RAG 知识库为什么会答非所问：切分粒度、召回证据与重排检查

RAG 知识库出现“答非所问”时，最常见的根因不是把模型换得不够大，而是正确内容没有以合适的粒度进入候选集，或者候选证据在过滤、重排后被挤掉了。排查时要把问题拆成“切出了什么、召回了什么、最终交给模型什么”三段，而不是只盯着最终回答。

先保留一次完整检索链路：问题、过滤条件、召回片段、相似度、重排分数和最终上下文。只要能确认正确证据在哪一步消失，修复就会从猜参数变成按证据调整。

先把“答非所问”拆成三种故障

同一句错误回答，可能对应完全不同的修复方向。若正确段落根本不在召回结果里，这是召回覆盖问题；若正确段落在候选里但排在很后面，是排序或阈值问题；若正确段落已经进入最终上下文，模型仍引用了别的内容，则要检查上下文冲突、提示词约束和答案生成。

建议先保存一条最小调试记录：

{
  "question": "退款申请提交后多久能到账？",
  "filters": {"product": "标准版", "version": "2026"},
  "retrieved": [{"chunk_id": "refund-03", "score": 0.78}],
  "reranked": [{"chunk_id": "refund-03", "rank": 1}],
  "context_ids": ["refund-03", "refund-04"]
}

这份记录不需要包含用户隐私，但要保留足够的片段编号和分数，让每次调参都能回放。

切分粒度决定证据是否完整

把每段切得过短，定义、限制条件和例外会被拆散；切得过长，又会让一个候选片段包含多个主题，降低相似度并挤占上下文。实际调整时，先以标题层级和自然段为边界，再设置一个长度上限；遇到“条件—动作—结果”连续出现的说明，不要从中间截断。

给每个片段保留可追溯的标题路径

片段正文前可以带上轻量元数据，例如“退款 / 到账时间 / 标准版”。这样既帮助向量表达主题，也方便重排和人工查看。不要把完整网页导航、页脚和重复版权声明一起塞进片段，它们会制造相似但无用的噪声。

用边界问题检验切分是否合理

为同一知识点准备三类问题：直接问法、带条件问法、反向问法。若直接问法能命中，带版本或产品条件的问法命不中，通常是元数据过滤或片段上下文缺失；若三类都命中但回答混用版本，说明片段之间的版本标签还不够明确。

召回阶段先看“答案有没有进候选集”

召回调试应先固定问题和过滤条件，查看 top-k 的所有片段，而不是只看最终 top-1。向量检索适合找语义相近内容，但不能天然理解“只要 2026 年标准版”这类组合条件；这时需要把结构化过滤放在召回前或召回中，并确认过滤字段确实写在每个片段的元数据里。

# 伪代码：先过滤，再扩大候选，最后重排
candidates = vector_search(
    query=question,
    metadata_filter={"product": "标准版", "version": "2026"},
    top_k=20
)
ranked = rerank(question, candidates)[:5]

如果 top-k 从 5 调到 20 后正确答案才出现，不要立即把默认 top-k 永久调大。先检查错误片段为什么占据前排，以及更大的候选是否会把无关内容带进上下文。

重排不是越强越好，而是要解释排序变化

重排模型会综合问题和片段文本重新打分，但它也可能偏爱措辞相似、条件不完整的片段。排查时至少保存向量初排和重排后的顺序，找出“正确片段从第 2 名掉到第 8 名”的具体原因。若片段之间存在版本、权限或产品差异，应在重排输入中保留这些信息，而不是只传一段脱离上下文的正文。

用小评测集避免凭感觉调参

准备 20 到 50 个真实问题，每题标注正确片段编号、可接受的相邻片段和必须排除的片段。每次只改变切分长度、top-k、过滤条件或重排阈值中的一个，记录召回命中率、首条命中率、最终上下文噪声三项指标。

一个简单的检查表可以写成：

命中率 = 含正确片段的问题数 / 评测问题总数
首条命中率 = 正确片段排名为 1 的问题数 / 评测问题总数
噪声率 = 最终上下文中无关片段数 / 最终片段总数

推荐的调整顺序与上线边界

第一步修复文档清洗和元数据，确保标题路径、版本、产品和生效范围没有丢失；第二步调整切分边界，优先解决答案被拆散的问题；第三步再比较 top-k 和过滤策略；最后才引入或更换重排模型。这样可以避免用更复杂的模型掩盖知识库结构问题。

上线前至少保留三类回归：历史问题回归、带条件问题回归、无答案问题回归。无答案问题必须允许系统明确说“知识库中没有找到足够证据”，而不是用相似片段拼出一个看似完整的结论。

常见误区与恢复办法

只增加 top-k，不检查过滤条件

候选更多不代表证据更准确。如果版本过滤没有生效，扩大候选只会让旧版本内容更容易进入上下文。先在日志中打印过滤字段和值，再抽样核对索引中的元数据。

看到模型答错就更换生成模型

正确片段没有进入上下文时，生成模型没有机会回答正确。先检查 context_ids，再决定是否需要调整提示词或模型。

用一两个问题判断优化成功

单题容易被偶然相似度影响。固定评测集并保存每次结果，才能看出命中率提升是否以噪声率上升为代价。

相关问题

为什么向量相似度高，答案仍然不对？

相似度只说明表达接近，不保证版本、权限和条件一致。需要结合元数据过滤和重排后的证据检查。

RAG 是否一定需要重排模型？

小规模且结构清晰的知识库可以先用向量召回验证闭环。候选较多、问题条件复杂或首条命中率不足时，再用评测数据判断是否值得引入重排。

怎样判断应该改切分还是改 top-k？

正确答案不在候选集，优先改清洗、切分和过滤；正确答案在候选集但排序靠后，再比较 top-k 与重排策略。

RAG 的可靠性来自可回放的证据链。把切分、召回、重排和最终上下文分别记录，再用小评测集一次只改一个变量，通常比盲目扩大上下文或更换模型更快找到真正的故障点。