馬賽克 AI 向量搜尋是專為快速、可調整的擷取所建置。 向量搜尋效能取決於許多因素，包括 SKU 選擇、索引大小、查詢類型、向量維度、驗證方法，以及您的應用程式如何處理流量尖峰。 大部分的工作負載都表現良好，但針對您需要調整或優化延遲的情況，本指南會提供實用的秘訣和常見模式，以協助您設定系統以獲得最佳向量搜尋效能。
影響效能的因數
效能不是單一數位， 這是一個範圍，取決於工作負載特性、組態選擇和用戶端實作。 本指南旨在協助您建置清楚的心理模型，說明效能的運作方式，讓您可以更有效地使用馬賽克 AI 向量搜尋。
以下是影響系統運作方式的重要因素：
- SKU 選擇：標準或記憶體優化。
- 索引大小：儲存的向量數目。
- 內嵌大小：通常是 384–1536。
- 查詢類型：近似近鄰 （ANN） 或混合式。
- 要求的結果數目：較高的值會增加擷取時間。
- 內嵌類型：受控或自我管理。
- 查詢負載：一段時間后，有多少流量會叫用端點。
- 驗證方法：您的應用程式如何連線到 Databricks。
本文的其餘部分提供微調每個變數的實際秘訣，並說明它們如何影響真實世界部署中的搜尋延遲和查詢輸送量。
挑選正確的 SKU
馬賽克 AI 向量搜尋提供兩個 SKU，其設計目的是根據工作負載來平衡延遲、延展性和成本效益。 為您的應用程式選擇正確的 SKU 是第一個調整效能的槓桿。
通常：
- 當延遲很重要，且您的索引遠低於 320M 向量時，請選擇標準端點。
- 當您使用 10M+ 向量時，請選擇記憶體優化的端點、可以容忍一些額外的延遲，而且需要每個向量更高的成本效益（最高成本 7 倍）。
下表顯示一些預期的效能指導方針。
| SKU | 延遲 | QPS | 索引容量 | 向量搜尋單位 （VSU） 大小 |
|---|---|---|---|---|
| 標準 | 20–50 毫秒 | 30–200+ | 320M 向量 | 2M 向量 |
| 記憶體優化 | 300–500 毫秒 | 30–50 | 1B 向量 | 64M 向量 |
了解索引大小
當您的索引符合單一向量搜尋單位時，效能最高，且額外空間可處理額外的查詢負載。 當工作負載調整超過單一向量搜尋單位時（也就是標準向量 2M+ 向量或 64M+ 以用於儲存優化），延遲增加並關閉 QPS 點選。 最後，QPS 在大約 30 個 QPS （ANN） 上高原。
效能取決於每個工作負載特有的許多因素，例如查詢模式、篩選、向量維度和並行。 下列數位是參考點。
| SKU | Vectors | 尺寸 | 延遲 | QPS | 每月查詢 |
|---|---|---|---|---|---|
| 標準 | 10K | 768 | 20 毫秒 | 200+ | 500M+ |
| 10M | 768 | 40 毫秒 | 30 | 78M | |
| 100M | 768 | 50 毫秒 | 30 | 78M | |
| 記憶體優化 | 10M | 768 | 300 毫秒 | 50 | 130M |
| 100M | 768 | 400 毫秒 | 40 | 100M | |
| 1B | 768 | 500 毫秒 | 30 | 78M |
最小化內嵌大小
向量維度是指每個向量中的特徵數目。 一般值為 384、768、1024 或 1536。 較高的維度提供更具表現力的表示法，可改善品質，但會產生計算成本。 較低維度向量在擷取期間需要較少的計算，這可轉譯成更快的查詢時間和更高的QPS。 相反地，高維度向量會增加計算負載並減少輸送量。
一般規則是選擇最小維度，以保留使用案例的擷取品質。
例如，根據索引大小和查詢模式，將維度減少為 2 倍（例如，從 768 到 384）通常會將 QPS 改善約 1.5 倍，並將延遲減少約 20%。 這些收益在非常低的維度進一步增加。 例如，相較於數據表中顯示的768維度基準檢驗，使用64維度向量可提供大幅更高的QPS和明顯較低的延遲。 這讓 384 個維度和以下維度特別吸引高輸送量、延遲敏感的使用案例，只要擷取品質仍可接受。
使用 ANN 提高效率，並在必要時使用混合式
盡可能使用 ANN 查詢。 它們是最有計算效率且支援最高的 QPS。
必要時使用混合式搜尋。 混合式搜尋可改善某些應用程式中的召回率，尤其是網域特定關鍵詞很重要的地方。 混合式搜尋通常會使用與 ANN 一樣多的兩倍資源，而且可以大幅降低輸送量。
使用 10–100 個結果
每個查詢都包含參數 num_results ，這是要傳回的搜尋結果數目。 此值直接影響效能。 擷取更多結果需要更深入的索引掃描，這會增加延遲並減少QPS。 效果在較高的值上會變得更重要。 例如，增加 num_results 10 倍可能會增加查詢延遲，並根據索引大小和組態，將 QPS 容量減少 3 倍。
最佳做法是，除非您的應用程式特別需要更多，否則請保持在 num_results 10-100 的範圍內。 使用實際查詢來嘗試不同的 num_results 值，以瞭解對工作負載的影響。
避免針對生產環境調整為零
向量搜尋支援兩種具有不同效能取捨的內嵌類型。
受控內嵌是最方便的。 使用 Managed 內嵌，Databricks 會自動為您的數據列和查詢產生內嵌。 在查詢時，查詢文字會傳遞至服務端點的模型，以產生內嵌，這會增加延遲。 如果內嵌模型是外部的，它也會帶來額外的網路負荷。
自我管理內嵌可讓您事先計算內嵌，並在查詢時間直接傳遞向量。 這可避免產生運行時間，並啟用最快的擷取。 本文中包含的所有效能號碼都是以自我管理內嵌為基礎。
針對實時生產使用案例，請避免調整為零的模型端點。 冷啟動可能會延遲幾分鐘的回應，甚至會在查詢到達時造成失敗。
規劃查詢尖峰
本節描述流量增加的情況，以及如何保持在觸發延遲尖峰或 429 個錯誤（太多要求）的重要限制之下。
當負載適中時，延遲會保持低，當您接近最大QPS容量時，會逐漸增加。 當系統達到 100% QPS 容量時，就會開始傳回 429 錯誤。 如果您尚未設定適當的輪詢，應用程式可能會變得沒有回應。
429 錯誤可作為保護系統的安全機制。 它們會指示用戶端稍後回復並重試，讓端點保持狀況良好且回應，即使在突然的流量尖峰下也是如此。
最佳做法是使用 向量搜尋 Python SDK，其中包含內建輪詢和重試處理。
如果您使用 REST API，請使用抖動來實作指數輪詢。 請參閱 Azure 反模式。
搭配 OAuth 令牌使用服務主體
使用有效率的驗證方法獲得最佳效能。 Databricks 建議在所有生產環境中 搭配 OAuth 令牌使用服務主體 。 OAuth 存取令牌可提供更高的安全性，並利用網路優化的基礎結構，讓系統以完整容量運作。
避免使用個人存取令牌 （PAT），因為它們引進網路額外負荷、新增數百毫秒的延遲，並大幅減少端點可維持的 QPS。
使用 Python SDK
使用最新版本的 Python SDK，以受益於內建效能和可靠性優化。
跨查詢重複使用索引物件。 避免在每個要求中呼叫 client.get_index(...).similarity_search(...) ，因為此模式會增加不必要的延遲。
請改為初始化索引一次，並重複使用它：
# Initialize once
index = client.get_index(...)
# Then use it for every query
index.similarity_search(...)
在 MLFlow 環境中使用向量搜尋索引時，這很重要，您可以在端點初始化時建立索引對象，然後針對每個查詢重複使用它。
本指南特別有助於即時、區分延遲的應用程式。 在具有多個索引或 代表使用者授權 流程的 RAG 設定中，索引選取或認證僅在查詢時可用，因此初始化索引物件一次可能不可行。 在這些案例中，不需要此最佳化。
跨端點平行處理
Databricks 建議探索下列策略，以增加系統中的 QPS 總數：
- 跨端點分割索引。 如果您有多個索引，每個索引都會收到相當一部分的流量，請在不同的端點上裝載它們，以達到更高的總頻寬。
- 跨端點複寫索引。 如果大部分的流量達到單一索引，請在多個端點之間複製它。 在用戶端層級平均分割流量，以取得線性 QPS 收益。
利用負載測試來確保端點大小正確
負載測試會衡量向量搜尋端點在不同流量層級下的表現，模擬真實世界的使用情況，並幫助你正確調整端點規模以符合生產需求。 請參閱 「為向量搜尋端點配置負載測試 」，了解如何建立及執行負載測試。