Databricks推出Lakebase Search：內置於Lakebase Postgres的智能代理原生檢索系統

Databricks近日宣佈推出Lakebase Search，這是一款內置在Lakebase中的混合向量與全文檢索系統，目前已於AWS和Azure上提供Beta版本。該系統的核心是兩個原生Postgres擴展——lakebase_vector和lakebase_text，它們使得整個智能代理循環能夠完全依賴單一數據後端，即一個Lakebase實例。

智能代理將搜索轉化為一個操作工作流：它們檢索上下文、推理、行動、記憶。這深度連接了讀取路徑（檢索）與寫入路徑（記憶），使得即時檢索對於實時訪問新生成的洞察至關重要。然而，在此之前的Postgres平台中，並沒有一個專為大規模搜索所需的經濟性而構建的原生解決方案。

搜索對於智能代理而言本質上是一個操作負載。與人類用户不同，智能代理對搜索有着截然不同的需求。傳統搜索引擎假定數據是隻讀的快照，但智能代理將搜索視為一個實時的操作數據庫。典型的代理模式中，分塊的文檔和嵌入直接與活躍的對話記憶日誌共存，形成一個持續的讀寫循環。代理在一步中寫入新知識到記憶，下一步就需要該數據被完全索引並可搜索。它們不僅需要快速檢索，還需要在最新寫入上實現即時搜索。

搜索是一種獨特的工作負載，有兩個鮮明特性。首先，存儲的數據量遠大於實際查詢的數據量，大部分數據處於冷狀態。其次，向量搜索導致嚴重的數據膨脹：一個1KB的文本文件在向量化後會顯著增大，因為文檔被分割成多個塊，每個塊生成一個高維嵌入，這還不包括索引開銷。當擴展到數千個大多數處於空閒狀態的多租户時，傳統搜索架構就會崩潰。行業標準的向量索引（如HNSW）本質上是內存綁定的，因為快速圖遍歷嚴重依賴索引常駐RAM，所以託管冷多租户數據的成本非常高昂。

去年，Databricks推出了Lakebase：一種無服務器Postgres OLTP架構，數據存儲在廉價的雲對象存儲中，但分層緩存（RAM、本地NVMe、頁面服務器）確保熱頁以本地磁盤延遲讀取。團隊認識到這正是現代搜索所需的架構。然而，要釋放這種經濟性而不犧牲查詢速度，需要一個專門為分層存儲層次結構設計的索引布局。因此，他們構建了Lakebase Search。

通過將分層架構與專門構建的分層索引配對，Lakebase Search實現了無速度懲罰的下一代規模：通過智能地從對象存儲中僅獲取所需頁面到本地緩存，較小的Postgres實例可以達到相同的召回率和延遲，而無需龐大的計算資源。經濟性方面，冷向量的尾部存放在近乎免費的對象存儲中，而熱工作集駐留在NVMe上。用户只需為查詢的數據付費，而非存儲的數據。

在構建Lakebase Search時，團隊有兩個嚴格的要求：它必須是100% Postgres原生（重用標準的pgvector/tsvector類型和生態系統工具），並且索引必須從根本上為分層雲對象存儲而構建。為此，他們推出了兩個新的Postgres擴展（Beta版）。

lakebase_vector：通過RaBitQ（隨機二元量化）壓縮向量，將索引體積縮小32倍，同時保持高召回率。一個原本需要300GB RAM的一億向量索引現在可容納在10GB以下。減少的內存佔用使得單個索引能夠擴展到超過10億向量。活躍工作集緩存在本地NVMe上，而冷尾部則駐留在對象存儲中。

lakebase_text：用針對雲對象存儲順序讀取優化的索引替代GIN，為Postgres引入原生BM25相關性排序，而無需GIN的內存佔用。由於兩個擴展在同一引擎中執行，混合搜索可以通過單個SQL查詢實現，向量相似度和關鍵詞相關性通過倒數排名融合（RRF）結合。

基準測試表明，Lakebase Search在LAION-100M數據集（1億個768維向量）上，單實例單連接，温緩存查詢性能優異：Recall@10達到0.955時P99延遲為30毫秒，QPS為51。相比之下，標準pgvector需要512GB RAM的實例，索引構建約40小時；而lakebase_vector在192GB實例上運行，索引構建僅需1.5小時，且冷緩存首次查詢只需1.13秒。

Lakebase Search為智能代理提供了單一後端用於記憶和上下文，以及持續的搜索實驗和專用檢索引擎等能力。代理無需再拼接向量數據庫和事務數據庫，整個代理循環在單一數據庫上運行。由於搜索與操作數據相鄰，混合搜索、連接應用表、按租户安全過濾等操作可在單個SQL查詢中完成。

Lakebase Search Beta版現已於AWS和Azure上可用。