ベクトル検索は不要なのか

はじめに

タイトルの問いに対して、結論から言うとベクトル検索が完全に不要になった、ということはないです。一方、「各文書を分割→ベクトル化→並列に配置して検索」のような従来RAGのアーキテクチャだと対応できないユースケースは多々あります。
本記事では、従来のベクトル型RAGの特徴を振り返り、技術的課題を再認識するとともに、最新のRAGアーキテクチャの利点を踏まえて、これらとベクトル検索をいかに共存させるかを再検討します。

RAG（Retrieval-Augmented Generation）

RAGの定義

そもそもRAGとは、外部にあるデータを抽出し、ユーザーの入力と合わせてLLMに入力する仕組みです。コストの重い「学習」というプロセスを経ずにLLMへ知識を追加できることが最大のメリットとなります。（ベクトル検索＝RAGではない）

外部データの表現

• キーワード検索
  生のテキストからキーワード検索・パターンマッチングによって情報を検索
• ベクトル表現による検索
  事前にEmbeddingモデルでテキストをベクトル化し、コサイン類似度でセマンティックに検索
• 知識グラフを用いた検索
  テキスト情報からエンティティやリレーションを抽出・知識グラフに変換し、データベースクエリなどで検索

ベクトル型RAG

典型的なアーキテクチャ

巨大な外部テキストを「チャンク（小さな塊）」に分割してベクトル化し、データベースに保存します。ユーザーが質問を入力した際、その質問をベクトル化し、データベースから意味の近いチャンクを探し出してLLMに渡す仕組みです。

ベクトル型RAGの課題

ベクトル型RAGにおいて、前処理・チャンク分割・データの更新サイクル・検索・AIといった各RAGコンポーネントごとに汎用的に解決困難な課題が存在します。
ゆえに、使用用途・業務要件に応じて個別最適化になりがちで、得たノウハウを他方に流用しきれない場合があります。

Agentic RAG

従来のRAGがユーザーの入力に対して1回だけ前処理的に検索を行うのに対し、Agentic RAGは、AI自身が「どのようなクエリで検索するか」「何回検索を繰り返すか」を自律的に考え、ツールを使用して情報収集を行います。

Agentic RAGの利点

ユーザの質問そのものだけ検索するのではなく、AI自身が検索クエリを拡張することによって、検索ヒット率向上が見込めます。
また、1回検索して望む情報が得られなかった場合でも、結果を見て試行錯誤を繰り返し、欲しい情報が手に入るまで粘り強く探索できます。

研究事例

A-RAG[Du et al. 2026]

AIエージェントが検索をツールとして実行します。ツールとして、キーワード検索・ベクトル検索・チャンク読み出しを使用し、キーワード・文・チャンクレベルのように階層的に情報を取得して集約する仕組みが特徴です。

出典: A-RAG (arXiv:2602.03442)

最近のトレンド

ファイル検索×AIエージェント

Keyword search is all you need[Subramanian et al. 2026]

• linuxコマンドである「grep」ベースのツールを持たせたAIエージェントとベクトル型RAGを比較した論文です。
• 技術文書データセットではベクトル型RAGとほぼ同等の精度、金融文書では精度面でベクトル型RAGを上回る結果となりました。
  
  出典: Keyword search is all you need (arXiv:2602.23368)

Did Filesystem Tools Kill Vector Search?[Bertelli et al. 2026]

• LlamaIndexがハイブリッドベクトル検索RAG（従来RAG）とファイル検索型Agentic RAG（grep・glob・readベースのツール）を比較した記事となります。
• 論文ベースのデータセットで検証し、論文数本の規模の場合、速度面では従来RAGが優位ですが、精度面はファイル検索Agentic RAGが大幅優位となる結果となりました。
• 一方、大規模な実験設定（論文数百本）だと、速度面・精度面どちらとも従来RAGが優位です。

Structure-AwareなRAG

PageIndex

• ベクトル検索フリーなRAGとして有名な手法です。チャンク分割もありません。
  文書を階層的なツリー構造に変換（「目次」のようなイメージ）し、AIがその構造を辿って検索を行います。
• 金融文書ベンチマークFinanceBenchで98.7%の正解率で、SOTAを達成しました。
  
  出典: PageIndex Blog

DeepRead[Li et al. 2026]

• 本手法は、文書をMarkdown形式への変換を通して、文書の見出しや段落の階層構造を抽出し、ファイルの階層構造をAIにシステムプロンプトで付与します。
  事前に文書の各段落に独自の構造座標を割り当て、これをもとに情報を探す「Retrieve（検索）」と連続して読み進める「ReadSection（読解）」という2つのツールを使い分けることも特徴です。
• 複数の長文ドキュメントQAデータセット（Single・Multi Documentのどちらもあり）で検証し、既存のAgentic RAG手法を凌駕しました。
  
  出典: DeepRead (arXiv:2602.05014)

結論

ベクトル検索が不要ではなく使い分けが重要

トラディショナルなベクトル型RAGが不要になったのではなく、手法ごとの得意不得意が明確になったと言えます。頻繁に変更される流動性の高いデータ（ローカルのファイル環境など）にはファイル検索型Agentic RAGが適しており、大規模なデータや全体最適を求める場合にはベクトル検索など既存の手法が依然として有効です。検索速度に関しても、全文書のチャンクに対して一括でユーザクエリで類似度検索を行うベクトル検索が優位であると言えるでしょう。
RAGアーキテクチャの要所でベクトル検索を活用することが精度とスループット面で重要だと考えます。

階層的検索がキーとなる？

ここからは持論ですが、階層的検索がこれからのRAGの一つの重要な鍵を握ると考えます。

1. 従来のベクトルインデックス構造の不自然さ

人間の営みとして、各文書をファイルシステム上の階層的構造で管理し、その構造を辿ることで目的の文書を特定します。
一方、ベクトル型RAGはフォルダ構造を一旦破壊し、文書をチャンク・ベクトル化、インデックスとして並列に並べて検索します。これは人間のファイル管理の文化と乖離しており、インデックスも階層的構造の方がより自然な構造だと考えます。（親子チャンクやAgenticな階層的検索など）

2. コンテキスト管理の最適化

最近注目されているClaude Skillsの特徴的なアーキテクチャとして、Progressive Disclosure（段階的開示）というものがあります。これは従来のMCPツールとは異なり、最初にすべての情報をロードするのではなく必要な情報だけを段階的にロードすることで、コンテキストウィンドウを効率的に使用します。
RAGも同様に、情報を闇雲にコンテキストに投入するのではなく、段階的に情報をAIが取得・検索することがコンテキスト管理として適していると考えます。

余談： Gemini Embedding2

ここで余談として、「Gemini Embedding2」に触れます。
Geminiアーキテクチャを基盤とする初の完全マルチモーダル埋め込みモデルであり、テキスト・画像・動画・音声・PDFを一つの特徴空間上に埋め込むことが可能です。

モダリティ制限

• テキスト：最大8192トークン
• 画像：１リクエストあたり最大6枚
• 動画：最大120分
• 音声：最大80秒
• PDF：最大6ページ

複数モダリティ（例：画像＋テキストなど）を1ベクトルに混在させることも可能なので、ベクトル型RAGの課題であった前処理の部分でも便利ですね。（例：画像付きPDFをテキストと画像それぞれ分離して処理が不要）
ベクトル検索の利便性をブーストする画期的なモデルと言えます。