AlloyDB: A unified database engine for hybrid search

使用 AlloyDB 混合搜索和 RRF 简化 AI 搜索 | Google Cloud 博客

数据库

AlloyDB：用于混合搜索的统一数据库引擎

2026年10月6日

##### Kumar Ramamurthy

数据库高级产品经理

##### Ricky Zhou

数据库软件工程师

##### 11月4日：Agentic Data Cloud 活动

加入我们的产品负责人，构建您的自主代理未来

注册

对于现代 AI 和 RAG 应用程序，实现高搜索相关性需要结合至少两种技术：向量搜索用于语义上下文，全文搜索（FTS）用于关键词精确匹配。虽然 AlloyDB for PostgreSQL 支持这两种能力，但传统上要确保最佳性能，需要更手动的操作方式。

挑战不在于执行搜索，而在于后续的结果集融合。将向量查询（距离分数）和 FTS 查询（相关性分数）的结果合并，需要复杂的 SQL 查询或应用层的自定义代码。这通常意味着需要维护一个独立的系统来进行融合、分数归一化和重新排序。

本文详细介绍了 AlloyDB AI 的混合搜索如何消除这种复杂性。我们将探讨最近的更新如何让您：

• 简化混合搜索：通过互惠排名融合（RRF）技术，将复杂的 SQL 查询或多步骤的应用程序工作流程整合到一个高性能的 SQL 函数中。
• 优化 FTS 性能：使用新的 RUM 扩展，通过直接在索引中存储词位置，实现低延迟的相关性排序和高效的短语匹配。
• 利用行业标准排名：使用新原生支持的 BM25 索引，开箱即用实现更优的基于关键词的评分。
• 扩展搜索灵活性：通过新的外部搜索 Foreign Data Wrapper（FDW）在不离开 AlloyDB 环境的情况下，对专用外部集群（包括 Elasticsearch、OpenSearch 和 Solr）执行查询。

多步骤工作流的问题

在 AlloyDB AI 原生解决方案出现之前，实现强大的混合搜索非常具有挑战性，尤其是对试图使用标准 SQL 在数据库中保持此逻辑的开发人员而言。这种方法需要多步骤的编排，不仅难以管理和维护两个数据源，而且随着添加更多数据源，几乎不可能扩展。这些步骤包括：

• 执行向量搜索：使用向量列或向量索引（对于 AlloyDB 可以是 ScaNN 索引）运行查询，找到前 k 个结果，生成向量分数。
• 执行 FTS 查询：使用通用倒排索引（GIN）运行 FTS 查询，找到前 k 个结果。
• 归一化分数（脆弱的步骤）：编写复杂的 SQL 逻辑或自定义应用程序代码，将两个结果集映射到同一尺度。当数据分布变化时，这种逻辑容易失效。
• 执行跨服务连接和重新排序：使用应用程序内存对文档 ID 执行复杂的 FULL OUTER JOIN，对归一化分数进行加权求和，最后在 FTS 搜索与向量搜索使用的系统不同时，对合并结果进行排序。

这种分散的方法导致了脆弱的评分逻辑、增加的延迟、高操作负载，以及对应用程序专业知识的依赖以保持搜索质量。

简化这一过程的关键在于采用 RRF（Reciprocal Rank Fusion，倒数排名融合），由于其本质上是基于排名的，因此巧妙地完全绕过了分数归一化这一脆弱的步骤。RRF 包含两个部分：

#### 1. 单一数据源

您无需采用多步骤的获取和连接流程，只需调用一个 SQL 函数，将搜索组件作为声明式 JSON 数组提供：

SQL

加载中...

SELECT id, score FROM ai.hybrid_search( search_inputs => ARRAY[ -- 向量组件（语义），通过自然语言动态生成嵌入向量 $json${ "data_type": "vector", "limit": 10, "table_name": "documents", "key_column": "doc_id", "vec_column": "embedding", "distance_operator": "<=>", "query_vector": "ai.embedding('text-embedding-005', 'alloydb search')::vector" }$json$::jsonb, -- 文本组件（关键词） $json${ "data_type": "text", "limit": 10, "table_name": "documents", "key_column": "doc_id", "text_column": "content", "query_text_input": "alloydb search" }$json$::jsonb ] );

（注：统一的 ai.hybrid_search API 不仅限于两个组件。它还通过新的 FDW 原生支持外部搜索源。）

#### 2. 数据库原生编排

hybrid_search() 函数通过单个查询计划执行整个工作流，最小化开销并帮助确保事务一致性。它使用以下技术：

• 动态 CTE 生成：该函数构建动态 SQL，为每个组件创建通用表表达式（CTE）。每个 CTE 负责计算其结果的位置排名（ROW_NUMBER()）。

• 内核级融合：所有排名组件结果立即通过基于文档 ID 的 FULL OUTER JOIN 进行合并。

• 最终 RRF 分数：使用 RRF 公式通过合并后的排名计算最终统一分数：

通过采用这种方法，脆弱的分数计算和应用层连接变得不再必要。虽然目前我们使用倒数排名融合（RRF）作为排名算法，但未来计划引入其他合并和排名选项。

结果：性能与操作简洁性

从复杂的外部工作流转向原生 SQL 函数可立即带来可衡量的收益：

| 指标 | 多步骤应用工作流（通过手动 SQL 模拟） | AlloyDB AI 原生 hybrid_search() UDF | |------|----------------------------------|-------------------------------| | 代码复杂度 | 复杂的分数归一化函数、服务调用和应用连接 | 零外部逻辑；单个声明式 SQL 调用 | | 维护 | 持续调整归一化公式 | 无需调整；RRF 基于排名且与分布无关 |

提升 FTS 性能：RUM 扩展

AlloyDB AI 的 hybrid_search() 函数旨在通过结合高性能向量搜索与 FTS（全文搜索）来实现全面的搜索相关性。虽然 AlloyDB 的原生 FTS 功能强大，但文本组件依赖标准 PostgreSQL GIN 索引可能导致高级操作出现瓶颈。

GIN 索引的挑战在于它们不存储词语的位置信息。这一限制迫使代价高昂的表扫描重新分析内容以实现：

• 相关性排名：基于词语接近度和频率计算搜索结果分数

• 短语搜索：查找精确词序，这需要位置信息。

#### 引入 RUM 扩展实现低延迟 FTS

RUM 扩展是一种基于 GIN 的强大索引访问方法，可直接解决这些性能问题。

• RUM 的核心优势：与 GIN 索引（将单词映射到 [docID]）不同，RUM 索引直接在索引中存储每个单词的位置信息（例如，单词 -> [(docID1, [pos])], ...）。

• 性能优势：这使得 RUM 能够在索引内部执行复杂的操作（如排序和短语匹配），避免代价高昂的堆扫描。RUM 提供显著更快的相关性排序和高效的短语及邻近性搜索。

• 适用于混合搜索：RUM 是混合搜索框架中向量搜索（如 ScaNN）的关键补充，因为 GIN 的潜在延迟使其不太适合实时混合搜索场景。

RUM 扩展是需要大量排序或高并发搜索应用的绝佳选择。通过直接在索引中存储单词位置，RUM 消除了排序过程中重新扫描表页的需要，从而为您提供快速且有序的结果。然而，它也伴随着一些权衡：索引构建速度较慢且磁盘占用更大。如果您的工作负载优先考虑快速查询和精确排序，而非写入速度和存储密度，RUM 是一项值得投资的方案。

#### 可衡量的收益与集成

直接采用 RUM 可显著提升 AlloyDB 中 FTS 的性能，在原始 FTS 查询和包含 FTS 查询的混合搜索中均表现出明显收益。以下性能统计数据展示了在各种 BEIR 数据集上使用 RUM 相比 GIN 的加速效果。

（性能基于使用 BEIR Natural Questions 基准测试的结果。）

RUM 与专用的 <=> 距离运算符集成，该运算符支持在混合搜索 SQL 调用中使用，实现了两者的最佳结合。以下代码示例展示了如何配置并使用 RUM 索引与混合搜索 UDF。

引入 BM25 索引：现代排序标准

我们最近在 CloudSQL 和 AlloyDB 的预览版中引入了 BM25 索引，通过 pg_textsearch 扩展实现了行业标准的相关性排序。BM25 使用 TF-IDF，考虑了词频饱和度和文档长度归一化，为基于关键词的搜索查询提供了显著更高的精度和质量。通过在 AlloyDB AI 中利用原生 BM25 索引，您可以开箱即用地实现更优越的排序准确性，使精确匹配和关键关键词无需依赖外部搜索引擎或复杂的自定义评分逻辑即可获得高分。

-- 安装 pg_textsearch 扩展 CREATE EXTENSION pg_textsearch; -- 在 content 列上创建原生 BM25 索引 CREATE INDEX idx_docs_bm25 ON cymbal_products USING bm25 (product_description) WITH (text_config='english'); -- 全文搜索查询 SELECT product_name, product_description <@> 'cherry tree' AS bm25_score FROM cymbal_products ORDER BY bm25_score LIMIT 5;

外部搜索：通过外部数据包装器扩展灵活性

为了进一步扩展搜索功能，我们还在 AlloyDB AI 中引入了外部搜索的外部数据包装器（FDW）。这使您能够针对专用的外部集群（如 Elasticsearch、OpenSearch 和 Solr）执行全文搜索，并提供以下关键架构优势：

• 优化检索：无需离开 AlloyDB 环境，即可利用专用搜索后端的排序算法和更丰富的功能集。

• 统一的 SQL 接口：通过标准 PostgreSQL SQL 与外部数据进行交互，执行连接操作并合并结果，同时不丢失高级 FTS 查询的表达能力。

• 强大的可移植性：在保留现有搜索基础设施的同时，受益于 AlloyDB AI 提供的简化混合架构。

以下 codelabs 是端到端的代码指南，逐步演示如何通过 Elasticsearch 和 Solr 集成实现混合搜索。

用于 AI 驱动搜索的统一架构

现代搜索的真正挑战并非技术本身，而在于实现架构的简洁性和持续的操作稳定性。AlloyDB AI 通过三大核心技术创新构建统一平台来解决这一问题：

• 简化混合搜索：AlloyDB AI 的混合搜索功能基于 RRF 实现，将原本脆弱的多步骤应用工作流转化为单一的高性能 SQL 调用。这种原生实现消除了复杂评分归一化和应用层连接的需求，大幅降低运营和工程成本，同时持续提供准确且快速的混合相关结果。

• 优化 FTS 性能：为确保混合搜索的 FTS 组件满足多样化的应用需求，AlloyDB AI 提供了多种全文搜索选项。RUM 扩展通过将位置数据直接存储在索引中，优化了低延迟性能，从而实现更快的相关性排序和高效的短语搜索——这对于需要快速查询速度的场景至关重要。或者，BM25 索引提供行业标准的相关性排序，是优先考虑关键词评分精度时的首选方案。您可以根据搜索延迟或排序精度的侧重点，在这些选项之间进行选择。

• 通过外部搜索增强多功能性：通过 FDW 实现的外部搜索功能将 AlloyDB 的能力扩展到 Elasticsearch 等专用搜索后端。这使您可以利用专用搜索集群的卓越扩展性和高级检索功能，同时保持熟悉的 PostgreSQL 接口。通过将这些外部结果直接集成到混合搜索框架中，AlloyDB AI 确保您能够将最庞大的文本仓库与基于向量的语义洞察相结合。

通过将评分、连接和重新排序的复杂性集中在数据库内核中，并提供两种 FTS 路径——利用 RUM 实现优化的低延迟内部 FTS，或通过外部搜索对接专用的可扩展后端——AlloyDB AI 提供了强大且自包含的搜索基础。这种共存关系是混合搜索整体方案的关键，提供了根据工作负载、数据量和现有基础设施选择最佳路径的灵活性。现在，您可以专注于构建智能应用功能，同时确信搜索架构既高性能又易于维护。

立即体验

观看 AlloyDB 如何成为终极混合搜索引擎。

了解 AlloyDB 中的 BM25 支持。

入门指南

准备好为 AI 工作负载带来更高的速度和成本效率？

• 新手用户？通过 30 天免费试用体验 AlloyDB。

• 开始使用混合搜索：创建文本搜索索引并选择向量搜索索引。创建完成后，您可以参考示例执行各种混合搜索查询。

• 外部搜索：在 AlloyDB 中创建外部数据包装器和外部表，以查询来自 Elasticsearch、Solr 或 OpenSearch 的外部数据。

发布于

• 数据库