あなたのRAGはどこで精度を落としているか — 症状から原因を引く診断ガイド

「デモは動いたのに、本番でうまくいかない」。RAGの相談で、私たちが最も多く聞く言葉です。

社内文書をつないで最初の質問に答えが返った瞬間は、誰もが「いける」と思う。ところが実データを当てて現場が普段どおりの質問を投げ始めると、正答率は40〜60%台で頭打ちになり、「自分で探したほうが早い」と言われて、半年後には誰も開かなくなる。

この記事は、その状態を症状から診断するためのガイドです。私たちは商社の週次レポート検索、エネルギーインフラの法令ナレッジ、広告営業の見積など、複数のRAG/AI案件を本番まで持っていきました。そこで繰り返し確かめたのは、本番で精度が落ちる原因は、たいていモデルではなく、その手前の設計のどこかにあるということです。だから「もっと賢いモデルを待つ」より、症状を手がかりに穴の空いている層を特定するほうが、ずっと速く効きます。

先に地図を渡します。RAGの精度は4つの層——データ・検索・評価・運用——のどこでも漏れます。まず、あなたのRAGがいま出している症状から、疑うべき層を引いてください。

症状から、疑うべき層を引く

この表は「当たりをつける」ためのものです。ひとつの症状に原因が複数またがることもありますが、まずは一番上に来る層から手を入れると、たいてい一番大きく動きます。以下、層ごとに「なぜ漏れるか」と「どこで直すか」を順に見ていきます。

4層のどこで精度は漏れるか

第1層 データ設計 — 前処理を雑にやると、上の層で取り返せない。 精度の土台はデータです。地味で誰も評価してくれない作業ですが、ここが雑だと上のどの層で頑張っても取り返せません。文書を機械的に文字数で区切ると、答えの半分だけが入ったチャンクや文脈を失った断片が生まれ、検索でそれを拾ってもLLMは答えようがない。だから文書の種類ごとに切り方を変え、表を崩さず、メタデータを付け、古い版や廃止規程を整理する。精度はモデルより前処理で決まる——これはこのクラスタ全体で私たちが最も強く言いたいことで、詳しくは文書構造に沿ったチャンク設計にまとめました。

第2層 検索設計 — ベクトル検索だけでは固有名詞を取りこぼす。 本番で最も大きく精度を落とし、かつ改善インパクトが一番大きい層です。ベクトル検索は意味の近さに強い一方、固有名詞・型番・条文番号のように一文字違えば別物になる情報を平気で取りこぼす。「A社」と「B社」は意味的に近いので、A社を聞いたのにB社の資料が上位に来る。ここで効くのが、意味の曖昧さはLLM側（ベクトル）に、厳密な一致はルール側（キーワード＝BM25）に役割を分け、リランキングで束ねるハイブリッド検索です。設計の詳細はハイブリッド検索の設計に書きました。

第3層 評価設計 — 「なんとなく良くなった」を捨てる。 どこを直せば効くのかを、感覚で当てにいってはいけません。PoCが止まる現場には、ほぼ例外なく評価セットがない。何問中何問が正解で、どの種類の質問で外しているかを誰も数字で言えない。だからコードより先に、評価セットという物差しを作る。商社案件では49問、法令案件では4軸20点満点の評価を先に用意しました。作り方は評価セットの作り方にまとめています。

第4層 運用設計 — 納品した日が、精度のピークでは困る。 文書は更新され、規程は廃止され、組織が変われば呼び名も変わる。何もしなければAIは更新前の世界を見続け、廃止されたルールを根拠に堂々と誤答する。更新フロー・品質監視・評価セットによる定点観測を納品物に含める。第3層で作った計器盤が、ここで生き続けます。

4層をひとつの現場で積み上げた具体は、商社の文書検索で正答率を38.8%→93.6%にした4層設計に、数字とともに書いています。

「系統」で、次の一手を決める

層で原因の見当がついたら、次はいまのRAGがどの系統（世代）にいるかで打ち手を選びます。RAGの検索は、素朴なものから段階的に育ちます（この整理はNaive→Advanced→Modularというサーベイの体系におおむね対応します——Gao et al. 2023）。

大事なのは、上の系統ほど偉い、ではないことです。素のRAGで足りるなら素のRAGでいい。参照構造の無い文書にGraphを足しても、複雑さが増えるだけです。症状が指す層と、扱う文書の性質に合わせて、必要な系統だけを選ぶ。たとえば法令や規程のように条文が準用でつながる文書ならGraph RAGが効き（法令RAGをGraph拡張で解いた事例）、商談の前・最中・後のように手順が分岐する業務ならAgentic RAGが効く（「使われる」営業AIの設計）。過剰でも過少でもない系統を選ぶ。これが「次の一手」の決め方です。

迷ったら、LLMを増やす前に「ルールで解けないか」を考える

改善の相談でいちばん多い誤解が、「精度が出ないのは、もっと強いLLMを使えば解決する」というものです。すでに書いたとおり主因はモデルの手前にあり、そのうえで私たちが繰り返し確かめてきたのは——決定的に解ける処理は、LLMよりルールベースのほうが良い、ということです。

固有名詞の一致、記号や略称の正規化、値付けの条件——こうした「答えが一意に決まる」処理をLLMに投げると、出力がぶれ、コストがかかり、なぜその結果になったのかを追いにくくなる。同じことをルールで書けば、測定しやすく、ブレず、安く、保守しやすい。実際、広告営業の見積エージェントでは、ベテランの頭の中にあった値付けの勘所をルールとして明文化し、LLMは自由文の依頼を型に落とす所に絞りました。LLMの出番は、意味の曖昧さを吸収する所や、自由文を構造化する所に限る。決定的に解ける所はルールに寄せ、LLMは曖昧さの担当に回す——この非対称が、本番で安定するRAGの地味な核心です（線引きの詳細はハイブリッド検索の設計）。

精度は「保つ」まで設計する — 人間監査から、やがて自動のループへ

最後に、多くのプロジェクトが設計しないまま終わる部分です。精度は上げて終わりではなく、保つところまでが設計です。ここで私たちが描く道筋は、3段階あります。

道筋は3段階です。まず人がAIの回答をチェックする人間監査（human-in-the-loop）を挟み、次に評価セットの数字で「監査が求める品質を安定して満たす」ことを実証し、そのうえで監査を外して評価とフィードバックのループを自動で回す——つまり監査を「卒業」していきます。

いきなり全自動を目指せば、品質を担保できているか誰も言えないまま暴走します。逆に人手監査を続ければ、そのコストが運用の重石になる。評価という物差しを先に持ち、人間監査で品質を実証してから卒業する——この順番だけが「作って終わり」を避けます。段階の踏み方と「卒業」の判断基準は評価セットの作り方に詳しく書きました。

RAG精度 診断チェックリスト（保存版）

いま手元のRAGが本番で精度を落としているなら、上から順に点検してください。

• データ設計 — 文字数で機械的に切っていないか。表・見出し・メタデータを保てているか。（→チャンク設計）
• 検索設計 — ベクトル検索だけになっていないか。固有名詞をキーワード（BM25）で押さえているか。（→ハイブリッド検索）
• 評価設計 — 評価セットはあるか。どの種類の質問で外しているかを「数値で」言えるか。（→評価セットの作り方）
• 運用設計 — 更新時にインデックスを入れ替えるフローと、精度の定点観測があるか。
• 系統の選択 — 症状と文書の性質に合った系統（素／ハイブリッド／Graph／Agentic）を、過剰でも過少でもなく選べているか。
• ルール優先 — 一意に決まる処理をLLMに任せていないか。ルールで固められる所を固めているか。
• 精度の維持 — 人間監査を挟み、卒業の判断を評価の数字で下せる設計になっているか。

症状を聞かせてください

もし、いま手元のRAGが本番で精度を落としていて原因が掴めないなら、症状を聞かせてください。「社名で聞いたのに別の取引先が出る」「準用先が抜ける」「数ヶ月で劣化した」——症状が分かれば、4層のどこに穴が空いていそうか、当たりはつけられます。RAG精度設計のサービスの形はAI/RAG精度設計サービスのページにまとめています。

参考文献

• Lewis et al. (2020) Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS — arXiv:2005.11401
• Gao et al. (2023) Retrieval-Augmented Generation for Large Language Models: A Survey — arXiv:2312.10997
• Cormack, Clarke & Büttcher (2009) Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods, SIGIR — PDF
• 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