Azure AI Search でのベクトルストレージ

[アーティクル]
09/03/2024

Azure AI 検索には、ベクトル検索とハイブリッド検索用のベクトルストレージと構成が用意されています。サポートはフィールドレベルで実装されます。つまり、同じ検索コーパスでベクトルフィールドと非ベクトルフィールドを組み合わせることができます。

ベクトルは検索インデックスに格納されます。 Create Index REST API または同等の Azure SDK メソッドを使用して、ベクトルストアを作成します。

ベクトルストレージの主な考慮事項は以下のとおりです。

目的とするベクトル取得パターンに基づいて、ユースケースに合うスキーマを設計します。
インデックスサイズを見積もり、検索サービスの容量を確認します。
ベクトルストアを管理する
ベクトルストアをセキュリティで保護する

ベクトル取得パターン

Azure AI Search には、検索結果を操作するための 2 つのパターンがあります。

生成検索。言語モデルは、Azure AI Search のデータを使用して、ユーザーのクエリに対する応答を作成します。このパターンには、プロンプトを調整し、コンテキストを維持するためのオーケストレーションレイヤーが含まれます。このパターンでは、検索結果はプロンプトフローにフィードされ、GPT や Text-Davinci などのチャットモデルが受け取ります。このアプローチは、検索インデックスによってグラウンドデータが提供される取得拡張生成 (RAG) アーキテクチャに基づいています。
検索バー、クエリ入力文字列、レンダリングされた結果を使用した従来の検索。検索エンジンによって、ベクトルクエリが受け入れられて実行され、応答が作成されます。ユーザーはそれらの結果をクライアントアプリにレンダリングします。 Azure AI Search では、結果はフラット化された行セットで返され、検索結果を含めるフィールドを選ぶことができます。チャットモデルがないため、応答で人間が判読できる非ベクトルコンテンツをベクトルストア (検索インデックス) に設定することが期待されます。検索エンジンはベクトルに一致しますが、非ベクトル値を使用して検索結果を設定する必要があります。 ベクトルクエリとハイブリッドクエリは、従来の検索シナリオ用に作成できるクエリ要求の型に対応します。

インデックススキーマには、主なユースケースが反映されている必要があります。次のセクションでは、生成 AI と従来の検索用に構築されるソリューションのフィールド構成の違いに着目します。

ベクトルストアのスキーマ

ベクトルストアのインデックススキーマには、名前、キーフィールド (文字列)、1 つ以上のベクトルフィールド、およびベクトル構成が必要です。非ベクトルフィールドは、ハイブリッドクエリ、または言語モデルを通過する必要のない、人間が読み取り可能な逐語的なコンテンツを返す場合に推奨されます。ベクトル構成の手順については、「ベクトルストアを作成する」を参照してください。

基本的なベクトルフィールドの構成

ベクトルフィールドは、データ型とベクトル固有のプロパティによって区別されます。フィールドコレクション内のベクトルフィールドの外観を以下に示します。

{
    "name": "content_vector",
    "type": "Collection(Edm.Single)",
    "searchable": true,
    "retrievable": true,
    "dimensions": 1536,
    "vectorSearchProfile": "my-vector-profile"
}

ベクトルフィールドの型は Collection(Edm.Single) です。

ベクトルフィールドは検索可能で取得可能である必要がありますが、フィルター可能、ファセット可能、並べ替え可能にすることはできません。また、アナライザー、ノーマライザー、シノニムマップの割り当てを持つことはできません。

ベクトルフィールドでは、埋め込みモデルによって生成される埋め込みの数に dimensions を設定する必要があります。たとえば、text-embedding-ada-002 では、テキストのチャンクごとに 1,536 個の埋め込みが生成されます。

ベクトルフィールドには、"ベクトル検索プロファイル" によって示されるアルゴリズムを使用してインデックスが作成されます。このプロファイルはインデックス内の他の場所で定義されているため、例では示されていません。詳細については、ベクトル検索の構成に関するページを参照してください。

基本的なベクトルワークロードのフィールドコレクション

ベクトルストアでは、ベクトルフィールド以外にもさらにフィールドが必要です。たとえば、キーフィールド (この例では "id") はインデックス要件です。

"name": "example-basic-vector-idx",
"fields": [
  { "name": "id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "key": true },
  { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": null },
  { "name": "content", "type": "Edm.String", "searchable": true, "retrievable": true, "analyzer": null },
  { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": true, "facetable": true }
]

"content" フィールドなどの他のフィールドでは、人間が判読できる "content_vector" フィールドと同等のものが提供されます。応答の作成専用の言語モデルを使用している場合は、非ベクトルコンテンツフィールドを省略できますが、クライアントアプリに検索結果を直接プッシュするソリューションには非ベクトルコンテンツが必要です。

メタデータフィールドは、特にメタデータにソースドキュメントに関する配信元情報が含まれている場合に、フィルターに役立ちます。ベクトルフィールド上で直接フィルター処理を行うことはできませんが、ベクトルクエリの実行前または実行後にフィルター処理を行うプリフィルターモードまたはポストフィルターモードを設定することができます。

データのインポートとベクトル化ウィザードによって生成されるスキーマ

評価と概念実証のテストには、データのインポートとベクトル化ウィザードをお勧めします。ウィザードによって、このセクションのスキーマ例が生成されます。

このスキーマの偏りは、検索ドキュメントがデータチャンクを中心に構築されていることです。 RAG アプリで一般的なように、言語モデルが応答を作成する場合は、データチャンクを中心に設計されたスキーマが必要です。

データチャンクは、言語モデルの入力制限内を維持するために必要ですが、複数の親ドキュメントからプルされたコンテンツの小さなチャンクに対してクエリを照合できる場合の類似性検索の精度も向上します。最後に、セマンティックランク付けを使用している場合、セマンティックランカーにはトークン制限もあります。これは、データチャンクがアプローチの一部である場合に、より簡単に満たされます。

次の例では、検索ドキュメントごとに 1 つのチャンク ID、チャンク、タイトル、ベクトルフィールドがあります。 blob メタデータ (パス) の base 64 エンコードを使用して、chunkID と親 ID がウィザードによって設定されます。チャンクとタイトルは、BLOB コンテンツと BLOB 名から派生します。ベクトルフィールドのみが完全に生成されます。これは、ベクトル化されたバージョンのチャンクフィールドです。埋め込みは、指定した Azure OpenAI 埋め込みモデルを呼び出すことによって生成されます。

"name": "example-index-from-import-wizard",
"fields": [
  {"name": "chunk_id",  "type": "Edm.String", "key": true, "searchable": true, "filterable": true, "retrievable": true, "sortable": true, "facetable": true, "analyzer": "keyword"},
  { "name": "parent_id", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": true},
  { "name": "chunk", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true, "sortable": false},
  { "name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": false},
  { "name": "vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "vector-1707768500058-profile"}
]

RAG アプリとチャットスタイルアプリのスキーマ

生成検索用のストレージを設計する場合は、インデックスを作成してベクトル化した静的コンテンツに対して個別のインデックスを作成し、プロンプトフローで使用できる会話用に 2 つ目のインデックスを作成できます。以下のインデックスは、chat-with-your-data-solution-accelerator アクセラレータから作成されます。

生成検索エクスペリエンスをサポートするチャットインデックスのフィールド:

"name": "example-index-from-accelerator",
"fields": [
  { "name": "id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true },
  { "name": "content", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
  { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "my-vector-profile"},
  { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
  { "name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "facetable": true },
  { "name": "source", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true  },
  { "name": "chunk", "type": "Edm.Int32", "searchable": false, "filterable": true, "retrievable": true },
  { "name": "offset", "type": "Edm.Int32", "searchable": false, "filterable": true, "retrievable": true }
]

オーケストレーションとチャット履歴をサポートする会話インデックスのフィールド:

"fields": [
    { "name": "id", "type": "Edm.String", "key": true, "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": false },
    { "name": "conversation_id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "content", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
    { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "default-profile" },
    { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
    { "name": "type", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "user_id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "sources", "type": "Collection(Edm.String)", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "created_at", "type": "Edm.DateTimeOffset", "searchable": false, "filterable": true, "retrievable": true },
    { "name": "updated_at", "type": "Edm.DateTimeOffset", "searchable": false, "filterable": true, "retrievable": true }
]

次に示すのは、Search Explorer における会話インデックスの検索結果のスクリーンショットです。検索に条件がないため、検索スコアは 1.00 となっています。オーケストレーションとプロンプトフローをサポートするために存在するフィールドに注目してください。会話 ID は、特定のチャットを特定します。 "type" は、コンテンツがユーザーとアシスタントのどちらからのものであるかを示します。日付は、古さによって履歴からチャットを削除するために使用されます。

物理的な構造とサイズ

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

インデックスのサイズと内容は、以下によって決まります。

ドキュメントの数量と構成
個々のフィールドの属性。たとえば、フィルター処理可能なフィールドにはより多くのストレージが必要です。
類似性検索に HNSW と網羅的 KNN のどちらを選択するかに基づくインデックス構成 (内部的なナビゲーション構造がどのように作成されるかを指定するベクトル構成を含む)。

Azure AI 検索はベクトルストレージに制限を課しており、これは、すべてのワークロードにとってバランスのとれた安定したシステムを維持するのに役立ちます。利用者が制限の範囲内に留まるのを手助けするために、ベクトルの使用状況は Azure portal においてと、サービスとインデックスの統計情報を使用したプログラム的な方法とで個別に追跡され報告されます。

次に示すのは、1 つのパーティションと 1 つのレプリカで構成された S1 サービスのスクリーンショットです。この特定のサービスには、平均して 1 つのベクトルフィールドを含む 24 個の小さなインデックスがあり、各フィールドは 1536 個の埋め込みで構成されています。 2 番目のタイルが示しているのは、ベクトルインデックスのクォータと使用状況です。ベクトルインデックスは、各ベクトルフィールドに対して作成された内部的なデータ構造です。そのため、ベクトルインデックスのストレージは常に、インデックス全体によって使用されるストレージの一部となります。残りの部分は、その他の非ベクトルフィールドとデータ構造によって使用されます。

ベクトルインデックスの制限と見積もりについては別の記事でカバーされていますが、前もって強調しておくべき 2 つの点として、ストレージの最大値はサービスレベルによって異なるということと、検索サービスがいつ作成されたかによっても異なるということがあります。同じレベルでも新しいサービスの方が、かなり多いベクトルインデックスの容量を持ちます。このため、以下のアクションを行ってください。

検索サービスのデプロイ日を確認する。 2024 年 4 月 3 日より前に作成されている場合は、容量を増やすために新しい検索サービスを作成することを検討してください。
ベクトルストレージ要件の変動が予想される場合、スケーラブルなレベルを選択する。 Basic レベルは、以前の検索サービスの 1 つのパーティションに固定されています。柔軟性とパフォーマンスを向上させるには、Standard 1 (S1) 以降を検討するか、より高い制限や多くのパーティションを null 許容レベルで使用する新しい検索サービスを作成します。

基本的な操作と相互作用

このセクションでは、1 つのインデックスへの接続やセキュリティ保護など、ベクトルの実行時操作について紹介します。

Note

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

継続的に使用可能

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

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

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

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

エンドポイント接続

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

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

<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 検索への接続方法

アクセス許可または API アクセスキーがあることを確認します。既存のインデックスに対してクエリを実行する場合を除き、検索サービスのコンテンツを管理および表示するには、管理者権限または共同作成者ロールの割り当てが必要です。
Azure portal から開始します。検索サービスを作成したユーザーは、[アクセス制御 (IAM)] ページを使用して他のユーザーにアクセスを許可するなど、検索サービスを表示および管理できます。
プログラムによるアクセスのために他のクライアントに移動します。最初の手順としては、以下のクイックスタートとサンプルをお勧めします。
- クイックスタート: REST
- ベクトルのサンプル

ベクトルデータへのアクセスをセキュリティで保護する

Azure AI 検索では、データ暗号化、インターネットなしのシナリオ用のプライベート接続、Microsoft Entra ID を介した安全なアクセスのためのロールの割り当てが実装されています。エンタープライズセキュリティ機能の全容については、「Azure AI 検索のセキュリティ」で説明されています。

ベクトルストアを管理する

Azure には、診断ログとアラートを含む監視プラットフォームが用意されています。推奨するベストプラクティスを次に示します。

次の方法で共有

Azure AI Search でのベクトルストレージ

ベクトル取得パターン

ベクトルストアのスキーマ

基本的なベクトルフィールドの構成

基本的なベクトルワークロードのフィールドコレクション

データのインポートとベクトル化ウィザードによって生成されるスキーマ

RAG アプリとチャットスタイルアプリのスキーマ

物理的な構造とサイズ

基本的な操作と相互作用

継続的に使用可能

エンドポイント接続

Azure AI 検索への接続方法

ベクトルデータへのアクセスをセキュリティで保護する

ベクトルストアを管理する

関連項目

フィードバック

その他のリソース

次の方法で共有

Azure AI Search でのベクトル ストレージ

ベクトル取得パターン

ベクトル ストアのスキーマ

基本的なベクトル フィールドの構成

基本的なベクトル ワークロードのフィールド コレクション

データのインポートとベクトル化ウィザードによって生成されるスキーマ

RAG アプリとチャットスタイル アプリのスキーマ

物理的な構造とサイズ

基本的な操作と相互作用

継続的に使用可能

エンドポイント接続

Azure AI 検索への接続方法

ベクトル データへのアクセスをセキュリティで保護する

ベクトル ストアを管理する

関連項目

フィードバック

その他のリソース

Azure AI Search でのベクトルストレージ

ベクトルストアのスキーマ

基本的なベクトルフィールドの構成

基本的なベクトルワークロードのフィールドコレクション

RAG アプリとチャットスタイルアプリのスキーマ

ベクトルデータへのアクセスをセキュリティで保護する

ベクトルストアを管理する