企业RAG评测集该由谁来长期维护?

企业 RAG 评测集最怕“有人负责过”，却没人真正长期维护。项目上线时，模型团队往往会整理一批问题，业务团队也会帮忙标注答案；过一段时间，制度变了、流程更新了、用户问法变了，评测集却还停在原地。此时它测到的不是系统现状，而是过去的记忆。

真正适合长期维护的，不应是某一个部门，而是一套有明确分工的机制。业务部门最适合负责判断“什么答案才算正确”，因为它了解制度、流程和适用边界；知识库或资料管理人员负责确认文档是否有效、是否存在版本冲突；AI 或工程团队负责分析检索、引用和生成环节；权限相关人员则要确认不同角色能看到什么内容。项目负责人可以统筹，但不应替所有人拍板。

其中，业务方应当是评测标准的最终责任方，而不是只在上线前提供一批标准答案。企业内部问答涉及流程和规定，少一个条件就可能改变实际含义。评测样本最好保留问题来源、期望命中的资料、关键事实、有效时间、用户角色及可访问范围。这样系统答错时，才知道是资料没找到、答案没理解，还是权限边界出了问题。

维护评测集的入口，也不该只来自人工想象。客服记录、内部咨询、搜索日志、工单和试运行期间的真实提问，都可以不断补充新样本。尤其是那些曾经失败的问题，应进入回归检查，而不是修好一次就删除。标准问法之外，还要保留简称、口语、错别字和多条件提问，否则评测结果很容易显得漂亮，实际使用却不稳定。

更重要的是，评测集维护应当触发于变化：资料更新、流程调整、检索策略改变、回答约束变化，或者出现新的权限风险时，都需要重新检查相关样本。每轮复盘也不要只看一个总分，而要观察失败集中在哪一层。

所以，企业 RAG 评测集的长期维护者，应该是业务主责、技术共建、资料和权限管理共同参与的持续机制。问题不在于谁“拥有”这份表，而在于谁能确保每条样本始终代表真实业务风险。