Google Cloud 更新了 AlloyDB 的 ScaNN 索引，官方公布的規模上限來到百億筆以上向量。在這個量級下，官方實測數據是 P95 延遲不超過 51 毫秒、召回率 95%。AlloyDB 是 Google Cloud 的代管資料庫服務，相容 PostgreSQL 介面。
這次改動落在索引結構本身。先前的 ScaNN 用兩層或三層樹來組織向量，這次加到了四層。
樹多一層，查詢量少兩個數量級
近似最近鄰檢索的做法，是先把向量依相似度聚成一層層的群組，查詢時從最上層往下走，每層只挑最接近的幾個分支展開。層數決定了搜尋的複雜度：兩層樹大約是 O(N^1/2)，三層降到 O(N^1/3)，四層再壓縮到 O(N^1/4)。
這幾個指數在百億規模下差距非常大。粗算一下，N 取百億時，平方根約等於 10 萬，立方根約 2150，四次方根約 316。同一次查詢要碰觸的候選數量，從十萬級掉到三百上下。51 毫秒這個數字就是這樣算出來的。
Google 列出的具體手法包括 Top-K 分支策略、SOAR 演算法、質心調整與平衡樹建構，另外用動態取樣繞開記憶體限制。官方點名了舊結構的兩個瓶頸：樹一大，建索引和查詢遍歷的運算量都會跟著上升；在百億筆向量規模做取樣時，很容易把可用記憶體耗光。
是 Agent 把資料量頂上去的
Google 在文中的說法是，企業級 Agent 應用的需求正把使用情境推向數十億筆向量規模，底層向量資料庫常常撐不住。
這句話點出了這一輪擴容的來源。傳統檢索增強生成的場景裡，一家企業把內部文件全部切成片段，量級通常落在千萬到億筆之間。Agent 不一樣：它每執行一步就要回頭查歷史紀錄、查工具說明、翻使用者偏好，一次任務下來可能觸發十幾次檢索。資料來源也從文件擴展到工作階段紀錄、操作日誌、中間產出，這些東西每天都在增量累積。
再算一筆帳。以 51 毫秒的 P95 來看，一次 Agent 任務如果跑 15 次檢索，光是向量資料庫這段就要花掉約 0.77 秒。這還只是資料庫這一段，模型推論、工具呼叫、網路來回都得另外算。檢索延遲在單次互動裡看起來不起眼，放進多跳鏈路後就成了使用者實際感受得到的一部分。
通用資料庫正在收編專用產品
把百億級向量檢索做進相容 PostgreSQL 的代管服務裡，指向的是同一條路線：向量不再需要一套獨立的基礎設施。
對企業客戶來說，這筆帳很好算。業務資料本來就在關聯式資料庫裡，使用者表、訂單表、權限規則都在那裡。向量單獨放一套專用資料庫，意味著要維護兩套備份、兩套權限、兩套一致性保證，還得自己處理跨資料庫的交易邊界。能在原本的資料庫裡加個索引解決，維運複雜度直接砍掉近一半。
專用向量資料庫這兩年的處境也跟著改變。它們在極端效能與檢索演算法的迭代速度上仍有優勢，但通用資料庫把「夠用」的門檻一路往上推——從百萬級到億級，現在來到百億級。留給專用產品的空間，被壓縮到對延遲與吞吐量要求最嚴苛的那一小塊。
AlloyDB 這次沒有公布分區數、向量維度、索引建構耗時與 QPS 上限。這些參數在實際選型時，往往比峰值規模更有參考價值，建索引要花多久尤其關鍵，百億規模的重建成本可能高得驚人。
參考來源：Google Cloud 官方部落格、AlloyDB ScaNN 索引文件、CocoLoop；向量規模、P95 延遲與召回率數值以官方公告為準，複雜度換算為編輯部粗估。