# 正解データが変わり続ける中でRAGをどう評価するか

- 番組: [AI Engineering Podcast](https://ai-curator.jp/podcasts/shows/cmv8ukqpf00017110ed1v5oja)（Tobias Macey）
- 元のタイトル: How to Evaluate RAG Systems When Ground Truth Keeps Changing
- 配信日: 2026年10月7日
- 長さ: 1時間2分
- 要約作成日: 2026年10月15日
- トピック: [#RAG](https://ai-curator.jp/topics/RAG) [#LLM-as-a-judge](https://ai-curator.jp/topics/LLM-as-a-judge) [#RAG評価](https://ai-curator.jp/topics/RAG%E8%A9%95%E4%BE%A1) [#エージェント](https://ai-curator.jp/topics/%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#コンテキストエンジニアリング](https://ai-curator.jp/topics/%E3%82%B3%E3%83%B3%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0) [#text-to-SQL](https://ai-curator.jp/topics/text-to-SQL)
- URL: https://ai-curator.jp/podcasts/cmv8ukrjq001k7110mror5qs0

## 要約

Vectara出身のOfer Mendelevitch氏が、本番環境でRAGを運用する際の課題と評価手法をTobias Macey氏と語った回。大規模データの取り込み、ハイブリッド検索、リランキング、マルチモーダル対応といった実運用の難しさを整理し、正解データ作りが非現実的な場合の代替としてUMBRELAやAutoNuggetizerなどのLLM-as-a-judge手法、合成質問、本番トラフィックのサンプリングを紹介している。さらにエージェント型RAG、コンテキストエンジニアリング、コーディングエージェントの活用にも話が及んだ。

## ポイント

- RAGは「PDFと対話する」デモから、数百万件規模の取り込み、差分更新、マルチモーダル、ハイブリッド検索、リランカーを備えた本番システムへ進化したと述べている。
- 評価は検索精度と生成精度を分けて考えるべきで、数千万チャンクへの人手ラベル付けは現実的でなく、正解回答も組織や製品の変化で陳腐化しやすいという。
- UMBRELAは各チャンクを0〜3で採点するLLM判定手法で、Jimmy Lin氏の研究室が人間の判断との高い相関（約80%と記憶していると本人は述べる）を確認した。AutoNuggetizerは回答が重要情報を取り込んでいるかを見る。
- 評価の立ち上げには、合成質問の生成、本番ログの分析、専門家への質問募集が有効。オンライン評価はレイテンシとコストを避けるため、サンプリングして非同期で行うことを勧めている。
- エージェント型RAGは検索を一つのツールとして扱い、クエリ書き換えや反復を可能にした。一方、外部ツールの検索品質への依存やオンプレミス要件というトレードオフがある。
- RAGはコンテキストエンジニアリングにおける『アテンションのような選択機構』と捉えられるという独自の見方を示し、権限管理（RBAC）のメタデータフィルタも重要な実務課題として挙げた。

## 章立て

- [00:00] **ゲスト紹介と経歴** — Ofer氏が2000年代初頭の機械学習の経験からGPT-2、著書『Hands-On RAG for Production』までを振り返る。
- [05:21] **RAGの役割と取り込みの難しさ** — RAGが登場した背景と、大規模ファイル、更新戦略、マルチモーダルなど本番での取り込みの課題を説明する。
- [09:38] **ハイブリッド検索とリランカー** — ベクトル検索に加え、BM25などの語彙検索との統合やリランキングが現在の標準になっていると語る。
- [14:51] **検索と生成の評価手法** — 正解データ作成の限界と、UMBRELA、AutoNuggetizerというLLM判定手法を紹介する。
- [24:57] **合成データとオンライン評価** — 合成質問、ログ活用、回帰テスト化、サンプリングによる非同期のオンライン評価を解説する。
- [29:17] **エージェント型RAGとツール** — 単発のRAGからエージェント型へ進化した経緯と、MCPなどツール接続のトレードオフを議論する。
- [36:38] **コーディングエージェントとコンテキスト** — データパイプラインでのコーディングエージェント活用と、RAGとコンテキストエンジニアリングの関係を述べる。
- [42:59] **実運用の工夫と今後の展望** — 権限管理、マルチモーダルUI、エアギャップ環境、中国製モデルへの抵抗感、エージェント群の将来、text-to-SQL、教育の課題を語る。

## 解説記事

AI Engineering Podcastの今回の回では、Vectaraで活躍し、O'Reillyから『Hands-On RAG for Production』を出版したOfer Mendelevitch氏が、ホストのTobias Macey氏と、RAGシステムを本番で評価する難しさについて語った。正解データが不完全で、しかも常に変化する状況でどう品質を保つのかが主題である。

#### 「PDFと話す」から本番システムへ

Ofer氏によれば、RAG（検索拡張生成）が注目された最大の理由は、LLMが企業の私的データを知らないことだった。Google DriveやNotionなどのデータを取り込み、検索で関連チャンクを取り出してプロンプトに渡すという単純な発想で、デモは容易に作れた。

しかし本番では話が違う。15,000ページのPDFや数千万件のファイルをどう処理するのか、途中でエラーが出たらどうするのか。更新のたびに全件を再取り込みせずに済ませる仕組みも要る。さらに、グラフや図表に価値が埋め込まれていたり、研修動画があったりと、マルチモーダルへの対応も欠かせないという。

検索側も、ベクトル検索だけでは足りない。TF-IDFやBM25といった従来の語彙検索を組み合わせるハイブリッド検索と、精度を補うリランカーが現在の標準的な構成だと説明している。

#### 評価が最も難しい理由

Tobias氏が指摘するように、チャンク分割、モデル、プロンプト、リランカーのどれを変えても出力は予測しにくく変わる。Ofer氏は、評価では検索精度と生成精度を分けて考えるべきだと述べる。

適合率や再現率といった古典的指標は正解ラベルを必要とする。だが数千万チャンクを人手で判定することは現実的ではない。生成側でも、千問ほどの質問と模範回答を作る方法はあるが、30年続く組織では答えを知る人がいなかったり、製品の更新で答えが変わったりして、維持が難しい。

#### UMBRELAとAutoNuggetizer

そこで有力なのがLLM-as-a-judge（LLMを採点者にする手法）である。UMBRELAは、上位チャンクそれぞれを0（無関係）から3（問題をほぼ解決する）で採点する。Jimmy Lin氏のウォータールー大学の研究室が、特定のプロンプトで人間の判断との相関が高いことを確認しており、Ofer氏は約80%だったと記憶していると話す。プロンプトを勝手に変えず、検証済みの形で使うことが重要だという。

AutoNuggetizerは、回答が高く評価されたチャンクの重要情報（ナゲット）を正しく取り込んでいるかを確かめる、生成側の評価手法である。ナゲット生成にLLMを使う点が自動化の部分だと説明された。

#### 評価の立ち上げと運用

評価データがゼロの状態からは、取り込んだ文書をLLMに読ませて多様な質問を合成する方法が有効だという。ただし複数文書にまたがる質問は難しい。すでに稼働中なら、ログから実際の質問を拾い、専門家にも質問案を求める。評価セットはバージョン管理し、回帰テストに組み込むべきだと述べている。

オンライン評価は、レイテンシとコストが問題になる。Ofer氏は、まずオフラインを整え、あとから段階的に追加することを勧める。また全クエリではなく5〜20%程度をサンプリングし、ユーザーを待たせず非同期で診断として使う方式を挙げた。

#### エージェント型RAGとコンテキストエンジニアリング

エージェント型RAGは、クエリの書き換えや複数回の検索を可能にしたもので、長いコンテキストウィンドウの普及が後押ししたと説明している。現在のエージェントは、検索ツール、text-to-SQL、MCP経由の各種SaaSのAPIなどを使う。ただし外部ツールの検索品質に依存するため、品質が低ければ役に立たない。オンプレミスやエアギャップ環境では、データをローカルに取り込む選択も残るという。

コンテキストエンジニアリングについては、LLMに渡す内容を設計者が制御することだと整理し、RAGはその中の「アテンションのような選択機構」だと捉える見方を示した。実運用では、ロールベースのアクセス制御をメタデータのフィルタで検索前に適用する工夫や、動画の該当秒数まで示すUIも重要だと述べる。

また、コーディングエージェント同士に相互レビューをさせる手法や、役割別のエージェント群で協調させる流れにも触れた。長いセッションでコンテキストが劣化する問題は未解決だという見方も示している。

#### まとめ

Ofer氏の主張の核は、チームが評価を後回しにして苦労するという点にある。正解データが作れないなら、検証済みのLLM判定手法と合成質問、本番ログを組み合わせ、回帰テストとして育てることが現実的な道筋になる。日本の開発現場でも、検索と生成の評価を分離して設計し、権限管理やオンプレミス要件を初期から考慮する視点は参考になるだろう。教育や組織面のギャップが技術以上に大きいという指摘も、AI導入を進める企業にとって示唆的である。

> この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: AI Engineering Podcast「How to Evaluate RAG Systems When Ground Truth Keeps Changing」