机器学习项目有一个很典型的失败模式：离线评估 AUC 0.92，上线后效果平平，排查半天发现不是模型不行，而是训练时用的特征和线上算出来的特征不一致。这类问题不靠加数据、调参能解决，只能靠工程规范。
一、训练与推理不一致的三种来源
| 类型 | 表现 | 典型根因 |
|---|---|---|
| 逻辑不一致 | 离线用 SQL、线上用 Python 各写一遍 | 两套代码无人对账 |
| 时间不一致 | 离线用了未来信息，线上拿不到 | 特征回填未做时间点对齐 |
| 分布不一致 | 线上特征分布明显偏离训练集 | 缺失值填充、默认值策略不同 |
其中时间不一致的危害最大且最难发现。比如用“用户近 30 天订单数”做特征，若离线直接取当前快照值，则训练样本里实际混入了标签发生后才产生的数据，离线指标会虚高，而这种虚高在上线后无法复现。
二、时间点正确性：必须写进流程
特征回填时，“每个训练样本只能看到标签时点之前的信息”这条约束需要被工具化强制，而不是写在文档里提醒。实现上有几种做法：
- 事件时间快照：特征按时间分区存储，回填时取样本时间之前的最后一个版本。
- 统一时间基准：把事件时间、采集时间、入库时间三者分清楚，且在链路上全程传递事件时间。
- 自动检查：在特征产出后自动检测特征时间戳是否晚于样本时间，发现违规直接阻断数据集生成。
建议把最后一项做成阻断式检查，而不是告警。因为这类错误的后果是“指标好看但没用”，它不会被业务发现，只会被时间发现。
三、特征平台真正该提供的四件事
一是统一的特征定义。特征名称、业务含义、计算逻辑、负责人、更新频率。定义应可版本化，修改要与模型训练记录关联。
二是离线与在线的一致产出。同一个定义能同时生成离线数据集与线上特征。实务中最容易落地的方式是：在离线侧计算并写入在线存储，保证两边同源，而不是各自实现一遍。
三是回填与重算能力。特征逻辑修正后，能按时间区间重算并覆盖。没有这个能力，特征库会逐渐失去可信度。
四是监控。在线特征的分布、缺失率、延迟，以及相对训练集的偏移程度。
四、上线后的监控与回滚
模型上线不是终点，而是监控的起点。除了业务指标（点击率、转化率、坏账率），技术侧至少需要盯三类信号：
- 特征漂移：在线特征的分布相对训练集的偏移超过阈值时告警。它是模型失效最早的信号。
- 预测分布：预测值的均值与方差发生突变，往往意味着上游数据出问题或模型未正确加载。
- 特征延迟：依赖实时特征的模型，特征延迟直接影响效果，应作为可用性指标对待。
同时必须预置回滚路径：模型版本可快速切回上一版、特征可切换到降级版本（比如用离线最新值代替）。没有回滚能力的模型上线，等于把风险留给了业务。
五、推进顺序建议
不建议一上来就建“大而全”的特征平台。可行的路径是：先选一个已有效果较好的模型，把它的特征从代码里抽到统一定义中，建立离线与在线的一致性验证，跑通一两个迭代周期；然后再扩到更多模型。这个顺序的好处是：你能先看到一致性问题到底存不存在、存在哪里，再决定平台要建得多重。
