ベクトル インデックス サイズの制限

ベクトル フィールドを使用してドキュメントにインデックスを作成すると、Azure AI Search では、フィールドに指定したアルゴリズム パラメーターを使用して内部ベクトル インデックスを構築します。 Azure AI Search ではベクトル インデックスのサイズに制限があるため、ベクトル インデックスのサイズに関するメトリックを取得する方法と、ユース ケースのベクトル インデックスのサイズの要件を推定する方法を理解することが重要です。

ベクトル サイズの制限に関する重要なポイント

ベクトル インデックスのサイズはバイト単位で測定されます。 サイズの制約は、ベクトル検索用に予約されたメモリに基づいていますが、サービス レベルでのストレージにも影響します。 サイズの制約は、サービス レベル (または SKU) によって異なります。

このサービスでは、検索サービスのパーティションの数に基づくベクトル インデックス サイズ クォータが適用されます。パーティションあたりのクォータは、レベルとサービスの作成日によって異なります (サービス制限の「ベクトル インデックス サイズ」を参照してください)。

サービスに追加するパーティションが追加されるたびに、使用可能なベクトル インデックス サイズのクォータが増加します。 このクォータは、サービスの正常性を保つためのハード制限です。 また、これはベクトル サイズがこの制限を超えると、それ以降のインデックス作成要求が失敗することを意味します。 一部のベクトル ドキュメントを削除するか、パーティションでスケールアップを行うことで、使用可能なクォータを解放すれば、インデックス作成を再開できます。

次の表は、パーティションごと、およびすべてのパーティションが使用中の場合のサービスごとのベクトル クォータを示しています。 この表は、2023 年 7 月 1 日以降に作成された新しい検索サービスに関するものです。 古い検索サービスの制限や、パーティションごとの埋め込みのおおよその数の制限など、詳細については、「検索サービスの制限」を参照してください。

レベル メジャー グループ ストレージ (GB) パーティションあたりのベクトル クォータ (GB) サービスあたりのベクトル クォータ (GB)
Basic 1 2 1 1
S1 12 25 3 36
S2 12 100 12 144
S3 12 200 36 432
L1 12 1,000 12 144
L2 12 2,000 36 432

重要なポイント:

  • ストレージ クォータは、すべての検索データについての検索サービスで使用できる物理ストレージです。 Basic では、サービス上のすべてのデータを格納する必要がある 2 GB の 1 つのパーティションがあります。 S1 のパーティション数の上限は 12 であり、それぞれのサイズは 25 GB で、すべての検索データに対する上限は 300 GB です。

  • ベクトル クォータは、各ベクトル フィールドについて作成されたベクトル インデックスであり、パーティション レベルで適用されます。 Basic では、パーティションが 1 つしかないため、すべてのベクトル フィールドの合計が 1 GB を超えることはできません。 最大 12 個のパーティションをもつことができる S1 では、ベクトル データのクォータは、1 つのパーティションだけを割り当てた場合は 3 GB で、12 個すべてのパーティションを割り当てた場合は最大の 36 GB となります。 パーティションとレプリカの詳細については、「容量の見積もりと管理」を参照してください。

サービスの作成日を確認する方法

2023 年 7 月 1 日以降に作成されたサービスは、同じレベルの以前のものと比べて少なくとも 2 倍のベクトル ストレージを提供します。

  1. Azure portal で、リソース グループを開きます。

  2. 左側のナビゲーション ウィンドウの [設定] で、[デプロイ] を選択します。

  3. 検索サービス デプロイの場所を見つけます。 デプロイが多数ある場合は、フィルターを使用して "検索" を探します。

  4. デプロイを選択します。 複数のデプロイがある場合は、一つずつクリックして、それがご利用の検索サービスであるかどうかを確認します。

    Screenshot of a filtered deployments list.

  5. デプロイの詳細を展開します。 "作成済み" の表記と作成日が表示されるはずです。

    Screenshot of the deployment details showing creation date.

  6. 検索サービスの古さがわかったので、以下でサービスの作成方法に基づくベクトル クォータの制限を確認します。

ベクトル インデックス サイズを取得する方法

ベクトル メトリックの要求は、データ プレーン操作です。 Azure portal、REST API、または Azure SDK を使用して、サービス統計情報と個々のインデックスを通して、サービス レベルでベクトルの使用状況を取得できます。

使用状況の情報は、[概要] ページの [使用状況] タブで確認できます。ポータル ページは数分ごとに更新されるため、インデックスを更新したばかりの場合は、少し待ってから結果を確認してください。

次のスクリーンショットは、1 つのパーティションと 1 つのレプリカ用に構成された、新しい Standard 1 (S1) レベルのものです。 ベクトル インデックス クォータは、メガバイト単位で測定され、各ベクトル フィールドに対して作成された内部ベクトル インデックスのことを指します。 全体として、インデックスは使用可能なストレージの内の約 460 MB を消費していますが、ベクトル インデックス コンポーネントが占めているのは、この検索サービスで使用されている 460 MB の内の 93 MB に過ぎません。

Screenshot of the Overview page's usage tab showing vector index consumption against quota.

[使用状況] タブのこのタイルは、検索サービス レベルでのベクトル インデックスの消費量を追跡します。 検索サービスの容量を増減すると、タイルはそれに応じた変化を反映します。

ベクトル インデックスのサイズに影響を与える要因

内部ベクトル インデックスのサイズに影響を与える 3 つの主要なコンポーネントがあります。

  • 生のデータのサイズ
  • 選択したアルゴリズムからのオーバーヘッド
  • インデックス内のドキュメントの削除または更新によるオーバーヘッド

生のデータのサイズ

各ベクトルは、Collection(Edm.Single) 型のフィールド内の単精度浮動小数点数の配列です。 現時点では、単精度浮動小数点のみがサポートされています。

ベクトル データ構造体には、データの "生のサイズ" として次の計算で表されるストレージが必要です。 この "生のサイズ" を使用して、ベクトル フィールドのベクトル インデックス サイズの要件を推定します。

1 つのベクトルのストレージのサイズは、その次元によって決まります。 1 つのベクトルのサイズに、そのベクトル フィールドを含むドキュメントの数を乗算して、"生のサイズ" を取得します。

raw size = (number of documents) * (dimensions of vector field) * (size of data type)

Edm.Single の場合、データ型のサイズは 4 バイトです。

選択したアルゴリズムに起因するメモリ オーバーヘッド

すべての近似最近傍 (ANN) アルゴリズムは、効率的な検索を実現するために、メモリ内に追加のデータ構造体を生成します。 これらの構造体は、メモリ内で余分な領域を消費します。

HNSW アルゴリズムの場合、メモリ オーバーヘッドの範囲は 1% ~ 20% です。

ベクトルの生のサイズが増加するため、次元が高くなるとメモリ オーバーヘッドは小さくなりますが、追加のデータ構造体はグラフ内の接続に関する情報を格納するため固定サイズのままです。 その結果、追加のデータ構造体による影響は、全体のサイズに占める部分としては小さくなります。

HNSW パラメーター m の値を大きくすると、メモリ オーバーヘッドが大きくなります。これは、このパラメーターによって、インデックスの構築中に新しいベクトルごとに作成される双方向リンクの数が決まるためです。 これは、m がドキュメントあたり約 8 ~ 10 バイトに m を掛けた値であるためです。

次の表は、内部テストで観察されたオーバーヘッドの割合をまとめたものです。

ディメンション HNSW パラメーター (m) オーバーヘッドの割合
96 4 20%
200 4 8%
768 4 2%
1536 4 1%

これらの結果は、次元、HNSW パラメーター m、HNSW アルゴリズムのメモリ オーバーヘッドの関係を示しています。

インデックス内のドキュメントの削除または更新によるオーバーヘッド

ベクトル フィールドをもつドキュメントが削除または更新された場合 (更新は内部的に削除操作と挿入操作として表される)、基になるドキュメントは削除済みとしてマークされ、後続のクエリ中にスキップされます。 新しいドキュメントのインデックスが作成され、内部ベクトル インデックスが大きくなると、システムはこれらの削除されたドキュメントをクリーンアップし、リソースを回収します。 このことは、ドキュメントを削除してから、基になっているリソースが解放されるまでに、遅延が発生する可能性があることを示しています。

これを「削除されたドキュメント率」と称します。 削除されたドキュメント率はサービスのインデックス作成特性によって変化するため、このパラメーターを推定する普遍的なヒューリスティックはなく、サービスについての有効な比率を返す API やスクリプトはありません。 削除されたドキュメント率は、お客様の半数で 10% 未満であることを確認しています。 削除や更新の頻度が高い傾向にある場合は、削除されたドキュメント率が高くなる可能性があります。

これが、ベクトル インデックスのサイズに影響を与えるもう 1 つの要因です。 残念ながら、現在の削除されたドキュメント率を表出させるメカニズムはありません。

メモリ内のデータの合計サイズの見積もり

ベクトル インデックスの合計サイズを推定するには、次の計算を使用します。

(raw_size) * (1 + algorithm_overhead (in percent)) * (1 + deleted_docs_ratio (in percent))

たとえば、1,536 次元の一般的な Azure OpenAI モデル text-embedding-ada-002 を使用しているとして、raw_size を計算するとします。 これは、1 つのドキュメントが 1,536 Edm.Single (floats) または 6,144 バイトを消費することを意味しています (各 Edm.Single は 4 バイトであるため)。 単一の 1,536 次元ベクトル フィールドをもつ 1,000 のドキュメントは、合計で 1,000 ドキュメント x 1536 floats/doc = 1,536,000 floats、つまり 6,144,000 バイトを消費します。

複数のベクトル フィールドがある場合は、インデックス内の各ベクトル フィールドについてこの計算を実行し、それらすべてを加算する必要があります。 たとえば、2 つの 1,536 次元ベクトル フィールドがある 1,000 個のドキュメントでは、1,000 doc x 2 フィールド x 1536 floats/doc x 4 バイト/float = 12,288,000 バイトを消費します。

ベクトル インデックス サイズを取得するには、この raw_sizeアルゴリズムのオーバーヘッド削除されたドキュメント率を乗算します。 選択した HNSW パラメーターのアルゴリズム オーバーヘッドが 10% で、削除されたドキュメント率が 10% の場合、6.144 MB * (1 + 0.10) * (1 + 0.10) = 7.434 MB となります。

ベクトル フィールドがディスク ストレージに与える影響

ベクトル データのディスク ストレージ オーバーヘッドは、ベクトル インデックス サイズの約 3 倍のサイズです。

ストレージのクォータ とベクトル インデックス サイズのクォータ

サービス ストレージとベクトル インデックス サイズ クォータは、別個のクォータではありません。 ベクトル インデックスは、全体として検索サービスのストレージ クォータに影響します。 たとえば、ストレージ クォータが使い果たされていて、ベクトル クォータには残りがある場合でも、パーティションでスケールアップしてストレージ クォータを増やすか、ドキュメント (テキストまたはベクトル) を削除してストレージ使用量を減らすまで、それ以上インデックスを作成することはできません。この場合、ドキュメントがベクトル ドキュメントかどうかは関係ありません。 同様に、ベクトル クォータが使い果たされていて、ストレージ クォータには残りがある場合、ベクトル ドキュメントを削除するか、パーティションでスケールアップして、ベクトル クォータが解放されるまで、インデックスを作成しようとしても失敗します。