Databricks Certified Generative AI Engineer Associate 教科書
第5章 評価とモニタリング(Evaluation and Monitoring, 12%)
🎯 この節の学習目標
5-1で述べたとおり、RAGの品質問題の多くは検索段階に起因します。検索が質問に関連する文書チャンクを取得できていなければ、生成側のLLMは正しい回答を作りようがありません。したがって「回答がおかしい」と感じたら、生成(プロンプトやモデル)を疑う前に、まず検索を測るのが定石です。
検索は「クエリに対して文書をランキングして上位k件を返す」処理なので、その評価には情報検索の分野で確立されたランキング指標を使います。これらの指標には「どの文書がその質問に関連するか」という正解ラベル(質問と関連文書のペア)が必要です。
| 指標 | 測るもの | 直感的な問い |
|---|---|---|
| Precision@k | 取得した上位k件のうち関連文書の割合 | 「持ってきたものの中に、どれだけ当たりがあるか」(ノイズの少なさ) |
| Recall@k | 全関連文書のうち上位k件で拾えた割合 | 「拾うべきものを、どれだけ拾えたか」(取りこぼしの少なさ) |
| MRR(Mean Reciprocal Rank) | 最初の関連文書が現れる順位の逆数の平均 | 「最初の当たりが、どれだけ上位に出るか」 |
| NDCG(Normalized Discounted Cumulative Gain) | 関連度の高い文書ほど上位にあるかを、順位で割り引いて総合評価 | 「関連度の高いものから順に並んでいるか」 |
Precision@k と Recall@k は「上位k件に入っているか」だけを見て順位を区別しません。一方、MRR と NDCG は順位を考慮します。LLMのコンテキストにはチャンクが順に詰められ、上位の情報ほど活用されやすいため、順位を考慮する指標にも意味があります。
💼 例:k=5 での計算
ある質問に対する関連文書(正解)が全部で 4件(D1、D2、D3、D4)あるとします。検索システムが上位5件として次を返しました(✓=関連、✗=非関連)。
1位: D1 ✓ / 2位: X1 ✗ / 3位: D2 ✓ / 4位: X2 ✗ / 5位: D3 ✓
もし最初の関連文書が3位に初めて現れる並び(✗ ✗ ✓ …)なら、Reciprocal Rank は 1/3 ≈ 0.33 になります。NDCG はさらに、関連度に段階(高・中・低)があるとき「関連度の高い文書が上位にあるほど高スコア」となるよう順位で割り引いて計算し、理想的な並びを1として正規化した値です。
📝 試験のポイント
定義の対応付けが特に問われやすいです:「上位k件中の関連割合 → Precision@k」「関連文書のうち拾えた割合 → Recall@k」「最初の関連文書の順位に注目 → MRR」「順位(ランキングの並び)まで考慮した総合指標 → NDCG」。また、これらの指標には質問と関連文書の正解ラベルが必要である点も覚えておきましょう。
正解ラベル付きデータセットの整備には手間がかかります。MLflow 3 の統合評価フレームワーク(従来は Mosaic AI Agent Evaluation として提供。5-2)には、LLMジャッジで検索品質を評価する仕組みがあり、ラベルがなくても検索段階を診断できます。
「chunk relevance は低いが context sufficiency は高い」なら、必要な情報は取れているがノイズが多い(Precision の問題)、「context sufficiency が低い」なら、そもそも必要な情報が取れていない(Recall の問題)、というように切り分けられます。
これらの検索評価も、生成の評価(5-2)と同じく mlflow.genai.evaluate() に検索系スコアラー(mlflow.genai.scorers の RetrievalRelevance、RetrievalSufficiency など)を渡して実行できます。検索対象が Databricks AI Search(旧 Vector Search)のインデックスであっても、評価の入力は「質問と取得チャンク」なので同じ仕組みで測れます。検索と生成のスコアを1回の評価実行でまとめて取得し、MLflow 上で比較できるのが統合フレームワークの利点です。
試験では「この指標が低いとき、どの改善を行うべきか」という形で問われます。代表的な対応関係を押さえましょう。
| 症状 | 意味 | 主な改善アクション |
|---|---|---|
| Recall@k が低い(context sufficiency 不足) | 必要な情報を取りこぼしている | チャンキング戦略の見直し(サイズ・オーバーラップ、第2章)/ top-k を増やす / 埋め込みモデルの変更(ドメインに合うものへ)/ クエリの書き換え |
| Precision@k が低い(chunk relevance 低) | ノイズ(無関係チャンク)が多い | リランキング(re-ranking)の導入(3-5)/ メタデータフィルタで検索対象を絞る / top-k を絞る |
| MRR が低い | 当たりはあるが順位が低い | リランキングで関連文書を上位へ押し上げる |
注意したいのは top-k の増減がトレードオフである点です。top-k を増やせば Recall は上がりやすい一方、無関係なチャンクも増えて Precision が下がり、コンテキストが長くなってコストも増えます。だからこそ「何が足りないのか」を指標で特定してから対策を選びます。
ランキング指標の計算には「質問 → 関連文書(チャンク)」の正解ペアが必要です。作り方の実務ポイントは次のとおりです。
✅ この節のまとめ
mlflow.genai.evaluate() のスコアラーとして生成の評価と一括実行できる。問1. ある質問の関連文書は全部で4件ある。検索システムが返した上位5件のうち関連文書は2件だった。Precision@5 と Recall@5 の組み合わせとして正しいのはどれか。
正解:A
Precision@5 は「取得した5件のうち関連の割合」なので 2/5 = 0.4。Recall@5 は「全関連文書4件のうち拾えた割合」なので 2/4 = 0.5 です。BはPrecisionとRecallの分母を取り違えた計算、CとDは分子・分母の組み合わせが誤っています。「Precisionの分母は取得件数k、Recallの分母は全関連文書数」と覚えましょう。
問2. RAGアプリの評価で「取得コンテキストに正解を導くための情報がそもそも含まれていない」ケースが多いと分かった。取りこぼし(Recall)を改善するアクションとして最も適切なのはどれか。
正解:A
必要な情報が取得できていないのは検索段階(Recall)の問題です。top-k を増やして拾える範囲を広げる、チャンクサイズやオーバーラップを見直して情報の分断を防ぐ、ドメインに合う埋め込みモデルへ変更する、などが有効です。B・C・Dはすべて生成段階のパラメータであり、検索結果に情報が存在しない問題は解決できません。コンテキストにない情報はどんなLLMでも(捏造以外では)出力できません。
問3. 検索評価の結果、「必要な情報は上位k件に含まれているが、無関係なチャンクが多く混ざっている(Precisionが低い)」と分かった。最も適切な改善アクションはどれか。
正解:B
ノイズが多い=Precisionの問題には、取得候補を関連度で並べ直すリランキングと、文書種別・部署などのメタデータフィルタで無関係な文書を検索対象から除外する方法が有効です。Aのtop-k増加は無関係チャンクをさらに増やしPrecisionを悪化させます。Cの次元数変更に「必ず解決」という保証はありません。Dのチャンクサイズ変更は主にRecall・文脈の分断に効く手段で、ノイズ混入への直接の対策ではありません。
問4. 正解ラベル(質問と関連文書のペア)をまだ整備できていない段階で、検索段階の品質を診断したい。MLflow 3 の統合評価フレームワーク(旧 Mosaic AI Agent Evaluation)で使える方法として最も適切なのはどれか。
正解:B
chunk relevance(各チャンクは質問に関連するか)と context sufficiency(回答に十分な情報が取れているか)はLLMジャッジによる判定なので、関連文書の正解ラベルがなくても検索段階を診断できます。AのNDCGとDのRecall@kはいずれも「どの文書が関連か」というラベルがなければ計算できません。Cはジャッジによるラベル不要の評価が存在するため誤りです。