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