RAG が自信たっぷりに間違え始めたとき — 検索の取りこぼしを接地率で計測する運用メモ

Claude を採点者にして接地率を測る

接地率は人手で採点すると続きません。そこで、生成に使うのとは別の呼び出しで Claude を採点者に立て、回答が取得文書に支持されているかを判定させました。採点用のプロンプトは短く、判定を構造化して受け取ります。

// eval/groundedness.ts
import Anthropic from '@anthropic-ai/sdk';
const client = new Anthropic();
 
type Verdict = { grounded: boolean; supported_claims: number; unsupported_claims: number };
 
export async function scoreGroundedness(
  answer: string,
  retrievedDocs: string[],
): Promise<Verdict> {
  const context = retrievedDocs.map((d, i) => `[doc ${i + 1}]\n${d}`).join('\n\n');
  const res = await client.messages.create({
    model: 'claude-sonnet-5',
    max_tokens: 300,
    // 採点は生成とは別プロセス。文書の外の知識で補わせない
    system:
      '与えられた文書だけを根拠に、回答の各主張が文書で支持されているか判定してください。' +
      '文書に無い主張は unsupported と数えます。JSON のみを返してください。',
    messages: [
      {
        role: 'user',
        content:
          `# 取得文書\n${context}\n\n# 回答\n${answer}\n\n` +
          '{"grounded": boolean, "supported_claims": number, "unsupported_claims": number} の形式で返答。',
      },
    ],
  });
  const text = res.content[0].type === 'text' ? res.content[0].text : '{}';
  return JSON.parse(text.slice(text.indexOf('{'), text.lastIndexOf('}') + 1));
}

採点者に「文書の外の知識で補わない」と明示するのが要です。ここを曖昧にすると、Claude が自分の一般知識で回答を擁護してしまい、接地率が甘く出ます。判定を JSON で受け取り、支持された主張と支持されない主張の数まで取ると、後で「どの回答が」「どれだけ」ずれているかを追えます。

検索ヒット率のほうは、評価用に「質問と、その答えを含む正解文書 ID」を 120 件ほど固定したデータセットを用意し、取得結果に正解 ID が含まれるかを機械的に数えました。特別な仕組みは要りません。日次で回すバッチに組み込むだけです。

接地率を毎日の一つの数字にする

計測を一度きりの調査で終わらせると、劣化はまた静かに戻ってきます。私は接地率と検索ヒット率を、毎朝ダッシュボードで眺める二つの数字として固定しました。個人開発で複数サイトの処理を日々モデルに任せている立場では、こうした計器が夜間の自動実行を安心して続ける支えになります。私自身、AdMob 収益のサポート文面までモデルに預けているので、答えの正しさが崩れると影響が実務に直に及びます。

数字を追いながら、主因を上位から潰していきました。

最も効いたのはチャンクの再分割でした。文書追加のたびに、見出し単位の長いチャンクが増えていて、一つのチャンクに複数の話題が同居していたのです。埋め込みが平均化され、どの質問にも中途半端に近い、決め手に欠けるベクトルになっていました。512 トークン前後へ切り直しただけで、検索ヒット率は 14 ポイント上がりました。

しきい値のドリフトも見逃せません。埋め込みモデルを新版へ差し替えたとき、以前のコサイン類似度しきい値をそのまま流用していました。新旧でスコアの分布が違うため、実質的に足切りが厳しくなり、答えの文書を弾いていたのです。

// retrieve.ts — しきい値は分布から較正する（固定値を使い回さない）
export function calibrateThreshold(scores: number[], keepRatio = 0.3): number {
  const sorted = [...scores].sort((a, b) => b - a);
  const idx = Math.floor(sorted.length * keepRatio);
  return sorted[idx] ?? 0; // 上位30%が残る位置を動的なしきい値に
}

固定のしきい値を埋め込みモデル更新後も使い回さない。これは、一度痛い目を見て初めて身につく類の教訓でした。

接地しないなら答えない、を生成側に組み込む

検索を直しても、接地率は検索ヒット率に少し遅れて追いつきます。最後の一押しは生成側でした。取得文書が答えを含まないとき、Claude が一般知識で穴埋めするのを止める。プロンプトで、根拠がなければ「わからない」と言い切らせます。

// generate.ts の system プロンプト（抜粋）
const system = `あなたは取得文書のみを根拠に回答します。
- 文書に根拠がある主張だけを述べてください。
- 文書に答えが無い場合は、推測せず「提供された資料には該当の記載がありません」と述べてください。
- 各主張の末尾に、根拠とした [doc n] を必ず付けてください。`;

根拠に [doc n] を必ず付けさせると、接地率の採点も安定し、利用者にとっても回答の検証がしやすくなります。「わからない」と正直に言える RAG は、流暢に嘘をつく RAG より、はるかに信頼できます。私自身、穴埋めの流暢さより、境界を正しく引く誠実さを取るようになりました。

立て直しの順序を一枚にまとめる

同じ状況に出会ったとき、私が次に辿る手順はこうです。

1. 回答の見た目を信じない。流暢さと正しさは別物として扱う
2. 「検索ヒット率」と「接地率」に分けて疑う。原因が検索側か生成側かを先に切り分ける
3. Claude を採点者に立て、接地率を毎日の一つの数字にする
4. チャンク肥大・しきい値ドリフト・埋め込み更新の三つを上位から潰す
5. しきい値は分布から較正する。固定値を更新後に使い回さない
6. 生成側に「接地しないなら答えない」を組み込み、根拠 [doc n] を必須にする

RAG は、作って終わりではなく、答えを掴み続けているかを計測して初めて信頼できます。派手さはありませんが、この地道な計器が、生成の流暢さに隠れた劣化を静かに照らしてくれます。実装の参考になれば幸いです。お読みいただきありがとうございました。