模型评测为什么一上在线 AB 胜率就开始误判模型升级：从 Interleaving 到 Guardrail Metric 的工程实战
很多团队把模型升级推到线上后，最危险的错觉不是离线分数变高，而是在线AB胜率也赢了。⚠️ 在客服、搜索问答和办公助手里，继续追问率、人工接管率和一次幻觉带来的二次成本，往往比答案是否更讨喜更关键。
在线评测容易误判，是因为它把流量差异、问题难度和风格偏好混成了一个结论。📌 本文只看两个抓手：Interleaving负责削弱样本偏斜，Guardrail Metric负责挡住“表面赢、真实亏”的版本。
[外链图片转存中…(img-H5yg1T6f-1777601776352)]
在线 AB 胜率为什么经常会骗人
很多平台随机分流后统计点赞、停留或人工选择。🧭 这对传统推荐实验够用，对大模型却不稳，因为请求长度、工具链复杂度和用户耐心都在波动。短问答与长任务落到不同桶里，胜率会被流量结构直接带偏。
偏好指标还会天然奖励“更像好答案”的输出。📉 更长、更自信的回答更易拿票，也更可能扩写事实、误调工具和污染上下文。团队若只看win rate，就会把文风优势误判成真实升级。
一组更接近生产的在线实验设计
这次实验选了企业知识助手7天真实流量，覆盖问答、检索增强和工具调用。🧪 基线与候选模型接入同一套RAG和函数调用，只比较模型响应。为降低难度偏斜，团队抽取18%流量做请求级Interleaving，让同一问题双跑后再随机展示收集偏好。
随后把质量指标和护栏指标拆开计算。✅ 前者回答“用户更喜欢谁”，后者盯投诉率、工具重试率和P95时延。任一护栏越阈值，版本即便偏好领先也不能放量。
| 评测方式 | 主要判定依据 | 表面胜率 | 投诉率变化 | 工具重试率 | 放量结论 |
|---|---|---|---|---|---|
| 纯在线 AB | 点赞与主观偏好 | 53.8% | + 11% | + 9% | 容易误放量 |
| Interleaving | 同请求双跑后的成对偏好 | 51.2% | + 4% | + 3% | 能削弱样本偏斜 |
| Interleaving + Guardrail | 成对偏好 + 风险阈值 | 50.9% | - 2% | - 6% | 可进入灰度 |
defcan_ramp(candidate,baseline):ifcandidate["complaint_rate"]>baseline["complaint_rate"]*0.98:returnFalse,"complaint_guardrail"ifcandidate["tool_retry_rate"]>baseline["tool_retry_rate"]*0.97:returnFalse,"tool_retry_guardrail"ifcandidate["latency_p95_ms"]>baseline["latency_p95_ms"]+120:returnFalse,"latency_guardrail"ifcandidate["interleaving_win_rate"]<baseline["interleaving_win_rate"]+0.005:returnFalse,"quality_not_significant"returnTrue,"eligible_for_ramp"这套逻辑看起来保守，却能挡掉很多“回答更讨喜、系统却更脆”的版本。🔧 复盘显示，最初在纯AB中胜出的候选模型，会把检索证据扩写得更漂亮，却让工具链多出一层无效重试。
评测框架真正缺的不是更多分数，而是分层决策
笔者认为，很多线上评测失真，不是因为指标少，而是把“选择指标”和“准入指标”混成一分。🚨 偏好胜率适合排序，护栏指标适合拦截。两者被压成综合分后，质量小涨会把风险平均掉。
更稳的做法，是先用Interleaving把同请求比较做干净，再按意图切片看护栏。📊 知识问答、工单检索和多工具任务应分别观察，因为同一升级可能在短问答更强，却在多步调用里更慢。
未来 3 到 6 个月，在线评测会越来越像发布系统
接下来更有价值的方向，不是继续堆花哨评测分，而是把线上实验做成可审计的发布系统。🧩 每次升级都应留下切片结果、护栏触发原因和回滚依据，让实验结论直接服务灰度、限流和熔断。
一句话总结：在线AB胜率只能回答“用户更偏爱哪种表达”，却回答不了“这个版本是否值得上线”。⭐ 当Interleaving比质量，Guardrail Metric拦风险，模型评测才真正接上生产放量。你们的线上实验，更像在比答案观感，还是在比现网可用性？