第 23 篇 检索进阶：查询改写、混合检索与图检索

第 23 篇 检索进阶：查询改写、混合检索与图检索

第二季第 7 篇 · 温习：第 05 篇的〈RAG 六环节失败地图〉、第 05 篇的〈切分策略决定检索上限〉、第 05 篇的〈四个指标里上下文召回率最该优先修〉 · 新增：查询端优化与多路融合——诊断瓶颈、查询改写六法、混合检索与重排、图检索适用性、成本收益对照与引入顺序

温习：第一季的三条结论

• 第 05 篇〈RAG 六环节失败地图〉：RAG 管线沿"检索 → 切分 → 嵌入 → 召回 → 重排 → 生成"逐环节都可能失败，定位问题要先沿这条链路二分，不能笼统说"效果不好"。
• 第 05 篇〈切分策略决定检索上限〉：文档怎么切分（按段 / 按句 / 按语义块）直接决定了单段可被召回的内容上限，切分错了再怎么调检索也救不回。
• 第 05 篇〈四个指标里上下文召回率最该优先修〉：召回率、精确率、忠实度、相关性四个指标中，上下文召回率（该召回的有没有召回）最该优先修，它是下游一切质量的地板。

第一季把"RAG 有六环节、切分定上限、召回率最该先修"讲透了，但没讲"当召回率修到瓶颈时，下一步该往哪个方向加力、加什么、代价多大"。本篇结论先行：基础 RAG 的瓶颈常常不在生成，而在"查询"这一侧——用户怎么问、系统怎么改这个问、怎么把多路信号融起来。

一、诊断先行：先判断瓶颈在召回还是在生成

动手优化前，必须先回答一个问题：用户看到的坏答案，根因在召回还是生成？ 这两类问题的修法完全不同：召回问题靠改查询、改切分、加融合；生成问题靠改提示、改重排、加约束。在错误的一侧使劲，只会浪费数周。

最省事的二分法：抽 20–30 条真实 bad case，把系统召回的上下文原文单独拿出来人工看。

• 如果答案其实就在召回的上下文里、只是模型没用好 → 生成侧问题（召回够了，没用上）。
• 如果答案根本没被召回、上下文里压根没有 → 召回侧问题（该改查询和检索通道）。

这条二分要写成固定动作，每次效果下滑先跑一遍，再决定去哪个环节。下面给出可直接照做的诊断决策表。

注意最后一行：相当一部分"效果差"其实是知识库没更新，不是检索算法问题。诊断表能帮你把这类问题挡在门外，避免在无谓的算法调优上耗时间。

二、查询改写：六种手法（本篇重点之一）

很多坏召回的根源，是"用户原话"和"知识库里写这句话的方式"措辞不匹配。查询改写就是在检索前，把用户查询加工成更适合检索的形式。下面六种手法按"从轻到重"排列，越靠后额外调用越多、延迟越高、偏离原意风险越大。

① 指代消解（多轮对话中"它"指什么）
适用条件：多轮场景，用户用"它"“这个”"前者"等代词，但向量检索是无状态的，单看这一句会丢失指代对象。
代价：需结合前文拼出完整查询，通常一次额外大模型调用或基于对话状态机的槽位替换。
风险：消解错了比不消解更糟——把"它"指向了错误的实体，召回全偏。务必在消解后把完整查询显式记录，便于排查。

② 查询扩展（同义词、领域术语、缩写展开）
适用条件：领域黑话多、同义词多、缩写普遍（如"企微"→"企业微信"）。
代价：低，可离线维护一张同义词 / 缩写词典，检索时直接拼接，不必然调用模型。
风险：扩展过头会引入噪声，把不相关的同义表述也召回。建议词典由领域人员维护，而非纯模型生成。

③ 多查询生成（一个问题拆成几个子查询分别检索再合并）
适用条件：原问题复合、需要多个角度的片段才能回答（如"对比 A 和 B 的定价"）。
代价：中高，N 个子查询 = N 次检索 + N 次嵌入，延迟与成本随子查询数线性增加。
风险：子查询拆偏了，召回的片段彼此不互补甚至冲突；合并时还可能重复。建议子查询数控制在 2–4 个，超出要评估收益。

④ 先生成假想答案再检索（HyDE 类做法）
适用条件：用户问题抽象、语义表述与知识库表述差异大，直接检索向量距离远。
代价：中，需先让模型生成一段"假设性答案"，再用这段去检索相似文档。
风险：假想答案可能带错事实，把检索带偏到错误方向；对事实强约束场景要谨慎。它是"用语义相似性换精确度"的取舍，不是万能药。

⑤ 多跳问题分解
适用条件：答案需要沿实体关系跳几步才能得到（如"张三是哪个部门的，该部门最近发了什么通知"）。
代价：高，逐跳检索、逐跳拼接，链路长、失败点多。
风险：任何一跳召回失败，最终答案就断链。单跳召回质量不过硬前，不要急着上多跳。

⑥ 查询路由（判断该走哪条检索路径）
适用条件：知识源异构——既有 FAQ 库、又有文档库、又有结构化表，不同问题该走不同通道。
代价：低中，一次分类调用决定路由。
风险：分类错了直接走错库，零召回。路由的判据要可解释、可回退（路由失败时退回到"全通道检索"）。

六种手法对比汇总如下，便于选型：

改写引入的代价（务必讲清）：所有改写都意味着"系统检索的不再是用户原话"。代价有三——额外调用推高成本、链路变长推高延迟、改写可能偏离用户原意。所以改写不是默认全开，而是"诊断到某类失败后才针对性启用"。这是第六节的引入顺序要落实的原则。

三、混合检索：为什么纯向量检索不够

向量检索（稠密）擅长语义相似，但有系统性盲区：

• 专有名词 / 编号 / 型号：用户搜"WX-2024 规格"，向量更可能召回语义相近的"某型号参数"，而非精确那个编号。
• 代码符号 / 公式 / 标识符：符号序列相似 ≠ 语义相近，向量容易失准。
• 精确匹配需求：法律条款编号、订单号、错误码，要的是"命中即命中"，不是"近似"。

这类场景靠关键词检索（稀疏，如 BM25）更稳——它按词项命中，对字面匹配敏感。但关键词反过来不擅长"换种说法问"。二者互补，于是有了混合检索：向量负责"懂你意思"，关键词负责"认得字面"。

融合策略对比：

调参直觉：先用混合检索把"召回天花板"抬高（解决"该召回的没召回"），再用第四节的重排在候选集上挑"最相关的"。两件事分工不同——混合管"别漏"，重排管"别乱序"。

四、重排的位置与收益

重排（rerank）的本质是：先用便宜的检索粗召回一批候选，再用更贵但更准的模型对这批候选重新排序。位置很关键——它跑在召回之后、生成之前，且只在"候选集"上跑，不碰全库。

收益与成本的结构：

• 粗召回可以很宽（如取 Top 50–100），保证"别漏"；重排在这 50–100 条里精挑 Top 5–10 给生成。因为只处理候选集，重排的算力成本可控，不会随知识库规模线性膨胀。
• 重排模型通常比嵌入模型更"懂相关性判断"，能纠正向量检索的排序偏差（例如把字面不相似但真正回答问题的片段排到前面）。

什么时候值得上：

• 知识库规模中等以上、且向量召回的 Top 结果噪声明显时，重排收益最大。
• 知识库很小（几十到几百条）且查询模式单一时，重排边际收益低，可暂缓。
• 经验判据：若粗召回的 Top 10 里"真正相关"的占比低于某个阈值（示例数据：< 50%），上重排几乎一定划算；若已很高，先去修召回而非加重排。

五、图检索与结构化知识

当知识不只是"文档"，而是"实体和它们之间的关系"时，图检索（知识图谱式）才值得考虑。

什么场景值得：

• 实体关系密集（人、组织、产品、事件相互关联）。
• 多跳查询（A 的上级部门、该部门的预算、预算对应的项目）。
• 需要聚合推理（“统计某类实体的数量”“找出所有满足若干条件的节点”）。

向量检索擅长"找相似片段"，不擅长"沿关系跳"和"计数聚合"。这类需求硬用 RAG，往往要靠第五节的多跳分解硬拼，脆弱且贵。

构建代价（常被低估）：

• 抽取：从非结构化文本里抽实体与关系，需模型或规则，质量参差。
• 消歧：两个"张伟"是不是同一个人？实体对齐是长期工程债。
• 更新维护：知识变了，图要同步更新，否则图比文档更快过时。
• schema 演化：关系类型一旦定错，返工成本高。

适用性判断清单（逐条打分，满足多数才上）：

若多数打"否"，图检索是过度工程——先用好混合检索 + 重排，性价比高得多。

六、成本-收益对照表（本篇核心工具）

把上述所有手段放在一张表里，按"解决哪类失败 / 延迟增量 / 成本增量 / 实施难度 / 何时值得上"横向对比，作为决策依据：

读表要点：延迟和成本增量大多落在"低到中高"区间，只有图检索是"高"且持续——因为它的成本不在推理而在长期维护。所以引入顺序上，图检索永远排最后。

七、引入顺序：顺序错了会浪费大量时间

把优化手段排个优先级，不是"哪个高级先上哪个"，而是"哪个先修性价比最高、且是后面手段的地基"：

判断依据一句话：从"零额外调用"到"多次调用"、从"改配置"到"建工程"，逐级加码；每一级先用最小成本的手段验证收益，成立再加码，不成立不浪费。

可直接套用的引入检查清单：

检索优化引入检查清单（逐级，未通过不进下一级）
──────────────────────────────────────
[ ] 1. 切分与数据已达标？（召回率是否仍低→先回第一季修切分）
[ ] 2. 诊断表跑过，确认是召回侧而非生成侧？
[ ] 3. 已上「查询扩展 + 指代消解」并复测？（最低成本手段先试）
[ ] 4. 仍存在编号/符号/精确失准？→ 上混合检索
[ ] 5. 粗召回 Top10 相关率 < 示例阈值？→ 加重排
[ ] 6. 复合/多跳问题仍答不全且非查询能解？→ 评估多查询/HyDE
[ ] 7. 确有密集实体关系+多跳+聚合需求？→ 走第五节清单，多数"是"才上图检索
纪律：每加一级都复测召回率；任一级无效立即停，不盲目叠加。

一页速查

检索进阶 · 一页速查
─────────────────────────────
诊断先行(必做)：bad case 拿出召回原文人工看
上下文里有答案却没用→生成侧(改提示/重排)
上下文里没有→召回侧(改查询/切分/融合)
查询改写六法(从轻到重)：
①指代消解(多轮代词) ②查询扩展(同义/缩写) ③多查询生成(复合)
④HyDE(先假答案再检) ⑤多跳分解(沿关系跳) ⑥查询路由(选通道)
代价三件套：额外调用↑成本 / 链路↑延迟 / 可能偏离原意 → 按需不开全
混合检索：向量懂意思 + 关键词认字面
融合：加权(易调) | RRF(免归一化) | 重排统一(最准最贵)
重排位置：召回后、生成前，只跑候选集→成本可控
候选相关率<示例阈值时最值得上
图检索：实体关系密集+多跳+聚合才值；代价在抽取/消歧/长期维护
引入顺序(逐级,不通过不进下一级)：
修切分数据 → 改查询(扩展/指代) → 混合+重排 → 最后图检索
纪律：每级都复测召回率；零额外调用优先；图检索永远最后。

常见坑

结语

基础 RAG 的瓶颈常常不在生成，而在查询与融合：先诊断清瓶颈在哪一侧，再用"从零额外调用到多次调用、从改配置到建工程"的逐级顺序加手段——每一级都用最小成本验证收益，不盲目堆叠，检索上限才抬得动、抬得稳。

本文为「AI 产品经理入门与进阶」系列第二季第 7 篇（总第 23 篇）。温习自第 05 篇《RAG 产品设计与调优实战》。数据来源：本篇诊断表、改写六法、融合策略、成本收益对照与引入清单均为可操作框架；延迟与成本增量按量级/区间表述，示例阈值（如候选相关率、子查询数）已标注"示例数据"。具体数值随技术迭代变化，请以最新数据为准。