インフルエンサー「RAGは所詮 先の時代の敗北者じゃけェ」
初学者「今までRAGをやってきた僕はまるで…バカじゃないですか!!? 時間がもったいだいっ!!!!」
ってなってると聞いたので、そもそもの誤解と実態について纏めたいと思う。勢いあまってアカウント作ったまま放置してたZennを解禁した。
なんで争いは起こったのか
発端は、私が把握する限りだと、1つは「Claude Codeの初期バージョンではRAG + ローカルベクトルDBを使用していましたが、エージェント型検索の方が一般的にうまく機能することがすぐにわかりました。」という下記のAnthropicエンジニア@bcherny氏からの提言。
そして先日OpenAI創設者の1人であるKarpathy氏から投稿された、LLM Wiki(知識データをローカルに加工・集約しナレッジグラフっぽくしてAgentic Searchする方法)が、RAGより手軽であり機能しやすいことで、「RAGよりAgentic Search論」が再加熱。(ななめ読みなので間違ってたらすみません)
更にRAG不要論でよく取り沙汰されるのは、「LLMにおける昨今のコンテキストウィンドウの拡大が進めば、最初からテキスト全てLLMに渡せばRAGを使わなくても良いのでは？」という、いわゆるCAGが主流になるのでは、という議論である。
この3点の提言自体は正しいと私も思うが、RAGにまつわる用語の解釈次第では意味が間違って捉えられることも多く、2次情報の拡散によって誤解が大きくなっているので、この場を借りて整理していきたい。
各手法の背景が省略されたことによる混乱
RAGの呼称問題
技術的な解説に入る前に、諸悪の根源であるRAG呼称問題について整理してから進みたい。
RAGという言葉の問題の1つは、「ベクトル検索を用いたもの＝RAG」という認識と、「データを取得してLLMの回答に活かすアーキテクチャ＝RAG(取得方法を特定な手法に限定しない)」という認識が混在している点である。
「ベクトル検索＝RAG」というやや狭い定義が今もなお根強いのは、初出論文においてベクトル検索を用いることが前提とされていた点と、RAG全盛期にEmbeddingの性能がLLMと共に大きく向上し「万能な検索手法」という誤認が起きていたため、ベクトル検索がRAGとセットで構成される実装が多数を占めた当時の状況が影響している。
しかしながらRAGの現在の定義は、「LLMに外部のデータを参照させて回答に役立てる」という、取得場所や取得手段は限定していないやや広い定義に変化しつつある。 Microsoft/AWS/NVIDIA はいずれも「外部ソースから情報を取得して生成を強化する」趣旨でRAGを紹介しているが、ベクトル検索を使うこと(そもそも検索すら)を前提としていない。
この変化は、RAG(和訳すれば取得拡張生成)の名称自体が手段を限定していない汎用的なものである点からしても、Graph RAGに代表されるさまざまな取得手段が登場している昨今の状況からしても、割と自然な流れだろう。
もちろん初出論文を尊重するのであればベクトル検索＝RAGという面は正しいものの、LLMの用語の意味合いは時代や技術発展で徐々に変化することは珍しいことではない。「CoT」を初出論文流のfew shotを前提とするもので認識する人が現在ではほとんど居ないように、RAGも昨今の技術進展を考えると、ベクトル検索を用いないRAGも普通に存在する前提で是非を議論してほしいところではある。
Agentic Searchの呼称問題
これに加えAgentic Searchについても、その呼称が誤解を呼ぶ原因となっている。Agentic Searchは本来その名の通り、Agenticな検索手法を意味する。LLMの文脈ではその実装の実態は「Reasoningを用い、1度の検索で終わらず結果を吟味しながら、何度も検索を繰り返すアプローチ」 だ。
もちろん、検索手段はベクトル検索だろうがキーワード検索だろうが問わないし、今回のような「LLMにコードが置かれたファイルシステムを探らせるために、何度もgrep/globコマンドを吐かせて検索するアプローチ」に限定するものでもない。
のだが、上記の方法を文脈を省略してファイルシステムのgrep/globコマンドなどを使った探索を単に「Agentic Search」と呼ぶポストがバズったことで、より混乱を生んでいる。
結局何を比較したかったのか
RAGとAgentic Searchを人に例えればより分かりやすいかも知れない。調査論文執筆作業を題材にすれば、RAGは「調査論文執筆における調査、執筆の全体のフロー」、Agentic Searchは「執筆に向けた調査を1回で終わらせず、吟味しながら何度も調査すること」と言い換えてもいいだろう。そもそもレイヤーが違うし、Agenticな調査はRAGと両立するものだ。
こう考えれば「RAG vs Agentic Search」や、「Agentic SearchでRAGが不要に？」という見出しが如何に訳がわからない比較となってしまっているか想像しやすい。
「何度も調査するアプローチをすれば調査フローが不要に？」
意味が分からない。
丁寧に書くなら本来比較すべきは、「ベクトルDBにインデックスを作りLLMで生成したクエリでベクトル検索する手法」と、「ファイルシステムにデータを配置してLLMで生成したgrepコマンドなどで探る手法」 なのだが、その関連コンテキストが省略され、これらが単に「RAG」と「Agentic Search」に置き換えられたことで多くの人が混乱している。
私のようにずっとこの辺りの技術経緯を追っているヒマ人なら何を言いたいのか伝わるが、初学者にとっては「え、RAGってもう使わないの？どういうこと？どういうこと？」となり、「取り消せよ……!!!今の言葉……!!!」ってなる。
LLMに対してだけでなく多くの人間に向けた発信の際にもコンテキストの省略は良からぬ影響を及ぼすので、業界のために少しだけ熟練者は広すぎる呼称を扱うときに気をつけてほしいな…と思うのが私の想いである。
技術的に整理してみる
本題に入る。「RAG vs Agentic Search」という略称によって混沌化した議論で本質的に言及されているのは、上記を踏まえると2つのポイントがある。
- Agenticな検索アプローチの是非
- 「ベクトル検索RAG」と「ファイルシステム探索RAG」の比較
それぞれ解説していこう。
Agenticな検索アプローチ
こちらに関しては先にも述べたように、乱暴に言えば「LLMが結果を見ながら何度も検索する」だけなので、精度面だけで見れば使わない理由は無い。検索手段もベクトル検索はじめどんな取得手段とも組み合わせて使うことが可能だ。ただ留意点としては3つある。
1つは検索の長時間化。当たり前だが、複数の検索が回る可能性があるということは時間は延びる。吟味の時間含めると更に。ユーザをあまり待たせられないケースでは採用しにくいことは認識しておくべきだろう。
2つめはコスト。検索結果の吟味はそれだけ多くのテキストを読み込むことになるため、LLMの消費するコンテキスト量が増加する。
3つめは後続フェーズへの精度影響。消費したトークンをエージェントのコンテキストに残しておくとノイズとなり、後続作業には邪魔でしかなくなる。何も考えずそのまま作業継続する作りにすると思わぬ精度劣化を招くことになる。
これらを踏まえて、最近は検索用のエージェントをエンジン側に寄せたり、別途サブエージェントを立てて軽量モデルを使ってコスト節約したり、良い結果のみをメインに返送する実装や機能が増えてきている。
ベクトル検索を用いるRAGは死んだのか？
これが最も注目を浴びているところだろう。本当にベクトル検索RAGは死んだのか？
結論から言えば、死んでいない。必要な場面はたくさんある。ただし、最盛期のように何でもかんでもベクトル検索という間違った状況からは抜け出したと言えるだろう。
CAGとの比較
ファイルシステム探索RAGとの比較に入る前に、CAGの存在は無視できないので、ここで触れておこう。CAGは要は大きくなってきたコンテキストウィンドウがあるのだから、必要な情報を最初から入れておいて、キャッシュを効かせておけば動的にデータを取る必要はコスト面でも精度面でも薄くなるという至極単純な発想だ。
これはある一面では正しい。例えばリクエスト時にPDFファイルを指定してそれをオートでチャンキングしてRAGを構成する機能は現状のChatGPTやAPIにも存在しているが、LLMのコンテキスト解釈力の向上も相まって、大きさにもよるが数ファイルくらいではRAGを用いずCAGのようにコンテキストに全てテキストを置いてしまう方が精度が高いことが多くなった。
ただ気を付けたいのは、これは「フラッグシップモデルを使って数ファイルを読み込ませ軽い質問をするといった従来用途」、という注釈付きで成り立つ。小型モデルを使ったり、単純質問ではなく複数のタスクをこなすエージェント用途においては、数ファイルとは言え大きなドキュメントを持ち続けるのはコンテキストのノイズになるため、なるべく動的に取得した方が良いと言える。
動的に取得する手段はベクトル検索RAGや、今回議論に挙がっているファイルシステム探索RAGも候補になる。どの取得手段を選ぶかについてはデータやタスクの性質によって変わってくる。
ファイルシステム探索RAGとの比較
ファイルシステム探索RAGの流れは以下である。
- LLMのツールとしてファイルシステムにアクセスできるCLIなどを準備
- ユーザ入力やタスクの過程における思考で、LLMがファイルシステムの探索が必要と判断したら、探索のためのgrepやglobコマンドテキストを出力。
- 出力されたレスポンスをオーケストレータが受け取り、コマンドをCLI上で実行
- 実行結果をオーケストレータがLLMへ返送し解釈
- Agenticな検索動作にした場合、2に戻ることもある
こうして見ると当たり前だが、探索に使うのがgrepやglobってだけなので、下記のような利点がある。
- 事前にインデックスを構成せずファイルシステムに置くだけでいい
- 探索範囲が狭く、クエリが一般的なもので済む場合は精度が高い
- コマンド実行で済むため検索ステップが高速
そりゃ人間だってコードベースを探索する時にわざわざベクトル検索を使うケースは少ないし、具体的な文字列や記号が分かっていることが多いから「Coding Agentの探索でgrep,globの方が早くて手軽！」ってのは当たり前なのである。
これに加えて、そもそもベクトル検索は曖昧な意味検索に関して全文検索などと比較し優れている手法であるため、表記が揺れやすい自然言語のドキュメント群で威力を発揮しやすい。コードベースのように比較的ワードを引っ掛けやすく、命名も一定の規則性があるようなデータセットの場合にはEmbeddingするメリットが薄れるのは至極当然の話と言える。
また、単純に検索手段が単純で意図が拾えないほど、ノイズを拾う可能性も高く、その解釈のために時間も掛かる。ファイルシステム探索RAGは探索空間がある程度狭くないと破綻しやすい点にも注意だろう。
LLM Wikiに関しての考察
冒頭紹介したKarpathy氏が紹介した手法とも見てみよう。
ここで紹介しているのは、ナレッジファイルをLLMに解釈、Wiki化させてファイルとして配置、更にそれらの関連性をObsidianなどを使いながら更に磨いていくことでファイルシステム探索RAGで取得しやすいナレッジベースをオートで構築させるというアプローチだ。磨き上げで精度を良くしていくことはもちろん、大規模化すると破綻するファイルシステム探索RAGの欠点を、ナレッジベースに圧縮することでカバーしているとも言えるだろう。
文章をLLMに加工してナレッジベースを構築するのは、いわゆるGraph RAGの考え方にも近いが、これをファイルシステムで完結させられるように工夫した結果となる。Graph RAGは大規模データだとナレッジ作成時点でやたら費用が掛かるのと、その結果の良し悪しを判断しにくいという弱点があったが、小規模範囲でそれを実現し可視性をある程度保ち、更に磨かせ続けることで精度も保つというのは素晴らしい。AI Agentによる業務の自動化をするなら、厳密な正解が決まっていない業務改善Tipsなどもここに溜め続けていくと個人的に面白いんだろうなとは思った。
とはいえこちらはファイルシステム探索RAGを上手く使いこなすための1つのアイディアといった位置づけになる。検索手法の比較とは少しレイヤが違いそうだ。
まとめ
ここまでを総括すると、ベクトル検索RAGとファイルシステム探索RAGは、「対象データの性質・規模・タスクで使い分けることが大事だね」という至極当たり前な結論になる。Agent開発とは一つの手法ですべてが解決できるほど甘い話ではないということだ。(そうであってほしいとは思うけど)
そしてこの戦争が物議を醸すのは、RAG, Agentic Searchなど技術用語の背景をXのポストでは省略されてしまうことが多いことにも原因がある。
特にこれはCoding Agentユーザの数がXで多いことにも関連する。MCP不要論争も、「(Coding Agentハーネスにおいては)MCP(を使った固定関数のTool Use)は(よほど多用するベーシックなツール以外)不要！」という隠れたコンテキストが丸ごと削ぎ落されて広まっている。
LLM界隈は全方位的にサービスが拡がるため、発信者がどのコンテキストで技術を評価しているのか、この点も初学者は注意した方が良いだろう。
Discussion
素晴らしい知見です。大変参考になりました。