Azure AI Search の検索インデックス

[アーティクル]
10/21/2024

Azure AI Search の "検索インデックス" は検索可能なコンテンツであり、検索エンジンでインデックス作成、全文検索、ベクトル検索、ハイブリッド検索、フィルターされたクエリに使用できます。インデックスは、スキーマによって定義され、検索サービスに保存されます。2 番目のステップとしてデータのインポートが続きます。このコンテンツは検索サービス内に存在します。これは、最新の検索アプリケーションで想定されるミリ秒単位の応答時間に必要な、プライマリデータストアとは別のものです。インデクサー主導のインデックス作成シナリオを除き、検索サービスがソースデータに接続したり、クエリを実行したりすることはありません。

検索インデックスを作成して管理する場合、この記事は次の点を理解するのに役立ちます。

コンテンツ (ドキュメントおよびスキーマ)
物理データ構造
基本操作

今すぐに使いたいですか? 代わりに、検索インデックスの作成に関する記事を参照してください。

検索インデックスのスキーマ

Azure AI Search のインデックスには 検索ドキュメントが格納されます。概念的に、ドキュメントはインデックス内で検索可能なデータの 1 つの単位です。たとえば、小売業者には製品ごとのドキュメント、大学にはクラスごとのドキュメント、旅行サイトにはホテルと目的地ごとのドキュメント、といったものが存在する場合があります。これらの概念をなじみのあるデータベースの同等のものに対応させるなら、検索インデックスはテーブルと同じで、ドキュメントはテーブルにおける行とほぼ同じです。

次の例に示すように、ドキュメントの構造は "インデックススキーマ" によって決まります。 "フィールド" コレクションは通常、インデックスの最大の部分であり、各フィールドには、名前、データ型の割り当て、および使用方法を決定する許容される動作を示す属性が設定されます。

{
  "name": "name_of_index, unique across the service",
  "fields": [
    {
      "name": "name_of_field",
      "type": "Edm.String | Collection(Edm.String) | Collection(Edm.Single) | Edm.Int32 | Edm.Int64 | Edm.Double | Edm.Boolean | Edm.DateTimeOffset | Edm.GeographyPoint",
      "searchable": true (default where applicable) | false (only Edm.String and Collection(Edm.String) fields can be searchable),
      "filterable": true (default) | false,
      "sortable": true (default where applicable) | false (Collection(Edm.String) fields cannot be sortable),
      "facetable": true (default where applicable) | false (Edm.GeographyPoint fields cannot be facetable),
      "key": true | false (default, only Edm.String fields can be keys),
      "retrievable": true (default) | false,
      "analyzer": "name_of_analyzer_for_search_and_indexing", (only if 'searchAnalyzer' and 'indexAnalyzer' are not set)
      "searchAnalyzer": "name_of_search_analyzer", (only if 'indexAnalyzer' is set and 'analyzer' is not set)
      "indexAnalyzer": "name_of_indexing_analyzer", (only if 'searchAnalyzer' is set and 'analyzer' is not set)
      "normalizer":  "name_of_normalizer", (applies to fields that are filterable)
      "synonymMaps": "name_of_synonym_map", (optional, only one synonym map per field is currently supported)
      "dimensions": "number of dimensions used by an emedding models", (applies to vector fields only, of type Collection(Edm.Single))
      "vectorSearchProfile": "name_of_vector_profile" (indexes can have many configurations, a field can use just one)
    }
  ],
  "suggesters": [ ],
  "scoringProfiles": [ ],
  "analyzers":(optional)[ ... ],
  "charFilters":(optional)[ ... ],
  "tokenizers":(optional)[ ... ],
  "tokenFilters":(optional)[ ... ],
  "defaultScoringProfile": (optional) "...",
  "corsOptions": (optional) { },
  "encryptionKey":(optional){ },
  "semantic":(optional){ },
  "vectorSearch":(optional){ }
}

簡潔にするために他の要素は折りたたまれていますが、次のリンク先で詳細を確認できます。

suggesters は、オートコンプリートのような先行入力クエリをサポートします。
scoringProfiles は関連性のチューニングに使われます。
analyzers は、アナライザーがサポートする言語規則やその他の特性に従って文字列をトークンに処理するために使われます。
corsOptions、つまりクロスオリジンリモートスクリプト (CORS) は、さまざまなドメインから要求を発行するアプリに使われます。
encryptionKey は、インデックス内の機密コンテンツの二重暗号化を構成します。
semantic は、全文検索とハイブリッド検索でのセマンティック再ランク付けを構成します。
vectorSearch は、ベクトルフィールドとクエリを構成します。

フィールド定義

検索ドキュメントは、インデックス要求の作成に関する記事の本文の "フィールド" コレクションによって定義されます。ドキュメントの識別のためのフィールド (キー)、検索可能なテキストの格納、フィルター、ファセット、並べ替えをサポートするためのフィールドが必要になります。ユーザーに表示しないデータのフィールドが必要になる場合もあります。たとえば、検索スコアを上げるためにスコアリングプロファイルで使用できる、利益率やマーケティングプロモーションのフィールドが必要になることがあります。

受信データが階層化された性質を持つ場合は、入れ子構造に使われる複合型として、インデックス内でそれを表すことができます。あらかじめ登録されているサンプルデータセットである Hotels は、各ホテルとの一対一のリレーションシップを持つ Address (複数のサブフィールドを含む) と、各ホテルに複数の部屋が関連付けられている複合型コレクションの Rooms を使用した複合型を示しています。

フィールド属性

フィールド属性は、フィールドがどのように使用されるか (フルテキスト検索、ファセットナビゲーション、並べ替えなどの操作で使用されるかどうか) を決定します。

文字列フィールドは多くの場合、"検索可能" および "取得可能" としてマークされます。検索結果を絞り込むために使用されるフィールドには、"並べ替え可能"、"フィルター可能"、および "ファセット可能" が含まれます。

属性	説明
"検索可能"	全文またはベクトル検索可能。テキストフィールドは、インデックス作成時に単語分割などの字句解析の対象になります。検索可能フィールドを "sunny day" などの値に設定した場合、その値は内部的に個別のトークン "sunny" と "day" に分割されます。詳細については、「フルテキスト検索のしくみ」を参照してください。
"フィルター可能"	$filter クエリで参照されます。型 `Edm.String` または `Collection(Edm.String)` のフィルター可能フィールドは単語分割されないため、比較は完全に一致するかどうかだけになります。たとえば、このようなフィールドを "sunny day" に設定した場合、`$filter=f eq 'sunny'` では一致が見つかりませんが、`$filter=f eq 'sunny day'` では見つかります。
"並べ替え可能"	既定では、システムは結果をスコアで並べ替えますが、ドキュメント内のフィールドに基づいて並べ替えを構成できます。型 `Collection(Edm.String)` のフィールドを "並べ替え可能" にすることはできません。
"ファセット可能"	通常、カテゴリ (たとえば、特定の市にあるホテル) ごとのヒットカウントを含む検索結果のプレゼンテーションで使用されます。このオプションは、型 `Edm.GeographyPoint`のフィールドでは使用できません。 "フィルター可能"、"並べ替え可能"、または "ファセット可能" である型 `Edm.String` のフィールドの長さは、最大 32 キロバイトです。詳細については、「Create Index (REST API) (インデックスの作成 (REST API))」を参照してください。
"キー"	インデックス内のドキュメントの一意識別子。キーフィールドとして正確に 1 つのフィールドを選択する必要があり、それは型 `Edm.String` である必要があります。
"取得可能"	検索結果でこのフィールドを返すことができるかどうかを決定します。これは、あるフィールド ("利幅" など) をフィルター、並べ替え、またはスコア付けのメカニズムとして使用するが、このフィールドをエンドユーザーには表示したくない場合に役立ちます。 `true` for `key` である必要があります。

いつでも新しいフィールドを追加できますが、既存のフィールド定義はインデックスの有効期間の間ロックされます。このため、開発者は通常、単純なインデックスを作成したり、アイデアをテストしたり、ポータルページを使用して設定を検索したりするためのポータルを使用します。インデックスを容易に再構築できるようにコードベースのアプローチに従う場合は、インデックス設計を頻繁に反復する方がより効率的です。

Note

インデックスの作成に使用する API には、さまざまな既定の動作があります。 REST API の場合、ほとんどの属性は既定で有効であり (たとえば、文字列フィールドの "searchable" および "retrievable" は true です)、無効にする場合は、単にそれらを設定するだけです。 .NET SDK の場合は、逆のことが言えます。明示的に設定していないプロパティの場合、既定では、特に有効にしない限り、対応する検索動作は無効にされています。

物理的な構造とサイズ

Azure AI Search におけるインデックスの物理的な構造は、主に内部実装です。ユーザーはスキーマへのアクセス、コンテンツのクエリの実行、サイズの監視、容量の管理を行うことはできますが、クラスター自体 (逆インデックス、ベクトルインデックス、シャード、その他のファイルとフォルダー) は Microsoft によって内部的に管理されます。

インデックスのサイズは、Azure portal の [検索管理] > [インデックス] ページで、または検索サービスに対して GET INDEX 要求を発行して、監視できます。サービス統計情報要求を発行し、ストレージサイズの値を確認することもできます。

インデックスのサイズは、次の条件によって決まります。

ドキュメントの数量と構成
個々のフィールドの属性
インデックスの構成 (具体的には、suggester を含めるかどうか)

ドキュメントの構成と数量は、インポートに選択した内容によって決まります。検索インデックスには検索可能なコンテンツのみを含める必要があります。ソースデータにバイナリフィールドが含まれている場合は、AI エンリッチメントを使用してコンテンツを解読して分析し、テキスト検索可能な情報を作成する場合を除き、それらのフィールドは除外してください。

フィールドの属性によって動作が決まります。これらの動作をサポートするために、インデックス作成プロセスによって、必要なデータ構造が作成されます。たとえば、Edm.String 型のフィールドの場合、"検索可能" によって、トークン化された用語の転置インデックスをスキャンする全文検索が呼び出されます。これに対して、"フィルター可能" または "並べ替え可能" の属性では、未変更の文字列に対する反復処理がサポートされます。次のセクションの例では、選択した属性に基づくインデックスサイズのバリエーションを示しています。

suggester は、先行入力またはオートコンプリートのクエリをサポートするコンストラクトです。そのため、suggester を含めると、インデックス作成プロセスによって、逐語的な文字の照合に必要なデータ構造が作成されます。 suggester はフィールドレベルで実装されるため、先行入力にふさわしいフィールドのみを選択してください。

属性と suggester がストレージに与える影響を示す例

次のスクリーンショットは、属性のさまざまな組み合わせの結果であるインデックス格納パターンを示しています。このインデックスは不動産サンプルインデックスに基づいています。これは、データのインポートウィザードと組み込みのサンプルデータを使用して簡単に作成できます。インデックスのスキーマは表示されませんが、インデックス名に基づいて属性を推測できます。たとえば、realestate-searchable インデックスでは "searchable" 属性が選択されていて他には何もなく、realestate-retrievable インデックスでは "retrievable" 属性が選択されていて他には何もなく、以下同様です。

これらのインデックスのバリエーションはやや人為的なものですが、属性がストレージに与える影響の広範な比較のために参照できます。

"取得可能" は、インデックスのサイズに影響しません。
"フィルター可能"、"並べ替え可能"、"ファセット可能" は、より多くのストレージを消費します。
suggester では、インデックスサイズが大きくなる可能性が大いにありますが、スクリーンショットで示すほどではありません。(suggester 対応になる可能性のあるすべてのフィールドが選択されていますが、ほとんどのインデックスではこのようなシナリオになる可能性はありません)。

また、上記の表に反映されていない事柄に、アナライザーの影響があります。 edgeNgram トークナイザーを使って逐語的な文字シーケンス (a, ab, abc, abcd) を格納した場合、インデックスは、標準アナライザーを使用した場合よりも大きくなります。

基本的な操作と相互作用

インデックスの概要を理解したので、このセクションでは、1 つのインデックスに接続してセキュリティを保護するなどの、インデックスの実行時操作について説明します。

Note

インデックスを管理する際、インデックスの移動やコピーに関して、ポータルや API のサポートはないことに注意してください。代わりに、ユーザーは通常、アプリケーションデプロイソリューションを別の検索サービスでポイントする (同じインデックス名を使用している場合) か、名前を変更して現在の検索サービスにコピーを作成してからビルドします。

インデックスの分離性

Azure AI Search で操作の対象となるインデックスは一度に 1 つです。インデックスに関連したすべての操作は、単一のインデックスが対象となります。関連するインデックスや、インデックス作成またはクエリのための独立したインデックスの結合の概念はありません。

継続的に使用可能

インデックスは、最初のドキュメントのインデックスが作成されるとすぐにクエリで使用できますが、すべてのドキュメントのインデックスが作成されるまでは完全には機能しません。内部的には、検索インデックスはパーティション間で分散され、レプリカ上で実行されます。物理インデックスは内部で管理されます。論理インデックスはユーザーが管理します。

インデックスは継続的に使用可能であり、一時停止したり、オフラインにしたりすることはできません。継続的な操作のために設計されているので、コンテンツの更新やインデックス自体への追加はリアルタイムで行われます。その結果、要求がドキュメントの更新と一致する場合、クエリは一時的に不完全な結果を返す可能性があります。

ドキュメント操作 (更新または削除) や、現在のインデックスの既存の構造と整合性に影響しない変更 (新しいフィールドの追加など) に対しては、クエリの継続性が存在します。構造上の更新 (既存のフィールドの変更) を行う必要がある場合は、通常、開発環境での削除と再構築のワークフローを使用して、または運用サービスでインデックスの新しいバージョンを作成することによってそれらが管理されます。

インデックスの再構築を避けるため、小規模な変更を行っている一部のお客様は、以前のバージョンと共存する新しいものを作成することによって、フィールドの "バージョン管理" を選択しています。これは、時間の経過と共に、特にレプリケートに負荷のかかる運用環境のインデックスで、古いフィールドまたは古いカスタムアナライザー定義の形式の、孤立したコンテンツになります。インデックスライフサイクル管理の一部として、インデックスの計画更新に関する問題に対処することができます。

エンドポイントの接続とセキュリティ

すべてのインデックス作成とクエリの要求は、インデックスを対象とします。エンドポイントは、通常、次のいずれかになります。

エンドポイント接続とアクセスの制御

<your-service>.search.windows.net/indexes インデックスのコレクションを対象とします。インデックスを作成、一覧表示、または削除するときに使用します。これらの操作には管理者権限が必要です。管理者 API キーまたは Search 共同作成者ロールを通じて使用できます。

<your-service>.search.windows.net/indexes/<your-index>/docs 1 つのインデックスのドキュメントコレクションを対象とします。インデックスまたはデータ更新に対してクエリを実行するときに使用します。クエリには、読み取り権限で十分であり、クエリ API キーまたはデータ閲覧者ロールを通じて使用できます。データ更新の場合は、管理者権限が必要です。

エンドポイント	接続とアクセスの制御
`<your-service>.search.windows.net/indexes`	インデックスのコレクションを対象とします。インデックスを作成、一覧表示、または削除するときに使用します。これらの操作には管理者権限が必要です。管理者 API キーまたは Search 共同作成者ロールを通じて使用できます。
`<your-service>.search.windows.net/indexes/<your-index>/docs`	1 つのインデックスのドキュメントコレクションを対象とします。インデックスまたはデータ更新に対してクエリを実行するときに使用します。クエリには、読み取り権限で十分であり、クエリ API キーまたはデータ閲覧者ロールを通じて使用できます。データ更新の場合は、管理者権限が必要です。

Azure AI 検索への接続方法

Azure portal から開始します。 Azure サブスクライバー (つまり検索サービスの作成者) は、Azure portal で検索サービスを管理できます。サービスを作成または削除するには、Azure サブスクリプションに共同作成者以上のアクセス許可が必要です。このアクセス許可レベルは、Azure portal で検索サービスを完全に管理するのに十分です。
プログラムによるアクセスには、他のクライアントを試してください。最初の手順ではクイックスタートをお勧めします。

次のステップ

Azure AI Search のほぼすべてのサンプルまたはチュートリアルを使用して、インデックスを作成する実践的な体験ができます。まず、目次から任意のクイックスタートを選択できます。

ただし、データを使用してインデックスを読み込む方法についても理解しておく必要があります。インデックスの定義とデータのインポートの方法は、連携して定義されます。次の記事では、インデックスの作成および読み込みの詳細について説明します。

次の方法で共有