Note
Azure AI 検索は、Azure ポータル、REST API、およびAzure SDKから使用できます。 また、Foundry IQ は、エンタープライズ コンテンツを、Microsoft Foundry ポータルのエージェントの再利用可能なアクセス許可に対応したナレッジ ベースに変換するマネージド ナレッジ レイヤーです。
埋め込み(異種コンテンツの数値表現)は、ベクター検索ワークロードの基礎です。 ただし、埋め込みのサイズにより、スケーリングが困難になり、処理にコストがかかります。 大規模な研究と製品化により、スケールを改善し、処理時間を短縮するための複数のソリューションが生み出されています。 Azure AI 検索は、高速かつ安価なベクター ワークロードのために、これらの機能の数を活用します。
この記事では、ベクター サイズとクエリの処理時間を短縮するのに役立つ、Azure AI 検索のすべての最適化手法について説明します。
ベクター最適化の設定は、検索インデックスのベクター フィールド定義で指定します。 この記事で説明するほとんどの機能は、最も安定した REST API バージョンおよびそのバージョンを対象とするAzure SDK パッケージで一般提供されています。
オプションを評価する
ベクター フィールドで使用されるストレージの量を減らすためのAzure AI 検索のアプローチを確認します。 これらのアプローチは相互に排他的ではありません。そのため、 ベクター サイズを最大に縮小するためにそれらを組み合わせることができます。
組み込みの量子化をお勧めします。メモリ と ディスク上のベクター サイズが最小限の労力で圧縮されるためです。 この方法は、ほとんどのシナリオで最もメリットが得られる傾向があります。 これに対し、狭い型 (float16 を除く) では作成に特別な労力が必要であり、 stored はディスク ストレージに保存されます。これはメモリほど高価ではありません。
| アプローチ | このアプローチを使用する理由 |
|---|---|
| スカラー量子化またはバイナリ量子化の追加 | ネイティブ float32 または float16 埋め込みを int8 (スカラー) またはバイト (バイナリ) に圧縮します。 このオプションを選択すると、クエリ のパフォーマンスが低下せず、メモリとディスク上のストレージが削減されます。 int8 や byte などのデータ型が小さいほど、埋め込み量が大きいデータ型よりもコンテンツが少ないベクター インデックスが生成されます。 情報損失をオフセットするために、組み込みの圧縮には、非圧縮埋め込みとオーバーサンプリングを使用してクエリ後の処理を行い、より関連性の高い結果を返すオプションが含まれています。 再ランク付けとオーバーサンプリングは、float32 または float16 フィールドの組み込みの量子化の特定の機能であり、カスタム量子化を受ける埋め込みでは使用できません。 |
| MRL対応テキスト埋め込み3モデルのディメンションをトランケートする | テキスト埋め込み 3 モデルでは、使用するディメンションが少なくなります。 Azure OpenAI では、これらのモデルは、異なるレベルの圧縮で複数のベクター表現を生成する Matryoshka Representation Learning (MRL) 手法で再トレーニングされます。 この方法では、セマンティック情報の損失を最小限に抑えながら、検索の高速化とストレージ コストの削減が実現されます。 Azure AI 検索では、MRL はスカラー量子化と二項量子化を補完します。 いずれかの量子化方法を使用する場合は、ベクター フィールドに truncateDimension プロパティを指定して、テキスト埋め込みの次元を減らすこともできます。 |
| 小さいプリミティブ データ型をベクター フィールドに割り当てる | float16、int16、int8、バイト (バイナリ) などの狭いデータ型では、メモリとディスクの領域が少なくなります。 ただし、ベクターを狭いデータ形式で出力する埋め込みモデルが必要です。 または、小さなデータを出力するカスタム量子化ロジックが必要です。 少ない労力を必要とする 3 番目のユース ケースは、ほとんどのモデルによって生成されたネイティブ float32 埋め込みを float16 に再キャストすることです。 バイナリ ベクトルの詳細については、「 バイナリ ベクトルのインデックスを作成する」を参照してください。 |
| 取得可能なベクターのオプションのストレージを排除する | クエリ応答で返されるベクターは、クエリの実行中に使用されるベクターとは別に格納されます。 ベクターを返す必要がない場合は、取得可能なストレージをオフにして、フィールドごとのディスクストレージ全体を最大 50% 削減できます。 |
空のインデックスに対してこれらのオプションをすべて定義します。 いずれかを実装するには、Azure ポータル、REST API、またはその API バージョンを対象とするAzure SDK パッケージを使用します。
インデックスを定義したら、ドキュメントを別の手順として読み込んでインデックスを作成できます。
例: ベクター圧縮手法によるベクター サイズ
Python を使用した
このコードでは、各ベクター ストレージ最適化オプションのストレージ インデックス サイズとベクター インデックス サイズを作成して比較します。 これらの結果から、 量子化 によってベクター サイズが最も小さくなりますが、複数のオプションを使用すると、最大のストレージ節約が実現されます。
| インデックス名 | ストレージ サイズ | ベクター サイズ |
|---|---|---|
| コンプレッションテスト-ベースライン | 21.3613 MB | 4.8277 MB |
| 圧縮テスト-スカラー圧縮 | 17.7604 MB | 1.2242 MB |
| compressiontest-narrow | 16.5567 MB | 2.4254 MB |
| 圧縮テスト-非格納 | 10.9224 MB | 4.8277 MB |
| 圧縮テスト-すべてのオプション | 4.9192 MB | 1.2242 MB |
Search Service REST API は、ストレージとベクター サイズをインデックス レベルで報告するため、フィールドではなくインデックスを比較する必要があります。 ベクター サイズを取得するには、Azure SDKで Indexes - Get Statistics (REST API) または同等の API を使用します。