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