RAG 自信地答错：该换模型，还是先修数据？

概念来源： Microsoft Learn 的 RAG 评估器说明。文档区分检索评估和回答质量。以下流程与案例为独立分析，不是产品介绍或真实部署报告。

假设向内部助手询问设备采购流程。回答流畅，还附链接，却指向旧规定。这不一定只是模型幻觉：模型可能忠实总结了错误文档。

一个错答案，可能有多种原因

RAG 通常先检索文档片段，再交给模型。错误可能发生在生成之前：正确文档未入索引、相关片段没找出，或旧版本排名更高。也可能正确文本已到达，但回答超出证据。

我认为质量不是一个总分。应区分找不到证据和不会使用证据。更准确的模型若仍拿到相同错误上下文，也不保证回答能被接受。

有效引用不只是漂亮链接

有链接不证明原文支持主张。审阅者应能找到相关段落，了解日期和适用范围。忠于文本也不等于文本今天仍有效：旧材料可能产生有依据但不合格的答案。

这是实践建议，不是某工具的保证功能。冲突需要内容负责人和组织规则，模型不能悄悄成为政策制定者。

用真实问题构建测试集

1. 收集常见问题，不带机密信息。
2. 与内容负责人明确预期文档和段落。
3. 加入无答案、模糊、过期和受限访问案例。
4. 分别记录检索、引用正确性和回答验收。

以后用同一集合比较变更。如果同时换模型、提示、分块和搜索，就难以知道改善或退化的原因。一次成功演示也不代表员工所有问题。

权限也是质量的一部分

把正确答案泄露给无权用户，不是产品成功。应检查文档权限如何落实，以及禁止内容是否通过暗示或摘要泄露。日志也不能成为无保护的敏感文本仓库；只保留必要标识与元数据，并设置适当访问。

决策问题

什么时候升级模型？

当正确且获授权的证据已到达，模型却无法正确使用或按要求表达，并且受控测试证明有可接受改善时。成本和延迟仍须纳入验收。

自动评估足够吗？

它适合重复比较，但也会出错。边界案例和敏感回答需要内容负责人判断。高分不代表不会犯错。

谁负责文档更新？

必须事先明确。我建议确定负责人、复核日期和淘汰旧版本的流程。“模型自己会发现”不能替代维护。

最终标准是：对获准问题给出被接受、且证据真正支持主张的答案。性能方面可读 CPU 与 GPU 瓶颈分析。

来源核查：2026年11月2日。案例为假设，方法为原创建议，不保证模型或系统准确。