1.2 从运营、算法与工程视角看推荐系统

在任何一家企业中，推荐系统都不是由算法工程师独立维护的，而是一个寄宿在企业服务端上的软件组件和运营工具。这决定了参与推荐系统日常使用、维护的角色中包含了内容的推荐业务运营人员、项目开发与运维工程师。每个人在自己的立场、背景和知识体系下，对这个系统有着不同的诉求。被理解是每个表达者的使命，把这样一个与技术无关的部分放在本书靠前的位置，是因为我希望每个翻开这本书的推荐算法工程师、出于兴趣浏览的推荐业务运营人员能在相互理解的方向上各迈出一步。首先要做的就是了解大家在各自立场上的思维模式。理解了问题，再寻找解决问题的手段就不复杂了。

1.2.1 推荐业务运营思维：货找人

推荐业务的运营人员往往直接对业务整体目标负责，因此他们的思维模式是业务驱动的。虽然“人货场”是运营的基础思维模型，“场”无法与“人货”割裂开来谈，但“场”的元素其实在具体的业务场景搭建初期就确定下来了，它与具体业务的大方向、大战略有关，不仅涉及推荐技术，也耦合了用户界面设计、交互模式设计等话题。抛开具体的业务背景，我想在这里讨论一些通用、常见的运营思维模型，我们暂且忘记“场”的概念，聊一聊业务驱动下，场内的人货运营。

“我盘的货，为什么分发不出去？”“为什么货A会排在货B的前面？”“为什么给我推这个，不给我推那个？”这些是推荐业务运营人员对推荐算法工程师的常见发问。究其根源，其实都可以被归结为“货找人”的思维模式。而这种思维模式，又可以具体化为两个问题。

1.流量分配问题

第一个问题是流量分配问题，以曝光和转化两个维度为核心，包含4种形态。

（1）高转高曝问题 某些高转化率的内容被高频率大范围地曝光给用户，这是当推荐系统以转化为优化目标时常常出现的问题。以转化为优化目标是错的吗？当然不是，这是推荐系统实现平台商业目标的核心手段。我们的关注点在于曝光结构的合理性。如果一个电商平台，纸巾等低价高销品长期占据推荐首页靠前的位置，那么用户多次打开App时，容易对这个电商平台形成只卖便宜高销品类的品牌印象。纸巾是绝大多数用户的日常需要，并且会频繁购买，因此把纸巾频繁推送给所有用户，从推荐技术的视角看，做到了人货匹配，是合情合理的。然而从品牌形象的角度来看，这限制了平台的形象。

（2）高转低曝问题 某些高转化率的内容被低频率、小范围地曝光，甚至逐渐在流量池内沉寂下去。在进行后验数据分析的时候，我们会发现某些内容虽然在初期投放（冷启动或定向人工投放）的时候，有着非常好的消费表现，但进入推荐系统的流量循环后，曝光持续低迷，无法形成人群辐射扩散的效应。如果推荐系统频繁出现这类问题，且难以人为干预，会极大影响B端体验。一个典型的影响是，不利于高质量爆款内容的孵化。

（3）低转高曝问题 一些持续转化率低下的内容被持续大范围、高频率地曝光，这种问题常见于多目标的复杂推荐系统中，随着目标多元化（例如既要用户浏览更多商品，又要促成用户消费转化）、特征体系复杂化，推荐的策略和模型也越发复杂，一个直接的结果就是，推荐结果的可解释性、推荐系统的问题可定位性大大下降，偶尔会出现低转高曝的负面案例。

（4）低转低曝问题 低转低曝问题指的是，一些内容在被投放时，其转化效率低，累计曝光次数也低的现象。读者可能会觉得，低效率的内容获得更少的曝光次数，这不是符合常理的吗？如果内容实际质量差，那的确是正常的，说明推荐系统可以识别出低质内容并限制其分发。但如果内容质量高，那就有可能是推荐系统的问题。

我们介绍一个典型案例。为了满足站内某类用户的潜在需求，推荐业务中的内容运营人员经过大量数据分析和行业调研，通过招商、招标、购买、举办激励性质的活动，引入一批高质量的内容，在进入推荐系统流量循环后，它们的转化效果却很差。可能的原因就包含：用户画像不准确或推荐模型匹配能力差，导致好货没有推送给对的人。进而，由于这些内容转化率低，系统也不会给予持续曝光的机会。

2.排序因子问题

第二个问题是排序因子问题，主要关注的维度包含分发效率、兴趣相关度、货品质量、互动效果等。

在绝大多数推荐业务运营人员眼中，从用户行为日志中得到的数据是绝对客观的，那么通过数据分析得到的结论都是可靠的。在这个逻辑下，与数据分析结果定义与业务指标有关的排序因子就可以产生可解释的、有效的推荐，这是运营业务人员的惯性思维，也是与推荐算法工程师的认知模型常常冲突的问题点。

推荐系统日志数据不完全可靠的原因在于，推荐系统向用户推送的不是孤立的货品，而是一个货品的队列。排在队列前面的有更大概率被用户看到；排在后面的，用户可能还没下滑到这个位置就离开场景了。这类由系统交互形态以及用户主动选择行为造成的数据分布失真，叫作推荐系统的选择偏置。选择偏置是造成推荐系统日志数据不完全可靠的众多因素中的一种。

假设我们可以得到绝对客观的数据结论，并得到了绝对可靠的排序因子，那么泛泛而谈，排序因子好的排在排序因子差的前面，不就实现了理想中的可解释、高效率的推荐系统了吗？

现实情况往往不是这样简单的。举一个简单的例子：货品A的全站分发效率比B的好，而货品B与当前用户的主兴趣匹配度更高，那么谁应该排在前面呢？如果推荐业务运营人员只定义好与业务相关的排序因子，不定义偏序关系，推荐算法工程师就难办了。往往排序因子的维度越来越多，定义偏序关系也变成一个无法罗列的不可能任务，推荐算法工程师在优化排序模型的时候只能盯着主要商业目标进行优化，各因子之间的偏序可解释性就会降低。

1.2.2 推荐算法建模思维：人找货

业务形态千变万化，推荐系统在逻辑层面上的执行流程却是统一的：推荐系统在绝大多数情况下是被动接受用户请求并返回推荐结果的系统。这里说“绝大多数情况”，是暂且抛开推送技术，谈大部分推荐技术场景。

一次推荐请求发起的流程，大致可以描述为用户点击进入App或App的某个推荐场景，或是进行某种交互操作时，App客户端向后端服务器发送了一个复杂的请求，这里面就包括请求对应推荐场景的推荐结果，方便客户端页面的结果渲染和展示。推荐服务端在接收请求后，拉取用户信息，结合交互场景的上下文信息，进行复杂的多级多次匹配计算，从推荐货品池中筛选出少量的精选结果，返回给客户端，完成渲染展示，如图1-3所示。

从图1-3所示的场景中，不难理解推荐算法工程师的建模思维，就是为这个“人”去找对的“货”。“人找货”的建模思维，是从满足用户需求为第一准则出发产生的建模思维，也是与推荐业务相关的黄金准则。从大方向上看，这个思路是对的，然而往往只有在落实到实践中，我们才会发现这一问题并不简单，甚至暗含“逻辑陷阱”。

首先，以更严谨的表达方式叙述，有的读者会把“人找货”解读为“在给定用户兴趣的前提下，为用户找到与其兴趣相关的内容”。这种解读方式的“逻辑陷阱”是问题的条件无法满足。推荐系统永远无法得知用户的真实兴趣，推荐系统所使用的用户画像是通过系统与用户长期交互产生的数据中提炼得来的，而用户与推荐系统交互产生的数据都是系统基于“用户兴趣”为用户进行推荐产生的，这里的逻辑形成了因果的循环，因而不攻自破。所以我们会经常听到这个说法：“推荐问题不是一个完备定义的问题。”

其次，每个发往系统的请求是孤立的，而与系统交互的人不是孤立的，每时每刻都有大量用户正在和系统进行实时的协同过滤（一个推荐系统的经典思想，第8章会进行介绍）。这里面暗示的是，用户有时候也不能把握好自己的兴趣，用户的兴趣甚至会受到群体行为的影响。

再次，由于数据是流动的，流量也是流动的，用户的兴趣也会随着时间流动和变迁，因此每一次推荐的结果应该与这个流动的生态产生互动。

最后，品牌调性、生态结构，往往是算法不可优化的目标，也不遵从“人找货”的思维模式，而遵从“人试货”的思维模式。

总的来说，“人找货”是推荐系统算法建模的黄金准则，但不能狭隘地去理解它，需要推荐算法工程师在具体的业务、具体的场景、具体的技术环节以及具体的业务目标约束下，去思考为用户找到什么样的内容。这也是业务驱动思想在“人找货”模式中得以应用的方式。

1.2.3 推荐引擎工程展望：服务产品化

推荐系统发展到今天，逐渐形成了较同质化的系统结构。一个普通的软件工程项目，在设计之初也要考虑低耦合、高内聚，在业务扩展时也要考虑可以快速进行能力复制、高效部署，甚至从定制化服务走向产品化服务。

服务产品化不仅仅是架构设计艺术的追求，更是技术能力商业化的追求。我们可以通过一个简单案例来理解。某手机厂商想要做好自研浏览器的流量生态，苦于没有内容也没有用户画像。不想用户打开浏览器只有简单的搜索框，他们想要调用某新闻资讯类App的内容推荐接口，把内容在浏览器页面上渲染展示。

对于这个新闻资讯App来说，想要的并不是接收一个HTTP请求并返回一些图文结果这么简单。自动化的日志服务、数据仓储、画像构建、特征分析等全套推荐服务，都要可以自适应地适配对方的消费场景，形成一个完整的推荐服务产品。这就要求推荐系统各个模块高度抽象化，同时具备在推荐策略上一定程度的自由定制化的能力。如此一来，这个推荐接口就可以按调用次数计费，技术团队就有了向二方、三方营收的能力。

技术能力商业化，也是从业务驱动的角度出发，去为企业谋求价值的途径。商业竞争不会一直都是零和博弈，在特定的阶段，通过特定的方式，不同的商业体可以谋求合作共赢。产品化技术能力输出，不仅仅是工程技术团队谋求实质收入的手段，更是拓宽市场、获取用户的一种渠道，它能为主营业务带来增量。