AI
RAG 精度向上はどこから始める?原因の見分け方と方式選定の基準

社内検索や問い合わせ対応のRAGで回答品質が安定しない事業責任者向けに、元データ、検索、回答生成の問題を切り分ける方法を解説します。Vector RAG、ハイブリッド検索、Agentic RAG、GraphRAGの選定基準と、費用や応答時間を含むRAG 精度向上の評価方法が分かります。
はじめに
RAGの回答が間違っていると報告を受けると、事業責任者は生成AIの性能や検索方式を疑いがちです。 しかし、利用者が確認できるのは最後の回答だけです。 規程が登録されていない場合も、検索で取りこぼした場合も、生成AIが根拠を読み違えた場合も、利用者には同じ回答の間違いに見えます。
原因を切り分けるため、RAGの処理を理解します。 社内文書などから関連情報を探し、その内容を生成AIへ渡して回答を作る仕組みがRAGです。 AWSのRAG解説↗では、文書の取り込み、質問、関連情報の検索、回答生成という流れを説明しています。 失敗した箇所を確かめずに方式を変更すると、費用が増えた理由は分かっても、精度が改善した理由を説明できません。
RAG 精度向上に取り組む責任者は、まず元データ、検索、回答生成のどこに原因があるかを調べます。 方式を選ぶのは、原因を切り分け、質問の性質を確認した後です。
RAG 精度向上は元データ、検索、回答生成の順に切り分ける
原因を切り分けるには、正答の根拠となる文書と質問時の検索結果を最初に確認します。 生成された文章だけを見ても、どの処理で失敗したかは分かりません。
確認する順序は、元データ、検索結果、回答生成です。 正しい根拠が登録されていなければ、どの検索方式でも取得できません。 根拠が登録済みなのに検索結果へ現れない場合は、検索側を調べます。 正しい資料を取得しているのに回答が違う場合は、回答生成が調査対象です。 この順序で確認すれば、改修対象を絞れます。
代表的な症状は、次のように分類できます。
| 利用者から見える症状 | 確認する箇所 | よくある原因 | 最初の対応候補 |
|---|---|---|---|
| 古い規程を答える | 元データ | 旧版が残っている、更新されていない | 文書の版管理、更新手順の整備 |
| 根拠のある質問に答えられない | 検索結果 | 文書の分割が不適切、言い換えを拾えない | 分割単位、ベクトル検索の調整 |
| 製品コードや固有名詞を取り違える | 検索結果 | 意味の近さだけで検索している | キーワード検索の併用 |
| 正しい資料を取得しても回答が違う | 回答生成 | 指示が曖昧、複数資料が矛盾している | 回答ルール、優先する資料の明確化 |
| 部門をまたぐ質問で情報が欠ける | 検索と質問処理 | 一度の検索では条件を拾い切れない | 質問の分解、複数回の検索 |
切り分けには、実際の利用者が尋ねる質問と正答の根拠となる文書を組にした評価データを使います。 問い合わせ履歴から、頻度が高い質問、誤答時の損失が大きい質問、回答不能が許される質問を責任者が選べば、事業上の優先順位を評価へ反映できます。 回答の良し悪しだけを確認するより、改修すべき箇所を絞りやすくなります。
Vector RAGとハイブリッド検索は文字一致の必要性で使い分ける
元データに問題がなくても、検索処理が意味の近い文書を取得できないことがあります。 正答の根拠となる箇所が検索結果の下位に埋もれている場合も、既存の検索処理を調整します。
自然文による検索では、文章を数値の組へ変換し、質問との意味的な近さで文書を探す方法があります。 この方式がVector RAGです。 表現が一致しなくても関連文書を見つけられるため、自然文で尋ねる社内検索に向いています。 担当者は、文書の分割、検索件数、対象範囲、検索後の並べ替えを確認します。
意味の近い文書が検索結果に並ぶだけでは足りない業務もあります。 就業規則の条番号、型番、契約番号、日付では、文字の一致が判断を左右します。 意味の近さだけで検索すると、こうした情報を取りこぼす可能性があります。
文字の一致も必要な場合は、全文検索とベクトル検索を同時に行い、結果を統合します。 この方式がハイブリッド検索です。 Azure AI Searchの公式文書↗でも、製品コード、専門用語、日付、人名などをキーワード検索に適した例として挙げています。
対象業務が単一の文書群への事実確認であれば、検索条件の調整とデータ整備だけで目的を満たせる可能性があります。 責任者は方式を増やす前に、既存方式でどこまで改善できるかを確かめます。
Agentic RAGとGraphRAGは質問の性質で選ぶ
一度の検索で情報を拾い切れない場合は、検索件数を増やすだけでは解決しないことがあります。 複数の条件や情報源を扱う質問では、調査対象を分ける必要があります。 文書全体の関係や傾向を調べる質問では、個々の検索結果を集めるだけでは関係を把握しにくくなります。
複雑な質問を条件や情報源ごとの小さな検索へ分け、情報が不足している場合は検索を重ねる構成があります。 この構成がAgentic RAGです。 Azure AI SearchのAgentic retrieval↗では、複雑な質問を複数の小さな検索へ分解し、結果をまとめる処理を説明しています。 たとえば、取引条件を満たし、過去に同種の事故がなく、今期中に納品できる仕入先を探す仕事では、担当者が条件ごとに確認します。
文書内の関係を扱うには、人、組織、製品、出来事などの関係を抽出し、そのつながりを使って情報を探す方法があります。 この方式がGraphRAGです。 MicrosoftのGraphRAG Query Engine公式資料↗では、特定の対象に関する検索と、データ全体を俯瞰する検索を分けています。 顧客の要望と不具合、製品、担当部署の関係を調べる場合や、多数の報告書から共通傾向をまとめる場合が候補です。
Agentic RAGとGraphRAGは、Vector RAGより常に高い精度を出す方式ではありません。 選定基準となるのは、扱う質問の性質です。
| 質問や失敗の特徴 | 選択肢 | 判断時の注意点 |
|---|---|---|
| 言い換えた質問で文書を探したい | Vector RAG | 文書の分割と検索対象を先に確認する |
| 型番や固有名詞と意味検索を両立したい | ハイブリッド検索 | 検索結果の統合方法も評価する |
| 一つの質問に複数の条件や情報源がある | Agentic RAG | 検索回数、応答時間、外部接続権限が増える |
| 複数文書の人物や案件の関係をたどりたい | GraphRAG | 関係抽出の品質と索引更新の負担を確認する |
| 用語の意味や分類が部署ごとに揺れる | 用語集やオントロジーの整備 | 検索方式だけで用語の不一致を解決しない |
検索方式を変えても、部署間の用語の揺れは解消しません。 顧客、案件、解約といった語の定義が部署ごとに異なるなら、各部署の責任者が定義をそろえる必要があります。 概念と関係を組織として定義する仕組みがオントロジーです。 オントロジーを採用する場合、組織は定義を承認する人と変更する人も決めなければなりません。 ナレッジグラフや検索方式を増やす場合は、この運用負担も選定条件に含めます。
RAG 精度向上の事業効果は業務指標で測る
検索と回答を改善すると、正答率の上昇を期待できます。 しかし、投資効果を正答率だけで判断しても、業務への効果は評価できません。 回答を探す時間、確認作業、誤案内の影響、利用者が自己解決できる範囲も確認します。
業務への効果は、利用場面によって異なります。 社内規程検索では、人事や総務への定型問い合わせが減る可能性があります。 顧客対応では、担当者が資料を探す時間や回答のばらつきを抑えられるかもしれません。 営業支援では、担当者が過去事例を見つけやすくなれば、提案準備を短縮できる可能性があります。 効果の大きさは文書の状態、利用頻度、業務手順に左右されるため、導入前に一律の数値では示せません。
改修の優先順位は、誤答の件数だけでは決められません。 福利厚生の案内と契約条件の回答では、同じ一件の誤答でも損失が異なります。 各質問を利用頻度と誤答時の影響で分類すれば、高リスク領域に人の確認を残すか判断できます。
高度な方式には、追加の処理時間、利用料、保守作業が伴います。 Agentic RAGは単一検索より待ち時間が増えることがあり、GraphRAGでは担当者が文書から関係を抽出し、索引を作り直す工程が必要です。 責任者は、精度の上昇分が追加費用と運用負担に見合うかを確かめたうえで方式を選びます。
RAG 評価は検索結果と最終回答を分けて行う
方式の変更前後で最終回答だけを比べても、どの処理が改善したかは判断できません。 実際の業務質問を固定し、変更前後の検索結果と最終回答を分けて評価します。 正答率に加えて、根拠、回答不能時の挙動、応答時間、費用を記録すれば、責任者は現場投入の可否を比較できます。
評価項目は、回答の正しさだけではありません。 MicrosoftのRAG評価ガイド↗は、回答が根拠に沿っているか、質問を漏れなく扱っているか、関連しているか、事実として正しいかを別の評価項目として扱っています。 生成AIの出力は同じ入力でも変わり得るため、同ガイドでは単一の結果を基準にせず、一定の範囲で評価する考え方も説明しています。
事業責任者がRAG 評価の計画に入れる項目は、次のとおりです。
- 現場の問い合わせ履歴から評価用の質問を選ぶ
- 各質問に正答、根拠文書、許容できる回答を設定する
- 検索結果に正しい根拠が含まれるかを確認する
- 最終回答の正確さ、根拠表示、回答不能時の挙動を確認する
- 応答時間、一件当たりの費用、人による確認時間を比較する
- 文書の追加や更新後も同じ評価を繰り返す
合格基準を平均値だけで定めると、高リスクな誤答を見落とすおそれがあります。 責任者は契約、価格、法令、健康や安全に関わる質問を別に集計し、必要なら人の承認を必須にします。 合格基準には、目標とする精度に加えて、自動回答を許す質問の範囲も定めます。 責任者は、これらの基準を基に運用の可否を判断できます。
まとめ
RAGの回答が間違っているときは、複数の原因を想定します。 元データ、検索結果、回答生成の順に確認すれば、改修する箇所を切り分けられます。
質問に合う方式は、検索で扱う情報の性質によって異なります。 単一文書の検索ではVector RAGの調整、文字一致も必要な場合はハイブリッド検索、複雑な条件の調査ではAgentic RAG、関係や全体傾向の把握ではGraphRAGが候補です。 用語の不一致が原因なら、組織は先に用語集やオントロジーを整備します。 方式を複雑にしても、精度が同じ割合で上がるとは限りません。
最初に行うのは、実際の問い合わせから少数の評価用質問を作り、現在の方式における検索結果と回答を記録する作業です。 両者を分けて記録すれば、利用者には見えなかった失敗箇所を判別できます。 責任者は、その結果を基に、データ整備で対応するか、検索方式へ投資するかを選びます。
参考文献
- Understanding Retrieval Augmented Generation - AWS Prescriptive Guidance↗
- Hybrid Search Overview - Azure AI Search | Microsoft Learn↗
- Agentic Retrieval Overview - Azure AI Search | Microsoft Learn↗
- Overview - GraphRAG↗
- Develop a RAG Solution on Azure - Large Language Model End-to-End Evaluation Phase - Azure Architecture Center↗
