LlamaIndex Evaluating は「RAG が悪い」を分解して測り直させる
このノートは原文の代替ではありません。読むべきポイントと実装上の意味を整理し、原典への入口を示します。
要点まとめ
- RAG の答えが悪い時に、検索が悪かったのか、取れた根拠をまとめる段階で壊したのかを分けずに直し始めると、改善が外れやすい。
- この docs は、その切り分けを測定でやれと求めている。まず「必要文書を取れたか」と「取れた文書から答えを崩さなかったか」を別々に見る。
- そのあとで、検索側には retrieval evaluation、答え側には response evaluation を当て、MRR や faithfulness のような指標はそれぞれの層で使い分ける。
- 実務上の最初の一歩は、最近の誤答ログを「検索失敗」と「答え生成失敗」に切り分けることだ。
読み終えたら次へ
この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。
何が変わったのか
このページは evaluation を「答えの良し悪し」から「部品ごとの測定」へ移しています。response evaluation では faithfulness や context relevancy のように、答えが文脈に沿っているかを見る。一方 retrieval evaluation では、ground-truth ranking を前提に MRR、hit-rate、precision などで retriever の順位付けを評価する、と分けています。 この整理は地味ですが強いです。RAG を 1 本のスコアで管理すると、retriever が壊れているのに prompt tuning へ走る、答え生成が壊れているのに vector DB を差し替える、といった無駄が起きます。
なぜ重要か
日本の RAG 現場では、PoC 段階の成功体験が強すぎて、改善もつい手触りベースになります。少し失敗すると chunk size や embedding モデルをいじりがちですが、それが正しいとは限りません。この docs は、最低限の measurement discipline を導入する入口になります。 PM にとっても意味があります。精度改善の依頼を「もっと賢くして」で終わらせず、retrieval 側の KPI と answer synthesis 側の KPI を別管理できるからです。
技術的ポイント
- response evaluation は、答えが source に忠実か、質問と文脈に関連しているかを見る層です。faithfulness や context relevancy のような観点が中心になります。
- retrieval evaluation は、ground-truth rankings を前提に、MRR、hit-rate、precision などの ranking metrics で retriever を独立評価します。
- この分離により、「正しい document を取れたが答えが崩れた」と「document 自体を取れていない」を別 failure class にできます。
- 評価 dataset を雑に 1 つ作るだけでは足りません。自社タスクでは、質問、期待根拠、許容回答、禁止回答を揃えないと metrics が意味を持ちにくいです.
英日キーワード
| 英語 | 日本語 | 補足 |
|---|---|---|
| response evaluation | 応答評価 | 出てきた答え自体の妥当性を測る評価。検索とは別に切り分けて見る。 |
| retrieval evaluation | 検索評価 | 必要文書を上位へ持ってこられたかを測る評価。RAG の retriever 側を独立に見る。 |
| faithfulness | 根拠忠実性 | 答えが与えられた文脈から逸脱していないかを見る観点。 |
| context relevancy | 文脈関連性 | 取り出した文脈が質問に本当に関係しているかを見る観点。 |
| MRR | 平均逆順位 | 正解候補がどれだけ上位に来たかを測る ranking 指標。 |
| hit-rate | 的中率 | 上位候補に正解が入った割合。retrieval 改善の基本指標。 |
試すなら
- 最近の誤答を 20 件ほど集め、「検索失敗」「答え生成失敗」「両方」の 3 区分で人手ラベルを付ける。
- retrieval 用には正解 document の期待順位を決め、MRR か hit-rate を 1 つでも回す。
- response 用には、faithfulness と質問適合性を別チェックにし、同じ誤答を 1 点で潰さない。
- 改善実験は 1 回につき retrieval 側か synthesis 側のどちらか片方だけを変える。
注意点
- LlamaIndex の docs ですが、考え方自体は framework 非依存です。API 名を追うより測定分解の発想を使うべきです。
- 自動評価だけで十分とは書けません。特に業務文書では、人手サンプル確認を外すと誤った指標最適化に寄る危険があります。
- ground truth が曖昧なタスクでは、MRR や hit-rate の数字だけを強く信じないほうがよいです。
この記事は役に立ちましたか
公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。