社内資料をRAGで検索しているのに「欲しい情報に限って見つけてくれない」「関係ない文書ばかり読んで的外れな回答をする」という経験はないでしょうか。AIDB が紹介する新しいRAG手法は、検索方法そのものをモデル自身に判断させるというアプローチで、この問題に正面から取り組んでいます。

従来RAGの限界：一本調子の検索

従来のRAGはシンプルです。あらかじめ決まった方法（主にベクトル類似度検索）で文書チャンクを引っ張ってきて、まとめてLLMに渡す。検索がハズれたら、その時点でもう正解にはたどり着けません。

どんなに優れたモデルを使っても、読む資料がズレていれば回答の質は上がりません。問題は「LLMの能力」ではなく「検索戦略の固定化」にあります。

3つの検索戦略を状況に応じて使い分ける

この新手法では、モデルが以下の3つの検索戦略から最適なものを選択し、必要に応じて組み合わせます。

検索戦略特徴向いているケース
キーワード検索特定の語句・コードをピンポイントで探す固有名詞、型番、コマンドなどを調べるとき
意味検索（セマンティック検索）意味的に近い文書を探す概念的な質問、言い換えが多い文書を扱うとき
チャンク全文読み対象範囲を丸ごと読み込む文脈が重要な長文、前後関係が必要なとき

重要なのは、どの順番で、どの検索を使うかをモデル自身が推論して決定する点です。固定のパイプラインではなく、質問の性質や文書の構造に合わせて動的に戦略を切り替えます。

なぜこれが機能するのか

読み込むテキスト量は同等以下

従来のRAGと比較して、読み込むテキストの量は同等かそれ以下です。にもかかわらず、回答精度は大きく向上します。これはトークン数の節約にもつながります。

モデル進化と共にスケールする構造

この手法の特筆すべき点はモデルの推論能力と性能が比例することです。モデルの推論能力が高いほど、「どの検索を、どの順番で使うか」という判断精度が上がり、RAG全体の性能が向上します。

つまり、将来より優れたモデルが登場すれば、RAGのフレームワーク自体を改修しなくても自然に性能が底上げされます。

実装への示唆

この手法を自社のRAGシステムに取り入れる場合、以下の点が設計のポイントになります。

1. 検索ツールの整備

モデルが選択できるよう、複数の検索エンドポイントを用意する必要があります。BM25（キーワード）、ベクトルDB（意味）、ドキュメント取得（全文）の3種を揃えるのが基本構成です。

2. ツール呼び出し（Function Calling）の活用

OpenAI / Anthropic / Google などの主要LLMはFunction Callingをサポートしています。検索戦略の選択をFunction Callingで実装することで、モデルが自律的に検索を制御できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

tools = [
    {
        "name": "keyword_search",
        "description": "固有名詞・型番・コマンドなど特定のキーワードで文書を検索する",
        "parameters": {"query": "string"}
    },
    {
        "name": "semantic_search",
        "description": "意味・概念の近さで関連文書を検索する",
        "parameters": {"query": "string"}
    },
    {
        "name": "read_document",
        "description": "指定した文書チャンクを全文読み込む",
        "parameters": {"document_id": "string"}
    }
]

3. 推論能力の高いモデルを選ぶ

この手法は推論能力に依存するため、コストと精度のバランスを見ながらモデル選定をする必要があります。ルーティング判断にだけ高性能モデルを使い、読み込み後の回答生成は軽量モデルで行うハイブリッド構成も検討できます。

まとめ

「AIが自分で調べ方を選ぶRAG」は、従来の固定パイプライン型RAGの限界を突破するアプローチです。

  • 検索戦略（キーワード・意味・全文）をモデル自身が選択・組み合わせる
  • 読み込むテキスト量は同等以下で回答精度は向上
  • モデルの推論能力が高いほど性能が伸び、モデル進化と共に自然にスケールする

社内機密文書を外部AIサービスに送れない環境でも、自社RAGの精度を大幅に改善できる可能性がある手法です。

参照: