在机器学习项目实施过程中,软件工程和模型工程的衔接上,存在巨大的技术和思维鸿沟：

• 软件工程师熟悉的主要为软件工程相关技术和架构,对模型工程师的机器学习模型则知之甚少
• 模型工程师熟悉的主要为相关机器学习模型算法,但是对软件工程相关技术则不甚了解

正式因为上述的技术和思维鸿沟,导致了模型工程师建模完成后,系统化落地比较困难。

模型工程师完成数据建模以后,后续模型计算的工作环节如下图所示:

主要流程包括以下四个环节:

• 宽表构建:根据基础数据,准备模型计算所需的基础宽表数据
• 基础预处理:对数据中的缺失值、极值进行基础处理
• 特征工程:原始数据中提取特征以供算法和模型使用
• 模型计算:采用特定的模型算法,根据模型计算结果和特征工程处理后的特征进行模型计算

上述四个环节中,越往后对于软件工程师来讲难度越大,为此很多时候模型部署落地的工作就落到了模型工程师手里,导致模型部署的实现方案各不相同。目前业内常用的落地方案包括:

• SQL 模式:目前最简单的方式,仅支持最简单的逻辑回归、决策树等简单模型,但是对于复杂的特征工程和复杂的模型算法支持极其困难
• Java 模式:通过 Java 代码完成特征工程和模型算法,可以支持绝大多数的模型算法和特征工程,缺点是代码开发工作量非常大,后续复杂的模型更新都需要进行额外的开发
• Python 模式:一般直接由模型工程师直接负责核心代码的编制,由软件工程师进行封装,完成模型的部署,缺点在于软件工程化程度不够,未来的运维、监控比较困难,且很多时候模型落地代码质量比较差
• R 模式:通过 R 服务监听的方式完成模型部署,一般由模型工程师完成模型的部署,需要模型工程师具备良好的软件工程思维

为了更好的划分号模型工程师和软件工程师的分工界面,结合实际业务需要,EPPDEV-MLIB 解决方案应运而生。通过 EPPDEV-MLIB 方案可以很好的区分模型工程师和软件工程师的分工界面,模型工程师负责完成 pmml 文件的构建,软件工程师通过调用 EPPDEV-MLIB 调用网关提供的标准化接口,即可完成模型的计算,具体逻辑如下图所示:

平台模型计算基于 PMML 标准来完成,支持多种常用的建模工具(如 sklearn, spark mlib, R, tensorflow 等),支持多种机器学习模型算法

平台提供了常用的模型调用工具 SDK,支持批量任务调用、hive sql 调用、实时接口调用等多种模型调用方式,可以满足不同应用场景下的系统对接

全分布式高可用架构,任意组件的失效均不影响模型运算的正常运转

当然,本平台仍然有一定的不足之处：

1. 模型构建必须输出为 pmml 格式,这就要求模型工程师在进行特征工程、模型构建是全部使用 Pipeline 方式,客观上会增加模型工程师的工作量,但是相对于模型部署上节约的工作量,这部分工作量基本上可以忽略不计
2. 目前平台仅支持模型部署,暂不支持基础数据建模和模型的定时更新,上述功能仍需模型工程师手工处理,或者开发相信的程序来完成。上述功能已纳入 V2.0 的版本规划中,待后续开发完成后,即可实现系统化建模和模型更新功能