先给大家交代个背景免得看文章对不上号。我这两年主要做搜索推荐方向的模型工程离线训练和在线服务这条链路基本上每天都要摸一遍。前阵子遇上一个特别典型的线上事故离线指标漂亮得不行AUC涨了将近两个点上线之后核心业务指标直接掉了百分之十几。当时第一反应是模型出了什么问题排查到最后才发现根子压根不在模型而在于训练时的数据一套逻辑线上服务用的又是另一套逻辑——离线训练与在线服务的数据一致性被我们自己亲手打破了。这个坑我前前后后踩了小半个月今天把整个排查思路、根因分析和最终的解决方案完整写出来希望能让正在做或准备做模型上线的同学少走点弯路。1. 先说我踩过的那个坑一场线上事故的完整复盘1.1 事故现场离线指标和线上表现为什么对不上那段时间我们刚上了个新特征拿历史三个月的日志离线训练了一版模型离线评估集上的AUC从0.72涨到0.74GAUC也明显改善。模型上线走的是标准的灰度发布流程先切5%流量观察。结果是切流当天还好第二天核心指标就开始往下走第三天上了一级报警CTR掉了12%人均点击量也跟着掉了。我的第一反应是模型过拟合或者特征穿越了赶紧把训练样本拉出来查。查了两天发现训练数据本身没什么大问题标签没有穿越特征分位分布也正常。后来是组里一个做特征平台的同学提醒了一句你上线用的特征和训练时候用的特征真的是同一个东西吗当时我还觉得这个问题很傻都是同一个特征怎么可能不是同一个东西。后来才发现人家问到了要害上。1.2 把训练和上线两条链路摆到一起问题立刻暴露我们把训练样本里用到的特征生成逻辑和在线服务里实际用的特征生成逻辑一条一条对着看很快就发现了问题。我们有个特征是“用户最近24小时点击次数”训练的时候用的是T1的离线批处理统计口径是自然日零点到当前日志时间点的点击量算的是精确值线上服务为了性能考虑用的是一套近实时计数服务里面做了个5分钟的批量攒批而且统计窗口是滑动24小时不是自然日。单看一个特征好像差别不大。但叠加到几百个特征上差异就非常可观了。关键是这类差异不是固定偏差它跟一天内的时间段有关跟流量波峰波谷有关也就是说它是个时变的系统性偏差。模型在离线训练时学会的模式是“基于精确统计量的特征分布”上线之后喂进来的却是另一种口径的特征值特征分布整体偏移了模型表现自然就崩了。那个时刻我意识到一个非常扎心的事实训练和线上看似用的是同一套特征逻辑但工程上只要任何一步做了简化、异步化或者口径调整数据一致性就会被打破。而这个问题靠离线评估根本发现不了。2. 数据不一致的三个典型形态2.1 预处理逻辑不一致训练脚本和线上服务各写各的这是最常见、也最隐蔽的一种不一致。我见过太多团队离线特征工程是一套Python脚本线上服务是另一套Java或者C实现两边各自写着各自的预处理逻辑美其名曰“两边对照过结果是一样的”。但实际情况是两边的代码很少能长期保持一致。举几个我实际遇到过的例子。缺失值填充离线训练的时候用全体训练集的均值填充线上服务却用0来填充归一化的时候离线用全局min-max线上每次请求动态地取一个滑动窗口内的min-max导致同一个特征在不同时刻的归一化结果完全不一样。还有个更隐蔽的某个连续性特征要做log1p变换离线Python里写的是np.log1p(x)线上Java里有人写成了Math.log(x 1.0)理论上这两个等价但在浮点数运算上会有极小误差本来问题不大偏偏这个特征又被做了离散化分桶误差刚好卡在分桶边界上有的样本被分到了不同的桶里。这类问题的本质是离线训练和在线服务用的是两套代码实现任何一次改动都可能让它们悄悄分叉。你以为它们还在一起其实早就各走各的了。2.2 窗口与时间语义不一致滑动窗口的边界到底怎么算时间窗口特征是重灾区。比如“用户最近7天购买金额”“最近1小时活跃度”这类特征训练和线上非常容易在窗口定义上不一致。离线训练的时候我们通常用日志表里的时间戳精确到毫秒窗口边界是严格的“当前时间往前推N天”。但线上服务里同一个特征可能来自一个近实时统计服务这个服务为了降低存储和计算压力可能会按分钟或者小时粒度做预聚合窗口边界就变成了“当前整点往前推N天”。这个差异在凌晨零点附近最明显——离线特征的窗口可能已经覆盖了新的一天刚开始的数据在线特征还在用昨天的数据。还有更麻烦的线上服务如果做了缓存不同请求可能命中不同时间点的缓存导致同一个用户在几分钟内看到的特征值都是旧的。从单次请求来看都没问题但累积起来特征分布就不稳定了。2.3 样本定义不一致正负样本的口径漂移了这类不一致通常藏得更深因为它往往不在特征层而在学习目标层。我们训练的时候正负样本的定义是从日志里按规则打的标签比如“曝光后点击”为正样本、“曝光未点击”为负样本。这套标签在离线是静态的一次跑完就固定了。但线上服务为了提升用户体验做了不少策略上的微调比如同一个位置展示的商品有置顶规则、有强插规则。这导致线上实际曝光的分布和训练样本里的分布不一样离线评估时模型觉得这个特征很有区分度线上却发现这个特征对应的场景有很大一部分在训练集里根本没见过或见的比例很小。如果你做的是推荐排序和广告模型还会遇到另一个问题训练时的负样本是全局随机采样或均匀采样线上却要面对真实的曝光分布——而真实曝光本身就经过了一定策略的筛选不是均匀的。这种样本选择偏差也会被很多人误以为是模型问题实际根源还是训练数据与线上场景不一致。3. 为什么同一个特征离线在线就是算不对3.1 训练用的是“事后快照”线上用的是“当下实时”这个点一定要单独拿出来说。离线训练最大的特点是它站在事后视角可以把某一次请求发生时还不存在的信息一并算进去只要日志落了库就行。比如一个用户当天晚上8点发生了点击离线训练在第二天跑特征的时候把晚上8点之后的曝光、点击这些信息也算进了当时请求的特征里——严格来说这是特征穿越正常都会做防护。但真正普遍存在的不是这种明显的穿越而是一种“轻微的未来信息”。比如特征计算的时候用了请求时刻之后才回传的埋点数据。离线生成特征的时候日志表里那些报数字段都已经完整了你按请求ID一join自然就能拿到所有字段。但线上服务在请求发生的那一刻很多数据根本还没产生。这就是“事后快照”和“当下实时”的本质区别。你离线做特征工程的时候数据表的每一行都已经尘埃落定你要什么有什么线上服务一条请求过来你能用的只有当前这一刻已经存在的数据晚一毫秒产生的那部分都用不了。很多一致性问题的根源就是有人不小心把这两个视角混用了。3.2 特征平台视角怎么从根本上统一两套逻辑聊完了病根再说治病的方向。我自己最后走通的方案是引入一层统一特征逻辑让离线训练和在线服务共用同一套特征定义、同一份特征代码而不是各写各的。具体做法是把所有特征计算逻辑抽象成一个个独立的特征函数用同一套代码跑两条链路。离线训练的时候这个特征函数读取历史日志产出训练样本线上服务的时候同一个特征函数读取实时数据拼接出特征结果。两边的差异只体现在数据源上特征计算逻辑本身是同一份实现不存在分叉的可能。这个思路有个专门的说法叫特征存储feature store核心就是把特征的定义、计算逻辑、取值历史、版本元数据全部统一管理起来。训练阶段需要的是历史特征回放在线阶段需要的是低延迟特征读取两者共用一套特征定义。这样就不再需要“离线一套、线上另一套”了一致性从机制上就得到了保证。兼容老系统其实也不难。我们的老流程里有一大堆历史特征短时间不可能全部迁移就先做了一层映射层把线上已有的特征服务包一层SDK离线训练的时候用SDK从特征库回放历史数据而不是直接跑SQL拼特征。这样至少能保证两边读到的是同一个特征库逻辑上先统一实现细节慢慢收敛。3.3 统一之后还得带上版本管理不然新老特征又分叉统一了代码只是第一步版本管理同样重要。模型训练的时候用v1版的特征逻辑线上服务可能已经悄悄升级到了v2版这种新老版本交替期间的差异比双代码分叉更难排查因为两边都不觉得自己有问题。我们的做法是每个特征函数都带版本号训练任务在启动时记录自己用的特征版本线上服务在请求日志里记录当前生效的特征版本这样线上和离线就可以精确地对上账。每次修改特征逻辑必须先发布一个候选版本在离线回放和线上小流量并行跑一段时间确认一致性达标后才全量切换。数据一致性是个持续的过程不是一次性修完就完事。想靠一次重构把所有问题都解决不现实更靠谱的是建立一套能持续发现问题、持续收敛的机制。4. 排查实录当线上效果崩了怎么一步步定位到数据不一致4.1 从指标异动倒推先分清是模型问题还是数据问题事故发生后第一步不是急着改代码而是先把问题范围圈定。我先看了模型自身的输出分布分别统计线上模型打分的高、中、低三档占比和离线评估时的打分分布做对比。结果发现线上打分分布整体偏低而且高分档占比明显比离线少。这一步很关键因为它帮我们区分了两种可能性如果是模型本身的问题打分分布通常不会产生这么明显的变化如果是喂给模型的特征出现了偏移打分分布就会跟着偏移。到这里怀疑的对象就从模型转移到了特征。4.2 特征层面做一致性比对把线上采样和离线重算放在一起思路很简单从线上真实请求里采样一批日志把当时线上服务实际用的特征值全部记录下来然后用离线训练的那套特征生成逻辑对同样的请求、同样的时间点重新生成一遍特征值。两边放在一起做对比差异就暴露了。我们当时写了一个比对任务对每个特征分别计算三个指标均值偏差、分位数偏差、以及差异率差异超过阈值的样本占比。跑完一看问题特征马上就浮出来了就是前面提到的“用户最近24小时点击次数”。它的均值偏差有18%差异率接近30%其他特征虽然也有差异但基本在正常范围内。定位到具体特征之后再回去看这个特征在线上服务里的实现很快就找到了那个5分钟批量攒批的代码。攒批本身不是问题问题是攒批之后没有对窗口做补偿窗口起点和离线口径不一致。改掉这个细节之后重新做比对差异率降到了1%以下。4.3 上线前的影子验证和回放能拦住大多数同类问题出了这次事故之后我们把一致性比对做成了标准流程每次模型要上线都会先做一轮特征一致性检测算法同学把离线特征和线上采样特征放到同一个框架里跑一遍差异率超标的直接不允许上线。还加了影子验证这一步。所谓影子验证就是把线上真实请求同时发给模型服务和一个影子服务影子服务用的是另一个版本的特征两边打分结果做对比。这个做法不产生真实曝光不影响线上体验却能非常真实地检验两套逻辑在线上环境下的差异。特别是新特征上线前用影子验证跑个24小时能覆盖不同时段的流量特征比单纯离线比对可靠得多。5. 一劳永逸的方案建立离线在线一致性机制5.1 统一特征逻辑层用一套代码解决分叉问题我们在特征平台基础上把所有特征沉淀成一份“特征定义”清单每个特征都有唯一的名称、版本、窗口定义、聚合粒度、数据来源。训练框架和服务框架都通过SDK调用这同一份定义禁止任何人绕过SDK自己写逻辑。给个简化示例帮助理解这套机制长什么样。假设我们要定义一个“用户最近24小时点击次数”的特征feature(nameuser_click_cnt_24h, versionv2) def user_click_cnt_24h(user_id: str, current_ts: int) - dict: # 统一的时间窗口定义当前时刻往前推24小时左闭右开 window_start current_ts - 24 * 3600 * 1000 window_end current_ts # 统一的聚合逻辑精确计数不做任何近似 click_cnt click_store.count(user_id, window_start, window_end) return {value: click_cnt, version: v2}离线训练的时候这个函数直接从离线数据源读取线上服务时同一个函数从在线特征服务读取。代码只有一份实现完全一致任何一方想改逻辑都只能改同一个地方分叉的可能性从机制上被消灭了。5.2 一致性测试怎么落地从比对到验收的具体流程有了统一逻辑层之后一致性测试要常态化。我按我们团队的实践整理了一个简化的流程离线基准建立每次发布新特征或修改特征逻辑先在离线环境生成一份基准特征集保存为文件或表。线上采样比对从线上真实请求中采样把线上实际使用的特征值与离线基准特征集做对比计算差异率。差异分析如果差异率超过阈值自动触发告警并把差异最大的Top特征打印出来。人工确认算法或特征工程同学确认差异来源是逻辑分叉还是数据延迟记录原因。回归通过只有差异率在合理范围内才允许模型上线。这个流程听起来不复杂但真正落地时会发现难点在阈值的确定。不同特征的容忍度不一样连续特征对均值偏差敏感离散特征对分桶错位敏感有些特征天生波动大不能一刀切。我们的做法是先离线跑一段时间统计每个特征在没有逻辑改动情况下的正常差异范围用这个作为基线阈值而不是拍脑袋定一个数字。5.3 一份能直接抄作业的排查清单把这次事故和之前几次同类问题的处理经验汇总一下整理了一份排查清单可以保存下来遇到线上效果异常的时候直接对着查检查项排查方法说明打分分布对比线上打分分布与离线评估打分分布分布偏移明显大概率是特征问题不是模型问题特征值快照线上服务打印实时特征值与离线重算值比对重点看均值、分位数、差异率三个指标时间窗口定义确认离线统计窗口和线上窗口是否同口径看边界是自然日、滑动窗口还是整点对齐缺失值处理确认离线填充值是否等于线上实际填充值两边各写各的fillna最容易出问题归一化参数确认min/max或均值和方差来自同一份统计来源线上不能用滑动窗口实时算类别特征映射确认线上能否处理离线训练中未出现过的新值新值fallback策略要和离线一致样本选择确认离线正负样本分布与线上真实曝光分布是否一致推荐排序场景特别容易忽视特征版本确认训练任务和线上服务使用的特征版本一致新老版本交替期最容易出现隐性问题这份清单不只是给算法同学看的特征工程、服务端开发、数据平台的同学都适用。很多时候问题不是某一个环节造成的而是每个环节各自为政、互相对不上账造成的。5.4 组织协作上的坑也顺便说一下技术方案说完了还是要提一句人在流程里的作用。数据一致性这个问题本质上不只是技术问题也是协作问题。我们团队之前的分工是算法同学写训练逻辑服务端同学写线上逻辑两边代码仓库都是独立的出问题之后互相扯皮占了不少时间。后来我们把特征逻辑的owner明确为一个人或一个小组谁的逻辑谁负责维护算法和服务端都只能通过SDK调用不允许绕过。代码评审的时候多一个审查点涉及特征逻辑的改动必须同时评估离线和在线两边的影响。看起来是多了一道流程实际上省了后面大量的排查时间。还有一个容易被忽略的点特征逻辑的改动尽量要做成向后兼容的不要让旧模型在线上跑着跑着特征就被换掉了。我们的习惯是每次特征逻辑变更都新起一个特征名或版本号老版本逻辑保留一段时间等所有在用模型都迁移完之后再下线老版本。6. 最后想说的心里话这次踩坑让我最深的体会是离线训练与在线服务的数据一致性不属于那种“做一次就完事”的工作它更像是一个持续对抗熵增的过程。模型本身进步很快但数据链路上的一次微小分叉就足以让模型在离线评估和线上表现之间出现巨大鸿沟。我个人现在有一个习惯不管模型改动是大是小上线前都强制自己回答三个问题线上服务和离线训练对于每个特征用的是同一个函数吗它们的时间窗口和数据来源是同一个口径吗如果两边有任何一方改过逻辑有没有重新做过一致性比对这三个问题想清楚了再谈模型效果心里就有底得多。另外也建议同行们重视特征日志的价值。我们这次事故能快速定位很大程度是因为线上服务一直在打印特征快照没有这个的话排查起来基本就是大海捞针。哪怕多花点存储成本也要把关键请求的特征日志留够关键时刻它是救命稻草。这个领域能聊的还有很多比如特征穿越的检测、时间一致性校验、在线离线AB实验对齐等等如果大家感兴趣我后面可以再把其他几块单独展开写写。
离线在线数据一致性：一次线上事故的复盘与根治方案
先给大家交代个背景免得看文章对不上号。我这两年主要做搜索推荐方向的模型工程离线训练和在线服务这条链路基本上每天都要摸一遍。前阵子遇上一个特别典型的线上事故离线指标漂亮得不行AUC涨了将近两个点上线之后核心业务指标直接掉了百分之十几。当时第一反应是模型出了什么问题排查到最后才发现根子压根不在模型而在于训练时的数据一套逻辑线上服务用的又是另一套逻辑——离线训练与在线服务的数据一致性被我们自己亲手打破了。这个坑我前前后后踩了小半个月今天把整个排查思路、根因分析和最终的解决方案完整写出来希望能让正在做或准备做模型上线的同学少走点弯路。1. 先说我踩过的那个坑一场线上事故的完整复盘1.1 事故现场离线指标和线上表现为什么对不上那段时间我们刚上了个新特征拿历史三个月的日志离线训练了一版模型离线评估集上的AUC从0.72涨到0.74GAUC也明显改善。模型上线走的是标准的灰度发布流程先切5%流量观察。结果是切流当天还好第二天核心指标就开始往下走第三天上了一级报警CTR掉了12%人均点击量也跟着掉了。我的第一反应是模型过拟合或者特征穿越了赶紧把训练样本拉出来查。查了两天发现训练数据本身没什么大问题标签没有穿越特征分位分布也正常。后来是组里一个做特征平台的同学提醒了一句你上线用的特征和训练时候用的特征真的是同一个东西吗当时我还觉得这个问题很傻都是同一个特征怎么可能不是同一个东西。后来才发现人家问到了要害上。1.2 把训练和上线两条链路摆到一起问题立刻暴露我们把训练样本里用到的特征生成逻辑和在线服务里实际用的特征生成逻辑一条一条对着看很快就发现了问题。我们有个特征是“用户最近24小时点击次数”训练的时候用的是T1的离线批处理统计口径是自然日零点到当前日志时间点的点击量算的是精确值线上服务为了性能考虑用的是一套近实时计数服务里面做了个5分钟的批量攒批而且统计窗口是滑动24小时不是自然日。单看一个特征好像差别不大。但叠加到几百个特征上差异就非常可观了。关键是这类差异不是固定偏差它跟一天内的时间段有关跟流量波峰波谷有关也就是说它是个时变的系统性偏差。模型在离线训练时学会的模式是“基于精确统计量的特征分布”上线之后喂进来的却是另一种口径的特征值特征分布整体偏移了模型表现自然就崩了。那个时刻我意识到一个非常扎心的事实训练和线上看似用的是同一套特征逻辑但工程上只要任何一步做了简化、异步化或者口径调整数据一致性就会被打破。而这个问题靠离线评估根本发现不了。2. 数据不一致的三个典型形态2.1 预处理逻辑不一致训练脚本和线上服务各写各的这是最常见、也最隐蔽的一种不一致。我见过太多团队离线特征工程是一套Python脚本线上服务是另一套Java或者C实现两边各自写着各自的预处理逻辑美其名曰“两边对照过结果是一样的”。但实际情况是两边的代码很少能长期保持一致。举几个我实际遇到过的例子。缺失值填充离线训练的时候用全体训练集的均值填充线上服务却用0来填充归一化的时候离线用全局min-max线上每次请求动态地取一个滑动窗口内的min-max导致同一个特征在不同时刻的归一化结果完全不一样。还有个更隐蔽的某个连续性特征要做log1p变换离线Python里写的是np.log1p(x)线上Java里有人写成了Math.log(x 1.0)理论上这两个等价但在浮点数运算上会有极小误差本来问题不大偏偏这个特征又被做了离散化分桶误差刚好卡在分桶边界上有的样本被分到了不同的桶里。这类问题的本质是离线训练和在线服务用的是两套代码实现任何一次改动都可能让它们悄悄分叉。你以为它们还在一起其实早就各走各的了。2.2 窗口与时间语义不一致滑动窗口的边界到底怎么算时间窗口特征是重灾区。比如“用户最近7天购买金额”“最近1小时活跃度”这类特征训练和线上非常容易在窗口定义上不一致。离线训练的时候我们通常用日志表里的时间戳精确到毫秒窗口边界是严格的“当前时间往前推N天”。但线上服务里同一个特征可能来自一个近实时统计服务这个服务为了降低存储和计算压力可能会按分钟或者小时粒度做预聚合窗口边界就变成了“当前整点往前推N天”。这个差异在凌晨零点附近最明显——离线特征的窗口可能已经覆盖了新的一天刚开始的数据在线特征还在用昨天的数据。还有更麻烦的线上服务如果做了缓存不同请求可能命中不同时间点的缓存导致同一个用户在几分钟内看到的特征值都是旧的。从单次请求来看都没问题但累积起来特征分布就不稳定了。2.3 样本定义不一致正负样本的口径漂移了这类不一致通常藏得更深因为它往往不在特征层而在学习目标层。我们训练的时候正负样本的定义是从日志里按规则打的标签比如“曝光后点击”为正样本、“曝光未点击”为负样本。这套标签在离线是静态的一次跑完就固定了。但线上服务为了提升用户体验做了不少策略上的微调比如同一个位置展示的商品有置顶规则、有强插规则。这导致线上实际曝光的分布和训练样本里的分布不一样离线评估时模型觉得这个特征很有区分度线上却发现这个特征对应的场景有很大一部分在训练集里根本没见过或见的比例很小。如果你做的是推荐排序和广告模型还会遇到另一个问题训练时的负样本是全局随机采样或均匀采样线上却要面对真实的曝光分布——而真实曝光本身就经过了一定策略的筛选不是均匀的。这种样本选择偏差也会被很多人误以为是模型问题实际根源还是训练数据与线上场景不一致。3. 为什么同一个特征离线在线就是算不对3.1 训练用的是“事后快照”线上用的是“当下实时”这个点一定要单独拿出来说。离线训练最大的特点是它站在事后视角可以把某一次请求发生时还不存在的信息一并算进去只要日志落了库就行。比如一个用户当天晚上8点发生了点击离线训练在第二天跑特征的时候把晚上8点之后的曝光、点击这些信息也算进了当时请求的特征里——严格来说这是特征穿越正常都会做防护。但真正普遍存在的不是这种明显的穿越而是一种“轻微的未来信息”。比如特征计算的时候用了请求时刻之后才回传的埋点数据。离线生成特征的时候日志表里那些报数字段都已经完整了你按请求ID一join自然就能拿到所有字段。但线上服务在请求发生的那一刻很多数据根本还没产生。这就是“事后快照”和“当下实时”的本质区别。你离线做特征工程的时候数据表的每一行都已经尘埃落定你要什么有什么线上服务一条请求过来你能用的只有当前这一刻已经存在的数据晚一毫秒产生的那部分都用不了。很多一致性问题的根源就是有人不小心把这两个视角混用了。3.2 特征平台视角怎么从根本上统一两套逻辑聊完了病根再说治病的方向。我自己最后走通的方案是引入一层统一特征逻辑让离线训练和在线服务共用同一套特征定义、同一份特征代码而不是各写各的。具体做法是把所有特征计算逻辑抽象成一个个独立的特征函数用同一套代码跑两条链路。离线训练的时候这个特征函数读取历史日志产出训练样本线上服务的时候同一个特征函数读取实时数据拼接出特征结果。两边的差异只体现在数据源上特征计算逻辑本身是同一份实现不存在分叉的可能。这个思路有个专门的说法叫特征存储feature store核心就是把特征的定义、计算逻辑、取值历史、版本元数据全部统一管理起来。训练阶段需要的是历史特征回放在线阶段需要的是低延迟特征读取两者共用一套特征定义。这样就不再需要“离线一套、线上另一套”了一致性从机制上就得到了保证。兼容老系统其实也不难。我们的老流程里有一大堆历史特征短时间不可能全部迁移就先做了一层映射层把线上已有的特征服务包一层SDK离线训练的时候用SDK从特征库回放历史数据而不是直接跑SQL拼特征。这样至少能保证两边读到的是同一个特征库逻辑上先统一实现细节慢慢收敛。3.3 统一之后还得带上版本管理不然新老特征又分叉统一了代码只是第一步版本管理同样重要。模型训练的时候用v1版的特征逻辑线上服务可能已经悄悄升级到了v2版这种新老版本交替期间的差异比双代码分叉更难排查因为两边都不觉得自己有问题。我们的做法是每个特征函数都带版本号训练任务在启动时记录自己用的特征版本线上服务在请求日志里记录当前生效的特征版本这样线上和离线就可以精确地对上账。每次修改特征逻辑必须先发布一个候选版本在离线回放和线上小流量并行跑一段时间确认一致性达标后才全量切换。数据一致性是个持续的过程不是一次性修完就完事。想靠一次重构把所有问题都解决不现实更靠谱的是建立一套能持续发现问题、持续收敛的机制。4. 排查实录当线上效果崩了怎么一步步定位到数据不一致4.1 从指标异动倒推先分清是模型问题还是数据问题事故发生后第一步不是急着改代码而是先把问题范围圈定。我先看了模型自身的输出分布分别统计线上模型打分的高、中、低三档占比和离线评估时的打分分布做对比。结果发现线上打分分布整体偏低而且高分档占比明显比离线少。这一步很关键因为它帮我们区分了两种可能性如果是模型本身的问题打分分布通常不会产生这么明显的变化如果是喂给模型的特征出现了偏移打分分布就会跟着偏移。到这里怀疑的对象就从模型转移到了特征。4.2 特征层面做一致性比对把线上采样和离线重算放在一起思路很简单从线上真实请求里采样一批日志把当时线上服务实际用的特征值全部记录下来然后用离线训练的那套特征生成逻辑对同样的请求、同样的时间点重新生成一遍特征值。两边放在一起做对比差异就暴露了。我们当时写了一个比对任务对每个特征分别计算三个指标均值偏差、分位数偏差、以及差异率差异超过阈值的样本占比。跑完一看问题特征马上就浮出来了就是前面提到的“用户最近24小时点击次数”。它的均值偏差有18%差异率接近30%其他特征虽然也有差异但基本在正常范围内。定位到具体特征之后再回去看这个特征在线上服务里的实现很快就找到了那个5分钟批量攒批的代码。攒批本身不是问题问题是攒批之后没有对窗口做补偿窗口起点和离线口径不一致。改掉这个细节之后重新做比对差异率降到了1%以下。4.3 上线前的影子验证和回放能拦住大多数同类问题出了这次事故之后我们把一致性比对做成了标准流程每次模型要上线都会先做一轮特征一致性检测算法同学把离线特征和线上采样特征放到同一个框架里跑一遍差异率超标的直接不允许上线。还加了影子验证这一步。所谓影子验证就是把线上真实请求同时发给模型服务和一个影子服务影子服务用的是另一个版本的特征两边打分结果做对比。这个做法不产生真实曝光不影响线上体验却能非常真实地检验两套逻辑在线上环境下的差异。特别是新特征上线前用影子验证跑个24小时能覆盖不同时段的流量特征比单纯离线比对可靠得多。5. 一劳永逸的方案建立离线在线一致性机制5.1 统一特征逻辑层用一套代码解决分叉问题我们在特征平台基础上把所有特征沉淀成一份“特征定义”清单每个特征都有唯一的名称、版本、窗口定义、聚合粒度、数据来源。训练框架和服务框架都通过SDK调用这同一份定义禁止任何人绕过SDK自己写逻辑。给个简化示例帮助理解这套机制长什么样。假设我们要定义一个“用户最近24小时点击次数”的特征feature(nameuser_click_cnt_24h, versionv2) def user_click_cnt_24h(user_id: str, current_ts: int) - dict: # 统一的时间窗口定义当前时刻往前推24小时左闭右开 window_start current_ts - 24 * 3600 * 1000 window_end current_ts # 统一的聚合逻辑精确计数不做任何近似 click_cnt click_store.count(user_id, window_start, window_end) return {value: click_cnt, version: v2}离线训练的时候这个函数直接从离线数据源读取线上服务时同一个函数从在线特征服务读取。代码只有一份实现完全一致任何一方想改逻辑都只能改同一个地方分叉的可能性从机制上被消灭了。5.2 一致性测试怎么落地从比对到验收的具体流程有了统一逻辑层之后一致性测试要常态化。我按我们团队的实践整理了一个简化的流程离线基准建立每次发布新特征或修改特征逻辑先在离线环境生成一份基准特征集保存为文件或表。线上采样比对从线上真实请求中采样把线上实际使用的特征值与离线基准特征集做对比计算差异率。差异分析如果差异率超过阈值自动触发告警并把差异最大的Top特征打印出来。人工确认算法或特征工程同学确认差异来源是逻辑分叉还是数据延迟记录原因。回归通过只有差异率在合理范围内才允许模型上线。这个流程听起来不复杂但真正落地时会发现难点在阈值的确定。不同特征的容忍度不一样连续特征对均值偏差敏感离散特征对分桶错位敏感有些特征天生波动大不能一刀切。我们的做法是先离线跑一段时间统计每个特征在没有逻辑改动情况下的正常差异范围用这个作为基线阈值而不是拍脑袋定一个数字。5.3 一份能直接抄作业的排查清单把这次事故和之前几次同类问题的处理经验汇总一下整理了一份排查清单可以保存下来遇到线上效果异常的时候直接对着查检查项排查方法说明打分分布对比线上打分分布与离线评估打分分布分布偏移明显大概率是特征问题不是模型问题特征值快照线上服务打印实时特征值与离线重算值比对重点看均值、分位数、差异率三个指标时间窗口定义确认离线统计窗口和线上窗口是否同口径看边界是自然日、滑动窗口还是整点对齐缺失值处理确认离线填充值是否等于线上实际填充值两边各写各的fillna最容易出问题归一化参数确认min/max或均值和方差来自同一份统计来源线上不能用滑动窗口实时算类别特征映射确认线上能否处理离线训练中未出现过的新值新值fallback策略要和离线一致样本选择确认离线正负样本分布与线上真实曝光分布是否一致推荐排序场景特别容易忽视特征版本确认训练任务和线上服务使用的特征版本一致新老版本交替期最容易出现隐性问题这份清单不只是给算法同学看的特征工程、服务端开发、数据平台的同学都适用。很多时候问题不是某一个环节造成的而是每个环节各自为政、互相对不上账造成的。5.4 组织协作上的坑也顺便说一下技术方案说完了还是要提一句人在流程里的作用。数据一致性这个问题本质上不只是技术问题也是协作问题。我们团队之前的分工是算法同学写训练逻辑服务端同学写线上逻辑两边代码仓库都是独立的出问题之后互相扯皮占了不少时间。后来我们把特征逻辑的owner明确为一个人或一个小组谁的逻辑谁负责维护算法和服务端都只能通过SDK调用不允许绕过。代码评审的时候多一个审查点涉及特征逻辑的改动必须同时评估离线和在线两边的影响。看起来是多了一道流程实际上省了后面大量的排查时间。还有一个容易被忽略的点特征逻辑的改动尽量要做成向后兼容的不要让旧模型在线上跑着跑着特征就被换掉了。我们的习惯是每次特征逻辑变更都新起一个特征名或版本号老版本逻辑保留一段时间等所有在用模型都迁移完之后再下线老版本。6. 最后想说的心里话这次踩坑让我最深的体会是离线训练与在线服务的数据一致性不属于那种“做一次就完事”的工作它更像是一个持续对抗熵增的过程。模型本身进步很快但数据链路上的一次微小分叉就足以让模型在离线评估和线上表现之间出现巨大鸿沟。我个人现在有一个习惯不管模型改动是大是小上线前都强制自己回答三个问题线上服务和离线训练对于每个特征用的是同一个函数吗它们的时间窗口和数据来源是同一个口径吗如果两边有任何一方改过逻辑有没有重新做过一致性比对这三个问题想清楚了再谈模型效果心里就有底得多。另外也建议同行们重视特征日志的价值。我们这次事故能快速定位很大程度是因为线上服务一直在打印特征快照没有这个的话排查起来基本就是大海捞针。哪怕多花点存储成本也要把关键请求的特征日志留够关键时刻它是救命稻草。这个领域能聊的还有很多比如特征穿越的检测、时间一致性校验、在线离线AB实验对齐等等如果大家感兴趣我后面可以再把其他几块单独展开写写。
