在你做推荐系统的过程中都遇到过什么坑？

Posted 2021-05-01 21CTO

导读："天问的E&E"、"线下 AUC 涨，线上 CTR/CPM 跌"，我们经常遇见坑，就像今天的标题少了个字。小编最近在浏览知乎大佬文章的时候，发现了一个有意思的话题："在你做推荐系统的过程中都遇到过什么坑？"。吸引了3,091关注者、被浏览192,713次，多位知乎大佬参与了回答 。

今天小编特意为大家推荐几个知乎大佬高赞的答案，大家一起来看看，这些坑你是否曾经也踩过吧~~

01

其实推荐系统是一个技术远远达不到需求的领域。今日头条已经算是国内推荐领域的相当不错的水平了，仍然颇受诟病。

在我看来，规则啊什么的都不算坑，作为系统工程，规则是架构灵活性的一部分，规则保证了系统的人工把控能力，是必不可少的一部分，相当于最强的先验，没有必要厚此薄彼。但是除此之外，问题还有很多。

1. 搞不懂的评价指标

推荐系统太难了。难到工程师和产品都还没清楚自己要的是什么。"推荐"这个问题本身都不是 well-defined 的。按照道理来讲，推荐系统要做的事情其实是"推荐用户希望看到的东西"，但是"用户希望看到的东西"落实到指标上，可就让人头大了。

以新闻推荐为例。你说究竟要得到什么呢？

• 高 CTR？那么擦边球的软色情以及热门文章就会被选出来

• 高 Staytime？那么视频+文章 feed 流就成为为视频 feed 流和超长文章 feed 流

• 高 read/U？那么短文章就会被选出来

这些指标相互依赖，此消彼长，目前主流是沿用计算广告的老路，按照 CTR 作为最广泛使用的评价指标来优化，这个指标的劣根性是显而易见的，然而至今并没有很好地指标来指导系统。

今日头条的做法是，优化 CTR 同时关注其他指标的变动；也有的从 CTR 开始，优化到瓶颈后进行 Staytime 的优化等等...

Medium 的做法是，优化一个 f(CTR, staytime,...) 的多指标加权的综合指标，但是据我所知，这个加权的系数，还是一个 magic number，是人拍脑门定的。

Pornhub 的做法是，优化一个 -staytime 的指标，用户停留时长越短，则越好，其基本假设就是"撸完嫌人丑"。很多人对这个指标拍案叫绝，但是其实这给公司的商业化部门带来很大压力，因为如果用户停留时间短，则流量变现会变得很困难。

大家都在探索， 也并没有一个定论，究竟推荐系统该优化一些什么。

相信很多人刚入行的时候对单纯优化 CTR 都是有疑惑的，日子久了，也就都麻木了。

2. 好的算法与不那么好的效果

有的算法确实很好，好到推荐的每个我都想点，但是算法越精准，在用户体验上未必是越好的。

举个例子，我喜欢汽车，电竞和科技。

好的推荐算法真的就推荐汽车电竞和科技，都是根据我的历史记录推荐的我确实喜欢的。

但也就只有汽车电竞和科技而已。

换句话说，好的推荐算法毫无疑问地会局限你的视野。

那他还是好的推荐算法么？

这个问题听起来就有点矛和盾的意思。有的时候我甚至在想，一个稍微差一点的推荐算法，是不是反而长期看是体验更好的？因为它不仅照顾了用户的核心兴趣，也稍稍辐射了一些边缘领域，在感兴趣和不感兴趣的边缘试探着。

就像下面这个高斯分布的图，绿色的"高瘦子"毫无疑问要优于红色的"矮胖子"，因为它像一把尖刀，更精准地直插兴趣点，但是究竟"精准的高瘦子"是不是真的好呢？

"矮胖子"还是"高瘦子"？

说到精准和探索，又不得不提 E&E 了。

3. 天问的 E&E

E&E，exploration & exploitation，这个真的是天问。

E&E，简单说，就是保证精准推荐的同时，进行兴趣探索。

一说大家都明白了，这不就是所有推荐系统做的最差的地方吗？我看了一个东西，就使劲出一个东西，App 明明很多东西，我却越用越窄。

这个问题更加玄学，更加让人无奈。

EE 要不要做？肯定要做，你不能让用户只能看到一类新闻，这样久了他的 feed 流只会越来越小，自己也觉得没劲，所以一定要做兴趣探索。

但是做，就势必牺牲指标，探索的过程是艰难的，大部分时间用户体验上也是负向的。

那么：

• 牺牲多少 ctr 来保 EE 才算是合适的？

• EE 的 ROI 什么时候算是>1的？

• 怎么样确定 EE 的效果？

• EE 要 E 到什么程度？

其实大家也都没有想清楚，多避而不谈。

E&E 就像玩扫雷游戏，你不知道给用户推荐的下一个东西会让你留住这个用户并继续开疆辟壤，还是 BOOM 的一声，GAME OVER，用户留存-1

02

关注这个问题有一段时间了，重点说下一种推荐系统最常见的坑：

线下 AUC 涨，线上 CTR/CPM 跌

这两年深度模型大火之后，各个团队都卯足了劲把网络规模做大做深，花了很大力气好不容易离线 AUC 涨了不少，上线一看效果 CTR 和 CPM 反而下降。可能的原因有几个：

1. 特征/数据出现穿越

一般就是使用了和 label 强相关的特征导致的数据泄漏。这种问题一般相对好查，很多时候在离线阶段就能发现。明显的表现就是训练集和测试集差异比较大

2. 线上线下特征不一致

据我所知，这种情况是导致离线涨在线跌或者没效果的最常见情况。

首先是代码不一致，例如，离线对用户特征的加工处理采用 scala/python 处理，抽取用户最近的50个行为，在线特征抽取用 c++ 实现只用了30个。只要离线和在线用不同的代码抽取就很容易存在这种代码带来的不一致。

另外一种线上线下不一致，是由于数据的不一致导致。这在离线拼接样本和特征的 Pipeline 中比较常见。一般离线特征都是按照天处理的，考虑各种数据 Pipeline 的流程，处理时间一般都会有延迟，离线特征处理完之后导到线上供线上模型预估时请求使用。

这种不一致都是怎么产生的？例如4月15日这天，线上预估请求用的特征是4月14号的特征数据。到了4月16日，特征 Pipeline 开始处理数据，到了凌晨4点，离线特征处理完了导到线上。那么在4月16日0点-4点，这段时间线上请求的特征使用的是老的特征数据，也就是4月14日的特征数据。4月16日4点-24点，线上特征使用的是4月15日的数据。而在离线样本生成过程中，到了4月17日0点，如果是按天拼接的，那么4月16号这天的所有样本，都会使用4月15日的特征。

这样，4月16日0-4日的样本，在离线样本拼接的阶段，使用的是4月15日的特征数据，而在线上请求特征的时候使用的还是4月14日的特征。特征 Pipeline 流程处理越长，这种不一致会越大。

要严格保证线上线下的特征一致性，最根本的方法就是同一套代码和数据源抽取特征，业内目前通用的方法就是，在线实时请求打分的时候落地实时特征，训练的时候就没有特征拼接的流程，只需要关联 label，生成正负样本即可。

3. 数据分布的不一致

如果仔细排查，既不存在数据泄漏，也没有出现不一致的问题，离线 AUC 明明就是涨了很多，线上就是下降，而且是离线涨的越多，线上下降越多，还有一种可能就是数据的不一致，也就是数据的"冰山效应"----离线训练用的是有偏的冰山上的数据，而在线上预估的时候，需要预测的是整个冰山的数据，包括大量冰面以下的数据！

这种情况其实在推荐系统里非常常见，但是往往非常的隐蔽，一时半会很难发现。我们看下面这张图。左边是我们的 Baseline，绿色的表示正样本，红色表示负样本，灰色部分表示线上由于推荐系统的"偏见" ( 预估分数较低 )，导致根本没有展现过的数据。

离线阶段，我们通过各种优化，新模型的离线评估表现更好了，例如图中第二列，可以发现第4个绿色的正样本和第7个绿色的正样本排到了第3和第6的位置，离线的auc指标涨了。

到了真正线上的预估也就是第三列，发现对于这部分离线见过的样本，模型的预估序并未改变。但是新模型给了灰色没有见过的数据更高的预估分数，这部分数据一旦表现不好，很可能造成我们前面说的情况，离线 ( 第二列 ) 评估指标明明涨了不少，在线 ( 第三列 ) 评估指标 CTR 却下降。

这种情况也不是必现的，在 LR 以特征工程为主要迭代的时代很少见。主要的原因是模型的前后迭代差异并不大。新模型对比老模型最主要的特点是新加入了一部分特征，往往模型的打分差异并不大，从图中第二列到第三列，原来那些冰山下的数据也就是旧模型预估分数偏低的部分，在新模型中能够脱颖而出拿到很高的预估分数的概率并不高。

而在模型有较大变化的时候，例如 lr -> 树模型，lr -> 深度模型，不同网络结构的深度模型变化，这种情况容易出现，原因就是新旧模型的变化较大，预估分数变化也较大。

举一个简单的例子，假设我们的 baseline 是热门模型，样本都是老的热门模型生产出的热门样本，这个时候我们用简单的 lr 模型去拟合，到了真正的线上预估的时候，对于大量之前没见过的非热门的数据，模型自然很难预估好。没有足够好的样本，模型也很难学到足够有用的信息。

说另一个很有意思的现象，之前在某个组的时候，两个 team 优化同一个场景，大家用的回流样本都是一样的，但是特征和模型都是自己独立优化和迭代。有意思的是，如果一个 team 的优化取得了比较明显的提升之后，另一个 team 哪怕什么都不做，过一段时间效果也会慢慢涨上来。

对于这种情况，最根本的手段就是解决数据的有偏问题。尤其是新模型，一开始相当于都是在拟合老模型产生的样本，刚上线效果如果比较差，经过一段时间迭代，影响的样本分布慢慢趋近于新模型，也能收敛，但效率较低。这里给下两个在我们这还比较有效的经验：

对无偏数据进行上采样：这里的无偏是相对的，可以是随机/探索流量产生的样本，也可以是新模型产生的样本。大概意思，就是尽可能利用这些对新模型有利的样本

线上线下模型融合：比较 trick 的方法，没有太多方法论，但是确实能 work。新模型预估分数 pctr_new 和老模型预估分数 pctr_old 直接在线上做线性融合，刚上线的时候 a 选取比较小，随着慢慢迭代，a 慢慢放大。

pctr=a*pctr_new+(1-a)*pctr_old

03

最大的坑是天天被业务方 diss 算法做的烂，本质上还是现有的技术难以满足业务日益增长的智能需求，头顶好大一个人工智障光环。

正经一点的回答，以前写过一个：

• i2i/simirank 等相似计算算法中的哈利波特问题，相似性计算在推荐系统的召回起到非常重要的作用，而热门物品和用户天然有优势。因此，处理方法基本上都是凭经验，会出现各种 magic number 的参数。

• svd/svd++ 等算法，在各种比赛中大放异彩，但是据我所知，各大互联网公司中基本没有用它的。

• i2i 及它的各种变种真是太好用了，大部分公司的业务量，从 ROI 来看，其实没有必要再做什么优化了。

• 推荐的召回策略多优于少，但系统的计算 rt 是个问题，没有好的系统架构，也没有什么优化空间。

• i2i 等类似计算算法，实际业务中容易跑挂，比如用 spark 就容易 oom，很容易发生倾斜，处理起来又有很多 trick 和 dirty job。

• 推荐系统不只有召回，召回后的 ranking 起到非常大的作用，这个和广告的点击率预估有点像。

• 非常多的业务没有办法向 头条/facebook 之类的有稳定的用户留存指标，而留存是推荐系统非常重要目标，因此需要找各种折中的指标去知道 abtest。

• 训练样本穿越/泄露问题，即在训练的特征中包含了测试集的样本的信息，这个是初期非常容易犯的错误，在后期有时也会隐秘的发生。

• 大部分推荐系统的训练数据需要在离线条件下去拼接，其中用户的行为状态和时间有关，拼接非常容易出问题，因为系统当时的状态会有各种状况 ( 延时、数据不一致 ) 等，导致训练和实际在线的数据不一致，建议把训练需要的日志在实际请求中直接拼接好打印落盘。

最后，算法的作用有点像前辈们讲的：短期被人高估，长期被人低估。按目前国内业务方对算法有了解的特别少，算法对生态的长短期影响，只能靠算法负责人去判断，因此，就算你只是个打工的，请有一颗做老板的心。

04

某知乎网友

墙裂赞同 @吴海波 的回答，最难填的坑还是跟业务有关的坑。我觉得任何跟技术有关的坑都不是不可抵抗力，作为"勇攀高峰"的工程师的你，遇到技术坑那不是坑啊，那是机会啊。遇到跟业务有关的坑那就是赤裸裸的不可抵抗力，有种吃苍蝇的感觉。

举个很经典的模型上线的例子，改进模型之前技术老大，产品老大，运营老大各种老大开个会，说我们准备上线一个新模型，换了 DNN 架构，用了 Attention，再搞个 Reinforcement Learning，各种 business 线的老大都听不懂的名词一甩，说能把我们的 CTR 提高，能提高用户观看时长，最终能提高我们的 revenue。好啊，大家很开心，大家皆大欢喜说要搞起啊。

你好不容易做了3个月，AB test 1个月，改进了1个月，辛辛苦苦搞上线之后，产品老大说这不是我想要的东西啊，你怎么在用户首页推恐怖情色内容啊 ( 废话，这哥们就爱看恐怖情色片，模型不推这个推啥 )？！但老大的话不听不行，咱加点 penalty 上去。啥，penalty 不行，一个也不许出现？！行吧，直接加条 rule 上去。

运营老大也说话了，说我们首页是要考虑市场公关因素的，是我们公司的脸面，要尽量推最 popular 的内容。但是 popular 的内容人家都看过了啊，你不得多 explore 一下嘛，尝试尝试其他类型嘛？不行，一定要 popular。那好，我人为提高 popularity feature 的权重。

Editor 老大也说话了，说我们想要再搞一个活动，插到推荐内容的前面，重点突出一下。你们的个性化排序让一让位置。行，我们往后靠一靠。

这一来二去，你的模型还是那个模型吗？数据的 pattern 还是那样的 pattern 吗？你的优化目标效果还是原来测出来的效果吗？你的模型好不容易提升了2%的效果，让人家加点 rules 之后，还有2%没有？

原来我当老大的时候，成天跟别的部门战斗，为的就是给组员说清楚优化目标是什么，尽量给他们提供一个纯净的技术环境；现在不当老大了，感觉还是安安心心的填技术坑省心啊。

今天的分享就到这里，欢迎大家在评论区留言，谈谈自己遇到过的坑哦~~

来源：DatafunTalk，知乎。21CTO转载，一并致谢。

原文：https://www.zhihu.com/question/32218407

推荐阅读：