查詢 30 億個向量：從原始實作到大規模工程優化

背景

這場討論源於作者受到 Google 首席科學家 Jeff Dean 的啟發，試圖挑戰在 30 億個向量（Vectors）中進行高效查詢。作者從最原始的 Python 實作開始，逐步發現即便經過向量化與資料類型優化，面對數十億規模的數據，單機運算仍會面臨嚴重的記憶體溢位（OOM）與運算時長問題，進而引發社群針對大規模向量檢索技術路徑的深度探討。

社群觀點

針對如何處理 30 億規模的向量查詢，Hacker News 的討論主要聚焦於「硬體資源分配」與「現成工具選擇」兩大核心。部分評論者認為，若查詢需求屬於低頻率的單次任務，採用循序讀取（Sequential Read）是成本效益最高的做法，因為建立近似最近鄰（ANN）索引的過程往往比單次查詢更耗時。然而，當數據量達到數十億等級時，單純依賴記憶體已不切實際。sdenton4 指出，許多追求低延遲的方案強制將數據載入 RAM，這在海量數據下會造成極高的硬體成本，因此支持使用如 USearch 這類能與磁碟協作的工具，在性能與儲存成本間取得平衡。

Redis 創始人 antirez 也參與了討論，他觀察到技術圈對新功能的採納往往存在滯後性。他認為對於中小型規模，Redis 的向量功能已能提供極高的查詢吞吐量，但他同時也對「30 億」這個數字的真實需求感到好奇。他指出，在這種極端規模下，真正的瓶頸往往不在於查詢，而是在於如何生成這些嵌入向量（Embeddings）。對此，antonvs 提出了不同看法，認為生成與查詢應視為解耦的過程，正如大型語言模型的訓練雖然昂貴，但推論端的效能才是直接影響用戶體驗的關鍵，因此優化查詢效率仍具備高度價值。

此外，社群對於實作細節也有不少爭論。有觀點質疑為何不直接利用 GPU 的並行運算能力，或是採用專門的向量資料庫如 LanceDB 或 Turbopuffer 來簡化開發流程。wood_spirit 則從演算法邏輯提出質疑，認為作者在文中提到的記憶體壓力可能源於不必要的結果儲存，實際上只需追蹤當前最接近的鄰居即可，無需保留所有比較結果。最後，也有人建議考慮使用 DuckDB 等現代分析型資料庫，探索其在向量運算上的潛力。整體而言，社群共識傾向於：技術實作並非唯一難點，真正的挑戰在於根據具體的應用場景（如查詢頻率、延遲要求與預算限制）來定義最合適的架構。

延伸閱讀

• USearch：適用於大規模向量儲存與近似最近鄰搜索的工具，支援磁碟操作以節省記憶體。
• Redis Vector Search (VADD/VSIM)：Redis 內建的向量操作指令，適合高效能查詢需求。
• LanceDB / Turbopuffer：專為向量檢索設計的資料庫解決方案。
• SimSIMD：專門用於大規模向量相似度比較的系統級優化函式庫。