針對每個向量欄位，Azure AI 搜尋使用欄位指定的演算法參數建構內部向量索引。 Azure AI 搜尋對向量索引大小施加配額，因此您應該要了解如何估計和監視向量大小，確保您不超過限制。
附註
關於術語的附註。 在內部，搜尋索引的實體資料結構包括原始內容（用於需要未斷詞內容的擷取模式）、反向索引（用於可搜尋的文字欄位），以及向量索引（用於可搜尋的向量欄位）。 本文說明每個向量欄位背後內部向量索引的限制。
秘訣
向量優化技術 現已正式推出。 使用縮小數據類型、純量和二進位量化，以及消除備援記憶體等功能，以減少您的向量配額和記憶體配額耗用量。
附註
並非所有演算法都會取用向量索引大小配額。 系統會根據近似鄰近搜尋的記憶體需求來建立向量配額。 使用階層式導覽小型世界 (HNSW) 演算法建立的向量欄位，在查詢執行期間必須位於記憶體中，因為圖形式周遊的隨機存取本質。 使用詳盡 KNN 演算法的向量欄位會在查詢執行期間動態載入到頁面中的記憶體中，因此不會耗用向量配額。
配額和向量索引大小的要點
向量索引大小以位元組為單位測量。
服務的總記憶體包含所有向量索引檔案。 Azure AI 搜尋會針對不同的用途維護向量索引檔案的不同複本。 我們提供了額外的選項，藉由排除其中一些複本來減少 向量索引的儲存額外負荷 。
向量配額會依每個分割區在整個搜尋服務上強制執行。 如果您新增分割區，向量配額也會增加。 新服務每個分割區的向量配額較高。 如需詳細資訊，請參閱向量索引大小限制。
如何檢查分割區大小和數量
如果您不確定搜尋服務限制為何，以下是取得該資訊的兩種方式：
在 Azure 入口網站的 [搜尋服務概 觀 ] 頁面上，[ 屬性 ] 索引卷標和 [ 使用量 ] 索引卷標都會顯示分割區大小和記憶體，以及向量配額和向量索引大小。
在 Azure 入口網站的 [ 調整 ] 頁面上，您可以檢閱分割區的數目和大小。
您的向量限制會根據您的 服務建立日期而有所不同。
如何取得向量索引大小
向量計量的要求是資料平面作業。 您可以使用 Azure 入口網站、REST API 或 Azure SDK，透過服務統計資料和個別索引，取得服務層級的向量使用量。
每個索引的向量大小
若要取得每個索引的向量索引大小，請選取 [搜尋管理>索引] 以檢視索引清單和文件計數、記憶體內向量索引的大小，以及儲存在磁碟上的索引大小總計。
回想一下，向量配額是以記憶體限制為基礎。 對於使用 HNSW 演算法建立的向量索引，所有可搜尋的向量索引都會永久載入記憶體中。 對於使用詳盡 KNN 演算法建立的索引，向量索引會在查詢期間依序以區塊方式載入。 沒有詳盡 KNN 索引的記憶體落地需求。 記憶體中載入頁面的存留期類似於文字搜尋，而且沒有其他計量適用於完整 KNN 索引，除了總記憶體之外。
下列螢幕快照顯示相同向量索引的兩個版本。 使用 HNSW 演算法建立了一個版本，其中向量圖形是駐留在記憶體中的。 另一個版本是使用詳盡的 KNN 演算法所建立。 使用詳盡的 KNN 時，沒有專門的記憶體內向量索引，因此門戶會顯示 0 MB 的向量索引大小。 這些向量仍存在且會計算在整體記憶體大小中，但不會佔用向量索引大小計量所追蹤的記憶體內部資源。
每個服務的向量大小
若要取得整個搜尋服務的向量索引大小，請選取 [概觀] 頁面的 [使用量] 索引卷標。入口網站頁面每隔幾分鐘重新整理一次，因此，如果您最近更新索引，請先等候一點再檢查結果。
較舊版的標準 1 (S1) 搜尋服務的螢幕擷取畫面如下，該服務是為一個分割區和一個複本所設定的。
記憶體配額是磁碟條件約束，包含搜尋服務的所有索引 (向量和非向量)。
向量索引大小配額是記憶體條件約束。 這是載入針對搜尋服務上每個向量欄位所建立之所有內部向量索引所需的記憶體量。
螢幕擷取畫面顯示索引 (向量和非向量) 耗用近 460 MB 的可用磁碟記憶體。 向量索引在服務層級耗用近 93 MB 的記憶體。
![[概觀] 頁面使用量索引標籤的螢幕擷取畫面，顯示相較於配額的向量索引耗用量。](media/vector-search-index-size/portal-vector-index-size.png#lightbox)
新增或移除分割區時，記憶體和向量索引大小的配額都會增加或減少。 如果您更改分割區數量，格子會顯示存儲和向量配額的相應變動。
附註
在磁碟上，向量索引不是 93 MB。 磁碟上的向量索引所占用的空間是記憶體中向量索引的三倍。 如需詳細資料，請參閱向量欄位如何影響磁碟儲存體。
影響向量索引大小的因素
有三個主要元件會影響內部向量索引的大小：
- 資料的原始大小
- 所選演算法的額外負荷
- 刪除或更新索引內文件的額外負荷
資料的原始大小
每個向量都是單精確度浮點數的陣列，以類型 Collection(Edm.Single) 的欄位表示。
向量資料結構需要儲存體，在下列計算中以資料的「原始大小」表示。 使用此「原始大小」來估計向量欄位的向量索引大小需求。
一個向量的儲存大小取決於其維度。 請將一個向量的大小乘以包含該向量欄位的文件數目，以取得「原始大小」：
raw size = (number of documents) * (dimensions of vector field) * (size of data type)
| EDM 資料類型 | 資料類型的大小 |
|---|---|
Collection(Edm.Single) |
4 個位元組 |
Collection(Edm.Half) |
2 個位元組 |
Collection(Edm.Int16) |
2 個位元組 |
Collection(Edm.SByte) |
1 個位元組 |
所選演算法的記憶體額外負荷
每個近似最近鄰居 (ANN) 演算法都會在記憶體中產生額外的資料結構，以啟用有效率的搜尋。 這些結構會耗用記憶體內的額外空間。
針對 HNSW 演算法，未壓縮 float32 （Edm.Single） 向量的記憶體額外負荷範圍介於 1% 到 20% 之間。
隨著維度增加，記憶體額外負荷百分比會減少。 這是因為向量的原始大小會增加大小，而儲存圖形連線資訊的其他數據結構則保留給定 m的固定大小。 因此，這些額外數據結構的相對影響會隨著整體向量大小而降低。
記憶體額外負荷會隨著 HNSW 參數 m的較大值而增加，這會指定索引建構期間為每個新向量建立的雙向連結數目。 這是因為每個連結在每份文件中大約貢獻 8 到 10 個位元組，而總額外負荷會隨著 m 按比例調整。
下表摘要說明 未壓縮 向量字段內部測試中觀察到的額外負荷百分比：
| 維度 | HNSW 參數 (m) | 額外負荷百分比 |
|---|---|---|
| 96 | 4 | 20% |
| 200 | 4 | 8% |
| 768 | 4 | 2% |
| 1536 | 4 | 1% |
| 3072 | 4 | 0.5% |
這些結果示範 HNSW 演算法的維度、HNSW 參數 m 和記憶體額外負荷之間的關聯性。
對於使用壓縮技術的向量字段，例如 純量或二進位量化，額外負荷百分比似乎耗用了總向量索引大小的較大百分比。 隨著數據的大小減少，用來儲存圖形連線資訊的固定大小數據結構的相對影響會變得更重要。
刪除或更新索引內文件的額外負荷
刪除或更新具有向量欄位的文件時 (更新會在內部以刪除和插入作業表示)，基礎文件會在後續查詢期間標示為已刪除和已略過。 當新文件編製索引且內部向量索引增長時，系統會清除這些已刪除的文件並回收資源。 這表示您可能會觀察到刪除文件與釋放基礎資源之間有延遲的情形。
我們將這稱為已刪除的文件比例。 由於已刪除的文件比率取決於您服務的索引編製特性，因此沒有通用啟發學習法來估計此參數，而且沒有 API 或指令碼傳回服務的有效比率。 我們觀察到一半的客戶具有小於 10% 的已刪除文件比率。 如果您傾向於執行高頻率刪除或更新，則可能會觀察到較高的已刪除文件比率。
這是影響向量索引大小的另一個因素。 不幸的是，我們沒有一種機制可呈現目前刪除的文件比率。
記憶體中資料的總大小估算
將先前描述的因素納入考慮，若要估計向量索引的總大小，請使用下列計算方式：
(raw_size) * (1 + algorithm_overhead (in percent)) * (1 + deleted_docs_ratio (in percent))
例如，若要計算 raw_size，假設您使用熱門的 Azure OpenAI 模型，text-embedding-ada-002 具有 1,536 個維度。 這表示一份文件將會取用 1,536 個 Edm.Single (浮點數)，或 6,144 個位元組，因為每個 Edm.Single 為 4 個位元組。 1,000 份具有單一、1,536 維度向量欄位的文件，總共會取用 1000 份文件 x 1536 個浮點數/文件 = 1,536,000 個浮點數，或 6,144,000 個位元組。
如果您有多個向量欄位，則必須針對索引內的每個向量欄位執行此計算，並將其全部加在一起。 例如，1,000 份具有兩個 1,536 維度向量欄位的文件，取用 1000 份文件 x 2 個欄位 x 1536 個浮點數/文件 x 4 位元組/浮點數 = 12,288,000 個位元組。
若要取得向量索引大小，請將這個 raw_size 乘以 演算法額外負荷和已刪除的文件比率。 如果所選 HNSW 參數的演算法額外負荷為 10%，且已刪除的文件比率為 10%，則我們會取得：6.144 MB * (1 + 0.10) * (1 + 0.10) = 7.434 MB。
向量欄位如何影響磁碟儲存體
本文多半提供記憶體向量大小的相關資訊。 深入瞭解 向量索引的儲存負荷。