如何构建阿里小蜜算法模型的迭代闭环？

导读：伴随着AI的兴起，越来越多的智能产品诞生，算法链路也会变得越来越复杂，在工程实践中面临着大量算法模型的从0到1快速构建和不断迭代优化的问题，本文将介绍如何打通数据分析-样本标注-模型训练-监控回流的闭环，为复杂算法系统提供强有力的支持。

新技术/实用技术点：

1. 实时、离线场景下数据加工的方案选型
2. 高维数据的可视化交互
3. 面对不同算法，不同部署场景如何对流程进行抽象

01. 背景

1. 技术背景及业务需求

小蜜系列产品是阿里巴巴为消费者和商家提供的智能服务解决方案，分别在用户助理、电商客服、导购等方面做了很多工作，双十一当天提供了上亿轮次的对话服务。其中用到了问答、预测、推荐、决策等多种算法模型，工程和算法同学在日常运维中会面临着如何从0到1快速算法模型并不断迭代优化，接下来将从工程角度介绍如何打通数据->样本->模型->系统的闭环，加速智能产品的迭代周期。

1. 实现

实现这一过程分为2个阶段：
0->1阶段：
模型冷启动，这一阶段更多关注模型的覆盖率。
实现步骤：
A. 抽取对话日志作为数据源
B. 做一次知识挖掘从日志中挑出有价值的数据
C. 运营人员进行标注
D. 算法对模型进行训练
E. 运营人员和算法端统一对模型做评测
F. 模型发布

1. 痛点

在以上过程中，会遇到如下几个痛点：
A. 不同算法需要不同的标注交互形式，如何快速支持
B. 运营方的标注凭借个人感觉，缺少指导，无法保障质量
C. 线上badcase如何快速发现和修复
D. 机器人中部署了上百个算法模型，日常维护需要占用工程师大量的精力
E. 数据样本在业务和算法之间来回传递，有安全隐患
02. 闭环迭代模型的产生

1. 模型训练闭环

基于以上的痛点，阿里小蜜团队构建了模型训练闭环。该闭环系统主要包括对话系统层、数据层、样本层和模型层这4个部分。

彼此之间的关系、流程如下：
A. 对话系统层：用户端会跟机器人系统进行对话
B. 对话产生的日志经过数仓埋点进入到数据层
C. 数据层由运营人员做标注
D. 完成标注的数据作为样本，借助算法团队提供的训练/评测服务，进入到模型层
E. 模型发布到系统中，形成训练闭环

1. 系统 => 数据

① 多维数据查询
这一部分讲述如何从系统层到达数据层，这里会涉及到“多维数据查询”这样一个概念。前面提到，数据来源的渠道是多种多样的；这些数据会具备多种多样的属性，例如：行业属性、用户类型属性等。不同业务的对话日志带有各自的业务属性。

数据立方体结构的不足：
A. 维度类型。对于商家这种百万数量级的维度，搜索起来效率低下。针对这种缺点，选择对于重点商家重点维度进行存储。
B. 多条件的or关系查询，在这种立方体结构中无法实现。
C. 枚举数量和效率的平衡。需要根据具体覆盖业务定义属性等。

1. 数据 => 样本

① 标注组件
数据标注环节由“人工智能训练师”这个角色参与，标注形式会根据算法的选择而调整，包括：标签、实体、属性间关系等。
如下图所示：

03. 实时布防

1. 语料关键词的识别与添加

1. 实时布防

1. 数据加工

从业务日志中提取模型需要的语料需要进行一些基本的算法加工，这些步骤除了面临大数据的压力，研发工程师还要考虑对这种加工能力的封装和复用。

模板中包含了算法组件、标注组件、训练组件等不同的组件；运营人员在线上可以挑选不同组件配置模板来优化对应的模型。
在模板执行的过程中，可使用mapreduce组件、UDF组件以及Spark组件。Spark组件是目前通用性较强的组件，既可本地调度，又可远程调度。

1. 构建数据处理引擎

基于Spark构建数据处理引擎，分为客户端和计算集群两个系统。客户端包括组件库、调度引擎，以及Spark Client Runner。

这种架构的好处：算法可以在本地开发spark组件，直接集成到模板中；同时支持远程集群模式和本机轻量级调度，大小数据量都适用；同时spark拥有 SQL和spark mllib两个组件库，研发通过封装可以直接开放给业务使用。
本次分享就到这里，谢谢大家。
欢迎加入DataFunTalk交流群，跟同行零距离交流。如想进群，请加逃课儿同学的微信（微信号：DataFunTalker），回复：交流，逃课儿会自动拉你进群。