# 混合文本搜索混合搜索将关键字搜索 (BM25) 与语义搜索（向量嵌入）相结合，以充分利用两者的优点：精确的关键字匹配和基于含义的检索。使用倒数排名融合 (RRF) 将两种方法的结果合并到单个排名列表中。本指南介绍了将 [pg_textsearch]() (BM25) 与 [pgvector]() 结合起来。需要两个扩展。对于大容量设置、过滤或高级 pgvector 调整（二进制量化、HNSW 参数），请参阅 **pgvector-semantic-search** 技能。 pg_textsearch 是 PostgreSQL 的新 BM25 文本搜索扩展，完全开源，可托管在 Tiger Cloud 上，也可用于自我管理部署。它提供真正的 BM25 排名，与 PostgreSQL 的内置 ts_rank 相比，这通常可以提高相关性，并且可以大规模提供更好的性能。注意：pg_textsearch 目前处于预发布阶段，尚不建议用于生产使用。 pg_textsearch 目前支持 PostgreSQL 17 和 18。 ## 何时使用混合搜索 * **当查询将特定术语（产品名称、代码、专有名词）与概念意图混合时使用混合** * **当含义比确切的措辞更重要时，仅使用语义**（例如，“如何修复慢速查询”应与“查询优化”匹配） * **仅在精确匹配至关重要时使用关键字**（例如，错误代码、SKU、法律引用）混合搜索通常比单独使用任何一种方法都提高了召回率，但代价是复杂性稍高。 ## 数据准备将文档分成更小的块（通常为 500-1000 个标记），并存储每个块及其嵌入。 BM25 和语义搜索都在相同的块上运行 - 这使融合变得简单，因为您正在比较同类。 ## 黄金之路（默认设置） -- 启用扩展如果不存在则创建扩展向量；如果不存在则创建扩展 pg_textsearch; -- 具有两个索引的表创建表文档（ id BIGINT 始终作为身份主键生成，内容文本不为空，嵌入 halfvec(1536) NOT NULL ）； -- BM25关键字搜索索引使用 bm25（内容）WITH (text_config = 'english'); 在文档上创建索引 -- 用于语义搜索的 HNSW 索引使用 hnsw 创建文档索引（嵌入 halfvec_cosine_ops）； ### BM25 注释 * **负分数** ：`<@>` 运算符返回负值，其中较低 = 更好匹配。 RRF使用rank位置，因此这不会影响融合。 * **语言配置** ：更改 `text_config` 以匹配您的内容语言（例如，`'法语'`、''德语'`）。请参阅 [PostgreSQL 文本搜索配置]()。 * **调优** ：BM25 有 `k1` （词频饱和度，默认 1.2）和 `b` （长度归一化，默认 0.75）参数。默认值效果很好；仅在相关性较差时进行调整。使用 bm25（内容）WITH (text_config = 'english', k1 = 1.5, b = 0.8); 在文档上创建索引 * **分区表** ：每个分区维护本地统计信息。分数不能直接在分区之间进行比较 - 当分数可比性很重要时查询各个分区。 ## RRF 查询模式倒数排名融合结合了多个搜索的排名。每个结果的分数为“1/(k + 排名)”，其中“k”是常数（通常为 60）。对搜索结果进行汇总并重新排序。 **从客户端并行运行两个查询**以降低延迟，然后在客户端融合结果： -- 查询1：关键字搜索（BM25） -- $1: 搜索文本 SELECT id, content FROM 文档 ORDER BY content <@> $1 LIMIT 50; -- 查询2：语义搜索（单独查询，并行运行） -- $1：将搜索文本嵌入为 halfvec(1536) 从文档中选择 id、内容 ORDER BY 嵌入 <=> $1::halfvec(1536) LIMIT 50; # 客户端 RRF 融合 (Python) def rrf_fusion（关键字结果，语义结果，k = 60，限制= 10）：分数 = {} 内容地图 = {} 对于排名，枚举中的行（keyword_results，start = 1）：分数[行['id']] = 分数.get(行['id'], 0) + 1 / (k + 排名) content_map[行['id']] = 行['内容'] 对于排名，枚举中的行（semantic_results，start = 1）：分数[行['id']] = 分数.get(行['id'], 0) + 1 / (k + 排名) content_map[行['id']] = 行['内容'] sorted_ids = 排序（分数，key=scores.get，reverse=True）[：限制] 返回 [{'id': id, 'content': content_map[id], 'score': Scores[id]} for sorted_ids 中的 id] // 客户端 RRF 融合 (TypeScript) 类型行 = { id: 数字;内容：字符串}；输入结果 = 行 & { 分数: 数字 }; 函数 rrfFusion(keywordResults: Row[], SemanticResults: Row[], k = 60, limit = 10): Result[] { const Scores = new Map(); const contentMap = new Map<数字, 字符串>(); keywordsResults.forEach((行, i) => { Scores.set(row.id, (scores.get(row.id) ?? 0) + 1 / (k + i + 1)); contentMap.set(row.id, row.content); }); SemanticResults.forEach((行, i) => { Scores.set(row.id, (scores.get(row.id) ?? 0) + 1 / (k + i + 1)); contentMap.set(row.id, row.content); }); 返回 [...scores.entries()] .sort((a, b) => b[1] - a[1]) .slice(0, 限制) .map(([id, 分数]) => ({ id, 内容: contentMap.get(id)!, 分数 })); } ### RRF 参数参数|默认 |描述 ---|---|--- `k` | 60|平滑常数。较高的值会减少排名差异； 60为标准每次搜索的候选人 | 50 | 50更高=更好的回忆，更多的工作最终限制| 10 | 10融合后返回结果如果缺少相关结果，则增加候选人。 k=60 常数很少需要调整。 ## 关键词加权与语义加权要使一种方法优于另一种方法，请将其 RRF 贡献相乘： # 语义搜索权重比关键字高 2 倍关键字权重 = 1.0 语义权重 = 2.0 对于排名，枚举中的行（keyword_results，start = 1）： Scores[row['id']] = Scores.get(row['id'], 0) + keywords_weight / (k + 排名) 对于排名，枚举中的行（semantic_results，start = 1）：分数[行['id']] = 分数.get(行['id'], 0) + 语义权重 / (k + 排名) // 语义搜索权重比关键字高 2 倍 const 关键字权重 = 1.0; 常量语义权重 = 2.0; keywordsResults.forEach((行, i) => { Scores.set(row.id, (scores.get(row.id) ?? 0) + keywordsWeight / (k + i + 1)); }); SemanticResults.forEach((行, i) => { Scores.set(row.id, (scores.get(row.id) ?? 0) + SemanticWeight / (k + i + 1)); }); 从相同的权重（每个 1.0）开始，并根据测量的相关性进行调整。 ## 使用 ML 模型重新排名为了获得最高质量，请使用交叉编码器模型添加重新排名步骤。交叉编码器（例如“cross-encoder/ms-marco-MiniLM-L-6-v2”）比双编码器更准确，但对于初始检索来说速度太慢 - 仅在候选集上使用它们。使用更高的 LIMIT（例如 100）运行与上面相同的并行查询，然后： # 1. 将结果与 RRF 融合（更多候选者进行重新排名）候选人= rrf_fusion（关键字_结果，语义_结果，限制= 100） # 2. 使用交叉编码器重新排序从句子转换器导入 CrossEncoder reranker = CrossEncoder('交叉编码器/ms-marco-MiniLM-L-6-v2') pairs = [(query_text, doc['content']) for doc in Candidates] 分数 = reranker.predict(pairs) # 3. 按重新排序分数返回前 10 名重新排序=排序（zip（候选人，分数），key = lambda x：x [1]，reverse = True）[：10] 从 'cohere-ai' 导入 { CohereClientV2 }； // 1. 将结果与 RRF 融合（更多候选者进行重新排名） const 候选者 = rrfFusion(keywordResults, SemanticResults, 60, 100); // 2. 通过 API 重新排名（示例使用 Cohere SDK；Jina、Voyage 等的工作原理类似） const cohere = new CohereClientV2({ 令牌: COHERE_API_KEY }); const reranked = 等待 cohere.rerank({ 型号：'rerank-v3.5'，查询：查询文本，文档：candidates.map(c => c.content), 前N：10 }); // 3. 映射回原始文档 const results = reranked.results.map(r => Candidates[r.index]); 重新排序是可选的——单独的混合 RRF 比单一方法搜索显着改进。 ## 性能考虑因素 * **对两列建立索引** ：BM25 文本索引，HNSW 嵌入索引 * **限制候选池**：每种方法 50-100 个候选通常就足够了 * **并行运行查询**：客户端并行性与顺序执行相比减少了延迟 * **监控延迟**：混合会增加开销；确保两个索引都适合内存 ## 使用 pgvectorscale 进行缩放对于大型数据集（10M+ 向量）或具有选择性元数据过滤器的工作负载，请考虑使用 [pgvectorscale]() 的 StreamingDiskANN 索引，而不是语义搜索组件的 HNSW。 **何时使用 StreamingDiskANN：** * HNSW 无法放入内存的大型数据集 * 按标签过滤的查询（例如，tenant_id、category、tags） * 当您需要高性能过滤矢量搜索时 **基于标签的过滤：** StreamingDiskANN 支持“smallint[]”标签列上的过滤索引。标签与向量一起索引，从而实现高效的过滤搜索，而不会损失过滤后的准确性。 -- 启用 pgvectorscale（除了 pgvector 之外）如果不存在则创建扩展 -- 带标签列的表用于过滤创建表文档（ id BIGINT 始终作为身份主键生成，内容文本不为空，嵌入 halfvec(1536) NOT NULL, 标签smallint[] NOT NULL——例如类别ID、租户ID ）； -- 带标签过滤的 StreamingDiskANN 索引使用diskann在文档上创建索引（嵌入向量余弦操作，标签）； -- BM25关键字搜索索引使用 bm25（内容）WITH (text_config = 'english'); 在文档上创建索引 -- 使用 && 过滤语义搜索（数组重叠）从文档中选择 ID、内容 WHERE 标签 && ARRAY[1, 3]::smallint[] 按嵌入 <=> $1::halfvec(1536) LIMIT 50 排序；有关过滤索引和调整参数的更多详细信息，请参阅 [pgvectorscale 文档]()。 ## 监控与调试 -- 强制使用索引进行验证（计划者可能更喜欢在小表上使用 seqscan）设置enable_seqscan = 关闭； -- 验证是否使用了 BM25 索引 EXPLAIN SELECT id, content FROM Documents ORDER BY content <@> '搜索文本' LIMIT 10; -- 查找：使用...进行索引扫描 (bm25) -- 验证 HNSW 索引是否已使用解释 SELECT id, content FROM 文档 ORDER BY embedding <=> '[0.1, 0.2, ...]'::halfvec(1536) LIMIT 10; -- 查找：使用...进行索引扫描 (hnsw) 设置enable_seqscan = on; -- 重新启用即可正常运行 -- 检查索引大小 SELECT 索引名称, pg_size_pretty(pg_relation_size(indexname::regclass)) AS 大小 FROM pg_indexes WHERE 表名 = '文档'; 如果 EXPLAIN 仍然显示“enable_seqscan = off”的顺序扫描，请验证索引是否存在并且查询使用正确的运算符（对于 BM25 为“<@>”，对于余弦为“<=>”）。有关更多 pgvector 调试指南，请参阅 **pgvector-semantic-search** 技能。 ## 常见问题症状|可能的原因 |修复 ---|---|--- 缺少精确匹配 |关键词搜索未返回|检查BM25索引是否存在；验证 text_config 与内容语言匹配语义结果不佳 |嵌入模型不匹配 |确保查询嵌入使用与存储嵌入相同的模型慢查询 |候选池庞大或索引缺失 |减少内部LIMIT；验证两个索引都存在并且已使用（解释）倾斜的结果 |一种方法占主导地位|调整RRF权重；验证两个搜索都返回合理的候选者

Postgres 混合文本搜索

包含技能