召回命中只是链路第一环RAG 流水线通常包含查询改写、召回、重排、上下文拼接、生成、引用展示。任意一环松动都会让最终答案看起来「有出处」实则对不上。常见假象是向量相似度高但片段讲的是旧版本政策或者召回了正确文档生成时却把结论迁移到另一段。因此上线前要核的是整条引用链路而不只是「有没有搜到东西」。来源分层先分可信度再谈拼接建议把知识源至少分成1. **权威源**现行制度、官方文档、已审定说明书。2. **工作源**内部 wiki、会议纪要、工单结论需标注时效。3. **参考源**外部文章、社区讨论默认不可作唯一依据。生成提示词应要求结论优先绑定权威源工作源只能支撑过程说明参考源不得单独支撑硬承诺。没有分层模型容易把论坛帖和制度条文写进同一句「根据资料」。时间戳与版本号必须进上下文很多幻觉来自过期文档。入库时写入 effective_from / superseded_by / 文档版本召回结果展示时间生成侧对冲突版本显式提示「存在多版本」。若无法判断现行版本正确行为是拒答或请求人工而不是挑一段「读起来完整」的旧文。片段对齐引用要能回跳到原句可核对引用至少满足答案中的关键断言能映射到具体 chunk id。前端可回跳原文而不是只显示文档标题。禁止「综合多处」却不标任何一处。评测时用「断言—引用」抽检随机抽答案人工看引用是否支撑该句。支撑失败计入缺陷而不是算「文风问题」。拒答与降级比硬编更安全当召回为空、相关度低于阈值、或多源冲突时应走降级返回「未找到依据」 已检索范围或转人工。把「必须给个答案」写进产品目标会系统性鼓励编造。审计留痕谁在何时用了哪份知识对客服、合规、内部决策类场景建议记录query、召回列表、选用 chunk、模型版本、最终答案、人工是否改写。事后争议才能复盘而不是只剩聊天窗口截图。局限与替代路线RAG 不能自动保证知识库本身正确垃圾进、垃圾出。也解决不了权限召回了不该看的文档引用再准也是事故。替代路线是「小而准的知识集 强引用校验 人工终审」。对变化快的领域用定期重索引和失效策略比盲目加大 top-k 更有效。对工程团队的启发把 RAG 成功标准从「回答流畅」改成「引用可回跳、版本可解释、冲突可拒答」。链路核对一次通常比追加提示词「请务必准确」更管用。合规自检无导流与行动召唤。含边界、局限与替代路线。CSDN 公开首发专稿。