ベクトルのストレージと処理を最適化するための方法を選択する
埋め込み、つまり異種コンテンツの数値表現は、ベクトル検索ワークロードの基礎ですが、埋め込みのサイズによってはスケーリングが困難になり、処理にコストがかかります。 大規模な研究と製品化により、スケールを改善し、処理時間を短縮するための複数の解決策が生み出されています。 Azure AI 検索は、これらの機能の多くを活用して、より高速で安価なベクトル ワークロードを実現します。
この記事では、ベクトルのサイズとクエリ処理時間を減らすのに役立つ Azure AI 検索のすべての最適化手法を示します。
ベクトル最適化の設定は、検索インデックスのベクトル フィールドの定義で指定します。 この記事で説明されているほとんどの機能は、2024-07-01 REST API とそのバージョンを対象とする Azure SDK パッケージで一般提供されています。 最新のプレビュー バージョンでは、ベクトル化に text-embedding-3-large または text-embedding-3-small を使用している場合、切り詰められたディメンションのサポートが追加されます。
オプションを評価する
ベクトル フィールドが使うストレージの量を減らすための Azure AI 検索での 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 パッケージを使用します。
インデックスが定義されると、別の手順としてドキュメントを読み込み、インデックスを作成できます。
例: ベクトル圧縮方法によるベクトルのサイズ
「コード サンプル: Python を使用するベクトル量子化とストレージ オプション」は、ベクトル ストレージの量子化、狭いデータ型、ストレージ プロパティの使用によって異なる複数の検索インデックスを作成する Python コード サンプルです。
このコードは、各ベクトル ストレージ最適化オプションについて、ストレージとベクトル インデックス サイズを作成して比較します。 これらの結果から、ベクトルのサイズが最も減るのは量子化ですが、ストレージの節約が最大になるのは複数のオプションを使った場合であることがわかります。
| [インデックス名] | ストレージ サイズ | ベクトルのサイズ |
|---|---|---|
| compressiontest-baseline | 21.3613 MB | 4.8277 MB |
| compressiontest-scalar-compression | 17.7604 MB | 1.2242 MB |
| compressiontest-narrow | 16.5567 MB | 2.4254 MB |
| compressiontest-no-stored | 10.9224 MB | 4.8277 MB |
| compressiontest-all-options | 4.9192 MB | 1.2242 MB |
Search API では、インデックス レベルでストレージとベクトル サイズがレポートされるため、フィールドではなくインデックスが比較の基準である必要があります。 ベクトル サイズを取得するには、GET Index Statistics または Azure SDK の同等の API を使用します。