不想当「厨师」的「采购员」不是「好运营」
对于一个内容产品来说，运营的日常的工作中，特别是「内容运营」的同学会经常和推荐算法同学有很多工作上的配合，运营同学像是一个餐馆的采购员，负责食材的采买，而推荐同学就像是厨师，结合用户所点的菜单（偏好）采用对应的食材做成用户大概率会喜欢的菜肴。
在这个链条里，运营同学在上游，如果引入的内容/创作者不够优质，就像采买的食材不够新鲜高质一样，推荐同学无论怎么努力都很难做出可口的菜肴。同时还有另一个问题，即便运营同学采买了最好的食材，如果推荐同学做菜的方式有问题，后者没有最合理的使用食材，也没有最大限度发挥食材的价值，暴殄天物了。
因此对于运营同学来说，不仅做好自己的上游工作，还非常有必要知道推荐的相关工作，这样当做出的菜肴不够好吃时，我们才能及时发现是食材的问题，还是做的方法有问题？更快的进行下一步的调整。
必知一：内容是如何被推荐的？
对于运营同学来说，首先需要了解的是：内容是如何被推荐的？我们引入的创作者和他们的内容，是如何经过层层流程，决定是否被推荐，以及被给到多少流量的？内容在进入系统后整体的处理流程，不同产品和不通过公司的处理是不太一样的，但是整体逻辑上基本相同，大模块的业务逻辑基本如下图。
如上图所示，当用户上传一条内容后，内容会首先经过安全审核的流程，安全审核主要是将一些违规，黄色暴力血腥的内容剔除掉，未过审的视频基本就永久屏蔽或者直接删除。通过安全审核后，大部分内容社区会有原创审核，将一些重复上传或者搬运的内容过滤掉，原创审核大部分是依靠机器来审核的，未通过原创审核的就只会在用户自己的个人主页，或者粉丝的关注页等私域展示；
通过了原创审核后的视频会再进入第一道质量审核，质量审核主要是把一些无意义、无主题、杂乱的内容过滤掉，通过了第一道质量审核后，内容将会被推荐系统纳入推荐候选池，然后会给作品最基础的流量推荐，目的是通过基础流量后产生的数据初步判断作品质量的好坏。
如果基础流量过后的数据反馈较好的话，就会接着加码给到更多的流量推荐，拿到更多流量推荐后，如果数据表现不好，也会被停止推荐，数据表现好的，会再进入一道内容质量审核或者举报审核，第二道质量审核主要目的是防止前面的审核会有漏审，或者有一些不符合社区内容调性的内容出现。举报审核是指消费内容用户主动点击的举报，收到过多举报的内容一定是有潜在风险，需要人工再次审核。
通过第二道质量审核，或者举报审核后，作品将会被持续给到更多流量，进入一个周期的推荐，成为内容平台重点推荐的候选内容。但是在整个持续推荐过程中，还会有一些更细的审核流程，比如高热审核，针对全平台最热门的视频进行审核，保证没有风险，同时持续进行用户举报审核，及时发现潜在违规作品。
持续推荐过程中，如果内容的数据反馈出现下滑，那么会慢慢的进行推荐冷却，直至停止推荐。
以上所有流程中，被停止推荐的作品，在后续的 过程中，也会因为一些偶然的触发或者其它的召回被重新激活，给到更多流量进行推荐。常见的比如遇到节日，过往节日类的内容就会被重新召回推荐。
了解了上面的推荐流程后，运营同学就能对整体内容的流转有一个清晰的认知，可以结合到自己的产品或者业务逻辑，细化整体的流程，这样当遇到问题的时候，就能及时的知道目前内容处在一个什么阶段。
必知二：推荐系统是如何工作的？
上述的推荐流程中，能帮助我们厘清内容流转的逻辑，但是在上图中的流量推荐模块，到底是如何进行推荐的，我们并不清楚。为了搞清楚这个问题，我们得先对整体推荐系统有一个了解。
如果把推荐系统简单拆开来看，推荐系统主要是由数据、算法、架构三个方面组成。
- 数据主要提供推荐所必须的信息，包括用户和内容的特征信息，用户对于内容的行为反馈数据等；
- 算法主要是提供策略和逻辑，在海量的数据下，人工策略已经很难进行分析和干涉，因此需要一套算法来自动的进行信息逻辑处理和返回推荐的内容；
- 架构主要是承载数据和算法的平台，对接上下游的数据和逻辑，保证系统能够稳定、实时自动的运行。
常见的推荐系统如下图所示。
在上图的推荐架构中，数据存储模块，主要是负责存储内容索引（一种对应到内容的逻辑标识，便于找到内容），用户特征（包含用户的画像信息，兴趣点等），用户日志（包含用户在客户端对内容产生的一些行为，比如，点击，点赞，分享，评论等）
推荐算法部分，会通过内容索引对内容进行召回，召回的候选内容一般都比较多，然后会经过一层过滤，将一些不适合推荐，或者其它运营、审核逻辑干涉的进行过滤，然后产生的推荐候选池会进行排序，排序通常分为粗排和精排两个步骤，排序的方式是通过用户的特征，以及用户的行为日志，将内容排成用户最有可能细化的顺序。这样最终的排序后的内容就会推送到客户端，按照客户端实际的展现场景进行展示。
内容展示后，用户对其产生的行为就会通过日志重新上报，然后实时进行日志的计算，用户画像更新和推荐指标更新，比如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进行推荐；
- 基于社交关系的召回，一般是通过社交媒体的关系，将用户的朋友喜欢的内容推荐给用户，比如微信视频号里的，你的朋友点赞的内容推荐；
- 上下文信息召回，是指依照一些时间上下文，位置上下午进行召回，最典型的是在节日期间，召回节日相关内容，还有就是依据地理位置，进行附近的内容召回。
召回之后的排序，一般分成粗排和精排两个阶段；粗排一般对召回的大量内容，进行一些简单的融合排序，比如多个召回源，各取TOP k，将大量的召回内容，截断到一个可控的量级（一般到千的量级），不然精排阶段会非常耗时，精排一般都采用模型进行排序，排序后召回内容会到百量级。
精排的方式有很多，最初级的是策略规则排序（对各路召回，指定权重和规则进行排序），后续有基于各种模型的排序，有LR（线性回归），LR+GBDT（线性回归+树模型），FM（因子分解模型），DNN（深度学习模型）等。各种模型的排序较为复杂，很多不具备可解释性，在这里不再赘述，感兴趣的读者可以自行检索。
必知四：部分书籍和文章推荐
作为运营的同学知道了上述的推荐逻辑后，基本能够很顺畅的和推荐同学进行沟通，同时，也能及时发现推荐系统中可能存在的问题，也能在推荐召回部分，用户画像，内容特征等维护根据自己运营的经验，给出一些自己的看法。
在写这篇文章过程中，我也参考了一些书籍和文章，推荐给大家。
《推荐系统实战》：https://book.douban.com/subject/10769749/
推荐系统技术演进趋势：从召回到排序再到重排：https://zhuanlan.zhihu.com/p/100019681
推荐系统怎样实现多路召回的融合排序：https://zhuanlan.zhihu.com/p/90796257
【机器学习】逻辑回归：https://zhuanlan.zhihu.com/p/74874291
