ハクソク

世界を動かす技術を、日本語で。

RAGの追悼文：エージェントに殺され、コンテキストウィンドウに埋められた

2025年10月2日原文(nicolasbustamante.com)

概要

  • AI検索技術の10年にわたる進化と限界の指摘
  • RAG（Retrieval-Augmented Generation）アーキテクチャの普及と課題
  • Fintoolでの高度なチャンク分割・検索・再ランキング手法の紹介
  • RAGの構造的・運用上の限界と“カスケード障害”問題
  • 新たなアプローチとしてエージェント型・直接検索手法への移行の兆し

RAGの誕生と限界

  • ChatGPT 登場により、 LLMのコンテキストウィンドウ制約 が注目
  • RAG （検索拡張生成）は、膨大な知識ベース対応のための 主流アーキテクチャ として普及
  • 長文書のチャンク化 が必須となり、文書構造やデータの分断問題が顕在化
  • Fintoolでは、 階層構造維持・表の一体化・クロスリファレンス保持・時系列一貫性・脚注紐付け など高度なチャンク分割を実装
  • チャンクごとに メタデータ （文書種別、会計期、階層、表ID、企業ID等）付与で精度向上

検索・埋め込み・ハイブリッド手法の課題

  • 埋め込みモデル は高次元ベクトル化で類似性検索を実現するが、 専門用語や数値表現 の扱いに難
  • BM25 によるキーワード検索は、 正確な一致・専門用語対応・文書長正規化 で有利
  • Fintoolでは ハイブリッド検索 （埋め込み＋BM25）を導入し、 動的重み付け・スコア正規化・RRF（Reciprocal Rank Fusion） で精度向上
  • それでも 再ランキング 工程が不可欠で、 レイテンシ増大・コスト増・管理負荷 が発生

RAGの構造的限界と運用負担

  • カスケード障害問題 ：チャンク化・埋め込み・BM25・ハイブリッド・再ランキング各段階で誤差が連鎖
  • Elasticsearch等の運用負荷 ：大規模インデックス・再インデックス・クラスタ管理・バージョンアップの煩雑さ
  • 構造的な問題点
    • コンテキスト分断 ：文書間・文書内の関係性の消失
    • 数値検索の非対応 ：数値表現やテーブルの意味理解不足
    • 因果関係の欠如 ：参照や会計項目間の因果追跡不可
    • 語彙ミスマッチ ：同義語や表現違いで検索漏れ
    • 時系列認識の弱さ ：期ズレや比較の混同

新潮流：エージェント型・直接検索の台頭

  • 2025年5月、AnthropicのClaude Code が登場し、従来型RAGを使わず 直接ファイルシステム検索 を採用
  • Ripgrep等のgrep系ツール によるライブ検索
    • インデックス不要、 正規表現 で高速・精密なパターンマッチ
    • ファイル種別やglobパターンで 柔軟なフィルタリング
    • 文脈付きの正確なヒット を即時返却
  • 従来のRAGパイプライン （チャンク化・埋め込み・検索・再ランキング）を経ずに、 シンプルかつ高速な検索体験 を実現

まとめ：RAGの黄昏と次の時代

  • RAGベースのインフラ は、技術的・運用的限界に直面
  • エージェント型・直接検索 の進化で、 「文脈の全体把握」や「柔軟な情報探索」 が現実味
  • 今後は 巨大なコンテキストウィンドウ と エージェントアーキテクチャ の成熟が、AI検索の主流に
  • 過去数年かけて築いた RAG基盤 は、 次世代AIの波 により役割を終えつつある

Hackerたちの意見

Claude Codeがgrepをforループに入れるだけで文脈を構築する能力にはいつも驚かされる。知らないコードベースで使うのとほぼ同じプロセスだよ。ファイルシステムをctrl+fして、正しいスタート地点を見つけるまで探す感じ。

└

以前は人間としてそういう使い方をしてたけど、やっとエディタとコンパイラ（とか）の統合設定の面倒くささを克服して、「定義にジャンプ」機能を使えるようになったよ。（まあ、直接的に面倒くささを克服したわけじゃなくて、vimやEmacsを統合設定せずに怠けてたのをやめて、vscodeを試したらそれが簡単にできたって感じ。）

└

すごいよね。めちゃくちゃシンプルで、エレガントで…効果的！grepとglob、あとはたくさんの反復だけで十分だよ。

LLMについて話しているときに、埋め込みや検索パイプラインを「エッジケースの悪夢」と呼ぶのがどれだけ皮肉か、著者は気づいてないのかな。

└

ハハ！LLM自体が純粋なエッジケースだよね、だって非決定論的だから。でも、その上に7ステップのパイプラインを追加したら、エッジケースの上にエッジケースが重なることになる。

これは根本的なスケーリングの問題を無視していて、全体の議論を台無しにしてる。著者の主な例は、Claude Codeがローカルのコードベースをgrepやripgrepで検索することだけど、そこからRAGがすべての文書検索に対して死んでいると主張するのは大きな論理的飛躍だよ。grepは、ミリ秒でスキャンできるローカルファイルシステムに数千のファイルがあるときは素晴らしいけど、ほとんどの企業のRAGのユースケースは分散システムに数百万の文書が関わってる。2Mトークンのコンテキストウィンドウがあっても、企業のナレッジベース全体をコンテキストに収めることはできない。著者はこれを簡単に認めているけど（「ハイブリッド検索を使うかもしれない」って）、それでもRAGが時代遅れだと主張し続けてる。もっと大きな問題は意味的理解だよ。grepは正確なキーワードマッチングをする。もしユーザーが「収益成長のドライバー」を検索して、文書が「売上増加に寄与する要因」について話していたら、grepは何も返さない。これが埋め込みが実際に解決する語彙のミスマッチ問題だよ。著者は記事の半分でこのシナリオ（彼の51億ドルの訴訟例）についてRAGの限界を文句言ってたのに、解決策としてgrepを提案してるんだから、逆にもっと悪化するよね。それに、「エージェント検索」がRAGを置き換えるという主張も誤解を招く。最近の研究では、エージェントRAGシステムがエージェントをRAGパイプラインに組み込んで検索を改善することが示されていて、チャンク化や埋め込みを置き換えるわけじゃない。LlamaIndexの「エージェント検索」もベクターデータベースとハイブリッド検索を使ってるし、ただより賢いルーティングをしてるだけ。コンテキストウィンドウはすごいけど、魔法じゃないよ。この記事は特定の問題（コード検索）を解決した人が、もっと広い領域で勝利を宣言してるように感じる。

└

エージェント検索は実際には深いリサーチの一形態だよ（製品の観点から見ると、ほとんど違いはないけど）。重要なのは、LLMがリランカーよりも優れていること、少なくともウェブスケールでコスト差が大きくなるまではね。

└

フィードバックありがとう。grepがRAGを置き換えるって言ってるわけじゃないよ。大きなコンテキストウィンドウのおかげで、LLMがファイル全体を読めるようになったから、もうチャンクやエンベッドのパイプラインは必要なくなったんだ。grepは候補を絞るための手っ取り早い方法って感じ。そこからモデルが100〜200のフルドキュメントを扱って、マークダウンファイルにメモを取ることでコンテキストを保てる。これって、従来のRAGとは全然違うワークフローだよね。

└

でも、LLMがその企業のナレッジベースの中から文書を人間と同じように検索することってできないの？同じ種類のクエリを使って、同じ基盤の検索インフラを使って。

└

エージェントにgrepを使わせるのって、RAGの一形態じゃないの？通常RAGはベクターデータベースで行われるけど、grepも確かにリトリーバルの一種だし、生成を補強してるよね。

└

同意だね。多くの専門家は、RAGが「大規模言語モデル（LLM）が新しい情報を取得して取り入れるための技術」を意味することを理解していないんだ。だから、RAGはほぼすべてのプロセスに適用される原則としてのパターンなんだよ。コンテキストウィンドウ？うん、細かいことには触れないけど（埋め込み、小型ストレージデバイス、セキュリティ、RAMの欠陥、異なるコンテキストのコストとストレージなど）、コンテキストを埋める行為は何かって？それが適用されたRAGなんだ。RAGはアーキテクチャではなく、原則なんだよ。構造的アプローチだね。最近、多くの人がRAGを検索エンジンと呼ぶ理由があるんだ。知識について知っていることは、無限のコンテキストウィンドウを持つ唯一の存在があるってこと。私たちは今でもそれを神と呼んでいるけど、クラウドとは呼ばないよね。

└

わからないな。grepはRAGじゃないの？

Hacker Newsで議論の続きを見る