第四范式先知平台的整体架构和实现细节

编者按：“范式大学”由第四范式发起，致力于成为培养工程师转型为数据科学家的“黄埔军校”。专栏专注于以人工智能解决具体商业问题。在这里你将会看到，企业如何通过可实施的方法完成 AI 转型；个人如何通过最新的科技工具，快速成为能解决问题的机器学习工程师。

大家好，我是来自第四范式的胡时伟，今天很高兴能够和我们的算法科学家涂威威一起跟大家分享我们在 AI 开发平台“先知”产品的一些经验，共同探讨机器学习从系统和工程方面的优化方向。

接下来主要从如下几个方面来讲述：

1. 为什么人工智能系统需要高维大规模机器学习模型
2. 训练高维大规模机器学习模型算法的工程优化
3. 机器学习产品的架构实践

首先先从人工智能发展说起，人工智能并不是一个最近出现的概念，早在 60 年代就有著名学者曾经预言二十年内机器将能够完成人能做到的一切工作。到今天我们又听到说 20 年之内，一大半的工作岗位将被机器人替代。那么 60 年代到今天发生的最大的区别是什么？这其中发生了两个重大的变化，第一个是计算能力的突飞猛进，今天的手机一个核的计算能力就足以秒杀当年的超级计算机。第二个是我们拥有了大数据，TB 级的数据存储、处理在今天已经不再困难，而 20 年前，GB 级的硬盘才刚刚兴起。

因此我们说今天人工智能 = 机器学习 + 大数据，那么什么样是好的人工智能呢？这里引入一个“VC 维”的概念。“VC”维是 1960 年代到 1990 年代由 Vapnik 及 Chervonenkis 建立的一套统计学习理论。VC 维反映了函数集的学习能力，VC 维越大则模型或函数越复杂，学习能力就越强。之前，统计建模曾经进入过一个误区，就是去追求经验风险最小化，什么意思呢？就是说我希望建立一个模型，在给定的样本上不要有误差，这样感觉非常好，但是往往这么一来，在实际的预测中非常糟糕，这是为什么呢？是因为采用了一些 VC 维很高的模型，虽然函数集学习能力是强了，但是由于数据不够，所以导致置信风险变大产生了一些类似过拟合的情况，最后这个模型还是不好用。

但是今天我们进入了大数据时代，样本的数量，包括样本的特征丰富程度有了极大提升，这就又带来了提升 VC 维的新机会。我们经常说经验主义害死人，过去的建模就是害怕经验主义，所以呢就把这个大脑变笨，降低 VC 维，使得模型更有效。但是今天的大数据情况下，可以通过补充更多的阅历（数据），来避免经验主义，那么一个阅历丰富的聪明的人，自然是要比一个笨的记不住东西的人要好的。因此我们说大数据人工智能时代，提升 VC 维变成了一个好的人工智能系统的关键因素。

那么机器学习中的高维度从何而来？传统方法只能利用可以放在特征矩阵这个平面中的数据，对于立体的数据，多维度的数据，因为它们多不是数字，所以传统机器学习模型无法处理，只能选择舍弃。但在实际工业应用中，这类非数字化的数据所包含的信息，往往信息价值很高，比如它可能对个性化推荐很有影响，可能对泛化处理有帮助。为了能成分利用这些数据，我们对特征矩阵外的立体的数据通过切片等算法进行变换，使得变换后的数据成为特征矩阵的一部分，同时还对不同特征之间进行交叉组合等操作，这样特征矩阵的每一行的列数就从原始数据的列数，变成了每一行都是一个巨大（比如 2 的 64 次方）的向量，形成超高维度的模型。

高维度模型真正的意义何在？通过对原来立体数据切片处理，可以使得某些过去只能有简单线性表达的数据，比如年龄等，获得更接近真实情况的细腻体现；此外，原来机器学习不能利用的非数字、没有排序关系的数据，比如姓名等，也可以发挥其价值所在。举个例子，在个性化推荐的场景中，体现个性化信息的数据之间通常是不可比的，比如，我们先只考虑热度、推荐序号和用户 ID 三个变量，其中用户 ID 这个变量就是传统机器学习模型所不能利用的，只有通过将这个数据切片处理，获得一个高维度模型，才可以真正将用户信息这个数据发挥出价值。

要获得一个成功的高维度模型，就需要好的机器学习系统，这个系统应当具备两个特征：横向可扩展的高计算性能和算法本身在收敛过程中的正确性。为此，我们的算法工程团队开发了一系列的基础设施组件，组成了大规模分布式机器学习框架 GDBT（General Distributed Brain Technology）。GDBT 是一个由 C++ 编写的，完全分布式的适合于机器学习计算场景的计算框架，可以运行在单机、MPI、Yarn、Mesos 等多个分布式环境。

大规模分布式机器学习框架 GDBT

机器学习是一种数据驱动的实现人工智能的方式，机器学习在实际应用中的大数据、高维度背景导致需要一个高效计算的平台，同时，监督学习领域著名的 No Free Lunch 定理指出，没有一个机器学习模型能够对所有的问题都是最有效的。所以在不同的实际问题里，需要使用不同的机器学习算法或者对机器学习算法做适应性地调整，去达到更好的实际效果。因此在实际的应用中，需要能够非常容易地开发出适应实际问题的机器学习算法。相比于传统的 ETL 计算，机器学习算法的计算过程有很多自身的要求和特点。

在框架设计上，没有普适的最好的框架，只有最适合自身应用场景的框架。GDBT 框架的设计初衷主要就是打造一个专门为分布式大规模机器学习设计的计算框架，兼顾开发效率和运行效率。GDBT 框架不是某一种算法，而是一种通用的机器学习算法计算框架，使算法工程师可以基于 GDBT 开发各种传统或者创新算法的分布式版本，而不用过多地关心分布式底层细节。

目前比较流行的计算框架比如 Hadoop、Spark 其重点任务大多是 ETL 类的任务。前面提到机器学习计算任务相比于传统的 ETL 计算任务有很多自身的特点，时间有限这里可以简单地展开一下。

在计算方面：相比于 ETL 会做的一些相对“简单”的运算，机器学习算法会对数据做相对复杂的运算，一些非线性的模型，比如深度学习模型会需要比较密集的计算；在实际的应用中，需要考虑不同计算资源的特性；分布式计算中，由于分布式带来的通讯、同步、灾备等等的 overhead 需要调整计算模式来尽可能地降低。

在通讯方面：很多机器学习算法在计算过程中会频繁使用到全局或者其他节点的信息，对网络吞吐和通讯延迟的要求要远高于 ETL 任务。同时，很多机器学习任务对于一致性的要求要低于 ETL 任务，在系统的设计上可以使用放松的一致性要求。

在存储方面：ETL 需要处理来源不同的各种数据，比较少的反复迭代运算，很多机器学习算法会对数据做反复的迭代运算，可能会有大量的不断擦写的中间数据产生，对存储的使用效率、访问效率有着更高的需求。

在灾备和效率的权衡方面：容灾策略有两方面的额外开销，一方面来自于执行过程中为了容灾所需要做的额外的诸如状态保存之类的操作，另一方面来自于灾难恢复时所需要进行的额外重复计算开销。这两方面的开销是此消彼长的。与 ETL 计算任务不同，机器学习计算任务流程相对复杂，中间状态较多，在较细的粒度上进行容灾会增加执行过程中的额外开销。因此在容灾策略和容灾粒度上，机器学习计算任务和 ETL 计算任务之间的权衡点不一样。

GDBT 计算框架针对机器学习任务在计算、通讯、存储、灾备等方面做了深入的优化。时间有限，这里可以简单的讲一点 GDBT 的工作，有兴趣了解更多的同学可以会后再和我们联系，或者加入第四范式一起解决这些有趣的问题：）

在计算方面，计算硬件发展到今天，提升计算能力的主要方式是堆积计算能力的分布式并行计算，比如现在做深度学习非常流行的 GPU 本身也是一种并行计算硬件，针对不同需求的计算硬件的种类也在变多，比如 FPGA 等等。对于大数据、高维度、复杂的机器学习计算任务，GDBT 框架充分考虑了分布式并行计算的特点，针对不同的硬件资源、不同的算法场景做了调度、计算模式、机器学习算法部件的抽象等的优化。GDBT 框架本身在设计上也刻意避免了现在一些框架设计容易走入的误区。比如：为了分布式而分布式，但是忘记了分布式带来的 overhead。GDBT 框架针对单机、分布式模式分别进行了优化，框架本身会对不同规模的计算任务、不同的计算环境做自适应的调整选择更高效的实现。

然后在通讯方面，通信效率是分布式机器学习系统中至关重要的部分。首先, 相比于 ETL 任务, 很多机器学习算法在计算过程中会频繁使用到全局或者其他节点的信息, 对网络吞吐和通讯延迟的要求都很高。其次, 一些机器学习算法在通信时可能有很多可以合并处理的通讯需求。再次, 很多机器学习算法并不要 求在所有环节保证强一致性。最后, 对于不同的网络拓扑, 最优的通讯方式也会不一样。因为存在可能的合并处理、非强一致性需求、网络拓扑敏感等, 就会存在有别于传统通讯框架的优化。先知的 GDBT 计算框架内部, 针对机器学习计算任务单独开发了一套通信框架, 为机器学习任务提供了更高效、更易用的支持点对点异步、点对点同步、深入优化的组通讯 (比如类 MPI 的 Broadcast、 AllReduce、Gather、Scatter 等等) 的通信框架, 同时为应用层提供了简便易用的合并、本地缓存 等等功能。

然后介绍下我们在参数服务器（Parameter Server）方面的工作，很多机器学习算法的学习过程都是在“学习”一组参数, 对于分布式机器学习任务, 不同的节点需要对“全局”的这组参数进行读取和更新, 由于是分布式并行的计算任务, 因此存在着一致性的问题, 不同的机器学习算法或者同一个机器学习算法的不同实现对一致性的要求会不尽相同, 不同的 一致性策略对整体算法的效率会产生很大的影响。参数服务器就是为了解决分布式并行机器学习任务中多机协同读取、更新同一组参数设计的, 设计上需要提供简单易操作的访问接口方便机器学习专家开发算法, 同时也需要提供可选择的一致性策略、灾备等等。

另外，由于是为机器学习任务设计，参数服务器的设计目标是高吞吐、低延迟。GDBT 中的参数服务器针对不同的应用场景做了更 加深入的优化, 结合高效缓存、智能合并等优化策略以及基于 GDBT 自带的高效异步通讯框架, 同 时, 还针对稀疏、稠密等不同的参数场景进行了针对性优化 ; 内置提供了丰富的一致性策略可供用户选择或自定义一致性策略；GDBT 将参数服务器看成一种特殊的 Key-Value 存储系统, 对其进行了独立的灾备设计, 同时提供不同粒度的灾备选项, 便于在实际的部署中选择合适的灾备策略提升效率。

这次我主要讲计算框架方面的工作，以后有机会可以再详细分享我们在机器学习算法框架以及机器学习算法方面的设计工作。针对机器学习算法计算，GDBT 框架做了进一步的抽象，比如数据流、优化算子、多模型框架等等，这里简单介绍下数据流的设计。对于研究并实现机器学习算法的专家而言，算法的核心就是数据的各种变换和计算。GDBT 框架为了让机器学习专家更容易、更快速地开发出不同的机器学习算法提供了数据流的抽象，使得机器学习专家通过描述数据流 DAG 图的方式编写机器学习算法。机器学习专家只需要关注数据的核心变换和计算逻辑，GDBT 计算框架将机器学习专家描述的数据流图进行高效的分布式计算。

数据流计算框架的抽象一方面有助于降低机器学习专家的开发门槛、提升开发速度（他们不需要关注底层分布式、并行细节），另一方面也为 GDBT 框架提供了更大的空间去进行数据流执行优化，能够进一步提升执行效率（如果 GDBT 框架只在底层模块进行优化，将会非常乏力；但是数据流的抽象使得 GDBT 框架能够更全面地了解计算任务的 pattern，可以做更多的优化工作）。

在存储、灾备设计等方面，GDBT 也做了深入的优化，比如多级缓存的设计、框架层面对存储读取写入、网络访问、计算过程等等的灾备设计，对不同计算规模采取不同的灾备粒度等等，这里时间有限，就不做过多介绍了。机器学习算法部分的工作以后有机会可以再一起交流。

GDBT 定制的通信框架、算法框架以及参数服务器，为进行大规模机器学习训练提供了基石。当然 GDBT 还有一个很大的特性是算法开发者友好，对于算法开发来说，学术研究和工业应用之间存在一定的取舍。一些其他的算法框架比如 Tensorflow，比较注重研究上的易用性，从而在效率上有所舍弃，而一些注重于生产应用的算法框架特别是分布式框架，在算法二次开发和扩展上则捉襟见绌。GDBT 提供的是工业级的开发者易用性，从语言级别，GDBT 整体基于 C++ 14 标准，为算法的开发提供了更大的自由。从功能抽象上，GDBT 提供了对参数服务器和算子的良好包装，在 GDBT 上，只需要数百行代码就可以实现像逻辑回归、矩阵分解等算法的分布式版本。

机器学习算法框架的语言选择问题

关于机器学习算法框架的语言选择 **** 问题，因为今天很多的大数据框架都是基于 Hadoop/Spark 这一套的，都是 JVM 上的东西，因此基于 JVM 从整体来说接入生态是比较容易的，但其实有三点理由让我们选择 C++ 而不是基于 JVM去做这件事情。

首先我们前面讲过，目前虽然计算能力对传统应用来说井喷，我们经常说 CPU 过剩、GPU 过剩。但是对于高维机器学习过程来说，依然是资源非常紧张的，这里面包括计算、网络、内存等多个方面，我们看 Spark 的 Project Tungsten 也做了大量堆外内存管理的工作以提升数据的处理效率，但是对机器学习来说，基本上整个过程都需要对内存和计算过程进行精细控制，以及避免不可控的 GC 过程。

其次，C++ 的一些语言特性，比如运算符重载机制也可以使得框架上层的算法应用的语法比较简单优雅，不会变成巨大的一坨，而大规模机器学习很多时候和字符串组成的离散特征打交道，C++ 对字符串处理的效率也要高出 JVM-Based 语言非常多。

再次，Spark 目前的机制和 Parameter Server 的结合很难做到优雅和完美，强行对接 PS 会破坏 Spark 自身的灾备、任务调度等特性。如果不对接，那么就基本上只能靠降低模型大小来确保效率，和高维度的目标南辕北辙。所以综合考虑，我们还是选择 C++ 来实现整个一套的系统，而将和大数据框架的对接以及开发门槛降低这个任务交给整个机器学习系统的架构。

整体架构

上面讲了很多机器学习算法框架，但有过实践经验的朋友都知道，光有一个算法框架只相当于汽车有了发动机，离开起来还很远。我们总结一个完整的机器学习系统需要有如下部分：

• 数据引入和预处理
• 特征工程
• 模型训练算法（支持参数灵活调整和二次开发）
• 模型评估
• 模型上线（批量预估、实时 API 调用、线上特征实时计算）

那么对于这所有的部分，我们开发了一个叫『先知』的整体平台产品，我们先看一下先知的整体架构图：

(点击放大图像)

整体来说，先知平台由界面层、调度管理层、集群适配层、集群任务执行层，另外外加一个线上的预估服务云。

这套架构能够给我们带来如下几个优势：

1. 把整个机器学习过程作为一个整体来看待，做到各模块的深度整合。下面是我们产品的一个截图

(点击放大图像)

可以看到，通过一个DAG 图的描述，可以将大数据的处理过程（SQL/PySpark/ 数据拆分）和机器学习的过程（特征工程、模型训练、模型评估）整体结合起来，用户不再需要去开发脚本去处理复杂的模块和模块之间的对接以及输入输出的各种判断。

同时呢，这个DAG 图的背后我们还做了很多工作，一个比较有意思的就是对存储的抽象和适配。我们有的客户是用AWS 作为基础设施，而有的客户用阿里云做基础设施，有的客户则选择在IDC 内构建自己的机房。这里面就有块存储、云盘、SSD、内存盘等多种存储服务。

另外，一个完整的机器学习过程，往往还要从数据库里面导入数据，最终要把数据导出到某个指定的位置。导数据在逻辑上的复杂性和由于某些开源模块不支持内存缓存和SSD 导致的性能的低下都是困扰数据科学家的问题。

对此设计了一个两层的存储抽象层API，第一层是一个开源项目alluxio，就是以前的tachyon，alluxio 这个东西是非常好的，好在哪里呢？他用一套解决方案一下子解决了几个问题，第一是可以支持很多分布式的文件系统，包括S3、Ceph 等。第二还能够比较透明的解决内存和SSD 加速的问题。针对Alluxio 这个项目，我们将整个的数据处理、模型训练、预估体系，包括我们自己开发的GDBT 框架都和alluxio 做了深度的融合集成，也针对开源的产品在访问调度、吞吐、SSD 优化上做了一些增强和修补的工作。

第二层是DataManager，我们知道企业的应用，特别在意安全性，那么如果我们直接把底层的文件系统暴露给使用者，会导致权限隔离等个方面的隐患。Datamanager 提供了一个数据的逻辑沙箱，使得每个使用者在自己的DAG 里面只能用一个唯一的名字来访问到自己安全容器内部的数据，这样不仅保证了安全，也避免了使用者直接去处理各种各样的长的数据文件的URI。

2. 给开发者提供比较好的体验，相信使用大数据系统的朋友都有一个感受，就是在分布式时代，调试变得难了。一方面很多时候日志太过于复杂，不知道错误在哪里，另外一方面经常出现跑了几个小时报一个错前功尽弃的情况。先知平台从产品上做了很多工作，比如说 Schema 推断

我们可以在运行这个 SQL 之前就在界面上交互式的看到哪里出了错误，以便及时改正，而不需要整个 DAG 图跑了几个小时，运行到这个地方的时候，可能人都去睡觉了报个错，只能第二天再来。另外比如我们还提供了特征重要性评估的功能：

这个功能可以让使用者很快发现自己模型里面的问题，比如某个特征重要性极高，需要考虑自己的模型是不是有看答案（用结果去训练模型，再去评估结果，导致模型线下评估效果非常好，线上无效）的现象。值得一提的是，这个特征重要性评估的算法也是基于 GDBT 框架开发的，GDBT 不仅可以高效的支持各种模型算法开发，也能够快速的支持各种其他的大规模分布式计算逻辑。

3. 支持模型的上线，模型上线有几个技术上的难点，一是线上线下的一致性，而是性能。线上线下一致性为什么难，因为你看到训练过程是那么复杂一个 DAG 图，那么对应的线上多个数据源，也要经过一个组合、变换的过程，那如果每次都去手动开发，这个代价就不得了。

先知的架构支持从线下的 DAG 导出线上服务的核心部分，那么特征工程、模型计算就可以直接获得一个可用的 API，可以极大的节省开发者的代价。另外一个难题就是性能，因为线下批量的训练，可以花很长时间，而线上如果是实时预估，那么就要毫秒级的响应，也要求很高的 QPS。

我们在线上有一个叫 Cannon 的分布式 KV 框架，可以支持到数十 T 分布式内存的模型高性能存储和查询。而模型计算的部分也可以复用 GDBT 的代码，既减少了开发量，又为一致性提供了保证。这里面也有很多有意思的工程优化，比如说如何解决机器数变大、网络条件变差情况下的可用性塌方式下降。今天时间有限就不展开说了，有机会可以再跟大家分享。

小结

非常感谢大家耐心听我们分享了上面我们做的这些微小的工作。第四范式是一个以产品研发为主的公司，我们有数十个来自于各大国内外公司顶尖机器学习团队的优秀工程师，各路 ACM 冠军选手每天在各个方向上做很多深入的产品和工程优化工作，希望能够促进机器学习和 AI 在各行各业的发展，也希望能够给从业者们带来更好用的平台和工具。

当然做出好的机器学习解决方案，最关键的还是要和行业结合，工具和平台系统只是其中的一小部分，所以还希望能够向各位同仁多多学习。这里打个小广告，现在先知平台公有云版本已经向业务场景成熟的企业客户有限名额的开放合作，如果有风控、内容推荐、客户经营等场景，数据量较大的朋友，我们也可以一起互相切磋，互相学习。谢谢大家。

Q&A

Q1：请问先知平台用到深度学习框架了么？

答：现有的开源的深度学习框架不能完全解决先知平台客户的问题，因为很多实际的问题，除了包含稠密的连续特征之外，还有大规模的稀疏离散特征，目前大部分的开源框架大多 focus 在稠密连续特征的深度学习问题上，对学术界比较关心的同学，可能可以发现 google 最近有一篇 wide&deep learning 的论文是做类似的事情的，这个解决方案和我们三年前在百度做的解决方案很类似，但是很可惜的是开源的 tensorflow 在这个问题上效率非常糟糕。实际问题的难点在于它是 IO 密集（大规模稀疏）且计算密集的（稠密），而且这样的模型是极其难调的，我们有很多新的算法在解决这方面的问题，不仅仅是深度学习。

Q2：是通过何种机制做到数百倍的加速的？

答：从算法设计到 GDBT 平台设计和底层优化，都有很多工作，今天的讲座里面有涉及到一些，可以翻看记录；

Q3：有没有提出一些最优化框架，比如 SVRG 等来加速收敛？

答：对于不同的问题，不同的场景，会对优化算法有不同的需求，比如收敛速度、稀疏性、稳定性、是否便于实现、是否便于分布式并行、是否访存友好等等，先知支持多种优化算法（batch/stochastic 的都有），比如 lbfgs、FOBOS、RDA、FTRL、SVRG、Frank-wolfe 等等都会有涉及，同时针对不同的应用场景也需要做一定的改进和调整。

Q4：超参数学习这块是通过 bayes 还是强化学习呢？

答：目前产品中的是 bayesian 的，其他方式也正在尝试。

Q5：在何种情况下如何判定自动特征不能起作用而改为人工特征呢？

答：有很多特征选择的算法和策略，同时，对于实际的问题，可以先用自动特征处理取得一个初步的效果，再从实际模型效果去看是否需要人工介入做进一步的优化，自动特征工程是一个很难的问题，目前其实是很难做到 100% 全自动的，我们平台期望能够尽最大可能的降低人力。

Q6：先知在实现过程中用到参数服务器了没有？ 模型的训练，是采用异步 asp，还是同步 bsp，还是半异步的 ssp 这种？ 如果是异步，如何解决收敛困难的问题？

答：前面有提到，我们用到了 parameter server。模型训练支持多种模式，对于不同的算法，不同的计算环境，会采用不同的同步方式。其实目前大部分情况下，如果数据切分 计算调度得当，异步和同步差别没有特别大，计算资源有较大差别的时候，还是建议带版本控制；更好的方式是采用类似的计算资源做好数据切分和计算调度。

Q7: 第四范式的先知和谷歌的 Tensor flow 有什么区别？

答： 从覆盖范围上，先知是一个机器学习应用全生命周期管理的平台，而 Tensorflow 对应的是先知的 GDBT 部分。而对于 GDBT 和 Tensorflow 的区别来说，前面也讲到，首先 Tensorflow 更多是为算法研究目的而存在的，已经有一些 benchmark 说明 tensorflow 比目前很多开源的深度机器学习框架都要慢，所以也有个外号叫 Tensorslow。当然我个人觉得这并不公平，因为 Tensorflow 本身也不是为大规模工业应用设计的，只是现在好的框架的确太贫乏了。Tensorflow 的一些设计理念比如高兼容性，跨平台也是很好的。这方面 GDBT 也都有考虑和规划。

Q8：GDBT 有没有解决模型并行训练问题？还是只依靠数据并行？

答：也分不同的算法，GDBT 同时支持模型分布式和数据分布式。

Q9：GDBT 怎么能够同时支持连续、离散的这两种数据的融合训练？

答：解决这个问题，一个是效率，首先框架底层上要能够支持很灵活的调度，能够根据连续和离散的数据的计算特性做针对性的设计，比如连续复杂模型是计算密集，可能需要调度到 GPU 运算，离散数据可能是 IO 密集，需要做好计算调度，资源异步调度；更重要的是在算法上做更多的新的改进，因为学术界大多情况下是分别考虑，我们有一系列自己重新设计的算法。对算法细节有兴趣的同学，可以考虑加入到第四范式，或者等我们的专利公开:)

Q10：请问 GDBT 对于异构计算的支持情况如何？

答：GDBT 目前支持 CPU 和 GPU 的异构计算。在百度的时候，我们有过在模型预测时使用 FPGA，不过，最近 GPU 进展不错，比如 nvidia 有一些新的芯片比如 Tesla P4 的出现，可能会对 FPGA 有一定的冲击，对于 FPGA 的使用，目前我们研究上还是跟随状态，并没有集成到先知产品中。

Q11：第四范式的人工智能平台先知可以直接替代 Spark 么？

答： Prophet 诞生的原因是因为我们为各种行业提供服务，每个行业的差异化乍一看都不少，按照传统的方式，我们需要 case by case 的去应对，给出对应的方法，然后进行实施。但在这个 case by case 的过程中，大部分的精力是花在如何把对领域专有知识的理解（业务理解）转换为机器学习过程的具体操作（数据科学家的工作），对于端到端的两端，数据 和 服务，反而是比较通用的。那么如果能够利用技术和算法，解决专有知识到对应机器学习过程的映射问题，我们就可以建设一个通用的平台来使得 AI 应用到不同场景的代价变小，实现人工智能的傻瓜机。Prophet 就是这个目标的第一步。

首先 Prophet 定位在一套完整的平台，包括核心机器学习算法框架 GDBT（没错不是 GBDT，这是个算法框架，其作者起名为 General Distributed Brilliant Technology），以及机器学习任务调度框架 TM，以及人机接口 Lamma，还有架设在整个框架上的一系列算子。当然这些都是内部名字无所谓，总的来说 Prophet 提供的是端到端的机器学习能力，进来是数据，出去是 Service。

然后关于 GDBT 和 Spark，应该说对比的是 基于 GDBT 的算法 以及 基于 Spark 的算法（MLLib 实现），由于计算架构的不同，所以简单的来说多少多少倍是没有太多的意义，因为如果特征纬度多到一定程度，MLLib 在不做数据采样的情况下是无法完成某些训练的。但是具体在几千万行，几十个核的场景下，快几百倍是实测结果。

另外，我们在做的事情，算法框架是一个部分，性能也是很重要的，但是做这些的目的是为了降低机器学习应用于具体行业的门槛和先决要求。这个先决要求既包含硬件上的，也包含人在机器学习方面知识的要求。拥有更强大的计算能力和特征处理能力，意味着我们可以更少的让人输入信息，而更多的依靠计算机自身的学习和计算来找到机器学习算法在具体问题上应用的最佳结合点，这其中甚至还需要包括如何去利用计算资源的投入避免机器学习常见的一些缺陷。

因此 Prophet 不会替代 Spark，Prophet 里面的很多组件也是基于 Spark 的，Prophet 的目标是把 AI 的能力较为容易的带到各个应用场景，为了这个目标，我们会利用好 GDBT，也会极致的利用好 Spark，也会利用硬件技术的最新进展。一切为了 AI for everyone。

（以上部分来源于知乎： https://www.zhihu.com/question/48743915#）

简单的来说，先知的设计范围超出了 Spark，包含了 Spark，所以不能说是替代。

Q12：什么样的企业用得起机器学习来辅助运营？使用你们机器学习系统的门槛是什么?

答：从目前来看，需要有一个好的业务场景和足够的数据。互联网的 APP 或者非常大的传统行业里面的推荐、营销、定价等场景都比较适合。数据量小的就要看，通常来说 10 万多样本分布均匀就有这个可能。用这个机器学习系统目前的门槛是首先要能理解数据和业务，有一定的统计的背景和思路，然后就是能够导入导出数据，最后就是阅读一下先知的使用手册和培训视频。

Q13：电商推荐平台，怎么样能最快地应用机器学习的精准推荐？

答：对于推荐场景，我们有相对比较成熟的接入方案，可以快速通过数据和 API 接入，通过公有云的 SaaS 服务享受到 GDBT 的能力以及先知的整体效果。有需求的朋友可以关注我们的官方网站和公众号（NextParadigm），我们会近期放出先知推荐的试用邀请。

Q14：机器学习目前哪些企业和行业应用比较广泛？国内有哪些成功案例。

答：大规模机器学习，BAT 今日头条等，广告推荐为主，成不成功请看他们收钱增长的速度特别是百度 09 年之后的增长。我们在银行最近的探索也有很多成功的例子，比如在营销和定价、反欺诈方面。另外风控一向是机器学习的主战场。

Q15：自动特征这套做法，跟百度凤巢的那套是一样的对吧？ 百度有公开论文，是 gradient boosting factorization machine，这个方法比深度学习那个自动特征相比如何

答：做法和夏粉老师的那套不一样；夏老师和张潼老师这篇文章和 nn-based 的各有优劣。其实 NN 没有大家想的那么万能，“人工”的很多 feature combination 是 NN 学不出来的，其中有很多有趣的问题，这里就不赘述了，可以再交流。

另外：对于 FPGA 和 GPU 的未来我们有一段简单的思考，之前有准备过一段，之前没用上，现在贴这里：

FPGA 是作为专用集成电路领域中的一种半定制电路而出现的，既解决了全定制电路的不足，又克服了原有可编程逻辑器件门电路数有限的缺点。机器学习尤其是深度学习是计算密集型的，比如深度学习里面有大量的浮点矩阵运算这种并行浮点运算需求，传统的 CPU 从设计上而言已经很难满足这种大规模浮点计算密集型任务。目前针对这种机器学习任务，CPU 主流的替代选择是 FPGA 和 GPU。

GPU 是固定的计算架构的计算设备，有着良好的软件编程接口，但是对于特定的计算模式和模型结构不一定是最优的选择。FPGA 本身是一种可编程的硬件，对于有研发能力的厂商而言，深度优化过的 FPGA，相比 GPU，能够提供更专有的硬件加速，更重要的是 FPGA 在单位能耗上能提供的计算能力要高于 GPU。

另外，企业级 FPGA 也比企业级 GPU 便宜很多。但是 FPGA 的缺点也非常明显，对相关专业人才的要求非常高，需要能够将复杂的机器学习算法映射到硬件逻辑上，同时提供高吞吐和低延迟，开发难度很大。对于中小公司而言，如果没有相应的 FPGA 研发能力，或者无法支撑高昂的研发成本，在机器学习尤其是深度学习的训练 / 预估硬件解决方案上可以选择架构固定的 GPU；

而对于有相应能力的大中型企业而言，FPGA 带来的硬件成本的大幅降低和能耗的大幅降低，能够轻易覆盖研发团队的费用，在机器学习尤其是深度学习预估的硬件解决方案上 FPGA 会是更合适的选择。

同时，在制造工艺上，相比于 FPGA，GPU 是固定的专用计算架构且不提供可编程能力，可以通过不断的芯片优化，提供更强的计算能力，对于计算更加密集的深度学习训练任务，GPU 现在还是更合适的选择。随着 GPU 在芯片上不断优化提升和能耗的降低，以及 FPGA 不断提升芯片可提供的计算能力，两者的差距在不断缩小，未来两者的地位是否会有大的变革，值得期待。

讲师介绍

胡时伟 第四范式联合创始人，研发副总裁

在大规模机器学习、广告、搜索、行业垂直应用、系统运维、研发团队管理等领域拥有丰富经验。

曾主持架构了百度“知心”系统和链家网系统，在百度任职期间作为系统架构负责人，主持了百度商业客户运营、凤巢新兴变现、“商业知心”搜索、阿拉丁生态等多个核心系统的架构设计工作。在担任链家网研发负责人期间，从 0 开始完成了链家网新主站、经纪人新作业系统、绩效变革系统的整体架构设计以及研发团队的建设管理，参与规划及推动了链家系统和研发体系的互联网化转型。

现任第四范式研发总工程师，负责产品技术团队以及第四范式核心产品『先知』机器学习平台的研发工作。

涂威威 第四范式数据建模专家

在大规模分布式机器学习系统架构、大规模机器学习算法设计和应用、在线营销系统方面有深厚积累。

百度最高奖 trinity 发起人之一。

首次将 FPGA 应用于在线营销深度学习预估系统。

设计开发百度机器学习计算框架 ELF。

感谢杜小芳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。