RAGの信頼性を高める「高精度ハイライト」の実装戦略
1. はじめに：RAGにおける参照元表示の重要性
現在、社内ドキュメントを参照して回答を生成するAIチャット（RAGシステム）を運用していますが、その信頼性、特にハルシネーションへの懸念が、利用拡大の障壁となっています。
信頼性向上のための「証拠」提示
この信頼性を向上させるには、単に回答を返すだけでなく、「この情報はどこから来たか」 という証拠を提示することが不可欠であると考えます。
RAGの回答と併せて、参照元ドキュメントを表示することがその第一歩です。
UXと信頼性を両立するハイライト機能
しかし、ドキュメント全体を表示するだけでは、ユーザーは根拠となる箇所を探す手間が生じ、UXを損ないます。
そこで我々は、回答に直結した文脈のみを色付けする関連箇所ハイライト機能を検討し、導入しました。
本記事では、このハイライト機能を実現するにあたり、我々が直面した 「精度とコスト」 のトレードオフについて、具体的な技術的アプローチと試算に基づき解説します。
2. 前提：現在のRAGシステムと制約事項
本記事で取り上げるハイライト機能は、既に稼働している以下のRAGシステムを前提としています。
2-1. RAGシステムのアーキテクチャ概要
-
LLM提供元: Azure OpenAI Service を利用しています。
→ このため、コスト計算やAPIの制約は、Azure OpenAIの価格体系および仕様に準拠します。 -
RAGのフロー: 標準的なRAG（質問 → ベクトル検索 → プロンプト生成 → 回答）が実装済みです。
-
利用シーン: 社内ユーザーが、社内ドキュメントベースのAIチャットを利用し、業務知識の検索や質問解決を行うことを想定しています。
2-2. UI表示とハイライトのスコープ
-
参照元表示の単位: 回答の根拠となった参照元ドキュメントは、最大で 5件のチャンク（ドキュメントの断片） がUI上に表示される設計です。
-
ハイライト対象は、この5件のチャンク表示部分です。
-
ハイライトの目的: ユーザーが、表示されたチャンクの中で「どの部分の文章」がLLMの回答に直接使われたかを直感的に把握できるようにすることです。
3. 参照箇所ハイライトの実現方法：二つのアプローチ
今回検討したハイライト実現方法は下記二つになります。
3-1. アプローチA：キーワード/チャンクベース検索（低精度・低コスト）
このアプローチは、既存のRAGフローで得られる情報のみを活用し、追加コストを発生させないことを最優先にします。
処理フローと具体的な実装
-
チャンク全体ハイライト:
RAGのベクトル検索でヒットし、プロンプトに組み込まれた5件の参照元チャンク全体をハイライト対象とします。 -
キーワード抽出:
LLMの回答文から、名詞や動詞など重要なキーワードを抽出します（これは追加のLLMリクエストなしで、形態素解析ライブラリやシンプルな正規表現で対応可能です）。 -
文字列マッチ:
抽出したキーワードが参照元チャンク内に含まれる場合、そのキーワード文字列のみをハイライトします。
| 項目 | 詳細 |
|---|---|
| 最大のメリット (コスト) | 追加の埋め込みAPIリクエストが一切不要。処理は完全に既存フロー内で完結するため、運用コストが最小限に抑えられます。 |
| 実装の容易さ | 実装が非常にシンプルで、ハイライトのアルゴリズムが単純な文字列検索に留まるため、開発工数が少ないです。 |
| 最大のデメリット (精度) | ハイライトが不正確になります。 実際に根拠となった文脈以外もハイライトされてしまうなど、文脈の関連性は無視されてしまいます。 |
3-2. アプローチB：ベクトル類似度検索（高精度・高コスト）
このアプローチは、文脈を考慮した文章・用語をハイライトに反映させ、より関連性の高い情報を提供することを目的とします。
処理フローと具体的な実装
-
回答文のベクトル化 :
LLMが生成した回答文全体を、改めて埋め込みモデル（Azure OpenAIのEmbedding API）に送信し、ベクトル化します。 -
ドキュメントの文単位ベクトル準備:
参照元チャンク内の文章を、事前に文単位や段落単位で分割・ベクトル化し、どこかに保持しておきます。 -
コサイン類似度計算:
ステップ1で得た 「回答ベクトルの意図」と、ステップ2の参照元の「各文のベクトル」との間でコサイン類似度 を計算します。 -
ハイライト決定:
類似度が特定の閾値以上（今回は0.9以上を採用）になった文のみを「回答の根拠となった文」として特定し、ハイライト対象とします。
コサイン類似度の閾値に関して
コサイン類似度検索の結果、その類似度を閾値として入手できます。
数値としては「-1」~「1」までの範囲で数字が小さいほど関連性が低くなります。
| 項目 | 詳細 |
|---|---|
| 最大のメリット (精度) | 精度が格段に向上します。回答の「意味」に最も近い文章だけがハイライトされるため、「なぜこの回答になったか」をユーザーは極めて直感的に理解できます。 |
| デメリット (コスト増) | リクエスト数が増加します。RAGの検索フェーズとは別に、回答生成後に必ず追加で複数回、埋め込みAPIへのリクエストが発生します。利用回数が増えるほど、このコストが運用費全体を圧迫します。（今回は参照元ドキュメントで5件、AI回答で1件の計6回の追加リクエストになりました。） |
| 実装の複雑性 | ドキュメントの文単位の分割・ベクトル化と、それに伴うインデックス管理が必要になるため、実装が若干複雑になります。 |
4. コスト vs 精度：具体的な増額イメージと試算
アプローチB（ベクトル類似度検索）を採用した場合、最大の懸念事項となるのが追加の埋め込みAPIリクエストによるコスト増加です。
ここでは、Azure OpenAIの価格に基づき、具体的な増額イメージを試算します。
4-1. コスト増加の前提条件
ベクトル類似度検索を採用する場合、RAGの通常のフローに加え、LLMの回答文・参照元ドキュメントそれぞれをベクトル化するための追加プロセスが発生します。
| 項目 | 詳細 | 備考 |
|---|---|---|
| 追加リクエスト数 | 1回のRAG実行につき、ハイライトのために1回の追加埋め込みリクエストが発生。 | LLMの回答文をベクトル化する。 |
| 埋め込みモデル | Azure OpenAIの標準埋め込みモデル（例：text-embedding-ada-002） |
現在、主流かつ最もコスト効率の良いモデル。 |
| 単価 | $0.0001 / 1,000 トークン | 非常に低価格ですが、リクエスト数が多いと影響大。 |
4-2. 具体的なコスト増額の試算イメージ（我々システムの数値を基に試算）
| 変数 | 値 | 備考 |
|---|---|---|
| 月間リクエスト数 (N) | 10000 回 | 社内AIチャットの月間総利用回数を想定。 |
| 平均回答トークン (T) | 200 トークン | LLMの平均回答長を想定。このテキスト全体をベクトル化する。 |
| トークン単価 (P) | $0.0001 / 1,000 トークン |
text-embedding-ada-002 の単価。 |
| 一回のリクエストあたりの埋め込み回数 | 6回 | ドキュメント5件➕AI回答1件の想定。 |
- 最新埋め込みモデルコスト（2025/10時点）
増額コストの計算式は、「総トークン数」に「単価」、「1リクエストあたりの埋め込み回数」をかけることで求められます。
試算結果
4-3. 試算結果の考察：コスト増加は許容範囲か？
試算の結果、月間1万回の利用想定で、ハイライトのための 追加コストは約 $1.2（約200円弱） になりました。これは、Azure OpenAIの埋め込みモデルの単価が極めて低いためです。
-
結論: コスト増加は極めて軽微であり、運用費への影響は無視できるレベルであると判断できます。
-
コスト vs 精度:
-
アプローチA (キーワード検索): コストは
0 - アプローチB (ベクトル類似度検索): コストは月数ドルだが、ハイライト精度が格段に向上し、サービスの信頼性とUXを担保できる。
-
アプローチA (キーワード検索): コストは
この考察により、コスト面はボトルネックにならないことが明確になったため、今回はアプローチB (ベクトル類似度検索)を採用することとしました。
5. さらなるハイライト精度の追求（AIの回答ベース）
アプローチB（ベクトル類似度検索）の精度をさらに高め、ユーザーに最高の信頼性を提供するための発展的な最適化を検討します。
5-1. セグメントの粒度を極める：最小意味単位でのベクトル化
ハイライトの正確性は、前処理の分割粒度に依存します。
- 課題と最適化: 現在の「文単位」からさらに踏み込み、「最小意味単位」（命題単位）でベクトルを構築します。
- 技術: 日本語の係り受け解析や意味的な区切りを捉える高度なNLP処理を導入。
- 効果: LLMが参照した最短のテキストを特定し、ハイライト範囲が広がることを防ぎます。
「NLP処理」とは
自然言語処理（Natural Language Processing）の略称。
人間が日常的に使っている言葉（自然言語）を、コンピュータが理解・分析・生成できるようにする一連の技術を指す。
5-2. その他の発展的ハイライト手法
| 手法 | 処理概要 | メリット | デメリット |
|---|---|---|---|
| プロンプトによる抽出 | LLMに対し、「回答生成後、その根拠となった具体的な文章を引用形式で示せ」と指示する。 | LLM自身が判断するため精度は高い。 | トークンコストが増加。引用文の揺れ（原文との不一致）リスクがある。 |
| 注意機構 (Attention) スコアの利用 | LLMモデル内部のAttention層から、回答生成時に参照した**重み（スコア）**を取得し、ハイライトに利用する。 | 理論的には最も正確。 | Azure OpenAIなどのマネージドサービスでは実装が非常に困難。 |
6. まとめ
本記事を通じて、RAGシステムにおける参照元ハイライト機能の実装は、本質的に「UXの向上」と「追加コストの発生」というトレードオフの関係にあることを分析しました。
最終的な結論と成果
| 項目 | 結論 | 理由と成果 |
|---|---|---|
| 技術選定 | 高精度のベクトル類似度検索を採用。 | コストが極めて軽微（月間 |
| ハイライトの課題 | 文脈の正確な紐づけに成功。 | LLMの回答文を再ベクトル化し、参照元ドキュメントの文単位ベクトルと比較することで、意味的な関連性の高い文章のみを抽出。 |
我々のAIチャットは、このハイライト機能の導入により、単に回答を生成するだけでなく、回答の根拠を直感的に提示できるようになりました。
ただ精度面はまだ改善の余地が多々あると考えています。
この知見が、何か皆様の一助となれば幸いです。
Discussion