核心结论
RAG 知识库上线后，效果不会自动越来越好。真正决定长期质量的是运营机制：是否有人收集 Badcase，是否有固定评测集，是否管理文档版本，是否能复盘权限命中和引用来源。没有运营，RAG 很容易从“上线可用”变成“越用越乱”。
Badcase 要按原因分类
用户觉得回答不好，背后原因可能完全不同。可能是资料没有收录，可能是资料写得模糊，可能是检索没有命中，也可能是模型没有遵守回答约束。只有分类记录，才知道应该补文档、调检索、改提示词还是加转人工。
- 无资料：知识库没有相关文档，需要补充。
- 资料过期：旧政策仍被命中，需要下线或标记失效。
- 检索偏差：相关资料存在，但召回不准确，需要调整切分、关键词或向量策略。
- 表达失控：资料命中了，但模型扩展了未授权内容，需要加强回答约束。
- 权限错误：用户看到了不该看的资料，需要检查权限链路。
评测集是质量复盘的基准
如果每次测试的问题都不一样，就很难判断系统是否真的变好了。建议从真实咨询中沉淀一组评测集，覆盖高频问题、边界问题、敏感问题、跨部门问题和多轮追问。
评测集要记录标准答案、可引用来源、是否允许回答、是否需要转人工。每次模型、知识库或检索策略调整后，都用同一套评测题回归。
文档版本要能追踪
企业知识库不是静态资料库。制度会更新，产品会迭代，报价会调整，组织权限也会变化。文档版本管理至少要包含标题、负责人、发布时间、适用范围、失效状态和最近更新原因。
如果一个问题同时命中多个版本，系统应优先使用当前有效版本，并在日志中记录命中文档 ID，方便人工追查。
权限命中要单独复盘
企业 RAG 最容易被忽视的是权限。普通搜索可以返回公开文档，但企业知识库常常涉及部门制度、客户资料、合同、财务或研发内容。检索前和回答前都要校验权限，不能只在前端隐藏入口。
运营角色要明确
RAG 系统至少需要三类角色：业务负责人负责判断答案是否可用；知识管理员负责文档版本；技术团队负责检索、接口和日志。没有角色分工，系统问题就会在“模型不好”和“资料不全”之间来回推。
聚匠的建议
RAG 项目上线后，建议每周复盘 Badcase，每月更新评测集，每次重大资料变更后做回归测试。长期看，运营机制比首版模型选择更影响效果。
