把评估跑进 CI：一次模型升级引发的翻车与修复

上周我们做了件很常规的事：把本地推理网关后面挂载的主模型从 32B 换成 70B，推理框架小版本也顺手升了一个号。按惯例，我们只跑了"冒烟用例"——三条典型问答，答案看起来都对，就合上了 PR，把网关切到了生产。

四十分钟后，工单进来了：三个用户的批量翻译任务，输出格式全部错乱。

复盘的时候我们翻出当年的验证记录，发现"冒烟"测的恰好是模型最稳的领域：知识问答。而真正出问题的批量翻译，用的是另一套提示词模板，还要求严格的 JSON 输出。更大的 70B 参数对长指令里的格式约束更"较真"了——它开始把解释性前缀也塞进 JSON 字段里，下游解析器直接抛错，任务整批失败。

问题不在模型变笨了，而在我们的评估集里根本没有这类 case。

这次之后我们立了三条规矩，成本都不高，但把同类问题挡在了上线前：

**第一，评估集按"提示词模板"而不是按"功能模块"组织。** 我们线上的调用其实是 11 套模板：翻译、抽取、摘要、改写……每套模板单独挂一组评估用例，至少 20 条真实脱敏样本。换模型或改推理参数时，全量 11 套都要跑，任何一套通过率掉 2 个百分点以上就阻断发布。这一点写进了 CI 的硬性门禁，不是"建议"。

**第二，格式类断言和语义类断言分开打分。** JSON 输出先过 schema 校验，通过才进语义评分。这样做的好处是翻车时定位极快：schema 挂了说明是格式问题，跟模型智商无关，直接查提示词和解析器；schema 过了但语义分掉了，才轮到怀疑模型本身。上次那种"答案看着挺对但批量任务全挂"的模糊地带，基本不会再出现。

**第三，给评估脚本留了"只读生产流量采样"的开关。** 我们把线上脱敏后的输入样例（不碰输出，避免标注成本）每周自动落一份到评估仓库，作为下一轮 case 的来源。模型对什么输入过敏，生产流量最清楚。

**第四，模型切换不再一刀切，走影子流量。** 新模型先在网关后挂成影子节点，接 5% 的真实流量，只记录不返回。影子侧的输出和主节点逐条比对，格式类字段严格 diff，语义类字段算相似度。影子期至少跑满 48 小时，覆盖一个完整的业务高峰谷，任何一类字段的劣化超过阈值就自动回滚影子节点并告警。这次 70B 走的就是这套流程——影子期第二天早上就抓到了翻译模板的 JSON 污染，是告警拉了我们一把，不是用户工单。

有人可能觉得 11 套模板 × 20 条 × 全量跑，成本不低。实际算下来，本地 70B 跑一轮评估约 18 分钟，机器是现成的，没有额外开销。相比之下，一次生产事故的排查加回滚，上次花了三个小时，还搭上了用户信任。

最扎心的一条经验：我们曾经以为"答案正确"就等于"系统正确"。对 LLM 流水线来说，答案只是众多输出属性中的一个，格式、长度、语言纯度、拒答行为，每一个都是独立的风险面。评估集覆盖了哪一面，你就在哪一面上有免疫力。

这次升级最终还是上了线——修完那套翻译模板的格式约束后，11 套评估全部通过。只是从此以后，"看起来都对"这句话，在评审会上再也过不了关了。