Azure AI Search は、データを AI に接続する、フル マネージドのクラウドホスト型サービスです。 このサービスでは、企業および Web コンテンツへのアクセスが統合されるため、エージェントと LLM はコンテキスト、チャット履歴、マルチソースシグナルを使用して、信頼性の高い、根拠のある回答を生成できます。
一般的なユース ケースには、 従来の検索 と、 エージェント検索による最新の検索拡張生成 (RAG) が含まれます。 これにより、Web サイト、アプリ、エージェント、チャットボットに検索機能を追加するかどうかにかかわらず、Azure AI Search はエンタープライズシナリオとコンシューマー シナリオの両方に適しています。
検索サービスを作成するときは、次の機能のロックを解除します。
- 2 つのエンジン: 単一要求の クラシック検索 と、並列、反復的、LLM 支援検索のための エージェント検索 。
- ローカル (インデックス付き) およびリモート コンテンツに対するフルテキスト クエリ、ベクター クエリ、ハイブリッド クエリ、マルチモーダル クエリ。
- チャンク、ベクター化、その他の方法で生コンテンツを検索できるようにする AI エンリッチメント。
- 意図の照合と結果の品質を向上させるための関連性チューニング。
- Azure のスケール、セキュリティ、監視、コンプライアンス。
- サポートされているデータ プラットフォーム、Azure OpenAI、Microsoft Foundry との Azure 統合。
Azure AI Search を使用する理由
正確でコンテキストに対応した応答を得るために、独自のエンタープライズまたはWebデータ内におけるAIエージェントおよびチャットボットを利用します。
Azure Blob Storage、Azure Cosmos DB、Microsoft SharePoint、Microsoft OneLake、およびその他のサポートされているデータ ソースからデータにアクセスします。 鮮度、待機時間、コンプライアンスのニーズに基づいて、インデックス付きアクセスまたはリモート アクセスを選択します。
チャンク、埋め込み、LLM 支援変換を実行するスキルを使用して、インデックス作成またはクエリ時にコンテンツを強化および構造化します。
フルテキスト検索とベクター検索 (ハイブリッド検索) を組み合わせて、精度と再現率のバランスを取ります。
単一のマルチモーダル パイプライン内のテキストと画像の両方を含むコンテンツをクエリします。
関連性のチューニング、ファセット ナビゲーション、フィルター (地理空間検索)、同意語マッピング、オートコンプリートなど、検索に関連した機能を容易に実装。
Microsoft Entra、Azure Private Link、ドキュメント レベルのアクセス制御、ロールベースのアクセスを通じて、エンタープライズ セキュリティ、アクセス制御、コンプライアンスを提供します。
Azure の信頼性、監視と診断 (ログ、メトリック、アラート)、自動化のための REST API または SDK ツールを使用して、運用環境でスケーリングと運用を行います。
特定の機能の詳細については、「 Azure AI Search の機能」を参照してください。
クラシック検索とは
クラシック検索は、予測可能で待ち時間の短いクエリのインデックス優先取得モデルです。 各クエリは、定義済みの 1 つの検索インデックスを対象とし、1 回の要求応答サイクルでランク付けされたドキュメントを返します。 取得中に LLM 支援の計画、イテレーション、または合成は行われません。
このアーキテクチャでは、検索サービスは、未処理のコンテンツを含むデータ ストアとクライアント アプリの間に配置されます。 アプリは、検索サービスにクエリ要求を送信し、応答を処理する役割を担います。
このアーキテクチャには、次の 2 つの主要なワークロードがあります。
インデックス作成は 、コンテンツをインデックスに読み込み、検索できるようにします。 内部的には、受信テキストはトークン化され、反転インデックスに格納されますが、受信ベクターはベクター インデックスに格納されます。 Azure AI Search では、JSON ドキュメントにのみインデックスを作成できます。 プッシュ メソッドを使用して JSON ドキュメントを直接アップロードするか、プル メソッド (インデクサーまたはロジック アプリ ワークフロー) を使用してデータを取得して JSON にシリアル化できます。
インデックス作成中に、 AI エンリッチメント を使用して、テキストのチャンク、ベクターの生成、構造とコンテンツを作成する他の変換の適用を行うことができます。 その後、Azure AI Search は、エンリッチされた出力を JSON ドキュメントにシリアル化し、インデックスに取り込みます。
注
この図では、わかりやすくするためにインデックス作成エンジンとクエリ エンジンを分離していますが、Azure AI Search では、読み取り/書き込みモードと読み取り専用モードで動作するのと同じコンポーネントです。
エージェント取得とはどのようなものでしょうか。
エージェント検索 は、複雑なエージェント間ワークフロー用に設計されたマルチクエリ パイプラインです。 各クエリは、 ナレッジ の完全なドメインを表すナレッジ ベースを対象とします。 エージェントは、何を基にグラウンディングを行うかについてナレッジ ベースを参照しますが、ナレッジ ベースは、グラウンディングを実行する方法を処理します。
ナレッジ ベースは、1 つ以上の ナレッジ ソース、クエリの計画と回答の合成のためのオプションの LLM、および取得動作を制御するパラメーターで構成されます。 各クエリでは、計画、フォーカスされたサブクエリへの分解、ナレッジ ソースからの並列取得、セマンティック再ランク付け、結果のマージが行われます。 3 本柱の応答は、エージェントの使用に最適化されています。
内部的には、エージェント検索は、マルチソースの取得を調整するコンテキスト レイヤー (ナレッジ ベース) を追加することで、従来の検索アーキテクチャに基づいています。 ナレッジ ソースはインデックスを作成することもリモートにすることもできます。インデックス付きソースはクラシック検索と同じインデックス作成エンジンとクエリ エンジンを使用し、リモート ソースはインデックス作成をバイパスし、ライブクエリを実行します。
比較方法
従来の検索とエージェント検索は、情報取得の補完的なモードです。 両方とも 、フルテキスト検索、 ベクター検索、 ハイブリッド検索、 マルチモーダル 検索をサポートします。 ただし、コンテンツの取り込みとクエリの方法は異なります。 次の表は、その主な違いをまとめたものです。
| 特徴 | クラシック検索 | エージェンティック検索 |
|---|---|---|
| コーパスの検索 | 検索インデックス | ナレッジ ソース |
| 検索先 | スキーマによって定義された 1 つのインデックス | 1 つ以上のナレッジ ソースを指すナレッジ ベース |
| クエリ プラン | プランなし、要求のみ | LLM 支援プランまたはユーザー指定プラン |
| クエリ要求 | インデックス内のドキュメントを検索する | ナレッジ ソースから取得する |
| [応答] | スキーマに基づくフラット化された検索結果 | LLM で作成された回答または生のソース データ、アクティビティ ログ、参照 |
| リージョンの制限 | いいえ | イエス |
| ステータス | 一般公開 | パブリック プレビュー |
ファースト ステップ
Azure AI Search には、Azure portal、 REST API、および .NET、 Java、 JavaScript、 Python 用の Azure SDK を使用してアクセスできます。
ポータルは、ナレッジ ベース、ナレッジ ソース、インデックス、インデクサー、スキルセット、データ ソースをプロトタイプ化するためのツールを使用して、サービス管理とコンテンツ管理に役立ちます。 REST API と SDK は、運用環境の自動化に役立ちます。
パスを選択する
作業を開始する前に、次のチェックリストを使用して重要な決定を行います。
検索エンジンを選択します。 エージェントまたはチャットボットを使用していない場合、従来の検索はほとんどのアプリのニーズを満たすことができます。LLM 統合よりもコストと複雑さが低くなります。 完全な LLM オーケストレーションなしでナレッジ ベースと複数のナレッジ ソースの利点が必要な場合は、最小限の推論努力でエージェントリトリーバルを考慮してください。
リージョンを選択します。 エージェント検索を使用している場合は、 サポートされているリージョンを選択します。 クラシック検索の場合は、必要な機能と容量を提供するリージョンを選択します。
インデックスバインドコンテンツのインジェスト方法を選択します。コンテンツがサポートされているデータ ソース内にある場合は、pull メソッドを使用してデータを取得し、JSON にシリアル化します。 サポートされているデータ ソースがない場合、またはコンテンツとインデックスをリアルタイムで同期する必要がある場合は、 プッシュメソッド が唯一のオプションです。
ベクトルが必要ですか? LLM とエージェントにはベクターは必要ありません。 類似性検索が必要な場合、またはベクターに均一化できるコンテンツがある場合にのみ使用します。 Azure AI Search では、このタスク に統合されたベクター化が提供されます 。
ユーザーベースのアクセス許可の継承が必要ですか? リモート SharePoint は、このシナリオ向けに設計されていますが、Azure Blob Storage または ADLS Gen2 のコンテンツにアタッチされているユーザーのアクセス許可を継承することもできます。 その他のすべてのシナリオでは、 セキュリティ フィルター の回避策を使用できます。
学習リソースを選択する
Microsoft では、さまざまなエンド ツー エンドの検索シナリオにまたがるクイック スタートを維持しています。
ヒント
複雑なソリューションやカスタム ソリューションに関するヘルプについては、Azure AI Search に関する深い専門知識を持つ パートナーにお問い合わせください 。