Azure AI Search についてよく寄せられる質問

Azure AI Search は、フル テキストおよびベクトル検索シナリオ向けに専用の検索エンジンと検索可能なコンテンツの永続的なストレージを提供します。 また、より多くのテキストと構造を生コンテンツから抽出し、ベクトル検索のためにコンテンツをチャンク化およびベクトル化するための、省略可能な統合 AI も含まれています。

プライマリ ワークフローは、インデックスの作成、読み込み、クエリです。 ポータルはほとんどのタスクに使用できますが、Azure AI Search はプログラムで使用し、クライアント コードから要求を処理することを目的としています。 プログラムによるサポートは、REST API と .NET、Python、Java、JavaScript SDK for Azure のクライアント ライブラリを通じて提供されます。

Azure Search は、コア操作でのコグニティブ スキルと AI 処理の利用拡大 (任意) を反映するために、2019 年 10 月に Azure Cognitive Search に名前が変更されました。 2023 年 10 月、Azure Cognitive Search は、Azure AI サービスに合わせて Azure AI Search に名前が変更されました。

トークン化に使われる既定のアナライザーは標準の Lucene であり、言語に依存しません。 それ以外の場合、言語サポートは、受信 (インデックス作成) と送信 (クエリ) コンテンツに言語ルールを適用する言語アナライザーによって表現されます。 スペル チェックなどの一部の機能は、言語のサブセットに制限されています。

クライアント コードでは、Azure SDK クライアント ライブラリまたは REST API を呼び出して検索インデックスに接続し、クエリを作成し、応答を処理する必要があります。 インデックスをビルドして更新するコードを記述したり、インデクサーをプログラムやスクリプトで実行したりすることもできます。

必ずしもそうではありません。 REST API は常に、プレビュー API バージョンで新機能を実装する最初の機能です。 Azure SDK のクライアント ライブラリは、一定期間内で新しい機能が選択されますが、独自のスケジュールでリリースされます。

REST API は最新のフィーチャーが最初に用意されますが、Azure SDK は、より多くのコーディングがサポートされているので、必要なフィーチャーが利用できない場合を除き、REST よりも推奨されます。

検索サービスを一時停止することはできません。 Azure AI Search では、サービスの作成時にコンピューティング リソースが割り当てられます。 そのリソースを必要に応じて解放し、再請求することはできません。

サービス レベル、名前、リージョンは、サービスの有効期間中は固定されます。

リソースを移動する前にチェックリストする に従い、各ステップが完了していることを確認する限り、ダウンタイムは発生しません。

検索インデックスを設定するテキストのコンテンツとトークンを取り込み、解析し、格納することを指します。 インデックス作成により、情報取得をサポートする逆インデックスやその他の物理的なデータ構造が作成されます。

スキーマにベクター フィールドが含まれている場合は、ベクトル インデックスが作成されます。

インデックスのポーティングはネイティブでサポートされません。 検索インデックスは、ダウンストリーム データ構造と見なされ、運用データを収集する他のデータ ソースからのコンテンツを受け入れます。 そのため、インデックスのバックアップと復元の組み込みサポートはありません。インデックスを削除した場合、またはインデックスを移動する場合は、ソース データからインデックスをリビルドすると予想されるためです。

ただし、検索サービス間でインデックスを移動する場合は、この Azure AI Search .NET サンプル リポジトリにある index-backup-restore サンプル コードを試すことができます。 バックアップと復元の Python バージョンもあります。

いいえ。Azure AI Search インデックスまたはサービスを削除した場合、復旧できません。 検索サービスを削除すると、サービス内のすべてのインデックスが完全に削除されます。

Azure SQL Database に対して検索インデクサーを使用している場合、インデックスを最初から構築するときに、データ ソースとしてプライマリまたはセカンダリのレプリカの使用に制限はありません。 ただし、(レコードの変更に基づく) 増分更新によるインデックスの更新には、プライマリ レプリカが必要です。 この要件は SQL Database に由来するものです。SQL Database は変更追跡をプライマリ レプリカでのみ保証しています。 インデックス更新ワークロードにセカンダリ レプリカを使用しようとすると、すべてのデータが取得される保証はありません。

ベクトル検索は、ベクトル表現を比較して最も似たドキュメントを検索する手法です。 ベクトル表現の目的は、項目の本質的な特性を数値形式でキャプチャすることであるため、キーワードまたはタグに基づいて明示的な一致がない場合でも、ベクトル クエリで類似のコンテンツを識別できます。 ユーザーが検索を実行すると、クエリがベクトル表現にまとめられ、ベクトル検索エンジンにより最も類似したドキュメントが識別されます。 大規模なデータベースの効率を向上させるために、ベクトル検索では、多くの場合、クエリ ベクトルの近似ニアレストネイバーが提供されます。 Azure AI Search のベクトル オファリングの詳細については、「ベクトル検索の概要」を参照してください。

Azure AI Search では、ベクトル インデックス作成と取得がサポートされています。 プレビュー ライブラリとベータ ライブラリを使用すると、クエリ文字列とコンテンツをベクトル化できます。

スタンドアロン ベクトル検索では、まず埋め込みモデルを使用して、埋め込み空間内のベクター表現にコンテンツを変換します。 その後、ドキュメント ペイロード内のこれらのベクトルをインデックス作成用の検索インデックスに提供できます。 検索要求を処理するには、インデックス作成と同じ DNN を使用して検索クエリをベクトル表現に変換し、ベクトル検索で最も類似したベクトルを検索し、対応するドキュメントを返します。

Azure AI Search では、テキストやその他の種類のコンテンツと共に、ドキュメント内のフィールドとしてベクトル データにインデックスを付けることができます。 ベクトル フィールドのデータ型は Collection(Edm.Single) です。

ベクトル クエリは、スタンドアロンで、または同じ検索要求の用語のクエリやフィルターなどの他のクエリの種類と組み合わせて発行することができます。

組み込みの統合ベクター化は現在、パブリック プレビュー段階になりました。

既存のサービスのほとんどではベクトル検索がサポートされています。 ベクトル検索をサポートするパッケージや API を使用していて、インデックスの作成に失敗した場合、基になる検索サービスはベクトル検索をサポートしていないため、新しいサービスを作成する必要があります。 これは、2019 年 1 月 1 日より前に作成されたサービスのごく一部で発生する可能性があります。

検索サービスでベクトル検索がサポートされている場合、既存と新規の両方のインデックスで、ベクトル フィールドに対応できます。

Microsoft では新しい検索サービスの改善されたベクトル インデックス サイズの制限を世界全域にロールアウトしますが、特定のリージョンでは引き続きインフラストラクチャ容量を構築します。 サポートされているリージョンで作成された新しい検索サービスでは、ベクトル インデックス サイズの制限の増加が見られます。 残念ながら、既存のサービスを新しい制限に移行することはできません。

インデックスでベクトル検索を有効にするには、次の手順に従います:

• フィールド コレクションに 1 つ以上のベクトル フィールドを追加します。

• ベクトル検索フィールドで使用される構成を指定するインデックス スキーマに "vectorSearch" セクションを追加します。これには、HNSW など、使用される近似ニアレストネイバー アルゴリズムのパラメーターが含まれます。

• 2023-11-01 または Azure SDK を使用して、インデックスの作成または更新、ドキュメントの読み込み、クエリの発行を行います。

クエリは、検索サービス上でホストされている 1 つの検索インデックスに対して実行されます。 複数のインデックスを結合して 2 つ以上のインデックス内のコンテンツを検索することはできませんが、複数の検索サービスで同名のインデックスに対してクエリを実行することはできます。

よくあるケースは、クエリの型ごとにサポートされる検索ビヘイビアーと言語分析のレベルが異なることを把握していない場合です。 主要なワークロードである全文検索には、用語を原形に分解する言語分析フェーズが含まれています。 トークン化された用語は、より多くの数の変形と一致するため、このようなクエリ分析はより広い網を一致候補にかけます。

ただし、ワイルドカード、あいまいクエリ、正規表現クエリは、通常の用語または語句クエリのように分析されず、クエリが検索インデックス内の分析されたワードフォームと一致しない場合、リコールが不適切になる可能性があります。 クエリの解析と分析について詳しくは、クエリのアーキテクチャに関する記事をご覧ください。

ほとんどのワイルドカード検索クエリ (プレフィックス、あいまい、正規表現など) は、検索インデックス内の一致する用語を使用して内部で再作成されます。 この追加の処理により、待ち時間が増えます。 さらに、a* などの広範な検索クエリでは、多くの用語で書き換えられる可能性が高いと、低速になる可能性があります。 ワイルドカード検索のパフォーマンスを向上させるには、カスタム アナライザーの定義を検討してください。

いいえ。クエリは常に単一のインデックスが対象です。

検索スコアは、一致する用語の統計プロパティに基づいて、フルテキスト検索クエリに対して生成され、結果セットで上位から下位に順序付けされます。 フル テキスト検索ではないクエリの型 (ワイルドカード、プレフィックス、正規表現) は、関連性スコアで順位付けされません。 この動作は仕様です。 定数のスコアによって、ランクには影響を与えずに、クエリ拡張によって見つかった一致を結果に反映することができます。

たとえば、ワイルドカード検索に「tour*」と入力すると、「tours」、「tourettes」、「tourmaline」との一致が生成されます。 こうした結果の性質上、用語の相対的な重みを適切に推測することができません。 そのため、ワイルドカード、プレフィックス、正規表現の種類のクエリでは、結果のスコア付けを行う際に、語句の出現頻度が無視されます。 予期しない一致に対するバイアスを回避するために、部分的な入力に基づく検索結果には一定のスコアが与えられます。

サービスがデプロイされている場所にデータが保存されます。 Azure AI Search では、顧客データはデプロイ リージョンの外部には保存されません。

はい。Azure AI サービスに基づいて組み込みのスキルを使用すると、インデクサーは内部ネットワーク経由で Azure AI サービスに要求を送信します。 カスタム スキルを追加すると、インデクサーはパブリック ネットワーク経由でカスタム スキルで指定された URI にコンテンツを送信します。

そうとも限りません。 通常、アプリケーションを実行する権限を持つユーザーには、すべての検索結果を表示する権限も与えられます。 Azure AI Search では、行レベルまたはドキュメント レベルのアクセス許可は組み込みサポートされていませんが、回避策として セキュリティ フィルター を実装できます。

はい。コンテンツに対するデータ プレーン操作へのロールベースの承認を使用できます。

クライアントとポータルへのアクセスを許可するネットワーク例外を作成する場合は、ネットワークで保護された検索サービスでAzure portalを使用できます。 詳細については、 IP ファイアウォール経由での接続 または プライベート エンドポイント経由の接続に関する説明を参照してください。

次のステップ

こちらでご質問の回答が見つからない場合は、次のソースでさらに質問と回答を参照できます。

Stack Overflow: Azure AI Search
Azure AI Search でのフル テキスト検索のしくみ
Azure AI Search とは?