5. 模型算法监控体系

绝大多数测试同学可能接触不到这方面的测试,只是为了记录下团队一年的成果,感谢小伙伴们的奋力拼搏!
发现已经写了1万多字了,新起一篇,方便大家阅读

提到模型算法方面的测试,往事浮现,历历在目。
记得商业化大老板跟我们说:“测试的同学能不能把测试工作再做的深入一些?不要局限于广告投放平台UI上面的点点点,而是把模型效果给测一测,因为平台交互的问题只会影响到一部分商户的体验,而模型效果的影响可能是数十万、几百万的用户,我更关心这方面的质量”,大老板非常委婉的Diss了测试,如芒在背。
我们去找模型算法的研发负责人沟通,测试人员有没有能介入的地方,我现在还记得他坐在对面歪着嘴笑(不是贬义,他平时笑起来也是嘴巴歪向一边),看着我们缓缓地摇头,当时的情景下深深的感觉测试被鄙视了,只不过我们没有放弃测试深入化这件事,方法总比困难多。

5.1 业界调研

通过跟研发同学沟通,我们发现研发同学评估新模型的效果会有两种办法,第一种是本地环境离线实验,第二种是线上小流量灰度测试,这两种方法都不需要测试太多的干预。我们在想如果不直接干预测试,还有其他事情能做吗?
老规矩,先去外面看看业界前辈是如何做的,找了一圈我们发现基于模型和算法的测试案例真的寥寥无几。正在我们苦思冥想的时候,我们发现研发每天都会把实验数据录入到wiki中,当作实验日志来记录。突然萌生了一个念头,这种碎片化的数据是不是可以连续跟踪呢?经过跟小伙伴们讨论后发现,我们有一个很重要的事情可以做,那就是“模型监控”

5.2 场景分析

广告引擎系统非常的复杂,不知道是否会涉密,所以我从网上找了个类似的架构图帮助大家理解,实际架构要复杂许多,可以参考刘鹏博士写的《计算广告》中提到的在线广告架构图:

(图片来源于百度)

5.2.1 基本概念分割线

这里稍微科普一下,在线商业广告有很多种类型:

一条广告从创建到召回,再到展示用户面前,会经历一系列复杂的处理,整个过程中都需要测试同学来参与验证,而目前我们对模型算法的测试还是空白,我们来看一下示意图:

召回引擎主要负责广告被召回的逻辑,比如在什么场景下,在什么广告位上,提供什么样的广告类型,并提供广告物料。
算法侧是根据当前的用户画像,计算广告展示策略,比如什么样的广告优先展示,广告的排序队列是怎样的。

广告涉及到的一部分算法类型:

涉及到的部分模型分类:分类模型、聚类模型、回归模型、预测模型……

我们每天要接触的素材是:算法、模型、样本、特征、指标……


言归正传,通过一段时间的沟通和分析,我们对模型训练周期进行了摸排和分解,并对每个环节曾经或可能出现的风险进行分析:

在真正了解到模型算法这块的流程后,我们一度想要放弃,因为难度确实超乎我们的想象,场景比我们想的要复杂。
由于算法模型的黑盒性、难解释性,不再是我们过去测试的true 或 false的情况,业界能借鉴的案例也极少。除此之外,还有一些坑等着我们跳:

5.3 测试体系

附上我们整体的测试体系和过程。

模型算法方面的测试我们划分为“生产环境”“测试环境”两套。针对生产环境,模型从生产到上线大抵可以划分为六个环节:

  1. 数据来源
  2. 特征提取
  3. 离线训练
  4. 模型Build
  5. 发布上线
  6. 实时预估

生产环境中,我们在这上面六大环节中分别做了各种定制化的监控,从而实现“全链路”的数据跟踪,同时也把所有能获取到的过程指标数据全部拿到,然后根据大数据的计算进行统计,把数据结果通过平台化的方式展现出来,提供研发人员进行问题追踪排查,同时也可以辅助算法工程师进行模型调优,最令人兴奋的是,我们的做法吸引了很多算法工程师前来,提出了大量的定制化数据需求,从而商定了很多监控报警和流程卡点机制。
测试环境上,我们搭建了一套完全模拟线上的仿真测试环境,通过流量回放技术,把线上数据引流到线下,对即将上线的新模型进行检测,查看各项指标的表现,从而预判能否发布到线上,在这个环节我们也增加了自动干预的卡点,如果出现较大的指标波动,我们就自动拦截上线。

5.4 数据监控

数据监控机制形成了四种分类:

上述四类,前面两类是跟模型算法内容相关的监控,而后面两类属于出于质量设计而扩展出来的能力。我们以样本特征和模型内容为例,在我们的监控环节里,需要采集到的指标有:

上图中,左侧是我们梳理和要监控的指标内容,右侧是我们需要根据这些数据提供查询的维度,其实是平台化后衍生出来的用户需求。实际上我们前后针对13个模型整理出来了44种监控指标,并且算法工程师们还在不断的增加新的指标,紧接着我们就面临了第二个挑战:大数据计算
前面有提到,某个模型的样本数据大约是5亿条,每个样本的特征项可能会有近百种。举个例子:某个用户的手机IMEI号作为其唯一的样本,对应的特征数据会有100多种,那么测试在做样本训练的时候,会遇到计算的性能问题,我们最初进行一次样本训练需要8个小时,而研发人员对样本训练的时效性要求又非常高,迫使我们不得不去解决这个问题。比如说:

诸如此类的问题还有很多,都是需要我们去排查和解决的,通过小伙伴们不懈的努力,我们把样本训练的时间从8小时减少到1小时,最终目前可以压缩到20分钟内完成。
另外尽管我们对样本数据进行了top N的筛选,但是结果数据依然非常复杂,因为我们需要用堆叠图来展示,对前端性能要求很高,见下图:

5.5 效果评估

在上面流程里,我们不止是对模型的过程进行监控,还需要兼顾效果评估类的工作,目前我们完成的事务可分为下面几大类:

基于需求,我们需要支持几个维度的数据对比,将平台能力提升到了一个新的复杂程度:

5.6 基础质量

关于基础质量,前面有提到,是我们围绕着模型算法测试干预的探索过程中,衍生出来的基于质量的行为。
这个是有惨痛的教训的,曾经发生过一个线上事故,因为上游某个特征数据推送出现问题,采用了默认的内容,从而导致了线上大面积的计算错误,虽然在数分钟内就发现了该问题,但是也产生了巨量的收入损失。
因此我们针对这种情况补充了几件事:

对于上游依赖的数据,我们会做全流程的监控,主要监控其变化异常,比如某个模型在进行训练的时候需要依赖的样本集大小,不能跟上个版本发生较大偏差,对于偏差量我们会配置一个阈值来进行监控,另外会根据样本文件的更新时间进行记录,从而避免使用默认文件的情况发生。模型生产过程也是同样的道理,只是监控的范围更大,维度更多,譬如下图中当文件出现不一致的时候发生的监控报警:

5.7 平台化

关于平台化的需求,其实是用户提出来的,也就是我们的算法工程师们,他们期望平台能够提供几个方面的支持:

目前系统功能已经越来越多,不能一一截图,下图是系统的一小部分截图:

5.8 模型监控带来的收益

这部分内容相信是大家最为关心的,就是做了那么多事情,到底有哪些可预期的收益?我们从监控平台上线以来,做了一次线上事故的对比:

在回顾全年的效果时,我们发现这种做法是非常有效果的,得到了业务方的高度认可。以至于后来我们支持的算法工程师调到别的项目去的时候,第一时间就把这套监控方案引入到项目中去。最值得高兴的是我们不但得到了业务方的认可,还给其他业务线带来了帮助,甚至有个业务线上线第一天就发现了2个有效问题,直接影响了收入的提升。

6. 团队取得的落地效果

最后,请允许我用团队述职报告里面的一部分内容来总结一下我们团队2019年的组织产出(求大佬们轻喷 😫😫 ):

之前规划的完成情况

7. 未来规划

新的一年,团队遭遇了重大的组织结构调整,之前规划的事情可能会面临很大的修改,这里暂时就贴一张图。
不论怎么样,我们都会秉承“专业、支撑、开放”的精神持续的奋斗下去,打造一支持续创新,锐意进取,努力拼搏的团队。


↙↙↙阅读原文可查看相关链接,并与作者交流