量子化、ナローデータ型、ストレージオプションを使用してベクトルサイズを小さくする

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

この記事では、Azure AI 検索でベクトル量子化やその他の手法を使用してベクトルサイズを小さくする方法について説明します。検索インデックスには、データ型の絞り込みの指定やベクトルコンテンツのコピーを検索結果に保持するかどうかを制御するために使用されるプロパティなどのベクトルフィールド定義を指定します。量子化もインデックスで指定され、ベクトルプロファイルを介してベクトルフィールドに割り当てられます。

この記事で説明されているほとんどの機能は、2024-07-01 REST API とそのバージョンを対象とする Azure SDK パッケージで一般提供されています。最新のプレビューバージョンでは、ベクトル化に text-embedding-3-large または text-embedding-3-small を使用している場合、切り詰められたディメンションのサポートが追加されます。

この記事の最後の例は、この記事で説明する各アプローチのベクトルサイズのバリエーションを示しています。

オプションを評価する

最初の手順として、ベクトルフィールドが使用するストレージの量を減らすための 3 つのアプローチを確認します。これらのアプローチは相互に排他的ではなく、組み合わせることでベクトルサイズを最大限に削減できます。

組み込みの量子化をお勧めします。これは、メモリ "および" ディスク上のベクトルサイズを最小限の労力で圧縮し、ほとんどのシナリオで最大のメリットが得られる傾向があるためです。一方、ナロー型 (float16 以外) では作成に労力を要し、stored で節約できるのは、メモリよりも安価なディスクストレージです。

アプローチ	このオプションを使用する理由
スカラーまたはバイナリ量子化を追加する	量子化を使用して、ネイティブ float32 または float16 埋め込みを int8 (スカラー) または Byte (バイナリ) に圧縮します。このオプションを使用すると、クエリのパフォーマンスを悪化させずにメモリとディスク上のストレージを削減できます。 int8 や Byte のようなより小さなデータ型を使用すると、より大きな埋め込みよりもコンテンツが豊富ではないベクトルインデックスが生成されます。情報の損失を緩和するために、組み込みの圧縮機能には、非圧縮の埋め込みとオーバーサンプリングを使用してより関連性の高い結果を返すクエリ後の処理オプションが含まれます。再ランク付けとオーバーサンプリングは、float32 または float16 フィールドの組み込み量子化の特定の機能であり、カスタム量子化の対象となる埋め込みでは使用できません。
MRL 対応 text-embedding-3 モデルのディメンションを切り詰める (プレビュー)	text-embedding-3 モデルで使用するディメンションを減らすオプションを試します。 Azure OpenAI では、これらのモデルは、異なるレベルの圧縮で複数のベクトル表現を生成する Matryoshka Representation Learning (MRL) 手法に基づいて再トレーニングされています。この方法では、セマンティック情報の損失を最小限に抑えながら、検索の高速化とストレージコストの削減が実現します。 Azure AI 検索では、MRL はスカラー量子化とバイナリ量子化の補完をサポートします。いずれかの量子化方法を使用する場合は、ベクトルフィールドに `truncateDimension` プロパティを指定して、テキスト埋め込みのディメンションを減らすこともできます。
ベクトルフィールドにより小さいプリミティブデータ型を割り当てる	float16、int16、int8、および Byte (バイナリ) などのナローデータ型では、メモリとディスクの使用量が少なくなりますが、ベクトルをナローデータ形式で出力する埋め込みモデルが必要です。または、小さなデータを出力するカスタム量子化ロジックが必要です。 3 番目のユースケースでは、必要な労力が少なく、ほとんどのモデルによって生成されたネイティブ float32 埋め込みが float16 に再キャストされます。バイナリベクトルの詳細については、バイナリベクトルのインデックスに関する記事をご覧ください。
取得可能なベクトルのオプションのストレージを排除する	クエリの応答で返されるベクトルは、クエリの実行中に使用されるベクトルとは別に保存されます。ベクトルを返す必要がない場合は、取得可能なストレージをオフにすることで、フィールドごとの全体的なストレージを最大 50% 削減できます。

これらのオプションはすべて空のインデックス上で定義します。これらのいずれかを実装するには、Azure portal、REST API、またはその API バージョンを対象とする Azure SDK パッケージを使用します。

インデックスが定義されると、別の手順としてドキュメントを読み込み、インデックスを作成できます。

オプション 1: 量子化を構成する

ベクトルサイズを小さくするためには、量子化が推奨されます。これは、float16 および float32 埋め込みのメモリとディスクストレージの両方の要件を低減するためです。より小さなインデックスの影響をオフセットするために、非圧縮ベクトルに対してオーバーサンプリングと再ランク付けを追加できます。

量子化は、float 型のベクトルを受け取るベクトルフィールドに適用されます。この記事の例では、受信 float32 埋め込みのフィールドのデータ型は Collection(Edm.Single) ですが、float16 もサポートされています。圧縮が構成されたフィールドでベクトルを受信すると、エンジンは自動的に量子化を実行して、メモリおよびディスク上のベクトルデータのフットプリントを削減します。

2 種類の量子化がサポートされています。

スカラー量子化では、浮動小数点値をより少ないビット数のデータ型に圧縮します。 AI 検索は現在、8 ビットの int8 をサポートしており、ベクトルインデックスのサイズが 4 分の 1 に削減されます。
バイナリ量子化は、浮動小数点数を、1 ビットを占有するバイナリビットに変換します。これにより、ベクトルインデックスのサイズが最大 28 分の 1 に削減されます。

組み込みの量子化を使用するには、次の手順に従います。

Create Index または Create or Update Index を使用して、ベクトル圧縮を指定する
検索インデックスに vectorSearch.compressions を追加する
scalarQuantization または binaryQuantization 構成を追加して名前を付ける
オプションのプロパティを設定して、損失のあるインデックス作成の影響を軽減する
名前付き構成を使用する新しいベクトルプロファイルを作成する
新しいベクトルプロファイルを持つ新しいベクトルフィールドを作成する
定義した構成でインデックス作成中に量子化された float32 または float16 データを含むインデックスを読み込む
必要に応じて、既定値をオーバーライドする場合は、オーバーサンプリングパラメーターを使用して量子化されたデータに対してクエリを実行します。

検索インデックスに "compressions" を追加する

次の例は、ベクトルフィールドと vectorSearch.compressions セクションを含む fields コレクションを持つ部分インデックス定義を示しています。

この例には scalarQuantization と binaryQuantization の両方が含まれています。必要な数の圧縮構成を指定し、必要なものをベクトルプロファイルに割り当てることができます。

POST https://[servicename].search.windows.net/indexes?api-version=2024-07-01

{
  "name": "my-index",
  "fields": [
    { "name": "Id", "type": "Edm.String", "key": true, "retrievable": true, "searchable": true, "filterable": true },
    { "name": "content", "type": "Edm.String", "retrievable": true, "searchable": true },
    { "name": "vectorContent", "type": "Collection(Edm.Single)", "retrievable": false, "searchable": true, "dimensions": 1536,"vectorSearchProfile": "vector-profile-1"},
  ],
  "vectorSearch": {
        "profiles": [ ],
        "algorithms": [ ],
        "compressions": [
          {
            "name": "use-scalar",
            "kind": "scalarQuantization",
            "scalarQuantizationParameters": {
              "quantizedDataType": "int8"
            },
            "rerankWithOriginalVectors": true,
            "defaultOversampling": 10
          },
          {
            "name": "use-binary",
            "kind": "binaryQuantization",
            "rerankWithOriginalVectors": true,
            "defaultOversampling": 10
          }
        ]
    }
}

重要なポイント:

kind は scalarQuantization または binaryQuantization に設定する必要があります
rerankWithOriginalVectors は元の非圧縮ベクトルを使用して類似性を再計算し、最初の検索クエリによって返される上位の結果を再ランク付けします。 stored が false の場合でも、非圧縮ベクトルが検索インデックスに存在します。このプロパティは省略可能です。既定値は True です。
量子化による情報の減少を緩和するために、defaultOversampling は潜在的な結果のより広範なセットを考慮します。潜在的な結果の数式は、クエリ内の k とオーバーサンプリング乗数で構成されます。たとえば、クエリが k を 5 に指定し、オーバーサンプリングが 20 の場合、クエリはその目的のために元の非圧縮ベクトルを使用して、再ランク付けに使用する 100 個のドキュメントを効果的に要求します。上位の k 個の再ランク付けの結果のみが返されます。このプロパティは省略可能です。既定値は 4 です。
quantizedDataType は省略可能であり、スカラー量子化にのみ適用されます。追加する場合は、int8 に設定する必要があります。これは現時点でスカラー量子化でサポートされている唯一のプリミティブデータ型です。既定値は int8 です。

HNSW アルゴリズムを追加する

インデックスに Hierarchical Navigable Small Worlds (HNSW) アルゴリズムが組み込まれていることを確認します。組み込みの量子化は、完全な KNN ではサポートされていません。

"vectorSearch": {
    "profiles": [ ],
    "algorithms": [
      {
          "name": "use-hnsw",
          "kind": "hnsw",
          "hnswParameters": {
              "m": 4,
              "efConstruction": 400,
              "efSearch": 500,
              "metric": "cosine"
          }
      }
    ],
     "compressions": [ <see previous section>] 
}

新しいベクトルプロファイルを作成して割り当てる

新しい量子化構成を使用するには、"新しい" ベクトルプロファイルを作成する必要があります。メモリ内に圧縮インデックスを構築するには、新しいベクトルプロファイルを作成する必要があります。新しいプロファイルでは HNSW を使用します。

同じインデックス定義で、新しいベクトルプロファイルを作成し、圧縮プロパティとアルゴリズムを追加します。ここでは、量子化アプローチごとに 1 つずつ、2 つのプロファイルを示します。

"vectorSearch": {
    "profiles": [
       {
          "name": "vector-profile-hnsw-scalar",
          "compression": "use-scalar", 
          "algorithm": "use-hnsw",
          "vectorizer": null
       },
       {
          "name": "vector-profile-hnsw-binary",
          "compression": "use-binary", 
          "algorithm": "use-hnsw",
          "vectorizer": null
       }
     ],
     "algorithms": [  <see previous section> ],
     "compressions": [ <see previous section> ] 
}

"新しい" ベクトルフィールドにベクトルプロファイルを割り当てます。フィールドのデータ型は float32 または float16 です。

Azure AI 検索では、float32 および float16 型のエンティティデータモデル (EDM) に相当するものはそれぞれ Collection(Edm.Single) と Collection(Edm.Half) になります。
```
{
   "name": "vectorContent",
   "type": "Collection(Edm.Single)",
   "searchable": true,
   "retrievable": true,
   "dimensions": 1536,
   "vectorSearchProfile": "vector-profile-hnsw-scalar",
}
```
インデックスを読み込むには、プルモデルのインデックス作成の場合はインデクサーを使用し、プッシュモデルのインデックス作成の場合は API を使用します。

Azure AI Search でのスカラー量子化のしくみ

スカラー量子化により、各ベクトル埋め込み内の各数値の解像度が低下します。各数値を 16 ビットまたは 32 ビット浮動小数点数として記述する代わりに、8 ビット整数を使用します。数値の範囲 (通常は 99 パーセンタイルの最小値と最大値) を識別し、それらを有限数のレベルまたはビンに分割することで、各ビンに識別子を割り当てます。 8 ビットスカラー量子化では、2^8 すなわち 256 のビンが存在する可能性があります。

実数を最も近い整数に四捨五入するのに似たプロセスで、ベクトルの各コンポーネントは量子化レベルのこのセット内で最も近い代表値にマッピングされます。量子化された 8 ビットベクトルでは、識別子番号が元の値の代わりに表示されます。量子化後、各ベクトルはそのコンポーネントが属するビンの識別子の配列によって表されます。これらの量子化されたベクトルでは、元のベクトルと比較して保存すべきビット数がはるかに小さいため、ストレージ要件とメモリ占有領域を削減できます。

Azure AI 検索でのバイナリ量子化のしくみ

バイナリ量子化は、各コンポーネントを 0 または 1 の単一ビットとして表すことによって、高次元ベクトルを圧縮します。この方法により、メモリ占有領域が大幅に削減され、検索および取得タスクにとって重要なベクトル比較操作が高速化されます。ベンチマークテストでは、ベクトルインデックスサイズが最大 96% 削減されることが示されています。

これは、1024 を超える次元の埋め込みに特に効果的です。より小さな次元の場合は、バイナリ量子化の品質をテストするか、代わりにスカラーを試すことをお勧めします。さらに、埋め込みの中心がゼロの場合、BQ のパフォーマンスが非常に高いことがわかりました。 OpenAI、Cohere、Mistral などの最も一般的な埋め込みモデルはゼロを中心としています。

MRL 圧縮と切り詰められたディメンションを使用する (プレビュー)

MRL マルチレベル圧縮では、ベクトルストレージが節約され、テキスト埋め込みに基づいてベクトルクエリのクエリ応答時間が向上します。 Azure AI 検索では、MRL のサポートは、量子化の別の方法と共にのみ提供されます。 MRL でバイナリ量子化を使用すると、最大限のベクトルインデックスサイズの削減が提供されます。最大のストレージ削減を実現するには、MRL でバイナリ量子化を使用し、stored を false に設定します。

この機能はプレビュー段階にあります。これは、2024-09-01-preview およびプレビュー API バージョンを対象とするベータ版 SDK パッケージで利用できます。

要件

Text-embedding-3-small、Text-embedding-3-large (テキストコンテンツのみ)。
Edm.Half 型または Edm.Single 型の新しいベクトルフィールド (既存のフィールドに MRL 圧縮を追加することはできません)。
HNSW アルゴリズム (このプレビューでは、完全な KNN はサポートされません)。
スカラー量子化またはバイナリ量子化を構成する。バイナリ量子化をお勧めします。

サポートされるクライアント

REST API 2024-09-01-preview
各 Azure SDK ベータパッケージ (Python、.NET、Java、JavaScript) の変更ログをご確認ください。

現時点では、Azure portal または Azure AI Studio のサポートはありません。

MRL 拡張テキスト埋め込みの使用方法

MRL は、テキスト埋め込みモデルの機能です。 Azure AI 検索でこれらの機能を活用するには、次の手順に従います。

インデックス定義で vectorSearch.compressions オブジェクトを指定します。
スカラーまたはバイナリ (推奨) のいずれかの量子化方法を含めます。
truncationDimension パラメーターを 512 に設定して含めるか、text-embedding-3-large モデルを使用する場合は最低 256 に設定します。
HNSW アルゴリズムとベクトル圧縮オブジェクトを指定するベクトルプロファイルを指定します。
フィールドコレクション内の Edm.Half または Edm.Single 型のベクトルフィールドに、ベクトルプロファイルを割り当てます。

MRL 対応のテキスト埋め込みモデルを使用するためのクエリ側の変更はありません。垂直統合、クエリ時のテキストからクエリへの変換、セマンティックランク付け、元のベクトルとの再ランク付けやオーバーサンプリングなどのその他の関連強化機能は、MRL サポートの影響を受けません。

追加の手順のためにインデックス作成は遅くなりますが、クエリは高速になります。

MRL をサポートするベクトル検索構成の例

次の例は、MRL の要件と推奨事項を満たすベクトル検索構成を示しています。

truncationDimension は圧縮プロパティです。スカラー圧縮やバイナリ圧縮などの圧縮方法と組み合わせて、メモリ内のベクトルグラフを圧縮する度合いを指定します。バイナリ量子化を使用する truncationDimension には、1,024 以上をお勧めします。ディメンションが 1,000 未満の場合、MRL とバイナリ圧縮を使用すると、検索結果の品質が低下します。

{ 
  "vectorSearch": { 
    "profiles": [ 
      { 
        "name": "use-bq-with-mrl", 
        "compression": "use-mrl,use-bq", 
        "algorithm": "use-hnsw" 
      } 
    ],
    "algorithms": [
       {
          "name": "use-hnsw",
          "kind": "hnsw",
          "hnswParameters": {
             "m": 4,
             "efConstruction": 400,
             "efSearch": 500,
             "metric": "cosine"
          }
       }
    ],
    "compressions": [ 
      { 
        "name": "use-mrl", 
        "kind": "truncation", 
        "rerankWithOriginalVectors": true, 
        "defaultOversampling": 10, 
        "truncationDimension": 1024
      }, 
      { 
        "name": "use-bq", 
        "kind": "binaryQuantization", 
        "rerankWithOriginalVectors": true,
        "defaultOversampling": 10
       } 
    ] 
  } 
}

MRL の要件を満たすすべて指定されたベクトルフィールド定義の例を次に示します。

ベクトルフィールドは、Edm.Half 型または Edm.Single 型である必要があることを思い出してください。ベクトルフィールドには、アルゴリズムと圧縮設定を決定する vectorSearchProfile プロパティが必要です。ベクトルフィールドには、スコアリングとランク付けの結果のディメンション数を指定するために使用される dimensions プロパティがあります。その値は、使用しているモデルのディメンション制限である必要があります (text-embedding-3-small の場合は 1,536)。

{
    "name": "text_vector",
    "type": "Collection(Edm.Single)",
    "searchable": true,
    "filterable": false,
    "retrievable": false,
    "stored": false,
    "sortable": false,
    "facetable": false,
    "key": false,
    "indexAnalyzer": null,
    "searchAnalyzer": null,
    "analyzer": null,
    "normalizer": null,
    "dimensions": 1536,
    "vectorSearchProfile": "use-bq-with-mrl",
    "vectorEncoding": null,
    "synonymMaps": []
}

オプション 2: ベクトルフィールドに狭いデータ型を割り当てる

ベクトルサイズを小さくする簡単な方法は、埋め込みをより小さなデータ形式で保存することです。ほとんどの埋め込みモデルでは 32 ビット浮動小数点数が出力されますが、ベクトルを量子化する場合、または埋め込みモデルでネイティブにサポートされている場合は、float16、int16、または int8 が出力される可能性があります。この場合、float32 よりも大幅に小さくなります。ナローデータ型をベクトルフィールドに割り当てることで、これらの小さなベクトルサイズに対応できます。ベクトルインデックスでは、ナローデータ型の方がストレージの消費量が少なくなります。

推奨される使用方法については、「ベクトルフィールドに使用されるデータ型」を確認してください。
- Collection(Edm.Single) 32 ビット浮動小数点 (既定値)
- Collection(Edm.Half) 16 ビット浮動小数点 (ナロー)
- Collection(Edm.Int16) 16 ビット符号付き整数 (ナロー)
- Collection(Edm.SByte) 8 ビット符号付き整数 (ナロー)
- Collection(Edm.Byte) 8 ビット符号なし整数 (パックされたバイナリデータ型でのみ使用できます)

そのリストから、埋め込みモデルの出力、またはカスタム量子化の対象となるベクトルに対して有効なデータ型を決定します。

次の表は、追加の量子化なしでナローデータ型 (Collection(Edm.Half)) を使用できるいくつかの埋め込みモデルへのリンクを示しています。追加の作業なしで float32 から float16 (Collection(Edm.Half) を使用) にキャストできます。

埋め込みモデル	ネイティブ出力	Azure AI 検索でこの型を割り当てる
text-embedding-ada-002	`Float32`	`Collection(Edm.Single)` または `Collection(Edm.Half)`
text-embedding-3-small	`Float32`	`Collection(Edm.Single)` または `Collection(Edm.Half)`
text-embedding-3-large	`Float32`	`Collection(Edm.Single)` または `Collection(Edm.Half)`
int8 embedding_type を使用した Cohere V3 埋め込みモデル	`Int8`	`Collection(Edm.SByte)`

モデルがより小さなデータ形式で埋め込みを生成する場合、またはベクトルをより小さな形式に変換するカスタム量子化がある場合は、他のナローデータ型を使用できます。

狭いデータ型のトレードオフを理解していることを確認します。 Collection(Edm.Half) には含まれる情報が少ないため、解像度が低くなります。データが同種または高密度の場合、追加の詳細情報や微妙な差異が失われると、近くのベクトルを区別するために使用できる詳細情報が少なくなるため、クエリ時に許容できない結果になることがあります。
インデックスを定義してビルドします。この手順では、Azure portal、Create or Update Index (REST API)、または Azure SDK パッケージを使用できます。
結果を確認する。ベクトルフィールドが取得可能としてマークされている場合は、Search エクスプローラーまたは Search - POST を使用して、フィールドのコンテンツがデータ型と一致することを確認します。

ベクトルインデックスのサイズを確認するには、Azure portal または GET Statistics (REST API) を使用します。

Note

フィールドのデータ型は、物理データ構造を作成するために使用されます。後でデータ型を変更する場合は、インデックスを削除して再構築するか、新しい定義で 2 つ目のフィールドを作成します。

オプション 3: `stored` プロパティを設定して、取得可能なストレージを削除する

stored プロパティはベクトルフィールド定義のブール値であり、取得可能なベクトルフィールドのコンテンツにストレージが割り当てられているかどうかを決定します。 stored プロパティの既定値は True です。クエリ応答にベクトルのコンテンツが必要ない場合は、stored を false に設定することで、フィールドごとに最大 50% のストレージ削減できます。

stored を false に設定する際の考慮事項:

ベクトルは人間には判読できないため、RAG シナリオで LLM に送信される結果や、検索ページに表示される結果では省略できます。ただし、ベクトルの内容を消費するダウンストリームプロセスでベクトルを使用している場合は、ベクトルを維持してください。
なお、インデックス作成戦略にドキュメントの部分的な更新 (ドキュメントの "merge" や "mergeOrUpload" など) を取り入れている場合、stored を false に設定すると、格納されていないフィールドのベクトルがマージ中に省略されますのでご注意ください。各 "merge" または "mergeOrUpload" 操作では、更新する他の非ベクトルフィールドに加えてベクトルフィールドを指定する必要があり、指定しない場合ベクトルは削除されます。

stored 属性は元に戻せないことに注意してください。これは、物理データ構造が作成される際、ベクトルフィールドのインデックス作成中に設定されます。後で取得可能なベクトルコンテンツが必要になった場合は、インデックスを削除して再構築するか、新しい属性を持つ新しいフィールドを作成して読み込む必要があります。

次の例は、検索インデックスのフィールドコレクションを示しています。ベクトルフィールドの取得可能なストレージを完全に削除するには、stored を false に設定します。

PUT https://[service-name].search.windows.net/indexes/demo-index?api-version=2024-07-01 
   Content-Type: application/json  
   api-key: [admin key]  
 
     { 
       "name": "demo-index", 
       "fields": [ 
         { 
           "name": "vectorContent", 
           "type": "Collection(Edm.Single)", 
           "retrievable": false, 
           "stored": false, 
           "dimensions": 1536, 
           "vectorSearchProfile": "vectorProfile" 
         } 
       ] 
     }

重要なポイント:

ベクトルフィールドにのみ適用されます。
メモリではなくディスク上のストレージに影響し、クエリにはまったく影響しません。クエリ実行では、stored プロパティの影響を受けない別のベクトルインデックスが使用されます。
stored プロパティはベクトルフィールドのインデックス作成時に設定され、元に戻すことはできません。後で取得可能なコンテンツが必要になった場合は、インデックスを削除して再構築するか、新しい属性を持つ新しいフィールドを作成して読み込む必要があります。
既定値は、true に設定された stored と false に設定された retrievable です。既定の構成では、取得可能なコピーが保存されますが、結果では自動的に返されません。 stored が true の場合、インデックスを再構築しなくても、いつでも retrievable を true と false の間で切り替えられます。 stored が false の場合、retrievable は false である必要があり、変更できません。

例: ベクトル圧縮方法

次のコードは、量子化、ナローデータ型、および保存されたプロパティの使用を示す Python コードです。コードサンプル: Python を使用したベクトル量子化とストレージオプション。

このコードでは、各オプションのストレージおよびベクトルインデックスサイズを作成して比較します。

****************************************
Index Name: compressiontest-baseline
Storage Size: 21.3613MB
Vector Size: 4.8277MB
****************************************
Index Name: compressiontest-compression
Storage Size: 17.7604MB
Vector Size: 1.2242MB
****************************************
Index Name: compressiontest-narrow
Storage Size: 16.5567MB
Vector Size: 2.4254MB
****************************************
Index Name: compressiontest-no-stored
Storage Size: 10.9224MB
Vector Size: 4.8277MB
****************************************
Index Name: compressiontest-all-options
Storage Size: 4.9192MB
Vector Size: 1.2242MB

Search API では、インデックスレベルでストレージとベクトルサイズがレポートされるため、フィールドではなくインデックスが比較の基準である必要があります。ベクトルサイズを取得するには、GET Index Statistics または Azure SDK の同等の API を使用します。

オーバーサンプリングを使用して量子化されたベクトルフィールドのクエリを実行する

圧縮または量子化されたベクトルフィールドのクエリ構文は、オーバーサンプリングまたは元のベクトルによる再ランク付けに関連付けられたパラメーターをオーバーライドしない限り、非圧縮ベクトルフィールドの場合と同じです。

インデックス内のベクトル圧縮定義には、より小さなベクトルインデックスの影響を軽減するための rerankWithOriginalVectors と defaultOversampling の設定があることを思い出してください。既定値をオーバーライドして、クエリ時の動作を変更できます。たとえば、defaultOversampling が 10.0 の場合は、クエリ要求で別のものに変更できます。

インデックスに明示的に rerankWithOriginalVectors または defaultOversampling の定義がない場合でも、オーバーサンプリングパラメータを設定できます。クエリ時に oversampling を指定すると、そのクエリのインデックス設定をオーバーライドし、有効な rerankWithOriginalVectors を true としてクエリを実行できます。

POST https://[service-name].search.windows.net/indexes/demo-index/docs/search?api-version=2024-07-01   
  Content-Type: application/json   
  api-key: [admin key]   

    {    
       "vectorQueries": [
            {    
                "kind": "vector",    
                "vector": [8, 2, 3, 4, 3, 5, 2, 1],    
                "fields": "myvector",
                "oversampling": 12.0,
                "k": 5   
            }
      ]    
    }

重要なポイント:

ベクトルプロファイルの割り当てに従い、ベクトル圧縮の対象となるベクトルフィールドに適用されます。
インデックスの圧縮構成でオーバーサンプリングまたは再ランク付けオプションが指定されていない場合でも、defaultOversampling 値をオーバーライドするか、クエリ時にオーバーサンプリングを実施します。

次の方法で共有

量子化、ナローデータ型、ストレージオプションを使用してベクトルサイズを小さくする

オプションを評価する

オプション 1: 量子化を構成する

検索インデックスに "compressions" を追加する

HNSW アルゴリズムを追加する

新しいベクトルプロファイルを作成して割り当てる

Azure AI Search でのスカラー量子化のしくみ

Azure AI 検索でのバイナリ量子化のしくみ

MRL 圧縮と切り詰められたディメンションを使用する (プレビュー)

要件

サポートされるクライアント

MRL 拡張テキスト埋め込みの使用方法

MRL をサポートするベクトル検索構成の例

オプション 2: ベクトルフィールドに狭いデータ型を割り当てる

オプション 3: `stored` プロパティを設定して、取得可能なストレージを削除する

例: ベクトル圧縮方法

オーバーサンプリングを使用して量子化されたベクトルフィールドのクエリを実行する

関連項目

フィードバック

その他のリソース

次の方法で共有

量子化、ナロー データ型、ストレージ オプションを使用してベクトル サイズを小さくする

オプションを評価する

オプション 1: 量子化を構成する

検索インデックスに "compressions" を追加する

HNSW アルゴリズムを追加する

新しいベクトル プロファイルを作成して割り当てる

Azure AI Search でのスカラー量子化のしくみ

Azure AI 検索でのバイナリ量子化のしくみ

MRL 圧縮と切り詰められたディメンションを使用する (プレビュー)

要件

サポートされるクライアント

MRL 拡張テキスト埋め込みの使用方法

MRL をサポートするベクトル検索構成の例

オプション 2: ベクトル フィールドに狭いデータ型を割り当てる

オプション 3: stored プロパティを設定して、取得可能なストレージを削除する

例: ベクトル圧縮方法

オーバーサンプリングを使用して量子化されたベクトル フィールドのクエリを実行する

関連項目

フィードバック

その他のリソース

量子化、ナローデータ型、ストレージオプションを使用してベクトルサイズを小さくする

新しいベクトルプロファイルを作成して割り当てる

オプション 2: ベクトルフィールドに狭いデータ型を割り当てる

オプション 3: `stored` プロパティを設定して、取得可能なストレージを削除する

オーバーサンプリングを使用して量子化されたベクトルフィールドのクエリを実行する