TiD2020质量竞争力大会邀请了好未来AI中台质量与工程效率部负责人赵明为参会者带来《AI工程提效平台研发实践》精彩演讲。
赵明从准、快、稳三个关键词分享了AI算法指标与评测平台架构与实践、AI微服务性能测试平台架构与实践、数据集管理平台架构与实践以及相应的案例演示。
准 ：AI的算法需要满足实际业务场景需求，达到很高的准确度。快：一张图片经过算法的处理，返回结果到用户的app/web端上去，需要去评价它的端到端指标，比如说200~300毫秒，是否能有一个快速的响应和返回。基于这种需求，我们开发了一个微服务性能测试平台。稳：比如语音、图像或者文本发送到模型里面，不会出现卡顿甚至模型崩溃，这跟模型的健壮性是有很大关联的。
好未来AI中台致力于将人工智能技术结合教育场景，打造各项AI能力，持续提升学习体验和效率。围绕AI技术主要有三种类型的模型研发。
第一语音，包括语音识别、语音评测，情感识别和情感分析。比如ASR把语音转成文本的形式，评测英文朗读的流利度、准确性。这都是它的教育场景。
第二图像，比如印刷体的OCR识别，拍照搜题，以及笔记工整度的评级，教育场景内容审核等，都会用图像的算法模型辅助提升效率。
第三数据挖掘，这里面有一部分跟NLP自然语言处理相关，比如文本关键词搜索，课堂的特征统计，精彩瞬间捕获，中文口语表达能力的评测。这一系列模型的能力，我们会把它作为一个AI的微服务部署在PaaS平台上面，供各个端调用。
(一)算法提测频繁，无自动化
算法层面，模型发生变化，如准召率提升、鲁棒性增强、新数据增加；服务化层面，如性能优化，接口变更等都要经过完整的测试，所以提测是非常频繁的。这个过程原来没有进行自动化，效率比较低。
(二)行业领先度无感知
算法工程师会将行业的领先度作为制定 KPI的非常客观的依据。比如50%的 AI能力能够做到行业第一，这个维度实际上是对于算法KPI的目标。如何去评估这个目标？我们需要把它量化，通过一个平台把指标展示出来。如果没有这个平台，对行业领先度是无法感知的。
(三)性能调优后性能评估成本高
无论是算法模型，还是服务化做了调优扩容，我们需要去进行一个端到端的性能评估。伴随评估频率的提高，成本也会相应增加。
(四)数据碎片化
数据是AI的血液。在AI生产研发过程中，每一个环节都离不开数据。数据需要在各个角色里面流转。针对产品，算法，工程研发，测试，都需要对数据进行统一管理。如果各个业务方的数据，包括各个版本的数据，没有一个统一的平台，就会非常碎片化，难于管理和维护。
基于痛点我们进行了改进，也就是平台化建设。我们希望通过算法评测平台、性能测试平台、数据集的管理平台建设可以解决上述四类业务痛点。
(一)工具平台体系建设
工具的建设需要对各个角色赋能。比如产品需求，包括产品上线后的效果，其实有很多的工具做链路跟踪。对于算法，例如核心的AI能力模型，也需要一些工具链辅助提升算法的产出。模型通过服务化的方式把工具暴露成接口，供外部调用。我们在整个过程中要保证它的质量，通过运维体系Devops做全链路监控。
从质量上说，产品负责需求的质量，算法负责AI模型的质量，开发负责代码的质量，测试负责端到端产品的质量，运维负责产品上线后线上的质量，所有的环节都离不开数据和质量相关工具的支撑。
(二)Al算法指标与评测平台架构与实践
1.场景需求及用户
第一个场景，无标注数据：AI算法badcase筛选。不需要提前做数据标注，可以通过竞品分析、竞品比对的过程，自动化筛选badcase。第二个场景，无标注数据：新数据的算法准确性摸底。我们会通过使用新的数据，基于这个平台做算法准确性摸底。第三个场景，有标注数据：AI算法指标竞品评测与领先性分析。会通过标注好的数据做算法指标，客观量化的进行评估，包括市场领先性分析。第四个场景，有标注数据：AI算法指标评测与分析。针对有标注数据，算法的指标可以做进一步的分析和评测，包括找到badcase，把这些数据提供给算法做模型的进一步优化。针对这四个场景，我们主要的用户是算法，算法测试，产品经理。
2.技术架构
Al算法指标与评测平台技术架构分为基础功能与接口调用层、逻辑抽象层、UI层。
基础功能与接口调用层，包括权限管理、数据源管理、存储管理、分析实例管理模块、报告管理。上面会通过接口调用，调用自研的接口和竞品接口，通过脚本库进行统一的管理，比如入参，出参的返回，格式的标准化。
逻辑抽象层，就是把基础的功能做一个工作流整合，要计算算法的指标，或者端到端地处理数据。数据需要进行预处理——脱敏、降噪、清洗、旋转图片、或过滤空音频。不同的模型的处理结果，算法指标的评价规则不同。比如语音的指标是字错率。图像的指标是准召率。那么，如何能够把它们归一化统一管理？AI能力注册，就是把新的开发能力统一。在底层逻辑和上层UI不变的情况下，如何去把它注册到这个平台上？比如说现在有10项能力到100项能力，需要尽可能地减少由于新能力注册导致前后端的逻辑或者代码发生重构的变化和影响。简单讲，它把底层基础构架和上层AI微服务的业务分离开。结果的导出，我们会根据不同的模板，不同的算法模型，会有相应的处理结果报告。可以把它导成表格，去做后续的报告整理和分析。
在逻辑抽象层的上面还会有一个多竞品处理引擎，用来做无标注数据，badcase自动分析，包括对其他竞品做数据比对，去发现自身的不足。
UI层。有评测实例，可视化的编排，也会通过一些可视化界面做badcase筛选和报告的展示。
3.实际效果
Al算法指标与评测平台可以提供算法badcase，为算法工程师做模型优化提供参考。比如：OCR识别错误，在图片识别过程中，因印刷问题造成的噪音数据会影响识别。上图在识别过程中，把“____in”识别成了“-tin”。所以在做算法模型处理的时候，就需要去提升模型本身的鲁棒性，需要针对于这种场景去做模型的专项调优。ASR转录错误就是把语音数据转成文本过程中出现与标注数据不一致的情况。例如标注数据是今年我们部门有多少offer。但模型AB的准确度都不是太好。在识别过程中出现了错误，模型A识别成了”一年我今年我们今年我们不没有多少分“，模型B识别成了“今年我们部门有多少分？”offer和分不能很好的区分。
我们会把错误罗列出来，针对 bad case做统一的报告整理和收集，提供给算法工程师去做模型的优化。
4.算法模型评估的指标
模型的好坏，评价标准需要一套客观的度量标准。
针对图像的统计指标有精确度、准确度、召回率，F1等。可以通过 TP、FN、FP、TN维度用公式计算出Precision、Recall、Accuracy，最后评估出相应的召回率和准确度，看看跟上一版本相比，哪些需要提升。针对语音，可以用WER/CER（词/子错率）做统计指标。这个指标越低越好。以插入错误、删除错误、替换错误除以总共单词数作为计算指标。计算指标会通过脚本的形式嵌入到平台里。
针对性能指标，我们将CPU，MEM，GPU等作为统计指标。针对稳定性指标，主要使用崩溃率和内存泄漏作为统计指标。通过这样的一些维度，我们可以客观地评价模型是不是准、快、稳。
5.Demo1-算法Badcase自动化筛选
针对于无标注数据场景
首先我们会有一个可视化编排的界面，先拖取数据源。这个数据源其实就是 FTP上的一组数据，实际是一个保存了被测图片的文件夹。我们会对图片进行预处理，比如说数据脱敏、自动正位等。因为图片有可能并不是正位的，会通过一些模型来进行正位。这样便于进行模型分析。我们会将脱敏后的数据同时与三个外部竞品模型做比对。
Badcase类似于投票法，比如有ABC三个模型，通过语音分析后如果得到的结果都是“今天是星期五”，那么它的置信度就非常高。如果自研结果和这三个模型的分析结果不一样，那么大概率就是Badcase。它的优势就在于不需要做标注，可以从线上抓取数据，自动化地进行筛选。模型处理完毕后，会做一些去除标点符号、空格、回车等非关键因素的后处理。处理完毕后，Badcase会显示在页面上。在这个页面我们可以调整阈值。阈值越高，说明Badcase的可能性越大。例如：Badcase准确度为0.9，说明它是badcase的可能性非常高。如果是0.2，说明有可能是误报。
针对印刷体的表格，我们会对它进行图片转成文本信息抓取的OCR评测，包括Goodcase和Badcase两种形式。我们可以通过平台，针对无标注数据进行自动化分析。分析出来的Badcase，就可以提供给算法工程师做核心迭代和优化。
6.Demo2-算法指标竞品评测
针对有标注数据
首先通过可视化编排界面，创建一个实例并命名版本。
我们从 FTP上拖取数据然后进行模型分析，把数据同时输入三个模型，其中一个是自研的模型。我们要看自研模型与竞品模型的差距，最后会导入标注数据，然后进行分析。
标注数据相当于一个标准答案。所以最后会得出三类指标。每一个模型都有一套指标。这样我们能够分析到底我们的模型行业的领先性是怎么样的。这有助于算法制定KPI。
针对 OCR类的量化评估指标有两个维度——序列准确度和字符准确度。这两个准确度可以评价模型的效果。在不同的时间迭代，每一个评价模型的标准会有差异。比如说每一个维度，有些可能是我们领先，有些可能是我们落后。这个指标可以看到我们在行业所处的地位。
当然我们也可以做筛选。这个筛选可以针对于不同的维度，或者说针对于不同的竞品，大家可以看到下面是个Badcase，有三个模型。最左侧是自研的版本。
自研版本的效果好于另外两个竞品。所以它的Badcase会比较少。这个页面是模型ABC跟标准数据的比对。如果它跟标准数据完全是一致的，那就是准确的。如果不一致，就说明识别是有误的。
对于印刷体公式的识别算法的模型，输入一张图片，最后会把图片里面的内容以文本的形式输出。一些比较复杂的公式识别，就需要增强模型鲁棒性。这是有一定难度的。正如刚才的演示，我们可以评测出来这个指标。它会通过计算逻辑公式，得到出一个结果。然后可以看到行业领先度。
这个平台算法、测试的伙伴都可以用。产品可以利用这个平台做新数据的摸底，无需算法或测试的参与。他不需要理解非常复杂的计算逻辑，可以通过拖拽等可视化编排的形式帮助工程师快速得出结论。
(三) AI微服务性能测试平台架构与实践
1. 场景需求及用户
AI微服务性能测试平台是解决“快”的问题。
第一个需求是算法和服务化测试环境管理与共享。算法工程师在本地有一套研发的环境，服务化的开发有一套环境。这里面涉及到很多模型的版本，包括基础的依赖库的版本Python 等库。这些库的标准要尽量做到单一化，最简单的方式是容器化管理和环境共享。
第二个需求是实现自动化部署。提测后，性能测试的所有环境需要自动地准备好，如准备好脚本。
第三个需求是自动化探压，包括设置最大 TPS、并发数，去实现自动化的探压。
第四个需求是性能瓶颈分析。瓶颈的分析是很关键的部分。涉及处理速度的问题。针对模型本身，进行模型压缩，剪枝，提高处理速度，减少硬件资源的浪费。
AI微服务性能测试平台针对的用户就是服务化测试、算法测试、研发、产品经理。研发和产品经理可以拿到性能指标跟客户沟通是否满足业务的需求。
2.技术架构
AI微服务性能测试平台架构包括数据源、接口层、UI层。
最底层是数据源，我们会用Prometheus做远程数据监控。针对数据源，会有数据库做持久化的存储。
中间层是接口层。这里面会有自动化探压的逻辑，包括远程的执行、部署，指标落地的计算，远程终端的控制。还可以一键登录。
上层是UI层，能够通过平台的界面登录，包括资源申请和释放，自动化探压，瓶颈的分析等。
3.实际效果
平台可实现无人值守的自动化探压，依据二分法算法在最短的时间内探查系统的最大TPS或并发请求数量。
二分法就是并发从100开始，100是初始的压力，步长也是100。我们进行100 200 300 400递增压测，当它达到最大的一个TPS拐点，如上图300这个极大值出现后，会把压力降下来到200-300之间，降到250。如果没有这个平台，我们每次都需要手动改并发。因为服务种类会比较多，有基于HTTP协议，也有基于Websocket协议。为了简化和通用，底层还是基于Jmeter去实现，然后通过一个模版替换的逻辑，替换JMX文件中的配置。Jmeter开源工具的功能是比较强大的。
手动压测平均每一个AI微服务，需要运行10轮左右不同并发数量下的压测。一轮60分钟，10轮就是600分钟，十分耗时。而每次都需要改脚本，启动压测，观察各项指标输出。服务端报错，需要降压力。指标正常，则继续增压。这十分耗费人力，而且这个工作是重复性的。但是有了自动化后效果就非常明显，从600分钟可以降低到10分钟，最后复核数据，报告没有问题，就可以直接得出结论，非常快。
4.Demo3-自动化探压与瓶颈分析
首先申请一个压测机。压测机申请完后，我们可以通过终端连接实现一键登录。这个里面可以操作各种命令。随后就可以根据刚部署的压测机做脚本部署，对Jmeter原生格式文件，做持续30秒恒压的部署，部署完后就可以执行监控。在这个平台上可以完成所有工作，包括资源申请，脚本远程推送部署执行，结果输出，监控数据的返回和展示。这个平台可以作为工作台，可以按照实际需求做各种各样不同的脚本的配置，包括相关的结果报告的产出。这个报告展示出来是一个Jmeter原生的报告。在这个报告里面可以展示TPS等各项指标。
同时我们还可以进行自动化探压场景。压力是100，步长也是100。每一轮大概60秒钟，实际测试时比这个要长。然后颗粒度是20，这里有个场景是退出的阈值，也就是说颗粒度设置。颗粒度就是说最大成功压力和最小失败压力的之间的差要小于一个值。颗粒度越细，跑的轮数就会越多。
从监控图可以看到，通过一段时间的运行，可以看到这个图到达300的时候，TPS达到了一个拐点，也就是说 TPS出现了瓶颈。瓶颈出现，我们就需要把压力降到250。
当我们运行完后，可以看得一个报告的展示，100的时候TPS是551，200的时候TPS是733，300的时候就TPS降到722。所以我们就需要把压力降回来，降到250~225。这样我们就可以知道在什么样的并发下面，它的TPS是最大的，吞吐量最大。这是一个TPS的场景，还有一个并发数量的场景，不出错的情况下，最多能承受多少个并发。这可以连接到Jmeter原生的报告里。这是端到端的，里面包括了网络传输，服务化的处理，模型调用的时长。
我们可以选择一个时间窗口做监控结构和瓶颈的分析。我们会监测主要的指标，比如内存泄漏。内存泄漏的阈值可以控制，设置默认值为5%。如果结束点比起始点增加了5%以上，我们就判断疑似有内存泄露。这个过程阈值可以调整。我们后面还会再改进得更加智能。
CPU使用率检测阈值，如果阈值允许80%，而它的平均使用率是90%，这样就会报错说已经超过了设置的上限，包括网络流量。这是总体监控的看板。通过开发后台逻辑的服务，从普罗米修斯里面把数据拿回来做一些加工和处理，然后通过接口返回，从前端做渲染。这样一种形式就可以实现：在无人值守的情况下自动探测压力，比如周五晚上下班时，运行自动化脚本，它就一直在探查最大的TPS或者并发数量。然后周一早晨就可以拿到所有的报告，甚至可以多组运行。这就节省了时间。
这可以看作是一个敏捷测试，通过我们的工具和平台，不断地为算法或者研发缩短反馈周期。
(四)数据集管理平台架构与实践
1.场景需求及用户
针对于不同的需求场景，主要用于训练和测试。数据的分类需要打不同的标签，比如哪类的数据是属于哪个业务的，或者属于不同的版本，是正向数据还是负向数据，来应用到不同的算法模型的类别，其实就是在做评测的类别。
算法工程师可能会用到一部分数据。我们在做客观评价时，使用黑箱数据。这对算法工程师是不可见的。但是有一些数据是针对算法自测的，可以与一些冒烟测试的数据一起用于算法测试。
查询标签化数据，标注数据的情况，看看过去搜集到哪些数据，有哪些是已经标注好的，有哪些是没有标注的，或者说它的标注质量比较差，需要重新标注的这部分数据。
我们需要构建一个混沌测试体系提升稳定性，提高模型的鲁棒性。
数据集管理平台的用户也比较多，包括算法、算法测试、产品经理、数据运营。
2.流程
首先选定数据集，其次实现自动化的下载，然后进行模型相关的工作处理，最后进行结果检查。模型处理就是在数据位置模型里面，监控各类指标是否运行正常。在中间这个过程中，监控准确率，监控准不准、快不快、稳不稳，通过这样的维度，监控实际效果是不是符合用户和业务的预期。
针对噪音数据、空数据、模糊图片、非法格式、缩放图片、低质数据、超限数据、碎片数据、光源点图、对抗数据等不同类型的数据，我们会通过不同的维度关注算法模型的表现。
3.实际效果
监控同时段内存使用量和CPU使用率可以发现模型是否稳定。如上图，同时段内存使用量是在不断地变化波动，波动范围在6G-8G。
同时段CPU使用率的波动也比较正常。最大值的波动在50%上下，也是在可以接受的范围。所以这批数据的处理针对资源使用来讲没有太大风险，这说明模型的稳定性达到了交付的标准。
(一)目标
考虑不同维度的评估标准，未来，我们将以高质、提效、降本为核心，助力产研算测团队，通过工具链或者平台研发，更敏捷地交付 AI产品和微服务。这是我们的目标。
(二)方向
针对“准”：我们将继续让平台具备支持算法指标优化方向的智能推荐能力。采用了什么样的模型，基于Badcase分析，使用了哪些参数等，可以针对这些维度的数据进行智能推荐，告诉算法工程师下一步优化的方向。
针对“快”：找到算法系统的瓶颈从而实现智能定位与分析。比如说模型处理效率是不是可以提升，在工程层面是不是可以做一些数据压缩，在网络链路传输中，可不可以做一些性能的提效，服务化申请资源时是否要进行横向扩容。
针对“稳”：进行算法与服务化内存泄漏扫描与定位。内存泄漏，不仅影响服务化，而且影响工程质量。它是影响系统稳定性的第一大杀手。如何快速定位内存泄漏的问题，这很重要，也很难。通常一个内存泄露问题，研发和算法部门一起分析，可能都需要几天才能够定位出来。这与敏捷研发迭代是相悖的。所以我们持续地研究如何通过一些工具获得静态加动态扫描的形式，进行进一步精准的定位。