「社内文書に答えるAI（RAG）を作ったが、“それっぽいのに間違う”回答が混じる」「PoCでは良かったのに、実際の質問だと精度が出ない」——RAGを業務に載せる段階で、多くの現場がここでつまずきます。原因をモデルの賢さに求めがちですが、結論から言うと、RAGの精度が上がらない多くのケースは、生成（LLM）ではなく「検索」でつまずいています。そして、精度改善は当てずっぽうに直すのではなく、失敗箇所を「検索」と「生成」に切り分けてから、検索側のレバーを順に効かせるのが実務です。
この記事では、なぜ検索でつまずくのか、どこで間違えているかの見極め方、精度を上げる具体的な打ち手、評価とセットで回す進め方を解説します（自社データの使わせ方全体はRAG・ファインチューニングの使い分け、誤答そのものの抑え方はハルシネーション対策、品質の測り方は生成AIの評価（Evals）も参照）。
RAGの精度が上がらないのはなぜ？——「検索」と「生成」に切り分ける
RAGは「検索して、その結果を文脈として渡し、生成する」仕組みです。だから精度は、検索の良し悪しと生成の良し悪しの掛け算で決まります。 ここを押さえるのが第一歩です。
RAG（Retrieval-Augmented Generation）は、質問に関係する社内文書を検索（Retrieval）して取り出し、それをLLMに渡して生成（Generation）させます。つまり、AIは「渡された根拠」をもとに答えているにすぎません。必要な根拠が検索で取れていなければ、どれほど賢いモデルでも正しく答えようがない——ここが、精度問題の多くが検索側にある理由です。
Retrieval質問に関係する文書を取り出す
Context取り出した根拠をLLMに渡す
Generation渡された根拠をもとに答える
RAGの精度は検索×生成の掛け算。根拠が取れていなければ、生成をいくら磨いても正しく答えられない。
よくある誤解は、精度が出ないとすぐに「もっと賢いモデルに変えよう」とすることです。しかし検索が外していれば、モデルを変えても結果は大きく変わりません。まず、どちらでつまずいているかを切り分ける——これが遠回りに見えて一番の近道です。
まず切り分ける：根拠を取れていないのか、根拠はあるのに間違えるのか
精度改善の出発点は、AIが実際に参照した根拠（取得された文書）を見て、失敗を2種類に分けることです。
- ① 検索の失敗：正しい根拠がそもそも取得できていない。関係ない文書や、古い版が上位に来ている。→ この場合、プロンプトをいじっても直りません
- ② 生成の失敗：正しい根拠は取れているのに、答えが間違う・根拠を無視する・盛って答える。→ この場合はプロンプトや出力の設計で直します
見分け方はシンプルで、「AIが根拠として使った文書」を回答と一緒に確認することです。そこに正解の情報が入っていなければ①（検索）、入っているのに答えがずれていれば②（生成）。多くの現場では①が主因ですが、思い込みで決めず、必ず実際の取得結果を見て判断します。この切り分けをせずに手を打つから、改善が空回りするのです。
RAGの検索精度を上げる主なレバー
検索側の失敗と分かったら、次のレバーを、効果を測りながら効くものから入れます。 一度に全部を入れる必要はありません。
| レバー | 何をするか | 効くのはこんなとき |
|---|---|---|
| チャンク設計 | 文書の分割の大きさ・重なり・見出しの保持を見直す | 文が途中で切れて意味が失われている |
| ハイブリッド検索 | ベクトル検索にキーワード検索を併用する | 型番・固有名詞・専門用語が拾えていない |
| リランキング | 取得結果を関連度で並べ替える（reranker） | 正解は取れているが上位に来ていない |
| メタデータ絞り込み | 部署・日付・文書種別で範囲を絞る | 古い版・別部署の文書が混ざる |
| クエリ変換 | 曖昧な質問を検索向きに書き換える | 質問が短い・略語・話し言葉 |
とくに効きやすいのが、チャンク設計とハイブリッド検索です。チャンクが大きすぎると無関係な部分がノイズになり、小さすぎると文脈が切れて意味が失われます。また、ベクトル検索は意味の近さに強い一方、型番や固有名詞のような「一致してほしい語」を取りこぼしがちなので、キーワード検索を併用すると精度が跳ねることがあります。正解が下位に埋もれているだけなら、リランキングで並べ替えるだけで改善します。
生成の精度を上げる——「根拠から答えさせる」
根拠は取れているのに間違える場合は、生成側を「渡した根拠だけで答える」設計にします。
打ち手は主に3つです。渡した根拠の範囲で答え、根拠がなければ『分かりません』と答えさせる、答えの根拠にした箇所（出典）を必ず示させる、答えの形式を業務に合わせて指定する。とくに出典を必ず提示させると、人が誤りに気づきやすくなり、実務での信頼性が上がります。根拠を無視して“それっぽく”答える傾向そのものの抑え方は、ハルシネーション対策も合わせて設計します。
なお、生成側をいくら締めても、検索で正しい根拠が渡っていなければ限界があります。順番としては検索側を先に、が原則です。
具体例：社内ドキュメントQAの精度を上げる
抽象的なので、ある社内ドキュメントQAの改善を例にします（数値はすべて説明用の仮の値です）。
社内規程やマニュアルに答えるRAGを作ったが、代表的な質問50問で正答率が62%にとどまった、という状況とします。まず、外した質問についてAIが参照した根拠を確認したところ、多くが「正しい根拠を取得できていない」検索の失敗でした。そこで、次の順で手を入れます。
| 手順 | 打ち手 | 結果（仮の値） |
|---|---|---|
| 1 | 参照根拠を確認し、失敗を検索/生成に切り分け | 失敗の7割が検索側と判明 |
| 2 | チャンクを見出し単位に作り直す | 正答率 62% → 74% |
| 3 | キーワード検索を併用（ハイブリッド化） | 74% → 83%（型番の質問が改善） |
| 4 | リランキングを追加 | 83% → 88% |
| 5 | 「根拠がなければ分からないと答える」指示＋出典提示 | 誤答の“それっぽさ”が減少 |
ポイントは、一気に全部を入れず、1手ごとに同じ50問で測って効果を確かめていることです。こうすると「何が効いたか」が分かり、無駄な複雑化を避けられます。逆に、切り分けをせずいきなりモデルを高価なものに変えていたら、検索の失敗は残ったままで、費用だけ増えていたはずです。
RAGの精度改善の進め方——評価とセットで回す
精度改善の成否を分けるのは、打ち手のうまさよりも「評価を先に用意しておくこと」です。 測れないものは、良くなったかどうかも分かりません。
進め方の勘所は3つです。
- 代表的な質問セットで評価をつくる：現場でよく来る質問・過去に外した質問を集め、「正しい答え」と「根拠にすべき文書」を定義する。まず数十問でよい（評価の作り方は生成AIの評価（Evals）を参照）
- 検索と回答を分けて測る：検索は「正しい根拠を取れているか」、回答は「正確か・根拠にもとづくか」を別々に見る。切り分けたまま改善するため
- 1手ずつ入れて測る：打ち手を一度に重ねない。1つ入れて再評価し、効いたものを残す。効果が見えないものは戻す
難しいのは、RAGの精度は自社の文書と質問の実態に強く依存する点です。他社でうまくいった設定をそのまま持ち込んでも、文書の作りや質問の傾向が違えば効きません。だからこそ、自社の質問・正解・合格基準を評価として定め、それを物差しに改善を回す——この地道な運用が、精度を実務レベルに引き上げます。
DeploAIのFDEはRAGの精度改善をどう支援するか
DeploAI の FDE（Forward Deployed Engineer）は、精度が出ないRAGを、評価で失敗箇所を切り分けるところから現場で一緒に立て直します。
RAGで成果を出す難所は、モデル選びより「どこでつまずいているかを見極め、自社の文書と質問に合わせて検索を作り込む」ことにあります。FDE は、評価データセットの作成と失敗の切り分け（検索/生成）、チャンク設計・ハイブリッド検索・リランキング・メタデータ設計、生成側のプロンプト改善、そして精度を測り続ける運用の構築までを一気通貫で担います。RAGの精度は自社データに依存するため、汎用ツールの初期設定だけでは上がりません。「それっぽいが間違う」を「根拠にもとづいて正しく答える」に変え、その物差しと改善の仕組みを社内に残すところまで伴走するのが特徴です。
まとめ
- RAGの精度が上がらない多くは、生成（LLM）ではなく「検索」でつまずいている。精度は検索×生成の掛け算。
- 出発点は、AIが参照した根拠を見て失敗を①検索の失敗②生成の失敗に切り分けること。思い込みで手を打たない。
- 検索側のレバーは、チャンク設計・ハイブリッド検索・リランキング・メタデータ絞り込み・クエリ変換。効くものから1手ずつ。
- 生成側は「渡した根拠だけで答える／根拠がなければ分からないと答える／出典を示す」。ただし検索が先。
- 成否を分けるのは評価を先に用意すること。自社の質問・正解・合格基準を物差しに、1手ずつ測って改善する。DeploAI の FDE が切り分けから運用まで伴走する。
RAGを実務レベルにしたい方は、RAG・ファインチューニングの使い分けで自社データの使わせ方を、生成AIの評価（Evals）で品質の測り方を確認してみてください。導入のご相談はお問い合わせから承っています。
関連記事：自社データをAIに使わせるには？（RAG・ファインチューニング）｜生成AIのハルシネーション対策｜生成AIの評価（Evals）｜コンテキストエンジニアリングとは？
