第20章 查询改写与混合检索：提升召回率的实战技巧

20.1 为什么需要查询改写？

用户的提问方式千奇百怪，但知识库中的文档写法是固定的。如果用户的问题和文档的表述差异太大，Embedding模型可能无法准确匹配，导致检索不到相关内容。

常见的用户提问问题：

• 太口语化："咋弄"、"怎么办"、"啥情况"——Embedding模型难以理解真实意图
• 太简短："密码"、"报错"、"保养"——信息太少，无法准确匹配
• 太模糊："设备有问题"——什么设备？什么问题？无法定位
• 用词不同：用户说"机器人"，文档里写"机械臂"；用户说"保养"，文档里写"维护"——同义词匹配困难
• 包含冗余信息："你好，我是张三，今天早上我在车间遇到一个问题，就是那个ABB的机器人..."——前面的寒暄和背景信息干扰检索
• 多意图混合："怎么重置密码还有怎么绑定手机"——两个问题混在一起，检索时互相干扰

20.2 查询改写的核心方法

20.2.1 用大模型改写（最常用）

最常用的查询改写方法是用大模型（GPT、Claude、DeepSeek等）把用户的原始问题改写成更适合检索的查询。

典型的查询改写Prompt模板：

你是一个查询改写助手。请把用户的问题改写成适合知识库检索的查询。

改写规则：
1. 去除寒暄、冗余背景信息，保留核心问题
2. 把口语化表达改成书面语、专业术语
3. 补充可能的同义词和相关术语
4. 如果问题太简短，补充合理的上下文
5. 如果包含多个问题，拆分成多个独立查询
6. 输出格式：JSON，包含"queries"数组，每个元素是一个改写后的查询

用户问题：{user_question}

改写结果：

20.2.2 查询扩展（Query Expansion）

查询扩展是在原始问题基础上，添加同义词、相关词、上下位词，丰富查询的语义覆盖范围。

方法：

• 同义词扩展："机器人"→"机器人、机械臂、机械手、工业机器人"；"保养"→"保养、维护、维保、检修"
• 缩写/全称扩展："PLC"→"PLC、可编程逻辑控制器"；"MES"→"MES、制造执行系统"
• 上下位词扩展："轴承"→"轴承、滚动轴承、滑动轴承、深沟球轴承"
• 相关词扩展："故障"→"故障、异常、报警、报错、停机、损坏"

实现方式：

• 用大模型生成扩展词（最简单，效果好）
• 用同义词词典（如WordNet、哈工大同义词词林）
• 用领域知识库构建同义词表（制造业、医疗等专业领域效果更好）

注意：查询扩展不是越多越好，扩展太多不相关的词会引入噪音，降低精确率。要控制扩展词的数量（通常3-5个），并确保扩展词和原始问题语义相关。

20.2.3 多查询生成（Multi-Query）

多查询生成是让大模型根据用户的原始问题，生成多个不同角度、不同表述的查询，分别检索后合并结果。

和查询改写的区别：

• 查询改写：把原始问题改写成1个更好的查询（1对1）
• 多查询生成：根据原始问题生成3-5个不同角度的查询（1对多）

多查询的角度可以包括：

• 不同表述方式（书面语、口语、专业术语）
• 不同侧重点（现象、原因、解决方案）
• 不同粒度（宽泛、具体）
• 同义词替换

优点：从多个角度检索，大幅提升召回率，避免因为单一查询表述不对而漏检。
缺点：检索次数增加3-5倍，延迟和成本增加；结果合并需要去重和重排序。
适用场景：对召回率要求高、用户问题表述不规范、知识库内容分散。

20.2.4 假设性文档生成（HyDE）

HyDE（Hypothetical Document Embeddings，假设性文档嵌入）是一种巧妙的检索优化方法：先让大模型根据用户问题生成一个"假设的答案文档"，然后用这个假设文档去检索，而不是用原始问题。

为什么有效？

• 用户问题通常很短（几个字到几十个字），语义信息少
• 知识库中的文档通常较长（几百字到几千字），语义信息丰富
• 短问题和长文档的向量分布不一致，相似度计算不准确
• HyDE生成的假设文档和真实文档长度、风格、分布更接近，检索更准确

工作流程：

1. 用户提问："ABB机器人IRB6700保养周期"
2. 大模型生成假设答案："ABB机器人IRB6700的保养周期分为日常检查、周保养、月保养、年保养。日常检查每班进行，包括清洁、检查气源...周保养每周五进行，包括检查运动顺畅性...月保养每月1号进行，包括更换润滑油...年保养每年12月进行，包括全面拆解检查..."
3. 用这个假设答案的向量去知识库检索
4. 检索到的真实文档和假设答案语义接近，相关性更高

优点：在某些场景下召回率提升明显（尤其是用户问题简短、文档较长时）。
缺点：

• 增加一次大模型调用，延迟和成本增加
• 如果大模型生成的假设答案偏差太大，会误导检索
• 对事实性、精确匹配的问题效果不一定好

20.2.5 子问题分解（Sub-Query Decomposition）

当用户的问题比较复杂，包含多个子问题或需要多步推理时，可以把复杂问题分解成多个简单的子问题，分别检索后综合回答。

例子：
原始问题："对比一下ABB和发那科的工业机器人在汽车焊接线上的应用，包括价格、精度、维护成本"
分解为：
1. "ABB工业机器人在汽车焊接线的应用"
2. "发那科工业机器人在汽车焊接线的应用"
3. "ABB机器人价格"
4. "发那科机器人价格"
5. "ABB机器人重复定位精度"
6. "发那科机器人重复定位精度"
7. "ABB机器人维护成本"
8. "发那科机器人维护成本"
分别检索后，大模型综合所有信息给出对比分析。

优点：复杂问题拆解后，每个子问题更简单，检索更准确；能覆盖问题的各个方面，避免遗漏。
缺点：检索次数多，延迟高；子问题分解质量取决于大模型；结果综合复杂。
适用场景：复杂分析类问题、对比类问题、需要多方面信息的问题。

20.3 混合检索（Hybrid Search）

20.3.1 为什么需要混合检索？

向量检索（语义检索）和关键词检索（全文检索）各有优劣：

可以看到，向量检索和关键词检索是互补的：向量检索擅长语义匹配，关键词检索擅长精确匹配。混合检索就是把两者结合起来，同时用两种方式检索，然后合并结果，取各自的优势。

20.3.2 混合检索的工作流程

1. 向量检索：用Embedding模型把用户问题转成向量，在向量数据库中检索Top-N个最相似的文档块，每个文档块有一个语义相似度分数
2. 关键词检索：用BM25算法（或其他全文检索算法）在倒排索引中检索包含用户问题关键词的文档块，每个文档块有一个关键词匹配分数
3. 结果合并：把两路检索的结果合并，相同的文档块取分数加权和（或用RRF等融合算法）
4. 重排序：合并后的结果用Reranker精排（可选但推荐），取Top-K传给大模型

20.3.3 结果融合算法

两路检索的分数分布不一样（向量相似度是0-1的余弦值，BM25是0到几十的整数），不能直接相加。需要用融合算法合并。

方法1：加权和（Weighted Sum）
把两路分数分别归一化到0-1，然后加权相加：
`final_score = α * vector_score_normalized + (1-α) * bm25_score_normalized`
α是权重系数，通常0.5-0.7（向量检索权重稍高）。需要根据你的数据调优。

优点：简单直观，可解释性强。
缺点：需要调参，分数归一化方法影响结果。

方法2：RRF（Reciprocal Rank Fusion，倒数排名融合）
不看分数，只看排名。对每个文档块，在两路检索中的排名分别取倒数，然后相加：
`rrf_score = 1/(k + rank_vector) + 1/(k + rank_bm25)`
k是常数，通常60。

优点：不需要归一化，不受分数分布影响，鲁棒性强，是最常用的融合算法。
缺点：丢失了分数信息（排名第1和第2的差距被压缩了）。

方法3：学习排序（Learning to Rank）
用标注数据训练一个排序模型（如XGBoost、LightGBM），输入是两路检索的分数、排名、文档特征等，输出是最终相关性分数。

优点：精度最高，能自动学习最优融合方式。
缺点：需要大量标注数据，实现复杂，维护成本高。
适用场景：大规模、高精度要求的搜索系统（如搜索引擎、电商搜索）。

20.3.4 混合检索的实现方式

方式1：向量数据库内置混合检索
越来越多的向量数据库支持内置混合检索：

• Milvus：支持标量过滤+向量检索，BM25需要自己实现或用Elasticsearch
• Weaviate：内置BM25+向量混合检索，一行代码搞定
• Qdrant：支持稀疏向量+稠密向量混合检索
• Elasticsearch：8.x版本内置向量检索+BM25混合检索，是最成熟的混合检索方案之一
• pgvector：PostgreSQL的全文检索（tsvector）+ pgvector向量检索，自己写SQL合并

方式2：双系统并行检索
向量检索用Milvus/Qdrant，关键词检索用Elasticsearch/OpenSearch，应用层并行调用两路，然后用RRF融合。

优点：各自用最擅长的系统，性能和效果都好。
缺点：需要维护两套系统，架构复杂。

方式3：单系统搞定（推荐中小团队）
用Elasticsearch 8.x或Weaviate，一个系统同时支持向量检索和BM25，内置混合检索。

优点：架构简单，运维成本低，效果好。
缺点：向量检索性能不如专业向量数据库（但千万级以下够用）。

20.4 查询改写 + 混合检索 + Reranker 的组合拳

在实际生产环境中，这三个技术通常组合使用，形成完整的检索优化 pipeline：

用户问题
    ↓
【查询改写】大模型改写/扩展/多查询生成
    ↓
【多路检索】每个查询分别做：
    ├─ 向量检索（语义匹配）
    └─ 关键词检索（BM25精确匹配）
    ↓
【结果融合】RRF或加权和合并多路结果
    ↓
【Reranker精排】交叉编码器重排序，取Top-K
    ↓
【大模型生成】基于Top-K文档生成答案

20.5 产品经理必须关注的权衡

20.5.1 效果 vs 延迟 vs 成本

建议的优化顺序（投入产出比从高到低）：

1. 混合检索（成本低、效果好、实现简单，优先做）
2. 查询改写（成本中等、效果好，第二优先级）
3. Reranker（效果最好但成本高，第三优先级）
4. 多查询生成（效果好但成本高，对召回率要求极高时再做）
5. HyDE（特定场景有效，按需选择）

20.5.2 什么时候不需要这些优化？

• MVP阶段：先跑通流程，验证产品价值，不要过早优化
• 知识库很小（<1万条）：纯向量检索效果已经够好
• 简单FAQ场景：问题和答案都是短文本，关键词匹配就够
• 对延迟要求极高（<500ms）：这些优化都会增加延迟，可能无法满足
• 预算有限：大模型调用、GPU、API都要钱，先做性价比最高的混合检索

20.6 常见误区

误区1：查询改写就是让大模型"润色"一下问题
查询改写不是简单的润色，而是有明确目标的优化：去除冗余、补充关键词、同义词扩展、多查询生成。改写的目标是"提升检索召回率"，不是"让问题听起来更顺"。要有明确的改写规则和评估标准。

误区2：混合检索就是把两路结果拼在一起
混合检索不是简单的拼接，而是需要融合算法（RRF、加权和等）合并分数和排名。简单拼接会导致重复、排名混乱、分数不可比。要用成熟的融合算法，并做A/B测试验证效果。

误区3：优化技术堆得越多越好
不是所有优化都要上。要根据你的场景、数据、预算、延迟要求选择合适的组合。技术堆太多会导致系统复杂、维护困难、延迟太高、成本失控。先做性价比最高的，逐步优化，每一步都做效果评估。

误区4：优化了检索就不用管知识库质量了
检索优化只能提升"从现有知识库中找到相关内容"的能力，不能解决"知识库本身没有答案"的问题。如果知识库内容不全、不准、过时，检索再厉害也没用。知识库质量是基础，检索优化是锦上添花。

误区5：只看召回率，不看精确率和延迟
召回率提升了，但如果精确率下降（检索了很多不相关的内容），大模型生成答案时会被干扰，答案质量反而下降。同时延迟和成本也要考虑。要综合评估召回率、精确率、答案准确率、延迟、成本，不能只看一个指标。

20.7 本章小结

查询改写和混合检索是提升RAG召回率的两大核心技巧，和Reranker一起构成RAG检索优化的"三驾马车"。

查询改写的核心方法：

• 大模型改写（最常用）：把口语化、模糊、简短的问题改写成适合检索的查询
• 查询扩展：添加同义词、相关词、上下位词，丰富语义覆盖
• 多查询生成：从多个角度生成3-5个查询，分别检索后合并
• HyDE：先生成假设答案文档，用假设文档检索
• 子问题分解：复杂问题拆成多个简单子问题，分别检索后综合

混合检索的核心要点：

• 向量检索（语义匹配）+ 关键词检索（BM25精确匹配），两者互补
• 结果融合用RRF（倒数排名融合），简单有效，不需要调参
• 实现方式：向量数据库内置（Weaviate、ES 8.x）或双系统并行
• 中小团队推荐用Elasticsearch 8.x，一个系统搞定混合检索

组合拳：查询改写 → 多路检索（向量+BM25）→ 结果融合 → Reranker精排 → 大模型生成。完整pipeline能把召回率从60%+提升到90%+，但延迟和成本也会增加，需要根据场景权衡。

作为AI产品经理，你要理解每种技术的原理、效果、成本、延迟，能根据项目场景选择合适的优化组合，而不是盲目堆技术。记住：先跑通流程，再逐步优化，每一步都做效果评估。

下一章我们会讲知识库运营，这是RAG系统长期效果的保障——技术再好，知识库没人维护，效果也会越来越差。

📝 本章练习（5题）

答案与解析请在 互动学习看板 中作答查看。

📚 AI产品经理实战训练营 课程目录（44 章）

1. 第1章 AI产品经理是做什么的？和传统PM有什么区别？
2. 第2章 2026年AI产品经理就业市场：哪些行业在招？薪资多少？
3. 第3章 零经验转行AI产品经理的3条路径
4. 第4章 AI产品全景图：从聊天机器人到Agent，一文搞懂
5. 第5章 AI产品经理能力模型：你需要掌握哪些技能？
6. 第6章 实战：拆解3个你每天在用的AI产品
7. 第7章 大模型是什么？用大白话讲清楚
8. 第8章 主流大模型对比：GPT-4o、Claude、DeepSeek、豆包、Kimi怎么选？
9. 第9章 Prompt入门：写好提示词的5个原则
10. 第10章 Prompt进阶：System Prompt、COT思维链、Few-shot示例
11. 第11章 结构化输出：让大模型返回JSON、表格、代码
12. 第12章 Prompt优化实战：从垃圾Prompt到高质量Prompt
13. 第13章 大模型的"幻觉"问题：产品经理怎么应对？
14. 第14章 实战：为一个智能客服设计完整Prompt体系
15. 第15章 RAG是什么？为什么企业都在做知识库？
16. 第16章 RAG工作原理：文档→分块→向量→检索→生成
17. 第17章 向量数据库选型：Milvus、Pinecone、Chroma、pgvector怎么选？
18. 第18章 Embedding模型选型：OpenAI、BGE、M3E、GTE对比
19. 第19章 Reranker重排序：让检索结果更精准
20. 第20章 查询改写与混合检索：提升召回率的实战技巧
21. 第21章 知识库运营：文档治理、更新机制、效果监控
22. 第22章 实战：从零搭建一个企业知识库（完整流程）
23. 第23章 Agent是什么？和聊天机器人有什么区别？
24. 第24章 Agent核心能力：感知、规划、工具调用、记忆
25. 第25章 主流Agent框架与协议：Agent Harness、MCP、A2A全解析
26. 第26章 工具调用（Function Calling）原理与实战
27. 第27章 Agent记忆系统：短期记忆、长期记忆、向量记忆
28. 第28章 多Agent协作：多个智能体怎么分工配合？
29. 第29章 Agent评估体系：成功率、成本、延迟怎么监控？
30. 第30章 实战：设计一个制造业生产异常处理Agent
31. 第31章 AI产品需求分析：怎么识别真需求还是伪需求？
32. 第32章 AI产品竞品分析：怎么调研和拆解竞品？
33. 第33章 AI产品PRD撰写：技术可行性、数据需求、评估指标
34. 第34章 AI产品原型设计：对话流、状态机、异常处理
35. 第35章 AI产品数据指标体系：从DAU到模型准确率，全面监控
36. 第36章 AI项目管理：从需求到上线的全流程管控
37. 第37章 实战项目1：从零搭建制造业AI智能质检系统
38. 第38章 实战项目2：从零搭建企业级AI知识库（RAG系统）
39. 第39章 AI产品经理简历优化：让HR一眼看中你
40. 第40章 项目经验包装：把普通项目讲成亮眼案例
41. 第41章 AI产品经理面试常见问题：提前准备，从容应对
42. 第42章 案例分析面试：用结构化思维征服面试官
43. 第43章 薪资谈判：拿到你应得的报酬
44. 第44章 入职前3个月：快速站稳脚跟，建立信任