RAGは壊れる, スタンフォード研究が示した「Semantic Collapse」とは何か

**投稿者:** How To AI (@HowToAI_)

**URL:** https://x.com/HowToAI_/status/2043713987171492224

**反応:** 2785 likes / 588 reposts / 2640 bookmarks / 302680 views

要約

このブックマークは、RAGが大規模化したときに性能劣化する根本原因として「Semantic Collapse」を紹介している。参照した元記事では、スタンフォードの研究をもとに、ベクトル検索が文書数の増加とともに意味的な距離を保てなくなり、関連文書の取り違えが起こる構造的問題を説明している。特に、1つの巨大なベクトル空間にすべての文書を押し込む設計は、数万件規模を超えると検索精度が崩れやすい。対策としては、ドメインや時系列ごとにコーパスを分割し、ルーティング層を設けて、検索前に探索範囲を絞るアーキテクチャが重要だとされる。

本文

生成AIの実務導入では、RAGは「幻覚を減らし、社内文書やナレッジベースを読ませるための王道手法」と見なされてきた。しかし、元記事が指摘するのは、RAGの問題はモデルの言い回しやプロンプト品質ではなく、*検索そのものが規模拡大で壊れる* ことにあるという点だ。

記事によれば、初期のRAGシステムはかなりうまく見える。社内デモや小規模テストでは、回答はもっともらしく、根拠もあるように見える。ところが本番投入後に文書数が増えるにつれ、回答が「一見もっともらしいのに、微妙に古い、欠けている、文脈がずれている」という壊れ方を始める。つまり、文章生成の自然さは保たれているのに、検索された文脈が正確ではない。

元記事は、スタンフォード大学の法務AI領域の研究をもとに、この現象を説明している。RAGでは通常、文書を高次元ベクトルに埋め込み、クエリに近いベクトルを検索して、その近傍文書をLLMに渡す。小規模な集合では、関連文書同士がきれいにまとまり、似た内容が近くに配置されるので機能する。だが、文書集合が大きくなってくると、ベクトル空間が混み合い、距離の差が潰れていく。

このとき起こるのが *Semantic Collapse* である。意味的に本来は区別されるべき文書群が、ベクトル空間上では十分に分離されなくなり、異なる領域、異なる時期、異なる制度圏の文書が「なんとなく似ているもの」として近くに並んでしまう。記事では、概ね1万文書を超えたあたりから精度低下が見え始め、5万文書を超えると意味検索の精度が大きく崩れ、場合によってはキーワード検索以下になると説明している。

この問題が危険なのは、出力が露骨に破綻しないことだ。LLMはランダムな嘘をつくのではなく、「意味的にはそれっぽいが、実際には誤った」文書群を元に整った回答を作る。法務分野なら、別の法域の判例を正しい文脈のように扱う。企業内ナレッジなら、古いポリシーや暫定メモを現行ルールのように要約してしまう。つまり、幻覚というより、*取得段階で間違った証拠が渡されることによる系統的誤答* が起きる。

元記事は、多くのRAGプロダクトが共有している前提, すなわち「全ドキュメントを単一の巨大ベクトルインデックスに入れておけばよい」という設計思想こそが問題だと指摘する。データが増えれば増えるほどノイズは増え、長いコンテキストウィンドウや大きなモデルで覆い隠すことはできない。モデルが流暢になるだけで、検索精度は戻らない。

対策として提案されているのは、コーパスを複数の有界グループに分割することだ。記事では、1グループあたりおよそ1万文書程度に抑えると、意味距離の有効性を保ちやすいとしている。分割軸は、法域、事業部、プロダクトライン、時期、文書種別など、実世界の構造に沿って設計するべきだとされる。重要なのは、最初から無関係な文書同士を競わせないことにある。

さらに、分割だけでは不十分で、検索前にどのグループを探索すべきかを決める *routing layer* が必要だと述べている。クエリに対して、どのドメインか、どの時間帯の情報か、どのカテゴリかといった制約を推定し、該当グループだけ検索する。これにより検索空間が狭まり、関連性の高いコンテキストだけをLLMに渡せるようになる。

元記事全体のメッセージは一貫している。RAGの本質的な品質は、生成の上手さではなく、検索の設計で決まる。強いメタデータ、コーパス分割、探索範囲のルーティング、そして検索精度そのものの計測が不可欠である。回答が流暢かどうかで評価していては、壊れたRAGを見抜けない。

なぜ重要か

RAGを「とりあえずベクターストアに全部入れればよい」と捉える実装はかなり多く、そのまま本番拡大すると静かに誤答率が上がる。AI検索や社内ナレッジQAを実運用するなら、生成より先に検索アーキテクチャを設計し直す必要がある。

活用ポイント

• 大規模RAGでは、文書を単一インデックスに集約しすぎない
• 事業部、文書種別、時系列などでコーパスを分割する設計を最初から考える
• クエリ前段にルーティング層を置き、探索範囲を限定する
• 回答の自然さではなく、検索精度や正答根拠の妥当性を評価指標にする
• 古い文書や別ドメイン文書が混ざると起こる「もっともらしい誤答」を重点的に監査する