選擇優化向量儲存和處理的方法
內嵌或異質內容的數值表示法是向量搜尋工作負載的基礎，但內嵌的大小使得難以調整和處理成本高昂。 重要的研究和產品化已產生多個解決方案，以改善規模並減少處理時間。 Azure AI 搜尋會利用這些功能，以更快且更便宜的向量工作負載。
本文列舉 Azure AI 搜尋服務中的所有優化技術，可協助您減少向量大小和查詢處理時間。
向量優化設定是在搜尋索引的向量欄位定義中指定。 本文所述的大部分功能在 2024-07-01 REST API 和以該版本為目標的 Azure SDK 套件中正式推出。 如果您使用文字內嵌-3-large 或 text-embedding-3-small 進行向量化，則 最新的預覽版本 會新增截斷維度的支援。
評估選項
檢閱 Azure AI 搜尋中的方法，以減少向量字段所使用的記憶體數量。 這些方法並非互斥，而且可以合併以達到向量大小縮減上限。
我們建議採用內建量化，因為會以最少的投入，壓縮記憶體「和」磁碟上的向量大小，而且在大部分案例中通常會提供最大效益。 相較之下，精簡類型 (除了 float16 之外) 需要特別投入，且 stored 會儲存在磁碟儲存體上，不像記憶體那般昂貴。
| 方法 | 為何要使用此選項 |
|---|---|
| 新增純量或二進位量化 | 使用量化將原生 float32 或 float16 內嵌壓縮為 int8 (純量) 或位元組 (二進位)。 此選項可減少記憶體和磁碟上的儲存空間，且查詢效能不會降低。 較小的資料類型 (例如 int8 或位元組) 會產生內容比較大內嵌少的向量索引。 為了克服資訊遺失，內建壓縮會包含使用未壓縮內嵌和過度取樣來傳回更相關結果的查詢後處理選項。 重新排名和過度取樣是 float32 或 float16 欄位內建量化的特定功能，無法用於進行自訂量化的內嵌。 |
| 截斷支援 MRL 的文字內嵌-3 模型維度（預覽） | 練習在文字內嵌-3 模型上使用較少維度的選項。 在 Azure OpenAI 上，這些模型已針對 Matryoshka 表示法學習 （MRL） 技術進行重新定型，可在不同壓縮層級產生多個向量表示法。 這種方法會產生更快的搜尋並降低儲存成本，且語意資訊遺失最少。 在 Azure AI 搜尋中，MRL 支援補充純量和二進位量化。 當您使用任一 truncateDimension 量化方法時，也可以指定向量欄位上的屬性，以減少文字內嵌的維度。 |
| 將較小的基本資料類型指派給向量欄位 | 精簡資料類型，例如 float16、int16、int8 和位元組 (二進位) 在記憶體和磁碟上耗用較少的空間，但您必須有內嵌模型，以精簡資料格式輸出向量。 或者，您必須具有輸出小型資料的自訂量化邏輯。 需要較少投入的第三個使用案例是將大部分模型所產生的原生 float32 內嵌重新轉換成 float16。 如需二進位向量的詳細資訊，請參閱索引二進位向量。 |
| 排除可擷取向量的選擇性儲存 | 查詢回應中傳回的向量會與查詢執行期間所使用的向量分開儲存。 如果您不需要傳回向量，您可以關閉可擷取的儲存空間，減少高達 50% 的整體各欄位磁碟記憶體。 |
所有這些選項都是在空的索引上定義。 若要實作其中任何一項，請使用 Azure 入口網站、REST API 或以該 API 版本為目標的 Azure SDK 套件。
定義索引之後，您可以載入文件並編製索引，作為個別步驟。
範例：向量壓縮技術的向量大小
程式代碼範例：使用 Python 的向量量化和儲存選項是 Python 程式代碼範例，可建立多個搜尋索引，這些索引會因使用向量記憶體量化、 縮小數據類型和 記憶體屬性而有所不同。
此程式代碼會為每個向量儲存優化選項建立和比較儲存和向量索引大小。 從這些結果中，您可以看到 量化 會減少向量大小最多，但如果您使用多個選項，則會節省最大的儲存空間。
| 索引名稱 | 儲存體大小 | 向量大小 |
|---|---|---|
| compressiontest-baseline | 21.3613MB | 4.8277MB |
| compressiontest-scalar-compression | 17.7604MB | 1.2242MB |
| compressiontest-narrow | 16.5567MB | 2.4254MB |
| compressiontest-no-stored | 10.9224MB | 4.8277MB |
| compressiontest-all-options | 4.9192MB | 1.2242MB |
搜尋 API 會報告索引層級的儲存空間和向量大小，因此索引和欄位不一定是比較的基礎。 使用 Azure SDK 中的 GET 索引統計資料或對等 API 來取得向量大小。