grep vs. RAG：AIエージェントに適した検索戦略の選択

最近の論文で、Senらは、エージェントツールチェーンによって検索が大きく変革された世界において、grepが最良のインターフェースである可能性を主張しました。ファイルシステムツールがまもなく意味検索、ひいてはRAG全体を打倒するという考えはしばらく前から広まっていましたが、その議論は主にテキストベースのドキュメント（Markdownファイル、ソースコード）に焦点を当てており、エージェントが実際に企業環境で日常的に遭遇するもの、つまり非構造化ドキュメント（PDF、Officeファイル、画像）をほとんど考慮していません。

本記事では、grep（より一般的には語彙検索）がRAGよりも高速かつ正確である場合と、そうでない場合について考察します。

grep とその関連ツール

語彙検索は二つの前提に基づきます：第一に、テキストコーパスが存在し、通常はファイルシステム上のテキストベースのファイルとして利用可能であること。第二に、コーパスが小規模（数百から数千のドキュメント）であること。これにより、エージェントは低い信号対雑音比に悩まされることなく検索対象を選択できます。ほとんどの設定では、grepはbashツールとして公開され、エージェントがシェルにアクセスできることを前提としています。

grepは正確な部分文字列および正規表現マッチングに優れたツールです。クエリの意味表現は持ちませんが、エージェントが複数の呼び出しで異なる検索パターンを発行することで意味を操作するため問題ありません。これにより、既知のトークン、関数名、エラー文字列など、非常に具体的な情報の検索に最適です。コンテキストが重要であり、エージェントがgrepを単独で使用することはほとんどありません。検索結果のパッセージを見つけた後、周囲のファイルを読み込んでコンテキストを拡張します。

grepは50年以上の歴史があり、その使用例は至る所に存在するため、LLMが効果的に適用し、パターンや最適化を一般化できます。

それでも、語彙検索には二つの大きな制限があります：第一に、PDF、画像内のテキスト、Officeドキュメントをgrepできません。語彙検索が解放できるコーパスは純粋なプレーンテキストのみです。Markdownや他のテキスト形式の採用が進んでいるにもかかわらず、ほとんどの企業知識は非構造化ファイルに閉じ込められたままです。第二に、コーパスサイズが大きくなるとスケーラビリティが崩壊します。オリジナルのgrepは100万ファイルの小さなパターンをスキャンするのに4秒以上かかります。ripgrepのようなサブ秒の代替手段でも、ランダムで無関係なマッチからのノイズがエージェントのコンテキストウィンドウを急速に満たし、関連情報を押し出します。

これらの制限に対して、エージェント検索のスケーラビリティを向上させつつ精度とレイテンシを維持するエンタープライズグレードのアプローチが存在します。

非構造化ドキュメントの解放

現在のほとんどのCLIエージェントツールチェーンは、基本的なPDF読み取りツールと、画像を「見る」ためのマルチモーダル機能を備えています。しかし、コーディングエージェントにおけるPDF読み取りは一般に不正確でロスが大きいです。レイアウトを認識しない抽出ツールはテーブルをまとめ、画像を無視し、カラムを引き裂きます。ビジョンは推論時にコストが高く、モデルが主にテキストでトレーニングされているため、ビジョンベースの読み取りは遅く、エラーや幻覚を起こしやすいです。

非構造化ドキュメントを解放し、そのテキストコンテンツをgrepのようなダウンストリームツールに公開するには、精度とレイテンシのバランスを取るツール層が必要です。LlamaIndexはこれに対するエージェントネイティブなツールセットを提供します：

• LlamaParse MCP：プラグアンドプレイのMCPサーバーで、エージェントがLlamaParseプラットフォームを呼び出してファイルの解析、分割、分類を行うことができます。130以上のフォーマットをサポートし、テーブル、チャート、画像、複雑なレイアウト、手書きテキストに対して高い精度を持ちます（エージェントOCR駆動）。
• LiteParse：非構造化ファイルを解析するための高速で完全にローカルなツール。空間的にテキストを抽出し、レイアウトを保持し、OCR（TesseractまたはカスタムのプラグアンドプレイHTTPサーバー）を使用してコンテンツを忠実に表現します。応答時間は通常数秒。LiteParseは、エージェントがドキュメントの概要を素早く把握する必要があるローカルな軽量ワークロードに最適であり、grepの最良のパートナーです。stdoutまたは検索可能なファイルに出力できます。

LiteParseとLlamaParseは両方とも、Vercel skills CLIでインストールするか、GitHubから直接プルできるエージェントスキルを持っています。これらのスキルは、エージェントがLiteParse、LlamaParse SDK、MCPを初日から効果的に使用するために必要なコンテキストを提供します。

非構造化ドキュメントを解放したら、その知識を適切な種類のエージェント検索（語彙または意味）と組み合わせることができます。これが次のセクションのテーマです。

スケールの構築：意味検索とRAG

語彙検索はエンタープライズスケールに達するずっと前に機能しなくなります。コーパスが数千から数百万のドキュメント（内部Wiki、契約書、サポートチケット、研究レポート、設計仕様書）に成長すると、grepスタイルの検索は三つの軸で同時に劣化します：レイテンシ（百万ファイルの線形スキャンは対話型エージェントループには遅すぎる）、再現率（語彙検索は文字通りの入力しか見つけられない、「収益認識」と尋ねても「ASC 606」などに言及したドキュメントを見逃す）、信号対雑音比（百万ドキュメントでは、特定のトークンでも数千の偶然のマッチが返り、関連結果が埋もれる）。

意味検索（およびその上に構築されたRAGパターン）はこれら三つすべてを回避します。ドキュメントはレイアウト認識ツール（非構造化フォーマットにはLlamaParseなど）で一度解析され、チャンク化され、ベクトル空間に埋め込まれ、インデックス化されます。クエリ時に、エージェントの自然言語クエリも埋め込まれ、近似最近傍インデックスがトップkの意味的に関連するチャンクを数十ミリ秒で返します。コーパスが1万でも1000万でも関係ありません。

これがスケーラビリティの真の姿です：

• サブ線形検索。ANNインデックス（HNSW、IVF、ScaNN）は、コーパスが成長してもクエリ時間をほぼ一定に保ちます。100万ドキュメントのインデックスは、1万ドキュメントのインデックスと同じウォールクロック予算で結果を返します。
• 語彙に依存しない再現率。埋め込みは意味を捉えるため、「収益認識」は「ASC 606」にマッチし、エージェントが同義語を列挙する必要がありません。これにより、エージェントのリトライ回数が大幅に削減されます。
• 制限されたコンテキストコスト。トップk検索は、無制限のgrepヒットリストの代わりに、小さくランク付けされたチャンクセットをエージェントに提供します。コンテキストウィンドウはクリーンなままで、エージェントはフィルタリングではなく推論にトークンを使えます。

ハイブリッドはさらに優れています。本番のRAGシステムは意味検索と語彙検索（BM25）およびメタデータフィルターを組み合わせ、正確一致検索の精度と埋め込みの再現率の両方を得ます。

意味検索にはインデキシングパイプライン、埋め込みモデル、ベクトルストアが必要であり、検索する正確な文字列がわかっている場合はgrepほど正確ではありません。しかし、コーパスが大規模で、異質で、非構造化ドキュメントで満たされている場合、これらのコストは最初のクエリで報われます。

結論：grepだけで十分か？

grepは消えませんし、消えるべきではありません。小規模なプレーンテキストコーパス（コードベース、ドキュメントフォルダ、一握りのMarkdownノート）では、語彙検索は高速で予測可能であり、エージェントに必要な正確性を提供します。

しかし、「grepだけで十分か？」は、ほとんどのエンタープライズエージェントが実際に生きている世界にとっては間違った質問です。コーパスは数百万のドキュメントであり、そのほとんどは非構造化（PDF、スライド、スプレッドシート、スキャン）で、クエリは既知のトークンではなく自然言語で行われます。そこでは、語彙検索だけでは重要ないたるところで壁にぶつかります：フォーマットを読めず、スケールせず、語彙のギャップを埋められません。

実用的な答えはレイヤー化です。レイアウト認識ツール（LlamaParseやLiteParseなど）で非構造化ドキュメントを忠実なテキストに解析します。そのテキストを意味検索用にインデックス化し、エージェントが意味によってスケールして検索できるようにします。そして、既知のコーパスでの正確一致検索が真に適切なケースのためにgrepをツールボックスに保持し、エージェントに選択させます。

grepは優れたツールです。ただ、エージェントが必要とする唯一のツールではありません。