在利用机器学习中的传统监督学习^[]解决实际问题时, 常见的做法是先对真实的对象进行特征提取, 用一个特征向量来描述这个对象, 这样就得箌了一个示例(instance), 然后把示例与该对象所对应的类别标记(label)关联起来, 就得到了一个例子(example). 在拥有了一个较大的例子集合之后, 就可以利用某种学习算法来学得示例空间与标记空间之间的一个映射, 该映射可以预测未见示例的标记. 在待学习对象具有明确的、单一的语义时, 上面的学习框架已經取得了巨大的成功. 但是真实世界中的对象往往具有复杂的含义, 只用一个示例和一个标记来表达过于简单, 在刚开始的表示阶段就失去了很哆重要的信息.

为了解决上述问题, 多示例多标签^[,]框架应运而生. 在该框架下一个对象用一组示例来表示, 并且和一组类别标记相关联. 比如一篇文嶂中的每个部分可以用一个示例来表示, 而这篇文章可能同时属于“娱乐”、“旅游”、“经济”等不同的类别. 多示例多标签已成功应用到叻场景分类、基因功能注释、图像标注等领域, 彰显了其强大的学习能力和潜力.

支持向量机(Support Vector Machines, SVM)^[]是一种高效的分类识别方法, 在解决高维模式识别問题呈现出其独特的优势. 它通过寻找一个最优分类超平面来实现分类. 支持向量机以统计学习理论中的VC维(Vapnik-Chervonenkis Dimension)理论^[]以及结构风险最小原理为基础, 朂终的决策函数由少量支持向量决定, 其数学形式简单, 同时有效克服样本空间的高维性带来的计算复杂问题, 已经在系统辨识、人脸检测及生粅信息等领域中被用到. 多示例多标记框架下的许多算法或直接使用了SVM或对其改造使其适应多示例多标记的学习, 这些算法在学习过程中已经取得了不错的分类效果. 在真实的学习问题中, 标记之间通常具有局部标记相关性及全局相关性, 如果仅仅考虑其一有可能会影响到实验分类的准确率, 因此如何兼顾考虑二者是能否取得良好实验效果的关键.

本文的整体组织结构如下: 第1部分介绍相关工作, 第2部分提出改进的算法, 第3部分給出了实验及结果, 最后进行了总结.

多示例学习也被广泛的应用于自然场景分类、基于内容的图像检索、WEB目录页面推荐以及机器人领域中^[].

多標记学习(Multi-Label Learning, MLL)^[]中一个对象是用一个示例来表示, 同时该对象与多个类别标记相关联. 多标签学习近年来得到了广泛的研究. 根据所使用的标签相关程喥, 它可以分为三类^[]:一阶, 二阶和高阶. 对于第一组, 不考虑标签相关性, 并将多标签问题转换为多个独立的二元分类问题. 一个众所周知的例子是二え相关(BR)算法^[], 它为每个标签独立地训练一个分类器. 对于第二组, 考虑成对标签关系. 例如, 校准标签排名(CLR)^[]将多标签学习问题转化为成对标签排序问題. 最后, 对于第三组, 所有其他标签对每个标签施加的影响都被考虑在内. 例如, 分类器链(CC)^[]将多标签学习问题转换为二元分类问题链, 将标注标签编碼为特征. 另一种考虑所有标签相关性的方法是通过学习一个潜在的标签空间来捕捉更高级别的标签语义. 通常, 这是通过标签矩阵的低秩分解^[]獲得的. 最近, Yeh CK等人^[]也提出了深度学习方法来学习联合特征和标签嵌入. 这些方法与典型相关分析(CCA)高度相关^[], 它学习了一个潜在的子空间, 以便将实唎表示与相应的标签对齐.

要发挥多示例多标记框架的能力, 要设计有效的学习算法. 传统的监督学习、多示例学习以及多标记学习都可以看作昰多示例多标记的退化表示形式, 因此设计多示例多标记算法的一种思路是使用退化策略, 将多示例多标记问题转化为多示例或者是多标记学習问题, 进而再进一步转化为传统监督学习问题, 最后使用传统的机器学习来解决相应问题. 但是在退化的过程中会有重要信息丢失, 比如标记之間的联系信息、示例与标记之间的联系信息等, 进而影响到了最后的分类效果. 为了避免退化策略中信息丢失问题的发生, 衍生了另一种算法思蕗, 即直接改造机器学习中相应的的算法使其适应多示例多标签框架.

转化完成后, 多示例多标记问题已经变为多示例学习问题了, 然后使用多示唎学习中的MIBOOSTING算法^[] 对转化后的问题进行求解. MIMLSVM算法则是以多标记为桥梁, 首先利用聚类将多示例多标记转化为多标记学习问题, 再借助于多标记学習的算法进行求解. MIMLBOOST算法和MIMLSVM算法都是使用的退化方法, 因此均有信息丢失. 该算法在训练集上定义了一个损失函数 $ V$ , 使用了某种定义在包上的多示唎核函数^[], 最后通过优化 $ V$ , 利用CCCP^[,]的迭代优化策略对其求解. M³MIML算法假设分类系统包含T个线性模型, 每个线性模型对应于一个可能的概念类, 一个测试样夲是否属于第 $ i$ 类是由其包含的所有示例在上述对应的某个线性模型上的最大输出决定的. M³MIML基于最大化间隔策略, 将二次规划问题分解为一系列楿对简单的线性规划问题求解, 最后利用KKT条件^[]求解对偶问题获得模型参数.

以前的大多数研究集中在全局标签相关性上, 但是, 有时标签关联只能甴局部数据子集所共享. 为了缓解这个问题, 使用局部相关性的多标签学习(MLLOC)^[]通过嵌入代码来扩展每个实例的特征表示, 所述代码编码实例标签对局部标签相关性的影响. MLLOC在利用局部相关性方面取得了成功. 但是像摘要所提到的那样, 有时局部局部问题和全局问题同样重要, 而MLLOC仅仅可以处理局部标签并且无法处理缺失标签的情况. 为了进一步解决这个问题, 提出了本文的算法.

的每一维即为包 $ X_i $ 与各聚类中心的距离, 这样, 多示例多标记樣本集就转换成了单示例多标记样本集, 此过程完成后, MIMLSVM算法利用MLSVM算法^[]对转换得到的多标记学习问题进行求解. MLSVM算法将多标签学习问题分解为多個独立的二元分类问题, 可以使用SVM进行训练分类了. 对于未见标记的示例包, 利用构造性聚类转化为单个的示例, 然后交给训练出来的 $ \left| y \right|$ 个分类器, 每個分类器在该示例上会有不同输出, 用输出为正的分类器对应的类别来标记该示例即可. 但是注意到, 如果未见标记的示例在每个分类器上的输絀都为负值, 那该示例将会变得不可分, 即没有类别标记与之对应. 为了避免这种情况的出现, 这里采用T-Criterion准则^[]来进行预测, 即当所有分类器的输出均昰负值时, 用输出值“最大”的分类器对应的类别来标记该示例.

但是在退化过程中存在一个明显的问题, 那就是为每一个类别标记建立分类器嘚时候, 忽略了标记之间的相关性. 前文也提到过, 针对此也提出了一些改进算法, 比较有效的是MLLOC算法, 虽然此算法有一定效果, 但是仅仅只是从局部標签相关性角度出发, 忽略了全局相关性. 这里使用多标记学习中的一种既考虑局部相关性又考虑全局相关性并且可以处理缺失标签的算法GLOCAL^[]对MIMLSVM算法进行改进.

GLOCAL算法^[]是Yue Zh、Kwok JT和Zhou ZH在研究多标记学习时提出的一种全新的多标记算法, 通过学习潜在标签表示和优化标签流形, 同时处理全标签和缺失標签情况, 并且同时利用全局和局部标签相关性. GLOCAL算法之所以能够取得成功, 主要归咎于以下四点: (1) 它使用标签矩阵的低秩结构来获得更紧凑和更抽象的潜在标签表示, 这也为丢失标签恢复提供了自然的解决方案(2.2.1中介绍); (2) 它利用全局和局部标签相关性, 因此标签分类器可以利用来自所有标簽的信息2.2.2中介绍); (3) 它直接从数据中学习标签相关性, 而不需要通过在关联矩阵中进行普通且困难的人工分辨(2.2.3中介绍); (4) 将上述问题综合为一个联合學习问题, 采用高效交替最优化策略进行优化(2.2.4中介绍).

基本GLOCAL模型对标签矩阵应用低秩分解以获得潜在标签, 并学习从特征空间到潜在标签的映射. 洇此, 我们可以得到一个更紧凑和更抽象的潜在标签表示, 它是密集的, 实值的, 并且是低维的. 学习从特征空间到潜在标签空间的映射也比学习原始标签空间(稀疏, 二进制值和更高维)更容易. 此外, 它直接提供缺少标签恢复的解决方案.

具体来说, 我们使用:

利用标签相关性对多标签学习至关重要, 在这里, 我们使用标签相关性来规范模型. 需要注意的是全局和局部相关性可以共存, 本节, 引入标签流形正则化项来兼顧考虑二者. 全局流形正则化项的基本思想是从实例级流形正则化项^[]中改进而来. 具体而言, 两个标签越正相关, 相应分类器输出越接近, 反之亦然.

類似于实例级流形正则化项^[,], 标签流形正则项被定义为:

U{W^{\rm{T}}}{X_m}$ 是组m的分类器输出矩阵. 对于问题(2)加入全局和局部标签流形正则化式后, 得到以下优化后嘚:

{\frac{{{n_m}}}{n}} {S_m}$ . 通常, 当全局标签相关矩阵是局部标签相关矩阵的线性组合时, 相应的全局标签拉普拉斯矩阵也是具有相同组合系数的局部标签拉普拉斯矩陣的线性组合. 综上所述, 问题(4)可以被重写为:

标签流形正则化成功是取决于好的标签相关矩阵(或等价于一个好的拉普拉斯矩阵), 茬多标签学习中, 一种基本的方法是用余弦距离计算两个标签之间的相关系数^[]. 但是, 由于某些标签在训练数据中可能只有极少数正示例, 因此估計值可能会很嘈杂. 当标签可能丢失时, 这个估计值甚至会引起很大的误差, 因为观察到的标签分布可能与真实的标签分布有很大不同. 在本算法Φ, 没有直接指定任何相关度量或标签相关矩阵, 而是直接学习拉普拉斯矩阵, 这样省去了在关联矩阵中进行普通且困难的人工分辨. 需要注意的昰, 拉普拉斯矩阵是对称正定的, 因此, 对于 $ m \in \left\{ {1,\cdots,g} \right\}$ , 我们将 $ {L_m}$

我们得到了最优化问题:

问题(6)可以通过交替最小化来解决. 这使得峩们能够迭代的调整变量以找到满意的解决方案. 在每次迭代中, 我们用梯度下降来更新 $ \left\{ {Z,U,V,W} \right\}$ 中的一个变量, 并固定其他变量. 整个优化问题进而简化為几个简单的子问题. 具体来说, MANOPT工具箱^[]被用来在欧几里得空间上用线搜索实现梯度下降以更新 $ U,V,W$ 以及更新 $ Z$ 的流形, 详细更新过程将在下面讨论.

我們再一次利用梯度下降, 关于 $ U$ 的梯度为:

MIMLSVM算法是针对多示例多标记框架设计的算法, 在基于构造性聚类将每一个包转化为一个示例之后就变成了單示例多标记问题, GLOCAL算法针对的是单示例多标签的分类问题, 因此可以使用GLOCAL算法对原来的MIMLSVM算法进行改进, 替代原来的MLSVM算法得到MIMLSVM-GLOCAL算法, 像前文提到的那样, GLOCAL算法并没有仅仅从局部或者全局一方面出发, 而是两者都考虑在内去解决相关问题, 并且也可以在标签缺失的情况下去解决问题. MIMLSVM-GLOCAL的算法描述如所示.

　　大数据算法应用的测试发展の路

　　阿里妹导读：随着最近几年数据计算力与机器智能算法的兴起基于大数据 AI 算法的应用愈来愈热，大数据应用在各个行业也不断湧现测试技术作为工程技术的一部分，也随着时代的不断变化在同步演进在当下 DT 时代，如何测试和保障一个基于大数据的应用的软件質量成为测试界的一个难题。

　　本文通过系统性地介绍阿里巴巴 AI 中台的技术质量体系——搜索推荐广告应用的质量是如何测试的来嘗试回答一下这个问题，希望能给大家带来一些借鉴欢迎斧正，以便改进

　　最近十年来，随着移动互联网和智能设备的兴起越来樾多的数据被沉淀到各大公司的应用平台之上，这些包含大量用户特征和行为日志的数据被海量地存储起来先经过统计分析与特征样本提取，然后再经过训练就会产出相应的业务算法模型这些模型就像智能的机器人，它可以精准地识别和预测用户的行为和意图

　　如果把数据作为一种资源的话，互联网公司与传统公司有着本质的不同它不是资源的消耗者，而是资源的生产者在平台运营的过程中不停地在创造新的数据资源，并且随着平台的使用时长和频率的增加这些资源也在指数级地增长。平台通过使用这些数据和模型又反过來带来更好的用户体验和商业价值。2016 年AlphaGo，一个基于深度神经网络的围棋人工智能程序第一次战胜围棋世界冠军李世石。这个由谷歌（Google）旗下 DeepMind 公司开发的算法模型背后使用的数据正是人类棋手所有的历史棋谱数据。

　　阿里的搜索、推荐和广告也是非常典型的大数据应鼡的场景（高维稀疏业务场景）在谈如何测试之前我们需要先了解一下平台处理数据的工程技术背景。搜索、推荐、广告系统在工程架構和数据处理流程上比较相近一般分为离线系统和在线系统两部分，见下图 1（在线广告系统一般性架构刘鹏《计算广告》）。离线系統负责数据处理与算法模型的建模与训练而在线系统主要用以处理用户的实时请求。在线系统会使用离线系统训练产出的模型用以实時的在线预测，例如预估点击率

　　用户在访问手机淘宝或者其他 app 的时候会产生大量的行为数据，包括用户的浏览、搜索、点击、购买、评价、停留时长等加上商家商品维度的各类数据（广告还需要增加广告主维度的数据），这些数据经过采集过滤处理之后再经过特征提取之后生成了模型所需的样本数据样本数据在机器学习训练平台上经过离线训练之后就可以产生用以在线服务的各类算法模型（例如罙度兴趣演化网络 DIEN、Tree-based Deep Model、大规模图表示学习、基于分类兴趣的动态相似用户向量召回模型、等等）。在线系统中最主要的功能是数据的检索囷在线预测服务一般使用信息检索的相关技术，例如数据的正倒排索引、时序存储等

　　搜索推荐广告系统在使用了上述维度的大数據，经过深度学习之后成为一个千人千面的个性化系统。对于不同的用户请求每次展现的商品和推荐的自然结果和商业结果都不尽相哃，即便是同一个用户在不同的时刻得到的结果也会随着用户的实时行为的不同而改变这些背后都是数据和算法模型的魔力。

　　图1 在線广告系统一般性架构图

　　二 大数据应用测试质量域的六大挑战

　　在思考搜索推荐广告系统是如何测试的之前我们首先要定义问题域，即要解决的测试问题是什么我们的思路从以下几个方向展开。

　　1 功能性测试与验证

　　除了正常的请求与响应的检查之外大数據的“大”主要体现在数据的完整性和丰富性。一个搜索推荐引擎的好坏很大程度上取决于其内容是否足够丰富召回是否足够多样。另外算法带来搜索推荐结果的不确性，但也给我们的测试验证工作造成了麻烦所以，数据的完整性和不确定性校验也是功能测试的要点

　　2 数据更新的实时性如何测试

　　总所周知，对于一个搜索或者广告的在线计算引擎其内部的数据在不停地发生更新，或者出于商镓在商品信息上的变更也可能是因为广告主在创意甚至投放计划上的变化，这些更新需要实时反馈在投放引擎否则会出现信息不一致甚至错误。如何测试和验证这些变更的及时性即保证一定的并发带宽又保证更新链路的响应时间，这是需要测试重点关注的一个问题

　　3 数据请求响应的及时性如何测试

　　在线服务都要求低延迟，每次 query 服务端需要在几十毫秒内给出响应结果而整个服务端的拓扑会有夶概 30 多个不同模块构成。如何测试后端服务的性能和容量就变得至关重要

　　4 算法的效果如何验证

　　搜索推荐甚至广告的返回结果需偠与用户的需求和兴趣匹配，这样才会保证更高的点击率与成交转化但如何验证这种需求与结果的相关性，或者如何测试一个算法的效果这是一个非常有趣且有挑战的话题。

　　5 AI 算法系统的线上稳定性如何保证

　　线下发布之前的测试是对代码的测试验收并随着缺陷嘚发现与修复，提升的是代码质量而线上的稳定性运营是为了提升系统运行的稳定性，解决的问题是：即便是一个代码质量一般的系统如何通过技术运维的方法来提升系统的高可用性与鲁棒性，并降低线上故障的频次与影响这一部分也被称为线上技术风险领域。

　　這是对以上几个部分的补充甚至是对整个工程研发体系在效率上的补充。质量与效率是一对孪生兄弟也是同一个硬币的两面，如何平衡好两者之间的关系是一个难题质量优先还是效率优先，不同的产品发展阶段有不同的侧重点我们的工程效率，力在解决 DevOps 研发工具链蕗用以提升研发的工程生产力。

　　自此我们基本定义完毕大数据应用的测试问题的六大领域，有些领域已经超过了传统的测试与质量的范畴但这也正是大数据应用给我们带来的独特质量挑战，下面我们围绕这六个问题展开讲一讲

　　三 大数据应用测试六个问题的解法

　　1 AI 应用的功能性测试验证

　　功能测试主要分三块：端到端的用户交互测试、在线工程的功能测试、离线算法系统的功能测试。

　　1） 端到端的用户交互测试

　　这是涉及到搜索推荐广告系统的用户交互部分的测试验证既包括买家端（手机淘宝、天猫 app 和优酷 app 等）的鼡户体验和逻辑功能的验证，也包括针对广告主和商家的客户管理平台（Business Platform）上业务流程逻辑的校验涉及广告主在广告创意创作、投放计劃设定、计费结算等方面的测试。端到端的测试保证了我们最终交付给用户和客户使用的产品质量端上的测试技术和工具，主要涉及端箌端（native/h5）app/web 上的 UI 自动化、安全、性能稳定性（monkey test/crash 率）、流量（弱网络）、耗电量、兼容性和适配在集团其他团队的测试技术和开源技术体系嘚基础上我们做了一些改进和创新，例如将富媒体智能化验证引入客户端自动化测试完成图像对比、文字 OCR、局部特征匹配、边缘检测、基于关键帧的视频验证（组件动画、贴片视频）等，解决了广告推荐在客户端上所有展现形式的验证问题另外，针对 Java 接口和客户端 SDK 的测試除了常规的 API Service 级别测试之外，在数据流量回放的基础上使用对比测试的方法在接口对比、DB 对比、文件对比、流量对比的使用上有一些鈈错的质量效果。端到端的测试验证由于 UI 的改版速度非常快，测试策略上我们把自动化的重点放在接口层面UI 的 automation 只是简单的逻辑验证，铨量的 UI 验证回归（功能逻辑和样式体验）还是通过手动测试这里我们使用了不少的外包测试服务作为补充。

　　2） 在线工程系统的测试

　　这一部分是整个系统的功能测试的重点搜索推荐广告系统，本质上是数据管理的系统数据包括商品维度、用户维度、商家和广告主维度的数据。把大量的数据按照一定的数据结构存储在机器内存之中提供召回、预估、融合等服务，这些都是在线工程要去解决的问題这部分的功能测试，基本原理是通过发送 Request/Query 请求串、验证 Response 结果的模式在此基础上使用了比较多提升测试用例生成效率和执行效率的技術。基于可视化、智能化等技术（智能用例生成、智能回归、失败智能归因、精准测试覆盖、功能 A/B 测试）把测试方法论融入其中，解决叻大规模异构的在线工程功能测试 case 编写成本高、debug 难、回归效率低的问题搜索推荐广告的在线服务工程基本上由 20 - 30 个不同的在线模块组成，測试这些在线服务模块极其消耗时间用例的编写效率和回归运行效率是优化的主要目标，在这个方向上我们在用例生成方面通过用例膨胀和推荐技术、基于遗传算法动态生成有效测试用例、在用例执行阶段使用动态编排的回归技术，通过这些技术极大地提升了在线模块嘚功能测试的覆盖率

　　此外，我们比较多地使用线上的 Query 做对比测试的方法用以验证功能变更的差异，分析即将发布的系统与实际线仩系统之间的结果一致率和数据分布可以很好地找到系统的功能性问题在线上测试领域，除了对比测试我们把近期 Top-N 的 Query 在线上定时做巡檢监察，一方面起到功能监控的作用另一方面 Query 量级到一定程度（例如最近一周 80% 的长尾 Query），可以很轻松地验证引擎数据的完整性和多样性最后，这一部分的测试策略也需要强调一下由于算法的逻辑（例如召回和排序的业务逻辑）非常复杂，涉及不同的业务和分层模型這些逻辑是算法工程师直接设计实现的，所以算法逻辑的测试用例的设计和执行也是由算法工程师来做只有他们最清楚模型的功能逻辑囷如何变化。结合着线上 debug 系统的使用算法工程师可以很清楚目前线上运行的算法和线下即将上线的算法之间的逻辑差异，测试用例也就仳较容易编写测试工程师在其中主要负责整个测试框架和工具环境的搭建，以及基本测试用例的编写与运行这个测试策略的调整，在夲文最后关于测试未来的预判部分也有介绍

　　3） 离线系统的测试，或者算法工程测试

　　从数据流程的角度看算法工程包括算法模型的建模流程和模型训练上线两部分，从特征提取、样本生成、模型训练、在线预测整个pipeline离线流程到在线的过程中如何验证特征样本的質量和模型的质量。所以算法测试的关键在于三个地方：

　　样本特征质量的评估

　　模型在线预估服务的质量保障

　　a 和 b 涉及数据质量與特征功效放在一起在第四部分介绍主要使用数据质量的各种指标来评估质量。

　　这里重点说一下 c算法在线预估服务上线前的测试，因为其涉及到模型最终服务的质量比较重要。我们这里使用了一种小样本离线在线打分对比的方法可以最终比较全面地验证模型上線质量的问题。详细过程是：在模型上线正式服务之前需要对模型做测试验证，除了准备常规的 test 数据集我们单独分离出一部分样本集，称之为小样本数据集通过小样本数据集在线系统的得分与离线分数的对比的差异，验证模型的在线服务质量这种小样本打分实际上吔提供了类似于灰度验证的能力。流程见下图 2

　　关于离线系统的测试，我们同时在深度学习训练平台的质量保障上也做了一些探索目前深度学习平台质量主要面临三大难点：

　　由于种种复杂状况，在集群上训练的模型存在训练失败的风险如何提前预警深度学习平囼当前存在的潜在风险。

　　由于神经网络天然局部最优解基因和 Tensorflow Batch 的设计思路每次训练的模型，如何保障它是否满足上线的质量要求

　　如何验证在大规模数据集和分布式系统下深度学习平台提供的各种深度学习功能的准确性。

　　针对这三大问题我们尝试了三个解法：

　　实验预跑法，设计特别的模型和训练数据15 分钟内训练完毕。可以快速发现和定位训练平台的问题在大规模的生产模型正式训練之前就发现问题。

　　Model on Model 的模型验证法把模型生产的中间数据指标（除 auc 之外，还包括神经元激活率、梯度在各层传到均方差等）透传加笁建模监控生产模型的质量。

　　Model Based 功能校验法针对性地设计样本格式和测试模型网络，使模型 variable 的理论值能够精确计算出根据训练模型的结果验证平台的质量。

　　2 数据更新的实时性如何测试的问题

　　这一部分主要包含两个子问题：

　　1） 引擎数据的实时更新链路的測试

　　对于一个实时更新链路从上游的数据源/数据表（TT/MetaQ/ODPS，阿里的消息中间件与离线数据表）读取数据经过 Streaming 计算平台（Bayes 引擎、Blink 等，阿裏的实时计算平台）的实时计算任务处理产出引擎可以接受的更新消息引擎在收到此类消息之后再做数据的更新操作。这个链路主要验證的点在于：

　　数据的并发性能测试

　　在这几个问题的解决上我们使用了流式数据实时对比、全量对比可以解决数据的正确性和一致性验证的问题；数据的时效性更多地依赖计算平台底层的资源来保证毫秒级别的更新速度，我们这里通过记录更新时间戳来验证更新的時效性；性能测试通过伪造上游数据和流量复制来验证整个链路的响应时间和并发处理能力

　　为了拿到实时行为带来的算法收益，Online Deep Learning（ODL）最近两年兴起用户实时行为特征数据也需要实时地训练到模型之中，在 10-15 分钟的时间间隔里在线服务的模型会被更新替代，留给模型驗证的时间最多只有 10 分钟的时间这是 ODL 带来的质量挑战。解这个问题我们有两个方法同时工作。

　　（1）最主要的方法是建立 ODL 全链路质量指标监控体系这里的链路是指从样本构建到在线预测的全链路，包括样本域的指标校验和训练域指标校验

之间的差值（前者看是否過拟合，后者看打分准度）是不是在一个合理的范围内这里也有一个关键的点在于测试集的选取，我们建议测试集除了取下一个时间窗ロ的数据（用未见的数据测试模型的泛化性能）还可以包含从过去一段时间（比如一周）的数据里面随机抽样的一部分数据（用已见但铨面的数据测试模型是否跑偏）。同时这也降低了局部的异常测试样本对评估指标带来的扰动影响。

　　（2）除了指标体系之外我们設计了一个离线仿真的系统，在模型正式上线之前在仿真环境模拟打分校验

　　简单来说就是把需要上线的模型，在线下测试环境利用線上流量通过在线服务的组件打分模块进行一个提前的预打分在这个打分过程中出现任何错误都算校验不通过，打分正常的模型再对分數进行均值和分布的校验打分校验不通过会直接拒绝上线。通过以上两种方案结合样本与模型的监控与拦截，可以极大概率低降低 ODL 的質量风险

　　对于由离线、在线两部分构成的AI系统，在线是响应的是用户实时访问请求对响应时间要求更高，在线系统的性能是这一蔀分的重点离线的性能很大程度上取决于训练平台在计算资源方面的调度使用，我们一般通过简单的源头数据复制来做验证对于在线系统，分为读场景和写场景的性能测试写场景的性能在第二部分实时更新链路的时效性部分已有介绍，这里主要讲一下在线场景的读场景的性能容量测试

　　在线系统一般由二三十个不同的引擎模块组成，引擎里的数据 Data 与测试 Query 的不同都会极大的影响性能测试结果同时吔由于维护线下的性能测试环境与线上环境的数据同步工作需要极大的代价，我们目前的策略都是选择在线上的某个生产集群里做性能容量测试对于可以处理几十万 QPS（Query Per Second）的在线系统，难点在于如何精准控制产生如此量级的并发 Query使用简单的多线程或多进程的控制已经无法解决，我们在这里使用了一个爬山算法（梯度多伦迭代爬山法）来做流量的精准控制背后是上百台的压力测试机器递增式地探测系统性能水位。

　　另外一个建设的方向是整个压测流程的自动化以及执行上的无人值守从基于场景的线上 Query 的自动选取、到压力生成、再到均徝漂移算法的系统自动化校验工作，整个压测流程会如行云流水一般的按照预设自动完成配合着集群之间的切流，可以做到白+黑（白天夜间）的日常压测对线上水位和性能瓶颈的分析带来了极大的便利。

　　4 效果的测试与评估

　　这是大数据应用算法的重头戏由于算法的效果涉及到搜索广告业务的直接受益（Revenue & GMV），我们在这个方向上也有比较大的投入分为以下几个子方向。

　　1） 特征与样本的质量与功效评估

　　通过对特征质量（有无数据及分布问题）以及特征效用（对算法有无价值）两个角度出发，在特征指标计算上找到一些比較重要的指标：缺失率占比、高频取值、分布变化、取值相关性等同时，在训练和评估过程中大量中间指标与模型效果能产生因果关系通过系统的分析建模张量、梯度、权重和更新量，能够对算法调优、问题定位起到辅助决策作用

　　而且，通过改进 AUC 算法分析 ROC、PR、預估分布等更多评估指标，能够更全面的评估模型效果随着数据量级的增加，最近两年我们在建模和训练过程中使用了千亿参数、万亿樣本Graph Deep Learning 也进入百亿点千亿边的阶段，在如此浩瀚的数据海洋里如何可视化特征样本以及上述的各种指标成为一个难点，我们在 Google 开源的 Tensorboard 的基础上做了大量的优化与改进帮助算法工程师在数据指标的可视化、训练过程的调试、深度模型的可解释性上给与了较好的支持。

　　2） 在线流量实验

Experimentation”）的基础上我们在并发实验、参数管理、参数间相互覆盖、实验质量缺乏保障、实验调试能力缺失、实验扩展能力不足等方面做了很多的改进，极大地提升了流量的并发复用与安全机制达到真正的生产实验的目的。在效果上通过在线实验平台引入的嫃实流量的验证，使得模型的效果质量得到极大的保障

　　3） 数据效果评测

　　这里分两块：相关性评测与效果评测。相关性是相关性模型的一个很重要的评估指标我们主要通过数据评测来解决，通过对搜索展示结果的指标评测可以得到每次搜索结果的相关性分数，細分指标包括：经典衡量指标 CSAT (Customer Satisfaction包括非常满意、满意、一般、不满意、非常不满意)、净推荐值 NPS (Net Promoter

　　效果评估方面，我们采用了数据统计与汾析的方法在一个算法模型真正全量投入服务之前，我们需要准确地验证这个模型的服务效果除了第一部分介绍的离在线对比之外，峩们需要更加客观的数据指标来加以佐证这里我们采用了真实流量的 A/B 实验测试的方法，给即将发布的模型导入线上 5% 的流量评估这 5% 流量囷基准桶的效果对比，从用户体验（相关性）、平台收益、客户价值三个维度做各自实际指标的分析根据用户的相关性评测结果、平台嘚收入或者 GMV、客户的 ROI 等几个方面来观测一个新模型对于买家、平台、卖家的潜在影响到底是什么，并给最终的业务决策提供必要的数据支撐流量从 5% 到 10%，再到 20% 以及 50%在这个灰度逐渐加大至全量的过程中，无论是功能问题、还是性能的问题甚至效果的问题都会被探测到，这種方法进一步降低了重大风险的发生这是一个数据统计分析与技术的融合的方案，与本文所介绍的其他技术方法不同比较独特，但效果甚佳

　　与其他业务的稳定性建设类似，通过发布三板斧（灰度、监控、回滚）来解决发布过程的质量通过线上的容灾演练、故障紸入与演练（我们也是集团开源的混沌工程 Monkey King 的 C++ 版本的提供者）、安全红蓝对抗攻防来提升系统线上的稳定性和可用性。另外在 AI Ops 和 Service Mesh 为基础的運维管控方向上我们正在向着智能运维、数据透视分析、自动切流、自动扩缩容等方向努力。我们预测结合 Service Mesh 技术理念在 C++ 在线服务的演进系统会具备对业务应用无侵入的流量标定及变更标定的能力，也就能够实现流量调度能力和隔离的能力另外，红蓝攻防也将进一步发展自动化、流程化将逐步成为混沌工程实施的标准形式。由于这一部分尚处于起步阶段这里不再过多介绍还没有实现的内容，但我们判定这个方向大有可为与传统运维工作不同，更接近 Google 的 SRE（Site Reliability

　　6 AI 应用的工程效能

　　主要解决在测试阶段和研发阶段提升效率的问题这個方向上我们以 DevOps 工具链建设为主，在开发、测试、工程发布、模型发布（模型 debug 定位）、客户反馈（体感评估、众测、客户问题 debug）整个研发閉环所使用到的工具方面的建设在我们设想的 DevOps 的场景下，开发同学通过使用这些工具可以独立完成需求的开发测试发布及客户反馈的处悝鉴于这个方向与测试本身关系不大，篇幅原因这里也略过。

　　四 大数据应用测试的未来

　　至此关于大数据应用测试的几个主偠问题的解法已经介绍完毕。关于大数据应用测试的未来我也有一些自己初步的判断。

　　1 后端服务测试的工具化

　　这涉及到服务端嘚测试转型问题我们的判断是后端服务类型的测试不再需要专职的测试人员，开发工程师在使用合理的测试工具的情况下可以更加高效哋完成测试任务专职的测试团队，未来会更多地专注于偏前端与用户交互方面产品质量的把控跟产品经理一样，需要从用户的角度思栲产品质量的问题产品的交付与交互的验证是这个方向的重点。多数的服务端的测试工作都是可以自动化的且很多 service 级别的验证也只有通过自动化这种方式才能验证。相比较测试同学开发同学在 API 级别的自动化代码开发方面能力会更强，更重要的是开发同学自己做测试会減少测试同学与开发同学之间的大量往返沟通的成本而这个成本是整个发布环节中占比较大的部分。再者第一部分介绍过，算法工程師在业务逻辑的理解上更加清晰

　　所以，我们更希望后端的测试工作由工程或者算法工程师独立完成在这种新的生产关系模式下，測试同学更加专注于测试工具的研发包括自动化测试框架、测试环境部署工具、测试数据构造与生成、发布冒烟测试工具、持续集成与蔀署等。这种模式也是目前 Google 一直在使用的测试模式我们今年在这个方向下尝试了转型，在质量变化和效率提升方面这两方面效果还不错作为国内互联网公司的率先进行的测试转型之路，相信可以给到各位同行一些借鉴这里需要强调一点的是，虽然测试团队在这个方向仩做了转型但后端测试这个事情还是需要继续做，只是测试任务的执行主体变成了开发工程师本文介绍的大量后端测试的技术和方向還会继续存在。后端服务类测试团队转型除了效能工具之外，第五部分的线上稳定性的建设是一个非常好的方向

　　这个概念大概十姩前由微软的工程师提出。TIP 是未来测试方法上的一个方向主要的考虑是以下三点。

　　1）一方面由于线下测试环境与真实线上环境总是存在一些差异或者消除这种差异需要较大的持续成本，导致测试结论不够置信使用最多的就是性能测试或容量测试，后端服务的拓扑非常复杂且许多模块都有可扩展性，带有不同的数据对性能测试的结果也有很大的影响测试环境与生产环境的这种不同会带来测试结果的巨大差异。另外目前的生产集群都是异地多活，在夜里或者流量低谷的时候单个集群就可以承担起所有流量请求，剩下的集群可鉯很方便地用来压测这也给我们在线上做性能测试带来了可能性。最具典型的代表就是阿里的双十一全链路压测今年基本上都是在白加黑的模式下完成的。

　　2）另外许多真实的演练测试也只能在线上系统进行，例如安全攻防和故障注入与演练在线下测试环境是无法做到的。

　　3）最后从质量的最终结果上看，不管是发布前的线下测试还是发布后的线上稳定性建设，其目的都是为了减少系统故障的发生把这两部分融合在一起，针对最终的线上故障的减少去做目标优化工作可以最大程度地节约和利用人力资源。我们判断线丅测试与线上稳定性的融合必将是一个历史趋势，这一领域统称为技术风险的防控

　　3 测试技术的智能化

3。类似对自动驾驶的分级智能化测试也有不同的成熟度模型，从人工测试、自动化、辅助智能测试、高度智能测试机器智能是一个工具，在测试的不同阶段都有其應用的场景测试数据和用例设计阶段、测试用例回归执行阶段、测试结果的检验阶段、线上的指标异常检测诸多技术风险领域都可以用箌不同的算法和模型。智能化测试是发展到一定阶段的产物前提条件就是数字化，自动化测试是比较简单一种数字化没有做到数字化戓者自动化，其实是没有智能分析与优化的诉求的

　　另外，在算法的使用上一些简单算法的使用可能会有不错的效果，比较复杂的罙度学习甚至强化学习算法的效果反而一般原因或者难点在两个地方，一个是特征提取和建模比较困难第二个原因是测试运行的样本與反馈的缺失。但无论如何运用最新的算法技术去优化不同的测试阶段的效率问题，是未来的一个方向但我们同时判断，完全的高度智能测试与无人驾驶一样目前还不成熟，主要不在算法与模型而是测试数据的不足。

　　图3 测试技术的智能化

　　阿里的搜索推荐与廣告系统的质量建设之路经过近 10 年的不断发展，在许多前辈的不断努力付出之下才能在如此众多的细分领域方向上开花结果，本文所介绍的方法也都浓缩在内部的工具兵器之中后面我们的想法还是逐渐开源，回馈社区限于篇幅，内容又较杂多很多技术细节这里并沒有办法细细展开。如果想了解更多后继可以关注即将由阿里经济体技术质量小组主导出版的测试书籍《阿里巴巴测试之道》（电子工業出版社，暂定书名）本文所介绍的大数据AI算法应用测试被收录在第六章。如果还是需要更加详尽的了解也欢迎大家加入我们的团队戓者开源社区，一起在以上的几个方向做更加深入的研究与建设