RAG 12：評価 ― 「よさそう」を数字にする

検索の評価と生成の評価を分ける

答えが間違っていたとします。原因は大きく2つに分かれます。

「答えが正しいか」だけを見ていると、この2つを区別できません。そこで、評価も検索の評価と生成の評価に分けます。

たとえるなら、料理がまずかったとき、「材料が悪かった」のか「料理人の腕が悪かった」のかを分けて考えるようなものです。材料が悪いのに料理人を替えても、おいしくはなりません。

図の上の2本の線が、それぞれの評価が見る範囲です。検索の評価は「正しい資料を集めたか」、生成の評価は「集めた資料どおりに答えたか」を見ます。

テストセット：質問・正解・正解の資料の組

測るためには、まずテストセット（評価用の問題集）を用意します。1問ごとに、次の3つを組にします。

正解の資料があれば、検索が集めた資料の中にそれが入っているかで、検索を採点できます。正解の答えがあれば、RAG の答えと比べて、生成を採点できます。

最初から何百問も要りません。数十問でも、あるとないとでは大違いです。大事なのは、毎回同じ問題で測ることです。問題を毎回変えると、数字が上がったのが改善のおかげなのか、問題が易しくなったからなのか、区別できません。

表は、スプレッドシートや JSON（プログラムが読みやすい決まった書式）の1ファイルで十分です。コードで書くなら、1問の形は次のとおりです。question が質問、goldAnswer が正解の答え、goldChunkIds が正解の資料の番号の一覧です（gold は「正解」の意味でよく使われる言葉です）。

type TestCase = {
  question: string;
  goldAnswer: string;
  goldChunkIds: string[]; // 答えが載っているチャンク
};

質問をどこから集めるか

テストセットの質問は、どこから持ってくればよいでしょうか。大きく3つあります。

LLM による合成は便利です。チャンクを1つ見せて「この資料で答えられる質問と、その答えを作って」と頼めば、正解の資料付きの問題がいくらでも作れます。

ただし、落とし穴があります。資料を見ながら作った質問は、資料と同じ言葉を使いがちです。「年次有給休暇の付与日数は？」のように。本物の利用者は「有休って何日あるんだっけ」と聞きます。同じ言葉を使った質問は検索が当てやすいので、点数が実力より高く出ます。また、複数の資料をまたぐ質問や、資料に答えが無い質問も、放っておくと作られません。

おすすめは、本物のログを中心にし、足りない種類を合成で補い、合成した問題も人が目を通すことです。「資料に答えが無い質問」も意図的に混ぜておくと、「見つからないと正直に言えるか」（第13章）も測れます。

recall@k：正解が上位 k 件に入ったか

検索の評価の基本は recall@k（リコール・アット・ケー）です。recall は「再現率」と訳され、ここでは「必要なものをどれだけ取りこぼさずに拾えたか」の意味です。

検索は、資料を「関係ありそうな順」に並べて返します。LLM に渡すのは、そのうち上位 k 件だけです（k は 3〜10 くらいがよく使われます）。recall@k は、「正解の資料のうち、上位 k 件に入った割合」です。

図の例では、正解の資料は2つ（2位と5位）です。k＝3 なら、上位3件に入った正解は2位の1つだけ。recall@3 は 1/2 です。

なぜこれが大事なのでしょうか。上位 k 件に入らなかった資料は、LLM から見えません。どれだけ賢い LLM でも、見ていない資料に基づいて答えることはできません。recall@k が低いなら、生成をいくら直しても無駄です。

テストセットの全問で recall@k を計算し、平均を取れば、検索の実力が1つの数字になります。たとえば3問で 1、1/2、0 なら、平均は 1/2 です。

下のコードは、1行目で検索結果の上位 k 件を取り出し、2行目で「正解の資料のうち、その中に入っているものの数 ÷ 正解の資料の数」を返しています。

function recallAtK(results: string[], gold: string[], k: number) {
  const top = new Set(results.slice(0, k));
  return gold.filter((id) => top.has(id)).length / gold.length;
}

k を増やせば拾える。でも余計な資料も増える

では k を大きくすればよいのでしょうか。図で k＝5 にすると、5位の正解も入り、recall@5 は 2/2 になりました。

ところが、渡した5件のうち、関係あるのは2件だけです。この「渡した資料のうち、関係あるものの割合」を precision@k（プレシジョン。「適合率」と訳される）と呼びます。ここでは 2/5 です。

この2つは綱引きの関係です。k を増やすと recall は上がりやすいけれど、precision は下がりやすい。余計な資料が増えると、LLM の読む量（お金と時間）が増え、関係ない資料に引っ張られて答えがぶれることもあります（第8章）。

実務では「recall を十分に高くした上で、リランキング（第7章）で上位を良いものにする」という組み合わせがよく取られます。まず広く拾い、次に絞るのです。

順位も見る：MRR と nDCG

recall@k は「入ったかどうか」しか見ません。でも、正解が 1位にあるのか、5位にあるのかでも違いがあります。上のほうにあるほうが、LLM は見つけやすく、k を小さくしても入ります。

そこで、順位も点数に入れる物差しがあります。

言葉で計算してみます。MRR（Mean Reciprocal Rank。逆順位＝「1÷順位」の平均）は、3問で最初の正解がそれぞれ1位・2位・4位なら、1、1/2、1/4 の平均で約 0.58 です。nDCG（正規化した割引累積利得）は、図の例なら、2位の正解を約0.63点、5位の正解を約0.39点と、下にあるほど割り引いて足し（約1.02）、正解2つが1位・2位に並んだ理想の場合の点（約1.63）で割って、約0.62 になります。

MRR は「1つ正解が見つかれば十分」な質問に向いています。nDCG は、「とても関係ある／少し関係ある」のように段階で採点したい場合や、複数の正解がある場合に向いています。

数式を覚える必要はありません。「上位に正解があるほど点が高い」とだけ押さえておけば十分です。計算は評価用のライブラリが行ってくれます。

生成の評価①：答えは資料に基づいているか

次は生成の評価です。いちばん大事なのは、答えが、渡した資料に基づいているかです。これを faithfulness（忠実さ）や groundedness（根拠のあること）と呼びます。

測り方の考え方はこうです。

「繰り越しは無制限」は、資料のどこにも書かれていません。LLM が一般常識から付け足したか、作ってしまったのでしょう。これがハルシネーション（第0章で見た、もっともらしい作り話）の芽です。

注意したいのは、faithfulness は「資料どおりか」を見る物差しで、「事実として正しいか」ではないことです。資料が古ければ、資料どおりの答えも間違いになります。正しさを見るには、正解の答えと比べる評価（answer correctness などと呼ばれます）を別に行います。

主張への分解や照合は、人がやると大変なので、たいてい LLM にやらせます。その話は少し後で見ます。

4つの物差し（RAGAS などの評価ツール）

RAG の評価用には、オープンソースの道具がいくつもあります。よく知られたものの1つが RAGAS で、2023年に論文とともに公開されました。RAGAS で有名になった物差しを4つ紹介します（版によって名前や計算方法が変わることがあります）。

answer relevancy は、faithfulness とは別物です。「休暇規程は全部で12条あります」という答えは、資料どおりで faithfulness は満点かもしれません。でも「有給は何日？」への答えにはなっていません。

4つを並べると、「どこが崩れたか」を場所で言えるようになります。たとえば faithfulness は高いのに context recall が低いなら、「LLM は資料に忠実だが、そもそも資料が足りていない」。直すべきは検索です。

同じような物差しは、他の評価ツールや、各社のクラウドの評価機能にも用意されています。名前が少しずつ違うので、何を測っているかの定義を必ず読んでから使いましょう。

LLM に採点させる（LLM-as-a-judge）

faithfulness や answer relevancy を、何百問ぶん人が採点するのは大変です。そこで、別の LLM に採点させる方法が広く使われています。これを LLM-as-a-judge（審査員としての LLM）と呼びます。

やり方は単純です。審査員役の LLM に、質問・資料・答えを見せ、採点の基準と出力の形を指示します。

あなたは採点者です。次の基準で、答えを1〜5で採点してください。
・資料に書かれていない内容を含むなら減点する
・質問に答えていなければ減点する
出力は JSON で {"score": 数字, "reason": "理由を1文で"} とする。

質問：…
資料：…
答え：…

上の指示は、採点の基準を2つ示し、点数（score）と理由（reason）を JSON という決まった書式で返させています。書式を決めておくと、プログラムで点数を集計できます。

理由も一緒に書かせるのがコツです。点数だけだと、なぜ低いのか分かりません。理由があれば、人が読んで「審査員の判断がおかしい」ことにも気づけます。

LLM-as-a-judge がよく使われるようになったのは、2023年の研究で、強い LLM の判定が人の好みとかなりよく一致することが示されたのがきっかけの1つです。ただし、同じ研究でくせも指摘されました。次のページで見ます。

審査員の LLM にもくせがある

LLM-as-a-judge には、よく知られたくせ（バイアス）があります。2023年の研究（MT-Bench という LLM 向けの問題集と、人が2つの答えを見比べて投票する Chatbot Arena というサイトを扱った論文）で整理されたものを中心に紹介します。

さらに、審査員はあいまいな基準ほどぶれます。「良い答えか」ではなく、「資料に無い主張を含むか（はい／いいえ）」のように、具体的で、答えが決まりやすい問いに分けて聞くほど安定します。

そして最後は人です。テストセットの一部（数十問）を人が採点し、審査員の点とどれだけ一致するかを確かめます。一致が低いうちは、審査員の点で判断してはいけません。基準の書き方を直すか、別のモデルを試します。審査員そのものも、評価の対象なのです。

何かを変えたら、同じテストで測り直す

評価の本当の出番は、何かを変えるときです。チャンクの大きさを変える、埋め込みモデルを替える、プロンプトを書き直す、LLM を新しい版にする。そのたびに、同じテストセットで測り直して、前後の数字を並べます。

図の例（数字は説明用）では、チャンクを大きくしたら、recall@5 は上がりました。答えの載った部分がチャンクに含まれやすくなったからです。ところが faithfulness は下がり、時間も延びました。長い資料の中で、LLM が関係ない部分に引っ張られたのかもしれません。

1つの数字だけを見ていたら、「検索が良くなったから採用」と決めていたでしょう。複数の物差しを並べて見ることで、改善と引き換えに何かを失っていないか分かります。

これをソフトウェアの回帰テスト（直したせいで、前は動いていたものが壊れていないかを確かめるテスト）のように、CI（プログラムを変えるたびに自動でテストを走らせる仕組み）に組み込んでおくと安心です。

下のコードは、テストセットを読み込み、1問ずつ検索して recall@5 を足し合わせ、問題数で割って平均を出します。平均が 0.8 を下回ったらエラーにして、変更を止めます（0.8 は例です）。

const cases: TestCase[] = loadTestSet("eval/questions.json");
let hit = 0;
for (const c of cases) {
  const results = await search(c.question, { k: 5 });
  hit += recallAtK(results.map((r) => r.chunkId), c.goldChunkIds, 5);
}
const recall = hit / cases.length;
if (recall < 0.8) throw new Error(`recall@5 が下がった: ${recall}`);

LLM の答えは毎回少し変わることがあるので、生成の評価は何回か回して平均を見るか、変化の小さい設定で測ります。

本番の信号も集める

テストセットは、どうしても「過去に想定した質問」です。本番では、想定しなかった聞き方が必ず来ます。そこで、本番の利用者の反応も信号として集めます。

注意したいのは、押されなかった＝良かった、ではないことです。黙って去った人のほうが多いかもしれません。信号は「ここを見に行くべき」という手がかりで、正解ではありません。

いちばん大事な使い方は、悪い信号が付いた質問を、正解を付けてテストセットに足すことです。こうして、テストセットは本番に合わせて育っていきます。評価は一度作って終わりではなく、回し続ける仕組みです。

本番の質問を保存するときは、個人情報や見せてはいけない内容が混ざります。保存の仕方は第13章で見ます。

よくある落とし穴

評価まわりで、よく見かける失敗を並べます。

他の章とのつながりも確かめておきます。検索の物差し（recall・MRR）が低いなら、第3章（チャンク分割）から第7章（リランキング）、第9章（質問を直す）を見直します。生成の物差し（faithfulness）が低いなら、第8章（プロンプトと生成）です。第14章では、評価そのものがなぜ難しいのかも改めて考えます。