Azure AI 検索でのエージェント主導の検索取得

Azure AI 検索では、エージェンティックリトリーバルは、チャットアプリやコパイロットアプリでユーザーやエージェントが行う複雑な質問に対応するために設計されたマルチクエリパイプラインです。 これは、 取得拡張生成 (RAG) パターンとエージェント間ワークフローを対象としています。

エージェント検索の機能を次に示します。

• 大規模な言語モデル (LLM) を使用して、複雑なクエリをより小さい、焦点を絞ったサブクエリに分割して、独自のコンテンツと外部コンテンツのカバレッジを向上させることができます。 サブクエリには、追加のコンテキストのチャット履歴を含めることができます。

• サブクエリを並列で実行します。 各サブクエリは、最も関連性の高い一致を昇格させるためにセマンティックに再ランク付けされます。

• 最適な結果を統合された応答に組み合わせ、LLM が基になる回答を生成するために使用できます。

• マージされたコンテンツと共にソース参照とアクティビティ ログを返すことができるので、グラウンド データのみを使用するか、LLM に渡して完全な回答を得ることができます。

この高パフォーマンス パイプラインは、チャット アプリケーションの高品質のグラウンド データまたは回答を生成するのに役立ち、複雑な質問にすばやく答える機能を備えています。

エージェント検索を使用する理由

エージェント検索では、エージェントとアプリのマネージド エクスペリエンスとカスタム エクスペリエンスの両方がサポートされます。 Microsoft Foundry ポータルでは、Foundry IQ がエージェントのマネージド ナレッジ レイヤーとして機能します。 Azure ポータル、Search Service REST API、またはサポートされているAzure SDKを使用して、カスタム エージェント検索ソリューションを構築することもできます。

エージェントやアプリに、チャットのコンテキスト、独自コンテンツ、外部ソースを活用して、より難しい質問に答えるための最も関連性の高いコンテンツを提供したい場合は、エージェント型検索を使用します。

エージェント検索では、単一クエリ パイプラインと比較して待機時間が増加しますが、1 つのクエリでは実行できないクエリの複雑さを処理します。 たとえば、次の処理を行うことができます。

• 「ビーチの近くで、空港送迎があり、ベジタリアン向けレストランまで徒歩圏内のホテルを探してください」のような、複数の要望を含む質問。

• 会話の以前のコンテキストに依存する質問。

• シノニム マップや LLM が生成した言い換えを用いてコンテンツ全体に対する網羅性を高められる、書き換えによって効果が見込めるクエリ。

• スペルミス。

アーキテクチャとワークフロー

エージェント検索プロセスは次のように機能します。

1. ワークフローの開始: アプリケーションは、クエリと会話履歴を提供する取得アクションを使用してナレッジ ベースを呼び出します。

2. クエリ計画:lowおよびmedium取得の理由付け作業では、ナレッジ ベースはクエリと会話履歴を LLM に送信し、フォーカスされたサブクエリを生成します。 minimal作業では、この手順はスキップされ、クエリはナレッジ ソースに直接発行されます。 推論の労力の既定値は low で、ナレッジベースで設定されます。

3. クエリの実行: ナレッジ ベースは、サブクエリをナレッジ ソースに送信します。 すべてのサブクエリは同時に実行され、キーワード、ベクター、またはハイブリッド検索を使用できます。 各サブクエリでは、最も関連性の高い一致を見つけるためにセマンティック再ランク付けが行われます。 参照は引用のために抽出され、保持されます。

4. 結果の合成: システムは、すべての結果を統合された応答に結合します。 マージされたコンテンツは常に返されます。 ソース参照と実行アクティビティ ログは省略可能です。

Components

エージェント検索のすべてのシナリオでは、ナレッジ ベースと少なくとも 1 つのナレッジ ソースが必要です。 その他のコンポーネントは省略可能であり、構成によって異なります。

統合要件

アプリケーションは、ナレッジ ベースを呼び出して応答を処理することで、パイプラインを駆動します。 パイプラインは、応答の生成または会話インターフェイスで直接使用するために LLM に渡すことができるグラウンド データを返します。 実装の詳細については、「 チュートリアル: エンドツーエンドのエージェント検索ソリューションを構築する」を参照してください。

可用性と価格

エージェントリトリーバルは、一部のリージョンで利用できます。 ナレッジ ソースとナレッジ ベースには、価格レベルと取得の推論作業によって異なる 上限 もあります。

請求

エージェントによる情報の取得では、次の 2 つのサービスから費用がかかります。

• Azure AI 検索 は、サブクエリの実行中に使用される取得トークンとセマンティック ランク付けに対して課金されます。 無料プラン (既定) では、毎月のトークン許容量が提供されます。 標準プランでは、無料許容量が消費された後に従量課金制の価格が有効になります。 詳細については、「エージェント検索の課金を有効または無効にする」を参照してください。

• Azure OpenAI は、LLM ベースのクエリプランニングおよび応答生成で使用される入力トークンと出力トークンに対して課金されます。 価格は常に従量課金制であり、ナレッジ ベースに割り当てるモデルに基づきます。 料金は、Azure OpenAI の請求書に表示されます。 料金については、「Azure OpenAI の価格」を参照>。

次の表では、従来の単一クエリ パイプラインとエージェント検索マルチクエリ パイプラインの課金を比較します。 クラシック パイプラインでは、課金対象コンポーネントは セマンティック ランカーです。

例: コストの見積もり

この例は、クエリの計画とクエリ実行のコスト見積もりプロセスを示すのに役立ちますが、応答合成は行いません。 コストが低くなる可能性があります。 現在の料金については、Azure AI 検索の価格とAzure OpenAI の価格を参照してください。

Azure OpenAI でクエリプランのコストを従量課金制として見積もるには、gpt-4o-miniを仮定します。

• 100 万個の入力トークンに対して 15 セント。
• 100 万個の出力トークンに対して 60 セント。
• チャット会話の平均サイズに対して 2,000 個の入力トークン。
• 平均出力プラン サイズに 350 トークン。

クエリ実行の推定課金コスト

エージェント取得トークンの数を見積もるために、まず、インデックス内の平均ドキュメントがどのように表示されるかを理解します。 たとえば、次の概数が考えられます。

• 10,000 個のチャンク。各チャンクは PDF の 1 ~ 2 段落です。
• チャンクあたり 500 トークン。
• 各サブクエリは、最大 50 チャンクを再ランク付けします。
• クエリ プランごとに平均で 3 つのサブクエリがあります。

実行価格の計算

1. プランごとに 3 つのサブクエリで 2,000 個のエージェント検索を行うとします。 これにより、合計約 6,000 個のクエリが得られます。

2. サブクエリごとに 50 個のチャンクを再ランク付けします。合計チャンク数は 300,000 個です。

3. 平均チャンクは 500 トークンであるため、再ランク付けのトークンの合計は 1 億 5,000 万です。

4. トークンあたり 0.022 という架空の価格を考えると、$3.30 は米ドルでの再ランク付けの合計コストです。

5. クエリ プランのコストに進む: 2,000 個の入力トークンに 2,000 個のエージェント検索が乗算され、合計 60 セントの入力トークンが 400 万になります。

6. 平均 350 トークンに基づいて出力コストを見積もります。 350 に 2,000 個のエージェント検索を乗算すると、合計 42 セントの合計で 700,000 個の出力トークンが取得されます。

すべてをまとめると、Azure AI 検索でのエージェント検索には約 3.30 ドル、Azure OpenAI の入力トークンには 60 セント、Azure OpenAI の出力トークンの場合は 42 セント、クエリ計画の合計は $1.02 です。 完全実行の合計コストは $4.32 です。

コストを管理するためのヒント

• 応答のアクティビティ ログを確認して、どのソースとパラメーターが使用されたクエリが発行されたかを確認します。 インデックスに対してこれらのクエリを再発行し、パブリック トークナイザーを使用してトークンを見積もり、API で報告された使用状況と比較することができます。 ただし、クエリまたは応答の正確な再構築は保証されません。 要因には、パブリック Web データや、ユーザー ID に基づくリモート SharePointナレッジ ソースなど、クエリの再現に影響を与える可能性があるナレッジ ソースの種類が含まれます。

• ナレッジ ソース (インデックス) の数を減らす。コンテンツを統合すると、ファンアウトとトークンの量が減少する可能性があります。

• クエリの計画とクエリの拡張 (反復検索) 中の LLM の使用を減らすための推論作業を減らします。

• コンテンツを整理して、最も関連性の高い情報をより少ないソースとドキュメント (たとえば、キュレーションされた概要やテーブル) で見つけることができます。

作業を開始する方法

エージェント検索ソリューションを作成するには、Azure ポータル、Microsoft Foundry (新しい) ポータル、REST API、または同等のAzure SDK パッケージを使用できます。

次の手順