「ベクトルDB不要」でRAG精度を上げるCorpus2Skill — 文書を階層的スキルに変換してエージェントがナビゲートする新手法
RAGの長年の課題である「回答の網羅性の欠如」を、ベクトルDBを使わずに解決しようとする論文が登場した。2026年4月16日にarXivに公開された論文「Don’t Retrieve, Navigate」は、Corpus2Skill という新手法を提案している。文書コーパスを階層的スキルディレクトリへ事前変換し、LLMエージェントがナビゲートして回答を構築するアプローチだ。 従来のRAGが抱える課題 RAG(Retrieval-Augmented Generation)はこの数年で大きく進化し、多くの問題が解決されてきた。しかし「AIの回答が網羅的でない」という問題は依然として未解決のままだ。 従来のベクトル検索ベースのRAGでは、クエリに類似したチャンクをいくつか取得して回答を生成する。この方式の弱点は以下の通りだ。 クエリ表現に引きずられ、関連する別の観点の文書を見落とす チャンク間の文脈的なつながりが断ち切られる 広範なトピックをカバーする質問への回答が部分的になりがち Corpus2Skillのアプローチ:「検索するな、ナビゲートせよ」 Corpus2Skillは発想を根本から変える。ベクトル検索で文書を「取ってくる」のではなく、人間が目次や索引を辿るように、エージェントがコーパスの階層構造を「ナビゲートする」。 オフラインのコンパイルパイプライン まず事前処理として、文書コーパスを階層的スキルディレクトリへ変換する。 反復クラスタリング — 全文書をk-meansなどでグループ化する LLM生成サマリー — 各クラスタの内容をLLMが要約する 階層化 — クラスタをさらに上位概念でまとめ、ピラミッド構造を構築する スキルファイルツリーの実体化 — 結果を SKILL.md / INDEX.md の形式でファイルシステムに保存する この処理はオフラインで行われるため、推論時の遅延には影響しない。 推論時のナビゲーション 質問が来たとき、LLMエージェントは次の手順で回答を構築する。 コーパス全体の俯瞰図(ルートサマリー)を受け取る 質問に関連する上位ブランチを選択し、段階的に下位サマリーへ降下する 目的のノードに到達したら、文書IDを使って完全な文書を取得する 必要に応じてバックトラックし、別のブランチも探索する この探索パスが明示的に推論されるため、なぜその文書が取得されたかを追跡できるという副次的なメリットもある。 ベクトルDBが不要になる理由 従来のRAGではベクトルDB(Pinecone, Weaviate, Chromaなど)が必須だった。Corpus2Skillでは、スキルファイルツリーがその役割を置き換える。 項目 従来のRAG Corpus2Skill インデックス形式 ベクトルDB 階層ファイルツリー 検索方式 類似度検索 エージェントによるナビゲーション インフラ依存 ベクトルDBが必要 ファイルシステムのみ スケーラビリティ O(N) O(log N) 探索パスの透明性 低い 高い(明示的に推論) 文書数が10万件でも階層深度はO(log N)に収まるため、大規模コーパスへのスケーラビリティが高い点も特長だ。 実験結果 WixQAベンチマーク Wix社の企業向け顧客サポートを対象とするWixQAベンチマークで評価した。比較対象は以下のベースラインだ。 Dense Retrieval(密集検索): 従来のベクトル検索RAG RAPTOR: 階層的サマリーを使った検索手法 Agent RAG: エージェントが検索を制御する手法 Corpus2Skillは全品質指標でこれらすべてを上回った。 ...