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上可用。