先问业务问题，再选指标
评测不是刷榜：你要先明确应用失败时的代价。客服场景可能更重视可纠错的错误率与转人工率；代码助手可能更重视可执行片段比例、安全拒绝率与引入漏洞的比率；写作辅助则更关注事实性与引用可追溯性。如果你把「平均分」当作唯一目标，团队很容易在离线集上过拟合，却在真实用户场景里翻车。
因此，第一步永远是写清楚：用户成功是什么样？失败是什么样？ 然后把失败拆成可标注的类别，否则评测只是在重复「感觉更好」。
离线评测：高质量小集胜过「大而脏」
公开基准能反映某些能力，但与你的数据分布往往不一致。更稳妥的做法是构建小规模但高质量的领域集：覆盖高频意图、边界问题与已知陷阱，并固定版本与提示模板，保证可复现。
离线集要记录：模型版本、温度、最大 token、检索配置（如有）、以及随机种子策略。否则两个月后你无法判断指标变化来自模型升级还是评测流程漂移。
分层指标：别只用准确率
在真实系统里，「答对」常常不是唯一目标。你可以同时观察：
- 任务完成率：用户是否达成目标（可用人工标注或弱监督）。
- 重试率：用户是否反复改写提示，暗示系统理解失败。
- 编辑距离/返工成本：对写作类任务尤其关键。
- 安全与合规：误拒（伤害体验）与漏拒（伤害风险）往往要分开统计。
如果你只报告一个数，建议选择与业务损失最相关的那个，并在附录里补充其他指标。
在线指标与人工抽检
上线后关注趋势而不是单日波动：
- 负面反馈（点踩、举报、转人工）是否与特定版本或特定流量段相关。
- 延迟与成本：同样的效果，是否以更贵的方式达成。
人工抽检应分层抽样，记录错误类型（事实性、指令遵循、风格、安全、工具调用失败等）。抽检量不必很大，但要稳定持续，否则你只能看到「平均很好」的幻觉。
报告方式：诚实比漂亮更重要
写清楚数据集来源、样本量、模型版本与温度；对不确定结论使用置信区间或定性描述，避免「绝对更好」的表述。若评测存在明显局限（例如样本偏差、标注噪声），应在文中显眼位置说明，并给出未来改进计划。
当指标提升但线上反馈变差时，优先怀疑：指标与用户体验脱节。这时回到第一步，重新定义「成功」。
成本与节奏：评测也要可维护
评测体系最大的敌人是维护成本过高。建议把数据与脚本放在同一仓库，使用固定入口命令生成报告；把「新增 bad case」变成例行流程，而不是项目结束后再补。
结语
好的评测不是证明产品「很强」，而是让团队更快、更便宜地知道错在哪里。选对指标，就是把学习曲线从玄学变成工程。