AI离线评估实践笔记

我们吃过几个亏：评估集用去年的数据、线上跑今年的分布；为了好算指标只挑"标准"场景；标注标准没拉齐，同一条样本两个人标出不同结果。指标看着漂亮，上线照样翻车。

为什么要离线评估

最直接的动机是：不敢直接上线上测。

在线评估有成本，而且有些问题一旦暴露就晚了。比如模型在某个长尾场景下完全崩了，用户投诉上来才发现，那就太迟了。

但离线评估也有边界：它只能告诉你"模型在已知场景下表现如何"，替代不了真实用户的反馈。所以我们的定位很清楚：

• 离线评估：做准入判断，筛掉明显有问题的版本，在可控范围内尽可能早发现问题
• 在线评估：做最终验证，看真实用户行为和业务指标

离线评估当不了在线评估的替身，它的位置在上线前：先把明显有问题的版本筛掉。定位搞反了，就容易变成"只信指标不信用户"。

我们要评估什么

不同的模型和服务，评估重点完全不同。

比如我们做的是文本生成类模型，得看一组指标，单盯一个数很容易误判：

• 基础指标：比如 BLEU、ROUGE 这类传统 NLP 指标，用来快速判断模型"有没有把话说对"
• 任务指标：比如准确率、召回率、F1，看模型在具体任务上的表现
• 业务指标：比如回答可读性、相关性、实用性，这些和真实体验更接近
• 稳定性指标：比如对输入噪声的容忍度、极端情况下的表现

这几个指标有先后顺序。基础指标（BLEU、ROUGE）没过，后面不用聊；基础过了再看任务指标；任务也过了，才轮到可读性、稳定性这些更贴近体验的维度。基础还差一截就去争论"用户体验好不好"，基本是在空转。

评估流程怎么搭

我们的评估流程大概是这个样子：

看起来简单，但每个环节都有坑。

准备数据集

数据集质量决定了评估的可信度。我们吃过几个亏：

• 数据不够新：评估时用去年的数据，但模型在线上跑的是今年的数据分布，结果上线后效果掉一大截
• 样本分布偏差：为了好算指标，只挑"标准"场景，结果模型在长尾场景下完全不 work
• 标注质量波动：标注标准没拉齐，同一个问题两个人标的结果不一样，指标自然就乱

后来我们定了几个硬性要求：

1. 数据集必须有明确的版本和采样时间
2. 样本要覆盖主要业务场景，不能只挑好做的
3. 标注前必须先对齐标准，并做一次 double check
4. 数据集本身要定期更新，不能一套数据用一年

配置评估指标

指标配置不是越多越好。刚开始我们一口气列了二十几个指标，结果每次评估完，大家对着一大堆数字反而不知道该看哪个。

后来我们收敛成几个核心指标，每个指标都回答一个明确问题：

每个指标都有自己的阈值：低于这个值直接不用谈，高于这个值才继续往下看。这样可以快速筛掉明显不合格的版本。

运行批量推理

批量推理本身不复杂，但有几个细节要注意：

• 推理环境要一致：评估时用的模型、配置、版本要和上线时完全一样，否则评估结果没参考价值
• 批次大小要调好：批次太大可能显存不够，批次太小又跑得慢，需要根据实际机器调
• 异常处理要周全：比如输入格式不对、模型报错这些情况，要有 fallback，不能让一个样本把整个评估流程卡死

我们把这些都固化成脚本，每次评估前先检查环境，再跑推理，最后把结果存下来。这样即使中途出问题，也能恢复。

计算指标结果

指标计算本身比较直接，但有两个坑容易被忽略：

• 指标版本要固定：很多指标库更新很快，不同版本算出来的结果可能不一样，所以必须指定版本
• 边界情况要处理：比如模型输出空字符串、输出格式异常，这些情况要特殊处理，不能直接算指标

我们把这些都封装成统一的计算接口，评估时只调接口，不用管细节。这样指标更新时只改接口实现，不影响评估流程。

踩过的坑

上面说的都是"应该怎么做"。真踩坑时才知道，平均数会骗人、指标和体验会脱节、数据集本身可能带 bias。

坑一：只看平均数

刚开始我们只看平均指标，比如平均 BLEU 提升了多少。结果有一次平均 BLEU 提升了 10%，但上线后发现用户投诉反而多了。

后来我们拆开看，发现是模型在常见场景下确实提升了，但在某些长尾场景下变得更差。这些场景在数据集里占比小，所以拉低了平均，但用户偏偏就碰上了这些场景。

从那以后我们坚持两件事：

1. 不只看平均，还要看分布，尤其是尾部
2. 做错误分析，把最差的几个样本拿出来人工看一遍

坑二：指标和体验脱节

有段时间我们发现模型 BLEU、ROUGE 都很高，但用户反馈说"说的都对，就是不好用"。

后来才发现，这些指标关注的是"有没有把话说对"，但用户更在意"说的有没有用"。比如用户问"怎么办"，模型准确复述了相关条款，但没给出具体建议，指标很高但体验很差。

所以我们后来补了业务指标，比如"是否给出可操作建议"、“是否解决用户问题"这些更贴近体验的维度。

坑三：数据集本身有 bias

有一次我们发现模型在某个数据集上表现特别好，但上线后效果一般。

后来才发现这个数据集本身就是"挑出来的”，只包含了那些模型本来就擅长的场景。用这种数据集做评估，结果自然很漂亮，但没意义。

所以现在我们特别注意：数据集要真实反映线上分布，不能只挑好做的。如果线上某个场景占比 10%，那数据集里也应该是 10%。

结果和收获

流程搭完，体感变化最明显的是开会时间少了。以前评估完经常吵：这个版本好、那个版本好，各执一词，要么拍脑袋要么拖。现在有阈值，合不合格先看数，争论集中在"为什么某个桶掉了"，而不是"我觉得"。

问题定位也前移了。以前上线后从用户投诉倒查原因，现在离线阶段就能把长尾桶、空输出、格式异常这类问题揪出来。

离线评估当然盖不住所有坑——真实用户的反馈、业务指标的波动，还是得在线看。但它能把一批"本可以提前发现"的问题挡在门外，这点对我们已经够用。

版权声明: 本文首发于 指尖魔法屋-AI离线评估实践笔记（https://blog.thinkmoon.cn/post/268-ai-offline-evaluation-metrics-analysis-practice/） 转载或引用必须申明原指尖魔法屋来源及源地址！