推荐系统优化之困局与破局之道

奇技指南

本文为大家介绍笔者在多年工作中总结的一些关于推荐系统优化的经验。

本篇为算法系列文章第5篇，由360信息流算法团队投稿。

  前言  

我多年以来，一直在从事推荐系统优化相关的工作，虽然期间有过短暂的金融风控经历，但这丝毫没有影响我对推荐系统的关注。从最开始的基于余弦相似度来实现item的协同推荐，到如今各种传统的、非传统的；浅层的、深层的；nn的、概率的；判别的、生成式的机器学习算法，我基本上都了解并使用过。有时候，面对业务、场景、数据的特殊性，还需要自己琢磨一些算法出来。现在推荐系统对统计学习模型的使用可谓无处不在，同时，行业内的交流也越来越多、越来越通畅，大家所使用的算法和模型也无出同行之右太多。

别人家的道理

然而相信很多同学都有过这样一种体会，我们既不想错过任何一场同行间的算法交流，同时又残酷地发现：各家讲的道理似乎都差不多，而且貌似只在他自己的手里有用，回来之后花了不少成本学着做了上线，效果却让人十分沮丧。似乎正应了那句：“纵然听了很多道理，但依然做不好自己的推荐系统”。同样，即使这篇短文能够有幸被您翻阅，它本身也无法直接帮您解决任何系统中存在的实际问题，因为它讲的依然是别人家的道理。

做推荐系统的我们几乎每时每刻都在跟“优化”打交道，这里讲的优化不是建模过程中的优化算法，但我们依然可以通过它来理解优化的本质。算法中的优化，对且仅对一个问题负责，那就是你为算法设定的损失函数。至于这个损失函数设置的否合理，是否能够解决系统的问题，就不是优化算法能够决定的了。因此决定一个优化过程是否有效的因素至少包含两点：

1. 问题的设定；

2. 优化方法或路径

基于AB实验的优化周期

我们期望并且假设推荐系统是一个可量化的系统，当然，我们也希望系统中的每一个优化过程也都是可量化、可通过业务指标来真实反应的。然而，真实情况则是，推荐系统中能够完全量化的优化过程很少。相信你肯定不止一次遇到离线指标杠杠滴，上线AB就强差人意。或者运气好点，AB实验有收益，并且长期实验坚挺依旧，但一放量就又萎了。更有甚者，即使实验流量放到90%，AB实验的相对收益依然明显，但悲剧的是整体指标并没有在同比、环比上有相应的提升。即使你足够幸运，实验流量放到90%以后，不光AB实验对照有收益，而且整体同环比也有相应的收益。我们仍然面临着，这个收益能够持续多长时间，会不会在一段时间之后收益消失的问题。

这一道道关口都闯过之后，才是一个完整的策略优化周期。整个优化周期就像一个剥洋葱的过程，由外而内一层一层地剥开，最终是否真的如愿，有时候真的需要点运气。

你可能已经发现，上述优化周期过程中的每一步都可能由于各种各样的问题导致结果与预期不符。即使你足够高瞻远瞩也有足够的运气，能够走到最后，周期也基本上是以月为单位计时的。这里面的变数你得认真考虑了。记得有一次推荐算法的分享沙龙上一位同学提问，大概意思是：“我已经做了了2年多的算法优化，各种推荐算法也尝试了不少，系统就是没有提升，该怎么办？” 我能说什么呢，如果我们把推荐系统的优化，比喻为武功修行，越往后越难。而所有的算法、框架、技巧等都只是第一层的东西。具备了第一层的技能，只是从事推荐系统优化工作的最基本要求。这只是必要条件，但远不是充分条件。当你真正完整地走过一个优化周期，并拿到收益，知其然也知其所以然的时候，所谓的算法反而不那么重要了。就像天龙八部中的乔帮主，在聚贤庄只用“太祖长拳（宋朝开国军体拳）”就把天下英雄打得哭爹喊娘一样。

既然推荐系统的优化不取决于算法，那优化又从何而来呢？其实很简单，系统之所以需要优化，不是因为指标不如人意，或者KPI还未完成。而是我们发现了系统中的某些问题，正是由于这些问题的存在才导致系统的表现不如人意。如果你实在找不到也无法定位系统的问题，或者压根没往那方面想，那出于对你负责的态度，奉劝你最好离这项工作远一点，因为你一定会变得很沮丧，沮丧到让你怀疑人生！

AB实验的无能为力

其实直到现在，我们所谈论的问题都还是相对友好的。我们假设推荐系统是一个可量化系统，有强有力的工具和平台支持我们做各种实验。很多时候我们的优化策略只是没有对系统产生正向的收益而已。即使策略对系统有伤害，也可以及时地从指标上得到反映，并及时止损。然而，推荐系统中至少还有两类场景是AB测试无能为力的。

1、非即时反馈策略的优化

这类问题，顾名思义就是短期无法观察的优化操作，但时间长了又不可观察。我们完全有理由相信过程中总会发生一些情况来影响策略在未来的表现。尤其是那些在短期会对系统有一定损失的优化，大概率会因为业务指标的压力而夭折。即使你自己作为优化策略的制定及实施者，也无法保证策略在未来的收益，能够将现在挖的坑填上。如果填不上咋办？只能凉拌了。如何取舍就真的考验人对系统整体的理解了，所谓经验，不外如是！

2、系统流程的优化

AB系统的适用点在于既定流程相对稳定，只优化其中一个环节的情形。我们针对这个环节实现平行的两个策略进行对比实验，得出在当前流程的前置及后置情况下，哪种策略会对系统的指标有正向收益。这里要注意两个问题：1，AB实验的结果不能完全体现两种策略本身的优劣，是有条件的；2，如果流程中需要优化的环节不止一个，而是一连串。试图通过几个环节的优化让整个流程更合理。问题在于各环节之间是互相影响的，且对系统的影响非正交。为了操作，我们只能将各个环节的组合作为一个独立的存在，实现从根本上将系统切成完全独立的流程。你会发现除了人不够用之外，系统100%的流量也根本不够用了。

不忘初心，摸着石头过河

推荐系统的优化似乎并没什么确定的策略保证能够切实有用，甚至我们连如何衡量一个优化策略是否真正起到了作用都极难做到。那我们这些号称做算法的推荐系统工程师，成天都在瞎忙乎啥？

其实正是因为推荐系统的优化有时候很难量化，所以才需要人在里面进行把控。如果一切都可以量化，那公司也不用养这些推荐算法工程师了，搞个automl就好了嘛。其实，比起盯着AB指标不放，我们更应该关注一下几点：

1、不做根本上不正确的事情

我不知道做什么一定正确，但至少可以知道做什么一定不正确。虽然我没吃过猪肉，但我至少见过猪跑。你非要诓我说这头猪成天挂在树上练习臂力，因此前腿肉卖的会更贵一些，那就说不过去了。

2、把本该正确的事情做对了

其实多数情况下，我们做的事情并不复杂，也并没有多高大上。所谓算法无非就是做些加减乘除，再辅以简单的ETL过程。但很多时候，我们还是会犯很低级的错误，导致系统的表现远低于策略生效的理论值。也导致我们错误地认为本该有效的策略无效。为了填这个坑，又不得不做更复杂、看起来更高大上的方案，然后又会挖更大的坑。挖坑界的“蝴蝶效应”就是这么来的。

3、越简单、越可靠

越复杂的方案涉及到的环节就越多，需要假设的条件也越多，实施起来出错的概率当然也就越高。手再稳的人，在概率面前也得认命。如果一个简单的方案能够达到理论效果的70%~80%，那我建议不惜一切地拥抱它。

4、适可而止，不做过度优化

从两方面考虑：

1. 投入产出比：一般来讲一个问题的优化，越往后越难。遇到这种情况，别轴，换个问题。我们只需要将一个问题优化到不成为系统的瓶颈即可。这就是系统优化过程中的“跨栏”原则；

2. 推荐系统的易变性：越复杂的方案依赖项及假设会越多，而这些大多数时候并不在你的控制范围内。如果强制要求依赖项不可变，那这个方案本身又成了系统进一步优化的限制条件。那时你又会陷入如何抉择的两难境地。所以，每一步都走的短一点，才能走的更远一些，步子太大就容易扯着。为什么学习率设置的不能太大，就是这个道理。

  总结  

综上，不论我们是作为算法工程师，还是工程架构师，或者是产品运营，推荐系统优化最根本的要求不是要我们懂多高深的理论和算法，而是要我们认真用心地发现、抽象、定义系统中存在的问题，并尽可能以最直接、最小假设、最不容易出错的方式去解决它。如此而已，毕竟大多数情况下，“以我们对产品和系统的理解，还真没到需要拼算法的地步！”

界世的你当不

只做你的肩膀

无

 360官方技术公众号 

技术干货|一手资讯|精彩活动

空·

我知道你在看哟