RAG は死んだのか？— Turbopuffer の Kuba Rogut氏

RAG は死んだのか？「検索」から「推論と検索のループ」へ、Cursor が示す未来

「RAG（Retrieval-Augmented Generation）は死んだ」という言葉がテック界隈で飛び交っています。しかし、これは単純な技術の終焉ではなく、単なるベクトル検索に依存する従来のアプローチから、エージェントが自ら文脈を発見・推論する「アジェンティック・サーチ」へと設計思想が転換したことを意味します。

本記事では、Turbo Puffer の Kuba Rogut 氏が語る最新動向を整理し、なぜ今、検索のあり方が根本から変わっているのか、そして Cursor が実証した具体的な最適化手法について解説します。

RAG とアジェンティック・サーチの再定義

「RAG は死んだ」という議論は、2025 年末から 2026 年初頭にかけて X（旧 Twitter）上で急増しました。多くの人が「エージェント型ファイル検索だけで十分だ」と主張する背景には、従来の RAG に対する限界への不満があります。

一般的に RAG と呼ばれるものは、コンテンツをエンベディング（数値化）してベクトル検索を行い、その結果を LLM に渡すだけの単純なプロセスと捉えられがちです。しかし、Kuba 氏はこれを「RAG の本質はベクトル検索だけではない」と定義し直します。

RAG は単なるベクトル検索ではありません。全文検索（BM25）、正規表現による grep、フィルタリングなど、多様な検索手法の組み合わせが真の RAG です。

一方で、「アジェンティック・サーチ」は、ファイルシステムの grep コマンドを拡張したような概念として語られることが多いです。しかし、Kuba 氏が提唱するのは、単なるツール呼び出しを超えたものです。

アジェンティック・リトリーバル（推論と検索のループ）とは、エージェントに一連のツールを与え、文脈を段階的かつ反復的に発見・推論させるプロセスです。必要な情報が見つからない場合、エージェントは自ら「もっと深く探す必要がある」と判断し、再検索を繰り返します。目的の状態に達するまでこのループが継続され、最終的に満足できる回答に至ります。

Cursor が実証した「Merkle ツリー」による索引化戦略

アジェンティック・サーチの成功事例として、コードエディタ「Cursor」の内部戦略が紹介されました。Cursor は Turbo Puffer を利用し、コードベースのインデックス化において画期的なアプローチを採用しています。

多くのエンジニアチームでは、100 人のメンバーが同じコードベースを扱う際、毎回すべてを再チャンク化（分割）して再エンベディングするのはコストと時間の無駄です。Cursor はこの課題に対し、Merkle ツリー（暗号化ハッシュツリー）を活用しました。

チームで開かれるコードベース間の類似性を計算するために Merkle ツリーを使用し、十分に似ている場合、データはコピーとして扱います。更新されるのは変更されたファイルのみです。

この仕組みにより、チームメンバーがコードベースを開いた際、99% のケースで重複するインデックスを再作成する必要がなくなります。変更点のみを再エンコーディングして Turbo Puffer に反映させることで、コストと精度の両方を劇的に最適化しています。

検索精度が 13% 向上した実証データ

この「Merkle ツリー」を活用したセマンティック検索の導入は、Cursor の内部ベンチマークにおいて明確な成果をもたらしました。

• 回答精度の向上: モデル全体で平均して約12.5%〜13.5%の精度向上が確認されました。特に Composer 2 より前のバージョンでは、回答精度がほぼ 24% 向上しています。
• ユーザー満足度とリテンション: オンライン A/B テストでは、大規模コードベースにおけるリテンション率（継続利用率）が約2.6%向上し、不満のあるユーザーからの問い合わせが2.2%減少しました。

「数値が小さいのではないか」と思われるかもしれませんが、これはセマンティック検索がすべてのクエリで使われているわけではないためです。100 件のランダムなクエリのうち、すべてが恩恵を受けるわけではありません。しかし、実際にツールを活用したケースでは、その効果は顕著に現れています。

ジェフ・ディーンが説く「ステージド・リトリーバル」

検索の未来を語る上で外せないのが、Google のジェフ・ディーン氏の発言です。巨大なコンテキストウィンドウ（トリリオントークン規模）を一度に読み込ませるのではなく、「適切なデータ」を段階的に取得する重要性が強調されています。

「一度にトリリオン必要ではなく、正しい百万が必要なのです。」

これは、LLM のコンテキストウィンドウが巨大化しても、すべてを一度に流し込むのではなく、軽量なメカニズムで必要な情報を数百万トークン単位に絞り込み、段階的に提示する「ステージド・リトリーバル」の本質を突いています。

Cloud Code の初期バージョンではローカルベクトル DB を使用していましたが、これが機能しなかった理由もここにあります。エージェントが毎回同じコードベースに対して同じ理解を得ようとし、メタデータフィルタリングや grep 検索を繰り返すことでトークンを浪費していたのです。一方、Cursor のように事前インデックス化（Merkle ツリー活用）を行い、ランタイムでは軽量なツールで情報を取得する設計は、エージェントの速度とコスト効率を劇的に改善しました。

まとめ：検索は「ワンショット」から「反復ループ」へ

RAG は死んだのではなく、単なるベクトル検索に依存する古い形が淘汰され、より洗練されたアジェンティック・サーチへと進化を遂げているのです。開発者は今、巨大なコンテキストウィンドウへの依存から脱却し、エージェントが自ら推論して必要な情報を段階的に取得する「反復的な検索ループ」を設計する時代を迎えています。

Merkle ツリーを活用したコスト最適化や、ジェフ・ディーンが説く「正しい百万トークン」の選別。これらの知見は、大規模コードベースやエンタープライズ環境における RAG アーキテクチャの最適化において、即座に適用可能な重要な指針となるでしょう。