當我們在討論 AI 應用時，很多人會關注 LLM 模型本身，但對於工程師來說，真正具備挑戰性的是如何將這些模型落地到大規模生產環境。HubSpot 最近分享了他們如何將語義搜尋（Semantic Search）從一個簡單的概念驗證（POC）擴展到管理 200 億個向量（Vectors）的實戰經驗。
對於初學者來說，首先要理解什麼是向量搜尋。傳統的關鍵字搜尋是比對文字是否相同，而語義搜尋則是將文字轉換成一串數字（即向量），透過計算這些數字在空間中的距離來尋找意思相近的內容。這對於 RAG（檢索增強生成）和 AI Agent 來說至關重要，因為它能讓 AI 在回答問題前，先從海量資料中找出最相關的上下文。
HubSpot 為了讓公司內部 38 個以上的團隊都能快速使用這項技術，開發了一套名為 VaaS（Vector as a Service）的平台。VaaS 並非單純的資料庫，而是一個封裝層，它在底層的 Qdrant 向量資料庫之上，提供了權限控制、向量化生成（Embeddings Generation）、資料版本管理以及回饋收集等功能。
選擇 Qdrant 作為底層資料庫的原因在於其靈活性。HubSpot 選擇私有化部署（On-premises），這樣能確保客戶數據的安全性，並能與公司內部的追蹤、成本監控和限流工具深度整合。此外，Qdrant 提供的量化（Quantisation，一種降低記憶體佔用的壓縮技術）和磁碟儲存功能，能有效控制在處理數十億級資料時的硬體成本。
然而，當規模達到 200 個索引、140 個叢集且寫入峰值高達每秒 10 萬次請求時，傳統的部署方式失效了。起初他們使用 Helm（Kubernetes 的包裝管理工具）來部署，但 Helm 的侷限在於它無法主動呼叫 API、無法根據外部指標自動擴展，也難以處理複雜的狀態生命週期。簡單來說，當規模大到一定程度，手動操作或簡單的腳本已經無法維持系統穩定。
為了克服這個問題，HubSpot 引入了 Kubernetes Operator 框架，並開發了所謂的 Translators（轉換器）。這套機制每 60 秒會檢查一次系統的期望狀態與實際狀態是否一致（Reconciliation），如果不一致就自動修正。透過這種自動化手段，他們將叢集的啟動時間從數小時縮短到數分鐘，並實現了自動化的分片遷移（Shard Movement）和副本恢復。
在實務運作中，HubSpot 發現一個關鍵痛點是分片不均（Memory Skew）。在向量資料庫中，如果某個分片承載了過多資料，會導致單個節點記憶體爆滿，迫使整個叢集在不需要時就得提前擴容。因此，精準的自動化平衡與分片管理，比單純增加硬體資源更重要。
總結來說，HubSpot 的經驗告訴我們，在大規模 AI 基礎設施中，資料庫本身的性能只是基礎，真正的挑戰在於周邊的運維自動化。當語義搜尋成為多個 AI 產品的核心時，它必須像一個成熟的平台服務一樣運作，透過自動化來平衡檢索品質、延遲與成本。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。