6月25日、Techstrong AIが「RAG Fails Upstream and Most Teams Are Fixing the Wrong Problem」と題した記事を公開した。RAG（Retrieval-Augmented Generation）パイプラインが本番環境で失敗する根本原因はデータ品質やガバナンスといった「上流」にあり、多くのチームが誤った場所を修正し続けているという問題を、複数のエンジニアリング実務者の証言をもとに詳しく論じている。
RAGは「ドキュメントをLLMに繋ぐだけ」という印象で普及した手法だ。LLMが回答を生成する前に外部ドキュメントから関連情報を検索・取得して文脈として与えることで、ハルシネーションを抑えつつ専門知識を活用できる。その手軽さゆえに、多くのチームがパイプラインの本質的な難しさを理解する前に本番リリースまで走り切ってしまっている。問題はデモでは現れない。3ヶ月後、検索品質が劣化し、エッジケースが積み重なった時点で噴出する。
問題は「上流」にある
記事の核心は「RAGは1つではなく2つの工学的問題であり、チームは簡単な方しか解いていない」という指摘だ。
2つの問題とは：
- 検索（Search）: 知識ベースから正しいチャンクを見つける
- 文脈組み立て（Context Assembly）: 見つけたチャンクをモデルが推論できる形で渡す
ほとんどの実装は2番目を「難しい問題」として過剰投資し、1番目の上流——つまりデータ品質とガバナンス——を軽視する。
AIネイティブの品質エンジニアリングプラットフォームTestMu AIの共同創業者Mayank Bholaは、この構図を繰り返し目撃してきたと語る。「データ準備の問題はデモでは表面化しない。デモはキュレーションされているからだ。本番投入後、デモが一度も触れなかったエッジケースが検索レイヤーに到達し始めた時点で露わになる。」
データ品質が最も多くのRAGを殺す
Instaclustr（NetApp傘下）のエンジニアリングエキスパートで、Cassandra・OpenSearch・Cadenceへの貢献でも知られるCarlos Roloは、企業が持ち込むデータの実態をこう描写する。PDF、Wordドキュメント、SharePointのコンテンツ——これらをRAGに流し込めば検索可能になる、という期待で話が始まる。しかし現実に待っているのは：
- カンマを含むテーブル（人間には自明でも、パースが壊れる）
- テキスト化できない画像・グラフ
- スキーマが不統一なレガシードキュメント
「カンマが一つ入っているだけで、RAGパイプライン全体が崩壊する。その後は何も検索できなくなる」とRoloは語る。
対策として記事が名指しするのは、IBMのDoclingとMicrosoftのMarkitdownだ。どちらも複雑な企業ドキュメントのパース専用に設計されたOSSで、データ準備レイヤーの構成要素として評価すべきだとされている。
アクセス制御は後付けできない
ガバナンスの問題はRoloが「最も過小評価されている」と指摘する領域だ。
ドキュメントレベルのアクセス制御は、パイプライン設計の時点で組み込む必要がある。稼働後に後付けすることはできない。「見てはいけない人が見ているのか？」という問いに、本番稼働前に答えられていないチームは、従業員が閲覧権限のないコンテンツを取得して初めてその事実に気づく——その時点でパイプラインの一部を作り直す羽目になる。
Dremioのデベロッパーリレーションズ責任者Alex Mercedはさらに踏み込む。「ほとんどの企業が抱えているのはエンベディングの問題ではなく、コンテキストの問題だ。データが複数システムに断片化され、記述が貧弱で、モデリングが一貫しておらず、自律的エージェントを想定していないプロセスでガバナンスされている。」そして「精度の高いエンベディングは、間違った答えを速く返すだけだ」と断言する。
ベクトル検索の過剰最適化という罠
Roloが到達したアーキテクチャ上の知見は、「キーワード検索とベクトル検索のハイブリッドが単独使用より一貫して優れる」というものだ。
- キーワード検索: 固有名詞・識別子・正確な用語マッチが必要な場合
- ベクトル検索: 概念的なクエリで、質問と文書が同じ語彙を共有しない場合
Mercedも同様の過剰最適化を企業チームで観察している。「エンベディングのチューニング、ベクトルDBの入れ替え、わずかなリコール改善の追求——こういった作業に時間を費やしながら、データガバナンス・セマンティック一貫性・ハイブリッド検索・エンドツーエンドのレイテンシという問題を軽視している。」
データベース選定についてRoloの結論はシンプルだ。「すでに持っているデータベースがベクトル検索をサポートしているなら、そこから始めろ。」pgvector付きPostgres、ML Commons付きOpenSearch、ベクトル検索付きCassandra——これらは成熟した選択肢であり、新システムの学習コストを払いながら信頼性の高いAIプロダクトを同時に出荷しようとする愚を避けられる。
コンテキストウィンドウの拡大は精度問題を解決しない
大きなコンテキストウィンドウを持つモデルが登場したことで、「検索の精度が低くてもとりあえず多く詰め込む」というアプローチが生まれた。Roloはこれを否定する。
「低品質なコンテキストがいくら大きくても、その中に必要な情報が含まれていたとしても、良い手法ではない。」関連性の薄い30チャンクに埋もれた3チャンクについてモデルが推論する精度は、3チャンクだけを渡した場合より著しく低下する。これは「コンテキストロット（context rot）」と呼ばれる現象だ（直訳すると「文脈の腐敗・劣化」であり、コンテキストに不要な情報が混入することで回答精度が徐々に落ちていく状態を指す）。
重要なのは、この劣化しきい値がモデルとデータ固有であることだ。「LLM AがLLM BやCより優れているという話ではない。自分たちのLLMがコンテキストをどう扱うかをベンチマークして理解することが重要だ」とRoloは述べている。
RAGは「一度作ったら終わり」ではない
TestMu AIのBholaは、同社が開発するエンドツーエンドテストエージェントKaneAIの構築経験から得た教訓を語る。「RAGを一度きりのビルドとして扱ったチームは、初期実装を急いで節約した時間より多くの時間を火消しに費やすことになる。検索レイヤーは徐々に劣化し、データ分布は変化し、モデルはアップデートされる。システムは動き続けているためアラートが発火しない。ただ3ヶ月前より悪化しているだけで、誰もそれを計測していない。」
対策として記事が示す処方箋は技術的な選択よりも「順序」と「オーナーシップ」の話だ——データ準備を並行トラックではなく前提条件として扱い、検索パイプラインに名指しのオーナーを置き、リトリーバルの品質ベンチマークを定期実行する体制を作ること。
詳細はRAG Fails Upstream and Most Teams Are Fixing the Wrong Problemを参照していただきたい。
