商社の文書検索で正答率を38.8%→93.6%にした4層設計

RAGのデモは、驚くほど簡単に動きます。社内文書を放り込んで、ノーコードのツールでつないで、最初の質問に答えが返ってきた瞬間、誰もが「これはいける」と思う。私も何度もその場に立ち会いました。

問題はその次です。実際の業務データを当てて、現場の人が普段どおりの質問を投げ始めると、正答率は40〜60%台で頭打ちになる。社名を入れたのに別の取引先の資料が出てくる。型番で聞いているのに似た製品が返ってくる。「結局、自分で探したほうが早い」という評価に落ち着き、半年後には誰も開かなくなる。

この記事では、私たちが大手総合商社の週次レポート検索で正答率を38.8%から93.6%まで引き上げたとき、実際に何を積み上げたのかを書きます。マーケティング向けに磨いた話ではなく、現場で手を動かした実装者として、どこで精度が漏れて、何を直すと上がったのかという具体です。RAGがPoCで止まっている方、本番で精度が落ちて原因を探している方に向けて書いています。

RAGが本番で精度を落とすのは、モデルのせいではない

まず誤解を解いておきたいことがあります。本番で精度が出ないとき、多くのチームは「もっと賢いモデルに替えれば解決するのでは」と考えます。GPTの新しいバージョンを待つ、別のLLMを試す。気持ちはわかるのですが、ここに原因があることは、私の経験ではほとんどありません。

精度が漏れているのは、モデルの手前です。LLMに渡す前の検索が、そもそも正しい文書を拾えていない。賢いモデルも、間違った資料を渡されれば、もっともらしく間違えます。逆に言えば、正しい文書さえ手元に届けば、いまのモデルは十分に正確な答えを返してくれる。

そもそもRAGは「外部の知識を検索してLLMに渡す」枠組みとして2020年に提案され（Lewis et al., 2020）、その後の研究で検索や拡張の設計がNaive→Advanced→Modularと体系化されてきました（RAG Survey, Gao et al. 2023）。本番の精度を分けるのは、まさにこの「モデルの手前」の設計です。

では、なぜ正しい文書が届かないのか。原因は大きく4つの層に分かれていて、これがそのまま私たちの設計の骨格になっています。データの作り方、検索のやり方、効果の測り方、そして運用のしかた。順に見ていきます。

第1層 データ設計 ── 前処理を雑にやると、上の層で取り返せない

精度の土台はデータ設計です。地味で、社内では誰も評価してくれない作業ですが、ここを雑にやると、上のどの層で頑張っても取り返せません。

よくある失敗が、文書を機械的に一定の文字数で区切ってしまうことです。多くのツールはデフォルトでこれをやります。けれど実際の業務文書は、表があり、見出しの階層があり、「前項の条件に従い」のように前後の文脈に依存した記述が当たり前にある。これを文字数で機械的に切ると、答えの半分だけが入ったチャンクや、文脈を失った断片が大量に生まれます。検索でそれを拾っても、LLMは正しく答えようがありません。

だから私たちは、文書の種類ごとに切り方を変えます。契約書なら条文の単位で、レポートなら見出しの構造に沿って、表は表として崩さずに扱う。あわせて、いつの文書か・どの部署のものか・更新されているかといったメタデータを付け、内容の重複した古い版を整理し、すでに廃止された規程が混ざっていれば取り除く。退屈な作業ですが、これだけで検索に渡る素材の質がまるで変わります。

第2層 検索設計 ── ベクトル検索だけでは固有名詞を取りこぼす

ここが、本番で最も大きく精度を落とす層です。そして、改善のインパクトが一番大きい層でもあります。

RAGの検索といえばベクトル検索、という理解が広まっています。文章を意味のベクトルに変換して、意味的に近いものを探す技術です。これは確かに強力で、「契約を途中でやめたいときの手続き」のような曖昧な聞き方でも、解約条項にたどり着ける。意味の近さで探すのが得意なのです。

ところが、この「意味で探す」という性質が、そのまま弱点になります。固有名詞・型番・条文番号・社内コードのように、一文字違えば別物になる情報を、ベクトル検索は平気で取りこぼす。「A社」と「B社」は意味のうえでは近い（どちらも会社名だから）ので、A社について聞いたつもりがB社の資料が上位に来てしまう。商社の業務では、まさにこの固有名詞の取りこぼしが致命的でした。

解決策は、検索を一本に頼らないことです。私たちは3つを組み合わせます。意味の近さはベクトル検索に任せ、固有名詞や型番のような厳密な一致はキーワード検索（BM25）で押さえる。この2つで集めた候補を、最後にリランキングという仕組みで「この質問に本当に答えているのはどれか」という観点で並べ直す。ベクトル＋キーワード＋リランキングの3段構成です（ベクトルとキーワードの検索結果を統合する方法としては、RRF（Reciprocal Rank Fusion）が古典的で安定します——Cormack et al., SIGIR 2009）。

この検索設計を入れたことが、38.8%から93.6%への改善の中で最も大きく効いた部分でした。

第3層 評価設計 ── 「なんとなく良くなった」を捨てる

ここまで読んで、「では検索を直せばいいのか」と思われたかもしれません。半分は正しいのですが、もう半分が抜けています。どこを直せば効くのかを、感覚で当てにいってはいけない。これが第3層、評価設計です。

PoCが止まる現場には、ほぼ例外なく評価セットがありません。「精度が出ない」とは言うものの、何問中何問が正解で、どの種類の質問で外しているのかを、誰も数字で言えない。この状態で改善を始めると、直した気になっては別のところが悪化し、いつまでも「なんとなく」から抜け出せません。

商社の案件で私たちが最初にやったのは、コードを書くことではなく、49問の評価セットを作ることでした。実際の業務でどんな質問が飛ぶのかを洗い出し、それぞれに「これが正解」という基準を用意する。そのうえで、検索が正しい文書を拾えているか、回答が正確か、というレイヤーごとに数値で測れるようにしました。検索と生成を分けて測るのは、RAG評価の研究でも標準的な考え方です（RAGAS, Es et al. 2023）。採点にはLLMを審査員に使う手法も取り入れつつ（LLM-as-a-Judge, Zheng et al. 2023）、ドメイン有識者の人手確認と併用しています。

この物差しがあって初めて、「いま外しているのは固有名詞の質問だ。原因は検索層だ」と特定できる。当て推量で全体をいじるのではなく、一番痛いところに狙って手を入れられる。評価セットは、改善の速度を決める計器盤です。

第4層 運用設計 ── 納品した日が、精度のピークでは困る

最後の層は、納品した後の話です。多くのプロジェクトはここを設計しないまま終わり、リリースした日が精度のピークになってしまう。

社内文書は更新されます。新しい規程が増え、古いものが廃止され、組織が変われば呼び名も変わる。何もしなければ、AIは更新前の世界を見続け、廃止されたはずのルールを根拠に堂々と誤った回答をするようになる。半年も経てば、最初の精度はもう残っていません。

だから運用設計を納品物に含めます。文書が更新されたらインデックスを入れ替えるフロー、データの品質を監視するしくみ、そして評価セットを使って精度を定点観測する手順。第3層で作った計器盤が、ここで生き続けます。記録し続けるから、劣化に気づける。「作って終わり」ではなく「使われ続ける」状態を保つための層です。

商社のケースで実際に起きたこと

ここまでの4層を、大手総合商社の週次レポート検索という具体的な現場で積み上げました。守秘のため社名は伏せますが、起きたことを数字で整理します。

着手前の正答率は38.8%。これは「2回に1回も正しく答えられない」水準で、現場の評価としては実用に届いていませんでした。回答率（そもそも答えを返せた割合）も42.9%にとどまっていた。

ここに4層を入れ、検索の中核にはAgentic RAGを採用しました。質問を受けて一発で検索するのではなく、LangGraphで検索のステップを組み立て、必要に応じて検索をやり直したり条件を絞り込んだりする構成です。前述のハイブリッド検索（ベクトル＋キーワード＋リランキング）と、文書構造に沿ったチャンク設計、49問の自動評価パイプラインを組み合わせています。

結果として、49問の業務シナリオ評価で、正答率は38.8%から93.6%へ。総合品質スコアは2.37から4.55（5点満点）へ。回答率は42.9%から100%になりました。数字を出せたのは、最初に評価セットという物差しを作っていたからです。

RAG改善でよくある誤解と落とし穴

最後に、相談を受ける中で繰り返し出会う誤解を、いくつか正しておきます。

「精度はモデル次第だから、最新モデルを待てばいい」 ── すでに書いたとおり、本番で精度が落ちる主因はモデルの手前にあります。検索が正しい文書を渡せていないのに、モデルだけ替えても結果は変わりません。

「ベクトル検索を入れたから検索は完璧」 ── ベクトル検索は意味の近さに強い一方で、固有名詞や型番の厳密な一致は苦手です。キーワード検索と組み合わせて初めて穴がふさがります。

「とりあえず動いたから、評価は後でいい」 ── 評価セットを後回しにすると、改善のたびに何が良くなったのか分からなくなります。コードを書く前に物差しを用意するほうが、結局は速い。

「リリースしたら完成」 ── 文書は変わり続けます。運用設計のないRAGは、時間とともに静かに劣化し、誤った回答を増やしていきます。

どれも、一度ハマると外から原因が見えにくい落とし穴です。逆に言えば、4つの層をそれぞれ正しく設計すれば、精度は着実に上がります。魔法ではなく、積み上げの問題です。

私たちが顧客の現場と実データに入り込み、PoCで終わらせず使われるまで伴走するのも、要件定義から運用まで一気通貫で関わるのも、層が分断されると精度が漏れることを現場で何度も確かめてきたからです。RAGの精度設計について、より詳しい方法論とサービスの形はAI/RAG精度設計サービスのページにまとめています。法令のように「参照関係」を持つ文書での具体例は、別記事法令RAGをGraph拡張で解いた事例に書きました。

4層チェックリスト（保存版）

RAGが本番で精度を落としているとき、次の4点を上から順に点検してください。ほとんどの場合、原因はこのどこかにあります。

• データ設計 — 文書を文字数で機械的に切っていないか。表・見出し・メタデータを保てているか。
• 検索設計 — ベクトル検索だけになっていないか。固有名詞をキーワード検索で押さえているか。
• 評価設計 — 評価セットはあるか。どの種類の質問で外しているかを「数値で」言えるか。
• 運用設計 — 文書更新時にインデックスを入れ替えるフローと、精度の定点観測があるか。

まずは現状の構成と課題を聞かせてください

もし、いま手元のRAGが本番で精度を落としていて原因が掴めないなら、一度話を聞かせてください。発注を前提とした商談ではなく、30分のオンライン相談です。

いまどんな構成で、どの種類の質問で外しているのか。それを聞けば、4層のどこに穴が空いていそうか、当たりはつけられます。その場で改善の方向性と、おおよその進め方の感覚をお伝えします。「最新モデルを待つしかない」と諦める前に、検索とデータと評価を見直すだけで届く精度が、まだ残っているかもしれません。

30分のオンライン相談を申し込む

参考文献

• 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