本番環境のRAGシステム向けに回帰ゲートを構築する方法

あるチームが社内のポリシー文書をもとに検索拡張チャットボットを構築した。デモで「育児休暇は何日ありますか」と聞かれ、ボットは正しく答え、正しい PDF を引用した。経費精算の上限額を聞かれ——これも正解。10 問出して 10 問正解、拍手が起きてリリース。3 か月後、ある従業員が自分の業務委託契約の立場が健康補助の対象になるかと尋ねると、ボットは自信たっぷりに「対象です」と答え、その根拠は昨年すでに置き換えられたポリシーだった。従業員はそれを信じて申請した。チームの誰も、このパイプラインがいつからこうした回答を出し始めたのか説明できなかった。それがそうなっているかどうかを測るものが、そもそも何もなかったからだ。

これが本番環境の RAG システムの実態だ。パイプラインが特別に不正確というわけではない——どんな検索システムにも取りこぼしはある。欠けているのは、問題を察知する仕組みのほうだ。デモは評価と見なされたが、デモこそ RAG システムがほぼ確実に通ってしまう種類のテストだ。質問はインデックスを構築した本人が選び、言い回しは文書中の表現と一致し、中身があると誰もが知っていることを聞く。

誤った回答と正しい回答は見分けがつかない

従来のソフトウェアは壊れるとき、大きな音を立てて壊れる。API 呼び出しが失敗すれば例外が飛び、デプロイに問題があれば 500 が返り、テストケースが落ちれば赤くなる。RAG の劣化はそのどれもしない。embedding モデルを差し替え、chunk サイズを変え、文書更新後に再インデックスする——それでもシステムは流暢で整った形式の、自信に満ちた引用付きの回答を返し続ける。それが根拠に基づいているかどうかは、手に入るどのシグナルにも現れない。例外もなければ、レイテンシの急増もなく、schema 違反もない。

これは RAG エンジニアリングにおける辺縁的なケースではなく、関連するエンジニアリング文献で繰り返し報告されている知見だ。CAIN 2024 の経験報告は 3 つの RAG ケーススタディ（研究、教育、生物医学の領域）を扱い、繰り返し現れる 7 つの故障点を導き出している——コンテンツの欠落、上位にランクされた文書の取りこぼし、検索されたが統合の過程で失われる回答、コンテキストにはあるが抽出されない回答、形式の誤り、具体性のずれ、不完全な回答。そしてその 2 つの中心的な結論は曖昧さがない。「RAG システムの検証は実行時にしか行えない。そして RAG システムのロバスト性は、最初から設計に組み込まれるものではなく、進化するものだ」。

最初の文をもう一度読んでほしい。この種のシステムは、リリース前に完全に検証することはできない。つまり評価の仕組みは、リリース後に足す任意のものではない——それ自体が実行時の検証であり、ただ体系化されたものだ。実際のユーザーが実際に尋ねた質問で構築し、システムとコーパスが変われば走らせ続ける。これが動くかどうかを知る唯一の手段だ。

「RAG はハルシネーションをなくす」はマーケティングであり、データがそれを示している

チームが評価を飛ばすのは、検索がモデルに根拠を与えるのだからハルシネーションの問題は解決済みだという思い込みがあるからだ。最も強力な反例は、このことに本気で金を賭けた領域から来ている。法律検索のベンダーは自社の RAG 製品を売り込む際、ハルシネーションを「なくす」「避ける」と謳い、引用が「ハルシネーションを含まない」とまで保証したhttps://reglab.stanford.edu/publications/hallucination-free-assessing-the-reliability-of-leading-ai-legal-research-tools/?ref=hackernoon.com。斯坦福。RegLab はこれらのツールに対して初の事前登録済み実証評価を行い、その結果、LexisNexis と Thomson Reuters のフラッグシップ製品は「それぞれ 17% から 33% のハルシネーション率」だった。

これらはプロ向けのシステムで、潤沢なリソースを持つチームが丁寧に整備した権威あるコーパス上で構築したもの——RAG の最良のケースだ。検索は素のモデルと比べてハルシネーションを確かに減らすが、それでも 6 分の 1 から 3 分の 1 の回答が作り話を含んでいる。「検索を足した」と「検索が自社のクエリで実際に何を届けているかを測った」の間の隔たり、それがベンダーのマーケティングが落ち込んだ隔たりだ。彼らが落ちるなら、社内チャットボットが落ちないはずがない。

「精度は？」は一つの問いが二枚のコートを着ている

この前提を受け入れて、では自分のパイプラインはどれくらい正確なのかと問うとする。この問いは定義が曖昧で、その曖昧さこそが「デモの手応えで評価する」やり方を生き延びさせてきた——照らし合わせるべき「正解」の基準が、そもそも合意されていないのだ。

RAG の回答は互いに独立した 2 か所で失敗しうる。そしてそれぞれに別の直し方がある。

• 検索の失敗。 モデルに渡された chunk の中に答えがない——インデックスされていない、top-k に入っていない、あるいはコンテキストの組み立て中に切り落とされた。prompt をどう書いても直らない。chunking、embedding、ランキングを変える必要がある。
• 生成の失敗。 答えはまさに検索されたコンテキストの中にあるのに、モデルが無視した、矛盾した、あるいは余計なことを付け加えた。re-ranking を強化しても直らない。prompt の契約を変えるか、モデルを替えるか、出力の検証を足す必要がある。

大まかな「精度」の数字はこれらの問題を一つに揉み込み、闇雲に最適化させる。RAGAS 評価フレームワークはこの分解を、それぞれ別々に測れる量として正式に定式化した。コンテキスト関連性 は検索側を評価する（正しい証拠が現れているか、無関係な材料に埋もれていないか）。忠実性 と 回答関連性 は生成側を評価する（回答の各主張に証拠の裏付けがあるか、問いに応えているか）。Ragas ライブラリは後に検索側をさらにコンテキスト精度とコンテキスト再現率に分解した。各指標の実装には知られた粗さがある——だが本当に重要なのはこの分解のほうだ。「ボットが間違えた」を、特定のコンポーネントを指し示すバグレポートに変えてくれるからだ。

実際の評価フレームワークとはどんなものか

これらに研究チームは要らない。最小限使える評価フレームワークは 3 つのものと 1 つの習慣だ——これも偶然ではなく、私が SophiArch の「LLM で AI アプリを構築する」コースで教えている eval モジュールの形そのものだ。デモが説得力を失ったとき、チームが実際に手を伸ばすのはこの 3 つだからだ。

1. ゴールデンセット：あなたの領域における「正しい」の定義を書き出す。 サポートチケット、トライアルユーザー、そして知識がどこに埋まっているかを知る技術専門家から、実問題を50〜100件集める。各質問について、期待される回答 および それがどのドキュメントに由来すべきかを記録する：

{
 "id": "policy_031",
 "question": "Does the health stipend apply to contractors?",
 "expected_answer": "No - eligibility requires full-time employment status.",
 "must_cite": ["benefits-eligibility-2026.pdf"],
 "trap": "superseded 2024 policy still in corpus says yes"
}

価値があるのは trap のフィールドだ。簡単な質問はスコアを押し上げる。ゴールデンセットが真価を発揮するのは、置き換えられたドキュメント、回答が2つの chunk にまたがる質問、コーパスが 答えられない 質問（正しい動作は「わかりません」——CAIN 分類法の最初の失效点は、拒答ではなく捏造を行うシステムだ）、そして検索されたテキストが表面的な文言の示す意味と逆である否定形の質問だ。

2. 検索と生成を分けたスコアリング。 「引用すべきドキュメントが検索結果に含まれているか？」と「回答は検索された内容に忠実か？」を別々に採点する。生成側は大規模になるとほぼ LLM 審査員に頼ることになる——実行可能だが、欠点がないわけではない：MT-Bench の LLM-as-a-judge に関する研究では、強い審査員は人間の評価者と80%以上一致する一方で、体系的な冗長性バイアス（品質と無関係に長い回答ほど高得点になる）と自己強化バイアスの兆候（審査員が自分のモデルの出力を好む可能性）も記録されている。審査員は使うが、回帰シグナルとして扱う前に人手によるアノテーションで抜き取り検査をしよう。

3. 回帰ゲート。 あらゆる変更——新しい embedding モデル、新しいチャンク戦略、インデックスの再構築、prompt の変更、モデルバージョンのアップグレード——で評価フレームワークを走らせ、スコアが下がったらその変更を止める。テストスイートの失敗がマージを止めるのと同じように。この一手が、評価を一度きりのレポートからエンジニアリングの制御手段に変える。ゲートがなければ、ゴールデンセットは notebook で一度走らせただけの benchmark にすぎない。ゲートがあれば、「さっき悪化した？」という問いに、ユーザーが教えてくれる前に答えが出る。

demo が答えるのは、あなたが選んだ質問だ。ゴールデンセットが答えるのは、ユーザーが実際に尋ねる質問——あなたの pipeline に嘘をつかせるために設計されたものも含めて——だ。まず2つ目を構築し、それから1つ目を信頼しろ。