RAG 检索结果为什么总带错文档：切分边界、召回阈值与证据核对

客服知识库上线后，最让人困惑的不是“搜不到”，而是搜到了看起来很像、实际却不适用的文档：同一个“退款多久到账”，结果里混进了旧版渠道规则，模型于是给出半对半错的答复。这个问题通常出在检索链路的三个接缝：文本切分把条件拆散了，召回阈值放进了无关片段，最后又没有把答案和证据逐条对回去。

先把错误答案拆成“命中的文档、命中的片段、触发的条件”三项，再分别检查切分边界、召回阈值和证据覆盖率，往往比直接换模型更快找到原因。

先复盘一次“相似但不适用”的召回

把线上请求保存成可重放样本，比盯着最终回答猜原因可靠。建议至少记录 query、doc_id、chunk_id、score、version、effective_from 和 channel。例如：

{
  "query": "企业微信渠道退款多久到账",
  "hits": [
    {"doc_id":"refund-v2","chunk_id":"refund-v2-03","score":0.86,"channel":"企业微信"},
    {"doc_id":"refund-v1","chunk_id":"refund-v1-01","score":0.84,"channel":"网页"}
  ]
}

这组结果的危险点不是第二个分数低，而是它和问题的渠道条件不一致。排障记录可以把文档记为 document、把业务约束记为 condition；先把每条候选标成“适用、冲突、信息不足”，再进入修复，否则调高 topK 只会把更多旧规则送给生成模型。

切分边界要保住业务条件

常见的粗暴做法是按固定字符数截断。退款规则恰好把“适用渠道”放在上一段，把“到账时间”放在下一段，向量化后两段都像答案，却没有一段完整表达条件。

切分时可优先以标题、条款编号和列表项为边界；超过长度再在句号或分号处切开，并给相邻片段保留少量重叠。每个片段同时写入元数据，例如 channel=企业微信、status=active、version=2。检索时先用元数据过滤，再做语义相似度排序。

一个可验证的片段检查

拿同一问题分别检索“完整条款”和“被截断条款”。如果命中片段只有“到账 1—3 个工作日”，却没有渠道和例外条件，就不能把它标成可回答证据。把这类片段送回切分任务，直到一个片段能够独立说明主体、条件和结果。

召回阈值不是越高越准

分数只表示当前索引和模型下的相似程度，不是“事实正确率”。阈值过低会把旧版本和旁支问题带进来；阈值过高又可能漏掉表述不同但确实相关的条款。

更稳妥的排查顺序是固定一组包含正例和干扰项的查询，记录每条候选的分数，再看正负样本是否存在明显间隔。若正例集中在 0.82—0.88、干扰项集中在 0.76—0.81，可以从 0.82 附近做小步测试；若两者大量重叠，优先修元数据和切分，不要用阈值掩盖索引问题。

topK=5 也不是必须值。对于带明确渠道条件的问题，先保留 3 条候选并要求至少 1 条通过条件过滤，通常比无条件保留 10 条更容易核对。

把生成前的证据核对变成硬门槛

检索结果交给模型前，增加一个轻量核对层：检查候选片段是否覆盖问题中的实体、条件和时间范围。实现层可以把这三项分别记成 metadata、ranking、evidence，缺少任一项就标为“信息不足”，要求模型追问或明确说明无法确认，而不是用相似文档补全。

可以把回答拆成结论数组进行审计：

结论 1：企业微信渠道退款通常为 1—3 个工作日
证据：refund-v2-03
条件：channel=企业微信，status=active
状态：covered

回归测试至少覆盖三类样本：同义问法、跨渠道问法、旧版本问法。修复后不只看命中率，还要看“冲突片段进入最终上下文”的比例是否下降，以及每个结论是否仍有可定位证据。

兼容注意：先修数据链，再考虑换模型

如果相同查询在不同模型下都召回同一份旧规则，根因大概率在文档状态、切分或过滤条件；如果候选已经正确，只有生成答案错了，再检查上下文顺序、引用格式和回答约束。把这两类问题分开，才能避免用昂贵的模型升级替代数据治理。

相关问题

为什么向量分数高的文档仍然可能不适用？

因为相似度主要反映词义或语义接近，不自动理解渠道、版本、生效期等业务约束。适用性必须由元数据过滤和证据核对补上。

召回结果应该保留多少条？

没有通用固定值。先用小规模标注样本观察正负分数分布，再结合上下文长度和条件过滤确定；关键是保留可核对的候选，而不是盲目堆数量。

收尾：用可回放样本验收一次修复

把原始问题、命中文档、过滤条件和最终证据一起保存，下一次规则更新时直接重放。只要能回答“为什么命中、为什么排除、结论依据哪一段”，RAG 的错误就从玄学变成了可定位、可回归的工程问题。