算法■深度|大数据算法应用的测试发展之路( 四 )


  • 由于种种复杂状况 , 在集群上训练的模型存在训练失败的风险 , 如何提前预警深度学习平台当前存在的潜在风险 。
  • 由于神经网络天然局部最优解基因和 Tensorflow Batch 的设计思路 , 每次训练的模型 , 如何保障它是否满足上线的质量要求 。
  • 如何验证在大规模数据集和分布式系统下深度学习平台提供的各种深度学习功能的准确性 。
针对这三大问题 , 我们尝试了三个解法:
  • 实验预跑法 , 设计特别的模型和训练数据 , 15 分钟内训练完毕 。 可以快速发现和定位训练平台的问题 , 在大规模的生产模型正式训练之前就发现问题 。
  • Model on Model 的模型验证法 , 把模型生产的中间数据指标(除 auc 之外 , 还包括神经元激活率、梯度在各层传到均方差等)透传加工建模 , 监控生产模型的质量 。
  • Model Based 功能校验法 , 针对性地设计样本格式和测试模型网络 , 使模型 variable 的理论值能够精确计算出 , 根据训练模型的结果验证平台的质量 。
2 数据更新的实时性如何测试的问题
这一部分主要包含两个子问题:
1) 引擎数据的实时更新链路的测试
对于一个实时更新链路 , 从上游的数据源/数据表(TT/MetaQ/ODPS , 阿里的消息中间件与离线数据表)读取数据 , 经过 Streaming 计算平台(Bayes 引擎、Blink 等 , 阿里的实时计算平台)的实时计算任务处理产出引擎可以接受的更新消息 , 引擎在收到此类消息之后再做数据的更新操作 。 这个链路主要验证的点在于:
  • 数据的正确性验证
  • 数据的一致性验证
  • 数据的时效性验证
  • 数据的并发性能测试
【算法■深度|大数据算法应用的测试发展之路】在这几个问题的解决上 , 我们使用了流式数据实时对比、全量对比可以解决数据的正确性和一致性验证的问题;数据的时效性更多地依赖计算平台底层的资源来保证毫秒级别的更新速度 , 我们这里通过记录更新时间戳来验证更新的时效性;性能测试通过伪造上游数据和流量复制来验证整个链路的响应时间和并发处理能力 。
2) 模型的实时更新(Online Deep Learning)链路如何测试
为了拿到实时行为带来的算法收益 , Online Deep Learning(ODL)最近两年兴起 , 用户实时行为特征数据也需要实时地训练到模型之中 , 在 10-15 分钟的时间间隔里 , 在线服务的模型会被更新替代 , 留给模型验证的时间最多只有 10 分钟的时间 , 这是 ODL 带来的质量挑战 。 解这个问题 , 我们有两个方法同时工作 。
(1)最主要的方法是建立 ODL 全链路质量指标监控体系 , 这里的链路是指从样本构建到在线预测的全链路 , 包括样本域的指标校验和训练域指标校验 。
指标选取上主要看是否跟效果相关联 , 例如对于 ctr 预估方向 , 可以计算测试集上的 auc、gauc(Group auc , 分组后的 auc)、score_avg(模型打分均值)等指标 , 甚至计算train_auc & test_auc , pctr & actual_ctr 之间的差值(前者看是否过拟合 , 后者看打分准度)是不是在一个合理的范围内 。 这里也有一个关键的点在于测试集的选取 , 我们建议测试集除了取下一个时间窗口的数据(用未见的数据测试模型的泛化性能) , 还可以包含从过去一段时间(比如一周)的数据里面随机抽样的一部分数据(用已见但全面的数据测试模型是否跑偏) 。 同时 , 这也降低了局部的异常测试样本对评估指标带来的扰动影响 。
(2)除了指标体系之外 , 我们设计了一个离线仿真的系统 , 在模型正式上线之前在仿真环境模拟打分校验 。
简单来说就是把需要上线的模型 , 在线下测试环境利用线上流量通过在线服务的组件打分模块进行一个提前的预打分 , 在这个打分过程中出现任何错误都算校验不通过 , 打分正常的模型再对分数进行均值和分布的校验 , 打分校验不通过会直接拒绝上线 。 通过以上两种方案 , 结合样本与模型的监控与拦截 , 可以极大概率低降低 ODL 的质量风险 。


推荐阅读