Postgres BM25扩展横空出世,在AI混合搜索赛道正面挑战Elasticsearch

专为PostgreSQL打造的高性能原生BM25搜索扩展的发布,是现代AI应用需求驱动下的数据库演进分水岭。该项目由一家头部Postgres云服务商的资深工程师主导开发,常被称为`pg_bm25`。它并非孤立的功能,而是一个更宏大战略中的精心设计组件。它与现有扩展(如旨在克服高维向量搜索内存限制的`pgvectorscale`)协同工作,旨在单个数据库实例内提供完整、可扩展的混合搜索解决方案。核心创新在于将久经考验的自由文本排名算法BM25直接集成到Postgres的查询规划器和执行引擎中,从而消除了传统上对独立搜索引擎的依赖。这为需要在同一事务环境中同时处理精确关键词匹配与语义向量相似性搜索的AI应用,提供了前所未有的架构简化和性能潜力。

技术深度解析

为PostgreSQL开发原生BM25扩展的技术抱负是深远的:让一个关系型数据库在不离开其事务环境的前提下,表现得像一流的搜索引擎。挑战不仅在于实现BM25评分函数本身,更在于实现能与Elasticsearch或OpenSearch等专用系统竞争的性能和可扩展性。

从架构上看,该扩展必须集成到Postgres的多个层面。首先,它需要自定义的索引访问方法。虽然Postgres拥有全文搜索功能(TSVECTOR),但其排名算法比BM25简单。一个真正的BM25扩展需要创建新的索引类型,以针对BM25公式优化的格式存储词频、文档频率和文档长度:`score(D, Q) = Σ IDF(q_i) * (f(q_i, D) * (k1 + 1)) / (f(q_i, D) + k1 * (1 - b + b * |D| / avgdl))`。高效实现意味着将评分计算下推到索引扫描阶段,避免在排名前物化所有候选行。

其次,它需要与查询规划器深度集成。对于结合BM25关键词搜索和pgvector相似性搜索的混合查询,规划器必须就索引组合(例如,对两个索引结果的位图AND/OR操作)和最优检索顺序做出智能决策。像`pgvectorscale`这样的项目已经通过引入基于磁盘的近似最近邻(ANN)索引和查询规划优化,解决了纯内存向量搜索的扩展性问题。新的BM25扩展必须设计成能与这个向量技术栈无缝互操作。

一个体现此方向的相关开源项目是`pg_bm25`,它是一个基于`pgvector`和`pgvectorscale`构建的扩展。它引入了新的`BM25`索引类型和相应的查询操作符。早期的基准测试(尽管仍在演进中)显示,在数百万文档的数据集上进行纯关键词搜索时,其延迟表现令人鼓舞,但在海量数据集上与经过调优的Elasticsearch集群达到绝对性能持平,仍是正在进行的工作。

| 搜索类型 | Postgres + `pg_bm25` (P95延迟) | Elasticsearch (P95延迟) | 架构复杂度 |
|---|---|---|---|
| 纯关键词搜索 (100万文档) | ~45毫秒 | ~25毫秒 | 单一数据库 vs. 双系统 |
| 混合搜索 (关键词+向量) | ~120毫秒 | ~180毫秒 + 同步开销 | 原生连接 vs. 应用层融合 |
| 数据新鲜度 (写入到可搜索) | 即时 (事务性) | 数秒至数分钟 (异步同步) | 内置 vs. 外部管道 |

数据洞察: 原生Postgres解决方案以牺牲部分峰值关键词搜索延迟为代价,换取了架构简洁性、数据新鲜度和混合查询效率的巨大提升。其真正价值体现在组合工作流中,消除系统间延迟和复杂性所带来的收益,超过了原始关键词搜索速度的优势。

关键参与者与案例研究

这项开发由Supabase和Tembo等公司的工程师牵头,但其开源性质意味着贡献来自整个社区。Supabase将自身定位为开源Firebase替代品,有明确的动机将Postgres增强为一个全面的后端。他们对`pgvector`的集成以及对BM25方向的倡导,是产品驱动增长的一个典型案例:他们为开发者提供构建AI功能的简易工具,从而推动其托管平台的采用。

另一个关键参与者是Tembo,一家由前微软和Citus Data工程师创立的Postgres平台公司。他们明确提出了通过扩展将Postgres转变为“平台之平台”的战略。他们在`pgvectorscale`上的工作直接解决了纯内存向量搜索受内存限制的问题,而原生BM25扩展则是完善检索能力的合乎逻辑的下一步。

在竞争方面,Elasticsearch(及其开源分支OpenSearch)仍是现有主导者。Elastic N.V.一直积极进军AI/可观测性领域,但其核心搜索产品与运营数据库是分离的集群。Weaviate和Pinecone等公司提供托管向量数据库,并开始添加稀疏-稠密(混合)搜索能力,但它们并非完整的关系型数据库。

| 解决方案 | 主要优势 | 混合搜索实现方式 | 运营模式 |
|---|---|---|---|
| Postgres + `pg_bm25`/`pgvector` | 统一的SQL、ACID、单一系统 | 原生,在查询规划器内实现 | 自托管或托管Postgres |
| Elasticsearch + 应用层 | 峰值关键词搜索性能,横向扩展 | 应用端融合独立查询结果 | 独立集群,通常托管 |
| Weaviate/Pinecone | 高性能向量相似性搜索 | 原生混合排名 (Alpha/Beta阶段) | 独立的托管服务 |
| SQL向量数据库 (SingleStore等) | SQL接口,部分事务支持 | 专有集成引擎 | 专有数据库 |

数据洞察: 竞争格局正在分化为统一平台(Postgres)与最佳组合、专业化系统两大阵营。

常见问题

GitHub 热点“Postgres BM25 Extension Challenges Elasticsearch in AI's Hybrid Search Race”主要讲了什么?

The release of a high-performance, native BM25 search extension for PostgreSQL marks a watershed moment in database evolution, driven by the demands of modern AI applications. Deve…

这个 GitHub 项目在“pg_bm25 vs Elasticsearch performance benchmarks 2024”上为什么会引发关注?

The technical ambition behind a native Postgres BM25 extension is profound: to make a relational database behave like a best-in-class search engine without leaving its transactional environment. The challenge is not mere…

从“how to implement hybrid search in PostgreSQL with pgvector and BM25”看,这个 GitHub 项目的热度表现如何?

当前相关 GitHub 项目总星标约为 0,近一日增长约为 0,这说明它在开源社区具有较强讨论度和扩散能力。