17 推荐系统方案中那些不得不知的坑

你好，我是大壮。《易经》中说：“上九：亢龙有悔”。上九是指阳爻在卦中处于最高位，亢龙是指飞向尽头的龙，穷尽至极力终有尽时，力尽则悔，悔不可及。

在前面的 18 讲我们已经讨论了整个推荐算法的演化过程，并经历过实践检验，貌似已经大功告成了。那么，如果我们沿着这条路走下去就一定能一帆风顺么？

答案：当然会有磕磕绊绊。

下面我们就着重讲讲推荐系统实际方案中的那些坑，让你少走弯路。

坑一：到底要对哪个指标负责？

以 58 同城 App 本地服务推荐业务为例，我们需要关注的指标有 CTR、CVR、Call/UV、浏览时长等，那么最应该关注哪个指标呢？

如果我们只关注 CTR，那么低俗内容和标题党就会显现出来；如果只关注浏览时长，那么就会有大量长帖子出现；如果只关注 Call/UV，那么比较短的帖子更占优势。

事实上，这些指标之间属于相互依赖、此消彼长的关系。然而，算法模型多是针对单独的指标进行样本筛选和优化，如果指标不同，结果也就大不相同。

针对这个问题，各大厂的通用做法是把这些互相矛盾的指标通过添加多个超参数连接起来，从而形式一个融合指标。此时，如何取这些超参数又成了一个问题。其实，在实际工作中，大多数的超参数都是拍出来的。

坑二：为什么离线指标很棒，一上线就不行了？

其实这个问题牵扯的东西比较多，这里我主要说两种相对比较常见的原因。

离线训练的数据都是隔天处理，且深度学习模型需要耗费大量的时间和资源对数据进行训练，这就使得上线之后往往模型就过时了，而线上属于实时样本数据。
离线训练的数据是有偏的，而线上实际用于预测的数据是无偏的，比如用户只习惯与某个位置的产品形态进行交互，并不是因为他们喜欢这些物品；再比如用户无法与未曝光的物品进行交互，也并不是因为他们不喜欢这些物品。

除了能够“阴沟里翻船”，还有一些已知的从理论维度尚且没有确定解决方案的问题。

坑三：准确度和丰富度如何两全？

在推荐系统中，准确度决定了平台的收益（“钱”），丰富度决定了用户对平台的“感情”。

俗话说：“谈钱伤感情，谈感情就伤钱”，就像 13 讲讨论的探索与开发问题，通常情况下我们只能牺牲一定的准确度来换取丰富度，从而破解“信息茧房”，以期在短期收益和长期收益中做权衡。

如果一定在两者之间做选择的话？牺牲多少指标收益来保证探索才是合适的，这是一个艰难的抉择，如果牺牲过少，则没有太大意义；牺牲过多，则用户体验在多数情况下是负向。

坑四：如何给推荐的结果一个合理的解释？

推荐系统的交互对象是用户，但是现在的推荐系统对于用户来说就像是一个黑盒，有时会给用户带来“惊吓”。因此，给予用户一个合理的推荐解释很有必要。这不仅可以加速用户决策，起到说服和原谅的效果，还能够建立用户的信任感。

事实上，解释并不是那么容易做出来的，原因总结为两点。

现在的深度学习算法是不可解释的；
解释一件事存在一定概率性和歧义性。比如“他是坏蛋，你是好人”这种描述就比较直白且容易理解，而现实世界往往不是非黑即白，比如“他也许是坏蛋，你可能是好人”。加上受展现的限制，推荐解释要求一定是短句，这就会造成一些解释上的歧义性。比如“开刀的是他父亲”，在没有上下文的情况下很容易让用户误解，父亲到底是医生还是患者呢？

虽说我们无法从根本上解决这个问题，我还是想分享几种解决路径：

通过用户之间的相似性，给出解释是另一个相关用户也喜欢；
利用物品属性之间的相似性，给出解释是看过另一个相同属性的物品（比如导演和主演的电影等）。

虽然推荐系统存在着一些坑，但是对于互联网平台来说它在未来会有更广泛的应用场景，但是推荐算法方面仍然存在着可以深度探究的领域，总结如下：

从懂到更懂用户和物品

其中的挑战主要是多种数据类型，如文本、图像、音频等，而且特征关系复杂，数据内部关系复杂等。通过深度学习范式对丰富的辅助信息和上下文信息的提取，通过大量隐式反馈样本数据，以及更加复杂的模型拟合能力等。

从复杂到更复杂的模型

组合多个深度范式构成深度复合模型针对异构特征进行建模，目前这方面的模型扩展还很有限，特定领域必然会出现更加有效的模型。本专栏模块三、模块四给出了大量的范式组合例子。

时间可以改变一切

利用新的建模方式捕获用户动态的需求，并且能够融合用户长期和短期需求。另外用户和物品的共同进化也是时间影响的重要方面，因为用户和物品特征可以独立发展并随着时间的推移依赖于共同演化。

多件事一起做

跨域推荐和多任务学习旨在通过使用从其他领域转移的知识来改善一个领域的任务或者通过使用从其他任务辅助另一个任务的学习，可以提供隐式数据增强，以减轻稀疏性问题。

弹性可扩展

不断增长的数据量和模型参数计算量给推荐系统效率水平带来很大的挑战。可扩展主要体现在数据可扩展性和模型可扩展性两个方面。可以把数据分片，并在片段上进行模型学习，或者在数据片段上进行建模，然后将子模型合并计算推荐结果。

如何达到开悟的阶段

经过本专栏的学习，我相信你已经具备了大量的知识深度和理解深度。如果想达到开悟的阶段，则需要经历以下几个阶段：

第一层：势

把势作为第一层并不是说“势”不重要，其实这正好相反。道德经中说：“道生之，德畜之，物形之，势成之”，由此可见势的重要性。

比如 2008 年我在朗讯贝尔实验室实习时，当时做了一个 IMS IM（即时通信）项目，它支持通过 PC/M/App 三端免费接打电话、互发短信/网路消息/语音等，类似后来的微信业务功能（甚至还要多一些）。不过，因为那时智能手机的市场保有量很低，也就是说客户量很小，最终导致项目入不敷出、垮掉了，这就是不符合当时的“势”的一种体现。

第二层：器

作为一名工程师，实操能力是触发一切职业发展可能的基础，也决定了一个人能否成功。

因此，除了借势之外，我们还需要具备一定的具体落地实操的能力，比如如何解决埋点问题？如何使用大数据平台清洗处理数据？如何优化线上代码提升运行效率？如何使用 TensorFlow 或 PyTorch 上一些算法模型等。

第三层：术

“术”即驾驭“器”的能力，这里为了方便理解，我们比方说“器”是保时捷，“术”是驾驶技术。如果驾驶技术不好，就算开保时捷也会掉沟里。

而在本专栏中，“术”指的就是推荐工程架构设计，即不同场景下选择什么推荐算法模型和特征工程等。因为对一名工程师来说，了解不同的技术，知道如何选型是进阶的基础。

第四层：法

“法”是将“道”从理论层面落实到实践层面的关键（即规章制度），具体来说就是规则、流程、步骤。比如推荐系统的工作流程是先对基本数据和反馈数据进行加工，再利用加工结果进行决策。从框架上来看，它需要经过数据采集、数据加工、数据决策、效用评价这 4 个阶段，而本专栏阐述的这套框架就是推荐系统的“法”，因为任何技术只有在合理的框架下才能够延续和发展。

从算法角度来看，算法的原理和推导过程同样也是“法”，它是实现模型的指导方针，这点本专栏在推荐算法的“法”上也有比较充分的介绍。