ハクソク

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

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

236日前原文(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じゃないの？

└

RAGって具体的に何なの？特定の技術なのか、それとも技法なの？僕はAIの専門家じゃないけど、コードベースをgrepするのはまさにRAGそのもののように思えるんだ。ツールの使用はただの（もっと洗練された）RAGじゃないの？

└

RAGは単に単語ベクトルだけじゃなくて、キーワード検索も含むよ。Claudeがgrepを使うのはRAGの一形態だね。

└

grepとLLMって、結局RAGの一種じゃない？

└

これが私の意見でもあるけど、あなたへの他の返信も一理あると思う。ここでのポイントは、RAGの「Retrieval」がすごく曖昧だってこと。誰が何のためにRAGを使うかによって、意味が全然違うんだよね。私はむしろ「ディープセマンティック検索と生成」と呼びたいものが必要だと思ってる。100kのPDFのテキストチャンクの埋め込みを使って、アイデアの近さを検索する能力があって、それをLLMのコンテキストに入れて、LLMがプロンプトに対して最も関連性の高いPDFから引用して応答を生成するっていうのが理想だと思う。これが「ディープリサーチ」アシスタントのキラーアプリだと思うし、単に単語をgrepして関連ファイルをコンテキストウィンドウに入れるだけでは実現できないよね。問題は、膨大な量の混合メディアファイルの埋め込みをどうやって迅速かつ安価に生成してデータベースに保存するかってこと。RAM内のファイルに対するCPU grepは、GPU上でチャンク化されたファイルのセマンティック埋め込みを生成して保存するのに比べて、桁違いに速いからね。

RAGは死んでないよ、ただちょっと面倒なだけで、タスクに合わせて検索を調整する必要がある。あと、grepもRAGの一種だよ、ただ埋め込みを使ってないだけ。

└

そうそう、要するにRAGのパイプライン、つまりインジェスト、チャンク、エンベッド、Elasticでの検索、再ランク付けが衰退してるってこと。grepの方がずっとシンプルだし、ほんとに簡単だよね。

└

いや、grepはRAGじゃないよ。RAGは埋め込み + ベクトル検索 + 固定ワークフローの下で動作するLLMのことなんだ。grepもRAGだと言うのは、ext4 + grepがデータベースだと言ってるようなものだよ。

建設業界の入札を処理してるんだけど、最初から「無料」のバケットソートがついてくるんだ。つまり、ほとんどの人が単一の入札だけを扱うから。でも、その単一の入札は10億トークン規模になることもある。たとえLLMがその狂ったコンテキストウィンドウをサポートしても、移動させるのは約4GBで、現在のLLMの価格だと推論に何千ドルもかかるよ。これについては、詳しくはここに書いたよ。https://www.tenderstrike.com/en/blog/billion-token-tender-ra... これはただの一つの（確かに大きいけど）入札に過ぎない。大きな会社のコーパスだと、トリリオンのトークンを見込むことになるだろうね。コンテキストを小さく切り分けてLLMに送るのがもはや良い戦略じゃないってのには同意するけど、最終的に関係のないページを何千も送るのも良くないし、エンベディングは（従来の）BM25テキスト検索と比べてはるかに優れた検索体験を提供してくれるよ。

└

AIスタートアップで働いてるんだけど、ドキュメントを事前処理して各ドキュメントの短い要約を作るソリューションを探ってるんだ。それから、その要約をボットに指示として提供して、どのドキュメントが関連しているかを判断させる感じ。これだと、100k〜1mトークンの数百のドキュメントにスケールできるみたいだけど、コンテキストウィンドウのサイズやロットの問題にぶつかるんだ。これをツリー構造に拡張することも考えたけど、今は他の優先事項があるから。エンベディングにはコンテキストサイズの制限があったんだよね。大きな技術マニュアルを見てたから。Geminiが1mのコンテキストウィンドウを持ってたけど、なぜかエンベディングウィンドウは小さいんだ。情報が多すぎるとエンベディングが崩れるんじゃないかって思ってる。

いくつかのRAGベースのアプリを作った後、著者が言及しているClaudeCodeベースのアプローチを試してみたくなったんだ。それで、ripgrepをREST APIに公開するPythonサービスを作ったよ。https://github.com/masterkram/jaguar これで、coolifyにすぐにデプロイできて、アップロードしたファイルのどれにでもripgrepを使えるエージェントをすぐに作れるようになるんだ。

人々は「エージェントはRAGじゃない」って言うけど、一つの見方としては、これはRAGを説明してるってことになる。データベースがファイルシステムで、bashがクエリ言語って感じ（他のCLIツールも使えるし、curlやjq、grepも含まれてる）。自分のメモをファイルシステム構造に書き込んで、それを「データベースをインデックスする方法」として維持してる。必要なデータのチャンクを選んで取得するためにコードを使ってるから、すべてをコンテキストに入れるわけじゃない。要するに、ただのより良いRAGってこと？

「エージェントにループ内でgrepを使わせる」っていう考えは分かるよ。結局、人間がctrl-fでドキュメントを探るのと似てるからね。でも、もしベクトル検索がctrl-fと同じくらい簡単に使えたら、人間もずっと使うんじゃないかな？だから、ベクトル検索を捨てるんじゃなくて、エージェントにツールとして提供すればいいと思う。複雑さは別として、エージェントが「ループ内でのベクトル検索」で巨大なドキュメントベースを探る方が、grepのループよりも強力だと思う。全体的にこの記事は良かったよ。

└

僕のメンタルモデル（「すべてのモデルは間違っているが、一部は役に立つ」という意味で）は、ベクトル検索がgrepするための用語を提供するものだと思ってる。

└

概念的にはそうだけど、実際にはベクトル検索の結果はあんまり良くないことが多いよね。

専門家じゃないから訂正されても構わないけど、RAGって単にコンテキストを豊かにすることじゃないの？必ずしもセマンティック検索である必要はなくて、APIコールやデータベースから情報を取得することも含まれると思うんだ。

正直、RAGが全盛期を迎えたのがいつだったのか、ちょっと分からないな。まだまだ初期段階だと思う。