從原型到生產：Databricks AI Search 的高 QPS

搜尋無處不在：零售網站的產品發現、智慧電視的語音查詢、每個資訊流中的推薦，以及賬戶查詢時的身份匹配。每一次頁面瀏覽、每一次按鍵、每一次使用者操作，都會觸發一個請求。在消費者級別的規模下，這意味著每秒鐘有數千個查詢命中搜尋索引，而峰值流量往往是平時的數倍。

搜尋也處於收入的關鍵路徑上。在零售領域，使用搜尋的購物者轉化率是單純瀏覽者的兩到三倍。在流媒體平臺上，推薦驅動了使用者觀看的大部分內容。

過去，要達到生產級別的 QPS，意味著需要為每個應用構建定製化的檢索棧。需要針對不同索引大小、查詢型別和過濾器進行負載測試，手動調整容量，並在索引前設定負載均衡器。每一個新的搜尋用例都意味著從頭開始。這種痛苦普遍存在於向量資料庫、搜尋引擎和 DIY 棧中。

今天，我們宣佈 Databricks AI Search 的高 QPS 擴充套件功能正式可用。現在，透過一個人類可讀的引數，標準端點可以擴充套件到數千 QPS。您告訴我們目標，我們為您配置基礎設施。

在建立端點時設定 target_qps，或隨時透過 SDK、REST API 或端點 UI 更新現有端點。Databricks 會配置基礎設施以滿足目標。無需管理副本數量、無需調整節點大小、無需連線負載均衡器。

Unity Catalog 治理和 Delta Sync 保持不變。同一端點可以從原型擴充套件到生產流量，無需離開平臺。

何時需要高 QPS 擴充套件：

搜尋欄：例如電商產品搜尋、流媒體和媒體平臺的內容發現、聯網裝置上的語音搜尋。自動補全框每次按鍵都可能觸發搜尋呼叫，因此 QPS 隨活動輸入量增長。延遲直接影響轉化率。

推薦/個性化系統：例如電商的“你可能也喜歡”面板、媒體和流媒體平臺的個性化資訊流。每次頁面瀏覽都會觸發推薦查詢，流量高峰首先影響檢索。推薦延遲是請求的關鍵路徑。

即時實體解析：例如身份匹配、去重、請求時對大型目錄的查詢。這裡的查詢速率是運營 SLA，不是可以緩衝的突發流量。

如果出現以下情況，您可能需要此功能：

• 生產日誌中出現 429（請求過多）錯誤
• P95 延遲隨流量增加而飆升，即使是平均利用率適中時
• 使用重複端點或客戶端負載均衡等變通方法

工作原理詳解：

宣告：您在端點上設定 QPS 目標。Databricks 計算並配置計算容量以達成目標。無需管理副本數量、無需節點大小規劃、無需容量規劃。

與現有端點相容：透過 Python SDK、REST API 或 UI 更新任何標準端點。新容量在下一次在端點上建立或同步索引時生效。

監控擴充套件狀態：端點上的 scaling_info 欄位跟蹤進度，從 SCALING_CHANGE_IN_PROGRESS 到 SCALING_CHANGE_APPLIED。

生產可觀測性：在生產中執行檢索系統需要了解每秒請求數、請求延遲和端點健康。端點 UI 現在為每個端點提供這三項指標。

使用服務主體認證以獲得最佳效能：服務主體流量透過為高 QPS 生產工作負載最佳化的網路路由。個人訪問令牌（PAT）流量限制在每秒幾十個 QPS，適合原型設計但不適合生產。請參閱效能指南以獲取完整說明。

規模調整：使用端點可觀測性 UI 和原生 Genie 整合來了解流量模式，並設定具有足夠餘量的 target_qps 以應對突發。

立即開始構建：

原型和生產之間的區別現在只是一個配置引數。高 QPS 擴充套件現已全面可用，無需選擇加入。兩種開始路徑：

• 使用 target_qps 設定初始目標建立新端點
• 更新現有端點的 target_qps 以擴充套件已為應用服務的索引

接下來：

我們將繼續使搜尋在規模上更易操作。計劃今年晚些時候推出針對流量突發的自動擴充套件（無需手動容量規劃或規模調整）以及對儲存最佳化端點的支援。

深入瞭解：

• 高 QPS 文件
• Databricks AI Search 概覽
• 效能最佳實踐
• 在 Databricks 上構建即時產品搜尋