Agentic Search
概要
外部データ（ファイル）を探す時に、grep / glob / read を使って自律的に何度も検索をしていく処理
issei1213.icon ディレクトリ名やファイルなどは大事になりそう。
issei1213.icon 頻繁に更新されるファイルの場合は、Agentic Searchが向いていそう
ベクトル検索をする時のRAGなどは事前にデータを準備する必要があるが、Agentic Searchは直接管理しているファイルなどを参照するため事前のデータはいらない
ClaudeCodeがベクトル型のRAG検索からAgentic Searchに移行したと話題になった
RAGとの違い
RAGは一回だけで外部の情報を取得してコンテキストに含めるが、Agentic Search は複数回自ら思考して情報を取得しにいく
実際の動き
1. まずディレクトリ構造やファイル名を眺めて「設定はconfigフォルダにありそうだな」と当たりをつける
2. 怪しいファイルをGrep（テキスト検索）で探す
3. 見つけたファイルをRead（読み込み）で中身を確認する
4. 違ったら別の場所を探す
似たような言葉で Agentic RAGという言葉があるが、RAGを固定パイプラインではなくエージェントに自律的に判断・実行させる手法や考え方全般を指す
AI Agentのツールとして、RAGを提供するやり方などがある
処理内容
そもそも検索が必要か判断する
質問を分解して複数回検索する
検索結果が不十分なら、クエリを言い換えて再検索する
複数の検索先（ベクトルDB、Web、SQL DBなど）を使い分ける（ルーティング）
ベクトルDBを使用するかしないかはここでは関係ない。
AgenticRAGの選択肢の中にAgenticSearchがあるイメージ
小規模（論文5本）
速度面はハイブリッド検索が優勢
正確面はAgentic Searchが優勢
大規模（1000本の論文）
速度面（大幅）も正確面（わずかに）もRAGが優勢になった
遅延が許容できる【質問: 「遅延が機能」は「遅延が許容できる」という意味でしょうか？原文では意味が取りにくく、「遅延が許容できる場合」「遅延が問題にならない場合」など筆者の意図する表現をご確認ください】（バックグラウンド処理や非同期処理）の場合はAgentic Searchで、速度が重要な場合はハイブリッド検索がいい
ベクトル検索はエンベディング処理に時間がかかるが、 一度最適化すれば高品質にスケールすることができるので、要件次第で切り替えるといい
参考