Perplexity 公開 CobbleDB：兩名工程師與數百 AI 代理兩個月建成搜尋熱庫，批量讀延遲約降五倍

Perplexity Engineering 於官方部落格發布〈CobbleDB: Rebuilding AI Search Storage for Lower Latency and Cost〉，說明該公司為 AI 原生搜尋自研鍵值「熱庫」CobbleDB，並以 Pillar（持久文件狀態）與 Lorry（分區批次更新）拆開寫入與讀取路徑。公開生產前後量測顯示，批量讀取中位數延遲由 31.4 毫秒降至 5.60 毫秒，p99 由 123 毫秒降至 24.2 毫秒，內部成本模型估計相對 DynamoDB 至少節省約兩成；團隊並計劃開源 CobbleDB。本文已對照官方部落格全文與 @perplexity_ai 同日技術串文，來源真實性已驗證。對香港企業而言，這不只是一則資料庫替換新聞，更是「小團隊＋持續在線編碼代理」能否改寫自研基建門檻的實測樣本。

一、核心事件：為搜尋服務路徑量身打造的熱庫

技術細節

Perplexity 指出，AI 原生搜尋對內容處理、儲存與服務的要求，與傳統「給人閱讀」的搜尋堆疊不同：管線需清洗頁面、切成語意段落、計算嵌入，並把段落與向量一併寫入資料庫；查詢時再批次取回候選頁內容，交給模型選段與生成。寫入側要能消化連續爬取、重新分塊或換嵌入模型的大規模回填；讀取側則必須在答案路徑上完成低延遲批量讀。

官方寫道，過去以 DynamoDB 承載準備頁（prepared pages）雖可靠，但用量計費隨索引與查詢量放大、內部放置／快取／副本選擇難以針對「一批頁鍵快速取回」調優，且處理管線直接寫入熱庫，使大型重處理與延遲敏感讀取互相干擾。新架構改為：Pillar 在 YTsaurus 上維護版本化文件狀態並決定匯出；Lorry 把匯出轉成按分區對齊的 S3 批次；CobbleDB 攝取批次並以頁鍵（雜湊 URL）提供已處理表示（預切段落＋每段向量）。CobbleDB 以 RocksDB 為節點引擎、三分區副本、同區優先路由，並用 MultiGet 平行讀取；慢節點可對另一副本做對沖讀。官方強調這不是通用資料庫，而是專為「重複批量讀準備頁記錄、非同步管線餵入」設計。

工程組織層面同樣引人注目：官方稱 CobbleDB 核心約四萬行 Rust，由兩名人類工程師與「數百個」持續在線、可跨 session 記住目標與風險的編碼代理群，在約兩個月內建成核心基建；人類仍負責架構、重大變更審查與生產操作授權，代理負責審碼、補測試、追 CI、監控 rollout 與整理專案狀態。

二、技術原理深度解析：把狀態、投遞與服務拆開

CobbleDB 的關鍵不在「再寫一個 KV」，而在責任分離。查詢路由器把鍵雜湊到分區後平行打到節點；同區副本優先，降低跨區延遲。節點可把熱資料放記憶體、冷資料放本地 NVMe，讓記憶體／磁碟比例跟著實際工作負載調。因為熱庫允許短暫的副本間不一致與「寫入後短時間不可讀」，系統刻意省略通用資料庫的強事務與同步副本開銷。

寫路徑上，Pillar 用便宜 HDD 存遠多於過去 DynamoDB 的文件元件與版本，只把政策定義的子集（例如新鮮或高價值頁）匯出到較貴的 NVMe 熱庫。Lorry 與 Cobble 之間用「資料面在 S3、控制面註冊批次」協議，讓慢節點或復原節點自行追進度，而不拖慢整集群。官方合成基準與生產前後對照都指向同一結論：在約 10–15 鍵、單項約 50KB、約 20 萬 rps 量級的批量讀場景，可調優的自研熱庫比托管讀路徑更能壓低中位與尾延遲；成本面則因避免「每字節讀寫」計費，估計至少便宜約 20%。

三、日常應用場景

1. 開發者與技術團隊

若產品是 RAG、Agent 搜尋或高 QPS 的「候選頁／段落批次取回」，應對照自家讀模式是否接近「固定鍵批量、可容忍短暫不一致」。若是，可評估 RocksDB／分區副本／同區對沖等模式；若需要強一致事務或任意查詢，CobbleDB 明確不適用。代理群協作則提示：把架構決策與上線授權留在人類閘門，把重複審碼、測試與監控交接給可持久的代理系統，才可能把「兩人兩個月」從口號變成可複製節奏。

2. 企業與隱私敏感行業

金融、法律、醫療若把文件庫與嵌入索引放在托管 KV，除了延遲與成本，還要面對跨境資料與供應商鎖定。CobbleDB 案例顯示「買不到剛好的讀路徑」時，自研專用層可能同時改善延遲、成本與可控性；但自研也意味著運維、備份與安全基線要自己扛。對必須資料不出境的團隊，更應把「熱庫／索引是否可私有部署」寫進採購與架構評審。

3. 一般用戶

一般用戶不會直接接觸 CobbleDB，但會感受到搜尋與代理回答更快、更穩。開源承諾若兌現，其他 AI 搜尋與企業知識庫團隊可能復用相同熱庫思路，間接拉高業界服務基線。

4. 香港與亞洲市場視角

香港企業部署私有檢索增強生成或內部知識代理時，常見痛點是雲端托管資料庫費用隨流量爬升、以及敏感語料不宜出境。CobbleDB 的公開數字提供可引用的對照：在讀多寫分批的場景，專用熱庫可同時攻延遲與成本。本地團隊若採「小核心工程＋受管代理群」推進基建，也須配套程式碼審查、變更授權與審計日誌，避免把生產寫入權交給無人看管的自動化。

四、專業評價與潛在考量

優勢

有官方工程文與生產前後延遲／成本數字，可核對、可引用。
架構敘事清楚：狀態、批次投遞、熱讀三分開，對 AI 搜尋工作負載有針對性。
「兩人＋數百代理／兩個月／約四萬行 Rust」把代理協作從演示推進到核心基建敘事，並計劃開源，商業與技術擴散潛力高。

需要留意的地方

延遲數字為不同時段生產流量的前後對照，非嚴格同請求 A/B；官方亦補充合成基準，但仍屬觀測性證據。
「至少 20% 更便宜」來自內部成本模型，未公開完整雲帳單明細。
CobbleDB 明確非通用庫；誤用於強一致交易或複雜查詢會踩坑。
開源時程僅稱「soon」，介面、授權與營運工具是否一併釋出仍待觀察。
代理群數量與「hundreds」屬公司自述，外部難以獨立審計其有效貢獻比例。

結語

CobbleDB 把 AI 搜尋的儲存問題從「再買一檔托管 KV」改寫成「為批量讀路徑自研熱庫，並用代理群壓縮交付週期」。對香港與亞洲要建設私有檢索與代理系統的團隊，重點不在複製每一行程式碼，而在認清工作負載、拆開讀寫責任，以及把人類閘門與代理執行力綁在同一條工程節奏上。如需在香港部署資料不出境的企業私有 LLM 與檢索相關基建，可參考 YSK Limited 的企業私有 LLM 全託管（https://ysk.hk/services/ai-automation）。

參考來源

Perplexity Engineering：CobbleDB: Rebuilding AI Search Storage for Lower Latency and Cost（https://www.perplexity.ai/hub/blog/cobbledb）（官方主來源；標題與延遲／成本數字以此為準）
X 發現來源：@perplexity_ai 技術串文（https://x.com/perplexity_ai/status/2099955628194316346）（發現用，非唯一依據）