工业中的机器学习是什么样的？不同之处。本文结合笔者十余年的行业经验，试图从行业的角度给出一些思考和结论。欢迎大家批评讨论。行业需要首先定义问题。在行业中，我们所做的一切都是为业务指标服务的。常见的业务指标包括DAU、时长、点击、体验、广告推广等。但是这里的业务问题一般不能直接转化为学术界的分类聚类问题，需要工程师结合自己对业务的理解进行适当的转换。例如广告中优化变现效率可以对应CPM，CPM=BID*CTR*1000（此处近似，由于计费模型不同，可能会略有差异，如GeneralizedSecondPricing下使用下一个bid进行计费）。BID一般是广告商的主观行为。机器学习算法不适合优化，更适合优化CTR。这是常见的点击率估算。可以用分类、回归或排序的思想来做预测。考虑到用户对广告的主观反馈是否有分，建模是分类而不是回归。至于为什么排序很少用到，是因为CTR的绝对值也很重要，在竞价排序和计费中需要用到。在线环境一直在变化。在学术界，机器学习是一项一次性任务。学完这一次，下次就不用担心了。在工业世界中，产品始终在线，它们学习和发挥作用的环境也在不断变化。机器学习是一个不断优化的过程，这就引出了几个很有意思的问题：如何保证学习的及时性，不断学习以适应环境的变化？短期内观察到的效果增益在长期内真的有效吗？历史上证明有效的方法今天是否仍然有效？过去没有收益的优化现在可能会奏效吗？基于当前模型A影响下的行为，我们学习了一个新的模型B，模型B的效果更好，所以替换了模型A。但是模型B的工作环境发生了变化（不再是受模型A的影响），而之前无法模拟这种变化，怎么办？不止一种算法可以用来解决问题在学术界，发表论文的套路一般是先分析一堆算法的缺点，然后根据某个发现点发明一种新的算法，最后用实验来验证这个算法的效果。在工业界，解决问题的套路与这个完全不同。你不需要关心哪种算法更好，也不需要限制一种算法来解决问题。相反，您可以使用多种算法来解决同一个问题。不管是同一个算法的集成，还是不同算法的集成，甚至是把算法连在一起，相互依赖解决问题也是可以的。学术界对集成学习的研究也揭示了集成学习对特定问题的效果往往更好。据我观察，牛叉的算法工程师一般都有自己的算法库。当出现问题时，他们可以同时试验几种不同的算法，并快速组合出一个基本的解决方案。如何量化机器学习应用的效果在学术界，我们常用AUC、准确率、召回率、F值等来评价算法的效果。这些指标可以反映模型在某个维度上的增益，但是在业界，这些指标很多时候并不能直接反映对业务指标的影响。比如CTR模型的AUC就上升了。在线CTR和CPM能提高多少？再者，如果AUC上升了，线上业务的关键指标能不能上升？这通常是不确定的。整体AUC的增加并不代表头部排序效果提升。可能是过滤阈值以下的部分有所改善。这对在线没有实际意义；单个指标上升了，可能会对其他指标造成不可预测的影响，整体可能还是不在线。此外，在线模型和策略往往是并行推出的，这会导致不同算法工程师的工作相互影响。这时候就需要设计一个好的实验机制，尽量减少相互之间的影响，真正体现对自己小块的优化。客观利益。1）需要更谨慎的样本工程在业界，Y标签的选择应该与业务指标直接相关，样本直接决定了机器学习优化的目标和方向。比如优化点击率，自然点击Y标签，或者不点击。但是在很多情况下，Y还是需要经过一些必要的处理才能学习。比如优化播放时间，直接定义Y标签为观看时间不一定合适，因为有的视频长，有的视频短。另外，现在用户基本都是在手机上使用产品，用户所处的环境可能有很大的不确定性，行为的置信度也不同。例如，当你很认真地刷手机和随便刷手机时，跳过内容的置信度明显不同。还有一点很容易被忽视：一款成功的产品涉及多方利益，很多行为未必是正常用户造成的。如何区分这些行为，以及在建模时如何对待它们，是非常有趣的问题。2）需要更重的特征工程在学术界，评价算法一般使用标准数据集，这些数据集的特征已经准备好，只需要输入到自己的算法建模中即可。在工业界，特征是由算法工程师自己处理的，处理的来源不局限于特定的数据源，会有一个近似开放的数据系统。基于这些数据源，可以不断地进行数据关联、数据挖掘、特征组合和选择。算法工程师应该根据自己的经验去思考新的特征、特征组合、新数据的引入。事实上，特征工程在机器学习过程中占据了大部分时间，AndrewNg在最近的一次分享中也提到了类似的观点。此外，不同的场景也有很大的不同。在图片和文本字段中，输入基本确定，看到的是原始信息，是一个完整的输入；但在推荐和营销领域，这个输入是不确定的，理论上，所有影响用户决策的因素都会对建模效果产生影响，这里的特征工程会比较复杂。不同学习任务的耦合是不可避免的。工业界有一种特殊的数据耦合现象——一个机器学习任务的输入是另一个机器学习任务的输出。这种耦合几乎是不可避免的，原因如下：分工协作的原因是一个算法团队有很多工程师，每个人需要分别解决不同的问题；从单任务学习的角度来看，它的学习应该专注于任务本身，不应该与其他目标混合，否则会增加学习的复杂性；从简单的架构来看，分层和子模块是一种自然的架构设计，层与模块之间的依赖关系也是自然的。但是在机器学习中，这种数据耦合是一个高风险的事情（不同于软件工程中的代码耦合），因为下游不能保证你的上游不会出问题（可能只是数据分布的变化，而不是whatBigBUG)，此时如何降低这个风险就很关键了。要优化的目标不是唯一的。在学术界，一个问题确定后优化的目标往往是唯一的。研究人员只需要优化这个指标即可。在工业界，一个业务往往有很多关键指标，比如DAU、点击率、时长、完成率、多样性、冷启动率、头部大V稳定率、广告投放效率等。虽然这些指标可以单独拆卸，它们往往相互影响。这种影响是一种非常复杂的关系，不是简单的相关或独立，而是耦合在一起，甚至说不清楚。虽然我们可以用机器学习来突破它们中的每一个，但是我们在应用学习到的模型时仍然需要将它们进行整合，这就导致了一个严重的问题——也许我们已经很好地学习了一个单点，但是在综合使用的时候，它会有对其他指标的不可预测的伤害。那么你可能很自然地会问一个问题，为什么不用机器学习直接从多目标问题中学习呢？当然有可能。一起学习模型，互相帮助当然好，但是大家可以想一想，这真的解决了多目标耦合甚至冲突的本质问题吗？工业界的机器学习是一个受限的机器学习系统。要解决的核心问题是如何建模和上线，但其输入输出取决于业务系统。能否与现有业务系统顺畅交互，直接决定学习效果的关键要素。在此前提下，将业务系统原有的一些约束直接加入到机器学习系统中。比如业务背景是C++，那么你的机器学习系统也应该是C++，这样会减少很多不必要的兼容性问题。还有一点，机器学习系统往往是在业务系统之后搭建的，需要对业务系统进行改造，比如必要行为的嵌入、数据上报通道、降级处理等，这些都需要验证反复。最后，业务系统本身的性能永远是第一位的。在此前提下，对模型性能的要求基本是有限的。要在此前提下完成特征处理、模型预测等操作，需要平衡性能和应用效果，选择最适合当前情况的算法上线。这也是为什么LR在很长一段时间内一直是业界主流算法的原因。写了一两个小时，发现还是有很多新的观点可以继续讲下去。由于时间关系，先写到这里吧，就当上篇吧，敬请期待下篇。
