RAG の核心的な問題：なぜナレッジベースの検索結果が不正確になるのか ── チャンク戦略から embedding モデル選定まで

多くのチームが RAG を構築する際、最初に注目するのは通常、生成モデルです。

どの大規模モデルで回答するか
どのプラットフォームで構築するか
プロンプトをどう書くべきか

しかし、本番運用後に最も一般的に発生する問題は「モデルが回答できない」ことではなく、「システムがそもそも正しい資料を検索できていない」ことです。

言い換えれば、RAG の核心的な問題は通常、生成側ではなく検索側にあります。

検索結果そのものが不正確であれば、後続のモデルが強力であるほど、むしろ誤ったコンテキストの上にもっともらしい、実際には的外れな回答を生成しやすくなります。

本記事ではこの問題を中心に展開します。なぜナレッジベースの検索結果がしばしば不正確になるのか、そしてチャンク戦略から embedding モデル選定まで、企業が実践においてどう理解し対処すべきかを説明します。

一、なぜ RAG はしばしば「不正確」に見えるのか

RAG の理想的なフローは通常以下の通りです。

ユーザーの質問
→ システムがナレッジベースから最も関連性の高いコンテンツを検索
→ モデルがそのコンテンツに基づいて回答を生成

問題は主に第二ステップに集中します。現実には、検索の不正確さには通常三つの典型的な表れがあります。

資料は明らかに存在するのに、検索されない
検索はヒットしたが、最も重要なその段落ではない
多くのチャンクが検索されたが、ノイズが多すぎて、かえって回答品質が低下する

多くのチームはこれらの問題を「大規模モデルが十分に安定していない」と帰結しますが、実際にはより一般的な原因は通常以下です。

文書のチャンク分割方法が不合理
データクリーニングが不十分
ユーザーの質問と文書の表現方法に明確なセマンティックギャップがある
embedding モデルと業務コーパスが不一致
検索パラメータがシナリオに応じて調整されていない

二、第一層の問題：チャンク戦略が検索の上限を決定する

RAG の基本動作の一つは、長い文書を複数のチャンクに分割し、これらのチャンクに対してベクトル化と検索を行うことです。

問題は、文書が分割されると、元々完全なコンテキストに属していたセマンティックな関係が破壊される可能性があることです。

典型的な例

元の文書の文は以下のようなものかもしれません。

「従業員は入社後六ヶ月経過後に10日間の年次有給休暇を取得できます。」

チャンク分割後に以下のみが保持された場合：

「六ヶ月経過後に10日間取得可能」

この文は一部の情報を保持していますが、コンテキストから切り離されると、その真の意味は曖昧になります。年次有給休暇、手当、試用期間、研修のいずれについて述べているのか、システムは自然に判断できません。

これが多くの RAG システムで最も一般的な第一カテゴリの問題です。情報はまだ存在するが、チャンク分割後にセマンティクスが不完全になっている。

三、チャンクは小さいほど良いわけでも、大きいほど良いわけでもない

多くの実践において、チームは「チャンクをより小さく分割すれば、検索がより精確になる」という直感を形成しがちです。

しかし、実際にはそれほど単純ではありません。

チャンクが小さすぎる場合の問題

文脈が失われる
一つの完全なルールが複数の断片に分割される
検索ヒット後、モデルが取得するのは不完全なコンテキスト

チャンクが大きすぎる場合の問題

ノイズが増加する
複数のテーマが同一チャンクに混在する
検索はヒットしたが、真に重要な情報が長い段落に埋もれる

したがって、チャンク戦略の本質は二つの事項のバランスを取ることです。

セマンティックの完全性
検索の集中度

より合理的な実践方法

異なる文書タイプには、通常異なる分割方法を採用すべきです。

制度系文書：条項または章・節単位で分割
FAQ 系文書：質問と回答のペアで分割
契約系文書：条項単位で分割
製品文書：機能ポイントまたはテーマ単位で分割

つまり、より効果的なチャンク戦略は通常、固定文字数ではなく、文書のセマンティック構造に基づいて分割するものです。

四、第二層の問題：質問方法と文書の表現方法の間に明確なギャップがある

RAG が不正確になるもう一つの一般的な原因は、ユーザーの質問とナレッジベース文書の表現方法の差異です。

例えば、ユーザーは直接以下のように質問します。

「休暇は何日ありますか？」
「これは経費精算できますか？」
「台風の時は何に注意すべきですか？」

一方、文書中の表現は往々にしてより正式です。

「年次有給休暇の付与日数」
「旅費精算規程第八条」
「災害時の行動基準」

ユーザーの質問は通常より口語的、より曖昧、より圧縮されます。文書の表現はより正式、より完全、より専門的です。セマンティクス上は関連していても、ベクトル空間上の距離が十分に近いとは限りません。

これが、ますます多くのチームが Query Rewrite や HyDE などの拡張戦略を導入する理由です。

まずユーザーの質問を規程言語や文書言語に近い形にリライトする
リライト後のクエリで検索に入る

本質的に見ると、この種の方法は「質問方法」と「文書の表現方法」間のギャップを埋めるものです。

五、第三層の問題：データ品質は通常モデル選択より重要

多くの RAG システムのパフォーマンスが不安定な理由は、戦略が高度でないからではなく、基盤データそのものが十分にクリーンでないからです。

よくある問題は以下の通りです。

同じコンテンツの複数バージョンがアップロードされている
旧版と新版の規程が混在している
PDF テキスト抽出のエラー
OCR スキャン品質が不安定
一つの文書に複数の無関係なテーマが混入している
ヘッダー・フッター、ページ番号、印章などのノイズが本文に入っている

このような状況では、どんなに優れた embedding モデルでも、低品質データに対してベクトル化を行うことしかできません。

したがって、非常に重要な原則は以下の通りです。

RAG の検索品質は、まずデータの入口が十分にクリーンかどうかで決まります。

アップロード前のクリーニング、重複排除、バージョン管理、構造整理は、多くの場合、後工程の複雑な調整よりも優先的に投資する価値があります。

六、なぜ embedding モデルの選定が極めて重要なのか

多くのプラットフォームでは、embedding はデフォルトコンポーネントとして扱われ、あれば十分使えるかのように見えます。

しかし実際には、embedding モデルはシステムが「類似」をどう理解するかを直接決定します。

ベクトル検索の本質はキーワードマッチングではなく、embedding モデルがテキストをセマンティック空間にどうマッピングするかだからです。

これが意味すること

同じ文が、異なる embedding モデルでは異なるセマンティック近接関係を形成する可能性があります。例えば：

英語技術コーパスに長けたモデルもある
日本語やビジネステキストに適したモデルもある
短文クエリに適したモデルもある
長文コンテキストの圧縮においてより安定したモデルもある

企業のナレッジベースが主に規程、契約、社内規範などのビジネスコーパスであるにもかかわらず、このタイプのテキスト構造に適していない embedding モデルを選択してしまうと、検索の不正確さは非常に自然な結果です。

インデックス構築コスト
インデックス再構築コスト
検索レスポンス速度
ローカルまたはプライベートデプロイのサポート有無

したがって、embedding モデルの選定は「どれが最も先進的か」だけを見るのではなく、「現在のビジネスコーパスと実際のデプロイ条件に最も適したもの」を重点的に見るべきです。

八、なぜ単に大規模モデルを入れ替えるだけでは RAG の問題は通常解決しないのか

チームが RAG のパフォーマンスが悪いと感じた場合、最初の反応としてよくあるのは、より強力な生成モデルへの入れ替えです。

しかし、検索で取得したコンテキスト自体が不正確であれば、どんなに強力な生成モデルでも根本的には問題を解決できません。できることは通常以下のいずれかに限られます。

誤ったコンテキストに基づいて誤った回答を生成する
ノイズの多いコンテキストの中で要点から外れた回答を生成する
資料不足の場合、常識で補完する

これが、実際の構築において以下の順序での最適化がより推奨される理由です。

データクリーニング
チャンク設計
クエリリライトまたは検索拡張
embedding モデルの評価
最後に生成モデルとプロンプトの最適化

九、より現実的な最適化順序

企業が社内 RAG システムを構築中であれば、以下の順序で問題を優先的に調査することを推奨します。

第一ステップ：データ品質を確認する

重複文書がないか
旧版資料が混入していないか
PDF のテキスト抽出は安定しているか
コンテンツがテーマ別に合理的に分割されているか

第二ステップ：チャンク戦略を確認する

純粋な文字数ではなくセマンティック構造に基づいて分割しているか
コンテキストが切断される問題がないか
一つのチャンクが複数のテーマをカバーしていないか

第三ステップ：クエリ方法を確認する

ユーザーの質問が口語的・曖昧すぎないか
Query Rewrite や HyDE が必要か
マルチターン対話で指示代名詞の解消が必要か

第四ステップ：embedding モデルを確認する

現在の言語に適しているか
現在の文書タイプに適しているか
実際の比較テストを行ったか、デフォルトオプションをそのまま使用していないか

第五ステップ：検索パラメータを確認する

Top K が合理的に設定されているか
重複チャンクが結果を占有していないか
リランキングや付加的な検索戦略が必要か

十、RAG の本質は「資料を入れること」ではない

多くの人は RAG を以下のように理解しています。

「会社の資料をアップロードすれば、AI が理解してくれる。」

しかしシステムの観点から見ると、RAG は検索システムにより近いものであり、生成モデルはこのシステムの最終層の表現能力に過ぎません。

その鍵は「どれだけ記憶しているか」ではなく、以下です。

正しいタイミングで
正しい場所から
正しいコンテキストを見つけ
それをモデルに組織化と出力を任せる

したがって、RAG の核心は「ナレッジベースがあるかどうか」ではなく、「検索システムがあなたの文書構造とユーザーの質問を真に理解しているか」です。

まとめ

ナレッジベースの検索結果が不正確になるのは、通常単一の問題ではなく、複数の層が重なった結果です。

チャンク分割方法が不合理
データ品質が不十分
ユーザーの質問と文書表現のギャップが大きすぎる
embedding モデルとコーパスが不一致
検索パラメータがビジネスシナリオに沿って調整されていない

したがって、RAG の核心的な問題は「モデルにどうすればもっとうまく回答させるか」ではなく、以下です。

回答されるべきコンテンツをシステムにどうすればまず見つけさせるか。

この順序を整理すれば、元々「モデルが十分に賢くない」ように見えた多くの問題が、より具体的で解決に適した検索エンジニアリングの問題として還元されることになります。

MKC — Dify Japan コンテンツ体系