大模型评测不能只看榜单：企业如何建立任务级基线

公开榜单适合帮助团队建立方向感，却不能代替自己的任务评测。企业真正关心的是：模型能否按规定格式输出，能否引用正确资料，遇到不确定问题会不会拒答，失败时是否容易被人工接管，以及每个成功任务需要多少时间和成本。

1. 先说结论

先把“好答案”写成验收标准。客服摘要可能要求不漏掉退款条件，代码修改可能要求测试通过，企业问答可能要求每个关键结论都有来源。没有验收标准，评测就会退化成几个人凭感觉打分，模型之间的差异也无法解释。

2. 问题背景

任务集应该覆盖正常样本、边界样本和失败样本，并保留输入来源、期望输出、允许的替代答案和不能回答的情况。样本不必一开始就很多，但必须来自真实流程，不能只挑最容易让模型表现好的问题。还要定期加入近期出现的错误，避免测试集过时。

3. 真正的技术取舍

单一总分会掩盖风险。建议至少拆成事实准确、指令遵循、引用支持、结构化输出、拒答质量、延迟和成本几个维度。对于企业来说，低概率但高影响的错误应该单独设置红线，不能被大量简单问题的高分平均掉。

4. 落地方法

模型比较时要固定提示词、上下文、工具、温度、输出格式和重试规则，否则比较的不是模型而是整套配置。更公平的方式是先固定工作流，再替换模型；随后再比较不同路由策略。最终结果应该报告“每个成功任务的成本”和“需要人工修改的比例”。

5. 常见失败

常见失败包括只测第一轮回答、不测试长上下文、忽略引用质量和把人工修订隐藏起来。还有团队在模型升级后继续沿用旧基线，直到线上投诉才发现行为已经变化。评测集应该像代码测试一样进入发布流程，而不是一次性 PPT。

6. FDE判断

FDE认为，榜单是选题工具，不是采购决策。真正可持续的模型数据库应该保存任务表现、版本、成本、延迟、失败案例和适用边界。这样以后换模型时，团队比较的是业务结果，而不是被一条新的宣传分数牵着走。

发布或采购前的检查清单

• 先写验收标准，再选择测试集。
• 固定模型外的变量，保证比较公平。
• 单独设置高风险错误红线。
• 把人工修改率和每个成功任务成本纳入评测。

下一步怎么做

先为一个真实流程建立 20–50 个样本的基线，再扩展到整个模型库。

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