複雑なクエリで最大40%の関連性向上：新しい agentic retrieval engine

Agentic Retrieval の理解を深めるための記事。以下まとめ。

Agentic retrieval in Azure AI Search とは

Azure AI Search の agentic retrieval の新しいAPIは、複雑なクエリやエージェントシナリオに対し、従来よりも適切な結果を返すために設計されたAPIです。

• どのように動作するか

  • クエリプランを定義し、会話履歴やAzure OpenAIモデルを活用

  • 複雑なクエリを分解・変換し、複数の検索を同時に実行

  • 結果を自動的に統合し、LLMで直接使える形式のコンテンツを返却

• 特徴

  • 呼び出し元による事前・事後処理が不要

  • 自動で最適なリトリーバルが実行される

  • そのままLLMに渡して回答生成可能

• パフォーマンス

  • 複雑なクエリでは最大+33ポイント（平均+16ポイント）の回答関連性向上

  • シンプルなクエリでは従来APIと同等

  • 会話履歴対応、スペル修正、パラフレーズなど複数変換を1回のLLM呼び出しで完結

  • GPT-4o/4.1ファミリーで高い性能

Agentic retrieval API

概要

このAPIは、インデックス化されたドキュメントから、回答生成に必要なコンテンツを自動的に抽出・統合します。

• 入力

  • コンテンツ取得を要求するクエリ

  • 会話シナリオでは会話履歴も含む

• 出力

  • LLMでそのまま使えるフォーマット済みの文字列

• 主なパラメータ

  • 最大出力サイズなど一部のみ

  • 必要なコンテンツの特定・抽出・結合は全自動

従来の検索APIとの違い

従来API

• Recall（L1）＋Reranking（L2）の2層構造

  • L1：テキスト・ベクトル・ハイブリッドで候補を取得

  • L2：セマンティックランカーで上位50件を最適化

• L1のみでは不十分。L2で大幅に関連性向上

エージェンティックリトリーバルAPI

• 上記2層構造は維持しつつ、検索前にクエリ変換処理を実施

• クエリを複数に分解・変換して、より適合度の高いドキュメントを取得

• 得られたドキュメントを重複除去し統合

• 呼び出し元での追加処理は不要、返却内容をそのままLLMへ

2つの新コンポーネント

1. クエリプランニング

• 入力クエリ→1つまたは複数の検索クエリに変換

• 会話履歴も反映

• パラフレーズやスペル修正も自動

• すべて1回のLLM呼び出しで実現

例

「what about KB4048959 and waht systmes is it compatibel with?」というクエリに対し、

• 「What security updates are related to KB4048959?」

• 「What systems is KB4048959 compatible with?」
  などに分解・スペル修正を実施（パラフレーズも生成）

2. 結果マージ

• 各検索クエリでL1/L2検索を実行

• 得られたドキュメントを重複排除し統合

• 統合結果を文字列で返却
  → 呼び出し元は追加処理なくLLMで回答生成可能

パフォーマンスベンチマーク

私たちは、エージェンティックリトリーバルAPIと従来の検索APIを、さまざまなタイプ・用途の多様なデータセットとクエリで比較テストしました。

検索APIの結果とエージェンティックAPIの効果

• 従来の検索APIは、「クラシック」な検索クエリ（一般的な検索）に対して十分に高い関連性を示します。

• 一方で、エージェンティックリトリーバルAPIは、エージェンティックなシナリオで発行される複雑なクエリに対して、関連性を大幅に向上させます。クラシックなクエリに対しては、従来APIと同等の関連性を維持します。

主な成果

• 回答関連性が +16ポイント向上

• 結果生成率が +15ポイント向上

• 10を超えるドメイン・6言語で一貫した改善を確認

• 特に、複数のインデックス文書から情報を集める必要がある、難易度の高いクエリで改善が顕著

• スペルミスや、関連する文書とクエリの単語重複率が低い場合にも大幅な改善（回答関連性で+14ポイント）

評価指標

エージェンティックなシナリオでは、クエリが非常に複雑になり、関連する回答を作成するために複数のコンテンツ断片を組み合わせる必要があります。そのため、従来の情報検索指標（例：NDCG）は、各文書単独での関連性しか評価できず、複雑クエリで求められる複数文書の統合的な関連性を正確に測定できません。

RAGトライアドによる評価

RAGやエージェンティックリトリーバルの既存研究にならい、「RAGトライアド」と呼ばれる3つの指標を用いて評価を行いました：

1. コンテンツ関連性
   取得したコンテンツがどれだけクエリに関連しているか

2. 回答関連性
   LLMで生成された回答がどれだけクエリに関連しているか

3. 根拠性
   生成された回答がどれだけ取得したコンテンツに基づいているか、もしくは幻覚（ハルシネーション）なのか

評価にはすべてGPT4oを用いました。関連性の測定には、クエリとテキストのペアをLLMに与えて「関連性スコア」を0〜100で算出させています。根拠性についても、生成回答中の情報がどれだけ取得コンテンツに含まれているかをLLMで判定し、0〜100にリスケールします。

公平な比較のための設定

• 両APIとも、同じインデックス・同じ検索設定でクエリを発行

• 回答生成用のテキスト長も統一

• 同じモデル・プロンプトで回答を生成し評価

• エージェンティックリトリーバルAPIでは、APIが自動で回答生成用文字列を算出（最大長は呼び出し元で指定可能。今回の実験では最大5000トークンを利用）

• 検索APIでは、ソート済みインデックスドキュメントリストが返却されるため、上限に達するまでリストのドキュメントを結合して1つの文字列とし、回答生成に使用

各指標の評価方法

• コンテンツ関連性
  入力クエリ、会話履歴（存在する場合）、回答生成に使ったコンテンツ（エージェンティックAPIなら出力文字列、検索APIなら連結したドキュメント）を用意し、評価用LLMに「このコンテンツはクエリにどれだけ関連するか」を判定させ、0〜100のスコアを算出。

• 回答関連性・根拠性
  取得したコンテンツを使ってLLMで回答を生成し、

  • 入力クエリと生成回答をLLMに与え「回答がどれだけ関連するか」をスコア化（0〜100）

  • 取得コンテンツと生成回答をLLMに与え「回答内容がどれだけ取得済みコンテンツに含まれるか」（根拠性）をスコア化（0〜100）
    なお、LLMが「回答が見つかりません」と返した場合、そのクエリについては根拠性の評価は行いません。

使用データセット

• Customer
  Azure顧客から許可を得て提供された文書セット（数百ページで、ベクトル化前にチャンク化が必要）

• Support
  多言語で提供される数十万件規模のパブリックサポート・ナレッジ記事（8言語利用）

• MIML（Multi-industry, Multi-language）
  10の顧客セグメント×6言語の代表的な文書セット（各セグメント約1000ドキュメント、合計60インデックス。繁体字中国語は除外し、簡体字のみ使用）

• FDA
  英語の医薬品文書コレクション

• DAYI
  中国語の医薬品文書コレクション

• Arxiv
  科学論文のコレクション

• MT-RAG
  会話シナリオ検証用の公開データセット（クエリ・会話・文書全て利用）

クエリの収集・生成方法

• クラシック検索クエリ

  • Bingで実際にユーザーが発行したクエリ

  • LLMに文書の一部を与えて自動生成（質問型、キーワード型、Web検索型、概念探索型など）。スペルミスやパラフレーズも含む

• 複雑クエリ

  • 複数インデックス文書から情報取得が必要なクエリ

    • GraphRAG

    • Multi-hop QA

    • HOTPOTQA

    • MoreHopQA

    • MultiHop-RAG

    • ComplexWebQuestions

    • MuSiQue

    • MEQA

  • 上記を文献にあるさまざまな手法をLLM用にアダプトして生成

  • 各データセット・各言語ごとに、クラシック・複雑それぞれ1000〜5000件のクエリを利用

検索構成

• L1：BM25＋OpenAI text-embedding-3-large（3072次元）のハイブリッド検索

• L2：L1で取得した上位50件をセマンティックランカーで再ランキング

この構成は、両APIで共通して使用されており、高品質な検索結果をもたらします（詳細は前回のブログ[2]参照）。

結果

コンテンツ・回答関連性（主な抜粋）

• クラシッククエリ

  • MIMLデータセットの場合、従来APIのスコアは「87.12」、エージェンティックAPIでは「87.89」となり、+0.76ポイントの改善となりました。

  • Supportデータセットでも、従来API「66.85」、新API「67.44」とわずかに向上しています（+0.58）。

• 複雑クエリ

  • MIMLデータセットでは、従来API「46.94」に対し、新APIは「57.13」と大きく改善（+11.25）。

  • Supportデータセットも「43.92」→「61.06」と、約+17ポイントの向上が見られました。

  • FDAデータセットでは特に顕著で、従来API「38.25」に対し新APIは「71.25」、+33ポイントの大幅アップです。

要点：
複雑なクエリにおいて、エージェンティックAPIは特に大きな関連性の改善を示しています。

根拠性（主な抜粋）

• クラシッククエリ

  • MIMLデータセットでは、従来APIが「83.58」、新APIが「83.52」とほぼ同等の値（-0.06の微差）。

• 複雑クエリ

  • MIMLデータセットの場合、従来API「72.82」に対し、新APIは「73.49」と、+0.67ポイントの向上。

要点：
根拠性については、両APIで大きな差はなく、新APIも十分高いレベルを維持しています。

回答生成可能率

• クラシッククエリ

  • MIMLデータセットで、従来APIは「90.37%」、新APIは「91.18%」と微増（+0.81）。

• 複雑クエリ

  • MIMLでは「54.49%」→「63.96%」と約9ポイント増加。

  • FDAデータセットでは「45.58%」→「76.08%」で+30.5ポイントの大幅向上。

要点：
複雑な問いでは、エージェンティックAPIによって回答生成できる割合が大幅に増加しました。

従来APIで回答不能なクエリに対し、エージェンティックAPIのみで回答生成できた場合の指標

• クラシッククエリ（MIML）

  • 回答関連性：82.85

  • コンテンツ関連性：67.60

  • 根拠性：76.49

• 複雑クエリ（MIML）

  • 回答関連性：84.36

  • コンテンツ関連性：53.98

  • 根拠性：70.25

要点：
従来APIでは回答不能だったクエリも、新APIでは高い関連性・根拠性で回答生成が可能です。

モデルごとの比較（抜粋）

• クラシッククエリ（MIML）

  • 各モデル（GPT4o, GPT4o-mini, GPT4.1, GPT4.1-mini, GPT4.1-nano）で、新APIのスコアは86〜88ポイントとほぼ同等の高い水準。

• 複雑クエリ（MIML）

  • 各モデルで新APIのスコアは54〜59ポイント。GPT4.1-nanoのみやや劣るが、他は大きな差はなし。

要点：
どのモデルを使っても、エージェンティックAPIによる関連性の向上が確認できます。

複雑クエリタイプ別 回答関連性（抜粋）

エージェンティックAPIは、さまざまなクエリタイプで回答関連性を向上させました。

• Aggregation（集約）

  • MIML：従来68.57→新API72.17（+3.60）

  • Support：従来48.36→新API68.44（+20.08）

• Analytical（分析）

  • MIML：従来35.88→新API39.38（+3.50）

  • Support：従来15.79→新API42.11（+26.32）

• Comparison（比較）

  • MIML：従来39.33→新API57.86（+18.53）

  • Support：従来38.24→新API58.14（+19.90）

• Compound（複合）

  • MIML：従来47.61→新API62.56（+14.94）

  • Support：従来41.86→新API68.02（+26.16）

要点：
特に分析・比較・複合的な複雑クエリで新APIの効果が際立ちます。

言語別パフォーマンス（抜粋）

エージェンティックAPIは多言語環境でも高いパフォーマンスを発揮しています。

• ドイツ語

  • 複雑クエリ（MIML）：従来50.99→新API58.78（+7.79）

  • クラシッククエリ（Support）：従来78.28→新API78.91（+0.63）

• 英語

  • 複雑クエリ（MIML）：従来42.75→新API60.50（+17.75）

  • クラシッククエリ（Support）：従来77.93→新API78.07（+0.14）

• 日本語

  • 複雑クエリ（MIML）：従来45.24→新API46.85（+1.61）

  • クラシッククエリ（Support）：従来57.33→新API56.89（-0.43）

要点：
英語・中国語・ドイツ語などでは複雑クエリで顕著な改善が見られました。日本語でも改善は小さいですが、全体として新APIの利点が多言語で確認できます。

エージェンティックリトリーバルAPIを始めるには

エージェンティックリトリーバルAPIは現在、一部リージョンでパブリックプレビュー中です。詳細については公式ドキュメント等でご確認ください。

Resources

• [1] Azure AI Search: Outperforming vector search with hybrid retrieval and reranking | Microsoft Community Hub

• [2] Raising the bar for RAG excellence: introducing generative query rewriting and new ranking model

• [3] ⟁ RAG Triad - 🦑 TruLens

• [4] Building and Evaluating Advanced RAG Applications - DeepLearning.AI

• [5] Using the RAG Triad for RAG evaluation | DeepEval - The Open-Source LLM Evaluation Framework

Appendix

複雑クエリのタイプ（例とともに）

• Aggregation（集約型）

  • リストやまとめ・要約を求める

  • 例：「各リージョンの平均応答時間は？」

• Analytical（分析型）

  • 深い分析や解釈が必要

  • 例：「SNSがメンタルヘルスに与える影響を分析せよ」

• Comparison（比較型）

  • 属性やエンティティ間の比較や関係

  • 例：「プランAとBの料金比較」

• Compound（複合型）

  • 複数の話題や質問を含む

  • 例：「Aは可能か？Bの場合は？」

• Complex（複雑型）

  • 複数ドキュメントの統合が必要

  • 例：「Azure Searchインデックスのセットアップ方法」

• Contextual（文脈型）

  • 背景や文脈理解が求められる

  • 例：「冷戦時のベルリンの壁の意義」

• Conversational（会話型）

  • 会話文・依頼文の形

  • 例：「'Your account is blocked...'エラーの対処方法は？」

• Exploratory（探索型）

  • 抽象的・複数文からなる説明が必要

  • 例：「なぜセマンティックサーチを使うべきか？」

• Factual（事実型）

  • 明確な単一答

  • 例：「フランスの首都は？」

• Filters（フィルター型）

  • 条件指定で範囲を絞る

  • 例：「MSFT 2025年第2四半期の売上」

• Index Interrogation（インデックス全体調査型）

  • インデックス全体への問い

  • 例：「利用可能なポリシーは？」

• Misspellings（スペルミス型）

  • クエリ中にスペルミスを含む

  • 例：「samantically r4nkedされたドキュメント数は？」

• Range（範囲指定型）

  • データ範囲や条件で指定

  • 例：「1単位あたり1000ドル未満のウィジェット」

• Snippet（スニペット型）

  • ドキュメントの一部文字列に一致する内容

  • 例：「Back your generative AI apps...」

• Terse（短縮型）

  • シンプルな検索エンジンクエリ

  • 例：「Best retrieval concept queries」