RAGシステムを運用していると、厄介な失敗に出くわします。
回答は一見すると根拠がしっかりしている。
実際のチャンクもちゃんと引用している。
それなのに、よく読むと微妙に間違っている。
この「正しそうなのに、正しくない」という失敗が、いちばん見つけにくいのです。
RAGASのような評価ツールは、faithfulness（忠実性）やanswer relevance（回答の関連性）といった分かりやすい問題なら拾ってくれます。
ただ、それだけでは取りこぼすケースがあります。
先日、海外の技術コミュニティ（Reddit）でこのテーマの議論を見かけました。
本記事は、そこで交わされていた知見を私なりに整理したものです。
なぜRAGASだけでは取りこぼすのか
議論のなかで核心を突いていたのは、
「局所的には正しいが、全体としては間違っている」という指摘でした。
モデルは、取得したチャンクには忠実に答えています。
faithfulnessの観点では問題なし。
ところが、そのチャンク自体に問題が潜んでいることがあります。
情報が不完全だったり、古かったり、そもそも質問に対する適切な根拠ではなかったり。
すると、忠実なまま間違った答えが出来上がってしまうわけです。
つまり問題は、回答が根拠に沿っているかどうかだけではないんですよね。
どの根拠を引いてきたのか。
その根拠が本当に十分なのか。
ここを見ないと、きれいに引用された間違いを見逃します。
評価を分けて考える
この失敗を捉えるには、評価をいくつかの問いに分解すると見通しがよくなります。
議論で挙がっていた観点を整理すると、次のようになります。
- 検索は、似たテキストではなく本当に正しい資料を見つけられたか
- その文脈は、質問に答えるのに十分な情報を含んでいるか
- 引用は、回答の主要な主張をそれぞれ裏づけているか
- 取得した他の資料と矛盾していないか
- 情報源は信頼でき、十分に新しいか
- 根拠が弱いとき、システムはきちんと回答を控えるか
ひとつのスコアにまとめてしまうと、こうした違いは見えなくなります。
検索の質、文脈の十分さ、引用の妥当性。
だからこそ、これらを別々に測るのです。
すると、どこで崩れているのかが見えてきます。
引用元をUIに見せるという発想
自動検出ツールに頼る前に、もっと素朴な対策が効いたという声もありました。
回答のどの部分が、どのチャンクに基づいているのか。
これをUI上ではっきり見せる方法です。
すると、ユーザーは引用元と主張を見比べられます。
そして「この出典、実は主張を支えていないぞ」と、自分で気づくわけです。
そのため、ハルシネーションの検出を自動の仕組みだけに任せずに済みます。
実際、それで負担が減ったといいます。
この考え方は、社内のQAレビューにもそのまま使えます。
レビュー担当者が根拠をたどりやすくなるからです。
LLMジャッジの落とし穴
評価をLLMに任せる、いわゆるLLMジャッジも話題に上がっていました。
便利な一方で、鋭い指摘が出ています。
ジャッジ自体もハルシネーションを起こすのではないか、と。
評価する側が間違えれば、問題が一段上にずれるだけなんですよね。
ではどうするか。
人のフィードバックでジャッジを少しずつ補正していく方法が有効だ、という意見がありました。
やり方はこうです。
まず、実験管理ツールのトレースを使います。
そして、人手で見直した難しい事例（few-shot）をジャッジに与えます。
こうすると、口調などを見るだけの汎用ジャッジより、意味的な誤りを捉えやすくなります。
手間はかかります。
ただ、効果は大きいそうです。
似た話もありました。
汎用メトリクスを思い切って捨てた事例です。
微妙な誤りの具体例をあらかじめ仕込み、独自のジャッジを作ったといいます。
維持の負担は増えます。
それでも、表面的なスコアでは拾えない誤りをしっかり捕まえてくれるとのことでした。
コストとの折り合い
見落としがちなのがコストです。
プルリクエストやプロンプト変更のたびに本格的な評価を回すと、費用はあっという間に膨らみます。
ある人は、PRごとに評価する方式をやめました。
代わりに、夜間にまとめて敵対的評価（adversarial eval）を流すようにしたそうです。
これだけで費用が現実的な水準に収まったといいます。
ツールを比べるときは、課金体系も見ておくとよいでしょう。
トークン単位なのか、評価の実行回数単位なのか。
組み方しだいで、費用は数倍も動きます。
最後はやはり人の目
複数の意見が一致していたのは、結局のところ人による検証がいちばん正確だ、という点でした。
新しいフレームワークは次々と登場します。
それでも、人間ほどうまく判断できるものはまだ現れていない。
そんな実感のようです。
ワークフローを手軽に差し替えて試せるかどうかも効いてきます。
コードだけで何パターンも検証しようとすると、すぐに管理が破綻しがちです。
その点、ノーコードで素早く切り替えられる環境のほうが、変種のテストは回しやすいでしょう。
AIに数値を出させること自体は、もちろんできます。
精度は高くありません。
それでも、何もないよりはまし、という場面はあるはずです。
現実的な落としどころは、二段構えです。
自動の引用・根拠チェックに、人がレビューする少数の「意地悪な質問」セットを組み合わせる。
これがいまのところ手堅い印象でした。
まとめ
RAGの評価で最大のリスクは、必ずしもハルシネーションそのものではありません。
きれいに引用されているのに、間違った根拠の上に立っている回答。
これがいちばん怖いのです。
faithfulnessやrelevanceだけを見ていると、こうした回答は素通りしてしまいます。
だからこそ、検索の質、文脈の十分さ、引用の妥当性を分けて測る。
引用元をユーザーに見せて、本人が気づける形にする。
LLMジャッジは人のフィードバックで鍛える。
そのうえで、自動チェックと人の目を重ねる。
万能の一手はありません。
複数の角度から評価を積み重ねること。
それこそが「正しそうなのに間違っている」回答を減らす近道だと、この議論は教えてくれました。
