RAG优化:明明召回了正确文档为什么答案还是错?

有一次我排查一个内部知识库，用户问的是：

Windows 客户端出现 ERR_CONN_RESET_1007，升级到 4.2 之后应该怎么处理？

系统其实召回了正确文档，而且就在前 10 条里。可最终回答仍然引用了 3.8 版本的旧操作，把用户带到了错误页面。

这类问题很容易让人误判。大家第一反应通常是：“是不是 Embedding 不行？”于是换模型、调 Chunk、把 TopK 从 5 改成 20。折腾一圈，结果时好时坏。

真正的问题是：召回到了，不等于排对了；排进前几名，也不等于适合直接塞给大模型。

一、先把 TopK 说清楚

TopK 不是一个神奇的“精度旋钮”。它只是告诉检索器：返回分数最高的 K 个候选片段。

假设检索结果如下：

排名	文档	是否能直接回答
1	网络连接通用排查手册	否，只是主题相关
2	3.8 版客户端 1007 错误处理	否，版本过期
3	代理服务器配置说明	否，只有部分关系
4	4.2 版 Windows 客户端升级说明	是
5	macOS 客户端升级说明	否，平台不符

如果 TopK=3，正确文档直接丢了，这是召回问题。

如果 TopK=10，正确文档虽然进来了，但前面混着大量更“像”问题、却不能回答问题的片段，这是排序问题。

如果把这 10 条全部交给大模型，还会出现第三个问题：旧版本、其他平台和通用说明互相打架，生成模型未必会稳定地挑中正确证据。

所以生产链路通常需要分两步：

候选召回阶段：宁可多捞一些，重点保证 Recall。
精排阶段：认真判断“这个片段能不能回答这个问题”，重点保证 Precision。

TopK 与 Rerank 的分工

一句话记忆：Retriever 负责别漏掉，Reranker 负责别排错。

二、为什么向量相似度高，答案却不一定对

向量检索擅长判断两段文字在说的事情是否相近，但业务真正需要的往往不止“主题相近”。

还是刚才的例子。用户的问题里至少有四个约束：

Windows；
客户端 4.2；
错误码 ERR_CONN_RESET_1007；
需要可执行的处理方法。

一篇“网络连接异常概述”可能在语义上非常接近，却没有操作步骤；一篇 3.8 版本的文档可能逐字包含错误码，却已经失效。单个向量分数很难同时承担语义匹配、精确实体、版本有效性和业务规则这几项工作。

这也是为什么混合检索经常比单纯向量检索更稳：

向量检索负责语义，例如“登录不了”和“身份认证失败”；
BM25 负责精确字符，例如错误码、型号、API 名称；
Metadata Filter 负责硬条件，例如租户、权限、版本、状态；
Reranker 负责综合判断问题与候选片段的真实相关性。

注意，这几个组件不是谁替代谁，而是各自处理自己擅长的部分。

三、Rerank 到底做了什么

常规 Embedding 检索采用“双塔”思路：问题编码一次，文档提前编码，然后快速计算相似度。它的优势是快，适合从几十万甚至上百万个 Chunk 中找候选。

Reranker 通常采用 Cross-Encoder 思路，把“问题 + 候选片段”放在一起读，再给出相关性分数。因为它能同时看到两边的细节，所以更容易判断：

文档是否真的回答了问题，而不只是出现了相同主题；
条件、对象、动作和结论是否对应；
否定、例外和版本限制有没有冲突；
片段是否包含足够完整的证据。

代价也很明确：它要逐条读候选，速度比向量检索慢得多。因此不能拿 Reranker 去扫整个知识库，更合适的用法是：

海量知识库  ↓ 快速召回20～50 个候选  ↓ Rerank3～8 个高质量片段  ↓大模型生成答案

四、先做 Hybrid Search，再做 Rerank

只用一条召回通道，经常会偏科。下面用一个简化案例说明完整做法。

1. 准备两路召回结果

向量检索返回：

1. 网络连接异常通用排查2. Windows 客户端代理设置3. 4.2 版 1007 错误处理

BM25 返回：

1. 3.8 版 ERR_CONN_RESET_1007 处理2. 4.2 版 ERR_CONN_RESET_1007 处理3. 错误码索引

两路结果的原始分数不能直接相加。向量库可能返回余弦相似度，BM25 使用的是另一套相关性尺度。一个常见的融合方式是 RRF（Reciprocal Rank Fusion），它更关心名次，而不是强行比较不同系统的分数。

from collections import defaultdictdef reciprocal_rank_fusion(result_lists, k=60):    scores = defaultdict(float)    documents = {}    for results in result_lists:        for rank, doc in enumerate(results, start=1):            doc_id = doc.metadata["chunk_id"]            scores[doc_id] += 1 / (k + rank)            documents[doc_id] = doc    ranked_ids = sorted(scores, key=scores.get, reverse=True)    return [documents[doc_id] for doc_id in ranked_ids]

这里一定要用稳定的 chunk_id 去重，不要直接拿正文文本当 ID。正文可能因为清洗、换行或版本更新发生变化。

2. 对融合结果做 Rerank

下面使用 sentence-transformers 的 CrossEncoder 演示核心过程。模型名称只是示例，生产环境要用自己的中文评测集选型。

pip install -U sentence-transformers

from sentence_transformers import CrossEncoderreranker = CrossEncoder("BAAI/bge-reranker-v2-m3")def rerank(query, documents, top_n=5):    pairs = [(query, doc.page_content) for doc in documents]    scores = reranker.predict(pairs)    ranked = sorted(        zip(documents, scores),        key=lambda item: float(item[1]),        reverse=True,    )    return [        {            "document": doc,            "rerank_score": float(score),            "original_rank": documents.index(doc) + 1,        }        for doc, score in ranked[:top_n]    ]

调用时不要只保存最终结果。最好把原始排名、融合排名和重排分数一起记下来：

candidates = reciprocal_rank_fusion([dense_docs, bm25_docs])final_docs = rerank(user_query, candidates, top_n=5)for new_rank, item in enumerate(final_docs, start=1):    doc = item["document"]    print({        "new_rank": new_rank,        "old_rank": item["original_rank"],        "score": round(item["rerank_score"], 4),        "chunk_id": doc.metadata["chunk_id"],    })

这样当答案出错时，你能看见正确文档到底是没召回、融合时掉了，还是 Rerank 判断错了。

五、Rerank 之后，别急着把前 5 条全塞进去

重排序解决了名次问题，但上下文组装仍然要做几件事。

去掉重复片段

相邻 Chunk 有 Overlap 时，同一段操作可能占据前三名。表面看 Top 3 都很相关，实际上只有一份信息。可以按 document_id + section_id 限制单个章节的片段数，或者合并相邻 Chunk。

保留来源和版本

最终上下文不要只有正文，至少带上文档 ID、标题、版本和更新时间。生成答案时要求引用这些稳定标识，后面才能追查。

设置最低门槛，但不要迷信统一阈值

Rerank 分数的分布会受到模型、语言、文档类型和问题长度影响。不要在没有评测的情况下照搬“低于 0.5 就丢弃”。更稳妥的做法是按业务分桶看分数分布，再选择阈值。

没有好证据时允许拒答

如果最高分仍然很低，或候选之间结论冲突，系统应该追问条件、提示证据不足或转人工，而不是硬生成一个看起来完整的答案。

六、TopK、候选数和 TopN 怎么调

可以先用下面这组参数起步，但它不是标准答案：

环节	起步范围	目的
向量召回	20～40	保证语义覆盖
BM25 召回	20～40	补充关键词与实体
融合去重后	20～50	控制 Rerank 开销
Rerank 输出	3～8	控制上下文噪声

真正调参时，请沿用前面文章建立的评测集，至少观察：

Recall@K：正确证据有没有进入候选；
MRR或 nDCG@K：正确证据是否排到前面；
Context Precision：最终上下文里有多少真正有用；
答案正确率与忠实度；
P50、P95 延迟；
每次查询的 Rerank 数量和成本。

实验要使用控制变量。例如固定检索器和评测集，只比较：

A：向量 Top5 直接生成B：混合召回 Top30，直接取前 5C：混合召回 Top30，Rerank 后取前 5

如果 C 的排序指标明显提升，但最终答案没有改善，问题可能已经不在检索，而在上下文组织或生成 Prompt。

七、生产环境最常见的五个坑

1. 候选集里没有正确文档，却期待 Rerank 救场

Reranker 只能重新排列已有候选，不能凭空找回漏掉的文档。

2. 对几百条候选逐条精排

效果未必继续提升，延迟和显存却会快速上涨。先通过多路召回、过滤和去重缩小候选集。

3. 把 Rerank 当权限系统

无权查看的文档不应该进入候选集。权限必须在检索前或检索过程中完成过滤，不能指望 Reranker 把敏感内容排到后面。

4. 只看一个成功案例

Rerank 对错误码查询提升很大，不代表对长问题、多跳问题也有效。一定要按查询类型分桶评测。

5. 只记录最终 TopN

没有中间排名，就无法知道优化到底在哪一步生效，也无法复现线上错误。

八、上线前检查清单

向量检索和关键词检索是否各司其职？
融合时是否使用稳定的 Chunk ID 去重？
权限、租户、版本是否在召回前过滤？
是否保存 Rerank 前后的排名变化？
是否限制单篇文档进入上下文的重复片段数？
是否用固定评测集比较 Recall、排序、答案、延迟和成本？
没有可靠证据时，系统是否允许追问或拒答？

总结

把 TopK 调大，只是让候选池变大；加入 Rerank，才是在候选池里认真挑证据。但 Rerank 也有一个前提：正确文档必须先被找回来。