很多团队第一次听到 PLFM_RADAR 这个名字都会问一句你们给自己监控系统起个雷达的名字是不是有点夸张后来线上模型连续几次诡异告警、业务方半夜找上门来我才彻底想明白——模型上线之后特征分布就像周围环境算法工程师不可能一直盯着每一寸空间必须有一部雷达帮我们扫描。PLFM 的全称是 Python Lightweight Feature Monitor本质是一个轻量级的特征监控雷达系统专门盯特征漂移、样本异常和模型行为突变。这篇文章我打算把整套思路、关键代码和踩坑记录都留下来。如果你正在做模型上线后的质量保障或者已经试过几个开源监控方案但总觉得差口气那这篇应该能帮上忙。先说一下我写这套东西时的核心判断模型监控的价值不在指标好不好看而在能不能在模型真正出问题之前先一步告诉我们哪里不对劲。1. 为什么现成的监控平台“不够用”我才决定自己写雷达1.1 开源方案在真实生产环境里的三个痛点我们团队最早也迷信过大而全的监控方案。Prometheus 拉取指标Grafana 画大盘CPU、内存、QPS、延迟、错误率一屏放下看着很唬人。但第一次线上模型效果滑坡就露馅了服务各项指标全部正常线程健康、内存稳定、QPS 没有波动唯独模型 CTR 预估在一夜之间偏了。业务方来问的时候我们盯着绿油油的大盘完全答不上来。后来复盘才发现问题出在特征分布上用户年龄特征的分布发生了明显偏移模型见过的分布和线上实际分布对不上了。可这些信息Prometheus 根本不会管因为它只认识 metrics不认识特征。我还专门试过几个开源工具先列一下真实感受。Whylogs 做数据画像和漂移检测很专业但它本质是一个 Python 库不是一套可落地的监控系统。调度怎么跑、检测结果存哪、告警怎么发、告警怎么去重全部要自己重新搭。Evidently 的报告确实漂亮PSI、数据质量、目标漂移这些功能都很全但它的强项是离线数据分析做成准实时告警需要额外接 Airflow 或 Prefect还要自己设计通知链路。Alibi Detect 的算法最丰富漂移检测、对抗检测都有但偏研究向光理解它的参数就要花不少时间拿来做线上监控有点像用火箭炮打蚊子。最别扭的是这些工具都缺一个东西告警的解释性。它们能告诉你特征漂移了但不会告诉你到底是哪个分箱发生了异常具体是哪部分人群的比例变了。而生产环境里没有定位信息的告警基本等于没有告警。1.2 从指标大屏到预警雷达PLFM_RADAR 的设计目标所以我决定自己写。PLFM_RADAR 这个名字有两层意思一是它真的像雷达一样按固定频率扫描线上的特征空间持续形成态势感知二是我们内部把 RADAR 解读为 Reliable Anomaly Detection and Alerting也就是可靠异常检测与告警这套机制。它的设计目标从一开始就不是做一个更漂亮的指标大屏而是做一台真正的预警雷达。这台雷达需要覆盖三类信号。第一类是单特征分布漂移比如年龄、收入、设备类型的分布变了第二类是特征间关系异常比如原本相关性很高的两个特征突然脱钩或者模型里最重要的特征被换掉了第三类是样本质量异常比如缺失率飙升、出现大量常量特征、NaN 或 Inf 激增。每一类都是一条独立的扫描线哪条先报警就优先看哪条。还有一个原则我坚持到现在雷达不能只喊有威胁必须给出方位和距离。告警消息里要带异常特征 TopK、每个分箱的占比变化、与基线的偏差程度这样值班的人拿到告警就能开始排查而不是再去写脚本重新算一遍。这个设计上的取舍后面救了我们不止一次。2. 系统架构拆解特征监控雷达到底在扫什么2.1 数据采集层训练基线特征库与线上实时特征流的对齐整个 PLFM_RADAR 的架构可以分成四层采集、检测、告警、行动。第一层是数据采集也是最容易出问题的一层。雷达需要一个参照物这个参照物就是训练基线特征库。我们会在模型训练完成、准备上线时把训练集全量样本的特征抽取出来计算每个特征的分位数、直方图和基础统计量保存成 Parquet 文件。注意这里保存的是特征分布画像不是原始样本。为什么要这样因为原始训练集可能动辄几千万行每次检测都去扫一遍不现实而分布画像已经足够判断漂移程度存储开销还小。线上特征流则是从实时特征存储和消息队列里收集最近一小时或最近一天的样本。收集的时候最怕口径不一致比如训练时某个特征是做过分位数归一化的线上采集时却忘了做同样的变换那雷达测出来的漂移其实是假的。我们后来把特征预处理逻辑统一收敛到一个公共函数库训练和线上共用一套代码这个问题才彻底根治。为了不让检测任务拖垮在线服务采集层还会做抽样和缓存。高流量的特征一小时抽几万条就够了长尾特征则拉到近一天的数据再看。数据落在中间存储里检测引擎只读中间表不直接连线上数据库。2.2 检测引擎三类信号如何并行扫描检测引擎是 PLFM_RADAR 的核心。它会在每个调度周期并行执行三类检测任务我把它们定义成三个检测器单特征漂移检测器对每个监控特征分别计算 PSI、KL 散度、分位数偏移等指标。这一层解决哪个特征变了的问题。特征间关系检测器计算特征之间的相关性矩阵对比基线的相关性矩阵差异同时用树模型的特征重要性快照做对比。这一层解决特征之间的关系变了的问题通常出现在上游特征工程改版、或者两个特征开始互相冗余时。样本质量检测器统计缺失率、常量特征比例、异常值占比、NaN/Inf 数量。这一层解决数据本身坏了的问题很多 P0 告警都是从这里出来的。每一类检测器都会输出一个结构化的信号包含特征名、检测方法、漂移分数、参考阈值、TopK 异常分箱明细。多个信号会写入一个统一的异常结果表后续所有告警规则都从这张表读取。2.3 告警与反馈回路从信号到行动检测引擎产出的信号不会直接变成告警。中间还有一个规则引擎用来做阈值判断、连续窗口确认和告警去重。通过了规则引擎的告警会按照分级策略进入不同的通知渠道。真正的闭环在于告警之后。PLFM_RADAR 会为每次告警生成一个带时间戳的事件便于后续复盘同时预留了 Webhook可以触发自动工单或者重训 pipeline。我们开始时只做到了告警有人看后面才逐步打通告警能触发行动。但这个反馈回路的设计从一开始就保留着因为我知道只报警不行动的监控系统用不了半年就会被团队无视。3. 漂移检测核心算法与代码实现从 PSI 到 KL 散度的落地选型3.1 PSI 的计算逻辑与代码PSIPopulation Stability Index群体稳定性指标是金融风控领域最常用的分布漂检测指标计算逻辑不复杂先把基线特征分成多个区间分箱再对比线上样本落在每个区间的比例最后累加差异的加权对数。这里最关键的是分箱方式。我们用的是基于基线分位数的等频分箱也就是让基线数据在每个箱子里样本量大致相等。如果改成等宽分箱遇到长尾分布的特征比如用户消费金额会出现大量空箱子PSI 结果会失真。下面是我一直在用的 PSI 计算实现import numpy as np def calculate_psi(baseline: np.ndarray, current: np.ndarray, bins: int 10) - float: 计算 PSI分箱边界由基线数据的等频分位数决定。 baseline: 基线特征值数组 current: 线上特征值数组 bins: 分箱数量默认 10 # 1. 基于基线构造分箱边界 edges np.percentile(baseline, np.linspace(0, 100, bins 1)) edges[0] -np.inf edges[-1] np.inf # 2. 对两个分布分别计数 baseline_counts, _ np.histogram(baseline, binsedges) current_counts, _ np.histogram(current, binsedges) # 3. 转成占比并做平滑处理防止除零或取 log(0) baseline_rate baseline_counts / len(baseline) current_rate current_counts / len(current) psi 0.0 for expected, actual in zip(baseline_rate, current_rate): expected max(expected, 1e-6) actual max(actual, 1e-6) psi (actual - expected) * np.log(actual / expected) return psi有两点要提醒一下。第一histogram的边界如果出现重复值比如大量样本等于同一个数导致某些分位数相同需要去重或者加微小抖动否则会报警。第二PSI 值建议按经验分档小于 0.1 表示分布稳定0.1 到 0.25 表示中等漂移需要观察大于 0.25 表示显著漂移应当触发告警。这个阈值不是绝对的后面我会讲怎么用历史数据校准。3.2 KL 散度与 JS 散度什么时候替换 PSIKL 散度是概率论里的经典指标PSI 本质上可以理解为 KL 散度的一种对称推广。但在实际监控中我会在两类场景下用 KL 和 JS 替换 PSI。第一种场景是检测单向退化。KL 散度是非对称的线上分布相对基线某个方向的变化会给出不同分数。如果业务方想单独监控某个年龄段的用户比例是不是大幅掉了KL 能更直接反映这种方向性。第二种场景是比较两个线上窗口。比如对比本周一和上周一的特征分布我们用的是 JS 散度因为 JS 散度是对称的且值域有界不会因为两个分布差异过大而爆炸。from math import log def kl_divergence(p: np.ndarray, q: np.ndarray, eps: float 1e-6) - float: p np.array(p) eps q np.array(q) eps p p / p.sum() q q / q.sum() return np.sum(p * np.log(p / q)) def js_divergence(p: np.ndarray, q: np.ndarray, eps: float 1e-6) - float: p np.array(p) eps q np.array(q) eps p p / p.sum() q q / q.sum() m 0.5 * (p q) return 0.5 * kl_divergence(p, m) 0.5 * kl_divergence(q, m)这里有一个容易被忽略的细节KL 和 JS 都要求输入是概率分布所以必须先做归一化。如果直接拿原始计数算数值会随样本量变化同一个分布样本多的时候就显得漂移大这显然不合理。3.3 更细的信号分位数偏移、均值突变与马丁格尔检验PSI 能发现分布变了但有时候业务方更关心具体指标变了多少比如p50 年龄从 32 岁变成 28 岁这种信息。PLFM_RADAR 里专门加了一个分位数偏移检测器对每个特征额外计算 p5、p25、p50、p75、p95 这五个分位数的绝对偏移和相对偏移。一旦连续两个窗口某个分位数偏移超过 5%就会生成一条特征信号。均值突变则用 EWMA指数加权移动平均来做。EWMA 会给近期数据更高权重适合捕捉缓慢累积的偏移而不是单点抖动。马丁格尔检验是我后来补上的原理不细讲了一句话说就是如果异常信号出现的时间点过于密集累积概率会快速下降说明漂移不是随机抖动而是结构性问题。这几种检测器不是每类特征都全跑一遍那样成本太高。我们的做法是按特征类型做配置连续型特征跑 PSI 分位数偏移 EWMA枚举型特征跑 PSI 分箱贡献分析样本质量类指标单独用阈值规则。分类施策后检测耗时降了一半多召回率反而更稳。4. 部署与告警调优阈值怎么定、误报怎么压4.1 监控任务的调度设计离线批处理 在线准实时PLFM_RADAR 的调度分两条线。高优特征直接影响模型效果的那几十个用小时级任务每小时跑一次延迟控制在 10 分钟以内其余特征用日级任务每天凌晨批量跑一次生成日报式的漂移汇总。调度框架我用过 Airflow也用过轻量的 APScheduler。如果你的团队已经有 Airflow直接在上面挂任务最省事因为重跑机制、日志、依赖管理都是现成的。如果只是为了跑这一套监控没必要引入 Airflow 这种重量级组件APScheduler 加一个结果表就够了。调度设计里最容易被忽略的是窗口重叠。小时级任务如果从当前时间往前推 1 小时那么每次窗口之间的边界会出现重叠或空隙。我们的方案是记录每个窗口的起止时间任务启动时从上次成功结束的位点开始拉取数据保证窗口连续且无重叠。4.2 阈值不是拍脑袋用历史分布反推告警边界PSI 超过 0.25 就告警、KL 超过 0.5 就告警这类经验值只适合初期。上线两个月后我们做了一次阈值校准抽取过去 30 天所有没有造成事故的检测结果计算每个特征 PSI 的 P95 和 P99 分位数把 P99 当作紧急告警阈值P95 当作观察告警阈值。为什么要按特征区分阈值因为特征本身的稳定性差异极大。像 user_age 这种分布相对稳定的特征PSI 超过 0.2 就是大事而某些营销活动相关的特征平时 PSI 就在 0.1 到 0.3 之间来回跳如果统一用 0.25一天能告警几十次。按特征的历史表现个性化设阈值是告警降噪的第一道闸门。还有一个细节阈值校准不是一次性的。每过一段时间线上数据的自然波动会变化我们会用滚动 30 天的窗口自动更新阈值但会加一个上限防止漂移被逐渐吸收。也就是说不能每次漂移告警都觉得是正常波动然后把阈值一直往上调那样雷达就废了。4.3 误报抑制连续确认、告警合并与静默机制阈值调完之后误报还是会有。我们用了三板斧来压制第一板斧是连续 N 个窗口确认。一个特征单次超阈值先不告警只记录观察信号连续 3 个窗口都超阈值才升级为告警。这能滤掉很多短暂抖动代价是告警延迟最多 2-3 小时对大多数场景完全可以接受。第二板斧是告警合并。同一个特征在一小时窗口内同时触发 PSI、分位数偏移和样本质量异常不应该发三条告警应该合成一条列出所有异常类型和诊断信息。告警多了人就会疲这是人性的问题靠技术手段缓解。第三板斧是静默机制。有些特征是跟着业务节奏走的比如大促期间某些特征必然漂移这些时段会提前设置静默窗口不让雷达乱叫。静默不是永久关闭而是带时间范围的过了窗口自动恢复监控。4.4 告警分级与通知渠道告警分级我们参考了故障管理里 P0/P1/P2 的思路定义得很明确级别触发条件通知方式响应要求P0特征缺失率超过 50%、全量 NaN、模型输出全常量电话 短信立即处理P1显著漂移且伴随业务效果下跌风险企业微信/钉钉群15 分钟内响应P2轻度漂移、单项指标超阈值日报汇总当天确认即可这里有个经验P0 对应的更多是数据质量故障不是分布漂移因为分布漂移通常不会让系统整个崩掉但数据坏了是真的会崩。把 P0 留给真正紧急的事告警系统才有公信力。5. 一次真实线上“翻车”复盘PLFM_RADAR 是怎么提前发现的5.1 事故背景CTR 模型在某天夜里出现效果下滑我们有一个信息流广告点击率预估模型线上 A/B 实验显示点击率下降约 15%。业务方发现的时候已经是第二天上午他们第一反应是算法在乱调参但我们很清楚最近一周没有发过新版本。后端日志显示服务一切正常这进一步说明问题大概率出在输入侧也就是特征分布或者特征生产链路。5.2 雷达报警时间线从特征漂移到模型衰减翻 PLFM_RADAR 的告警记录时时间线非常清楚。前一天下午 14:00雷达对 user_age 特征触发了一次 P1 告警PSI 达到 0.31超过了该特征的 P99 阈值。告警详情里直接写着第 4 分箱的占比从基线 19.2% 掉到了 7.8%同时第 6 分箱从 22.5% 涨到了 34.1%。18:00雷达又对 device_model 触发了一次 P1当时我们的值班同学看了一眼觉得设备型号分布偶尔抖动也正常加上 P1 有 15 分钟响应要求他按流程在群里回复了观察中未见业务异动。结果第二天上午业务方的反馈就来了。这一整晚雷达其实一直在记录漂移信号只是没有人把两条告警串联起来看。5.3 根因定位上游特征平台的版本升级排查最终指向了上游特征平台。前一天下午 13:30特征平台发布了一个新版本把 user_age 的缺失值填充策略从按渠道均值填充改成了按全局均值填充。就这一行配置的改动导致大量缺失年龄的用户被填充到同一个值附近分布自然出现断层。device_model 的问题更隐蔽设备型号归一化映射表更新后一批新出的机型被归入了其他类别导致其他类别占比骤增。这本来不是模型的问题但特征分布变了模型输出自然跟着偏。我们当时是怎么快速定位的就是靠雷达告警里附带的 TopK 分箱明细。user_age 第 4 箱大比例流失、第 6 箱大比例涌入这个模式非常像某个上游填充策略变了device_model 的其他类别异常膨胀则明显是枚举映射的问题。如果没有这些明细光靠一个距离阈值相差多少的分数我们至少要多花半天去漫无目的地查。5.4 复盘结论雷达的价值不是替代人而是缩短发现时间这次事故之后我们对 PLFM_RADAR 的定位更清晰了。它不是用来替代人盯指标而是把人发现问题的窗口从业务反馈之后提前到模型效果受影响的同时。这次 14:00 报警业务第二天上午才反馈中间隔了大约 18 个小时。如果能及时响应第一次 P1 告警直接回滚特征平台版本损失的点击量可以少一大截。更关键的是这次复盘把监控告警正式接入了值班流程。以前值班同学只管服务可用性现在特征监控告警也会同步到值班群平台组和算法组都要响应。这算是这套雷达系统真正落地的一个转折点。6. 落地一年后的经验与下一步扩展6.1 最容易踩的坑第一训练基线和线上特征口径不一致。这个问题我前面提过确实是我们踩得最深的一个坑。训练代码和线上采集代码如果分开维护迟早会漂移。建议把特征处理封装成统一模块训练和线上都必须引用同一份代码否则监控出来的漂移分不清是真实漂移还是口径漂移。第二基线更新节奏要克制。起初我们是每周用最新数据更新一次基线结果发现雷达的告警越来越少不是因为系统变好了而是因为基线一直在追着漂移跑。现在我们的策略是基线只在模型重训上线时更新模型上线期间一直用固定的基线这样告警才有意义。第三不要一上来就监控所有特征。几百个特征全量跑 PSI 和 KL计算量大不说阈值校准也会让人崩溃。建议先圈定影响模型效果最大的 30-50 个特征把链路跑通再逐步扩大到其他特征。6.2 下一步与重训 pipeline、特征平台打通PLFM_RADAR 目前已经能做到告警有人看、定位靠明细下一步我想把闭环走完整。具体来说是在告警规则里增加一个可配置的自动重训触发条件某个特征连续 3 个窗口超过紧急阈值且同时段模型效果指标下跌超过 5%自动发起重训任务但重训结果上线前必须经过人工确认。这条链路能显著缩短模型自适应的时间。还有一个方向是和特征平台打通。现在的告警可以定位到特征但还不能自动反查特征的完整生产链路。如果告警直接附带上游任务 ID、产出时间和相关版本信息排查效率还能再上一个台阶。6.3 给自建团队的一些建议如果你所在团队也有类似的模型监控需求我的建议是先有一个简单能跑的版本再逐步完善准确性和闭环。不要一上来就追求大而全先把 PSI 和缺失率监控做出来告警能发到群里就比完全没有强一百倍。其次要记住监控的最终目标是业务效果不是特征分布本身。分布漂移只有在可能导致效果下跌时才值得打扰人否则宁可做日报汇总。最后团队里最好有一个人真正理解这些统计指标背后的含义。工具能算出 PSI但只有人能判断这个漂移是业务正常的季节波动还是真的出了故障。雷达是助手不是决策者这个定位想清楚系统才不会越建越复杂。