PoC（概念実証）までは簡単に動きます。しかし本番運用に近づくほど、「関係ない文書を拾ってきて答えがブレる」「根拠にない内容をもっともらしく書く（ハルシネーション）」「そもそも精度が上がったのか下がったのか測れない」といった壁にぶつかります。さらに見落とされがちなのが、検索対象の文書そのものが攻撃の入口になるというセキュリティ面の問題です。

この記事では、各社の公式ドキュメントとOWASPの資料でRAGの仕組みとつまずきどころを整理し、「文書の選び方」「間違いの見つけ方」「評価のしかた」を扱った論文4本を紹介します。結論を先に言うと、検索はキーワードとベクトルを組み合わせて選別までを1つの層として設計し、取り込む文書の出どころを管理し、評価は「何を比べたいか」で手段を使い分けるのが基本です！

RAGの仕組み：「探してから答えさせる」

文書を小分けにして、意味の近さで探す

RAGの下準備では、まず社内文書を、通常は数百トークン程度の小さなかたまり（チャンク）に分けます。次に、各チャンクを埋め込み（エンベディング）と呼ばれる数値の並び（ベクトル）に変換して、ベクトルデータベースに保存します。質問が来たら、質問も同じようにベクトルに変換し、意味の近いチャンクを探してプロンプトに追加し、LLMに回答を書かせます（Anthropic「Introducing Contextual Retrieval」）。

OpenAI の説明では、埋め込みは「文字列どうしの関連の強さ」を測るためのもので、ベクトル間の距離が近いほど関連が強いとされます。同社のファイル検索では、既定で800トークンずつ、400トークン重ねて分けます（OpenAI「Vector embeddings」、OpenAI「Retrieval」）。

キーワード検索とベクトル検索は得意分野が違う

意味の近さで探すベクトル検索は、言い回しが違っても同じ話題の文書を見つけられます。一方で、製品の型番や専門用語、日付、人名のように「完全に一致すること」が大事な質問は、昔ながらのキーワード検索（代表的な方式がBM25）のほうが得意です。Microsoft はこの2つを1回の検索で同時に実行して結果を統合するハイブリッド検索を説明し、RAGでは取りこぼしを減らすためにハイブリッド検索を使うよう勧めています（Microsoft「Hybrid search」、Microsoft「RAG in Azure AI Search」）。OpenAI のファイル検索でも、両者の重みを調整できます（OpenAI「Retrieval」）。

RAGがつまずく4つの場所

公式資料を読み合わせると、つまずきは次の4つに整理できます。

1つ目について、Anthropic は「同社の売上は前四半期比3%増えた」のように、どの会社のいつの話かがチャンク単体では分からない例を挙げています。同社の実験では、チャンクに文脈を補ったうえでキーワード検索と組み合わせると、上位20件に必要な文書が入らない失敗が49%減りました（Anthropic「Introducing Contextual Retrieval」）。

2つ目について、OWASP は「LLM09:2025 Misinformation」で、もっともらしいが根拠のない出力をリスクとして挙げています。Anthropic のガイドは、分からないと答えることを許す、資料からの引用で根拠を示させるといった手立てを示しつつ、ハルシネーションを完全には無くせないので重要な情報は必ず確かめるよう書いています（OWASP「LLM09:2025 Misinformation」、Anthropic「Reduce hallucinations」）。

3つ目について、Microsoft は評価を「検索の質」と「回答の質」に分けています。回答の質では、渡した文書から外れていないか（groundedness）を見ます。検索の質は、正解の文書を人が決めておけば、検索設定を変えながら比べられるとしています（Microsoft「RAG evaluators」）。

4つ目は、OWASP が「LLM08:2025 Vector and Embedding Weaknesses」として独立した項目にしているリスクです。意図的か不注意かを問わず、検証されていない文書が混ざれば回答は操られます。OWASP は対策として、信頼できる出どころの文書だけを受け入れる検証の流れ、利用者の権限に応じたアクセス制御、検索の記録を挙げています（OWASP「LLM08:2025 Vector and Embedding Weaknesses」）。文書に指示文を紛れ込ませる手口はプロンプトインジェクションの記事で詳しく扱っています。

研究で見る「どの文書をLLMに渡すか」

📄 論文: 「関連がある」より「答えに効く」文書を選ぶ

InfoGain-RAG: Boosting Retrieval-Augmented Generation via Document Information Gain-based Reranking and Filtering（Zihan Wang ほか、2025年9月、arXiv:2509.12765）は、EMNLP 2025 採録（abs のコメント欄の記載）です。

検索の上位の文書が、回答に役立つとは限りません。この論文は、ある文書を渡したときと渡さないときで、LLMが正解を出す自信がどれだけ変わるかを数値にした指標（DIG）を作り、その値を手本に、検索結果を並べ替える小さなモデル（リランカー）を学習させました。そのうえで、オープンモデルと商用モデルを合わせた18のLLMと組み合わせ、質問応答と事実確認の4種類のデータで正答率を比べています。

GPT-4o と組み合わせた場合、並べ替えをしない素朴なRAGと比べた正答率の差は、4種類のデータの平均で15.3ポイントでした。リランカーは3億パラメータ台と小さく、70億パラメータの既存のリランカーより多くの場合で上回っています。ただし著者らは、この指標では検索した文書の中身が事実として誤っているかは見分けられないと限界に挙げています。

運営者にとっての意味は、検索と回答の間に選別の層を1枚挟むだけで回答が変わりうる、ということです。一方で、選別は「役に立ちそうか」を見るもので、文書が正しいかどうかの確認は別に必要です。

📄 論文: ベクトル検索だけに頼ると「毒入り文書」を拾いやすい

Semantic Chameleon: Corpus-Dependent Poisoning Attacks and Defenses in RAG Systems（Scott Thornton、2026年3月、arXiv:2603.18034）は、査読前の論文（プレプリント）です。

攻撃者が検索対象に細工した文書を紛れ込ませ、特定の質問のときだけ検索されるようにする攻撃をコーパス汚染（ポイズニング）と呼びます。この論文は、意味の近さで上位に来るよう計算で作り込んだ2つ1組の細工文書を、セキュリティ系Q&Aサイトの約6万8千件の文書に混ぜ、50回の攻撃を試しました。ベクトル検索だけの構成では、狙った質問で2つの文書がそろって上位に入った割合が38%でしたが、キーワード検索を組み合わせたハイブリッド検索では、試した3通りの配分のすべてで0%になりました。モデルの再学習は不要です。

ただし、攻撃者が両方の検索方式を同時に狙って作り込むと、ハイブリッド検索でも20〜44%の攻撃が成功し、キーワード側の重みが大きいほど破られやすくなりました。また、百科事典の文書ではベクトル検索でもハイブリッド検索でも細工文書は検索されましたが、無関係な質問でも出てきて目立つため、論文の定義では失敗でした。検索方式ではなく文書の性質による結果です。なお、ハイブリッド化による検索精度への影響はこの論文では測っていません。

運営者にとっての意味は、ハイブリッド検索は防御の第一歩にもなるが、万能ではないということです。外部の文書や利用者の投稿を検索対象に入れるなら、取り込む前の確認と検索の記録を併せて行います。

研究で見る「間違いの見つけ方」と「測り方」

📄 論文: 正解データなしで「根拠のない一文」を見つける

MetaRAG: Metamorphic Testing for Hallucination Detection in RAG Systems（Channdeth Sok ほか、2025年9月投稿・11月改訂、arXiv:2509.09360）は、ECAI 2025 のワークショップ（Identity-Aware AI）での発表論文です（abs のコメント欄の記載）。

業務の質問には正解データが用意されていないことが多く、商用APIではモデル内部ものぞけません。この論文は、ソフトウェアテストの考え方を借りて、回答を小さな事実の単位に分け、それぞれを同義語で言い換えた版と反対の意味にした版を作り、検索した文書と突き合わせます。言い換え版は文書で支持され、反対版は否定されるはずなので、そうならない事実が多いほど「根拠が怪しい」と判定します。

社内文書23件をもとにしたチャットボットの回答67件（人が根拠の有無を判定済み）で試したところ、設定の良い組み合わせでは判定の正確さを表すF1値が約0.94でした。ただし、データは非公開の小規模なもので、回答ごとの正誤しか正解がないため、「どの一文が怪しいか」を当てる精度そのものは測られていません。検証の手順が増える分、応答の速さが重要な場面では負担になりうると著者ら自身が書いています。

運営者にとっての意味は、正解データがなくても「文書で裏付けられない記述」を機械的に拾う仕組みは作れる、ということです。まずは本番の回答の事後点検から試すのが現実的です。

📄 論文: AIに作らせたテスト問題で、どこまで評価できるか

Can we Evaluate RAGs with Synthetic Data?（Jonas van Elburg ほか、2025年8月投稿・10月改訂、arXiv:2508.11758）は、ECML-PKDD 2025 のワークショップ（SynDAiTE）採録（abs のコメント欄の記載）です。

評価用の質問と正解を人手で大量に作るのは大変なので、LLMに作らせる方法が広まっています。この論文は、公開データ2種と企業の製品・営業資料に基づく非公開データ2種で、LLMが作った問題と人が作った問題のそれぞれでRAGの構成に順位を付け、順位がどれだけ一致するかを、完全一致で1になる相関係数で比べました。

取得する文書数などの検索設定を変えた比較では、おおむね順位が一致し、指標によっては平均0.84でした。ただし、検索結果の上位に必要な文書があるかを見る指標では平均0.08とほとんど一致しませんでした。LLMが作る問題は具体的で答えやすく、実際の利用者の曖昧な質問より難しさを低く見積もりがちだ、と著者らはみています。回答を書くLLMを入れ替えた比較では、順位はほとんど一致せず、逆転する組み合わせもありました。

運営者にとっての意味は、AIに作らせたテスト問題は検索設定の調整には使えるが、モデル選びの決め手にはしないほうがよい、ということです。

現場でやること

検索をハイブリッドにし、選別の層を足す

• ベクトル検索だけで動かしている場合は、キーワード検索との組み合わせを試す
• 上位の文書をそのまま渡さず、並べ替えや足切りの仕組みを入れる
• 型番や社内用語を含む質問で、拾えているかを確かめる

検索対象に入れる文書を管理する

社外から集めた文書、利用者の投稿、問い合わせメールなどを検索対象に入れる場合は、出どころを記録し、取り込む前に人か仕組みで確認します。部署ごとに見てよい文書が違うなら、検索の段階で権限で絞り込みます。どの質問でどの文書が使われたかも記録しましょう。

「分からない」と言える設計と、事後の点検

指示文で「文書にないことは分からないと答える」「根拠の箇所を示す」ことを求めます。そのうえで、本番の回答を定期的に抜き出し、文書で裏付けられない記述を点検します。MetaRAG のような自動判定は、この点検の手間を減らす候補になります。

評価用の質問は「実際の質問」から作る

問い合わせログから実際の質問を数十件選び、人が正解と根拠の文書を付けておくと、検索設定の比較にもモデルの比較にも使えます。AIに作らせた問題は、検索設定を何通りも試すときの補助と割り切ります。

RAGを本番で使える品質にする鍵は次の3点です

1. 検索は「ハイブリッド＋選別」までを1つの層として設計する
   キーワードとベクトルを組み合わせ、並べ替えや足切りで「答えに効く文書」だけを渡します。論文では評価された攻撃を抑えましたが、万能ではありません。
2. 取り込む文書の出どころを管理する
   選別の仕組みは文書の正しさまでは見ません。外部の文書は取り込む前に確かめ、権限と記録で守ります。
3. 評価は「何を比べたいか」で手段を使い分ける
   検索設定の比較にはAIに作らせた問題も使えますが、モデル選びには実際の質問で作った評価データを用意し、本番では根拠のない記述を継続して点検します。

まとめ：RAGは「つなげば動く」から「測って直す」へ！

RAGのつまずきは、検索の外れ、根拠のない回答、評価の難しさ、文書が攻撃の入口になることの4つにまとまります。今回の4本の論文は、選別の層を足す、ハイブリッド検索にする、文書で裏付けられない記述を拾う、評価の手段を目的で選ぶ、という具体的な手立てを示していました。

まずは自社のRAGで「どの検索方式で、どこから来た文書を、どう評価しているか」を書き出してみてください。手を付けるべき場所が見えてきます！

参考文献

• OWASP Gen AI Security Project「LLM08:2025 Vector and Embedding Weaknesses」（https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/）2026-10-01 確認
• OWASP Gen AI Security Project「LLM09:2025 Misinformation」（https://genai.owasp.org/llmrisk/llm092025-misinformation/）2026-10-01 確認
• Microsoft「Retrieval-augmented generation (RAG) in Azure AI Search」（https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview）2026-10-01 確認
• Microsoft「Hybrid search using vectors and full-text search in Azure AI Search」（https://learn.microsoft.com/en-us/azure/search/hybrid-search-overview）2026-10-01 確認
• Microsoft「Retrieval-Augmented Generation (RAG) Evaluators」（https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/rag-evaluators）2026-10-01 確認
• OpenAI「Vector embeddings」（https://developers.openai.com/api/docs/guides/embeddings）2026-10-01 確認
• OpenAI「Retrieval」（https://developers.openai.com/api/docs/guides/retrieval）2026-10-01 確認
• Anthropic「Introducing Contextual Retrieval」（https://www.anthropic.com/engineering/contextual-retrieval）2026-10-01 確認
• Anthropic「Reduce hallucinations」（https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinations）2026-10-01 確認
• Zihan Wang ほか「InfoGain-RAG: Boosting Retrieval-Augmented Generation via Document Information Gain-based Reranking and Filtering」arXiv:2509.12765（https://arxiv.org/abs/2509.12765）2026-10-01 確認
• Scott Thornton「Semantic Chameleon: Corpus-Dependent Poisoning Attacks and Defenses in RAG Systems」arXiv:2603.18034（https://arxiv.org/abs/2603.18034）2026-10-01 確認
• Channdeth Sok ほか「MetaRAG: Metamorphic Testing for Hallucination Detection in RAG Systems」arXiv:2509.09360（https://arxiv.org/abs/2509.09360）2026-10-01 確認
• Jonas van Elburg ほか「Can we Evaluate RAGs with Synthetic Data?」arXiv:2508.11758（https://arxiv.org/abs/2508.11758）2026-10-01 確認

2026-10-01 更新: 構成を見直し、論文へのリンクと参考文献を追加し、リランキングによる改善幅（単位と比較対象）、ハイブリッド検索による攻撃の抑止効果の数値、合成データによる評価の一致度、ハルシネーション検出の適用範囲の記述の誤りを修正しました

The post 【2026年最新】RAG（検索拡張生成）の実務×論文4選｜「検索が外れる」「もっともらしい嘘」「評価できない」を解く first appeared on クエビコ.