向量搜索是生成式AI、RAG和数据智能体的关键组件，但有时候只靠向量搜索不够。向量嵌入擅长理解概念语义，却在精确的字母数字ID和产品SKU上表现不佳。构建真正稳健的搜索和AI应用，往往需要把语义向量搜索和传统精确关键词全文搜索结合起来，这就是混合搜索。

在搜索领域，BM25是评估文档与查询相关性的核心算法。以前要在AlloyDB或Cloud SQL上获得BM25排名，必须额外搭一套全文搜索后端，由此带来数据孤岛、同步延迟和运维复杂性。现在Google Cloud在AlloyDB和Cloud SQL for PostgreSQL 17+上预览原生BM25索引，基础是TigerData的开源pg_textsearch扩展。这样就不需要再为全文检索单独准备和维护一套系统，直接在数据库内部完成，那里存着你的运营数据。

这次预览带来的具体好处包括：行业标准的BM25关键词排名，由TigerData的pg_textsearch提供C优化的快速评分；消除了多后端带来的数据重复、ETL管道和同步滞后；AlloyDB独有的向量搜索加速，使用ScaNN和HNSW索引类型，向量查询比标准PostgreSQL快6倍和10倍。

为什么选择BM25而不是PostgreSQL内置的ts_rank？ts_rank在规模变大后排名质量下降：它不支持逆文档频率，常见词和罕见词权重一样；没有词频饱和，一篇提到“database”50次的文档会压过只提到1次的文档。BM25是信息检索的黄金标准，具备逆文档频率（罕见词更重要）、词频饱和（重复不会主导）以及文档长度归一化。

开始使用很简单。先启用pg_textsearch扩展，在product_description列上创建索引；查询时用<@>操作符，例如搜索“cherry tree”。注意分数越负，相关性越强。

AlloyDB的混合搜索设置很直接：同一张表上同时创建向量索引和关键词索引，然后用内置的混合搜索UDF，通过RRF算法把两路排名合并成统一列表。示例查询同时做向量搜索“trees that grow taller than houses”和关键词搜索“California”，结果里“California Sycamore”这类既符合语义又精确匹配本地信息的条目会排在最前。向量部分负责理解概念，全文部分负责精确约束。

Cloud SQL也支持同样的混合搜索路径：在同一表建两种索引，用公共表表达式（CTE）和合并RRF分数的方式拼出混合查询，输出结果与AlloyDB一致。

目前这是预览功能，并且只面向PostgreSQL 17+。如果你正在做RAG、AI数据智能体，或者任何同时需要语义理解和精确标识匹配的应用，这个能力可以把检索架构收敛到单一数据库，减少一套需要维护的全文搜索系统。