Azure AI Search でのインデックスプロジェクション

[アーティクル]
11/15/2023

重要

インデックスプロジェクションは、追加使用条件の下でパブリックプレビュー段階にあります。この機能を含むように更新された Azure portal 2023-10-01-Preview REST API、Azure portal、ベータ版クライアントライブラリを通じて利用できます。

インデックスプロジェクションは、セカンダリインデックスの形状を定義するスキルセット定義のコンポーネントであり、エンリッチメントパイプラインのコンテンツが複数のインデックスをターゲットにできる 1 対多のインデックスパターンをサポートしています。

インデックスプロジェクションでは、エンリッチメントパイプラインによって生成された AI エンリッチメントコンテンツを取得し、検索サービス上のセカンダリインデックス (インデクサーが既定でターゲットとするものとは異なる) にインデックスを付けます。インデックスプロジェクションを使用すると、エンリッチされた項目の配列をターゲットインデックス内の複数の検索ドキュメントに一意に分離 (すなわち "1 対多" インデックス付け) できる方法で、インデックスを付ける前にデータの形状を変更することもできます。 "1 対多" インデックス付けは、チャンクされていないコンテンツのプライマリインデックスやチャンクされたコンテンツのセカンダリインデックスが必要になったりする、データチャンクのシナリオで役立ちます。

過去にコグニティブスキルを使用したことがある場合は、エンリッチされたコンテンツがスキルセットによって作成されていることを既にご存知でしょう。スキルセットは、エンティティの認識やテキストの翻訳など、アトミック変換を呼び出す一連のエンリッチメント通じてドキュメントを移動します。既定では、スキルセット内で処理された 1 つのドキュメントは、検索インデックス内の 1 つのドキュメントにマッピングされます。つまり、入力テキストのチャンクを実行し、各チャンクに対してエンリッチメントを実行すると、outputFieldMappings を使用してマッピングされた場合のインデックスの結果は、生成されたエンリッチメントの配列になります。インデックスプロジェクションでは、エンリッチされたデータの各チャンクをそれ自体の検索ドキュメントにマッピングするコンテキストを定義します。こうすることで、ドキュメントのエンリッチされたデータの 1 対多マッピングを検索インデックスに適用できます。

インデックスプロジェクションの定義

インデックスプロジェクションはスキルセット定義内で定義され、そして主にセレクターの配列として定義されます。この配列では、各セレクターが検索サービス上の異なるターゲットインデックスに対応します。各セレクターには、定義の一部として次のパラメータが必要です。

targetIndexName: インデックスプロジェクションデータのインデックスが付けられる検索サービスのインデックスの名前。
parentKeyFieldName: 親ドキュメントのキーの値が入ったターゲットインデックス内のフィールドの名前。
sourceContext: 個々の検索ドキュメントにデータをマッピングする細分性を定義するエンリッチメント注釈。詳細については、「スキルコンテキストと入力注釈言語」を参照してください。
mappings: 検索インデックス内のフィールドへのエンリッチされたデータのマッピングの配列。各マッピングは次で構成されます。
- name: データのインデックスを付ける検索インデックス内のフィールドの名前。
- source: データをプルするエンリッチメント注釈パス。

各 mapping では、ナレッジストアや Shaper スキルと同様に、オプションの sourceContext および inputs フィールドを使用してデータを再帰的に定義することもできます。これらのパラメータを使用すると、検索インデックス内の Edm.ComplexType 型のフィールドにインデックスを付けるデータを整形できます。

targetIndexName パラメータで定義されるインデックスには、次の要件があります。

インデックスプロジェクション定義を含むスキルセットが作成される前に、検索サービスで既に作成されている必要がある。
parentKeyFieldName パラメータで定義されている名前が付いたフィールドを含む必要がある。このフィールドは Edm.String 型である必要があり、キーフィールドにすることはできません。また、フィルター適用可否を true に設定する必要があります。
キーフィールドは、検索可否を true に設定し、keyword アナライザーで定義する必要があります。
mappings で定義されている各 name に対してフィールドを定義する必要があり、いずれもキーフィールドにはできない。

Split スキルによって出力された個々のページを、検索インデックス内のそれ自体のドキュメントとしてプロジェクションするのに使用する、インデックスプロジェクション定義のペイロードの例を次に示します。

"indexProjections": {
    "selectors": [
        {
            "targetIndexName": "myTargetIndex",
            "parentKeyFieldName": "ParentKey",
            "sourceContext": "/document/pages/*",
            "mappings": [
                {
                    "name": "chunk",
                    "source": "/document/pages/*"
                }
            ]
        }
    ]
}

親ドキュメントの処理

インデックスプロジェクションでは、スキルセットを介して実行される "親" ドキュメントごとに "子" ドキュメントが効果的に生成されるため、"親" ドキュメントのインデックス付けを処理する方法について次の選択肢もあります。

親ドキュメントと子ドキュメントを別々のインデックスに保持するには、インデクサー定義の targetIndexName が、インデックスプロジェクションセレクターで定義されている targetIndexName とは異なるようにするだけです。
親ドキュメントと子ドキュメントを同じインデックスにインデックス付けするには、ターゲットインデックスのスキーマが、インデクサー定義内の定義された fieldMappings と outputFieldMappings の両方と、インデックスプロジェクションセレクターの mappings を使用して動作するようにする必要があります。そして、インデクサー定義とインデックスプロジェクションセレクターに同じ targetIndexName を指定するだけです。
親ドキュメントを無視し、子ドキュメントのインデックスのみを付けるには、インデクサー定義に targetIndexName を指定する必要があります (インデックスプロジェクションセレクターに対してと同じものを指定できます)。次に、次に示すように、projectionMode キーを skipIndexingParentDocuments に設定して、selectors 定義の横にある別の parameters オブジェクトを定義します。
```
"indexProjections": {
    "selectors": [
        ...
    ],
    "parameters": {
        "projectionMode": "skipIndexingParentDocuments"
    }
}
```

REST
.NET

REST API バージョン 2023-10-01-Preview を使用すると、スキルセットへの追加によりインデックスプロジェクションを作成できます。

コンテンツのライフサイクル

インデクサーデータソースで変更の追跡と削除の検出がサポートされている場合、インデックス付けプロセスはプライマリインデックスとセカンダリインデックスを同期して、それらの変更を取得できます。

インデクサーとスキルセットを実行するたび、スキルセットまたは基になるソースデータが変更された場合には、インデックスプロジェクションが更新されます。インデクサーによって取得された変更は、エンリッチメントプロセスを通じてインデックス内のプロジェクションに反映され、プロジェクションされたデータが元のデータソース内のコンテンツの現在の表現になります。

Note

インデックスプッシュ API を使用して、プロジェクションされたドキュメント内のデータを手動で編集できますが、ソースデータ内のドキュメントが更新された場合、次のパイプライン呼び出しですべての編集が上書きされます。

プロジェクションされるキーの値

各インデックスプロジェクションドキュメントには、一意性を確保し、変更と削除の追跡を正しく機能させるために、インデクサーによって生成される一意の識別キーが含まれています。このキーには、次のセグメントが含まれています。

一意性を保証するランダムハッシュ。このハッシュは、親ドキュメントがインデクサーの実行間で更新された場合に変更されます。
親ドキュメントのキー。
ドキュメントの生成元のコンテキストを識別するエンリッチメント注釈パス。

たとえば、キー値が "123" の親ドキュメントを 4 ページに分割し、それらの各ページがインデックスプロジェクションによりそれ自体のドキュメントとしてプロジェクションされる場合、テキストの 3 番目のページのキーは "01f07abfe7ed_123_pages_2" のようになります。そして親ドキュメントが更新されて 5 ページ目が追加されると、3 番目のページの新しいキーが "9d800bdacc0e_123_pages_2" などとなったりします。これは、残りのプロジェクションデータが変更されなくても、インデクサーの実行間でランダムハッシュ値が変更されるためです。

変更または追加

プロジェクションされたインデックスドキュメント内のデータが変更されるように親ドキュメントが変更された場合 (たとえば、1 語が特定のページで変更されたが、実質的に新しいページは追加されていない場合など)、その特定のプロジェクションのターゲットインデックス内のデータは、その変更を反映するように更新されます。

親ドキュメントが変更され、以前は存在していなかった新しいプロジェクションされた子ドキュメントができる場合 (たとえば、ドキュメントに 1 ページ以上に相当するテキストが追加された場合など)、その新しい子ドキュメントは、インデクサーが次回実行されるときに追加されます。

どちらの場合も、特定のコンテンツが更新されたかどうかに関係なく、すべてのプロジェクションされたドキュメントはキーに新しいハッシュ値を持つよう更新されます。

削除

親ドキュメントが変更され、インデックスプロジェクションによって生成された子ドキュメントが存在しなくなった場合 (たとえば、テキストを短くして以前よりチャンクが減った場合など)、検索インデックス内の対応する子ドキュメントは削除されます。残りの子ドキュメントも、そのコンテンツが他に変更されていなくても、新しいハッシュ値を含むようにキーが更新されます。

親ドキュメントがデータソースから完全に削除された場合、対応する子ドキュメントは、データソース定義で定義された dataDeletionDetectionPolicy によって削除が検出された場合にのみ削除されます。 dataDeletionDetectionPolicy が構成されていなくて、データソースから親ドキュメントを削除する必要がある場合は、不要であれば子ドキュメントを手動で削除する必要があります。

Azure AI Search でのインデックス プロジェクション

インデックス プロジェクションの定義