RAG系统上线前怎么评估：准确、引用与新鲜度要一起看

很多知识库项目上线后才发现，模型回答很流畅，却引用了旧制度、混用了不同客户资料，或者根本没有证据。问题通常不在某个向量数据库，而在资料治理、检索评测、版本和权限没有被当成产品的一部分。

1. 先说结论

先建立问题集，每个问题标记标准答案、允许的证据来源和不能回答的情况。问题要覆盖高频任务、边界问题和容易混淆的版本。没有答案的问题也要写进测试集，因为“明确说不知道”比编造更符合企业需求。

2. 问题背景

召回质量不能只看最终回答。系统要记录命中的文档、排名、切片版本、过滤原因和最终引用。这样当答案出错时，团队才能判断是没召回正确资料、召回了旧资料，还是模型在有证据的情况下仍然推理错误。

3. 真正的技术取舍

企业资料有部门、租户、有效期和访问级别。权限过滤必须发生在数据查询层，不能只在提示词里提醒模型不要泄露。对于跨语言内容，还要检查中文和英文版本是否同步更新，避免一侧已经过期而另一侧仍被推荐。

4. 落地方法

新鲜度要成为可计算的字段。政策、价格、产品文档和职位信息都有不同有效期；更新后应标记受影响的切片，并触发相关问题回归测试。没有更新时间的知识库，无法解释为什么今天和下个月给出不同答案。

5. 常见失败

最常见的失败是只用几个问题做 Demo，忽略过期资料、权限越界、无答案拒答和长文档中的证据定位。另一个失败是把召回数量越多越好，结果上下文被相似段落挤满，模型反而更难找到当前有效的证据。

6. FDE判断

FDE认为，RAG不是搜索框加模型，而是一条有版本、权限、评测集和更新政策的知识工作流。真正的质量底线不是回答听起来流畅，而是能找到正确证据，并在证据不足时明确停止。

发布或采购前的检查清单

• 每个问题都要有标准答案或明确的不可回答标记。
• 记录文档版本、召回排名、权限过滤和引用。
• 更新资料后自动触发受影响问题的回归测试。
• 把跨租户泄露和过期资料命中设为红线。

下一步怎么做

从一个部门、一类文档和 20 个高价值问题开始，不要一开始就导入全公司的资料。

本文依据公开资料整理，来源包括：RAGAS documentation。文中“FDE判断”属于编辑分析，不等同于来源原话。