Databricks Lakebase Search 挑战独立搜索技术栈

Databricks 已在 AWS 和 Azure 上正式发布 Databricks Lakebase Search，将两种搜索引擎置于其托管 Postgres 服务之中。9 月 28 日发布的功能支持向量检索和 BM25 关键词排序，无需单独部署搜索数据库。这对一种常见的 AI 架构提出了挑战：由 Postgres 保存运营记录，再由另一套系统为其副本建立检索索引。

该公司称，其新的向量扩展可在 100 万条向量中实现 97% 召回率和 71 毫秒 P99 延迟。它还声称，在其基准测试中，吞吐量是次优系统的两倍，成本则比运行 pgvector 的云 Postgres 低四倍。这些结果颇具分量，但测试由 Databricks 自行完成，且尚未公布完整的独立验证。

更大的看点并非又一个向量索引。Databricks Lakebase Search 试图让运营 Postgres 以智能体规模处理语义检索、关键词检索和混合检索。如果这一架构能在真实生产负载下奏效，部分团队便可移除搜索服务及其周边的数据管道。压力将落在 pgvector 部署和专用搜索系统身上，后者一直通过更强的规模能力来证明其复杂性合理。

Databricks Lakebase Search 将检索带入 Postgres

此次发布让搜索从外挂服务变为运营数据库的一项托管能力。

这篇技术公告介绍了两项 Postgres 扩展。lakebase_vector 负责近似最近邻搜索，即在无需比较所有可能记录的情况下，找出与查询向量相近的向量。lakebase_text 则提供 BM25，这是一种综合考虑词频、文档长度以及词语在集合中稀有程度的排序方法。

两项扩展现已面向 AWS 和 Azure 上的 Lakebase 项目正式可用。开发者可安装其中任一扩展，也可将两者结合用于混合检索。这种组合很重要，因为向量搜索与关键词搜索解决的是不同的失效场景。

向量搜索会比较嵌入，即对语义的数值化表示。即使记录中并未出现完全相同的词语，它也能将“fast sports car”这类查询与提到某个汽车型号的记录匹配起来。对于标识符、名称、错误代码、产品编号，以及其他字面形式本身承载意义的术语，关键词搜索依然更具优势。

混合搜索会同时运行两种方法，并合并其排序结果。AI 支持智能体可以利用语义相似度找到概念上相关的事故记录，同时保留对特定错误代码的精确匹配。电商智能体则可理解购物者的意图，而不会遗漏其指定的型号编号。

这些操作直接在事务记录旁运行，而非针对一份单独同步的副本。开发者可利用租户、库存状态、访问权限或工作流状态等当前字段过滤检索结果。Databricks 表示，lakebase_vector 会在扫描索引块时应用过滤条件，从而减少先检索大量候选集、再剔除未获授权或不相关行的需求。

这一设计瞄准了检索系统中一个长期存在的问题。记录的最新版本往往位于应用数据库中，而可搜索版本则要稍后经由抽取管道才能到达。即使只是短暂延迟，也可能让智能体接触到已删除的文档、过期的权限信息，或已不存在的库存。

让检索更贴近运营数据可缩短这一同步窗口，也能减少工程团队需要监控、保护和修复的系统数量。对于构建可搜索知识库的团队而言，这一变化尤其重要，因为访问控制和文档变更必须与搜索结果保持一致。

Lakebase Search 并未消除所有数据移动步骤。嵌入仍需生成，源内容可能来自 Postgres 之外，而 lakehouse 表在提供服务前也需要同步。不同之处在于，应用可通过熟悉的 Postgres 类型和运算符查询最终形成的索引。

Databricks 还将这项功能与其更广泛的 lakehouse 平台绑定。其产品文档说明了如何将 Unity Catalog 表同步至 Lakebase。在这一过程中，嵌入列可转换为 Postgres 向量，源文本则可转换为 tsvector，即 PostgreSQL 针对文本检索优化的表示形式。

因此，眼下的变化相当具体：Lakebase 现已提供针对语义搜索和精确术语搜索的原生托管索引，应用可将其与运营字段一并查询。而紧张关系始于这种整合所替代的对象。

AI 智能体令独立搜索管道承受压力

智能体工作负载使同步错误和闲置基础设施更难被合理化。

传统搜索架构通常至少包含两个数据存储。Postgres 保存交易和应用状态；搜索引擎或向量数据库则通过抽取、转换和加载管道接收经过处理的副本。

这种拆分在大规模场景下可能运作良好，但也带来了运营负担。团队必须发现更新失败、重放缺失记录、协调模式变更、保留删除语义，并在另一套系统中复现数据库权限。他们还需要制定在不中断应用的情况下重建索引的方案。

AI 智能体放大了这些负担，因为检索成为决策循环的一部分。传统搜索页面可以容忍不完美的结果，用户仍可审阅替代选项。智能体则可能在检索到记录后立即采取行动，使数据新鲜度和授权情况变得更为关键。

客户管理智能体便可说明这一问题。它可能需要对会议记录进行语义搜索、精确匹配合同标识符，并按当前用户的权限过滤结果。如果这三类信号存在于不同系统中，应用就必须在模型能够安全响应之前对其进行协调。

同样的问题也出现在电商领域。购物智能体可以通过嵌入理解含糊的请求，但商品可用性和区域限制来自快速变化的运营列。搜索一份过期副本，可能会为一个已无货的商品生成看似令人信服的答案。

突发式使用又带来另一种压力来源。面向人工用户的企业搜索通常遵循可预测的工作时间。智能体在规划、验证和修订任务时，则可能生成大量并行检索请求。一次用户请求可能触发多次搜索，而非一次。

Databricks 围绕这种不均衡需求设计了 Lakebase Search。Lakebase 将持久存储与计算分离：数据保留在对象存储中，内存和本地 NVMe 用作缓存。搜索计算可在空闲时暂停，并在另一项查询到来时恢复。

该公司报告称，在一个包含 1 亿条、维度为 768 的向量索引上，从缩容至零后，P90 首次查询延迟为 1.13 秒。它还表示，同一集合可由一个 Lakebase Compute Unit 提供服务。这些均为公司的测量结果，并非普遍预期，但展示了其预期的运行模式。

一秒的冷启动查询并不适合每一种交互式应用。不过，若能避免持续运行大型搜索集群，它可能适用于低频使用的内部智能体。团队可在延迟至关重要时保持计算资源活跃，并让较安静的环境暂停。

索引构建也从主事务路径中移开。Databricks 表示，它可以从样本中训练质心，分布式执行向量分配和量化，然后写入独立的索引块。未来将任务卸载至 Spark 等分布式引擎是该公司的发展方向，不过公告称这一更广泛的能力仍有待后续发布。

这很重要，因为大型索引构建在消耗相同的处理器、内存和存储资源时，会与事务工作负载竞争。将这项工作从主数据库中移开可以减少相互干扰，也会将成本模式从维护一台永久预配置的索引服务器，转向为活跃检索计算和持久存储付费。

承受压力的目标并非所有专用搜索部署。大型搜索团队往往需要专用分析器、自定义排序管道、高级可观测性，或多年积累的功能。Lakebase 所施加的压力，更多针对这样一种常见架构：第二套系统的存在，主要是因为 Postgres 搜索已难以舒适地扩展。

这种区分让公告更贴近实际。Databricks 并非主张一个数据库应处理每一种搜索工作负载，而是认为更多 AI 应用可以推迟、简化或避免这种拆分。

Lakebase 向量搜索瞄准 pgvector 的内存模型

主要竞争在于以存储为后端的 Lakebase Search，与大规模场景下高度依赖内存的 pgvector 索引之间。

Pgvector 让 Postgres 成为语义检索的实用起点。它增加了向量类型、距离运算符、精确搜索和近似索引，无需迫使开发者转向陌生的数据库接口。它仍然是开源项目，并广泛适用于托管 Postgres 服务。

其标准近似方案包括 HNSW 和 IVFFlat。HNSW 会创建连接相邻向量的多层图。它在速度与召回率之间提供了有利平衡，但图构建需要时间，索引也会消耗大量内存。IVFFlat 则将向量分组为多个列表，并搜索最有潜力的分组，从而降低内存和构建成本，但通常会带来较低的查询性能。

该项目自身的pgvector 指南记录了这些权衡。指南指出，当图能够装入 maintenance_work_mem 时，HNSW 索引构建得更快；同时也警告，增加搜索候选数虽可提高召回率，却会牺牲查询速度。

Databricks 认为，当 HNSW 图增长到超出单台机器内存容量时，这些限制会变得更棘手。从远程对象存储中获取一串图节点，可能产生大量细小的随机读取。针对常驻内存优化的设计，在工作集处于冷状态时会变得效率更低。

Lakebase 向量搜索采用分层倒排文件聚类来改变这一访问模式。向量被分组为连续块。查询会先对聚类质心评分，再读取与最有潜力聚类相关的块。

该扩展将这种布局与 RaBitQ 二进制量化结合，用于初始候选评分时，会将每个向量压缩至每维约一比特。Databricks 将这种表示描述为比标准 32 位浮点向量小约 32 倍。随后，系统会使用全精度向量对有限候选集重新排序。

这一机制让索引更适合对象存储和本地缓存。冷查询会读取若干相关块，而不是沿着数百个图链接逐一访问。热查询则可以扫描紧凑的二进制代码，同时将更小的活跃工作集保留在内存中。

Databricks 表示，单个 lakebase_ann 索引可容纳超过十亿个向量。其文档还声称，索引构建速度比 HNSW 快 50 到 100 倍。这些数据描述的是该公司的实现，不应自动套用于所有 schema、嵌入模型或过滤条件分布。

这项重点基准测试使用了来自 LAION 数据集的 1 亿个向量。Databricks 称，Lakebase 的吞吐量是测试中次优系统的两倍。该公司报告称，在 71 毫秒 P99 延迟下实现了 97% 的召回率，这意味着 99% 的测量查询在该延迟内完成，同时以所述比率检索到真实近邻。

该基准测试还得出了相较于一家未具名、采用 pgvector 的云 Postgres 供应商成本低四倍的结论。Databricks 指出，pgvector 和 DiskANN 均在单个大型实例上进行测试。这一限制影响了比较的参考价值，因为架构、配置、硬件、并发度和定价假设都可能显著改变结果。

基准测试可以表明某种方法值得评估，但不能据此直接决定采购选择。Databricks 尚未证明每一种 pgvector 工作负载都应迁移。较小的索引可能能够轻松放入内存，而现有的 pgvector 部署也可能成本低廉、可移植且易于运维。

Pgvector 同样支持二进制量化、半精度索引、迭代扫描、分区和可配置的搜索强度。拥有经过调优部署的团队，选择远比简单的基准图表所呈现的更多。这个开源扩展可运行于多种 Postgres 环境，而 Lakebase Search 则属于 Databricks 的托管服务。

不过，兼容性缩小了迁移成本。Databricks 表示，lakebase_vector 使用 pgvector 的向量类型、距离运算符和查询语法。应用可以保留熟悉的 SQL，同时创建 lakebase_ann 索引来替代 HNSW 或 IVFFlat 索引。

这是一次有意为之的竞争布局。Databricks 并未要求开发者放弃 pgvector 的编程模型，而是在大致相同的接口之下，提供了不同的存储和索引引擎。

客户案例提供了一个实用信号。Conexiom 向 Databricks 表示，它在超过 1 亿行数据上运行混合 BM25 搜索，计算资源占用仅为此前 pgvector 配置的一半。这个案例颇具参考价值，因为它描述了一项实际运行的工作负载；但它仍是一份由供应商挑选的客户陈述，且没有独立公开的方法论支撑。

当集合规模较大、查询需求不规则且运营过滤条件十分重要时，Lakebase 向量搜索的优势最为明显。当团队优先考虑基础设施可移植性、拥有可预测的持续在线需求，或已通过 pgvector 达到延迟目标时，这一优势则会减弱。

原生 BM25 改变全文搜索的格局

这次发布中较少受关注的部分，可能比向量基准测试更重要。

许多 AI 搜索产品过度强调嵌入。语义匹配在用户和文档以不同措辞表达相同含义时很有帮助；但当查询包含嵌入模型视为弱信号或陌生信号的精确标识符时，它的可靠性会下降。

设想一个代理正在搜索“CVE-2026-1234”、客户账号或特定组件名称。相似度搜索可能返回概念相关的记录，却忽略该精确字符串的重要性。关键词排序提供了另一种检索信号，可保留字面匹配。

Lakebase 的 lakebase_text 扩展新增了一个 lakebase_bm25 索引，兼容 PostgreSQL tsvector 值和文本查询运算符。BM25 纳入了集合范围内的词频和文档长度，使罕见词能够比常见词产生更大的影响。

PostgreSQL 已经提供了相当丰富的全文功能。它可以解析文档、规范化词语、移除停用词、构建 GIN 索引，并使用 ts_rank 或 ts_rank_cd 对结果排序。官方排序文档指出，其内置排序函数使用词汇频率、邻近度和结构信息。

这些函数不会像 BM25 那样使用全局集合统计信息。当产品需要搜索引擎风格的相关性，而非简单匹配时，这一区别十分重要。团队历来需要添加自定义排序逻辑，或将文本迁移至专用引擎。

Databricks 表示，lakebase_text 使用 Block-Max WAND 进行 top-K 检索。该算法会跳过无法产生与当前最高分结果竞争的区域。引擎不会完整评分每一份匹配文档，而是将计算集中在可能进入所请求结果集的候选项上。

这种方法与向量检索相辅相成。一条支持查询可以针对 lakebase_bm25 检索精确错误文本，同时针对 lakebase_ann 检索语义相近的事件描述。随后，倒数排名融合可以合并这两个有序列表，而无需假定它们的原始分数采用相同尺度。

正是在这里，Databricks Lakebase Search 不再只是一个更快的向量索引。它在同一数据库内提供了两种不同检索模型组成的搜索栈。运营记录、嵌入、文本表示和过滤属性可以保留在一起。

这种整合影响的不只是便利性，也包括安全性。应用可以将租户边界和权限检查与检索一同表示为 SQL 谓词。工程师仍需测试每条索引路径是否正确执行过滤，但无需在独立服务中重建完整的授权模型。

它也简化了写入行为。新插入的记录无需等待第二个数据库确认事件，即可变得可搜索。更新和删除仍在熟悉的事务环境中完成，不过索引维护时机和同步 lakehouse 数据源仍需进行测量。

专用引擎仍保有重要优势。Elasticsearch 和类似系统支持广泛的语言分析、自定义评分、聚合、高亮、查询工具，以及专为搜索开发的运营控制能力。Lakebase 的 BM25 支持并未消除这些差异。

因此，有意义的比较是架构层面的。如果应用需要语义检索、精确术语排序、实时运营过滤和普通 SQL，Lakebase 可以在同一处覆盖更多工作负载。如果搜索本身就是产品，专业能力仍可能足以证明独立系统的合理性。

基准测试仍未解答生产环境问题

Databricks 展示了一种颇具吸引力的机制，但买方仍需要针对工作负载的证据。

最大的未知因素是基准测试的独立性。Databricks 选择了其公开比较背后的系统、配置、数据集、实例规格和成本假设。该公司提及 VectorDBBench 和 LAION 1 亿数据集，但公告没有提供足够细节，无法仅凭文章复现每一项结果。

召回率和延迟之间也存在相互影响。近似检索有意避免穷尽式比较，因此工程师会调整查询检查的簇或候选项数量。更高的召回率往往需要更多计算。单一性能点无法描述不同目标召回率下的完整曲线。

过滤条件会再次改变这条曲线。真实的业务查询可能按租户、地域、时间、库存状态或授权条件限制结果。均匀分布的基准测试未必能代表选择性极高或分布不均的生产过滤条件。

数据形态同样重要。LAION 的图像嵌入不同于企业文档嵌入、产品目录、源代码或客户记录。维度各不相同，重复数据会出现，更新到达并不均匀，部分租户还会主导流量。每项因素都可能影响缓存行为和索引质量。

冷启动性能需要谨慎解读。报告中的 1.13 秒 P90 适用于特定的 1 亿向量、768 维配置。具有严格交互目标的应用可能需要保持活跃计算资源，而非缩放至零。团队应同时测试首次查询及其后的突发请求。

运营约束也需要关注。文档称，启用 Lakebase Search 会重启项目中的每一项计算资源、断开活跃连接，并且无法撤销。这意味着启用它是一项需要规划的基础设施变更，而不是无害的扩展切换。

可移植性是另一项取舍。Lakebase 提供标准 Postgres 类型和熟悉的 pgvector 语法，但其新的索引访问方法是专有的托管能力。团队可以保留大部分应用 SQL，但仍会在索引行为、扩展能力和定价方面依赖 Databricks。

BM25 也面临同样的问题。标准 tsvector 列仍是可识别的 Postgres 对象，但 lakebase_bm25 索引及其执行特征专属于 Lakebase。迁出时可能需要重建索引，并在其他环境中重新测试排序质量。

成本主张需要直接测量。无服务器暂停可降低不规律使用的费用，但持续高并发可能更适合另一种模式。嵌入生成、同步表、存储、数据传输以及周边 Databricks 服务都会构成整体架构成本。

因此，团队应使用具有代表性的问题来评估 Lakebase Search，而非依赖通用排行榜。一个有用的测试语料库应包含当前记录、已删除记录、受访问控制的文档、罕见标识符、含糊的自然语言查询，以及最可能降低召回率的过滤条件。

他们还应比较运营结果。衡量数据新鲜度、故障恢复、索引构建影响、权限一致性，以及管理管道所需的人员时间。即使原始查询延迟变化不大，移除一个外部服务也可能很有价值。

这些问题没有否定这次发布。它们界定了在供应商基准之外，“最先进”应当意味着什么。这一架构具备可信的技术依据，但生产证据必须证明，其优势能够经受每位买方的数据分布和工作负载考验。

Lakebase Search 正式全面上线后值得关注的事项

三个信号将决定 Lakebase Search 是成为默认的 Postgres 功能，还是仍只是一项 Databricks 特定选项。

第一个信号是可复现的性能。独立测试应在多个召回率目标下，将 Lakebase 与经过调优的 pgvector、基于 DiskANN 的服务及专用搜索引擎进行比较。测试应公布实例规格、并发度、过滤选择性、缓存状态、索引构建时间和完整成本假设。

若结果接近 Databricks 的说法，将增强这样一种判断：对于大型无服务器集合，由存储支撑的聚类索引比面向内存的图结构更合适。若差距很大，即使整合仍带来运营优势，性能叙事也会被削弱。

第二个信号是替换双系统架构团队的采用情况。Conexiom 提供了一个早期案例，但市场还需要更多说明生产规模、更新频率、查询量和权限模型的实例。最有说服力的案例将记录被移除的搜索集群或 ETL 管道，而不只是一次成功演示。

采用情况还将揭示，熟悉的 Postgres 语法是否能减少迁移阻力。如果团队能够在保留数据模型和查询的同时修改索引定义，Lakebase Search 就拥有进入现有应用的现实路径。如果迁移需要广泛调整排序逻辑，兼容性主张的分量就会减轻。

第三个信号是竞争对手的反应。Pgvector 持续增加量化、过滤和迭代扫描等选项。托管 Postgres 厂商可以改进存储架构，或推出自有搜索扩展。专用搜索服务商则可以强调其成熟的排序控制能力、部署灵活性和混合检索功能。

Databricks 在其 2025 年的发布公告中，开始将 Lakebase 定位为面向 AI 应用的托管 Postgres。本次发布让这一定位更加具体。若每个严肃的检索查询仍需离开系统，仅靠事务能力并不能让数据库真正适配智能体应用。

眼下更直接、也更有价值的结论是：Databricks Lakebase Search 为开发者提供了一个托管平台，用于处理运营记录、向量相似度、BM25 排序和 SQL 过滤。其聚簇量化向量索引直接针对制约大规模 pgvector 部署的内存模型。

下一步该由工程团队作出决定。构建具有代表性的检索测试，纳入冷流量和热流量，应用真实的权限过滤条件，并比较完整的运维负担。若 Lakebase 能在保持相关性的同时消除同步基础设施，那么这种架构简化的重要性将超过任何单项基准测试中的柱状图。