2、新鲜度核心指标：延迟、时效性、一致性、准确性定义

聊特征新鲜度，不能光喊「数据要新」。你得有具体的尺子去量。

我个人习惯，把新鲜度拆成四个维度：延迟、时效性、一致性、准确性。这四个指标，说白了就是回答四个问题：数据多久能到？到了能用多久？多份数据打架了怎么办？数据到底准不准？

咱们一个一个说。

2.1 延迟（Latency）—— 数据从产生到可用的时间差

延迟是最直观的指标。它衡量的是「事件发生」到「特征可用」之间的时间间隔。

我在项目中遇到过，业务方说「我要实时特征」，结果一查，他们所谓的实时其实是 T+1。嗯，这里要注意，延迟必须定义清楚粒度。

你想想看，如果只盯着计算延迟，忽略了上游 Kafka 积压，那你的「实时特征」其实是个假实时。

延迟类型	典型场景	可接受范围
端到端延迟	推荐系统用户点击 → 特征更新	< 1 秒
计算延迟	Flink 滑动窗口统计	< 100 毫秒
传输延迟	Kafka 生产 → 消费	< 50 毫秒

2.2 时效性（Freshness Window）—— 特征的有效期

时效性跟延迟不一样。延迟是「多久能到」，时效性是「到了之后能用多久」。

举个例子。用户的短期兴趣特征，比如「最近 5 分钟点击的品类」，它的时效性窗口就是 5 分钟。超过 5 分钟，这个特征就过期了，再用它做推荐，结果会偏。

我建议把时效性分为三类：

• 强时效：窗口 < 1 小时。比如实时点击流、会话行为。这类特征必须用流式计算。
• 弱时效：窗口 1 小时 ~ 1 天。比如用户日活跃度、小时级统计。可以用微批处理。
• 无时效：窗口 > 1 天。比如用户画像、历史统计。离线跑批就行。

为什么要把时效性和延迟分开？因为延迟低不代表时效性高。你 100 毫秒就把数据算出来了，但特征窗口是 24 小时的，那这个特征其实很「钝」。反过来，延迟 10 秒但窗口只有 1 分钟，那它依然很「锐」。

2.3 一致性（Consistency）—— 多份数据不打架

一致性是个容易被忽视的指标。尤其是在 Lambda 架构里，实时链路和离线链路算同一个特征，结果经常不一样。

我记得有一次排查线上模型效果波动，查了两天，最后发现是实时特征和离线特征对「用户 7 日点击率」的计算逻辑差了 0.5 个百分点。就因为实时链路用了滑动窗口，离线链路用了固定窗口。

一致性可以从三个层面衡量：

1. 计算一致性：同一份原始数据，不同链路算出的特征值是否相同？
2. 时间一致性：实时特征和离线特征是否对齐了时间窗口边界？
3. 存储一致性：在线存储和离线数仓里的特征值是否最终一致？

一致性维度	常见问题	解决方案
计算一致性	实时用 Flink，离线用 Hive，聚合函数不同	统一特征计算算子，做回归测试
时间一致性	实时窗口是 00:00:00 ~ 23:59:59，离线是 00:00:00 ~ 次日 00:00:00	对齐时间戳边界，使用事件时间
存储一致性	Redis 里的特征被误删，HBase 里的还在	引入版本号，做周期性对账

2.4 准确性（Accuracy）—— 特征值本身对不对

准确性是新鲜度的底线。数据再快、再新，如果值是错的，那还不如不用。

准确性的定义其实很直白：特征值是否真实反映了业务事实。但落地时，你会发现很多模糊地带。

比如「用户是否在 30 秒内点击了推荐商品」。如果用户点击后立即卸载了 App，服务端没收到点击回调，那特征值就是 False，但业务事实是 True。这就是数据采集层面的准确性丢失。

我建议从三个角度衡量准确性：

• 采集准确性：埋点是否完整？日志是否丢数？
• 计算准确性：特征逻辑是否跟业务定义一致？比如「7 日点击率」分母是曝光还是请求？
• 存储准确性：特征写入在线存储时，有没有发生类型转换错误或精度丢失？

2.5 四个指标的关系

这四个指标不是孤立的。它们互相影响，甚至互相矛盾。

你想想看，追求极致的低延迟，可能会牺牲一致性（实时链路来不及对齐离线逻辑）。追求高准确性，可能会增加计算延迟（需要做更多校验）。

我个人的经验是：先定准确性底线，再优化延迟，然后保证一致性，最后根据业务需求调整时效性窗口。这个优先级顺序，能帮你避免很多无谓的折腾。