运营必知「推荐」二三事

南村小付 2023-07-28 06:54:13

不想当「厨师」的「采购员」不是「好运营」，对于一个内容产品来说，运营的日常的工作中，特别是「内容运营」的同学会经常和推荐算法同学有很多工作上的配合。

运营同学像是一个餐馆的采购员，负责食材的采买，而推荐同学就像是厨师，结合用户所点的菜单（偏好）采用对应的食材做成用户大概率会喜欢的菜肴。

在这个链条里，运营同学在上游，如果引入的内容/创作者不够优质，就像采买的食材不够新鲜高质一样，推荐同学无论怎么努力都很难做出可口的菜肴。

同时还有另一个问题，即便运营同学采买了最好的食材，如果推荐同学做菜的方式有问题，后者没有最合理的使用食材，也没有最大限度发挥食材的价值，暴殄天物了。

因此对于运营同学来说，不仅做好自己的上游工作，还非常有必要知道推荐的相关工作，这样当做出的菜肴不够好吃时，我们才能及时发现是食材的问题，还是做的方法有问题？更快的进行下一步的调整。

一、必知一：内容是如何被推荐的？

对于运营同学来说，首先需要了解的是：内容是如何被推荐的？我们引入的创作者和他们的内容，是如何经过层层流程，决定是否被推荐，以及被给到多少流量的？

内容在进入系统后整体的处理流程，不同产品和不通过公司的处理是不太一样的，但是整体逻辑上基本相同，大模块的业务逻辑基本如下图。

运营必知「推荐」二三事

如上图所示，当用户上传一条内容后，内容会首先经过安全审核的流程，安全审核主要是将一些违规，黄色暴力血腥的内容剔除掉，未过审的视频基本就永久屏蔽或者直接删除。

通过安全审核后，大部分内容社区会有原创审核，将一些重复上传或者搬运的内容过滤掉，原创审核大部分是依靠机器来审核的，未通过原创审核的就只会在用户自己的个人主页，或者粉丝的关注页等私域展示。

通过了原创审核后的视频会再进入第一道质量审核，质量审核主要是把一些无意义、无主题、杂乱的内容过滤掉，通过了第一道质量审核后，内容将会被推荐系统纳入推荐候选池，然后会给作品最基础的流量推荐，目的是通过基础流量后产生的数据初步判断作品质量的好坏。

如果基础流量过后的数据反馈较好的话，就会接着加码给到更多的流量推荐，拿到更多流量推荐后，如果数据表现不好，也会被停止推荐；数据表现好的，会再进入第二道内容质量审核或者举报审核。

第二道质量审核主要目的是防止前面的审核会有漏审，或者有一些不符合社区内容调性的内容出现。举报审核是指消费内容用户主动点击的举报，收到过多举报的内容一定是有潜在风险，需要人工再次审核。

通过第二道质量审核，或者举报审核后，作品将会被持续给到更多流量，进入一个周期的推荐，成为内容平台重点推荐的候选内容。

但是在整个持续推荐过程中，还会有一些更细的审核流程，比如高热审核，针对全平台最热门的视频进行审核，保证没有风险，同时持续进行用户举报审核，及时发现潜在违规作品。

持续推荐过程中，如果内容的数据反馈出现下滑，那么会慢慢的进行推荐冷却，直至停止推荐。

以上所有流程中，被停止推荐的作品，在后续的过程中，也会因为一些偶然的触发或者其它的召回被重新激活，给到更多流量进行推荐。常见的比如遇到节日，过往节日类的内容就会被重新召回推荐。

了解了上面的推荐流程后，运营同学就能对整体内容的流转有一个清晰的认知，可以结合到自己的产品或者业务逻辑，细化整体的流程，这样当遇到问题的时候，就能及时的知道目前内容处在一个什么阶段。

二、必知二：推荐系统是如何工作的？

上述的推荐流程中，能帮助我们厘清内容流转的逻辑，但是在上图中的流量推荐模块，到底是如何进行推荐的，我们并不清楚。为了搞清楚这个问题，我们得先对整体推荐系统有一个了解。

如果把推荐系统简单拆开来看，推荐系统主要是由数据、算法、架构三个方面组成。

数据主要提供推荐所必须的信息，包括用户和内容的特征信息，用户对于内容的行为反馈数据等；
算法主要是提供策略和逻辑，在海量的数据下，人工策略已经很难进行分析和干涉，因此需要一套算法来自动的进行信息逻辑处理和返回推荐的内容；
架构主要是承载数据和算法的平台，对接上下游的数据和逻辑，保证系统能够稳定、实时自动的运行。

常见的推荐系统如下图所示：

运营必知「推荐」二三事

在上图的推荐架构中，数据存储模块，主要是负责存储内容索引（一种对应到内容的逻辑标识，便于找到内容）、用户特征（包含用户的画像信息，兴趣点等）、用户日志（包含用户在客户端对内容产生的一些行为，比如：点击、点赞、分享、评论等）。

推荐算法部分，会通过内容索引对内容进行召回，召回的候选内容一般都比较多，然后会经过一层过滤，将一些不适合推荐，或者其它运营、审核逻辑干涉的进行过滤，然后产生的推荐候选池会进行排序。

排序通常分为粗排和精排两个步骤，排序的方式是通过用户的特征，以及用户的行为日志，将内容排成用户最有可能细化的顺序。这样最终的排序后的内容就会推送到客户端，按照客户端实际的展现场景进行展示。

内容展示后，用户对其产生的行为就会通过日志重新上报，然后实时进行日志的计算，用户画像更新和推荐指标更新，比如ctr等，实时计算完成后，再更新到数据存储中进行最后的存储。

这样，后续的推荐取得数据都是最新的。

三、必知三：推荐算法核心两步：召回+排序

上述的推荐系统结构图，让我们知道了推荐的上下游工作原理，也知道推荐系统的组成部分有哪些，在这些组成部分里，和运营日常工作中交集最多的部分，应该是推荐算法部分，推荐算法中最核心的两步就是：召回和排序。

了解了这一块，基本也就大概明白了推荐算法的原理，以及我们遇到一些推荐问题的时候，大概也能知道是哪一块出了问题。

我们先来看下「召回」，什么是召回？

召回就是指推荐系统通过某种策略从全量内容池中选取一部分出来，推荐系统召回的方式一般有很多种，比如常见的热门召回、协同过滤召回、兴趣标签召回等。

单一的召回有自己的优点，但同时缺点也会很明显，因此为了有更完整、全面的召回，通常采用的是「多路召回」，如下图所示：

运营必知「推荐」二三事

如上图所示：如果我们根据召回是否有用户个性化因素存在来划分，可以分成两大类：一类是无个性化因素的召回，比如热门内容或者历史点击率高的内容的召回；另外一类是包含个性化因素的召回，比如用户兴趣标签召回、协同过滤召回。

简单解释下这几个常见的召回策略：

热门召回：即全站，当前按照内容各项指标计算得到的综合分的排序，从这个排序中召回前k1个内容；
兴趣标签：指根据用户偏向的兴趣标签，比如用户喜欢看体育中的篮球，那么从篮球这个标签下召回k2个内容；
基于用户的协同过滤：是指计算出用户之间的兴趣相似度，举一个简单的例子，比如用户A喜欢{a,b,c},用户B喜欢{a,b,d},那么我们可以用两个用户喜欢集合的交集除以并集，得到两者的兴趣相似度，为{a,b}/{a,b,c,d}=0.5；这样我们找到和推荐用户兴趣点最相似的用户们，推荐其它当前用户没有看过的内容，比如给用户A推荐d；可以按照相似用户中不同内容的列表召回Top k3个内容；
基于内容的协同过滤：和基于用户的协同过滤类似，这里我们计算不同内容之间的相似度，计算的方式有很多，简单的可以直接喜欢两个内容的用户数之间的重合度来计算，这样可以得到和当前内容相似的内容序列，按照相似度进行排序，召回Top K4进行推荐；
基于社交关系的召回：一般是通过社交媒体的关系，将用户的朋友喜欢的内容推荐给用户，比如微信视频号里的，你的朋友点赞的内容推荐；
上下文信息召回：是指依照一些时间上下文，位置上下午进行召回，最典型的是在节日期间，召回节日相关内容，还有就是依据地理位置，进行附近的内容召回。

召回之后的排序，一般分成粗排和精排两个阶段：