Q30 · 混合检索、重排序和查询改写分别解决什么问题？

用户问客服：“这耳机签收 20 天还能退吗？”政策库里既有已失效的旧版“30 天”，也有当前有效的新版“7 天”。如果系统只搜“退”这个字，可能找不到对应政策；如果只按语义相似度搜，可能找到谈退货的段落，却漏掉“耳机”或生效日期；即使两版都找到了，旧版也可能排在前面。查询改写、混合检索、重排序分别处理这三个不同位置的问题：

用户问题 → 改写成合适的检索问句 → 关键词与语义两路找候选并合并 → 对候选重排 → 把有效证据交给模型回答。

三者可以组合，但不是 RAG 的必选三件套。先看真实错误发生在哪一段，再决定用哪一种。微软 Azure AI Search 的官方说明把混合查询描述为关键词与向量查询并行、再合并结果；语义重排发生在已取得初始结果之后。它的查询改写功能则在查询阶段生成问句变体，属于具体产品的一种实现。Azure AI Search：Hybrid search · Semantic ranking

先认清术语和资料

术语	这里指什么	耳机政策例子
RAG	从外部资料检索证据，再让模型依据证据生成回答	先查政策，再答能否按普通退货申请
Query / 查询	送给搜索系统的检索表达；可与用户原句不同	“耳机 签收 20 天 退货期限”
查询改写	在检索前将原问整理、补全上下文、纠错或拆成多个保留原意的检索问句	把“还能退吗”明确成“耳机退货期限”
关键词检索	依赖文字词项匹配，擅长精确商品名、编号、日期	搜到标题含“耳机”的条款
语义/向量检索	用 embedding 把查询和文段表示为向量，找意思相近的片段	“还能退吗”匹配“退货申请期限”
混合检索	同时使用关键词与向量路线，合并两路候选	两种路线都尝试找到耳机政策
候选片段	召回阶段取回的一批可供进一步筛选的文本	新版 7 天、旧版 30 天、其他商品政策
重排序 / rerank	对已经取回的候选按问题相关性重新排序	使更匹配且有效的新版规则排前面
元数据	附着在片段上的结构化信息，如商品、版本和生效期	category=earphone、effective_from=2026-09-01
top-k	从一次检索路线取前 k 个结果；k 是数量	top-5 取前 5 个候选

下文使用一组虚构的政策：旧版写“耳机签收后 30 天内且未拆封，可提交普通退货申请”，已在 2026-08-31 失效；新版从 2026-09-01 起生效，改成“签收后 7 天内且未拆封”。用户的耳机在 2026-09-06 签收、未拆封，今天是 2026-09-26，已经过了 20 天。正确结论是“这条普通退货政策不覆盖该订单，特殊情形需人工核查”，而不是“30 天内都能退”。这些日期、条款和订单事实只服务于讲解，不代表真实店铺政策。系统应先用业务权限核对订单归属；检索技术本身不会授予访问订单的权限。

查询改写：先把要找的问题说准

用户原句“这耳机签收 20 天还能退吗？”足够让人理解，但搜索系统可能不知道要找的是耳机类别的普通退货期限。改写可以将它整理为“耳机 签收 20 天 普通退货 申请期限”，或者生成两条互补查询：“耳机普通退货签收期限”“耳机退货政策生效日期”。有上下文的多轮对话还可把“这个”还原成上一轮明确提到的商品。目的不是让模型先给出答案，而是减少检索词与文档措辞的差异。Azure AI Search 的查询改写说明举了纠正拼写、改用近义词和生成多个变体的例子；该产品能力在相关文档中标为预览，不等于所有搜索服务都内置同一功能。Azure AI Search：Semantic ranking / query rewrite

改写最怕改掉事实：如果原问题没有说“未拆封”，不能凭空把它塞进查询；如果说“签收 20 天”，不能改成“购买 20 天”或直接加入模型猜出的“30 天政策”。因此应用应保存原问和改写结果，校验商品、时长、否定词、时间限定是否保留。拆出太多近义问句还会增加检索次数、延迟与噪声。Amazon Bedrock 文档也把复杂问题的查询分解列为可选能力：分解是把多方面问题拆成多个子问题，它和简单措辞改写相关，但目的与调用数量未必相同。Amazon Bedrock：Query decomposition

什么时候考虑改写？看日志中是否有大量“用户说法与文档写法不一致”、代词指代不清或复合问题混在一句里的失败。若原句已经是“耳机普通退货政策生效日期”，并且直接检索表现很好，再加改写未必值得。

混合检索：让两条路线都能提供候选

关键词路线会抓住“耳机”“2026-09-01”“退货期限”等精确词；语义路线则可能把“还能退吗”和文档里的“可提交普通退货申请”联系起来。两条路线各自产生一个有顺序的结果列表，再进行去重与合并。Azure AI Search 的混合搜索采用倒数排名融合（RRF）来合并：它主要利用候选在各列表中的名次，而不是直接把不同检索器的原始分数相加。它是一个具体的合并方法，其他系统也可能使用不同方法。Azure AI Search：Hybrid search overview · RRF scoring

在耳机例子中，关键词路线可能准确找到标题含“耳机”的新旧两版；语义路线可能找出正文里写“签收后可申请退货”的段落。合并后，两版都进入候选集合，后续才有机会检查日期并排序。若只看语义相似度，商品型号、订单编号和日期等精确约束可能被忽略；微软官方也指出这些专名和日期往往更适合关键词匹配，混合检索可利用两种方式的互补性。Azure AI Search：Hybrid search overview

混合检索的边界也很明确：两路都没取回新版条款时，合并不会凭空创造新版；若旧版和新版都取回，却没有过滤“已失效”，最终仍可能选错。实际工程中应先用权限、商品类别和生效期等结构化条件过滤候选，再比较关键词、向量、混合三种路线在同一组问题上的效果。混合路线常增加召回与计算开销，结果更多也可能带来噪声，不能看到“混合”两个字就当作质量保证。

重排序：从已有候选里挑更合适的证据

初始召回通常为了别漏证据，会保留多个候选；最终模型的上下文空间有限，必须把更相关的片段放前面。重排器读取用户问句与候选文本，给已有候选重新评分，再选择前几条送给生成模型。Azure AI Search 的语义排序是初始排序之后的一层，它只能对已取得的结果重新评分，不能重新搜索整个知识库，也不能创造原本不在候选中的新版条款。Azure AI Search：Semantic ranking overview

耳机政策的两版内容高度相似，仅凭“与退货问题语义相关”可能都得高分。因此需要让重排阶段看见标题、商品类别、版本和生效日期，或者更稳妥地在它之前按当前日期过滤掉失效旧版。相关性不等于有效性：旧版“30 天”可以非常相关，却已经不能作答。AWS Bedrock 的文档也把 reranker 描述为对取回结果改善相关性的可选模型，而不是事实有效性校验器。Amazon Bedrock：Reranking

若正确新版已经在初始 top-k，但排得太靠后、模型只看到了旧版，才重点试重排；若新版连候选都没进，应先修召回或改写。重排额外耗时、计费，并可能因输入缺少生效日期而把错版本排前，因此要做有无重排的对照评测。

图只讲顺序与职责：左边原问已经包含“签收 20 天”，改写没有添加新事实；中间两个篮子分别表示文字匹配和语义匹配，合到同一堆候选；右边放大镜是在候选里挑新版。图里的“选中 7 天”以版本和生效期已得到验证为前提，不能凭图上的颜色或相似度判断政策有效。

三者的区别，按失败症状选择

症状	优先检查	为什么
用户说“这个”“上面那种”，检索词脱离上下文	查询改写/指代消解	搜索之前就没把对象说清
精确型号、日期搜不到；同义表达也常漏	关键词与语义的召回结果及混合配置	需要让互补路线把正确片段带进候选
正确片段已在候选里，但总排在无关片段后	重排序、候选输入字段	问题是顺序和最终名额，不是是否召回
正确片段完全不在候选里	源文档/索引/过滤/召回	重排器没有可排的正确证据
新旧两版都在候选，旧版排更前	生效期过滤、版本元数据，然后看重排	先解决“可用性”，再优化“相关性”
正确新版已进模型上下文，答案仍用旧版	生成阶段与引用核对	三种检索增强都未必解决模型读错证据

这张表也解释了为什么 Q29 的排障次序要从源文档一路查到答案：三个技术都发生在链路中的特定位置，不能代替整个系统的质量控制。

怎样评测有没有真正变好

先准备一批经人工核对的政策问答，覆盖“耳机/其他商品”“当前版/旧版”“签收天数边界”“简称和同义说法”“多轮代词”“根本没有答案”。每题标出原问、正确政策片段、政策生效期和参考答复。固定相同的知识库版本与测试集，一次只切换一个策略：原始查询与改写、纯关键词/纯向量/混合、有无重排。观察：

• 改写保真度：商品、天数、否定、时间范围是否被保留；不能只看改写后的句子更流畅。
• 召回命中率或 Recall@k：正确片段是否进入初始前 k 个候选。若每题只标了一个标准片段，10 道题仅 6 道在候选里包含它，则这批题的命中比例是 6/10；若一题有多个必需片段，还要按实际找回的比例计算覆盖，不能只凭“找到其中一个”算成功。
• 重排后前列质量：正确且有效的片段是否进最终前几条、旧版是否被排除；对照未重排时的位置。
• 最终答案质量：是否按有效条款答对、是否有证据支撑、引用是否对应，同时记录延迟与成本。

AWS 对 RAG 评估区分只检索和检索后生成，分别提供上下文相关性/覆盖度与答案正确性/忠实度等指标。这能避免“答案碰巧答对”掩盖检索漏证据，也避免“证据已取到”掩盖模型读错。Amazon Bedrock：RAG evaluation metrics

面试时可以这样回答

我会先按位置区分三者：查询改写在搜索前，把用户的口语、代词或复合问题转成保留原意的检索问句；混合检索在召回阶段并用关键词和语义两条路线，增加正确证据进入候选的机会；重排序在候选已经产生后，改善前几条的顺序，不能救回没召到的文档。以耳机政策为例，用户问“签收 20 天还能退吗”，改写成“耳机普通退货签收期限”；关键词抓“耳机”和日期，语义抓“退货时限”，合并后可能同时拿到旧版 30 天和新版 7 天。应用要用生效期过滤旧版，再让重排器把有效条款放前面。上线前分别比较改写保真、初始召回命中、重排后的前列质量、答案正确与引用，以及延迟成本；发现问题落在哪一站，就修那一站。

参考资料

• Azure AI Search：Hybrid search overview 与 RRF scoring —— 关键词、向量并行召回与融合。
• Azure AI Search：Semantic ranking overview —— 语义重排和查询改写的作用及边界。
• Amazon Bedrock：Configure and customize queries —— 查询分解、重排和查询时过滤。
• Amazon Bedrock：RAG evaluation metrics —— 分层评测检索与答案。