智能算法测试平台基础设施
# 1 为什么要有中心化的智能算法平台
# 1.1 当前面临的问题
智能化产品测试团队对接我司的智能化算法模型服务以及相关产品,负责保障其产品质量。
目前我们根据算法能力的类别对分为四大类:文本类、音频类、图片类、视频类,每一类智能算法服务都有不同的测试数据集。
智能化产品的质量保障与传统的产品质量保障最大的区别在于其具备以下特征:
- 高度数据化
- 高度自动化
这两方面相辅相成,可以说是”一荣俱荣,一损俱损“。
# 1.2 当前智能化产品测试数据管理困境
# 1.2.1 标注信息存储混乱
智能化产品的测试,需要根据不同的智能化产品准备不同的测试数据样本集,测试样本集的数据量级从几千到几十万不等,不同类别的测试样本集有不同的标注信息,标注方式也不尽相同。
文本、图片、音频、视频的标注维度不同,数据结构也各种各样,即使同为图片,人脸、行人、车辆的标注信息维度也是迥然不同的。
标注信息随着算法服务能力的迭代升级,会有更新变化(扩充标注维度,删减标注维度,更新维度定义等)。
# 1.2.2 数据来源缺少辨识
当前测试样本的数据来源广泛,有来自生产环境脱敏的数据,有员工采集的数据,有互联网采集的数据,有自研工具构造的测试数据,但我们缺乏有效的分类记录措施。
# 1.2.3 存储分散易丢失
不同的算法服务由不同的测试工程师负责,数据存储在不同服务器的不同目录,还有些数据存储在个人PC中,也有数据存储在移动硬盘中,缺乏对数据的统一整合,容易丢失。
# 1.2.4 缺乏版本管理
某版本的智能算法服务测试结果需要与对应的测试集建立联系,便于回归测试和算法服务的版本迭代效果比对,当前缺乏这种测试数据的版本管理机制。
# 1.3 当前算法自动化持续迭代困境
# 1.3.1 测试数据获取方式五花八门
由于测试数据集的存储不统一,导致各类智能化算法服务的自动化测试代码获取测试数据的方式各不相同,有从代码直连数据库执行SQL获取,有读取本地文件,读取文件的数据格式也各不相同,这导致了测试代码编写方式无法统一。
# 1.3.2 自动化测试代码不规范
各个智能算法服务由不同的测试工程师负责,编码能力参差不齐,缺乏面向对象,模块化的代码设计模式,代码风格迥异,同一类功能的实现方式也各不相同,这给代码的维护带来了较大的困难。
# 1.3.3 测试结果输出形式各不相同
由于没有中心化的测试结果存储体系,且缺乏统一的设计和约束规范,各智能算法服务的测试代码输出形式各不相同,有的把测试结果输出到excel文件,有的输出到文本文件,有的直接存储到数据库,有的直接print到命令行终端。
# 1.3.4 测试结果缺乏持久化存储
各智能算法服务的测试代码由不同测试工程师设计开发维护,缺乏统一规范,测试结果输出方式和内容不统一,这就导致测试结果的持久化存储只能存储在测试执行环境或依赖测试工程师手动保存备份,甚至即用即销毁,都没有留存。
没有持久化测试结果的存储,难以实现对算法服务的质量进行全生命周期的跟踪,难以度量其质量变化趋势。
# 1.4 解决问题的思路
两条腿走路,要有代码设计开发维护的规范和测试人员开发能力的提升,也要有相应的基础设施辅以支撑规范和标准的落地运行:
- 对测试数据进行集中管理,建立统一标准的数据管理规范,提供各类测试数据管理的基础设施服务,能便捷,清晰,灵活,可靠的提供测试数据(包含标注数据)的入库、查询、更新、修改能力;
- 对每个算法服务项目、版本、迭代的测试结果进行标准化、持久化的存储,提供便捷的数据入库存档的能力;
# 2 目标
# 2.1 统一标准
将测试数据的解析、入库、存储标准化,遵循统一的流程和模式;
将测试数据的查询、获取标准化,通过统一的API形式获取;
将测试任务的记录,测试结果的存储方式统一,通过API记录和获取;
建立标准、模式统一会带来高效和生产力。
# 2.2 解决当下问题
解决测试数据管理和算法自动化持续迭代的痛点。
# 2.3 放眼长期发展
建立标准化的智能化算法测试基础设施和体系,为后续百花齐放和持续优化的各种智能算法能力提供高效的测试服务。
# 3 如何实现
# 3.1 AITestDBManager
http://172.16.114.1:7777/AITestDBManagerDoc/site/

# 3.2 AITPortal
# 3.3 资源监控体系
