精度70%のRAGを前に何を判断すべきか
AIのPoC（概念実証）が失敗するとき、その原因はモデルの精度不足そのものであることは意外に少ない。より多いのは、精度という数字が出たあとに、それをどう解釈し、どう事業判断につなげるか不明確であることだ。この記事では、検索拡張生成（RAG）を主な題材に、AIシステムの評価を「指標の定義」「計測」「解釈」の三つの課題に分解し、それぞれに対する実務的な対処を論じる。あわせて、動くソフトウェアを早期に提供するインクリメンタルな開発が、開発手法としてだけでなく評価の装置として機能することを示す。
なお、この記事の議論は特定のツールや製品に依存しない。RAGアプリケーションの雛形を短期間で動かす手段は、主要クラウドのマネージドサービス、OSSフレームワーク、社内基盤のいずれでも実現可能であり、以下の議論はそのすべてに適用できる。
評価を阻む三つの課題
1. 指標の定義：単一軸に還元できない業務
評価基準は、関係者全員が理解できる単純な指標であることが理想である。しかし、これまで人間が行っていた業務をAIに置き換える場合、その業務の品質は往々にして複合的な軸で成り立っている。文書検索を伴う問い合わせ対応であれば、回答の正確さ、根拠の提示、網羅性、トーンの適切さは独立に良し悪しがありうる。業務の本質を捉えようとするほど指標は複雑になり、複雑になるほど関係者の共通理解から遠ざかる。ここには本質的なトレードオフがある。
2. 計測：正解データが存在しない
指標を定義できても、計測にはリファレンス、いわゆるGolden Data（評価用の正解付きデータセット）が必要になる。RAGであれば「この質問にはこの文書のこの箇所を根拠にこう答えるべきである」というアノテーションである。実務ではこのデータが整っていないことがむしろ通常であり、整備には専門人材の時間という高いコストがかかる。計測できないものは改善できない、という原則がプロジェクトの初日から崩れている。
3. 解釈：数字が出ても判断できない
三つの中で最も見過ごされ、かつ最も深刻なのがこの課題である。precisionやrecallといった指標の定義は難しくない。難しいのは、計測の結果として精度95%、あるいは70%という数字が出たときに、それが事業での利用に値するのかを判断することである。100%は通常達成されない。では何%なら良いのか。この問いに机上で答えられる関係者は、ほとんどの場合存在しない。指標の算出と指標の解釈は別の作業であり、後者のための構造を持たないPoCは、良い数字が出ても悪い数字が出ても前に進めない。
前提の整理：何を評価しているのかを分離する
三つの課題に取り組む前に、RAGの評価で最も頻繁に起きる混同を除去しておく必要がある。それは検索（retrieval）の評価と、システム全体（end-to-end）の評価の混同である。
precision@kやrecallは、検索コンポーネントが適切な文書を取得できたかを測る指標である。一方、「チャットボットの回答が許容できるか」は、検索結果を受けた生成を含むシステム全体の出力品質の問題であり、忠実性（faithfulness：回答が取得文書に根拠づけられているか）や回答の適切性といった別系統の指標で測るべき対象である。検索精度が高くても生成が根拠を無視すれば回答は悪くなり、検索が不完全でも生成が適切に「わからない」と答えれば被害は限定される。
この分離は単なる用語の整理ではない。どちらの層で失敗しているかによって打ち手が全く異なる（検索の失敗ならチャンキングや埋め込みモデルの変更、生成の失敗ならプロンプトやモデルの変更）ため、混同したまま「精度」を一つの数字で語ると、改善のループそのものが回らなくなる。以降、この記事で「評価」というときは、この二層を意識的に区別した上での議論とする。
Golden Data不在時の評価アーキテクチャ
計測の課題（課題2）に対して「データが揃うまで待つ」以外の選択肢を持つことが、PoCの速度を決める。実務上有効なのは、正解データへの依存度が異なる複数の評価手段を段階的に組み合わせることである。
第一段階は少数精鋭のテストセットである。 網羅的なGolden Dataの整備を待つのではなく、ドメイン専門家に「これに答えられなければ話にならない」という質問を20〜50件挙げてもらい、正解の要点だけを付す。統計的な代表性はないが、致命的な欠陥の検出には十分であり、整備コストは数時間で済む。
第二段階は、生成に対するルーブリック（評価基準表）評価である。 検索は precision@k や recall で機械的に評価できるため、人手やLLMによる判断を要するルーブリックは、検索と独立な生成の品質に絞って用いるのが合理的である。全体を一つの尺度に押し込むのではなく、生成の品質を複数の軸——たとえば忠実性（取得文書に根拠づけられているか）、内容の正確さ、網羅性、トーンの適切さ——に分け、各軸にそれぞれ順序づけられた段階を定義する。これは課題1（複合的な評価軸）および前節の検索・生成の分離への応答でもある。複雑な単一指標に業務の本質を押し込むのではなく、単純な軸を複数持ち、各軸を段階で捉える方が、関係者の理解と改善の指針の両方に資する。
第三段階として、LLMを評価者として用いる（LLM-as-a-judge）際は、校正を前提条件とする。 LLMによる自動評価はスケールするが、その判定が人間の専門家の判定とどの程度一致するかを、少数サンプルで必ず検証してから使う。校正なしの自動評価は、計測の課題を解決したように見えて、実際には解釈不能な数字を量産するだけである。
この三段構えの要点は、評価の精密さとコストのトレードオフを、プロジェクトの段階に応じて意識的に選ぶことにある。PoC初期に必要なのは統計的に厳密な計測ではなく、改善の方向を決められる程度の解像度である。
動くソフトウェアは評価の装置である
ここまでの議論は指標の設計に関するものだが、課題3（解釈）は指標の設計だけでは解決しない。70%という数字の意味は、その70%に含まれる成功と失敗の中身を見なければ判断できないからである。
インクリメンタルな開発——最小限の機能を持つ動くアプリケーションを早期に提供し、そこに検証を積み重ねる手法——が評価において果たす役割は、ここにある。報告書の数字だけを受け取る場合と異なり、関係者が実際に入力と出力を操作できる環境があると、次の機構が働く。
第一に、定性的な体験が定量指標の解釈を校正する。 「recall 70%」という抽象的な数字は、実際の失敗例を10件見た関係者にとっては具体的な意味を持つ。失敗の中に「全く許容できない誤り」「一部は許容できる不完全さ」「運用プロセスを整えれば吸収できる欠落」という色合いの違いがあることは、出力に触れて初めて判別できる。指標が複雑であるほど、この体験による校正の価値は大きい。すなわち、体験環境の存在は、課題1で述べたトレードオフ（正確だが複雑な指標は理解されない）を緩和し、指標選択の自由度を上げる。
第二に、ドメイン固有の失敗モードが早期に露出する。 AI開発者が想定するエラーの分類と、ドメイン専門家が業務上重大とみなすエラーの分類は、多くの場合一致しない。専門家が実際に触れる環境は、開発者には特定不可能な課題を、評価データの整備を待たずに洗い出す。これは課題2に対する時間的なヘッジとして働く——Golden Dataを収集している期間を、課題の発見に充てられる。
第三に、Go/No-Go判断の材料が数字から構造に変わる。 事業判断に必要なのは「精度が何%か」ではなく、「どの種類の誤りが、どの頻度で起き、それぞれの業務上のコストはいくらで、どこまでが運用で吸収可能か」である。誤りの非対称性——例えば「回答しない」誤りと「誤った内容を自信を持って回答する」誤りのコスト差——は、体験を通じてのみ関係者間で合意可能になる。この構造が揃ったとき、70%という数字は初めて判断可能な情報になる。
まとめ
AIのPoCにおける評価の困難を、指標の定義・計測・解釈の三つに分解した。定義の課題には単純な軸の複数併用で、計測の課題には正解データへの依存度を段階化した評価アーキテクチャで、そして最も深刻な解釈の課題には、動くソフトウェアによる関係者の校正で応じることができる。
インクリメンタルな開発を「早く作るための手法」としてではなく、「判断可能な評価を成立させるための装置」として位置づける。検索と生成を分離して測り、段階化された評価手段で数字を出し、実際の出力への接触によってその数字の意味を関係者間で校正する。この構造を最初のPoCの設計に含めることが、その後の本番開発の成否を大きく左右する。
参考文献
[1] D. Sculley et al. Hidden Technical Debt in Machine Learning Systems. NIPS, pp. 2503–2511, 2015.
[2] C. Larman and V. R. Basili. Iterative and Incremental Developments: A Brief History. Computer, vol. 36, no. 6, pp. 47–56, 2003.
[3] Beck, K. et al. Principles behind the Agile Manifesto. https://agilemanifesto.org/principles.html, 2001.