别再怪模型不稳定：真正让 AI 线上翻车的，是你把“特征工程”当成了临时脚本

很多团队都经历过同一个魔幻时刻：

你在 notebook 里把模型调到 0.9+，验证集漂亮得像 PPT 封面；一上生产，效果直接塌成 0.6，甚至更差。然后会议室里开始出现熟悉台词：

• “是不是模型太弱？”
• “要不要换更大的底座？”
• “再调调参数吧。”

坦白说，这类讨论大多在浪费时间。我的判断很直接：多数线上劣化，不是模型问题，而是训练—服务偏差（train/serve skew）问题。

你训练时喂给模型的世界，和线上推理时让它面对的世界，根本不是一个世界。模型不是不聪明，是你在训练时教它开自动挡，上线时却把车换成手动挡，还怪它不会踩离合。

一、什么叫训练—服务偏差？

一句话：同一个特征名，背后不是同一个计算过程。

看起来你在训练和线上都用了 user_7d_ctr、is_new_user、session_depth，但细看实现：

• 训练侧用 pandas，线上用 Spark/Flink
• 训练侧缺失值填 0，线上填全局均值
• 训练侧按 UTC 切日，线上按本地时区切日
• 训练侧先 winsorize 后 log，线上顺序反了
• 训练样本用了“事后才知道”的字段，线上永远拿不到

这些差异单看都“不大”，叠加起来就是灾难。你以为是同一个特征，模型看到的却是两套语义。

这不是精度波动，这是输入分布被你自己改写了。

二、为什么这个坑反复出现？

因为很多团队把特征工程当“研究代码”，把线上推理当“工程代码”，中间靠口头对齐。口头对齐在 demo 阶段能活，在生产阶段必死。

1) 组织结构把“同一件事”拆成两拨人

算法同学写训练 pipeline，平台同学写 serving pipeline。两边都很专业，但目标函数不同：

• 算法追离线指标
• 平台追吞吐和延迟

最后出现经典局面：离线指标很好，线上 SLA 也没超，但业务指标掉了。因为没人对“特征语义一致性”负总责。

2) 代码复用是假象，逻辑复用才是关键

很多人说“我们复用了函数库”。问题是你只复用了工具函数，没复用完整变换图：字段依赖、执行顺序、时间窗口、缺失策略、版本边界。这些才是语义。

3) 评审机制在看“能不能跑”，不看“是不是同一个东西”

上线评审常问：

• 延迟多少？
• QPS 顶不顶得住？
• 回滚脚本有吗？

却很少问：

• 训练样本的特征分布和线上实时分布，PSI/KL 差距多少？
• 黄金样本在训练和服务两条链路产出的特征是否逐列一致？
• 时间切分是否保证了“当时可得性”？

你不问，就默认它一致；默认一致通常就是不一致。

三、别再迷信“更大模型能覆盖脏输入”

很多团队在 skew 出现后第一反应是升级模型：从小模型换大模型，从单塔换多塔，甚至直接上多模态。结果通常是：短期有点提升，长期继续崩。

原因很简单：

• 大模型可以提高容错，但不能修复系统性输入污染
• 输入语义漂移是“数据契约破坏”，不是“参数容量不足”
• 你今天靠容量硬扛，明天数据再漂一点，照样出事

用一句不好听但真实的话：用更大模型去掩盖 skew，就像用更厚的粉底遮结构性骨折。

四、真正有效的解法：把“特征”当产品，不当脚本

我建议把特征系统升级为三层治理，而不是继续堆 patch。

第一层：单一计算真相（Single Source of Feature Truth）

核心原则：特征只计算一次，多处消费，不允许二次实现。

• 训练、回放、在线推理都调用同一份特征定义
• 特征定义必须版本化（含依赖、窗口、缺失规则）
• 任何改动都生成新版本，不允许 silent overwrite

这一步做不到，后面全是补丁美学。

第二层：上线前“黄金样本对拍”

准备一组覆盖边界条件的黄金样本（新用户、老用户、异常值、跨时区、缺字段等），在训练链路和服务链路分别计算特征，逐列比对。

验收标准别写“差不多”，要写：

• 数值列容差阈值（如 abs diff < 1e-6）
• 枚举列完全一致
• 缺失模式一致
• 派生列依赖路径一致

对拍不过，禁止上线。 这条规则会得罪人，但会救命。

第三层：上线后分布守卫（Distribution Guardrail）

模型上线不是结束，而是开始。你需要持续监控：

• 特征分布漂移（PSI、JS/KL）
• 特征可用率（null ratio、超时率）
• 关键业务切片（新客/老客、地区、设备）上的输出稳定性

并且预先定义自动化动作：

• 漂移越过阈值 → 自动降级到上一稳定版本
• 缺失率异常 → 切换兜底策略并告警
• 关键切片崩塌 → 触发人工值班流程

没有“可执行的回滚”，所有监控都只是赛博烟花。

五、从工程问题到治理问题：你到底在奖励什么行为？

很多组织明知有 skew，仍长期不修，不是技术不会，是激励错了。

如果你的绩效体系奖励的是：

• 模型迭代速度
• 新功能上线数量
• 单点离线指标

那团队自然会把“特征一致性”当阻碍，因为它短期拖慢节奏。

你要改的是激励函数：

• 把线上一致性通过率纳入发布门槛
• 把回滚时长（MTTR）纳入核心指标
• 把“避免事故”计入可见贡献，而不是只奖励“造新东西”

系统会长成你奖励的样子。 这是工程世界最朴素、也最残酷的规律。

六、给正在做 AI 产品的团队一个硬结论

如果你现在还在：

• 训练一套代码、线上一套代码
• 特征定义散落在脚本和 SQL 里
• 上线不做黄金样本对拍
• 漂移监控只有 dashboard，没有自动动作

那你不是“偶尔会出线上事故”，你是已经在事故轨道上，只是等时间戳。

真正成熟的 AI 团队，不是离线分数最高的团队，而是能长期维持“训练语义 = 服务语义”的团队。前者靠天赋，后者靠制度。天赋会波动，制度才可复制。

所以，别再问“模型怎么又不稳定”。先问一句更扎心但更有用的话：

我们有没有把特征工程，从个人技巧升级成组织能力？

如果没有，现在就改。越晚改，补的窟窿越贵。

—— https://it8090.cn