RAGは「測れないと上がらない」— 評価セットの作り方と、人間監査を「卒業」する設計

「精度が出ないんです」。RAGの相談は、たいていこの一言から始まります。けれど「では、何問中何問が正解で、どの種類の質問で外していますか」と聞くと、答えが返ってこないことがほとんどです。

正直に書くと、私も昔は評価を後回しにしていました。とりあえず動かして、出力を眺めて、「なんとなく良くなった気がする」で直す。それで一度は良くなっても、別の質問が悪化し、どこをいじったから何が変わったのか分からなくなる。この当て推量のループから抜けられたのは、コードを書く前に評価セットを作るようになってからです。

この記事は、RAGの評価セットをどう作るか、そして——ここがいちばん伝えたいのですが——評価があると人間監査をどう「卒業」して、精度の維持を自動のループに移せるか、を実装者の視点で書きます。RAGが本番で精度を落とす原因の全体像は症状から原因を引く診断ガイドにまとめていて、この記事はその第3層「評価設計」を深掘りするものです。

なぜ、コードより先に評価セットなのか

評価セットが無いまま改善を始めると、必ず当て推量になります。直した気になっては別のところが悪化し、「なんとなく」から抜け出せない。物差しが無いのだから当然です。

逆に、物差しが1つあるだけで景色が変わります。「いま外しているのは固有名詞の質問だ。原因は検索層だ」と特定できれば、全体をやみくもにいじるのではなく、一番痛いところに狙って手を入れられる。評価セットは、改善のどこに効いたかを教える目盛りです。商社の文書検索案件で私たちが最初にやったのも、コードを書くことではなく、49問の評価セットを作ることでした。

評価セットの作り方

質問を洗い出す。 まず、現場で実際にどんな質問が飛ぶのかを集めます。ここを想像で作ると評価が現実とズレるので、問い合わせ履歴や現場ヒアリングから、固有名詞を含む質問・言い換えの質問・複数条件の質問といった種類がまんべんなく入るように選びます。同じ問いを、丁寧な文・話し言葉・略語まじり・キーワードの羅列のように言い回しを変えた版でも持っておくと、特定の聞き方にだけ強い状態を見抜けます。「誰が・どんな聞き方で」の分布を先に決めて評価用の問いを作る方法は、RAG評価の研究でも使われています（DataMorgana, 2025）。あわせて、文書に答えが無い質問も入れておきます。答えられない問いに「見つからない」と返せるかは、答えられる問いの正答率とは別に測る必要があるからです。

「正解」の基準を決める。 各問に、何をもって正解とするかを用意します。「この文書のこの箇所が根拠として出ていれば正解」「この数値が含まれていれば正解」というレベルまで落とすと、後の採点が安定します。長い回答が要る問いは、回答に含むべき事実を箇条書きにし、そのうちいくつ含んだかで網羅性を測ります（TREC 2024 RAGトラックの「ナゲット」評価と同じ考え方です——Pradeep et al., SIGIR 2025）。もう一つ、正解として付けた根拠が、本当にその答えを支えているかを人が1回確かめます。既存の評価データでも、正解として付いた根拠の多くが答えるには不十分だったと報告されています（Joren et al., ICLR 2025）。

検索と生成を分けて測る。 RAGの評価は、検索（正しい文書を拾えたか）と生成（拾った文書から正確に答えられたか）を分けて測るのが標準的な考え方です（RAGAS, Es et al. 2023）。分けておくと、外した原因が検索側か生成側かを切り分けられます。

表の一番上に読み取りを置いているのは、PDFやスキャンの読み取りで崩れた文字や表が、そのまま検索と回答の誤りに連鎖するからです（Zhang et al., ICCV 2025）。表の数値を問う質問が外れたとき、原因が検索ではなく読み取りにあることは珍しくありません。検索を経路別に出すのは、キーワード検索とベクトル検索で届く問いが違うためで、統合やリランキングが効いているかも経路別に見て初めて分かります。

採点は「ルールで測れる所はルールで」

評価というとすぐLLMに採点させたくなりますが、その前に一度立ち止まります。決定的に測れる所は、ルールで測るほうが良いからです。

正解文書がヒット集合に入ったか、必須キーワードを含むか、数値が一致するか——こうした「答えが一意に決まる」判定は、含有チェックや完全一致・正規表現といったルールで自動採点できます。ルール採点は、ブレず・安く・速く・何度回しても同じ結果になる。回帰テストのように毎回まわせるのが強みです。

LLMを審査員に使う（LLM-as-a-Judge）のは、ルールでは測れない曖昧な質——自然さ・網羅性・根拠との整合性——に絞ります。法令案件では「正確性・網羅性・整合性・生成品質」の4軸を各5点、20点満点で採点し、16点以上を合格としました。強力なモデルの判定は人間と8割以上一致すると報告されている一方（Zheng et al. 2023）、位置バイアスや冗長性バイアスといった癖も知られているので、最終的な品質判断はドメイン有識者の人手レビューと併用します。決定的な採点はルールに任せ、LLMは曖昧な質だけを見る——この役割分担は、検索だけでなく評価でもそのまま効きます。

LLMの採点役は、較正してから使う部品です。査読前の報告ですが、2つの回答の優劣を同じ条件で判定し直させると、平均13.6%で判定が入れ替わったとされています。あるモデルは先に示した回答を72%の割合で選び、意味の同じ指示文に書き換えるだけで25%の設問の多数決が変わりました（Yagubyan, 2026）。実務では次の3つを守ります。新しく採点基準を作るなら、1〜5点の点数より「根拠に支えられているか：はい／いいえ」と根拠の引用で判定させる。回答の並び順や指示文の言い回しを入れ替えて採点し直し、判定が変わる割合（反転率）を報告に載せる。人が判定した50〜100件と突き合わせて、採点役がどこでずれるかを確かめてから任せる。法令案件のように軸ごとの点数で採点している場合も、後ろの2つはそのまま効きます。

評価は、原因を指し示す「計器盤」になる

軸を分けて測ると、改善の効き目が軸ごとに見えます。法令案件では「網羅性」を独立の軸に置いたことで、まさに準用先の取りこぼしを数字で捕まえられました。参照をたどる検索を入れたら網羅性が上がったのか、用語のクエリ拡張で正確性が上がったのか——感覚ではなく数字で次の一手を決められる。

商社案件では、この物差しがあったからこそ「外しているのは固有名詞の質問＝検索層が原因」と特定でき、正答率を38.8%から93.6%へ、回答率を42.9%から100%へ引き上げられました（特定した検索層をどう直したかはハイブリッド検索の設計に書きました）。数字を出せたのは、最初に評価セットを作っていたからです。

計器盤を読むときの規律は2つです。ひとつは上流から見ること。読み取り→検索→生成の順に、最初に外れた層を原因として数えます。検索が正解の文書を拾えていない問いを、生成の工夫で直そうとしても動きません。もうひとつは、一度に変えるのは1か所だけにして、質問の種類ごとの前後差を全部見ること。複数を同時に変えると、ある種類が上がって別の種類が下がったとき、どの変更が効いたのか分からなくなります。

答えた・断ったを分けて数える

正答率1本で見ていると、見落とす失敗があります。分からない問いに当て推量で答えるほど、正答率の分子は増えることがあるからです。Kalaiらは、正解だけに点を与える採点が当て推量を得点にしてしまい、ハルシネーションを温存すると指摘しています（Kalai et al., 2025）。そこで、次の3つを並べて報告します。

正答率が同じでも、誤答率の低い設定のほうが業務では安全です。断った問いは人が調べ直せば済みますが、外した答えはそのまま業務に使われかねないからです。合否を1つの点にまとめたいときは「正答＋1・断り0・誤答−1」のように、外したときに点を引く採点にしておくと、断るべきところで答えてしまう設定を選ばずに済みます。評価セットに入れた「文書に答えが無い質問」は、ここで効きます。

人間監査を「卒業」する — 評価があるから自動化できる

評価セットの本当の価値は、精度を上げることだけではありません。精度を保つ運用を、人手依存から自動へ移していく土台になることです。私たちが描く道筋は3段階あります。

はじめは人がAIの回答をチェックする人間監査（human-in-the-loop）を挟みます。ここで大事なのは、監査を「作業」で終わらせないことです。監査で1問の外れを見つけたら、その質問を評価セットに1問足し、正解の基準まで書いて資産にする。評価セットが厚くなるほど、次からは同じ誤りをルールや自動採点で捕まえられるようになります。そうして評価の数字が「監査が求める品質」を安定して満たすようになったら——たとえば合格ラインを一定期間下回らなくなったら——監査の頻度を落とし、やがて外していい根拠が数字で立ちます。人を判断の中心に残したまま自動化へ寄せる考え方は「使われる」営業AIの作り方にも通じます。自動採点にLLMを使うなら、監査で人が下した判定がそのまま較正用のデータになります。人の判定と採点役の判定が一致し続けることを確かめてから、人手を外します。逆にこの物差しが無いと、「卒業」の判断そのものが下せず、いつまでも人手監査が運用の重石になります。

よくある落とし穴

「とりあえず動いたから評価は後で」 ── 評価を後回しにすると、改善のたびに何が良くなったのか分からなくなります。コードより先に物差しを。

「総合スコアを1つ見れば十分」 ── 1つの数字だけでは、どの層が原因かが見えません。検索と生成、正確性と網羅性を分けて初めて原因を指せます。

「LLM審査の点数を鵜呑みにする」 ── バイアスがあります。並び順や言い回しを入れ替えて判定が変わる割合を測り、特に合否の境目は人手レビューと併用してください。

「正答率だけを追う」 ── 当て推量で答える設定ほど良く見えることがあります。回答率・正答率・誤答率を並べて見ます。

「評価セットを一度作って放置する」 ── 文書が更新されれば正解も変わります。評価セットも運用対象です。

よくある質問

評価セットは何問あれば始められますか。

数十問で始められます。私たちの案件では、商社の文書検索が49問、法令ナレッジの初期評価が23問でした。エージェント型の調べものでも、Anthropicは約20問の小さな評価セットから始めたと書いています（Anthropic, 2025）。問数より先に、質問の種類（固有名詞・言い換え・複数条件・答えの無い問い）が偏りなく入っているかを見てください。監査や運用で見つけた外れを1問ずつ足していけば、評価セットは自然に厚くなります。

RAGASのような評価ツールは使うべきですか。

指標を計算する部品としては便利です。RAGASは2025年12月のv0.4で実験（experiment）を単位に回す形へ作り替えられ、従来の evaluate() 関数は非推奨になりました（Ragas）。ツールの作りは変わっていく前提で、正解との突き合わせと「どの層で外れたか」の判定は自分たちのコードに持っておくと、ツールを替えても物差しが変わりません。

埋め込みモデルやLLMは、公開ベンチマークの順位で選んでよいですか。

候補を2〜3本に絞るまでに使い、決めるのは自社の評価セットです。公開ベンチマークのデータは学習に混ざることがあり、非公開のデータで測るとスコアを落とすモデルがあると報告されています（Hugging Face, 2025）。日本語の埋め込みでも、ある公開ベンチマークで上位のモデルが別のベンチマークでは中位になる、といった入れ替わりが起きています。違う表の数字を並べて比べず、自社の質問で正解の文書を拾えた割合を比べます。

評価設計のチェックポイント

• 現場の実際の質問から評価セットを作ったか（想像で作っていないか）。
• 言い回しを変えた問いと、文書に答えが無い問いを入れたか。
• 各問に「正解」の判断基準があり、その根拠が答えを支えているか確かめたか。
• 読み取り・検索・生成を分けて測っているか。検索は経路別に出しているか。
• 決定的に測れる所はルールで自動採点しているか。
• 曖昧な質はLLM審査＋人手で測り、採点役の反転率を確かめているか。
• 回答率・正答率・誤答率を並べて見ているか。
• 評価の数字で「人間監査を卒業できるか」を判断できる設計か。

評価から始めませんか

RAGの精度が上がらないと感じているなら、まず評価セットから始めるのがいちばんの近道です。いまの構成と、どの種類の質問で外しているのかを聞かせていただければ、評価をどう組み、どこから直すかの当たりをつけられます。RAG精度の全体像は診断ガイドに、評価を含む4層を実際に積み上げた顛末は商社の文書検索事例に置いています。

参考文献

• Es et al. (2023) RAGAS: Automated Evaluation of Retrieval Augmented Generation — arXiv:2309.15217
• Zheng et al. (2023) Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena — arXiv:2306.05685
• Gao et al. (2023) Retrieval-Augmented Generation for Large Language Models: A Survey — arXiv:2312.10997
• Filice et al. (2025) Generating Diverse Q&A Benchmarks for RAG Evaluation with DataMorgana — arXiv:2501.12789
• Pradeep et al. (2025) The Great Nugget Recall: Automating Fact Extraction and RAG Evaluation with Large Language Models, SIGIR 2025 — arXiv:2504.15068
• Joren et al. (2024) Sufficient Context: A New Lens on Retrieval Augmented Generation Systems, ICLR 2025 — arXiv:2411.06037
• Zhang et al. (2024) OCR Hinders RAG: Evaluating the Cascading Impact of OCR on Retrieval-Augmented Generation, ICCV 2025 — arXiv:2412.02592
• Yagubyan (2026) The Coin Flip Judge? Reliability and Bias in LLM-as-a-Judge Evaluation（査読前） — arXiv:2606.13685
• Kalai et al. (2025) Why Language Models Hallucinate — arXiv:2509.04664
• Anthropic (2025) How we built our multi-agent research system — anthropic.com
• Hugging Face (2025) Introducing RTEB — github.com/huggingface/blog