RAG 系统效果不稳，问题可能根本不在模型

用户问“海外差旅能否报销出租车”，系统回答“可以”，但公司政策只允许机场到酒店且需要夜间到达证明。更换更大的生成模型也许会让表述更自然，却不会让缺失的限制条件自动进入上下文。RAG 的错误通常发生在一条链上，模型只是最后一环。

有效诊断必须把问题拆开：知识库里有没有正确证据；查询是否能召回；排序是否把证据放到前面；上下文是否保留关键结构；生成是否忠于证据；权限是否允许用户看到这些内容。把所有失败都叫“幻觉”，会让团队在错误的环节反复调参。

RAG 的承诺与实际边界

最初的 RAG 论文把参数化生成模型与可检索的非参数记忆结合，以改善知识密集任务并提供更新知识的路径。它证明了检索增强的价值，但没有保证任意企业文档、任意切分和任意查询都能得到可靠答案。

企业系统还增加了版本、权限、表格、扫描件和跨文档规则。真正的产品不是“向量库加大模型”，而是一条从内容治理到答案验证的证据管道。

第一层：先判断问题是否可回答

在调检索之前，从评测问题中随机抽样，由业务人员确认知识库是否包含足够、有效且可访问的证据。若政策只写了原则，没有定义例外，系统不应被要求给出确定答案；正确输出应是说明缺口并指向负责人。

文档需要稳定标识、版本、生效时间、所有者和权限标签。重复版本会让互相冲突的片段同时进入结果；缺失标题和层级会让“适用范围”与具体条款被拆开；扫描错误会破坏关键词和数字。文档治理决定了可达到的上限。

评测问题也要标记可回答性和时间。政策更新前正确的答案，更新后可能变成错误；若只保留答案文本、不保留所依据版本，回归结果会混乱。对时效性强的知识，应测试索引从发布到可检索的延迟。

第二层：分别测召回和排序

召回测试回答“正确片段是否出现在候选集合”，常用 Recall@k；排序测试回答“正确片段是否足够靠前”，可用 MRR 或 nDCG。先保证候选集中有证据，再优化重排。若正确片段从未被召回，调生成提示没有意义。

BEIR 基准展示了检索方法在不同数据集上的泛化差异，提醒团队不要把一个公开数据集上的优势当作普遍规律。企业应使用自己的查询、文档和相关性标注，对关键词、稠密检索和混合检索进行相同条件比较。

查询改写也要可观察。用户口语“打车能报吗”可能需要补充组织术语“市内交通/出租车/差旅报销”，但改写不能凭空加入用户未提供的地区或职级。保存原查询、改写查询和最终命中文档，才能判断问题出在哪里。

层级	关键问题	建议指标	常见修复
文档	答案和限制条件是否真实存在	可回答率、过期/重复率	版本治理、OCR、结构补全
召回	正确证据是否进入候选集	Recall@k	混合检索、元数据过滤、查询改写
排序	关键片段是否排在前列	MRR、nDCG	重排器、难负样本
上下文	条款与适用范围是否一起保留	证据覆盖率、冲突率	按结构切分、邻段扩展、去重
生成	回答是否只依据证据	忠实度、引用正确率、拒答准确率	结构化引用、冲突处理、答案约束
权限	用户是否只看到有权访问的内容	越权测试通过率	检索前过滤、身份透传、审计

指标应按业务风险设阈值；没有一种统一分数能替代分层证据。

第三层：切分要保留语义关系

固定长度切分实现简单，却可能把标题、适用对象、例外和脚注拆散。政策、合同和技术手册更适合先按章节、条款或表格结构切分，再根据上下文窗口决定是否附带父标题和相邻段。

片段过小会丢上下文，过大会稀释相似度并占用生成窗口。不要只调一个全站通用长度；按文档类型设置策略，并用失败样本验证。表格需要保留行列标题，图片和扫描件需要可追溯到原页。

多跳问题还可能需要组合不同文档。例如报销资格来自员工手册，金额上限来自地区附录。系统应记录组合了哪些证据，并测试文档间冲突。简单扩大 top-k 会增加噪声和成本，不一定提高正确率。

第四层：生成要能处理不足和冲突

提示词应要求答案区分事实、推断和未知，引用具体来源，并在证据不足或冲突时拒绝给出确定结论。引用不是在句末放一个链接：链接指向的片段必须真正支持对应陈述，用户还应能看到文档版本和生效时间。

RAGAS 论文提出无完整人工参考答案时评估上下文相关性和回答忠实度的方法。模型评分可以提高覆盖率，但关键场景仍需要人员抽查，因为评审模型也可能偏好流畅但不严谨的回答。

答案界面要让验证成本足够低。引用应定位到具体段落或页码，高亮支撑内容，并展示标题、版本和生效时间。若用户需要打开五份长文档才能核实一句话，系统虽然“带引用”，却没有真正降低复核成本。

用一条政策问答构造端到端测试

对“海外差旅出租车报销”准备三类问题：能直接回答的正常问法、缺少地区或职级的模糊问法、知识库没有规定的边界问法。为每条标注必需证据、允许结论、必须追问的信息和禁止泄露的文档。

测试结果按失败层归因。如果正确条款未进入前 20 个候选，是召回问题；候选存在但未进前 5，是排序问题；上下文完整但回答忽略夜间条件，是生成忠实度问题；低权限用户命中管理层政策，则是必须阻断发布的权限问题。

持续评测比上线前的演示更重要

知识库每天变化，索引、嵌入模型、重排器和生成模型也会升级。每次变更都要重跑固定回归集，并记录各层指标，而不是只比较最终回答总分。生产中的低评价、人工纠正和无结果查询应进入待标注队列，形成新的困难样本。

监控至少包括索引延迟、无结果率、来源分布、引用点击、拒答率、人工推翻率和单位成功查询成本。异常集中在某个文档所有者或内容类型时，修文档可能比换模型更有效。

延迟与成本也应分层记录：检索、重排和生成分别耗时多少，缓存命中是否牺牲了新鲜度。优化端到端速度时保留质量门槛，避免通过减少候选证据换来更快但更不可靠的回答。

什么时候才该更换模型

只有当正确、完整、获授权的证据已经进入上下文，而生成仍持续出现忠实度、格式或推理错误时，才有充分理由比较生成模型。即使更换，也要在同一检索结果和冻结测试集上运行，避免同时改多个变量。

RAG 的可靠性来自完整、可观察且可复跑的证据链。能明确说出失败发生在哪一层、由哪项指标和样本证明、修复后哪组回归通过，并能在版本变化后再次验证，团队才拥有一个可改进的系统；只能说“模型今天不太稳定”，说明诊断基础还没有建立。