线上和离线特征一致性如何保证？

简化版

线上线下一致性要求同一实体、同一事件时点、同一特征版本在训练和服务得到等价值。常见偏差来自两套代码、时间窗口、默认值、时区、迟到数据和刷新延迟；应共享定义并持续做影子对账。

详细版

• 一致不等于数值永远完全相同，要预先定义浮点容差。

• 训练按历史时点取值，线上按请求时点取值，比较时必须对齐时间。

• 默认值和缺失语义属于特征定义。

• 日志需记录实际送入模型的向量，而非只记源数据。

• 对账应覆盖正常、缺失、边界和迟到样本。

完整版教学

一、一致性是同一语义的双执行验证

离线常用 SQL/Spark，在线用流处理或应用代码；若逻辑复制两份，窗口边界和类型转换会逐渐分叉。

共享 DSL/转换库能减少偏差，但数据到达与状态存储仍不同，所以必须用真实请求对账。

对账目标不是追求所有浮点位完全相同，而是证明同一实体、时点和版本的差异处于预先定义的语义与数值容差内。

二、底层机制与公式

diff=abs(feature_offline(entity,t,version)-feature_online_logged(entity,t,version))
pass if diff<=atol+rtol*abs(reference)

三、带数字的推演

7 日窗口离线用 [t-7d,t)，在线误用 (t-7d,t]，边界各差一条交易。

普通样本看不出，恰在 t 或 t-7d 的回放样本会稳定复现差异。

四、方案对比

方案/对象	核心特点	代价或边界
共享转换代码	减少逻辑漂移	跨引擎兼容成本
在线日志回放	最贴近实际输入	日志与隐私成本
双写影子对账	持续发现偏差	增加计算与告警治理

五、执行流程

线上记录 entity/time/version/feature -> 延迟到齐后离线重算
-> 按容差逐项 diff -> 聚合偏差率 -> 定位代码/数据/时效根因

六、边界条件与工程代价

在线值更新有 SLA，离线真值要在同一数据可见时点重算；拿事后补齐数据比较会把迟到误报为代码不一致。

浮点、排序和集合聚合可能非确定，应为不同特征定义精确、相对或集合一致性规则。

记忆钩子：一致性对账的主键是“实体 + 时点 + 版本”。

七、常见误区与追问

• 误区：使用同一公式就一定一致。 数据时点、默认值和执行引擎也会造成偏差。

• 追问：对账比较什么日志？ 比较实际进入模型的特征向量。

• 误区：离线最新值可直接对比线上历史值。 必须锁定同一事件与可用时间。

• 追问：窗口边界怎么验？ 构造恰在起止时刻的交易样本。

• 追问：告警看哪些量？ 偏差比例、幅度、涉及实体和特征新鲜度。

八、加强记忆

一致性对账的主键是“实体 + 时点 + 版本”。

共享代码降低风险，真实输入日志回放才是最终证据。