AI首席测试架构师 孙高飞：《机器学习服务的测试实践》

9月15日FMI-2018人工智能与大数据高峰论坛圆满落幕,AI测试架构师孙高飞就机器学习服务的测试实践进行了深入的分享。

AI测试架构师孙高飞

飞马网将其内容整理如下：

大家好，我叫孙高飞，目前在一家AI公司就职测试开发工程师，主要的职责是测试我们公司自研的机器学习平台，我们在日常的工作中总结出来一些测试的方法和策略，今天想跟大家分享一下。

我们先来讲一下什么是人工智能，不严谨的说，现阶段实现人工智能最好的方式就是机器学习+大数据，为什么说是现阶段的？因为根据人类科技不断的进步，我们实现人工智能的方式是有变化的，比如在上世纪六七十年代的时候，我们普遍认为实现人工智能最好的方式是专家系统。

机器学习我们发现他在某些方面不仅可以达到人类的数据，甚至远远超出人类的水平，随着这几年大数据的发展，我们的深度学习也随之而崛起，之所以在大数据的发展之下深度学习崛起，因为我们之前所有的模型训练，机器学习的应用都受限于数据量的大小而限制了他的效果，像以前有些教科书会说我们在神经网络中最好不要把神经网络的层数设置为超过三层以上，就是因为之前我们的数据量和计算能力都足以支撑复杂的神经网络，之前数据比较小，在实验室中我们在网上下载的数据可能是几万条，在这种数据量的情况下用一个比较深的神经网络基本上够用了。随着大数据的来临和对机器学习算法的研究，把机器学习的应用带到前所未有的高度。这也是我们为什么说现在这个阶段，我们实现人工智能最好的方式是这种方式，也许过了几十年或者一百年以后，人类又发展出了更好的方式实现人工智能。

所以说对于机器学习人工智能和深度学习来说，他的关系差不多是这个样子的。机器学习是人工智能的一种实现方式，而深度学习是机器学习的分支。

再接下来我们可以讲一下什么是机器学习，用一个之前给银行做的反欺诈场景的项目为例子讲一下。什么是银行反欺诈，以前银行中有一批业务专家，他们的工作是向系统中输入一些规则，如果系统发现一个人在一个城市中用信用卡刷了一笔交易，但是在一个小时之内又在另外一个城市内刷了一笔交易，这时候根据人的经验判断这是有盗刷风险的，因为一个小时内跨一个城市的行为不会出现，专家会制订规则，向系统中输入几千条规则组成专家系统，专家系统是根据人的经验总结而来实现反欺诈的目的，但是这样的专家系统有局限，它的效果没有那么好，因为人的计算能力和分析能力都有局限，在一个系统中没有任何规格的时候，我们创建一条规格比较容易，但是系统中有大量前提下再创建新的规格很难，我们要保证新规格有效的同时，还要保障不跟之前的规格冲突，这是很难的事情。

我听说的最大的专家系统是当时百度凤巢的专家系统，他们有一万条左右专家规则，有一个将近50人的团队维护这些规则，当时他们所有人的力量都没有办法向系统中添加任何一个规则，人的分析能力达到极限，我们当时面对这个问题之后开始寻找更好的思路能够生成更多更复杂的规则帮助我们实现更好的效果。这个思路就是机器学习。

为什么我们叫机器学习？因为它也能够像人一样，它给人的感觉是这样的，它像人一样从过去的数据中总结出一些规律，制定出一些规定，他也能够像人一样向系统中定制很多规则，只不过它的规则更细致更复杂。

据我从凤巢出来的同学说，他们在2011年引入机器学习，从一万条规则扩展到几十亿还是几百亿，他们当年的凤巢广告营收的收益比往年提升了四倍，我们是把专家系统看成一个大脑，但它是比较小的大脑，他能处理的东西比较有局限性，我们把机器学习看成一个比较大的大脑，它能做的事情更多更好更复杂。

机器学习虽然现在已经崛起了，它被认定为比专家系统拥有更良好的性能，但是也有一些局限，这些局限我之后会慢慢的说。

说完了什么是机器学习，我们再说一下什么是模型，因为我们知道在机器学习中，经过训练之后会产生一个模型，这个模型是什么，尤其是之后在测试的时候，大部分时间围绕模型进行侧我们要先弄明白模型是什么，所以我们继续不严谨的说，模型我们看成一个数据库，这个数据库里存的就是所有的规则和他对应的权重。实际上在我们模型上线之后，很多算法都是这样的，一条条的数据过来之后，我们会把新的数据输入到模型中，查找新的数据匹配模型中哪些规则，把这些对应的规则和权重拿出来，然后进行累加，返回一个预测值，这就是机器学习最终提供的能力，提供一个预测的能力，所以我们可以把机器学习训练出的模型当成一个数据库。

接着问题就来了，我们如何测试这个模型。模型是用机器学习算法在比较大的情况下训练出来的，所以我们也需要在比较大量测试数据的情况下输入给模型，让模型预测，然后我们去预测这个模型他的一些诸如准确率的指标评估模型效果的好坏，在模型测试领域里基本上不会体积模型有没有什么Bug，我们基本上说这个模型好或者不好，这个模型好或者不好的因素有很多，有时候是数据选取的不对，有的可能是训练的时候参数调整的不太合适，我们不会以Bug的形式说这个模型有问题，只是这个模型的效果是不是达到我们的预期。

接下来讲一下模型的评估指标，先从二分类模型说，因为二分类模型从我们商业领域来说应用的最多的一种，而且它的模型评估指标是最复杂的，我们把它说清楚之后再讲多分类和回归模型比较容易，一般来说二分类模型有很多，我就讲主要的，主要的可能就这几种，混淆矩阵，ROC、AUC，召回、精准。

刚才基本上讲完了常用的模型评估指标，但是讲这些指标的重点不在这里，刚才说的所有东西在网上找论文都可以看到，这些指标计算公式都可以查到，最重要的是如何抽取我们的测试数据，因为测试数据才是真正决定我们这次测试本身的指标，我们在业界经常有一句话，一份数据的重要性，一个数据的质量决定了模型效果的上限，而我们调整算法的参数只是为了这个模型尽量逼近这个上限，真正决定这个上限的是数据，数据出现了误差，会出现什么后果。

在我们日常对于模型的测试中，我们对数据也特别看重，首先使用真实的数据，这个可能大家都理解，因为最真实的数据符合最真实的业务场景，但是有时候我们可能没有办法使用真实的数据。

我们在很多开源算法库里都有这种方式，比如他有预处理模块，有图片反转的东西都可以拿来利用，所以我们第一个原则，尽量使用真实数据，如果真实数据实在不能用，就可以用其他手段人工造一些我们需要的数据。第二，注意特征呈现时序性，我们数据中的特征随着时间出现剧变。比如推演系统怎么建模的，一般来说推演系统的AUC不会超过0.8，以前做图象识别都有过AUC特别高的情况，我们给龙泉寺做古经识别AUC达到98%多，我们推演系统预测的是人点击这个广告的概率，人点击一个广告的概率是很随性的，有时候今天心情好点一下，心情不好就不点，或者我这个人万年不点，什么广告都不点。在这种场景下，人点击广告的行为并没有过多的逻辑性可以推测，所以他的AUC比较低，不会超过0.8，一般我们自己建模的时候超过0.8可能是数据穿越了。

所以我们的建模工程师为了能解决这个问题做了一个决定，高度定制化，他们抽取特征的时候有时候对广告的ID做抽取，比如我们有一千万个用户，就有一千万个特征，我们有一亿个广告，我们对广告进行抽取就有一亿的特征出来，我们让我们模型对每一个用户做了拟合，让这个模型记录每一个用户的喜好，甚至每一个广告对应的不同的用户画像的人群都有一个刻画。这样我们的模型就有高度的定制化能力。但是这样的模型有一个特点，什么特点？我们发现这种场景很像是我们在建模中出现的异常，过拟合。我刚才一开始说的在数据量比较小的情况下，我们深度学习的算法会出现过拟合的情况，因为数据量比较小，网络比较复杂，函数比较大，在于训练级效果特别好，但是测试级效果非常差，因为我们忽略了真实场景。

我们在推荐系统里为了达到这个目的做了一个热点的模型，他就会出现一个特点，他不会很好的拟合时间久远的数据。我们每天有新的用户出来，新的用户没有拟合到模型中，我们还有新的广告，甚至在做视频推荐的时候，我们的特征抽取方式对视频的标题做切词处理，对每一个词做一个特征处理，我的模型会得到一个热点词的效果，但是随着时间的推移，今天这个词是热点，到了明天就不是热点了，这个模型在这个情况下引入高频的自学习，使用最新的数据不断更新模型，让模型达到一个热点的效果。在测试这种模型的时候我们一定要注意测试数据的时间，首先要清楚我们训练的数据是什么时间段，我们不能取训练数据时间段之前的，那相当于用之前数据预测过去的数据，我们一定要取未来的数据，如果只是紧接着训练数据是今天的，我不能拿今天的数据紧接着做，因为模型迭代是有时间的，自学习有迭代效率，可能要几个小时时间将模型更新完，我们选取测试数据的时间片段，首先要知道训练数据的时间，然后再知道自学习迭代时间是多少，然后在这段时间之后测试数据，做在这个场景下的一个测试数据的采集，这才是比较符合我们真实的情况。

以前我跟其他同行聊天的时候，很多他们在做这种模型的效果评估都把这个忽略了，测试的时间不是很正确，所以出现模型评估效果不是特别好的地方，还有特征随字段呈现不均匀分布，这个东西跟我们讲的分组AUC结合来做，从训练角度来讲，我们希望我们的训练数据中包含所有数据类型，所有的用户类型。有时候发现这么一种情况，我们在处理数据的时候某一个数据类型数据量不足够，比如跟之前的项目合作，他们抽取数据方式就是在线上随机抽取，这样出现一个问题，他们的数据分布不是很均匀。比如我们给脉脉做的模型，他们的分布肯定是用户职业，如果用随机抽取或者线上按时间段抽取会发生一个问题，如果我们点子不好会造成严重的数据倾斜，数据倾斜会造成某一个职业的数据不太够，这个结果会造成，假如说训练的数据这个职业的数据不够会造成模型拟合这部分的用户效果不好，如果我们测试数据抽取的时候，这份数据抽取的比较少，也会造成测试的评估效果不够权威，因为过小的数据量没有评估的价值。

所以说我们一般都会根据业务的规则确定不同的数据要怎样按照每一个分段进行随机抽取。这是我们数据采集的一个注意事项，接下来我们还会讲一些基于业务场景的测试，比如自学习，数据流和结合外围的方法。

我们先说自学习，刚才推荐系统的时候说过我们的模型有热点能力，为了能够让我们用最新的数据更新模型，让模型保持它的时效性，而不会因为随着时间的流失变成一个过拟合的场景，所以我们用高频的自学习来阶段性的更新模型。自学习的原理特别简单，我们用N天数据训练出模型，到新一天之后把新的数据加进来，把最老的数据抛出，训练出新的模型更新代替老的模型上线，这是我们自学习的一个原理，到这儿也许有朋友问为什么把老的数据删除，如果我们用FGD算法他可以实时训练建模，那个时候不会把老数据干掉，在数据来了之后直接训练一下，直接更新到里面，所以作为流式计算他不会删老数据，但是自学习为什么要删老数据，原因很简单，因为我们建模的方式，我们特征抽取的方式就是过拟合的，就是属于很有时效性的，老数据已经过了时效性了，如果把它再加到模型训练中就会有问题，首先他的效果有问题，再一个是数据越来越大，你的训练迭代速度也越来越慢，这个时候会出现问题，对于自学习来说，迭代的速度是非常重要的，因为我们刚才也说了模型有时效性，随着时间的推移，模型的效果越来越差，如果我们自学习迭代速度越快，更新模型速度越快，模型在线上效果越好，对于自学习来说，迭代速度很重要，很多时候拼的就是速度。

曾经我们公司里专门有一个关于自学习迭代速度的讨论，专门讲如何提升迭代速度，有了自学习之后发现一个问题，自学习是自动化的，他自动采集数据，自动模型更新，我们必须要在自学习更新模型上线的时候有一个良好的质量保证的过程，模型上线是很严肃的，一个模型出现问题造成损失非常大。所以我们要有一个比较完善的数据流，从数据采集一直到最后的模型更新上线到监控，都有一个数据闭环的过程，这个过程有数据模型的采集测试，就是这样的。首先有一个数据测试，先有一个数据采集系统，每天甚至迭代的频率更高，甚至每隔几个小时采集一次，采集到系统中，回流到数据里，一般将数据进行模型训练，这个时候发现一点，这些数据并没有经过测试，数据也有一定概率出现异常，虽然在自学习中我们用的模型训练的算法参数跟线下一致，如果我们线下进行测试了，这是没有问题的，但是我们并不能保证数据没有问题，有时候数据出现异常，所以这个时候第一件要做的事情是这样的。数据运行，每一天的数据，从数据采集系统采集到分布式系统上之后，我们要采集分布式技术扫描这些数据，我们公司常用的是Star（音），我们扫描这些字段，根据业务场景制订一些规则，扫描有没有异常的数据，有没有异常的分布，我们经常统计这些数据分布，比如用户的类型分布是什么样子的产品类型分别是什么样子的，商品类型分布是什么样子的。看看分布有没有异常，通常也会拿新的数据分布之后跟老数据对比，看看有没有用户行为异常，当然在这个时候这个目的不仅仅是测试了，也有数据分析目的，一旦这些数据出了异常，不管这个异常是预期的行为，还是用户发生了诡异的事情，或者数据采集系统发生了Bug，我们都要通知到建模科学家，让他们判断，这个数据加入自学习系统中是否合适，当然也有一些常见的符合预期的数据分布，比如我们遇到什么节日，或者政府发布了哪些法令，或者社会上出现了什么热点新闻，都有可能造成数据的分布异常。

比如卖商品的网站突然发现某一天玫瑰花产品销量激增，可能是碰上情人节了。这个时候用户行为有一个特性，一旦这个节日过去了，你的用户行为立刻恢复正常，比如快到情人节了，前一周开始玫瑰销量已经飙升了，但是一旦过了情人节销量直接断崖式的下来了。出现了因为某种情况导致数据分布的异常都要通知到建模科学家他们自己判断什么时候把数据加入到系统中什么时候不需要加入。这是数据预警功能，我们的数据已经经过测试了，数据经过测试之后可以加入自学习模型训练中，自学习模型训练跟线下模型训练一样，他也会统计模型评估指标，这里面有一些策略，我们要求AUC达到多少以上，我们才允许自学习生成的模型更新到线上。这方面模型评估指标我不说了。我们看下一个A/BTest，模型是非常严肃的不能出问题的，我们如果直接把模型替换上去，会有很大的风险，所以我们倾向于A/BTest的模式，我们同时上线两个模型，一个老模型一个新模型，把流量分发到这两个模型上，比较线上真实流量下两个模型效果对比，如果我们证明了在A/BTest情况下新模型优于老模型，我们是可以把模型更新上去的。这种更新策略也是有不同的方式，根据不同的情况有不同的策略。

在经过A/BTest之后老的模型完成历史使命可以下架了，新的模型产生新的价值，这里还有一个监控，我们一定要对线上模型进行监控，起码监控每日AUC多少，线上是，尤其是线上时时训练里更需要监控的机制，因为我们可以看到在迭代速度比较慢的情况下，不管是线上迭代或者自学习迭代，我们可以通过数据测试、A/BTest都可以进行测试，这是线上计算，可能一小时数据来了训练一次，或者32个小时数据做一次熟练，训练完后直接到服务上，所以监控很重要，要监控当前AUC多少，这样才能实时调整线下模型，经过模型上线之后，我们新的数据过来产生新的价值，新的数据继续回流到数据采集系统里，再继续做数据预警，形成数据闭环，有时候评价一个公司是否有人工智能能力的时候要看有没有数据闭环的能力，一旦有数据闭环，他就建立起了一个数据上的壁垒。

这个时候我们认为拥有这个能力的公司是拥有人工智能智能能力的重要的评价指标。在数据回流的时候，我也说了线上有Level（音）的功能，这个根据不同业务场景有不同的情况，有些情况数据回流完全自动化，比如我们的推荐系统完全自动化，用户点击之后我们可以拼回来，也有些没有办法拼，比如银行反欺诈，他没有办法自动做这个事情，所以他们每周或者每个月人工的拼Level，把数据回到采集系统里，这是数据闭环场景下要做的测试，A/BTest和监控。

接下来还有预测值的测试，这是经常发生在模型和系统打交道时候的事情，推荐系统特征抽取的方式和建模方式，但是推荐系统并不是一个典型的二分类的问题，只不过我们把解决推荐系统的方式转化成二分类处理。我们在模型做训练的时候做的是预测用户点击的概率是多少，我们的目标值就是他是否为点击，所以我们把推荐系统的场景慢慢转换成二分类场景做，但是我们的模型出来之后，到了外围系统里可能没有什么阈值了，刚才我们说评价模型评估指标的时候，混淆矩阵在阈值情况下做，但是对于推断系统来说，他并不希望你告诉他这个用户是不是有点击，他只希望你告诉他这个用户点击的概率是多少。这样他的玩法就不一样了，模型不会告诉用户会点击，反而告诉他概率是多少。

假如我有一个用户，有两千份数据推荐广告的侯选值，我们分别把这个用户的数据和广告的数据输入到模型中，让他预测，把预测值做一个排序，取Top10，把这Top10的广告输出给用户，大部分情况下没有阈值，这个时候问题来了，没有阈值，他的要求，完全是给我用户点击的概率，如果用户点击的概率一直在下降，比如说我们的模型出现了什么问题，我们计算出来的概率一直在下降，他只把Top10推荐给用户，用户点击概率越来越下降了，这个模型或者数据出现了什么问题，但是推荐系统无法感知，他判断不出来，所以这个时候我们都会做一个预测，我们的新的数据进行测试的时候要统计预测值的分布，看一下跟以前的分布是否一致，或者误差比较小，如果出现了预测值断崖式的下降，我们一定会找出为什么出现这种行为。

接下来是一开始说的对于专家系统，我们并没有淘汰的，在很多做反欺诈系统的时候都是专家系统和决策引擎一起使用，为什么机器学习之后还使用专家系统，因为银行历史上曾经出现数次黑天鹅事件，这些事件有一些特点，它的发生概率很小，一旦发生了对银行造成非常大的损失，这些黑天鹅事件不允许再出现，一定要防止，这个场景给机器学习来说有一个问题，机器学习是从历史中寻找规律的算法，你给他的数据越多，它的效果越好，那问题来了，黑天鹅事件的数量非常小，小到了完全可以淹没在庞大的训练数据中。这个时候机器学习训练出来的模型对于黑天鹅事件模型不好。就像分组AUC一样，黑天鹅事件分组下数据量太小，机器学习无法达到很好的性能，这个时候采用专家系统人为制订规则防止黑天鹅事件发生，跟机器学习一起配合的制订我们反欺诈系统的性能。

所以说在这个时候我们要测的不仅仅是机器学习，而是把机器学习和专家系统联合起来做，一般产品中做这么一个系统会有决策引擎，这个决策引擎是决定什么情况下使用机器学习模型，什么情况下使用专家系统，我们要测试的是决策引擎和模型还有专家系统三个合起来一块进行测试，当然测试的方式跟以前一样，还是统计那些指标，因为他们解决的业务场景一样。

接下来过一下性能测试的东西。算法和性能测试跟互联网高并发测试有什么不一样的地方，首先算法性能没有高并发，他就是调用分布式系统，让分布式处理，所以对算法来说，数据是最重要的。有时候说大数据时代到来了，深度学习到了高峰期的时候要做高维特征，有高维能力，客户说这个算法都是高维的，我们高低能处理多少高维，十亿特征情况下我们的算法性能是什么样子的。假如说是十亿特征的数据，这种高维场景，我们要给客户提供一份比较详细的性能报告，这个性能报告详实的展示着在不同数据类型不同数据规模和不同数据分布下我们算法性能是什么样子的。

这个测试数据的采集跟我们刚才说的尽量使用真实数据是完全不一样的，在做性能测试的时候一定不能用真实数据的，因为真实数据无法控制数据分布，比如我要求测试数据在一亿行一百列的情况下，这个数据不可能有这么规整的数据分布给我们使用。我们公司内部孵化出了一个造数的项目，这个项目是专门用来给各种各样的场景造要求严格的数据分布下的数据。它的原理特别简单，我们跟PIsbark（音）合作，它在数据系统上生成数据有两种方式，一种从已有中读取，一种从列表中创建，还有一个特性，它可以用生成器的方式，不占用内存的方式生成这些数据，所以我们制订了这么一个项目，制作了一个工具，这个项目专门提供一些可视化的配置，这些配置可以让用户选，我的列数是一百列，前十列是中文随机数据，要求他抽出多少的特征，要求他的字段长度是多少，这样通过这种方式就能够创造出符合企业级的性能测试标准的数据出来，在固定的资源下验证这些算法处理不同数据时候的性能是什么，因为在分布式的情况下对大数据小数据处理方式不一样。在高维情况下放在分布式情况下比较快，假如有些场景就是低维的处理，你还用高维的分布式的处理方式处理肯定非常慢，肯定不如存在数据库里快，我们都要在不同的维度下，不同的数据下给用户提供性能测试报告，来证明我们拥有比较良好的算法的性能，这是我们性能测试需要注意的点。我今天的分享就到这儿了，谢谢大家。