RAG 项目面里，很多回答会从向量数据库开始：文档切分，生成 embedding，召回片段，再交给大模型回答。这个流程没错，但如果面试继续问“为什么有引用还会答错”“资料明明召回到了，模型为什么没用对”“用户问的是最新政策，答案却引用了旧版本”，只会背流程就不够了。
RAG 的难点不是让答案看起来像有依据，而是让答案里的关键判断真的能回到证据。引用如果只是页面上的装饰，反而会制造更强的误导：读者看到链接或资料名，以为答案可靠，但实际结论可能来自模型补全、过期片段或不相关段落。
先把错误拆到链路里
RAG 答错通常不是一个点的问题。问题理解可能错，导致检索词和过滤条件偏了；召回可能只找到了相似但不相关的片段；重排可能把真正关键的材料排到后面；上下文组装可能因为长度限制截掉了限定条件；生成阶段可能把多个片段混成一个看似顺滑但并不存在的结论。
所以面试里不要只说“优化提示词”。提示词可以约束模型表达，但它不能替代检索质量、证据排序和上下文治理。一个更专业的回答应该能把错误定位到召回、重排、组装、生成或评测其中一段。
引用要对齐到具体结论
好的引用不是在答案末尾挂几个资料来源，而是让关键结论能对应到具体片段。比如答案说“这个接口需要管理员权限”，证据里就必须出现权限规则或角色说明；答案说“新版本已经废弃某个字段”，证据里就要能看到版本、时间或废弃说明。
如果只能引用到一篇长文标题，而不能说明哪一段支持了这个判断，证据链仍然很弱。工程上可以保留片段编号、文档版本、标题层级和命中原因；产品上可以只展示读者需要看的部分，但后台必须能追溯。
冲突资料比没有资料更危险
企业知识库里经常同时存在旧文档、新公告、FAQ、工单回复和人工总结。它们可能互相冲突。模型如果同时拿到这些片段，未必会自动选择最新、最高权限或最权威的一份。
这时要在检索链路里处理版本和权威性：文档要有更新时间、适用范围和来源等级；重排不只看语义相似度，也要看是否符合用户场景；上下文组装时要尽量避免把冲突资料无说明地塞在一起。如果冲突无法自动判断，答案应该提示存在冲突，而不是强行给一个确定结论。
权限过滤必须早于生成
RAG 还有一个容易被忽略的风险：用户没有权限看的资料，不能先放进上下文再要求模型不要说。只要进入模型输入，就可能以摘要、措辞或暗示的形式泄漏出来。
更稳的设计是检索前或召回后立即做权限过滤，只让当前用户可见的片段进入重排和生成。引用展示也要遵守同样边界。面试里把这一点说出来，会比单纯讨论向量相似度更像真实项目经验。
坏例回流比一次调参更重要
RAG 质量不会靠几次手工试问就稳定。需要把答错的问题沉淀成坏例：哪些是资料缺失，哪些是召回错，哪些是引用不匹配，哪些是权限边界，哪些是模型在资料不足时仍然硬答。
评测集也不能只放有答案的问题，还要放无答案、资料冲突、权限受限、版本变化、相似问题干扰这几类样本。每次改切分、embedding 模型、重排策略或提示词，都要看坏例是否减少，而不是只看几个成功样例是否更漂亮。
面试里可以这样收束
如果被问到 RAG 项目，我会把答案可信度拆成三层：第一层是资料能不能被正确找回，第二层是能不能把真正支持结论的证据放进上下文，第三层是生成时能不能按证据回答并在资料不足时拒答。上线后还要记录问题、召回片段、最终引用和用户反馈，用坏例反推检索和证据链路。
这样讲的好处是边界清楚。你不是把 RAG 说成“向量库加大模型”，而是在说明一个可运营、可排查、可审计的知识问答系统。对企业级 AI 应用来说，答案流畅只是表面，证据链闭合才是可信度的底层。