RAG精度改善ガイド｜評価指標で失敗原因を切り分ける【2026年版】

---

2026年、RAGは「作れるか」ではなく「測って直せるか」が問われる段階に入った。

PoCでは動いたのに本番では使えない――その失敗は、LLMの性能不足ではなく、元データ、チャンク、検索、評価、ログのどこかに潜む見えない故障である。

本記事では、RAGの精度が出ない原因を工程別に診断し、Ragasなどの評価指標を使って、どの順番で改善すべきかを判断できるようにする。

何が変わったのか

RAGは「作れるか」ではなく、「測って直せるか」が問われる段階に入りました。

2024〜2026年にかけて、RagasやDeepEvalなどのRAG評価フレームワークが整備され、「評価せずに改善する」こと自体がリスクになりつつあります。RAGは単なる検索付きチャットボットではなく、検索・生成・評価・運用ログを継続的に改善する業務システムとして扱う必要があります。

ある日の夕方。大手メーカーでバックエンドを担当する若手エンジニアの悠真は、自ら開発した社内ナレッジ検索用のRAGボットの画面を前に、深くため息をつきました。

「新製品AX-5000のUL規格に関する最新レポートは？」

自信を持って投げかけた質問に、ボットが返してきたのは、3年前に登録された旧製品AX-3000の暫定規格に関する古い回答でした。ベクトルデータベースも使っている。Embeddingも導入している。基本的なRAGの仕組みは整えている。それなのに、現場で聞かれる質問には的外れな回答を返してしまう。

この失敗は、特別なものではありません。多くのRAGプロジェクトは、PoC段階では「それらしい回答」が出るものの、本番に近づくほど次の壁にぶつかります。

• 必要な文書が検索されない
• 無関係な文書が混ざる
• 根拠はあるのに回答がずれる
• 引用元が古い、または不適切
• 評価データがなく、改善効果を説明できない
• 本番ログを見ても、どこで失敗したか分からない

つまり、RAGの精度改善とは、単に「LLMを最新モデルに替える」「Vector DBを高性能なものにする」ことではありません。RAGパイプラインのどの工程で失敗しているかを診断し、測定し、順番に直すことです。

RAG全体の仕組みや導入ロードマップについては、まず RAG完全ガイド を参照してください。本記事では、その中でも特に「精度改善・評価・失敗原因の切り分け」に絞って解説します。

なぜ今重要なのか

RAGの失敗原因は、生成モデルよりも前段のデータ・検索・評価設計に潜んでいることが多いです。

RAGの精度が出ないとき、多くの現場では最初にLLMの変更を検討します。しかし、実際にはLLMより前の工程で失敗しているケースが少なくありません。

たとえば、検索対象の文書が古ければ、どれだけ優秀なLLMでも古い情報を根拠に回答します。チャンクが文脈を壊していれば、検索結果に必要な情報が含まれていても、回答に必要な前後関係が欠落します。メタデータが不足していれば、部門、日付、製品、版数で絞り込むことができません。

RAGの精度低下は、主に次の7つに分解できます。

この7つのうち、どれがボトルネックかを見極めないまま改善を進めると、施策が迷走します。RAG改善の第一歩は、失敗原因を工程別に分解することです。

どう捉えるべきか

RAG評価では、検索品質と回答品質を分けて測ることが重要です。

RAGの改善では、「精度が悪い」という言葉をそのまま扱ってはいけません。精度が悪いと言っても、検索が悪いのか、検索後の順位付けが悪いのか、生成が悪いのか、評価設計が悪いのかで対策は変わります。

以下の診断表を使うと、症状から改善対象を切り分けやすくなります。

重要なのは、RAGを「一つのAI機能」として見ないことです。実務では、RAGを次の5工程に分けて観察します。

1. データ準備：古い文書、重複、表、PDF、権限、版数は整理されているか
2. 検索：必要な文書が取れているか、ノイズが混ざっていないか
3. 再ランキング：重要な文書が上位に来ているか
4. 生成：取得根拠に忠実に回答しているか
5. 評価・運用：失敗を測定し、改善履歴を追えているか

この工程分解ができれば、「LLMが悪いのか」「検索が悪いのか」「データが悪いのか」が見えるようになります。

RAG評価で見るべき主要指標

RAGの評価でよくある失敗は、回答だけを見て「良い・悪い」を判断することです。しかし、RAGでは回答が悪い原因が、検索側にあるのか、生成側にあるのかを分けて考える必要があります。

Ragasでは、Faithfulness、Answer Relevancy、Context Precision、Context Recallなどの指標を使って、検索品質と回答品質を分けて評価できます。2026年時点では、Ragasで評価指標やゴールデンデータセットを設計し、DeepEvalのようなpytestライクな評価フレームワークでCI/CDに組み込む、という併用パターンも広がっています。

Context Recallなど一部の指標は、期待回答や正解文書に相当するGround Truth / Referenceを前提とする場合があります。一方、FaithfulnessやAnswer Relevancyのように、取得文脈と生成回答の整合性を中心に評価できる指標もあります。評価設計では、必要な前提データ量、評価コスト、運用負荷が指標ごとに異なる点を押さえておくと、実装時の迷いが減ります。

Ragas v0.4+による評価プロジェクトの実行例

以下は、Ragas v0.4+のQuick Startに基づく評価プロジェクトの作成・実行イメージです。実務では、生成回答、検索で取得した文脈、期待回答、評価メトリクスを evals.py 側で定義し、改善前後のスコアを比較します。

# Ragas v0.4+でのセットアップ例
uvx ragas quickstart rag_eval
cd rag_eval
uv sync
export OPENAI_API_KEY="your-key"

# 評価の実行
uv run python evals.py

# 結果は experiments/ 以下にCSVとして保存される
# 例: experiments/2026-05-20_rag_eval_results.csv

※本コマンド例はRagas v0.4+のQuick Startに基づく実行イメージです。v0.1〜v0.3系の旧APIや旧CLIとは異なる場合があります。実装時は利用中のRagasバージョンと公式ドキュメントを必ず確認してください。

出力結果では、たとえば以下のような観点で改善前後を比較します。

faithfulness      0.91  # 回答が取得文脈に忠実か
answer_relevancy  0.87  # 回答が質問に適切に答えているか
context_precision 0.82  # 検索された文脈の上位に関連情報があるか
context_recall    0.78  # 回答に必要な根拠を取りこぼさず検索できたか

※スコアの目標値は、業務リスクや対象データによって変わります。社内FAQと法務レビューでは許容水準が異なるため、公式な固定基準として扱うのではなく、自社の評価セットに基づいて基準を設計してください。

実務ではどう判断するか

RAG改善は、派手な技術よりも、データ・検索・評価の基礎から順に整える方が成功率が高いです。

RAGの精度改善では、「最新技術を入れる」よりも「費用対効果の高い順に直す」ことが重要です。このセクションの「改善優先順位」は“何から手を付けるか”のチェックリスト、後半のロードマップは“いつ・誰が・どの順番で進めるか”をチームで共有するためのタイムラインと位置づけてください。以下の順番で進めると、失敗原因を見失いにくくなります。

チャンク改善：文脈を壊さない情報の切り分け

固定長で機械的に分割すると、重要な文章が途中で切れたり、表と説明文が別々のチャンクに分かれたりします。その結果、検索ではヒットしても、回答に必要な文脈が不足します。

改善策としては、以下が有効です。

• 見出し単位・段落単位で分割する
• chunk overlapを適切に設定する
• 表や箇条書きは説明文とセットで扱う
• 親子チャンク構造を使い、検索単位と回答単位を分ける
• PDFや規程文書では、ページ番号・章番号をメタデータ化する

from langchain_text_splitters import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=600,
    chunk_overlap=100,
    separators=["\n\n", "\n", "。", "、", " "]
)

documents = text_splitter.split_documents(raw_documents)
print(f"分割後のチャンク数: {len(documents)}")

Hybrid Search：意味検索とキーワード検索を併用する

ベクトル検索は、意味的に近い文書を探すのに強い一方、型番、規程番号、製品コード、顧客名などの完全一致検索には弱い場合があります。逆にキーワード検索は、固有名詞には強いものの、文脈理解には弱い傾向があります。

そのため、実務ではベクトル検索とキーワード検索を組み合わせるHybrid Searchが有効です。

• 製品型番や規程番号を取りこぼす場合は、キーワード検索を併用する
• 専門用語が多い業務では、BM25とベクトル検索を組み合わせる
• 検索後にRerankerを入れ、最終的な関連度を再評価する

Reranker：検索候補から本当に重要な根拠を選ぶ

RAGでは、検索候補を多く取れば良いとは限りません。top-kを増やすと必要な根拠を拾いやすくなる一方で、ノイズも増えます。ノイズが多いままLLMに渡すと、回答がぶれたり、古い文書を優先したりします。

Rerankerは、一次検索で広く候補を集めた後、質問との関連性が高い順に候補を並べ替える仕組みです。

生成制約：根拠にないことを答えさせない

検索結果が正しくても、LLMが根拠にないことを補ってしまえば、RAGの信頼性は下がります。RAGでは、生成プロンプトに以下の制約を入れることが重要です。

• 回答は取得文書の範囲に限定する
• 根拠がない場合は「不明」と答える
• 引用元を必ず示す
• 推測と事実を分ける
• 古い文書と新しい文書が矛盾する場合は、更新日を優先する

よくある失敗

RAG改善で失敗する現場は、技術選定よりも診断順序を間違えていることが多いです。
代表的な失敗は、いきなりGraphRAGに飛びつく、LLMを替えれば解決すると考える、評価セットなしで改善する、本番ログを見ない、の4つです。

GraphRAGは、人物、製品、組織、案件などの関係性を扱う強力なアプローチです。Microsoft GraphRAGが示すように、文章からエンティティと関係を抽出してナレッジグラフを構築し、その階層構造と要約を使って問い合わせ時のコンテキストを組み立てる、という「インデックス時に手間をかける」スタイルが基本です。

しかし、元データ、チャンク、メタデータ、検索評価が整っていない段階で導入すると、コストと複雑性だけが増えます。GraphRAGの詳細は、GraphRAGとは？RAG×知識グラフで実現する次世代AI検索で扱うのが適切です。本記事では、GraphRAGを「精度改善の最終手段の一つ」として位置づけます。

最新LLMに変更すれば回答品質が上がる場合もあります。しかし、必要な根拠を検索できていない場合、LLMを替えても根本原因は解決しません。LLM変更の前に、必要な根拠文書が検索されているか、検索順位は妥当か、古い文書や重複文書が混ざっていないか、回答が取得文脈に忠実か、評価セットで改善前後を比較しているかを確認します。

一次情報からどこまで言えるか

事実と解釈を分けることで、RAG改善の判断はぶれにくくなります。

一次情報から言えるのは、RAG評価と運用の実務化が急速に進んでいるということです。RagasはQuick Startで評価プロジェクトを生成する流れを整備し、DeepEvalはpytest型の評価実行やCI/CD統合を前面に出しています。Microsoft GraphRAGは、単純な類似検索ではなく、知識グラフ、コミュニティ階層、要約を使う構造化RAGとして位置づけられています。

一方で、これらの一次情報が示しているのは「すべてのRAGを高度化せよ」という話ではありません。むしろ、評価データ、実行ログ、検索品質の切り分けがないまま高度な仕組みを入れても、何が改善したのか分からないということです。

したがって、Arpableとしての解釈は明確です。RAG改善では、まずClassic / Hybrid RAGの失敗原因を測定し、必要な範囲だけReranker、Evals、GraphRAG、Agentic RAGを追加するべきです。

まとめ

RAG精度改善は、魔法の技術ではなく、失敗原因を測り、工程ごとに直す運用設計です。

本記事では、RAGの精度が出ない原因を、評価指標と工程別に切り分ける方法を解説しました。

RAGの精度改善で重要なのは、次の順番です。

1. 失敗ログを集める
2. 評価セットを作る
3. 元データとチャンクを見直す
4. メタデータとHybrid Searchを整える
5. Rerankerで検索候補を再評価する
6. 生成制約で根拠にない回答を抑える
7. Ragasや自社Evalsで改善前後を測る
8. 本番ログで継続改善する
9. 必要な場合だけGraphRAGやAgentic RAGを追加する

RAGの精度改善は、最新モデルへの乗り換え競争ではありません。「どこで失敗しているか」を測り、正しい順番で直すことが、RAGをPoCから本番運用へ進めるための最短ルートです。

専門用語まとめ

Context Precision

取得された文脈のうち、関連性の高い情報が上位に並んでいるかを評価する指標。

Context Recall

回答に必要な根拠文書を、検索でどれだけ取りこぼさず取得できたかを評価する指標。

Faithfulness

生成された回答が、取得された文脈にどれだけ忠実かを評価する指標。

Answer Relevancy

生成回答が、ユーザーの質問に対してどれだけ適切に答えているかを評価する指標。

Hybrid Search

ベクトル検索とキーワード検索を組み合わせ、意味検索と完全一致検索の弱点を補い合う検索手法。

Reranker

一次検索で取得した候補文書を、質問との関連性に基づいて再評価し、順位を並べ替える仕組み。

ゴールデンデータセット

RAG評価のために用意する、質問、期待回答、正しい根拠文書のセット。

GraphRAG

文書中の人物、組織、製品、概念などの関係性を知識グラフとして扱い、複数文書をまたぐ質問に答えるRAG手法。

Agentic RAG

AIエージェントが検索、評価、再検索、ツール実行を制御し、RAGを自律的に高度化する設計パターン。

参考文献 / 出典

次に読むならこの3本

補足Q&A

Q1.
RAGの精度改善で最初に見るべきポイントは何ですか？

A1.
最初に見るべきなのは、LLMではなく検索結果と元データです。

必要な根拠文書が取れていない場合、どれだけ高性能なLLMを使っても正しい回答は出せません。まず、取得チャンク、検索順位、旧版文書の混入、チャンク設計、メタデータを確認します。

Q2.
RAGの評価指標は何を使えばよいですか？

A2.
検索品質にはContext PrecisionとContext Recall、回答品質にはFaithfulnessとAnswer Relevancyを使うのが基本です。

ただし、最終的には業務上のTask Successや人間レビューも必要です。自動評価だけでなく、現場で使えるかどうかを確認する評価設計が重要です。

Q3.
RAG改善のROIはどう説明すべきですか？

A3.
短期的には、問い合わせ対応時間、一次回答の正答率、ヒューマンレビュー工数の変化を改善前後で比較するのが現実的です。

中長期では、GraphRAGやAgentic RAGの導入を含め、「回答可能な質問の範囲」や「ナレッジ継承コスト」を定量・定性の両面で計測し、LLMOps全体の投資対効果として位置づけます。経営層には、モデル精度だけでなく、業務時間削減、レビュー負荷低減、属人知識の再利用、監査可能性の向上まで含めて説明すると納得感が高まります。

更新履歴