テストのセットアップ方法

著者は2つの支払いルールブックのドキュメントをもとに、小規模な検索拡張生成（RAG）システムを構築し、2つのチェックを実施しました。

  • 再現率（Recall）テスト – 正しいページが上位5件の結果に含まれていたか？ 結果：60%
  • 回答テスト – 生成器によって出力された最終的な回答は正しかったか？ 結果：90%

40%もの差があることは、一見不可能に思えました。もしリトリーバー（検索器）が10回中4回も正しいページを見逃しているとしたら、どうしてモデルは10回中9回も正しく回答できるのでしょうか？

リトリーバーを「修正」するための最初の試み

開発者は2つの一般的な手法を試しました。

  • ハイブリッド検索 – 語彙検索（lexical）とベクトル検索のシグナルを組み合わせる。再現率は変わらず。
  • リランカー（Reranker） – 取得した5つのページの順序を再構成する。再現率は70%に上昇しましたが、90%の回答精度には依然として大きく及びませんでした。

どちらのツールも、すでに取得されたものの順序を入れ替えるだけであり、候補セットに入っていないページを魔法のように出現させることはできません。問題は別のところにありました。

モデルではなく、メトリクス（評価指標）に問題があった

著者は、ページのラベルによって成功を判断するのではなく、取得されたチャンク内の実際の事実を調査しました。4回の「失敗」のうち3回において、正しい事実は存在していましたが、テストスクリプトが想定していたページとは異なるページに記載されていました。評価指標が、想定外のページで正しい回答を見つけたリトリーバーに対してペナルティを与えていたのです。

メトリクスを「取得されたチャンクのいずれかに必要な事実が含まれているか？」に変更したところ、再現率は90%に跳ね上がり、回答精度と一致しました。リトリーバーは機能していましたが、評価フレームワークが機能していなかったのです。

なぜ従来の再現率が誤解を招く可能性があるのか

  • ページレベルのラベル付けが見かけ上の失敗を生む。 一つの事実は複数のページに現れることがあります。特定の1ページのみを正解（ground truth）としてタグ付けすると、それ以外の正しいヒットがすべてエラーとして扱われてしまいます。
  • 小規模なコーパスがその影響を増幅させる。 ドキュメント数が少ない場合、1つのラベル付けミスが再現率を劇的に変動させる一方で、回答精度は安定したままということが起こり得ます。
  • 埋め込み（Embedding）のノイズが事実を隠してしまう。 ベクトルはページ全体をスコアリングします。周囲の法的または技術的なテキストがターゲットとなる文章の関連性シグナルを希釈してしまい、事実は含まれているにもかかわらず、ページのランキングが下がってしまうことがあります。

RAG実務家への実践的な教訓

  • ランキングの失敗とリトリーバルの失敗を切り離す。 リランカーは前者を修正するだけであり、正しいチャンクが候補セットに入っていない場合、順序を入れ替えても意味がありません。
  • テストデータを事実レベルでラベル付けする。 各クエリを単一のドキュメント識別子に紐付けるのではなく、必要とする具体的な情報に紐付けます。
  • 小規模なデータセットに対して大規模なベンチマークを鵜呑みにしない。 小規模でドメイン固有のコーパスは挙動が異なり、一般的な再現率スコアは誤解を招く可能性があります。
  • 埋め込みの粒度に注意する。 ページサイズのチャンクには多くの単語が含まれており、周囲の法的テキストが、関心のある事実のランクを下げてしまう可能性があります。

結論： 評価がタスクと一致していない場合、高い回答精度と低い従来の再現率が共存することがあります。モデルではなくメトリクスを修正することで、時間の節約、誤検知の削減、そしてより信頼性の高いRAGの導入が可能になります。