RAG 答错先别换模型从证据到答案的五项检查一个 RAG 助手回答“退货申请需要在五天内送达”但当前规则其实是“完整申请收到后三个工作日内送达”。错误可能来自过期文档、分块丢失条件也可能来自模型误读。只看最终答案无法定位原因。本文围绕原文的五项检查把排障顺序整理成可执行步骤。文中的退货规则全部是虚构示例用于说明技术方法。1. 先保存一条能解释错误的 Trace至少保留原始问题、实际查询、过滤条件、召回片段 ID 与版本、选入提示词的完整上下文、最终答案和引用映射。{question:退货申请何时必须送达质检,query:退货 申请 质检 截止时间,filters:{status:active},chunk_ids:[returns-2023#04],context_version:1.4,prompt_context:申请须在五个自然日内送达。,answer:五个自然日内送达。,citations:[returns-2023#04]}这是诊断记录示例不是真实系统日志。对外分享时应脱敏并保留关键规则和条件。脱敏记录适合检查逻辑但不一定还能逐字重放生产请求。2. 检查一回答需要的段落召回了吗从权威源文件出发找到真正支持答案的段落再检查解析结果、索引和召回列表。主题相似不等于证据充分多段“退货流程”说明也不能代替具体的截止时间条款。问题若包含产品代码、政策编号或精确术语可以比较关键词检索、向量检索和混合检索。不要只因为语义分数高就认为检索成功。一个快速实验是固定问题、模型和指令手动提供正确段落。如果回答改善优先检查召回和上下文链路。但单次改善只缩小调查范围不足以证明某个组件是唯一根因。3. 检查二段落是否当前有效且适用旧政策可以和问题高度相关却不适用于今天。检查来源、版本、生效时间、适用对象与摄取记录确认当前版本确实完成同步。文件名叫“最新”或标签写着active都不能替代核对。历史资料可继续保留用于追溯但查询当前规则时应采用对应版本策略。时间敏感问题还应明确用户询问的是现在还是过去某个时间点。4. 检查三完整规则真的进入了上下文吗把源文、召回片段和最终prompt_context三者逐一比较。如果“收到完整申请后”被分到另一个块损失发生在分块阶段如果召回片段中有这句话组装后的提示词却没有损失发生在上下文选择或截断阶段。表格标题、单位、条件、例外和脚注尤其容易丢失。结构化分块、携带标题和必要的相邻内容都是可实验的方案但没有适用于所有文档的固定块大小。增加片段数也可能引入噪声应同时测质量与延迟。5. 检查四答案的每条主张是否有支持当前规则完整进入模型后再检查模型是否保留了“工作日”和起算条件。维度关注什么相关性检索内容是否与问题有关证据一致性答案是否由提供的上下文支持正确性是否符合验证过的当前事实引用质量指定来源是否支持对应主张模型准确复述过期政策可以与上下文一致却仍然不符合当前事实。有引用也不自动正确必须确认引用对应的段落支持那个具体数字或条件。自动评测有助于批量筛选但细小限定词和多版本冲突仍值得人工抽查。6. 检查五缺少证据时如何回答空召回并不证明知识库中没有答案。先排除摄取与检索故障再决定是否属于真正的知识覆盖缺口。如果用户缺少某项会影响规则选择的信息可以澄清如果资料根本没有相关政策继续追问用户也不能生成证据应说明无法确认或转人工。提示词可以要求证据不足时停止回答但仍需要评测。只增加拒答用例会让“什么都不答”的系统看起来更安全必须保留可回答的控制问题检查是否过度拒答。7. 把一次修复变成回归集建议包括常规问题、改写提问、精确编号、旧版本陷阱、跨块条件和不可回答问题。每次只改一个可控组件再重新运行完整链路对比新旧 Trace。如果修的是索引或检索只重放旧的prompt_context不够因为那只验证生成阶段。只有确认完整当前证据已经送达模型、模型仍反复遗漏条件时比较其他生成模型才是有证据支持的下一步。