离线评测、在线评测、A/B，什么时候该用哪一种
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-31 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
很多团队一提到“评测”，脑子里其实混着三件完全不同的事：
- 用历史样本离线跑分
- 在真实流量里观察效果
- 把两个版本同时放给用户做 A/B
它们都叫评测，但解决的问题并不一样。
如果边界没分清，团队就很容易出现两种典型混乱：
- 明明还没离线证明安全，就急着上 A/B
- 明明用户体验已经变了，还只拿离线分数说话
所以我现在会先把这三种方法当成不同阶段的不同工具，而不是互相替代的同一种东西。
三种方法各自回答什么问题
离线评测：这个版本在已知样本上有没有更好
离线评测最适合回答的问题是：
- Prompt v4 比 v3 好吗
- 新模型在高风险样本上有没有退步
- 新路由策略会不会让拒答率异常
它的优势是：
- 便宜
- 可复现
- 能快速比较多个候选版本
但它的限制也很明显：
- 只能看你已经收进来的样本
- 很难反映真实用户行为变化
- 对延迟、交互路径、转化影响感知有限
在线评测：系统在真实流量里有没有稳定工作
在线评测更像线上观察与对照，常见形式包括：
- shadow mode
- 小流量灰度
- 线上人工抽检
- 真实请求回放
它最适合回答：
- 真流量分布下，错误是不是变了
- 延迟、超时、回退比例有没有异常
- 某些离线没覆盖到的边缘输入是不是开始暴露
也就是说，在线评测更偏“系统稳定性与真实使用反馈”，不只是“回答文本好不好”。
A/B：这个变化是否真的改善了用户结果
A/B 最适合回答的是最终业务问题：
- 用户是否更愿意继续使用
- 工单是否更快关闭
- 人工介入率是否下降
- 转化是否上升
它不是为了帮你 debug 质量，而是为了验证版本变化有没有真正改变业务结果。
我一般按这个顺序走
如果是一个比较完整的 AI 功能改版，我通常会按下面的顺序推进：
- 先做离线评测
- 通过后进入线上小流量观察
- 确认线上稳定后，再决定要不要做 A/B
这个顺序的逻辑很简单：
- 离线评测先过滤明显不合格版本
- 在线评测先确认真实运行没出新问题
- A/B 最后才承担业务决策验证
也就是说，A/B 不是第一道门，而是最后一道门。
什么情况下不该直接上 A/B
我现在很少支持“先放线上做 A/B 看看”。
只要出现下面几种情况，我都会先挡一下：
1. 高风险输出还没离线验证
例如医疗、金融、审核、客服路由这类场景，不能拿真实用户去帮你筛掉明显错误版本。
2. 版本差异还没搞清是质量问题还是系统问题
如果你连 Prompt、路由、模型、缓存、工具调用哪一层变了都没分清，上 A/B 只会让结果解释更难。
3. 观测能力还不够
没有流量标记、没有实验分组、没有关键指标埋点，A/B 跑了也只是热闹。
一个容易被误解的点：在线评测不等于 A/B
很多团队把“线上看指标”直接叫 A/B，其实不太准确。
例如你把新版本放到 5% 灰度流量里观察：
- 超时率
- 回退率
- 人工纠正率
- 用户投诉
这更像在线评测或 canary，而不是严格意义上的 A/B。
因为它重点是“先确认不会出事故”，不一定是在做随机分流下的业务效果对比。
三种方法适合的主要指标也不一样
离线评测常看
- 准确率 / 召回率
- rubric 分数
- 高风险样本通过率
- 结构化字段正确率
在线评测常看
- 超时率
- 回退比例
- 失败类型分布
- 人工复核通过率
- 用户真实输入覆盖情况
A/B 常看
- 留存
- 点击/转化
- 任务完成率
- 工单关闭时长
- 单次成功成本
如果你拿错指标，这三种方法很容易被误用。
我的一个现实判断
离线评测更像质量闸口，在线评测更像运行闸口，A/B 更像业务闸口。
这三道闸口都重要，但顺序不能乱。
顺序一乱，团队就会拿最贵、最慢、最危险的方式，去回答本来可以更早、更便宜解决的问题。
总结
离线评测、在线评测、A/B，什么时候该用哪一种？我现在的答案是：
- 先用离线评测淘汰明显不行的版本
- 再用在线评测确认真实系统是否稳定
- 最后用 A/B 验证业务指标是否真的改善
它们不是竞争关系，而是接力关系。把顺序排对了，评测才会真正成为产品迭代的加速器，而不是一团混在一起的“上线看看”。