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

先说结论：RAG质量的底线是能找到正确证据，并在没有证据时明确说不知道。

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

一、为什么这个问题现在值得关注

企业资料具有版本、部门、租户和有效期。相同关键词可能命中多个版本，最相关的段落也不一定是当前有效的段落。RAG必须把相关性、新鲜度、来源可信度和访问权限一起考虑。

二、把能力放进真实工作流

先建立问题集，每个问题标记标准答案、允许的证据来源和不能回答的情况。检索阶段记录召回文档、排名和过滤原因；生成阶段要求逐条引用；权限过滤放在数据查询层，而不是只提醒模型“不要泄露”。

不要只看演示中的“成功回答”。真实系统还要记录输入来源、上下文版本、工具调用、人工修改、失败原因和最终结果。只有把这些信息连起来，才能知道效果变好是因为模型更强，还是因为流程和数据更合理。

三、上线前的质量与安全检查

至少测试召回率、引用支持率、过期资料命中率、无答案时的拒答率和跨租户泄露率。资料更新后要自动触发受影响问题的回归测试，低于门槛的知识库不能直接进入自动发布流程。

涉及客户资料、账号权限、外部发布、付款、删除和合规判断时，必须把读取、起草、提交拆成不同步骤。模型可以提出建议，但服务器端仍然要做权限校验、参数校验、重复执行保护和审计记录。

四、给团队的落地建议

小团队可以从一个部门和一类文档开始，手工维护高价值问题集。先让 Agent 只做带引用的回答，再逐步开放草稿生成；把“没有足够证据”设计成合格结果，而不是失败。

先用一组真实但脱敏的样本建立基线，再比较准确率、引用完整度、人工修改比例、延迟、失败恢复率和单次成功成本。低分结果不要直接发布，应当回到资料、提示词、模型路由和流程边界逐项排查。

五、SEO与读者价值

一篇有长期价值的内容，不应该只复述发布消息，而要回答读者真正会搜索的问题：它解决什么问题、适合谁、怎样评估、有什么限制、下一步如何开始。正文使用清晰的 H2/H3 层级，标题包含主关键词，摘要说明读者收益，重要结论配有来源，相关页面通过内链互相连接。

总结

RAG不是搜索框加模型，而是一条有资料版本、权限、评估集和更新机制的知识工作流。

本文为 FDE 基于公开资料和 AI 产品实践完成的原创双语分析，重点区分公开事实与编辑判断，供学习和产品决策参考。