构建在生产环境中站得住脚的评测体系

基准分数是模型在静态数据集上取得的成绩。评测体系是你用以判断新模型能否上线的依据。两者不是同一回事——把它们当作同一回事，正是大多数生产环境 LLM 团队在每次模型升级时都要手工再验证两周的原因。

下面是几条原则，来自我们构建并见过其在生产环境中成败起伏的若干评测体系。

按子集打分，而非按总分

平均分提高 3%、却在某个失败模式子集上回归 12% 的新模型——在任何无法容忍该失败模式的生产场景中——其实是更差的。总分会把这件事完全掩盖。评测体系应将每个子集的差值作为常规上报项；部署门控的容差应按子集分别配置。若你无法清楚说出子集是什么，那你还没建出评测体系——你建的是基准。

子集应从你真实的失败模式中提炼，而不是借用通用分类法。"幻觉"不是一个有用的子集。"用药路由提示集中编造的药物相互作用"才是。

合成评测案例对探测你已知的失败模式有用。它们会过拟合到恰恰那一处——你撰写时就已经知道的失败模式。一套评测数据全部为合成的体系，会自信地告诉你模型在你早已理解的失败上表现良好。

一套有用的体系要求每次发布评测中必须有可观比例的案例来自上次发布以来已裁定的近期生产日志。这能让评测对真实分布漂移保持诚实——那些合成案例不会预见的用户行为变化与语料内容变化。

单一 LLM 评审存在已知失败模式：评审与被评估系统在弱点上具有相关性。评审本身无法产出的回答，也就无法可靠评估。解法是采用不相关的评审——至少使用来自不同模型家族的两位 LLM 评审，并通过分歧触发的人在回路抽样队列加以补充。

分歧队列同时承担两项职能。它会浮出评测最不自信的案例——通常正是值得人工过目的案例。它也会随时间标示评审漂移——若同类分歧反复出现，评审自身就需要更新。

把报告生成在仪表盘上的体系，其建议是可选的。把体系作为门控接入部署管道——总分回归阻断发布、超出容差的子集回归阻断发布、校准检查失败阻断发布——其建议就是不可选的。可选性的代价，正是大多数团队已经习以为常的两周手工再验证。

部署门控的容差是产品决策，不是工程决策。这是团队对"为了新模型带来的吞吐收益、可以接受每条轴向上多大回归"做出明确表态的地方。这场对话并不舒服。回避这场对话，才是大多数团队没有部署门控的真正原因。

基线评测数据会老化。世界在变；用户行为在迁移；检索语料中的文档在更新。基线两年没动的体系，是在拿一个不再存在的世界去比对。从第一天起就把刷新周期建进体系——不是因为你现在就需要，而是因为等你意识到需要时，你已经把回归发上线了。

基线陈旧的体系会产出自信的错误答案。溯源薄弱的 LLM 也会。结构性问题是同一个。