（图片来源于百度）
绝大多数测试同学可能接触不到这方面的测试，只是为了记录下团队一年的成果，感谢小伙伴们的奋力拼搏！
发现已经写了 1 万多字了，新起一篇，方便大家阅读
提到模型算法方面的测试，往事浮现，历历在目。
记得商业化大老板跟我们说：“测试的同学能不能把测试工作再做的深入一些？不要局限于广告投放平台 UI 上面的点点点，而是把模型效果给测一测，因为平台交互的问题只会影响到一部分商户的体验，而模型效果的影响可能是数十万、几百万的用户，我更关心这方面的质量”，大老板非常委婉的 Diss 了测试，如芒在背。
我们去找模型算法的研发负责人沟通，测试人员有没有能介入的地方，我现在还记得他坐在对面歪着嘴笑（不是贬义，他平时笑起来也是嘴巴歪向一边），看着我们缓缓地摇头，当时的情景下深深的感觉测试被鄙视了，只不过我们没有放弃测试深入化这件事，方法总比困难多。
通过跟研发同学沟通，我们发现研发同学评估新模型的效果会有两种办法，第一种是本地环境离线实验，第二种是线上小流量灰度测试，这两种方法都不需要测试太多的干预。我们在想如果不直接干预测试，还有其他事情能做吗？
老规矩，先去外面看看业界前辈是如何做的，找了一圈我们发现基于模型和算法的测试案例真的寥寥无几。正在我们苦思冥想的时候，我们发现研发每天都会把实验数据录入到 wiki 中，当作实验日志来记录。突然萌生了一个念头，这种碎片化的数据是不是可以连续跟踪呢？经过跟小伙伴们讨论后发现，我们有一个很重要的事情可以做，那就是“模型监控”！
广告引擎系统非常的复杂，不知道是否会涉密，所以我从网上找了个类似的架构图帮助大家理解，实际架构要复杂许多，可以参考刘鹏博士写的《计算广告》中提到的在线广告架构图：
（图片来源于百度）
这里稍微科普一下，在线商业广告有很多种类型：
一条广告从创建到召回，再到展示用户面前，会经历一系列复杂的处理，整个过程中都需要测试同学来参与验证，而目前我们对模型算法的测试还是空白，我们来看一下示意图：
召回引擎主要负责广告被召回的逻辑，比如在什么场景下，在什么广告位上，提供什么样的广告类型，并提供广告物料。
算法侧是根据当前的用户画像，计算广告展示策略，比如什么样的广告优先展示，广告的排序队列是怎样的。
广告涉及到的一部分算法类型：
涉及到的部分模型分类：分类模型、聚类模型、回归模型、预测模型……
我们每天要接触的素材是：算法、模型、样本、特征、指标……
言归正传，通过一段时间的沟通和分析，我们对模型训练周期进行了摸排和分解，并对每个环节曾经或可能出现的风险进行分析：
在真正了解到模型算法这块的流程后，我们一度想要放弃，因为难度确实超乎我们的想象，场景比我们想的要复杂。
由于算法模型的黑盒性、难解释性，不再是我们过去测试的 true 或 false 的情况，业界能借鉴的案例也极少。除此之外，还有一些坑等着我们跳：
附上我们整体的测试体系和过程。
模型算法方面的测试我们划分为“生产环境”和“测试环境”两套。针对生产环境，模型从生产到上线大抵可以划分为六个环节：
生产环境中，我们在这上面六大环节中分别做了各种定制化的监控，从而实现 “全链路” 的数据跟踪，同时也把所有能获取到的过程指标数据全部拿到，然后根据大数据的计算进行统计，把数据结果通过平台化的方式展现出来，提供研发人员进行问题追踪排查，同时也可以辅助算法工程师进行模型调优，最令人兴奋的是，我们的做法吸引了很多算法工程师前来，提出了大量的定制化数据需求，从而商定了很多监控报警和流程卡点机制。
测试环境上，我们搭建了一套完全模拟线上的仿真测试环境，通过流量回放技术，把线上数据引流到线下，对即将上线的新模型进行检测，查看各项指标的表现，从而预判能否发布到线上，在这个环节我们也增加了自动干预的卡点，如果出现较大的指标波动，我们就自动拦截上线。
数据监控机制形成了四种分类：
上述四类，前面两类是跟模型算法内容相关的监控，而后面两类属于出于质量设计而扩展出来的能力。我们以样本特征和模型内容为例，在我们的监控环节里，需要采集到的指标有：
上图中，左侧是我们梳理和要监控的指标内容，右侧是我们需要根据这些数据提供查询的维度，其实是平台化后衍生出来的用户需求。实际上我们前后针对 13 个模型整理出来了 44 种监控指标，并且算法工程师们还在不断的增加新的指标，紧接着我们就面临了第二个挑战：大数据计算。
前面有提到，某个模型的样本数据大约是 5 亿条，每个样本的特征项可能会有近百种。举个例子：某个用户的手机 IMEI 号作为其唯一的样本，对应的特征数据会有 100 多种，那么测试在做样本训练的时候，会遇到计算的性能问题，我们最初进行一次样本训练需要 8 个小时，而研发人员对样本训练的时效性要求又非常高，迫使我们不得不去解决这个问题。比如说：
诸如此类的问题还有很多，都是需要我们去排查和解决的，通过小伙伴们不懈的努力，我们把样本训练的时间从 8 小时减少到 1 小时，最终目前可以压缩到 20 分钟内完成。
另外尽管我们对样本数据进行了 top N 的筛选，但是结果数据依然非常复杂，因为我们需要用堆叠图来展示，对前端性能要求很高，见下图：
在上面流程里，我们不止是对模型的过程进行监控，还需要兼顾效果评估类的工作，目前我们完成的事务可分为下面几大类：
基于需求，我们需要支持几个维度的数据对比，将平台能力提升到了一个新的复杂程度：
关于基础质量，前面有提到，是我们围绕着模型算法测试干预的探索过程中，衍生出来的基于质量的行为。
这个是有惨痛的教训的，曾经发生过一个线上事故，因为上游某个特征数据推送出现问题，采用了默认的内容，从而导致了线上大面积的计算错误，虽然在数分钟内就发现了该问题，但是也产生了巨量的收入损失。
因此我们针对这种情况补充了几件事：
对于上游依赖的数据，我们会做全流程的监控，主要监控其变化异常，比如某个模型在进行训练的时候需要依赖的样本集大小，不能跟上个版本发生较大偏差，对于偏差量我们会配置一个阈值来进行监控，另外会根据样本文件的更新时间进行记录，从而避免使用默认文件的情况发生。模型生产过程也是同样的道理，只是监控的范围更大，维度更多，譬如下图中当文件出现不一致的时候发生的监控报警：
关于平台化的需求，其实是用户提出来的，也就是我们的算法工程师们，他们期望平台能够提供几个方面的支持：
目前系统功能已经越来越多，不能一一截图，下图是系统的一小部分截图：
这部分内容相信是大家最为关心的，就是做了那么多事情，到底有哪些可预期的收益？我们从监控平台上线以来，做了一次线上事故的对比：
在回顾全年的效果时，我们发现这种做法是非常有效果的，得到了业务方的高度认可。以至于后来我们支持的算法工程师调到别的项目去的时候，第一时间就把这套监控方案引入到项目中去。最值得高兴的是我们不但得到了业务方的认可，还给其他业务线带来了帮助，甚至有个业务线上线第一天就发现了 2 个有效问题，直接影响了收入的提升。
最后，请允许我用团队述职报告里面的一部分内容来总结一下我们团队 2019 年的组织产出（求大佬们轻喷 
）：
移动广告业务从优化 CI、CT、CD 流程，到精准测试的研发，再到线上监控一整套解决方案的落地，把移动广告整体事故损失从去年的 XXX 多万降至 XXX 万，减少 54%。
新的一年，团队遭遇了重大的组织结构调整，之前规划的事情可能会面临很大的修改，这里暂时就贴一张图。
不论怎么样，我们都会秉承“专业、支撑、开放”的精神持续的奋斗下去，打造一支持续创新，锐意进取，努力拼搏的团队。
