RAGの評価方法｜Ragasの評価指標とボトルネック特定・精度改善

RAGの評価は「検索」と「生成」を分けて測る

結論として、RAGの品質劣化は検索と生成のどちらでも起きるため、評価も2つに分けないと原因が特定できません。

処理が2段階なら、壊れる場所も2つある

RAGは「質問に関連する文書を探す」工程と、「探した文書をもとに回答を書く」工程に分かれます。前者が失敗すれば、必要な根拠が手元にないまま回答が作られます。後者が失敗すれば、根拠はあるのに回答が文書から離れていきます。

症状はどちらも「回答が間違っている」で同じです。ところが打ち手はまったく違います。検索が原因なら埋め込みモデルやチャンク設計を触ることになり、生成が原因ならプロンプトや出力制約を触ることになります。

総合スコア1本では改善が止まる

「正答率72%」のような単一スコアは、報告には向きますが改善には使えません。72%の内訳が「検索で根拠を拾えなかった20%」なのか「根拠はあるのに回答が逸脱した20%」なのかで、次の一手が変わるためです。

評価設計の段階で、検索側の指標と生成側の指標を必ず別々に出しておきます。ここを分けておくと、改善の効果も「どの指標が動いたか」で説明できます。

評価は3つの層で考える

RAGの評価は、検索・生成・エンドツーエンドの3層で整理すると見通しが良くなります。

検索側は情報検索の古典的な指標（Recall@k、MRR、NDCGなど）がそのまま使えます。生成側はLLMを使った採点が中心になります。

ミニFAQ：検索指標だけ見ていれば足りますか。

足りません。検索が完璧でも、回答が文書にない内容を足してしまう（ハルシネーション）ケースは残ります。Faithfulnessのような生成側の指標を必ず併用してください。

RAG評価の主要指標｜Ragasで何が測れるか

結論から言うと、まずは4指標に絞って回すのが現実的です。RagasはRAG評価に特化したオープンソースのフレームワークで、利用可能な指標の一覧が公式ドキュメントに整理されています。

検索側の2指標

Context Precision は、検索した文脈のうち関連するものを上位にランクできているかを測ります。スコアが高いほど、上位に無関係な文書が混ざりにくい状態です。公式ドキュメントの定義では、各位置でのPrecision@kを算出し、その平均を取る形です。ノイズが上位に混ざるとスコアが落ちます。

Context Recall は、回答に必要な情報が検索結果に含まれていたかを測ります。こちらは「拾い漏れ」の指標です。Recallが低いまま生成側をいくら調整しても、根拠がないので回答は良くなりません。

生成側の2指標

Faithfulness は、回答が検索した文脈にどれだけ忠実かを測ります。回答を個別の主張（claim）に分解し、各主張が文脈から導けるかを検証して、支持された主張の割合をスコアにします。全主張が支持されれば1.0、半分なら0.5です。

Response Relevancy は、回答が質問の意図に沿っているかを測ります。執筆時点では、旧名称の answer_relevancy から Response Relevancy に変更されています。計算方法が独特で、生成された回答から逆に質問を複数作り、元の質問との埋め込みのコサイン類似度を平均します。事実の正しさは測っていない点に注意してください。回答が的外れでも内容が整合していれば高く出ます。

補助的に使う指標

Noise Sensitivityだけは向きが逆なので、ダッシュボードに並べるときは要注意です。無関係な文書に引きずられた誤りを見たい場合は、irrelevantモードを指定します。

正解データが必要かどうかの早見表

評価を設計するとき、最初に効いてくるのが「正解（reference）を用意できるか」です。

正解を作る工数が取れない立ち上げ期は、reference不要の3つ（LLMContextPrecisionWithoutReference、Faithfulness、Response Relevancy）から始める構成が取りやすくなります。NonLLM系はLLMを呼ばないため、文脈の照合が文字列で足りるケースではコストを抑えられます。

なお、Ragasは更新の速いOSSです。指標名・クラス名・必要なフィールドはバージョンによって変わることがあるため、実装時は利用中のバージョンの公式ドキュメントもあわせて確認してください。本記事の記載は執筆時点の公開ドキュメントに基づいています。

Ragasの使い方｜データ形式と実行の流れ

結論として、Ragasの導入で手間がかかるのは実行部分ではなく、評価データを揃える部分です。実行自体は数行で終わります。

評価データは4つのフィールドで持つ

公式のRAG評価ガイドでは、評価データを次のフィールドで持ちます。

ポイントは、retrieved_contexts を必ず記録しておくことです。本番のログに質問と回答しか残していないと、後から検索側の評価ができません。RAGを作る段階で、検索結果をログに落とす設計にしておいてください。

実行はデータセット化して評価関数に渡すだけ

辞書のリストを EvaluationDataset.from_list でデータセットに変換し、evaluate 関数に指標のリストと評価用LLMを渡します。評価用LLMは LangchainLLMWrapper などでラップして指定します。結果は指標ごとに0.0〜1.0のスコアで返ります。

指標の多くはLLMを使って採点するため、評価そのものにAPIコストがかかります。質問数 × 指標数 × 内部の呼び出し回数だけLLMが動く、と見積もっておくと予算を外しません。指標によっては1問あたり複数回の判定が走ります。式だけで見積もらず、まず10件程度の小さいサンプルで実測し、そこから比例させるのが確実です。

正解データがないときの進め方

referenceを用意できない場合でも、評価は始められます。

1. reference不要の指標（Faithfulness、Response Relevancy、WithoutReference版のContext Precision）だけで回す

2. 低スコアの質問を人手で見て、そこだけ正解を作る

3. 作った正解を評価セットに戻し、Context Recallを計測できる範囲を広げる

いきなり全件の正解を作ろうとすると、たいてい途中で止まります。低スコアから順に正解を作るほうが、同じ工数で得られる情報が多くなります。合成データで評価セットを作る仕組みもRagas側に用意されているので、テストデータ生成のドキュメントも確認しておくとよいでしょう。

ミニFAQ：評価用のLLMは、本番と同じモデルでよいですか。

別系統のモデルを使うほうが望ましい、というのが原則です。同じモデルだと自己採点に近くなり、甘く出る懸念があるためです。ただしコストや利用可能なモデルの制約で難しい場合は、同一モデルでも運用できます。その場合は、サンプルを人手で突き合わせて採点の傾向を確認してから使ってください。

評価データセットの作り方｜件数と質問の集め方

結論として、最初から大規模に作る必要はありません。30〜50問あれば、指標の傾向と大きなボトルネックは見えてきます。

件数は「毎週回せる規模」で決める

評価は1回で終わりません。改善のたびに回すものなので、1回の実行が現実的な時間とコストで終わる件数に抑えます。LLM採点を伴う評価は件数に比例してコストが増えるため、500問を月1回より、50問を週1回のほうが改善サイクルは速く回ります。

本番リリース前の最終確認など、節目では件数を増やした大きめのセットを別に用意する二段構えが扱いやすい形です。

質問は3つのソースから集める

• 実際の利用ログ：最優先です。想定質問と実際の質問は、言い回しも粒度もずれます

• 業務担当者へのヒアリング：導入先の現場が「これに答えてほしい」と思っている質問を拾います

• 文書からの合成：カバレッジを埋める用途。ドキュメントから自動生成した質問で、手薄な領域を補います

この3つを混ぜておくと、評価セットが特定の質問パターンに偏りにくくなります。

正解の作り方は先に合意する

正解の粒度がばらつくと、スコアも当然ばらつきます。着手前に次の点を決めておいてください。

• 正解は「文書からの抜粋」か「要約された回答文」か

• 複数の文書にまたがる質問を、どう正解として書くか

• 「答えられない」が正しい質問（文書に情報がない質問）を含めるか

3つめは見落とされがちですが重要です。情報がないときに素直に「わからない」と返せるかは、業務システムでは評価ポイントになります。

スコアからボトルネックを特定する

ここがRAG評価の核心です。指標を4つ並べたら、組み合わせで原因を切り分けます。

公開されている改善事例や実務で見かけるのは、1行目と2行目のパターンが多い印象です。そのため不調はまず検索側から確認する進め方が取られやすくなります。ただし常に検索が原因とは限りません。文書が古いまま放置されている、生成側の制約が足りない、といった構成では生成側が主因になることもあります。切り分けは指標で行い、順序は目安として扱ってください。

最後の行は見逃されやすいパターンです。スコアがすべて高いのに現場の評価が低い場合、評価セットが「答えやすい質問」ばかりになっている可能性があります。そのときは指標ではなく、評価セットのほうを直します。

RAGの精度改善｜効果が出やすい順に進める

結論として、改善は上流から順に当たるのが鉄則です。下流から触ると、原因が動いたのか偶然なのか分からなくなります。

1. ドキュメント前処理

もっとも地味で、もっとも効きやすい工程です。PDFから抽出したテキストの改行が壊れている、表がぐちゃぐちゃに潰れている、同じ内容の旧版と新版が両方入っている。こうした元データの問題は、どんな検索手法を入れても解決しません。

改訂履歴のある社内文書を扱う案件では、旧版の混入が精度低下の主因になっていることがよくあります。前処理の段階で版管理のルールを決めておきます。

2. チャンク設計

チャンクのサイズとオーバーラップ、分割の単位を見直します。固定長で機械的に切ると、見出しと本文が分断されたり、表が途中で割れたりします。見出し構造を保ったまま分割する、親子関係を持たせて検索は小さい単位・生成には大きい単位を渡す、といった設計が取られます。

3. 検索の改善

ベクトル検索だけだと、型番や固有名詞の完全一致に弱くなります。キーワード検索（BM25など）と組み合わせるハイブリッド検索は、社内文書RAGで採用例が多い構成です。加えて、検索結果を関連度で並べ替えるリランキングを入れると、Context Precisionが改善しやすくなります。

ベクトルDBの選定自体に悩む場合は、ベクトルDBの選び方｜Pinecone・Weaviate・Qdrant・pgvectorの使い分けで選定軸を整理しています。

4. 生成の改善

プロンプト側では、出典の明示を必須にする、文脈にない情報は書かせない、情報がない場合は「わからない」と答えさせる、といった制約が定番です。Faithfulnessのスコアは、この種の制約を入れるだけで改善することがあります。

5. 構成そのものを変える

ここまでやって頭打ちなら、RAGの構成を変える選択肢に入ります。文書間の関係性が重要な領域では、グラフ構造を使う方法もあります。詳しくはGraphRAGとは｜通常RAGとの違い・仕組み・構築案件の実務を参照してください。

ミニFAQ：いきなり生成モデルを上位モデルに変えるのは有効ですか。

Faithfulnessが低いケースでは効くことがあります。ただし検索側が原因の場合はほとんど改善せず、コストだけが上がります。切り分けを先にしてください。

評価ツールの選び方｜Ragas以外の選択肢

結論として、使っている基盤に評価機能が載っているなら、まずそれを試すのが早道です。

OSSとマネージドの使い分けは、3つの軸で考えると整理しやすくなります。

評価データに機密文書が含まれる案件では、採点用LLMにどこまでデータが渡るかも選定条件になります。ここは技術要件というより契約・情報管理の論点です。参画前に確認しておくと、後から構成をやり直さずに済みます。

研究動向としては、TREC RAG Trackで評価手法そのものの議論が進んでいます。評価設計の妥当性を顧客に説明する場面では、こうした公開評価の枠組みを参照すると話が通りやすくなります。

RAG評価でつまずきやすい点と対策

LLM採点のばらつき

LLMで採点する以上、同じ入力でもスコアが揺れます。対策は、温度を下げる、複数回実行して平均を取る、スコアの絶対値ではなく変化量で判断する、の3つです。

「0.78だから合格」ではなく、「改善前0.71 → 改善後0.78」で見ます。絶対値での合格ラインを顧客と握ってしまうと、後で苦しくなります。

評価コストの膨張

指標を全部入れたくなりますが、LLM呼び出しは指標ごとに発生します。日常の定点観測は4指標、節目のフル評価では補助指標も入れる、という二段構えにするとコストを抑えられます。NonLLM系の指標を混ぜるのも有効です。

評価セットの陳腐化

ドキュメントが更新されれば、昔作った正解は合わなくなります。文書の更新タイミングで評価セットを棚卸しする運用を、最初から組み込んでおいてください。

導入チェックリスト

着手時に確認しておくと手戻りが減る項目です。

• 検索結果（retrieved_contexts）がログに残る実装になっているか

• 検索側と生成側の指標を分けて出す設計になっているか

• reference を作れるか、作れないならreference不要の指標で始めるか決めたか

• 評価の実行コスト（質問数 × 指標数）を見積もったか

• 「情報がない質問」を評価セットに含めたか

• スコアの合格ラインではなく、変化量で判断する合意を取ったか

• 文書更新時に評価セットを棚卸しする運用を決めたか

RAG評価スキルはフリーランス案件でどう扱われるか

結論として、RAG構築案件では「作れること」より「良くできること」の比重が上がっています。PoCから本番運用に移る段階で、評価の仕組みを持っているかが問われます。

面談で聞かれやすいのは、次のような点です。

• 精度が出ないと言われたとき、どう原因を切り分けたか

• 評価データをどう用意したか（誰が正解を作ったか）

• 改善の効果をどう数字で示したか

ここで「プロンプトを調整しました」だけで終わると、評価されにくくなります。検索側と生成側を分けて測り、どちらが原因だったかを説明できると、同じ経験でも伝わり方が変わります。

案件そのものの内容や参画ルートはRAG構築案件の実情｜単価相場・必要スキル・獲得方法、評価・アノテーション寄りの関わり方はLLM評価・データアノテーション案件｜単価相場と参入ルートで整理しています。単価の水準は案件の役割や稼働によって変わるため、自分の経験でどのくらいを狙えるか知りたい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？にまとめています。

実装フレームワーク側の知識を補強したい場合は、LlamaIndexとは｜RAG構築の仕組み・LangChainとの違いを解説もあわせて確認してください。

まとめ

RAGの評価は、検索と生成を分けて測り、スコアの組み合わせからボトルネックを特定する作業です。ここが分けられていないと、改善は勘に頼ることになります。

• 中心は4指標。Context Precision / Context Recall（検索）と Faithfulness / Response Relevancy（生成）

• Faithfulness と Response Relevancy は正解データなしで測れる。立ち上げ期はここから始める

• Response Relevancy は事実の正しさを測らない。Faithfulnessと必ず併用する

• 評価セットは、PoCや初期運用なら30〜50問の定点観測から。実ログの質問を優先的に入れる

• 改善は前処理 → チャンク設計 → 検索 → 生成の順。上流から当たると原因が特定しやすい

• スコアは絶対値ではなく変化量で判断する。LLM採点は揺れるため

• 検索結果をログに残していないと、後から検索側の評価ができない。実装段階で設計しておく

次のステップとしては、手元のRAGで retrieved_contexts がログに残っているかを確認してみてください。残っていない場合、評価の前にそこから着手することになります。

参照した一次情報は以下のとおりです。各ツールの仕様は更新されるため、記載内容は執筆時点の公開情報に基づきます。

• Ragas 公式ドキュメント

• Ragas 利用可能な指標一覧

• Ragas RAG評価のはじめ方

• RAGAS: Automated Evaluation of Retrieval Augmented Generation（arXiv）

• TREC RAG Track