前言
从接触机器学习/深度学习一开始，我们看到的就是各种数学公式，算法和模型。毫无疑问，这些理论性的工作是ML的坚实基础，也是非常值得深究的领域。但是，这里，我想多说一些点关于机器学习工程化的东西。在工业界，机器学习是用来解决实际问题的，比较常见的像广告CTR预估，推荐系统等。相对算法来说，机器学习的工程化工作，同样决定了这个模型的价值，而且影响不小。
在线服务
大多数刚接触ML的同学，对ML的整个流程认识其实是不全的。缺的这一环，就是模型上线，也就是模型对外提供预测的服务。模型真正实时的对外提供服务，才意味着发挥着作用和价值。
简单来说，机器学习的在线服务就是一个server使用模型，根据实时提交来的数据，返回predict的结果。跟所有的在线服务一样，它面临着同样的问题，延迟，吞吐量和稳定性。即使有一个非常准确的模型，它的判断逻辑非常复杂，每一次predict都会带来巨大的开销，那这个模型也是无法在线上使用的。基于这个情况，简单的LR模型，是工业界比较青睐的模型，尽管它准确性比其他复杂模型稍差一点，但是在线服务的性能好，能带来更多的收益。
那么我们在这方面的工程化需要关注什么呢？第一，和其他在线服务一样，关注它的各个性能指标，如95、99延迟等等。第二，如何提前知道一个模型的性能指标。这里性能并不是指AUC，准确率这类，而是影响着predict的指标，比如特征维数，模型大小等。模型的大小(对于LR模型来说，其实也是特征维数)影响了加载时的gc，查找权重的时间开销。LR模型做预测时，相当于就是拿特征去查表，然后得到各个特征的分数，求和。主要的开销就是查表。工程化需要做的就是，在确定模型上线会对线上服务带来影响地情况下，拦截住模型更新，这需要是一种自动化的工作。
数据的管理
类似的，大多数刚接触ML的同学都是从一个干净的数据开始自己的ML之旅的。这样的坏处就是，让人忽略了一个重要的事情，数据源可能会有问题。
一个发挥着巨大作用的机器学习系统，往往它是每天不断更新的，我们称之为“自学习”。每天产生了大量的上游数据(简便起见，称之为数据源)，这些数据喂到了一个旧的模型，得到一个更好的新的模型。每天的新的数据会不会出现问题呢？答案，当然会。这些数据时时是在变化的，它受用户的请求而变化，也受上游系统的逻辑而影响。对于我们(消费这些数据的人)来说，我们需要做的是，如何最快地检测上游数据出现问题，避免脏数据污染当前的模型。当然，污染之后，如何恢复也是一个工程上需要考虑的问题。我们需要了解数据源，知道它的数据规模、分布、极值等等统计指标，在消费它们之前发现是否有异常。是的，这需要工程化，自动地完成。
前面提到了，当模型被污染了，我们需要快速恢复。最基本的，我们要有快速回退模型版本的机制。其次，我们要感知和管理数据的版本，当数据恢复时，通过一整套操作，切入到一个较早的时间点，重新训练，更新。
我们可以将数据源，特征数据，模型都看成是数据，那么，我们需要做的管理工作就很多了，当然，最后能做到(功能)的也很多。
线上线下的一致性
一致性非常重要，它意味着，线下训练的模型实实在在地能在线上起作用。举个例子，假设离线训练时，拿到的某个数据和线上拿到的不一样，同一个用户，线下标记为男，线上拿到的是女，那这个模型在predict的时候，在“性别”这个特征上肯定是没用了。线上线下不一致的原因有很多，我们需要做的是，从工程上消除部分不一致，如线上线下代码复用，代码版本管理(线上线下版本同步)，数据重构只存一份(备份另说)等等。另外，工程上，我们需要提供发现不一致的机制。一些不一致比较细微，宏观上并不能发现，但是实际上它却实实在在的在影响着效果，长期下来，带来的损失还是比较大的。
