深度学习推荐系统实战_42_33技术权衡解决方案这么多哪个最合适
你好，我是王哲。
今天我想和你聊聊技术权衡这个话题。
在实际的工作中，我们经常会面临一些技术上的抉择。
就比如在设计推荐系统的时候，我们是该用模型a还是用模型b是用TNNFLLW还是用patch? Ch,是用REDIS还是用EV cash呢？那从理论上来说，其实选哪个方案都可以。
但在工程落地里，不同的方案对系统整体的开销以及整个团队的工作量，以至最终的推荐效果都有着非常大的影响。
我想这也是很多算法工程师的困惑。
那工程落地环节的解决方案有这么多，我们到底该选哪一个呢？今天我们就一起来探讨一下技术权衡的问题，看看能不能在理论知识和工程落地之间找到一条最优的路径。
工程和理论之间的权衡，是所有工程师都要考虑的问题。
对这个问题的思考方式决定了你具备的是工程思维还是研究思维，又或者是学生思维。
那推荐系统是一个工程性特别强，以技术落地为首要目标的领域。
因此，工程思维对推荐系统工程是最重要的。
事实上，无论是算法工程师还是研发工程师，甚至是涉计电动汽车、神舟飞船、长征、火箭的工程师，他们的职责都是一样的，那就是在现有实际条件的制约下，以工程完成和技术落地为目标，寻找并实现最优的解决方案。
这里边有一个词最关键，那就是制约。
那这个制约怎么理解呢？比如说在机器学习领域的理论层面，一切的事情都是理想化的。
就像模型结构是精确定义的，训练过程是严格推导的。
但是实际条件下一个模型的训练过程会受到算力条件、数据质量、工程时间限制等等很多条件的制约，这也是我们不得不面临这么多的选择和权衡的原因。
再比如说我有些同学在航天领域工作，那最近趁着嫦娥五号任务圆满完成的热点，我咨询了他们一个问题，说咱们国家什么时候能实现载人登月啊？他们这帮航天工程师的回答当然也非常严谨，说制约咱们国家载人登月的，主要是火箭的运力问题。
那现在的长征五号火箭近地轨道运载能力是二十五吨。
那当初美国阿波罗计划使用的土星五号火箭运载能力是一百四十吨，整整差了五倍多。
你看所有的工程师都会受到客观条件的制约，那怎么办呢？他们又讲了，要么就一步一步来，先攻克运载火箭技术，再像阿波罗计划一样，一发火箭，把登月舱、返回舱、航天员等等一起火到月球。
要么就是用现在的长征五号发射四到五枚火箭，在太空中完成登月舱返回舱载人飞船的组装。
那第一个计划的优势是一次性搞定，但是周期长，需要等待火箭技术的攻克。
第二个计划的优势是，现在就可以开始着手做，但因为要发射四到五枚火箭，整个任务的容错率低，风险大。
所以你看航天工作者们发射火箭也是成天抱怨运力不够，就像我们训练模型，总说算力不够一样，那怎么办？日子就不过了吗？当然不是，我们工程师就是要在这样的制约条件下又快又好的解决问题完成任务，这就是你的职责所在。
那推荐系统中现有实际条件的制约都有什么呢？我们经常会遇到这么三种，第一种是软硬件环境的制约，第二种是研发周期的制约。
第三种是实际业务逻辑和不际应用场景的制约。
正是因为有这些制约的存在。
一名工程师不可能向学术界的研究者一样，不断的尝试新的技术，做更多探索性的创新。
也正是因为工程师永远以技术落地为目标，而不是炫耀自己的新模型新技术是否走在业界前沿。
所以在前沿理论和工程现实之间做权衡，是一名工程师应该具备的基本素质，而不个技术权衡，具体应该怎么做呢？接下来我就用三个实际的案例帮助你体会一下。
第一例子，怎么在READIS容量和模型上线方式之间进行权衡。
那对于线上推荐性来说，为了进行工线线服务，需要把特征和模型参数存储到线上数据库或者线上服务器的内存里。
那为了保证这两部分数据的实时性，很多公司采用了内存数据库的方式来实现。
就像我们在第十课里讲的那样，REDS这类内存数据库自然就是主流的选择了。
那是啊REDIS需要占用大量的内存资源，而内存资源又比存储资源和计算资源稀缺昂贵。
因此啊，无论是亚马逊的AWS,阿里巴巴的阿里云，还是公司自建数据中心，实现REDIS模块的成本都比较高，那自REDIS的容量就成了制约。
推荐模型上线方案的关键因素。
由于这个制约因素，我们在实现线上服务的时候，就要考虑两方面的事情了。
一方面，模型的参数规模要尽量小，特别是对于深度学习推荐系统来说，模型的参数量级比传统模型提升了几个量级，所以我们更应该重点考虑模型的参数规模。
另一方面，因为要考虑线上预估延迟和特征存储空间有限的情况，所以线上预估需要的特征数量也不能无限制的增加。
要根据重要性做一定的删减。
因此，在实际上线推进型的时候，我们必然需要进行一定的取舍，舍弃一些次要的要素，关注主要的矛盾。
具体怎么做呢？那这里我结合自己的经验，把整个取舍的过程做了一个梳理。
一共可以分为四步，你可以作为参考。
首先，对于千万量级甚至更高量级规模的特征向量维度来说，因为线上浮很难支持这种级别的数据量。
所以我们在上线模型的时候，需要更加关注模型的稀疏性和复杂度，通过舍弃一定的模型预测准确度，来换取上限的速度和资源的消耗。
明确了工程权衡的时标，我们就要思考怎么提高模型的稀疏性，降低模型的复杂度。
那提高稀疏性的常见方法是加入l one的正则画像，或者采用FTL这类稀疏性很强的训练方法，让大部分的参数归零，从而减少模型的体积。
那对于降低复杂度来说，我们可以通过减少神经网络的层数以及每层内的神经元的数量来实现。
当然，这个方法只有在不明显降低模型效果的前提下才是可行的工程策略。
那在明确了多种备选方案之后，如果还是没有办法确定哪种技术效果更合适，我们就需要实现所有的备选方案，还有方案里的各种组合进行离线和线上的效果测试。
最后，我们需要根据效果测试的结果，最定最终的技术方案，完成最终的落地方法。
这了刚才我说的这些就是模型测的瘦身方法。
那在在线特征测的瘦身计划，当然也可以采用同样的思路。
比如，先采用主成分分析的方法进行特征筛选，这不显著降低模型效果的前提下，减少所用的特征。
其次，针对不好取舍的特征进行离线评估和线上AB测试，好，就达到工程上可以接受的水平。
那除了硬件条件的限制，研发周期的制约同样是不可忽视的因素，这就需要工程师对于项目有整体的把控，对于研发周期有比较准确的预估。
那在产品日益迭代迅速的互联网领域，没有人愿意成为拖累整个团队最慢的一个环节。
那接下来我以一个平台迁移的例子来讲一讲如何在研发周期的制约下完成技术决策。
那比如说公司希望把机器学习平台从spark ML整体迁移到TENOFFW上，毫无疑问，这是顺应深度学习浪潮的一个技术决策。
是非常正确的决定。
但由于spark平台的特殊性，那它的编程性，那模型训练的方式都和TNL flow有很大的差别。
因此整个迁移必然要经历一个很长的研发周期。
那我就经历过很多公司产品和技术平台的大规模升级，很常见的情况是在保证平台升级正常进行的。
同时，我们还需要兼顾日常的开发进度去实现一些新的产品需求。
那这就是工程师需要做出权衡的时候了，也是最考验工程师架构能力的时候。
在这样的情况下，一般来说有两种可行的技术方案。
那第一个方案是就是集中团队的力量，先完成spark到TENFOW的迁移，然后在新平台上进行新模型和新功能的研发。
那第二个方案是让团队一部分成员利用成熟稳定的spark平台快速满足产品需求。
那为TNNFOW的迁移调试试运行留足充分的时间。
同时呢让另一部分成员全力完成TNSFLOW相关的工作，尽量保证新平台的成熟和可靠。
如果单纯从技术角度考虑，既然团队已经决定迁移到TENF flow平台了，理论上就没有必要再花时间利用spark平台研发新模型，否则到时候还需要进行二次开发。
但是，再成熟的平台也需要整个团队磨合，调试较长的时间，绝不可能刚迁移到teninl flow,就让它支持重要的业务逻辑。
而且技术平台的升级逻辑应该作为技术团队的内部项目，最好对其他团队是透明的，不应该成为减缓对业务知持的直接理由。
因此，从工程进度和风险角度考虑，那第二个技术途径显然就更符合工程实际的需求。
那最后我想来谈一谈来自于业务逻辑，或者说应用场景的制约。
啊，最常见的比如说有物品的冷启动问题。
那这类业务问题往往制约了模型的更新和应用的方式。
那之前我们讲了很多种生成物品embedding的方法。
但是在任何公司的业务中，物品都不可能是一成不变的。
就像视频网站要不断的添加新视频电商网站，会不断的加入新的商品。
这个时候新物品的embedding该怎么生成呢？对于item to act d book这类基于物品节点的embedding模型来说，数据中必须包含有新物品的ID,才能够生成跟它对应的embedding.这就要求我们必须加快模型的更新速度，让模型尽快学习新物品ID对应的数据。
那这就是业务场景特点在倒逼我们改进模型的实施性。
因为我们不提高实施性比的一物品就无法生成embedding.那这个时候我们就要思考改进embedding模型实施性的方法了。
方。
同样我也结合自己的经历，总结了三个备选方案，你可以用来参考方案。
一是从模型训练pipeline的各个环节入手，看看哪些环节可以优化。
比如说我们可以优化spark数据预处理的过程，加快预处理的速度，优化embedding上线的过程，或者让embedding从产生到上线的过程更紧凑，那整体的过程就加快了模型的训练的速度。
那方案二就是从模型的复杂度入手，看看能不能在不显著上级效果的前提下，通过降低模型的复杂度来降低训练时间，从而加快模型更新的速度。
那最后一种方案就是跳出end to end训练embedding模型的限制，看看能不能通过其他策略性的手段来生成临时性的新物品embedding.那在这三个方案里，那前两个方案需要我们从细节入手来优化工程上的实现。
而第三个则要求我们有更灵活的处理思路。
这一点也是我想跟你多聊一聊的一个点。
那我们在改进推荐系统的时候，不能总是陷入机器学习的固定思维里，认为一定要用一些机器学习的模型或者深度学习网络去解决问题。
我把这样的思维叫做技术洁癖。
我们应该清楚的是，工程师的第一任务是解决问题，而不是搭一个非常精致好看的技术玩具。
所以在推荐模型的基础上用一些策略性的手段来修补一些边界情况。
Bad case是可以去尝试的那回到这个物品embedding冷启动的例子上，策略性的生成新物品的embedding就是很好的补充方式。
那举个例子，那短租行业的巨头airb BB就给我们提供供一成很好的参考的方案。
那在air BNB这个平台上，如果一个新的出租屋发布了，但是魔镜还没有学到它的embedding LBNB的推荐系统会怎么做呢？它会通过三个步骤生成新出租屋的embedding.第一步，根据新房屋的属性，比如租金价格、房屋类型、面积、几房几厅等等的特征。
先找到和它相似的一批房屋。
第二步，在这些相似房屋中找到离它最近的三个。
第三步，通过平均这三个最近房屋的embedding来生成新房屋的embedding,就像文稿中示意图展示的那样，颜色相近的点代表着embedding非常接近的房屋。
如果一个新的房屋落在了图中的某个位置，LBB就可以根据它的地理位置和属性只们相近的房屋，并且给它涂上相似的颜色。
所以我们经常会看到，一些推荐系统中的补充策略，往往可以高效的解决一些推荐模型无法解决的棘手问题。
当然，在我们日常工作中，技术间的权衡无时无刻不再发生。
小到一个变量，取什么名字好，一行代码应该怎么写？大到一个平台，应该怎么重构？一个模型应该怎么构建我们这节课的例子？当然没办法把所有的情况都讲到。
一是希望能帮助你建立起正确的进行技术权衡的取路，做到抓住主要的矛盾，做出有利于主要目标的取舍。
好了，这节课讲完了，我们一起来做个总结。
那这节课我通过三个例子带你一起讨论了工程落地中的技术权衡问题，希望能够进一步加深你对工程师职责本质的理解。
那事实上，对于任何领域来说，工程师职责的本质都是在现有实际条件的制约下，以工程完成和技术落地为制约，寻找并实现最优的解决方案。
那在推荐系统领域典型的制约条件有三类，软硬件环境的制约，研发周期的制约，以及实际业务逻辑和应用场景的制约。
在这些制约条件下，我认为的技术方案间的权衡之道，用一句话总结就是抓住主要矛盾，抓出备选方案。
通过分析对比，做出有利于主要目标的取舍。
最后我们来看一道思考题。
那这节课我们提到了物品冷启动问题的解决方案，你觉得基于一beding还有哪些好的冷启动的解决方案呢？如果让你来解决的话，在实践中你会做出哪些取舍，倾向于哪种选择呢？期待在留言区看到你的分享和思考。
我们下节课见。