結論から言う。RAGは「入れた後」じゃなく「入れる前」で勝負が決まる

RAGを導入した中小企業の現場で、最もよく聞く失敗がこれだ。

「社内の文書、全部ベクトルDBに突っ込みました」

これ、最悪の一手。コストが膨らむだけじゃない。検索精度そのものが壊れる。

RAG（Retrieval-Augmented Generation）は、外部データを検索して、LLMに渡して回答を生成する仕組みだ。ChatGPTに「自社データで答えさせたい」というニーズで導入する企業が増えている。だが、ほとんどの企業が「データの入れ方」を軽視している。

問題の本質はシンプルだ。ゴミを入れれば、ゴミが返ってくる。しかも、LLMはゴミをもっともらしい日本語で包装して返してくるから、現場は「合ってるっぽい嘘」に気づけない。

この記事では、最新の研究動向を踏まえつつ、「データを入れる前に何をすべきか」を中小企業の現場目線で整理する。

—

「毎回解釈し直す」から「最初に整理しておく」へ——インジェスト時コンパイルの衝撃

従来のRAGは、ユーザーがクエリを投げるたびに、LLMが生データの意味を解釈していた。毎回、だ。

これはデータベースで言えば「フルテーブルスキャン」に近い。テーブルが小さいうちはいい。だが、社内文書が数千件、数万件になったらどうなるか。検索は遅くなり、コストは跳ね上がり、的外れな文書を拾ってくる確率が上がる。

ここで注目すべきがインジェスト時コンパイル（Ingest-time Semantic Compilation / ISC）という考え方だ。

何が違うのか。データを投入する「その瞬間」に、以下を済ませてしまう。

• 文書を「原子的な主張（atomic claim）」の単位に分解する
• 各主張に対して埋め込みベクトルを生成する
• 主張間の依存関係を事前にマッピングする

つまり、検索される前に、データを「検索されやすい形」に加工しておく。

研究では、このアプローチによりデータ更新時のコストが従来比で約33.7分の1に下がったと報告されている。中小企業にとって、この差は致命的に大きい。月額のAPI利用料が30万円かかっていたものが1万円以下になる可能性がある、という話だ。

しかも精度が上がる。なぜか。LLMが毎回「この文書、何が言いたいんだっけ」と解釈し直す必要がなくなるからだ。事前に整理された主張を、そのまま検索して渡せばいい。

「入れる前にどう整理するか」が、コストと精度の両方を決める。これがISCの本質だ。

—

「必要な情報が静かに消える」問題——構造的排除は気づけない

RAGにはもう一つ、中小企業が見落としがちな落とし穴がある。

必要な情報が、検索結果から静かに排除される現象だ。

RAGでは、クエリに関連する文書を上位N件取得してLLMに渡す。このNには上限がある。トークン数の制約、コストの制約があるからだ。

問題は、「直接的には関連が薄いが、回答に不可欠な前提情報」が、このN件から漏れることだ。研究ではこれを「構造的間接前提排除（Structural Indirect Premise Exclusion）」と呼んでいる。

具体例で言おう。

社内の営業マニュアルに「A製品の価格は、B契約の条件に基づいて決定される」と書いてある。ユーザーが「A製品の価格は？」と聞いたとき、RAGは「A製品」に関連する文書を優先的に取得する。だが、「B契約の条件」に関する文書は関連スコアが低いため、検索結果に含まれない。結果、LLMは不完全な情報で回答を生成する。間違った価格を、自信満々に答える。

この問題への対策として提案されているのがDependency-aware Semantic Garbage Collection（DSGC）だ。情報間の依存関係を追跡し、「この主張を保持するなら、前提となるあの主張も保持しなければならない」というルールで記憶を管理する。

効果は劇的だ。従来手法では情報の保持率が0.03（3%）まで落ちていたケースが、DSGCでは0.90（90%）まで改善されたという報告がある。

中小企業の現場で言えば、「なぜかRAGが的外れな回答をする」という現象の多くが、この構造的排除に起因している可能性がある。データの量ではなく、データ間の「つながり」が切れているのだ。

—

「関連性が高い」と「正しい」は別の話——誤情報検出の壁

もう一つ、現場で見過ごされている問題がある。

RAGが取得した文書の「関連性スコア」が高いからといって、その内容が「正しい」とは限らない。

古い社内規程、更新されていない価格表、誰かが書きかけで放置したメモ。これらがベクトルDBに入っていれば、関連性スコアだけは高く出る。LLMはそれを「正しい情報」として回答に使う。

これがSecurity-Reliability Gapと呼ばれる問題だ。意味的に近い文書を取得する能力と、事実として正確な文書を取得する能力は、まったく別のスキルなのだ。

最近の研究では、自然言語推論（NLI）ベースの事実検証を組み込んだEvaluation Agentが、特定トピックにおいて91%の精度で誤情報を検出できたと報告されている。

だが、中小企業がいきなりこの仕組みを実装するのは現実的ではない。ここで大事なのは、技術で解決する前に「入れるデータの鮮度と正確性を人間が担保する」というステップだ。

具体的には、こういうことだ。

• 最終更新日が1年以上前の文書は投入対象から外す
• 「下書き」「未承認」ステータスの文書は除外する
• 同じトピックに複数バージョンがある場合、最新版のみ投入する

地味だ。だが、この「入れる前のフィルタリング」だけで、体感の回答精度は劇的に変わる。300件の文書を全部突っ込むより、厳選した50件を入れたほうが精度が高い。そういう世界だ。

—

中小企業が最初にやるべき、たった1つのこと

ここまでの話をまとめると、構造はシンプルだ。

中小企業が最初にやるべきことは、「インデックス設計書」を1枚作ることだ。

大げさなものじゃない。以下の3つを決めるだけでいい。

1. 何を入れるか——対象文書の範囲と除外基準を明文化する
2. どう分割するか——文書単位か、段落単位か、主張単位か
3. 何を捨てるか——古い文書、重複文書、下書きの扱いを決める

この1枚があるかないかで、RAGの精度はまったく違うものになる。

技術的に高度なISCやDSGCは、将来的に導入を検討すればいい。だが、「何を入れて、何を入れないか」を決めることは、今日からできる。コストはゼロだ。

—

「入れる前」を制する者がRAGを制する

RAGは「AIが賢く答えてくれる魔法の箱」ではない。「何を食わせるかで出力が決まる、正直すぎる機械」だ。

大企業は専任チームを組んでデータパイプラインを設計できる。中小企業にはその余裕はない。だからこそ、「入れる前の設計」に集中すべきだ。少ないリソースで最大の効果を出せるポイントが、まさにここにある。

300件の文書を全部突っ込んで月額30万円払い続けるか。50件に厳選して月額3万円で、しかも精度が上がるか。

答えは明白だろう。

RAGの導入を検討している中小企業の経営者に伝えたい。ツール選定の前に、ベンダーとの打ち合わせの前に、まず「インデックス設計書」を1枚書いてほしい。それが、RAG成功の9割を決める。

—