透明度に関する注意: Azure AI 検索

AI エンリッチメント は、Foundry Tools の機械学習モデルを、生の形式で簡単に検索できないコンテンツに適用することです。 エンリッチメントを通じて、分析と推論を使用して、以前は存在しなかった検索可能なコンテンツと構造を作成します。

AI エンリッチメントは、顧客の検索サービスと同じリージョンの Foundry Tools に接続する、Azure AI 検索 インデクサー パイプラインのオプションの拡張機能です。 エンリッチメント パイプラインには、一般的なインデクサー (インデクサー、データ ソース、インデックス) と同じコア コンポーネントと、アトミック エンリッチメント手順を指定するスキル セットがあります。 スキル セットは、 Foundry Tools API (Vision や Language など) に基づく組み込みスキル、または指定した外部コードを実行する カスタム スキル を使用して組み立てることができます。

ベクター検索は、ドキュメントとクエリがプレーン テキストではなくベクトルとしてインデックスで表される情報取得の方法です。 ベクター検索では、Azure AI 検索から外部でホストされる機械学習モデルによって、ソース入力のベクター表現が生成されます。これは、テキスト、画像、オーディオ、またはビデオ コンテンツです。 ベクター埋め込みと呼ばれるこの数学的および正規化されたコンテンツ表現は、検索シナリオの一般的な基礎となります。

すべてがベクターの場合、関連する元のコンテンツが画像とテキスト、言語など、クエリとは異なるメディアの種類にある場合でも、クエリはベクター空間で一致を見つけることができます。 検索エンジンは、インデックスをスキャンして、クエリ内のベクトルに最も類似したベクトルコンテンツを検索します。 キーワードではなく数学的ベクトル表現に一致すると、セマンティックな意味を共有するが、"car" や "auto" などのテキスト的に異なる一致を見つける可能性がはるかに高くなります。 これにより、ベクター埋め込みと類似性アルゴリズムのしくみについてより詳しく説明します。

主な用語

セマンティック ランカーは、クエリのコンテキストまたはセマンティックの意味を使用して、元のクエリの意図にセマンティックに最も近い結果を上位に昇格させる新しい関連性スコアを計算します。 最初の結果セットは、 BM25 ランク付け、 ベクター 検索、または両方を含む ハイブリッド検索 を含むキーワード検索から取得できます。 また、結果に見つかった逐語的なコンテンツを抽出して "キャプション" を作成して返し、結果内の重要なコンテンツに注意を促す "強調表示" も行います。 また、クエリに質問の特性 ("水の凍結点は何ですか") があり、結果に回答の特性を持つテキスト ("水が 0°C または 32°F でフリーズする" ) が含まれている場合は、"回答" を返すこともできます。

主な用語

クエリの書き換えでは、合成クエリが作成されます。これは、 BM25 ランク付け、 ベクター検索、または ハイブリッド検索の再現率 (使用可能なドキュメントの合計数から取得された関連ドキュメントの割合) を向上させるために、実際の顧客入力から人為的に作成または生成されるクエリです。 元のクエリは合成クエリと組み合わされ、検索エンジンからの最適な再現率が提供されます。

GenAI Prompt スキルは、Azure AI 検索のスキル カタログの一部であり、お客様はデータに基づいて AI によって生成されたコンテンツを使用して検索インデックスを強化できます。 顧客の組織独自のデータと好みを使用することで、このスキルは、特定のニーズに合わせて調整された要約、回答、または分析情報を生成するのに役立ちます。

つまり、エンド ユーザーが AI Search を使用して顧客のコンテンツを検索すると、AI によって生成されたコンテンツはより有益でコンテキストに対応した結果を提供できるため、ユーザーは探している情報を簡単に見つけることができます。

主な用語

エージェント検索は、会話型大規模言語モデル (LLM) を "クエリ プランナー" として使用する並列クエリ処理アーキテクチャです。LLM は、必要に応じて、ユーザーの会話履歴を 1 つまたは複数のフォーカスされたサブクエリに変換します。 これらのサブクエリは、Azure AI 検索 インデックスで同時に実行され、サービスによって上位の結果がマージされ、次が返されます。

• 最も関連性の高い一節 (グラウンド データ) を含む 1 つのコンテンツ文字列。
• 完全なソース ドキュメントまたはチャンクを公開する参照配列 (省略可能)。
• コストの追跡とデバッグを支援するために、すべての操作、トークン数、待機時間を一覧表示するアクティビティ配列。

主な用語

システムの動作

AI エンリッチメントを実現するために、Azure AI 検索 の複数の 組み込みスキルが Foundry Tools を活用しています。 スキルの使用を選択する際の考慮事項については、以下にリンクされている各組み込みスキルの透明性に関するメモを参照してください。

• キー フレーズ抽出スキル: 言語 - キー フレーズ抽出
• 言語検出スキル: 言語 - 言語検出
• エンティティ リンク スキル: 言語 - エンティティ リンク
• エンティティ認識スキル: 言語 - 名前付きエンティティ認識 (NER)
• PII 検出スキル: 言語 - PII 検出
• センチメント スキル: 言語 - 感情分析
• 画像分析スキル: ビジョン - 画像分析
• OCR スキル: Vision - OCR
• ドキュメント レイアウト スキル: ドキュメント インテリジェンス

各スキルのドキュメントを参照して、それぞれの機能、制限事項、パフォーマンス、評価、および統合と責任ある使用方法の詳細を確認してください。 これらのスキルを組み合わせて使用すると、複合効果につながる可能性があることに注意してください (たとえば、OCR の使用時に発生したエラーは、キー フレーズ抽出を使用するときに発生します)。

ユースケース例

ユースケースの例

Azure AI 検索はフルテキスト検索ソリューションであるため、AI エンリッチメントの目的は、非構造化コンテンツの検索ユーティリティを向上することです。 組み込みスキルでサポートされるコンテンツ エンリッチメント シナリオの例を次に示します。

• 翻訳 と 言語検出 により、多言語検索が可能になります。
• エンティティ認識 は、テキストの大きなチャンクから 人 、 場所 、 およびその他のエンティティ を抽出します。
• キー フレーズ抽出 では、重要な用語を識別して出力します。
• OCR は、バイナリ ファイル内の印刷されたテキストと手書きのテキストを認識します。
• 画像分析 では、画像の内容が記述され、説明が検索可能なテキスト フィールドとして出力されます。
• Integrated vectorization は、Azure OpenAI 埋め込みモデルを呼び出してデータをベクター化し、Azure AI 検索に埋め込みを格納して類似性検索を行うプレビュー機能です。

システムの動作

ベクター検索では、検索エンジンはインデックス内の埋め込み空間内のベクトルを検索して、クエリ ベクターに近いものを見つけます。 この手法は、 最近隣検索と呼ばれます。 これは、項目間の類似性 (距離) の度合いを定量化するのにも役立ちます。 ベクトルの類似性が高い場合は、元のデータも同様であることを示します。 Azure AI 検索でサポートされる 2 つのベクター検索アルゴリズムには、この問題に対するアプローチが異なり、待機時間、スループット、再現率、メモリなどのさまざまな特性がトレードオフされています。

最も近い "k" の真のセットを見つけるには、入力ベクトルをデータセット内のすべてのベクトルと完全に比較する必要があります。 各ベクターの類似性の計算は比較的高速ですが、大規模なデータセット間でこれらの包括的な比較を実行すると、計算コストが高く、必要な比較の数が多いため、低速になります。 また、各ベクターの次元が高いほど、各ベクターの計算が複雑になり、時間がかかります。

この課題に対処するために、近似最近傍 (ANN) 探索方法を使用して、呼び戻しの速度をトレードオフします。 これらのメソッドは、クエリ ベクターに似ている可能性が最も高い少数の候補ベクトルセットを効率的に検索し、ベクター比較の合計数を減らすことができます。 Azure AI 検索では、階層ナビゲーション可能 Small World (HNSW) アルゴリズムを使用して、高次元データ ポイントを確率論的階層グラフ構造に整理します。これにより、検索精度と計算コストの間で調整可能なトレードオフを実現しながら、高速な類似性検索が可能になります。

Azure AI 検索では、各ベクター結果の最も近い近隣とスコアを決定するための複数の類似性メトリックもサポートされています。これには、コサイン、"ユークリッド" ("l2 norm" とも呼ばれます)、"ドット積" が含まれます。コサインは、2 つのベクトル間の角度を計算します。 ユークリッドは、2つのベクトル間のユークリッド距離を計算します。これは、2つのベクトルの差のl2ノルムです。 ドット積は、ベクトルの大きさとそれらの間の角度の両方の影響を受けます。 正規化された埋め込みスペースの場合、ドット積はコサインの類似性に相当しますが、より効率的です。

ユースケース例

ユースケースの例

ベクター検索が便利で、ベクター埋め込みの生成に使用されるモデルの機能によってのみ制限されるシナリオは多数あります。 ベクター検索を使用できる一般的なユース ケースを次に示します。

• Semantic 検索: Azure OpenAI Service 埋め込みモデルなどのモデルを使用するなど、モデルを使用してテキストからセマンティック理解を抽出。
• さまざまなデータ型 (マルチモーダル) 間で検索する: 画像、テキスト、オーディオ、ビデオ、またはミックスからのコンテンツをエンコードし、それらのすべてで 1 回の検索を行います。
• 多言語検索: 多言語埋め込みモデルを使用してドキュメントを複数の言語で表し、サポートされている言語で結果を検索します。
• ハイブリッド検索: ベクター検索はフィールド レベルで実装されます。つまり、ベクター フィールドと検索可能なテキスト フィールドを含むクエリを作成できます。 クエリは並列で実行され、結果は 1 つの応答にマージされます。 セマンティックランク付けされたハイブリッド検索結果は、最適な定性的な結果を提供するために示されています。
• フィルター処理されたベクター検索: クエリには、ベクター クエリとフィルター式を含めることができます。 他のデータ型に適用されるフィルターは、他の条件に基づいてドキュメントを含めたり除外したりするのに役立ちます。
• ベクター データベース: この純粋なベクター ストアは、長期メモリまたは大規模言語モデル (LLM) の外部ナレッジ ベース用です。 たとえば、Azure AI 検索を取得拡張生成 (RAG) アプリケーションのプロンプト フローで使用する Azure Machine Learning のベクターインデックスとして使用します。

ユース ケースを選択するときの考慮事項

ベクター埋め込みを生成するために選択した特定のモデルに関連する考慮事項と懸念がある場合があります。 各モデルにはバイアスと公平性に関する独自の問題が存在する可能性があり、アプリケーションで使用する前に評価する必要があります。 Azure AI 検索では、サービスの一部としてコンテンツをベクター化するモデルは提供されません。 これらの考慮事項の例については、Azure OpenAI Service透明度に関するメモを参照してください。 他のサード パーティまたは OSS モデルには、確認すべき独自の考慮事項があります。

システムの動作

最初のレイヤー取得手順の結果をランク付けすることは、リソースを大量に消費するプロセスです。 クエリ操作の予想待ち時間内にランカーの処理を完了するには、取得エンジンからの上位 50 件の結果のみが入力としてセマンティック ランカーに送信されます。 長すぎる場合、セマンティック ランカーを実行する前に、各結果から最も関連性の高いコンテンツを抽出する集計手順に 50 件の結果が最初に送信されます。

概要作成手順では、取得したドキュメントは、最初に、異なるドキュメント入力を 1 つの長い文字列に連結する準備プロセスを経ます。 文字列が長すぎる場合は、トリミングの演習が行われ、 特にセマンティック構成に追加されたフィールドに含まれるコンテンツを保持することに重点が置かれます。 文字列が準備されると、機械読解と言語表現モデルを通じて渡され、クエリに対して最適な要約を提供する文とフレーズが決定されます。 このフェーズでは、セマンティック ランク付けステージに渡される文字列からコンテンツを抽出し、必要に応じて セマンティック キャプション または セマンティック回答を出力します。

最後のステップであるセマンティック ランク付けでは、前の手順で抽出したコンテンツの関連性をユーザーのクエリに決定し、セマンティック ランク付けスコアを 4 (関連性の高い) から 0 (無関係) まで出力します。 この手順は、クエリ テキストと要約されたテキストに基づいており、取得レイヤーの計算よりも複雑な計算が含まれます。

ユースケース例

ユースケースの例

セマンティック ランカーは、複数のシナリオで使用できます。 システムの目的のユース ケースは次のとおりです。

• 取得拡張生成 (RAG): セマンティック ランカーを使用すると、定義した関連性スコアのしきい値を満たす関連する検索結果で、生成 AI アプリケーションからの応答を取得できます。 たとえば、お客様のデータに対応する Azure OpenAI Serviceは、Azure AI 検索を使用し、Azure OpenAI モデルをお客様のデータで強化します。 このサービス内でセマンティック ランカーを使用して、Azure OpenAI モデルに提供される情報の関連性を向上させることができます。
• コンテンツ検索: セマンティック ランカーを使用すると、テキストとメタデータを分析して、データ内の関連するコンテンツを検索できます。 たとえば、learn.microsoft.com の Web サイトでは、セマンティック ランカーを使用して、Microsoft の技術ドキュメントを検索するソフトウェア開発者のための検索の関連性を向上させます。
• e コマース検索: セマンティック ランカーを使用すると、e コマース 企業は、セマンティックの関連性に基づいて関連する製品の結果を提供することで、検索エクスペリエンスを強化できます。 たとえば、オンライン小売業者はセマンティック ランカーを使用して、オンライン 買い物客に関連する検索結果を提供することで e コマース エクスペリエンスを最適化します。
• QnA: Azure AI 検索は、データベースで使用可能な情報に基づいて質問に回答することで、ユーザーに会話エクスペリエンスを提供できるようにします。 たとえば、製造元はセマンティック ランカーを使用して、チャットボットで使用できる情報を拡張できます。 エンジニアは、このチャットボットを使用して質問し、取得したドキュメント内のクエリとインスタント回答に関連する関連性の高い内部ドキュメントを取得できます。

ユース ケースを選択するときの考慮事項

革新的なソリューションやアプリケーションでセマンティック ランカーを使用することをお勧めします。 ただし、ユース ケースを選択する際の考慮事項を次に示します。

• 機密情報 : セマンティック ランカーを有効にする機械学習モデルは、個人情報や財務情報などの機密情報を含む、検索クエリで取得されたデータを処理します。 このようなユース ケースにセマンティック ランカーを実装する前に、プライバシーとセキュリティへの影響を考慮してください。
• バイアスと公平性 : セマンティック ランカーはディープ ラーニング モデルを利用します。 これらのディープ ラーニング モデルは、パブリック コンテンツを使用してトレーニングされました。 顧客データは、セマンティック ランカー モデルによってスコア付けされます。 ユース ケースを選択するときにセマンティック ランカーの出力を評価します。特に、雇用や採用など、公平性と公平性に影響を与えるユース ケースに対して評価します。
• 規制コンプライアンス: 医療や金融などの一部の業界は厳しく規制されており、AI と機械学習の使用に制限がある可能性があります。 このような業界でセマンティック ランカーを使用する前に、ソリューションが関連する規制とガイドラインに準拠していることを確認してください。

システムの動作

元のクエリは、Azure AI 検索によってホストされる fine-tuned Small Language Model (SLM) に送信されます。 このモデルは、パブリック コンテンツを使用してトレーニングされました。 SLM は、元のクエリを一連の合成クエリに変換します。 これらの合成クエリは、意味的には元のクエリの意図に近いですが、検索エンジンからの呼び戻しを改善するために別の用語セットが含まれています。

合成クエリは元のクエリと組み合わされ、検索エンジンに送信されます。 BM25 ランク付けを実行すると、合成クエリの主要な用語が元のクエリと組み合わされます。 ベクター検索を実行すると、元のクエリはベクター埋め込みステップの前に合成クエリと連結されます。

ユースケース例

ユースケースの例

クエリの書き換えは、複数のシナリオで使用できます。 クエリの書き換えには、 セマンティック ランカーを使用する必要があります。

• データとのチャット操作: クエリの書き換えにより、定義した関連性スコアのしきい値を満たす関連する検索結果で、生成型 AI アプリケーションからの応答を取得できます。 たとえば、Azure OpenAI Service On Your Data では、Azure AI 検索を使用して、Azure OpenAI モデルをデータで拡張します。 このサービス内でクエリの書き換えを使用して、Azure OpenAI モデルに提供される情報の結果の関連性を向上させることができます。
• Conversational Questions and Answers (QnA): Azure AI 検索は、データベースで使用可能な情報に基づいて質問に回答することで、ユーザーに会話エクスペリエンスを提供できるようにします。 たとえば、製造元はセマンティック ランカーを使用して、チャットボットで使用できる情報を拡張できます。 エンジニアは、このチャットボットを使用して質問し、取得したドキュメント内のクエリとインスタント回答に関連する関連性の高い内部ドキュメントを取得できます。

ユース ケースを選択するときの考慮事項

革新的なソリューションやアプリケーションでクエリの書き換えを使用することをお勧めします。 ただし、ユース ケースを選択する際の考慮事項を次に示します。

• 機密情報と PII: クエリの書き換えを可能にする微調整された SLM は、機密情報を含む可能性がある検索クエリを処理します。 このようなユース ケースに対してクエリの書き換えを実装する前に、プライバシーとセキュリティへの影響を考慮してください。
• 無意識の偏りを減らすために個人情報を編集します。 たとえば、会社の履歴書のレビュー プロセス中に、検索中に無意識の性別やその他の偏りを減らすために、候補者の名前、住所、または電話番号をブロックすることができます。
• 法的および規制上の考慮事項。 組織は、AI Search を使用する際に、潜在的な特定の法的および規制上の義務を評価する必要があります。これは、すべての業界またはシナリオでの使用に適していない可能性があります。 制限は、地域または地域の規制要件によって異なる場合があります。 さらに、AI Search は、該当するサービス利用規約および関連する行動規範で禁止されている方法で設計されておらず、使用されない場合があります。

GenAI プロンプト スキルを使用すると、お客様は、自分のデータ ソースに存在するドキュメント コンテンツ、カスタム プロンプトを、Microsoft Foundry でホストされている自分が所有する言語モデルに渡すことができます。 言語モデルは入力を処理し、エンリッチされたコンテンツを返します。これにより、元のドキュメント コンテンツと共に検索インデックスに取り込まれます。 このプロセスにより、顧客が定義した条件に基づいて、AI によって生成された概要、画像キャプション、エンティティ抽出などを使用して検索インデックスを拡張できます。

次の例は、GenAI プロンプト スキルの動作を示しています。

ゼロショット チケットの概要

目標: サポート エージェントが複数ページのメール スレッドを数秒でスキミングできるようにします。

しくみ:

• インデックス作成中、チケットの長い会話はすべて論理セグメント (初期要求、フォローアップの質問、診断ログなど) に分割されます。
• 各セグメントについて、言語モデルは"このセクションを 3 つの鮮明な文にまとめる" よう指示されます。
• 結果の要約は、取得中に生のテキストを置き換えるので、エージェントとダウンストリーム RAG パイプラインでは、凝縮されたエッセンスのみを参照します。

それが役立つ理由: 簡潔なセグメント レベルの概要により、プロンプト サイズが縮小され、応答の生成が高速化され、エージェントが顧客の主要な問題に集中するのに役立ちます。

フューショット エンティティ抽出

目標: "Product X がエラー 500 でクラッシュしたすべてのチケットを表示する" などのクエリをサポートします。

しくみ

• 完全なチケット テキストは、目的の出力形式 (製品名、エラー コード、オペレーティング システム、重大度などの主要エンティティの一覧) を示す 1 つの有効な例と共にスキルに送信されます。
• このモデルは、製品、error_code、プラットフォーム、重大度のすべての発生を抽出します。
• この構造化リストはドキュメントと共に格納され、iOS で重大度の高いクラッシュが発生した場合など、すぐに表示されるフィルターを有効にします。

それが役立つ理由: 事前計算済みのエンティティは、フリーフォームの顧客メッセージをフィルター可能なデータに変え、サポートリードがパターンを特定し、手動解析なしで修正に優先順位を付けることができます。

一度きりのチケット経路分類

目標: 各チケットを適切なキューに自動的にルーティングします。

しくみ:

• 各チケットは、5 つのサポート カテゴリ (課金、技術的な問題、アカウント アクセス、機能要求、一般的なフィードバック) と 1 つの参照例 ("チケット→課金の例" を一覧表示するプロンプトで分析されます。
• このモデルでは、上記の 5 つのサポート カテゴリに基づいて、AI Search システムに入力されるすべてのチケットに 1 つのラベルが正確に割り当てられます。
• ヘルプ デスク システムでは、このラベルを使用して、財務スペシャリストに課金クエリを送信したり、技術的なクラッシュをエンジニアに送信したりします。

これが役立つ理由: 高速で一貫性のあるラベル付けにより、誤ってルーティングされるチケットが減り、解決時間が短縮され、顧客満足度が向上します。

思考過程の解決策提案

目標: 問題を解決するための最適な次の手順をサポート エージェントに提供します。

しくみ

• チケット全体 (またはその最新の顧客メッセージ) が言語モデルに渡されます。
• ユーザー メッセージは、システム プロンプトの後にモデルに指示します。"内部的にステップ バイ ステップを考えるが、推奨される次のアクションのみを出力する" というメッセージが表示されます。
• 返されるガイダンスは、"キャッシュをクリアしてバージョン 3.2.1 を再インストールするように顧客に依頼してください" です。
• エージェントは、提案を直接コピーするか、応答する前に絞り込むことができます。

役立つ理由: エージェントは、モデルのプライベート推論チェーンなしで実用的な推奨事項を受け取り、トラブルシューティング手順を簡潔かつ関連性の高い状態に保ちながら時間を節約します。 場合によっては、サポート エージェントに不要な情報が殺到することはありません。

ユースケース例

ユースケースの例

GenAI Prompt スキルは、Azure AI 検索内のデータ エンリッチメントを強化し、ユーザーの意図と期待に沿った対応を支援します。 このスキルでは、AI によって生成されたコンテンツを検索インデックスに統合することで、より正確でコンテキストに応じて適切な検索結果を得られます。 主なアプリケーションは次のとおりです。

• より迅速な情報取得を容易にするために、長い文書の簡潔な要約を生成する:法律事務所は広範な契約を処理し、GenAIプロンプトスキルを使用して重要な条項を強調する簡単な要約を作成し、弁護士が文書全体を読まずに重要な情報を簡単に確認できるようにします。
• 検索可能性とアクセシビリティを向上させるために画像のテキスト説明を作成する: メディア会社は、画像の膨大なライブラリを管理します。 GenAI Prompt スキルを適用することで、画像ごとに説明的なキャプションを生成し、デジタル資産管理システム内での効率的な検索と編成を可能にします。
• 特定のエンティティまたは事実を特定し、カスタム条件に基づいてドキュメントから抽出する: 研究機関は、科学的な論文を分析して、化合物とその特性に関する言及を抽出します。 GenAI Prompt スキルは、この抽出を自動化し、研究者が関連するデータに迅速にアクセスできるように構造化されたデータベースを設定します。
• 組織と取得を改善するためにドキュメントを定義されたカテゴリに分類する: 保険会社は、毎日さまざまな種類のドキュメントを受け取ります。 GenAI プロンプト スキルを使用して、これらのドキュメントをクレーム、ポリシーの更新、顧客フィードバックなどのカテゴリに自動的に分類します。 これにより、ドキュメント管理プロセスが合理化され、必要に応じて特定のドキュメントを簡単に見つけることができます。

これらは一般的なアプリケーションですが、スキルは柔軟であり、顧客は独自の要件に合わせて調整されたプロンプトを定義できます。

ユース ケースを選択するときの考慮事項

コンテンツ、プロンプト、および言語モデルのデプロイは、完全に顧客が管理するリソースであることに注意してください。 Foundry では、モデルデプロイのコンテンツセーフティフィルターがサポートされており、顧客が必要に応じてこれらのフィルターを構成する責任があります。 Foundry で使用できる構成以外に、Azure AI 検索は GenAI Prompt スキル内で追加のコンテンツ セーフ フィルターを適用しません。

GenAI Prompt スキルを実装する場合は、次の点を考慮してください。

• 特に情報の信頼性に影響を与える可能性のあるプロンプト変換を適用する場合は、AI によって生成されたコンテンツを人間がレビューするためのプロセスを実装します。 Azure AI 検索の debug セッション ツールを利用して、本格的なデプロイの前にサンプル ドキュメントのプロンプトをテストします。
• システムを使用または誤用すると、個人に重大な身体的または精神的損傷が生じる可能性があるシナリオを避けます。 たとえば、患者を診断したり、薬を処方したりするシナリオでは、重大な損害を引き起こす可能性があります。 シナリオに意味のある人間のレビューと監視を組み込むことは、有害な結果のリスクを軽減するのに役立ちます。
• 生成的なユース ケースをすべて慎重に検討してください。 コンテンツ生成シナリオでは、意図しない出力が生成される可能性が高くなる可能性があり、これらのシナリオでは慎重な検討と軽減が必要です。
• 法的および規制上の考慮事項。 組織は、AI Search を使用する際に、潜在的な特定の法的および規制上の義務を評価する必要があります。これは、すべての業界またはシナリオでの使用に適していない可能性があります。 制限は、地域または地域の規制要件によって異なる場合があります。 さらに、AI Search は、該当するサービス利用規約および関連する行動規範で禁止されている方法で設計されておらず、使用されない場合があります。

システムの動作

元の会話または検索クエリは、顧客所有の Azure OpenAI モデルに送信され、クエリ計画手順が実行されます。 クエリ計画は、修正されたスペルと拡張シノニムを使用して、ユーザーの基になる意図を反映する一連の最適化されたサブクエリに会話を分割します。 Azure AI 検索、完全な検索検索システム全体ですべてのサブクエリを一度に処理します。 サブクエリは、最初にキーワード検索とベクター検索の ハイブリッドの組み合わせ によって処理されます。 キーワード検索 では、サブクエリと同様のキーワードを持つ検索インデックス内のドキュメントが検索されます。 ベクター検索は、 異なるキーワードを持つ可能性があるが、サブクエリに似た基になる意味を持つ可能性がある検索インデックス内のドキュメントを検索します。 その後、このハイブリッド検索の結果が セマンティック ランカー によって再ランク付けされ、サブクエリの意図に最も一致するドキュメントが検索されます。 次に、サービスは、ランク付けされた結果から重複をマージして削除し、最終的な応答を返す前に最大出力長などの応答制限を適用します。

ユースケース例

ユースケースの例

• カスタムチャットボットのためのデータの基盤。 チャットボットを会社の公式人事ポリシーと従業員ハンドブックにリンクして、誰かが「休暇の日数を取得しますか」と尋ねると、チャットボットは推測するのではなく、それらのドキュメントから答えを直接引き出します。
• エンタープライズ ナレッジ アシスタントを使用して、ユーザー コンテキスト、フィルター、チャット履歴を尊重します。 たとえば、従業員が特定の期間の目標について尋ねると、アシスタントは自分のロール、現在のフィルター (リージョン: 米国など)、進行中の会話 (たとえば、最後のトピックは "Q2 パイプライン") を使用して、パーソナライズされた応答を生成します。
• 1 つのキーワード クエリの再現率が低い複雑な情報シーク タスクに取り組みます。 このようなタスクには、トラブルシューティング ガイド、医学文献研究、製品比較などがあります。 たとえば、技術者が単に "デバイス エラー" を検索し、一般的な結果を受け取った場合、エージェントリトリーバーは、デバイス モデル、ソフトウェア バージョン、メンテナンス履歴、およびネットワークの状態を含む可能性がある会話履歴全体を考慮して、正確で関連する記事を表示できます。
• 取得された内容、理由、コストに関する完全な透明性を確保します。 たとえば、規制ドキュメントと過去の監査結果を要約する場合、正確なソース (たとえば、"2023 年第 2 四半期からの SEC ファイリング")、選択の根拠 ("一致したキーワード: リスク開示、派生物")、関連するコスト (トークンの使用など) を把握することが重要です。

ユース ケースを選択するときの考慮事項

• 待機時間: クエリ計画のために 2 回目の LLM 呼び出しを追加すると、要求のラウンドトリップ時間が必然的に延長されます。 高速モデルの場合でも、ピーク時のトラフィックの下で余分な遅延をベンチマークし、全体的なエクスペリエンスがユーザーにとって引き続き許容可能であることを確認する必要があります。 待機時間が重要な場合は、頻繁にクエリをキャッシュするか、より小さく高速な計画モデルを使用することを検討してください。
• コスト: 料金は、OpenAI モデル トークンと検索ランク付けトークンの 2 つのディメンションで発生します。 クエリ プランナー呼び出しは、入力トークンと出力トークンの両方に対して Azure OpenAI によって課金されますが、各サブクエリは、ランク付けする必要があるトークンに対してAzure AI 検索によって課金されます。 ランク付けトークンは、パブリック プレビューの最初のフェーズでは無料です。 ワークロードのモデル番号とランク付けトークン番号の両方を事前に見積もります。
• 機密性の高い入力: 会話履歴全体がプランナー モデルに転送されます。つまり、個人を特定できるデータやビジネス上の機密データは、すぐに信頼できる境界から離れます。 LLM を呼び出す前に、そのようなデータを削除、マスク、または編集し、データ保護体制でその軽減策を文書化します。
• リージョンとプレビューの制限: エージェンティックリトリーバルは、セマンティック ランカーが使用可能なリージョンでのみ使用できます。 個々のエージェントは、1 つの検索インデックスのみを指すことができます。 データとモデルをホストしているリージョンでエージェントの取得がサポートされていることを確認し、複数のインデックスまたは地域にまたがる必要がある場合は個別のエージェントを計画します。
• コンプライアンス: LLM 駆動型クエリ プランナーを使用して、セクター固有または地域の要件 (データ所在地、プライバシー、医療や財務の自動決定ルールなど) に準拠していることを確認します。 十分な人間の監視と管理を確保する。 計画されたタスクの確認や外部データ ソースの呼び出しなど、開発者がアクションをタイムリーに検証、確認、承認するのに役立つコントロールを含めるかどうかを検討します。
• 法的および規制上の考慮事項: Foundry Tools とソリューションを使用する場合、ユーザーは特定の法的および規制上の義務を評価する必要があります。これは、すべての業界やシナリオでの使用には適していない可能性があります。 さらに、Foundry Tools またはソリューションは、該当するサービス利用規約および関連する行動規範で禁止されている方法で設計されておらず、使用されない場合があります。

Azure AI 検索の AI エンリッチメントでは、サービスのインデクサーとデータ ソース機能を使用して Foundry Tools を呼び出してコンテンツ エンリッチメントを実行します。 このプロセスで使用されるインデクサーとデータ ソースの制限が適用されます。 これらの関連する制限事項の詳細については、 インデクサーとデータ ソースのドキュメント を参照してください。 Azure AI 検索の AI エンリッチメント パイプラインで使用される各 Foundry Tool の制限も適用されます。 これらの制限の詳細については、 各サービスの透明性に 関する注意事項を参照してください。

技術的な制限事項、運用上の要因、範囲

Azure AI 検索にアップロードされるすべてのベクターは、任意のモデルを使用してサービスから外部で生成する必要があります。 各モデルの技術的な制限と運用要因、および作成する埋め込みを最適化するか、ユース ケースに適しているかを検討するのは、お客様の責任です。 これには、コンテンツから抽出された意味の推論と、ベクター埋め込み空間の次元の両方が含まれます。

ベクター化モデルは、アプリケーションの結果のエンド ユーザー検索エクスペリエンスを定義する埋め込み空間を作成します。 モデルが目的のユース ケースとうまく一致しない場合や、生成された埋め込みの最適化が不十分な場合、モデルの機能とパフォーマンスの両方に悪影響を与える欠点がある可能性があります。

ベクター検索の多くの制限は埋め込みの生成に使用されるモデルに由来しますが、クエリ時に考慮する必要がある追加のオプションがいくつかあります。 ベクトル検索結果の関連性を決定する 2 つのアルゴリズムから選択できます: 全探索 k 近傍法 (KNN) または階層型ナビゲーション可能スモールワールド。 完全な k ニアレスト ネイバー (KNN) は、データ ポイントのすべてのペア間の距離を計算し、クエリ ポイントの正確な k 個の最近傍を見つけることで、クエリに最も似た一致に対してベクター空間全体のブルート フォース検索を実行します。 より正確ですが、このアルゴリズムは遅くなる可能性があります。 低待機時間が主な目標である場合は、階層ナビゲーション可能 Small World (HNSW) アルゴリズムの使用を検討してください。 HNSW は、高次元埋め込み空間で効率的な近似最近傍 (ANN) 検索を実行します。 これらのオプションの詳細については、 ベクター検索のドキュメント を参照してください。

システム パフォーマンスを向上するためのベスト プラクティス

• アプリケーションでサポートされる予定のさまざまなコンテンツとクエリの種類を使用して、アプリケーションのテストに時間を費やしてください。 ニーズに最適なクエリ エクスペリエンスを確認します。
• さまざまな状況での動作を理解するために、さまざまな入力コンテンツを使用してモデルのテストに時間を費やしてください。 このコンテンツには、モデルに固有のバイアスがあるかどうかを理解するために、潜在的に機密性の高い入力が含まれる場合があります。 Azure OpenAI 責任ある AI の概要では、責任を持って AI を使用する方法に関するガイダンスを提供します。
• Azure AI Content Safetyをアプリケーション アーキテクチャに追加することを検討してください。 これには、アプリケーションやサービス内の有害なユーザー生成および AI によって生成されたテキストまたは画像を検出するための API が含まれています。

ベクター検索を評価および統合して使用する

最適なパフォーマンスを確保するには、ベクター検索を使用して実装する予定のソリューションを独自に評価します。 評価プロセスに従います。(1) 一部の内部関係者を使用して結果を評価し、(2) A/B 実験を使用してベクター検索をユーザーにロールアウトし、(3) サービスが初めてエクスペリエンスにデプロイされたときに主要業績評価指標 (KPI) とメトリック監視を組み込み、(4) セマンティック ランカーの構成やインデックス定義をテストおよび調整します。 ユーザー インターフェイスの配置やビジネス プロセスなどの周囲のエクスペリエンスを含む。

Microsoftでは、返される結果の速度、スケーラビリティ、精度を測定するためにさまざまなデータセットを使用して、待機時間と再現率と関連性の両方でベクター検索を厳密に評価しました。 評価作業の主な焦点は、特定のユース ケースに適したモデルを選択し、モデルの制限と偏りを理解し、エンドツーエンドのベクター検索エクスペリエンスを厳密にテストすることです。

技術的な制限事項、運用上の要因、範囲

セマンティックの結果、キャプション、回答が正しくないように見える場合があります。 セマンティック ランカーによって使用されるモデルは、さまざまなデータ ソース (オープンソースや Microsoft Bing コーパスからの選択を含む) でトレーニングされます。 セマンティック ランカーは 、さまざまな言語 をサポートし、検索結果のコンテンツにユーザー クエリを照合しようとします。 セマンティック ランカーは、エンド ツー エンド ソリューションの全体的なコストを予測する際に考慮する必要がある追加コストのプレミアム機能でもあります。

セマンティック ランカーは、記事や説明など、意味的に豊富なコンテンツに対する関連性を向上させる可能性が最も高いです。 用語間のコンテキストや関連性を探し、クエリに基づいてより意味のある一致を優先します。 言語理解では、コンテンツ内で要約やキャプションと回答を "検索" しますが、Azure OpenAI Service モデル GPT-3.5 や GPT-4 などの生成モデルとは異なり、作成されません。 応答には、ソース ドキュメントからの逐語的なテキストのみが含まれ、検索結果ページにレンダリングして生産性の高い検索エクスペリエンスを実現できます。

最新の事前トレーニング済みモデルは、集計とランク付けに使用されます。 ユーザーが検索に期待する高速なパフォーマンスを維持するために、セマンティック集計とランク付けは、既定のスコア付けアルゴリズムでスコア付けされた上位 50 件の結果のみに適用されます。 入力は検索結果のコンテンツから派生します。 検索インデックスに戻って、クエリ応答で返されなかった検索ドキュメント内の他のフィールドにアクセスすることはできません。 入力の対象となるトークンの長さは 8,960 です。 これらの制限は、ミリ秒の応答時間を維持するために必要です。

既定のスコアリング アルゴリズムは、Bingおよび Microsoft Research からのものであり、アドオン機能としてAzure AI 検索 インフラストラクチャに統合されています。 モデルは内部的に使用され、開発者には公開されず、構成できません。 セマンティック ランカーを支援する研究および AI 投資の詳細については、「 Bing からの AI がAzure AI 検索に力を発揮する方法 (Microsoft Research Blog).を参照してください>

セマンティック ランカーには、応答、キャプション、応答内の強調表示も用意されています。 たとえば、モデルがクエリを質問として分類し、回答に 70% 自信がある場合、モデルはセマンティック回答を返します。 さらに、セマンティック キャプションは、結果内で最も関連性の高いコンテンツを提供し、そのスニペット内の最も関連性の高い単語または語句を強調表示する簡単なスニペットを提供します。

セマンティック ランカーの結果は、基になる検索インデックスのデータに基づいており、モデルでは、インデックスから取得された情報に基づいて関連性のランク付け、回答、キャプションが提供されます。 運用環境でセマンティック ランカーを使用する前に、さらにテストを行い、データセットが意図したユース ケースに対して正確かつ適切であることを確認することが重要です。 セマンティック ランカーを評価する方法の詳細と例については、 こちらのコンテンツと付録を参照してください。

システム パフォーマンス

多くの AI システムでは、多くの場合、パフォーマンスは精度に関連して定義されます。つまり、AI システムが正しい予測または出力を提供する頻度です。 大規模な自然言語モデルでは、2 人の異なるユーザーが同じ出力を見て、それがどれほど役に立っているか、関連性が高いかについて異なる意見を持つことがあります。つまり、これらのシステムのパフォーマンスをより柔軟に定義する必要があります。 ここでは、パフォーマンスは、広義には、アプリケーションがユーザーとあなたの期待どおりに実行され、有害な出力を生成しないことを意味します。

セマンティック ランカーは、パブリック コンテンツでトレーニングされました。 その結果、セマンティックの関連性は、インデックス内のドキュメントと、それに対して発行されたクエリによって異なります。 このコンテンツを意思決定に使用する場合は、独自の判断と調査を使用することが重要です。

システム パフォーマンスを向上するためのベスト プラクティス

• キーワードとハイブリッドプラスセマンティック ランカーなど、さまざまなクエリの種類でアプリケーションのテストに時間を費やしてください。 ニーズに最適なクエリ エクスペリエンスを確認します。
• 機能のドキュメントに従ってセマンティック構成を設定するには、妥当な労力を費やしてください。
• 検索インデックス内の情報の精度に自信がない場合は、セマンティック回答を信頼しないでください。
• セマンティック キャプションは、簡単なスニペットで最も関連性の高い回答を予測する一連のモデルを通じて顧客コンテンツから抽出されるため、必ずしも信頼しないでください。

セマンティック ランカーの評価

評価方法

セマンティック ランカーは、複数のデータセットに対する自動および人間による判断や、内部顧客からのフィードバックなど、内部テストを通じて評価されました。 テストには、ドキュメントを関連性のあるものとしてスコア付けするか、関連性のないドキュメントとしてスコア付けし、関連性の優先順位でドキュメントをランク付けすることで、ドキュメントのランク付けが含まれます。 同様に、キャプションと回答機能も内部テストによってランク付けされました。

評価結果

すべてのモデル更新プログラムを回帰フリーで出荷するよう努めています (つまり、更新されたモデルは、現在の運用モデルのみを改善する必要があります)。 各候補は、評価される機能に適したメトリック (たとえば、ランク付けの 正規化された割引累積ゲイン と回答の精度/再現率) を使用して、現在の運用モデルと直接比較されます。 セマンティック ランカー モデルは、さまざまなプロパティ (言語、長さ、書式設定、スタイル、トーン) を持つドキュメントを代表する幅広いトレーニング データを使用してトレーニング、チューニング、評価され、最も広範な検索シナリオをサポートします。 トレーニング データとテスト データは、次のデータから取得されます。

ドキュメントのソース:

• 学術および業界のベンチマーク
• 顧客データ (テストのみ、顧客のアクセス許可を使用して実行)
• 合成データ

クエリのソース:

• ベンチマーク クエリ セット
• 顧客が指定したクエリ セット (テストのみ、顧客のアクセス許可で実行)
• 合成クエリセット
• 人間が生成したクエリ セット

クエリとドキュメントペアのスコアリングに使われるラベルのソース:

• 学術および業界のベンチマーク ラベル
• 顧客ラベル (テストのみ、顧客の許可を得て実施)
• 合成データ ラベル
• 人間がスコア付けしたラベル

使用におけるセマンティック ランカーの評価と統合

セマンティック ランカーのパフォーマンスは、実際の使用方法と、ユーザーが使用する条件によって異なります。 ディープ ラーニング モデルを用いたセマンティック ランカー機能の関連性の品質は、検索インデックスのデータ品質に直接相関します。 たとえば、現在、モデルには、セマンティック回答の上位 8,960 個のトークンのみを考慮するトークン制限があります。 したがって、検索クエリに対するセマンティック回答が長いドキュメントの末尾 (8,960 トークン制限を超える) に見つかった場合、回答は提供されません。 キャプションにも同じ規則が適用されます。 また、セマンティック構成では、関連する検索フィールドが優先順位で一覧表示されます。 この一覧のフィールドを並べ替えて、ニーズに合わせて関連性を調整できます。

シナリオで最適なパフォーマンスを確保するには、セマンティック ランカーを使用して実装するソリューションの独自の評価を行う必要があります。 お客様は通常、評価プロセスに従う必要があります。(1) 一部の内部利害関係者を使用して結果を評価し、(2) A/B 実験を使用してセマンティック ランカーをユーザーにロールアウトし、(3) サービスが初めてエクスペリエンスにデプロイされたときに KPI とメトリックの監視を組み込み、(4) セマンティック ランカーの構成やインデックス定義をテストおよび調整します。 ユーザー インターフェイスの配置やビジネス プロセスなどの周囲のエクスペリエンスを含む。

医療、人事、教育、法的分野などの高い領域または業界でアプリケーションを開発している場合は、アプリケーションがシナリオでどれだけうまく機能するかを評価し、強力な人間による監視を実装し、ユーザーがアプリケーションの制限をどの程度よく理解しているかを評価し、関連するすべての法律に準拠します。 シナリオに基づいて、他の軽減策を検討してください。

技術的な制限事項、運用上の要因、範囲

合成クエリが正しくない、制限が多すぎる、またはコストが高すぎる場合があります。 クエリの書き換えは 、幅広い言語を サポートしており、ユーザー クエリを書き換えて呼び戻しを最大化しようとします。クエリ言語を入力として指定する必要があります。 クエリの書き換えは、セマンティック ランカー (検索の関連性を向上させるためのAzure AI 検索機能) の一部であり、追加コストのプレミアム機能です。 これは、エンド ツー エンド ソリューションの全体的な費用を予測するときに考慮する必要があります。 クエリの書き換えは、セマンティック ランカーが有効になっている場合にのみ使用できます。

運用環境 (アプリケーションのライブ バージョン) でクエリの書き換えを使用する前に、さらにテストを行い、合成クエリが目的のユース ケースに適していることを確認することが重要です。 クエリの書き換えを評価する方法の詳細と例については、 こちらのコンテンツと付録を参照してください。

システム パフォーマンス

大規模な自然言語モデルでは、2 人の異なるユーザーが同じ出力を見て、それがどれほど役に立っているか、関連性が高いかについて異なる意見を持つことがあります。つまり、これらのシステムのパフォーマンスをより柔軟に定義する必要があります。 ここでは、パフォーマンスは、広義には、アプリケーションがユーザーとあなたの期待どおりに実行され、有害な出力を生成しないことを意味します。

クエリの書き換えのパフォーマンスは、実際の用途と、ユーザーが使用する条件によって異なります。 クエリ書き換えモデルによって提供される合成クエリの品質は、元の検索クエリと直接関連付けられます。

シナリオで最適なパフォーマンスを確保するには、クエリの書き換えを使用して実装するソリューションの独自の評価を行う必要があります。 お客様は通常、次の評価プロセスに従う必要があります。

1. は、社内の利害関係者を活用して結果を評価し、
2. A/B テストを利用してクエリの書き換えをユーザーに展開するために使用し、
3. には、サービスが初めてエクスペリエンスにデプロイされたときの KPI とメトリックの監視が組み込まれています

システム パフォーマンスを向上するためのベスト プラクティス

• さまざまなクエリの種類 (フルテキスト、ベクター、ハイブリッド、またはその他の種類のクエリ) を使用して、アプリケーションの A/B テストを完了します。 ニーズに最適なクエリ エクスペリエンスを確認します。
• クエリの書き換えによって生成されるすべての合成クエリに、元のクエリの正確な意図が反映されるとは限りません。 合成クエリは、微調整された SLM によって生成されます。これは、元のクエリの意図とセマンティックに似たクエリを生成しますが、正確な意図と一致しない可能性があります。

クエリの書き換えの評価

評価方法

クエリの書き換えは、複数のデータセットに対する自動および人間による判断や、内部のお客様からのフィードバックなど、内部テストを通じて評価されました。 テストには、セマンティック ランク付けのみの結果の関連性と比較した、クエリの書き換えと組み合わせたセマンティック ランク付けの結果の関連性の評価が含まれていました。

評価結果

各候補モデルは、評価対象の機能に適したメトリックを使用して、現在デプロイされているモデルと直接比較されます。 クエリ書き換えモデルは、さまざまなプロパティ (言語、長さ、書式設定、スタイル、トーン) を持つクエリを代表する幅広いパブリック データを使用して調整および評価され、幅広い検索シナリオをサポートします。 トレーニング データとテスト データは、次のデータから取得されます。

ドキュメントのソース:

• 学術および業界のベンチマーク
• 顧客データ (テストのみ、顧客のアクセス許可を使用して実行)

クエリのソース:

• ベンチマーク クエリ セット
• 顧客が指定したクエリ セット (テストのみ、顧客のアクセス許可で実行)
• 合成クエリセット
• 人間が生成したクエリ セット

クエリとドキュメントペアのスコアリングに使われるラベルのソース:

• 学術および業界のベンチマーク ラベル
• 顧客ラベル (テストのみ、顧客の許可を得て実施)
• 合成データ ラベル
• 人間がスコア付けしたラベル

あなたの使用向けのクエリ書き換えの評価と統合

クエリの書き換えがパブリック コンテンツでトレーニングされたので、合成クエリは発行されたクエリによって異なります。 そのため、このコンテンツを意思決定に使用する場合は、独自の判断と調査を使用することが重要です。

技術的な制限事項、運用上の要因、範囲

GenAI Prompt スキルは強力な機能を提供しますが、特定の制限事項を認識することが不可欠です。

• このスキルは、Foundry 内で顧客が構成したコンテンツ フィルターに依存します。 Azure AI 検索では、このスキルに追加のコンテンツの安全性メカニズムは提供されません。
• AI によって生成されるコンテンツの品質は、プロンプトの有効性と基になる言語モデルによって異なります。 出力が目的の標準を満たしていることを確認するには、徹底的なテストが必要です。
• 複雑なプロンプトで大量のデータを処理するには、大量の計算リソースが必要であり、待機時間が発生する可能性があります。 パフォーマンスとコスト効率を維持するだけでなく、データ処理の遅延を防ぐために、リソースを賢明に計画して割り当てます。

システム パフォーマンス

システム パフォーマンスを向上するためのベスト プラクティス

GenAI プロンプト スキルのパフォーマンスを最適化するには:

• Azure AI 検索の debug セッション ツール を利用してサンプル ドキュメントのプロンプトをテストし、AI によって生成されたコンテンツが完全なデプロイ前の期待に沿っていることを確認します。
• 言語モデルを効果的にガイドするための明確で詳細なプロンプトを作成し、無関係または不正確な出力の可能性を減らします。
• 必要に応じてシステムのパフォーマンスを監視し、リソースをスケーリングして、AI 処理のコンピューティング要求を処理します。
• 出版または普及する前に、成果物を人間が監視するよう奨励します。 生成 AI では、手元のタスクに対して不快または無関係なコンテンツを生成する可能性があります。

GenAI プロンプト スキルの評価

GenAI Prompt スキルの評価とあなたの使用に向けた統合

特定のコンテキスト内で GenAI Prompt スキルの利点を最大限に活用するには、次の手順を検討します。

• スキルのアプリケーションをビジネス ニーズに合わせて調整するために、簡潔な概要の生成、主要なエンティティの抽出、説明的なメタデータの作成など、特定のエンリッチメントの目標を決定します。
• データのサブセットから始めて、スキルのパフォーマンスを評価し、必要な調整を行います。 このアプローチにより、本格的なデプロイの前に、制御された実験と絞り込みを行うことができます。
• AI によって生成されたコンテンツの品質と影響を監視するメカニズムを確立します。 改善のための領域を特定し、強化されたデータがユーザーの期待を満たしていることを確認するために、エンド ユーザーからのフィードバックを要請します。

技術的な制限事項、運用上の要因、範囲

LLM によって生成されるサブクエリが、無関係、過度に制限的、またはドライブアップ トークン コストである場合があります。 エージェント検索では GPT-4o ファミリによって処理されるすべての言語がサポートされますが、生成されるクエリ プランの品質は、ユーザー入力の明確さによって変わります。 エージェント検索はサブクエリごとにセマンティック ランカーに依存するため、インデックスでセマンティック ランカーを有効にする必要があります。 セマンティック ランカーは、Premium のトークン ベースの機能です。ランク付け料金はパブリック プレビューの初期フェーズ中に免除されますが、後で適用され、総保有コストに考慮する必要があります。

エージェント検索を運用環境に移行する前に、追加のテストを実施して、サブクエリと返された通路が目的のユース ケースに適していること、待機時間とコストがサービス レベルの目標を満たしていること、および基底データが機密または非準拠のコンテンツを公開していないことを確認します。

システム パフォーマンス

大規模な言語モデル システムと同様に、返される通路の有用性や関連性に関する判断がユーザーによって異なる場合があるため、パフォーマンスを柔軟に定義する必要があります。 エージェント検索では、エンド ツー エンド のアプリケーションが、許容できない待機時間、コスト、または有害な出力なしで、ユーザーが期待するコンテンツを提供することを意味する優れたパフォーマンスを考慮します。

エージェント検索の有効性は、多くの実際の要因によって異なります。

• プロンプト/チャット履歴の長さ
• LLM で生成されたサブクエリの数
• インデックス のサイズとスキーマ (キーワード、ベクター、ハイブリッド)
• 計画モデルの選択 (GPT-4o と GPT-4o-mini)
• セマンティック検索の構成とスコアのしきい値

システム パフォーマンスを向上するためのベスト プラクティス

• 古いチャット ターンを要約またはトリミングして、トークンの使用率を低く保ちます。
• 関連性の高いパッセージのみを返すようにランカーのしきい値を調整します
• 可能な場合はフィルターを使用する

エージェント主導の検索の評価

エージェント検索は、複数のデータセットに対する自動および人間の判断を含む内部テストによって評価されています。 テストには、セマンティック ランク付けのみの結果と比較したエージェント検索の結果の関連性の評価が含まれていました。

評価方法

プランナー プロンプト、モデル バリアント、サブクエリ数、およびランク付けしきい値によって定義された各候補エージェント取得構成は、運用環境のベースラインに対して一対一で評価されます。 複数クエリの取得シナリオ専用に選択された関連性、安全性、待機時間、コストのメトリックのスイートを適用します。 実際のユース ケース全体で信頼性を確保するために、チューニングとテストは、言語、クエリの長さ、書式設定、スタイル、会話のトーンが異なる、パブリックおよび顧客が承認したデータセットの幅広い組み合わせで実行されます。 テスト材料のソースは次のとおりです。

ドキュメントのソース:

• 学術および業界のベンチマーク
• 顧客データ (テストのみ、顧客のアクセス許可を使用して実行)
• クエリのソース:
• ベンチマーク クエリ セット
• 顧客が指定したクエリ セット (テストのみ、顧客のアクセス許可で実行)
• 合成クエリセット
• 人間が生成したクエリ セット

クエリとドキュメントペアのスコアリングに使われるラベルのソース:

• 学術および業界のベンチマーク ラベル
• 顧客ラベル (テストのみ、顧客の許可を得て実施)
• 合成データ ラベル
• 人間がスコア付けしたラベル

使用のためのエージェント検索の評価と統合

agentic-retrieval planner は主にパブリック データに対してトレーニングされるため、生成されるサブクエリの品質と関連性は、ドメインと特定のユーザー プロンプトによって異なります。 特定のコンテキスト内でエージェント検索の利点を最大限に活用するには、次の手順を検討してください。

• 出力を使用してビジネスクリティカルな意思決定を行う前に、出力を検証します。生成されたサブクエリと返されたドキュメントのサンプルを手動で検査して、ドメインの用語、精度、コンプライアンスの要件に合っていることを確認します。
• ドメイン固有の情報をプランナーに提供します。 LLM がコンテンツに一致する言語でクエリを言い換え、分解できるように、 シノニム マップと完全な会話履歴を提供することで、再現率と精度が向上します。
• フォールバックまたはガードレール ロジックを実装する: プランナーが低信頼またはスコープ外のサブクエリを生成する場合は、要求を単純なキーワードまたはベクター検索にルーティングするか、確認プロンプトをユーザーに表示して、信頼性の低い回答がダウンストリームに伝達されないようにします。