檢索基礎架構與向量儲存

向量搜尋的概念驗證，與能在真實查詢量下穩定運作的正式系統，是兩個截然不同的工程課題。我們建置並營運位於您 RAG 管線、代理式工作流程或語意搜尋產品底層的檢索基礎架構層——向量引擎、為其供給資料的嵌入管線、維持其健康的索引生命週期管理，以及能在使用者察覺之前捕捉品質劣化的可觀測性堆疊。

我們對引擎保持廠商中立。我們的實務不偏好任何單一引擎，橫跨 Qdrant、Milvus、Weaviate、pgvector 與 Elasticsearch kNN，至於我們建議採用哪一種，取決於您的向量數量、查詢模式、多租戶需求與營運能量。

從 5 萬向量的演示到 2 億向量的正式環境

演示與正式系統之間的差距，幾乎完全是基礎架構的問題。演示將 5 萬個向量 載入 Pinecone，執行一次餘弦相似度查詢，並在 40 毫秒內回傳結果。正式環境則完全不是這麼一回事。

• 2 億個向量 與 每秒 500 次查詢 持續運作
• 15 個中繼資料篩選維度 ，且文件更新頻率為 每小時
• 三個團隊在嚴格租戶隔離下共用同一個叢集

在該規模下，HNSW 壓實的尖峰會使您的 P99 飆升至 800 毫秒，召回率在一週的增量更新後悄然劣化，而嵌入管線也跟不上您的文件變更速率。這正是我們著力之處。

引擎選擇是一項基準測試工作，而非品牌決策

每家廠商都聲稱擁有同級最佳效能；但基準測試道出的是更細緻的故事。我們不會從功能對照表挑選資料庫——我們載入您實際的向量、以您實際的中繼資料篩選條件執行您實際的查詢，並在具營運意義的 k 值下，連同並發負載下的 P50/P95/P99 延遲一併測量召回率。

測試結果經常與廠商行銷相互矛盾。Pinecone 的無伺服器方案看似具成本效益，直到持續的高 QPS 工作負載將讀取單元成本推過自行託管的損益平衡點；而 pgvector 看似受限，直到迭代掃描填補了篩選搜尋的缺口。

嵌入管線才是正式環境檢索真正失效之處

團隊將 60% 的向量搜尋工程投入花在管線上，而非儲存端。管線負責文件擷取、分塊、嵌入模型推論、文件更新時的增量重新索引，以及中繼資料傳播——而每一個階段都有會悄然劣化檢索品質的失效模式。

• 陳舊知識 ——第二常見的正式環境 RAG 失效。文件在 Confluence 中更新了，但索引仍提供舊的嵌入。修正之道是採用變更資料擷取（CDC）觸發器來進行增量重新嵌入，而非每夜的批次重新索引。
• 幽靈文件 ——來源文件已被刪除，但其向量仍存在，為不再存在的內容回傳結果。由於在分離式架構中，橫跨真實來源系統與向量儲存的原子交易幾乎不可能實現，我們會建置對帳層來偵測並清除孤立的向量。

嵌入模型的選擇，比多數團隊所意識到的更為重要，而日後切換代價高昂：當您從 800 萬份文件 升級 text-embedding-ada-002 至 text-embedding-3-large 時進行重新嵌入，需耗費數天的運算，並需要雙寫入基礎架構以避免停機。我們會在您做出決定之前，針對您領域特定的查詢集評估各模型。

• Cohere embed-v4 ——以 每百萬 token 0.01 美元 在 100 多種語言中領先多語言檢索。
• Nomic Embed v2 —— 1.37 億個參數，可在 CPU 上執行，具備市場上最佳的品質對體積比。
• OpenAI text-embedding-3-large ——強大的全能型選擇。

正確的選擇取決於您的語言組合、延遲需求，以及您是否能接受 API 依賴或需要地端推論。

索引生命週期：無人事先警告你的營運難題

HNSW 索引會劣化——這不是錯誤，而是架構上的現實。在 1.6 億向量下，一次完整的 HNSW 重建需耗時 3 至 6 小時。增量更新會使圖結構變得次佳，並隨時間侵蝕召回率；壓實事件會使查詢延遲飆升；而每一次 upsert、刪除與區段合併都會觸發子索引重建，將 CPU 消耗在維護上而非服務查詢。這項取捨無可迴避：從 0.8 推升到 0.95 召回率 會使 HNSW 延遲提高約 31%。

我們設計的生命週期管理，能在不損失品質的情況下吸收持續擷取：

• 藍綠索引輪替 ——在獨立的基礎架構上重建，並以零停機的方式原子性切換。
• 自動化召回率驗證關卡 ——在每次重大操作後，以黃金查詢集比對當前索引；若召回率跌破閾值，切換便不會發生。
• 在 Qdrant 與 Elasticsearch 中，GPU 加速的 HNSW 建置 能將重建時間縮短一個數量級，不過何時重建、如何驗證、如何切換的協調工作，仍屬客製化工程。

量化更進一步延伸了這點。Qdrant 現已提供 1.5 位元、2 位元與非對稱 量化，而 Elasticsearch BBQ 能將堆積記憶體 相較 float32 減少超過 95%。這些方式可節省記憶體並提升吞吐量，但每種方案針對不同的資料分佈都有不同的召回率表現——因此我們會在於正式環境部署量化之前，針對您特定的向量刻劃其召回率影響。

真實規模下的多租戶與隔離

服務 200 多個內部 ML 團隊的平台團隊，或是擁有數千個客戶租戶的 SaaS 產品，都需要能保證隔離的基礎架構：租戶 A 的查詢絕不能回傳租戶 B 的資料，稽核日誌必須將每一次查詢追溯到某個租戶身分，而冷租戶不應消耗熱租戶所需的資源。

• Weaviate ——搭配租戶狀態（ACTIVE、INACTIVE、OFFLOADED 至 S3）的一租戶一分片模型，是高租戶數部署中最成熟的實作。
• Milvus ——支援在資料庫、集合、分區或分區鍵層級的隔離，使粒度與您的合規需求相匹配。

兩者在規模化時都需要客製化協調——租戶佈建、狀態轉換、配額管理與跨租戶洩漏偵測，並非由資料庫本身處理。我們會建置營運層，使多租戶對於需要 SOC 2 或 ISO 27001 合規的受監管部署變得可管理。

代理式工作流程正在重塑基礎架構需求

代理式 AI 浪潮改變了向量儲存必須做到的事。靜態 RAG 針對固定語料庫檢索文件。代理式工作流程則需要 情節記憶 （對話歷史與中間推理）、對大型文件語料庫的 語意搜尋 ，以及 使用者設定檔層 ——往往在單一代理步驟中同時觸及這三者。相較於批次 RAG， 低於 400 毫秒 的延遲需求更為嚴苛，而 ACID 交易支援對於在不產生部分寫入下更新狀態的多步驟代理，正變得不可或缺。

沒有單一向量資料庫能將這三種記憶層都處理得很好，因此團隊會組合多儲存架構： Redis 用於工作階段狀態、 Qdrant 或 Milvus 用於語意搜尋，以及一個 圖形資料庫 用於關係追蹤。 Oracle 的 Unified Memory Core（2026 年 3 月） 嘗試在單一引擎中匯聚向量、JSON、圖形、關聯式與空間查詢。我們為代理式系統設計檢索層——哪些儲存處理哪些記憶類型、查詢如何在各儲存間路由，以及當代理在單一推理步驟中橫跨多個後端更新狀態時，一致性如何維繫。

我們交付的內容

每一次合作皆始於一個 基準測試階段：我們載入您的向量、執行您的查詢，並產出量化的引擎建議。在此之後，我們建置正式環境的基礎架構：

• 此 向量儲存叢集，含容量規劃與擴充運作手冊。
• 此 嵌入管線，含 CDC 觸發的增量重新索引與模型版本管理。
• 此 索引生命週期自動化，含藍綠輪替與召回率驗證關卡。
• 此 多租戶協調層，用於您需要租戶隔離時。
• 此 可觀測性堆疊，含漂移偵測、召回率退化警示與 P95/P99 延遲監控。
• 遷移工具 ，供在引擎之間移轉的團隊使用，藉由中介的 Parquet 格式，在維度相符時保留嵌入，而非強制進行完整的重新嵌入。

我們為每一次合作界定明確的 每月基礎架構成本預估，讓您在做出決定之前便清楚正式環境將花費多少。