15 本地服务业务中的推荐系统实战——工程篇

《易经》“九五：飞龙在天，利见大人”。九五是指阳爻在卦中处于第五位，已接近极限。飞龙指龙飞在天上，居高临下，大展鸿图。

在前面 4 个模块中，你已经掌握推荐系统的核心知识体系了。本模块主要是介绍推荐算法工程化的落地方案，实践性很强，助你灵活运用已学知识来解决实际问题。

在这一讲，我们通过介绍同城本地服务业务的背景和特点，来讲述推荐系统落地的工程化方案。

本地服务事业群，旧称“大黄页”“黄老大”，在集团内是既古老又年轻的业务线。古老是因为自从成立以来，它就是一个以提供本地信息服务的分类信息网站；年轻是因为近期它在业务上做了很多创新，面貌焕然一新了。

本地服务的业务生态涉及面非常广、杂，其中业务主要战场有 20 多个，涉及行业有 200 多个，如丽人、餐饮美食、家政、教育培训等，而这些行业之间的关联也比较少。

本地服务产品流量形态

目前，本地服务主要分为三大块：主站、到家、到店&电商。本地服务业务形态较为复杂多变，在流量分发上依托于商家中台和合伙人流量分发网络。

合伙人流量分发网络是一种流量组织形式，通过对社会各个锚点的重新组织，形成与之前流量投放及变现完全不同的流量分发渠道。

下面我们一起看看同城本地服务三大块业务的特点，以及这些业务下的推荐场景位所关注的指标。

主站业务：它是通用的一种业务形式，用户通过 App、PC、M 等端口进入本地服务落地页，以流量生意为主（开环业务，目前产品形态正从开环向半闭环演进）。

• 推荐的应用场景：列表页、详情页、落地页等；
• 推荐的内容：帖子、商家、店铺、商品、标签等；
• 推荐效果的关注指标：CTR、CVR、Call/UV 等。

到家：它主要提供到家精选服务品牌（完全闭环业务）。

• 推荐效果的关注指标：GMV、订单转化率、复购率等。

到店&电商业务：它是的一个创新业务（完全闭环业务）。

• 推荐效果的关注指标：GMV、订单转化率、复购率等。

城市合伙人业务：指的是用户通过线上招募/线下招募/主动注册为合伙人后，将任务（该任务可以是以上多种业务形态）转发给对应合伙人，对应合伙人再通过社交进行分发。任务一旦形成转化，就可以拿到一定的分佣。

推荐效果的关注指标：效果转化率、ROI、DAU。

流量业务梳理与推荐工程建设

在实际业务中，各个业务的推荐场景、位置，会根据互联网传统产品生命周期的分析模型（AARRR），从获客、促活、留存、收入、传播五个维度，起到相应作用。

我们可以将不同流量形态的业务的主要关注点在这五个维度上做一下拆分，在不同的收益目标上有所偏重。

• 比如主站业务，因为它是开环业务，所以其推荐位主要关注的指标是同城 App 用户的促活和留存；
• 而到家精选、心宠等服务类业务，其推荐位关注的指标是拉新、收入。

城市合伙人业务属于流量类业务，根据合伙人任务的不同，投放属性（CPC、CPS、CPA）及目标也有所不同。比如 CPA 任务的主要目的是将主站商家的帖子分享到朋友圈，从而提高曝光率；通过提高 CPA 任务的点击率，来提高消耗率，从而提高收入；通过提高 CPC 任务的曝光率，达到留存等目的；通过提高 CPS 任务的曝光率，为到店/电商做业务推广。

电商类的到店/电商业务主要目的是拉新、促活、留存。

同城本地服务业务的创新速度极快，随着业务的不断更迭，本地服务业务的数据资产也在不断增加。因此，除了最基础的类目信息、帖子信息之外，商品、服务、标签等基本数据类型都需要接入推荐系统，并提供服务。

面对千万级别的用户、不同的业务场景以及海量的数据信息，同城本地服务推荐系统需要帮助用户快速筛选感兴趣的内容。比如用户面对陌生领域时，推荐系统需要提供可参考性的意见；在用户需求不明确时，推荐系统要做用户的贴心助手，并且满足用户的好奇心。

同城本地服务推荐系统需要描述物品特点，迅速捕捉用户兴趣和兴趣的变化，并选择合适的场景、时机、表现方式，将信息与用户进行匹配，以便帮助用户有效地过滤信息，从而解决信息过载问题。

本地服务推荐系统工程架构的演变历程

随着本地服务业务的不断更迭，目标的重新确立，产品思路、架构、算法也随之进行变迁。接下来，我们主要阐述在这个变迁过程中推荐搜索架构的演进。

通常架构的产生都是来源于团队和业务环境，并用于解决环境中的问题。所以架构形成初期会带着较为明显的特点，在其实施落地中会对一些问题具有针对性效果。

同城本地服务推荐系统的架构经历了独立架构、分层架构、平台架构这三个阶段。

为了便于你理解同城本地服务推荐系统架构的演进历程，我们先来回顾一下 05 讲中介绍的推荐业务流程的构成。

理论上，业内推荐系统的流程基本都是相似的，推荐系统的目标是为了解决用户与物品之间的关系，将用户感兴趣的物品推荐给他。

一个物品被进行推荐会经过召回、排序、策略、展示、反馈，到评估这几个部分，再改变召回候选集，形成一个完整回路。

• 召回部分是指从不同的数据源获取到用户可能感兴趣的物品，通过算法或规则对每个物品进行打分、排序；
• 通过业务规则的处理，补充信息后展示给用户，用户的点击、浏览等行为又反馈到系统中；
• 通过评估部分影响候选集召回，以及打分排序算法。

系统架构 1.0 时期：独立架构

在系统架构 1.0 时期，推荐系统的主要目标是将本地服务不同类目的帖子、标签等信息展示给用户，并促使用户与商家联系，从而提升整体电话连接数这个指标。

当时，推荐系统的架构设计主要从研发团队的内部因素、外部因素两方面进行考虑。

项目团队需求多，当时团队只有 4 名后台开发工程师，但并行开发的项目很多， 同时项目的周期很短，排期仓促，很难有时间进行细致的系统整理和业务抽象

当时业内的推荐架构也有不同的发展方向，大家都在尝试摸索一些符合自身发展的架构思路

由于上述的原因，工程师们在面对一个接一个的项目时，都会根据自己的理解，使用熟悉的技术栈来搭建框架，这样形成了一个又一个的独立架构。

在系统架构 1.0 时期，我们是以业务实现为主要目标，快速建立推荐系统。在这个阶段，数据体系尚未完善，因此需要充分利用现有数据以及对业务知识的理解，快速建立最小可行（MVP）的推荐产品。

所以，系统架构在 1.0 时期没有建立起完整的反馈以及评估体系，同时排序部分也是被策略部分取代的，那架构重点就体现到了召回部分、策略部分、展现部分上。当时的推荐流程基本可以被简化为召回、策略、展现三个部分。

说到这里，你可能觉得这个时期的架构组成很简单，没有必要讲述。但事实上，后来的分层架构以及平台架构的基础都来源于这个阶段。没有这个阶段团队不断踩坑、总结，就没有后续因地制宜的架构进化。

因此这里还需要剖析一下系统 1.0 的架构组成与特点。

如图所示，系统架构 1.0 的流程是类目、帖子等业务信息通过离线计算后保存到数据存储服务，在线服务根据不同场景的业务逻辑将数据召回，展示给用户。这里我试图将每个项目的架构都在图中表达出来，但在真正的实施过程中，每一个独立的项目负责人会选择各自的在线服务框架，同时使用多种 KV 存储介质用于数据存储，并且采用离线定时任务或 Spark 进行数据的离线计算。

系统架构 1.0 的优缺点如下所示。

• 推荐流程不完整，缺乏反馈、评估等
• 缺乏统一的数据处理机制
• 没有给算法提供相关的支撑
• 逻辑过度耦合、复用率低

尽管系统 1.0 架构存在诸多缺点，但是它的发展，也给后面的架构优化奠定了一定的基础。

系统架构 2.0 时期：分层架构

到系统架构 2.0 时期，研发团队内部因素、外部因素也发生了一定变化。

在这个时期，研发团队成员在进行核心业务实现时，不断演进工具以及框架。与推荐系统架构 1.0 时期不同的是，系统架构 2.0 时期的技术目标已经不仅仅是实现业务需求，而是完善推荐流程。

推荐系统 2.0 架构需要覆盖召回部分、排序部分、策略部分、展示部分、反馈部分、评估部分的流程，这时系统建设的重点是：

• 实现完整的推荐流程
• 建立推荐指标体系
• 算法与工程解耦
• 提高迭代效率

其中，系统架构 2.0 需要建立推荐指标体系，以数据为先，提炼出数据架构，并且实现数据对比，效果以数据为准。推荐系统架构 2.0 需要提供一个算法模型方便介入的方式，既能保证业务的快速迭代和开发，又能支持高效运算。

另外系统架构 2.0 需要明确算法工程师与后台开发工程师的责任边界。因为在这个时期新增了算法工程师，由于算法工程师与后台开发工程师在工作目标上有所不同，需要在做架构的时候划分好职责边界，来让他们更好地配合。

后台开发工程师的工作职责是推荐场景实现接入，提供基础组件，保证服务稳定可靠，使系统具备良好的扩展能力。算法工程师的工作职责是开发可执行的算法模型组件，维护实验策略，提升效果，进行策略和算法迭代。

接下来，是系统开发中的业务抽象过程，这里对照同城本地服务“猜你喜欢”推荐和“找相似”推荐的业务流程。在“猜你喜欢”场景中有基于用户行为的推荐策略和基于用户位置的 LBS 推荐策略。在数据召回阶段，从不同的数据源召回数据，通过不同的模型打分排序后形成推荐集，展示给用户。在“找相似”场景下只有相似帖子的推荐策略，但是在数据召回阶段，采用了与“猜你喜欢相”同的 CallCF 召回算法，通过 LR 模型排序，最终获得“找相似”推荐集展示给用户。

通过对不同场景的分析，可以发现同一种召回模型或排序模型又可能应用到不同的推荐场景，为了实现算法模型的复用，我们将推荐流程重新抽象为场景、策略、召回模型、排序模型、摘要展示等几部分，如下图所示。

进一步地，推荐的流程可以抽象为场景、策略、算法三部分，也就明确了算法工程师与后台开发工程师的分工。

• 后台开发工程师负责场景接入，以及定义不同场景的主要业务流程；
• 算法工程师负责实现召回算法和排序算法，并根据不同场景选择合适的算法模型，以及后续的算法迭代，提升推荐效果。

系统工作流程在业务实现的基础上，将算法实现与工程实现解耦，并确保易维护和高性能。通过对业务流程的梳理，新的推荐流程被划分为在线推荐、离线计算两部分。

• 离线计算：通过分析用户的行为轨迹信息、帖子信息、标签信息，构建了用户、帖子、标签三种核心数据集，供在线推荐使用。
• 在线推荐：通过实验分流、数据召回、候选集排序、摘要补全几个核心流程，最终将推荐结果展示给用户。

系统架构 2.0 的优化目标是：

• 系统功能模块化；
• 将工程上的业务流程与复杂算法逻辑拆分，使同一个算法模型可以在不同业务间复用；
• 提高系统可用性、稳定性、扩展性；
• 业务迭代和算法模型优化能够同步进行，提高工作效率。

系统架构 2.0 被划分为接入层、业务层、数据层 、监控服务、基础组件几部分。

不同的推荐场景通过接入层接入到推荐系统中，再通过业务层的处理获取到推荐结果集，展示给用户，用户的点击、浏览、拨打电话等行为又会被埋点系统收集，通过数据计算后同步到数据集服务，供在线推荐使用。

从业务发展、运维、质量等多个维度考虑后，业务层的关键业务会作为微服务进行建设，包括主体服务、进行动态路由实验的分流服务、面向算法与数据的召回、排序服务，以及组装推荐结果的摘要服务。

主体服务会根据用户的请求构建推荐任务上下文，通过 AB 分流后组装合适的推荐策略，在召回服务选择不同的召回算法构建推荐候选集，排序服务会根据实验策略指定排序算法对推荐候选集进行打分、排序，并根据业务规则将已打分的候选集重排序，最终摘要服务将图片、标题、简介等信息补充完整，通过不同的场景展示给用户。

为了保证服务质量，及时发现问题，系统中加入了可靠的监控预警功能。考虑到团队合作、开发效率、后期运维的问题，整个系统采用私有云做底层容器，并采用了集团已有的公共服务作为系统的基础组件，如下图所示。

系统架构 2.0 的优缺点如下所示。

这种架构已经实现了完整的推荐流程，为算法的接入提供了良好支持，并且初步建立了评价指标体系。但是，依然存在着新业务接入成本较高、通用性较低的问题。

系统架构 3.0 时期：平台架构

系统架构 2.0 有一个重要不足是“接入成本高、系统的通用型低”，于是我们希望能够在

接下来的优化中解决它。那这个不足会带来什么问题？为何在已经满足业务需求时，推荐架构需要再次往前发展呢？

还是来看看当时所处的环境。

• 在团队内部，推荐产品不断扩张，对效果更为看重，将工作重点从业务开发和迭代转变为以效果为目标的算法迭代。开发新项目或者迭代已有业务时，发现重复的工作很多，而架构没有解决，存在冗余。
• 除了推荐业务外，团队还承担了同城本地服务业务的搜索系统的开发工作，到家精选 、城市合伙人提出了新的推荐搜索需求。

此时研发团队内部因素、外部因素也发生了变化：

在同城本地服务中，不同业务对搜索推荐能力的需求场景不一样，但是却有着相似的业务复杂度。面对已知的业务和已知的功能、未知的业务与未知的功能，需要有能力将复杂的业务流程与技术进行拆分。

一个搜索任务的流程包含 Query 理解部分、召回部分、排序部分、策略部分、展示部分、反馈部分、评估部分。

• 其中 Query 理解包括纠错、改写、扩展、分词等
• 召回部分给定一个查询词，从数据源中召回有效正确的候选集，并将结果传递给排序。
• 排序部分根据众多因子对召回候选集进行排序，挑选出最好的信息展示给用户。

除了 Query 理解外，搜索流程与推荐任务流程相似，那么搜索和推荐也许可以某种方式结合在一起？

搜索、推荐本质上都在解决信息过载的问题，各自解决的手段、目标不相同，各自诞生在产品生命周期不同阶段。从几个维度对比一下，看看它们不同和相同在哪。

• 搜索

要解决的问题是如何精确、快速地找到想要的结果。最重要的目标是降低延迟和提高相关性。搜索更关注内容消费者，不会像社交网站或资讯网站那样变成 Time Killer，人们依赖搜索而不沉迷搜索。在搜索解决用户的信息获取需求时，也很少给予用户一些“惊喜”，不会随随便便扩充一些不那么相关的结果这也不是搜索的目的。

• 推荐系统

推荐系统则不同，首先一款产品很少完全依靠推荐系统来支撑，推荐系统大都是起到一个“锦上添花”的作用。但是好的推荐系统都会使产品变成一个 Time Killer，让用户走进去就不想出来。推荐系统不需要像搜索词一样明确的需求，因此给出的结果就有很多发挥创意的余地，也可以给用户制造一些惊喜，这一点和搜索很不一样。

搜索和推荐的信息对象，理论上可以共用的，也就是说可以允许用户设置条件去检索一堆候选对象，也可以把这些候选对象主动推荐给可能感兴趣的用户。

那么，我们可以抽象一下两者的需求共性：本质都是在匹配用户的兴趣和需求（看成 Context），但匹配的目标、条件和策略不尽相同。

进一步抽象下去，又可以分为三步：过滤候选（Filter）、排序候选（Ranking）、个性化输出（Personalization）。

召回候选集这一步在搜索里面天经地义，Query 解析得到查询意图或者更多结构化的搜索条件，再获取搜索候选。召回候选集在基于内容的推荐策略中也有类似的过程。而其它推荐策略，比如协同过滤或者隐因子模型，一般是提前计算好的，并没有明显的类似搜索一样的召回。不过我们仍然可以粗略地把各种不同召回策略看作“召回候选集”这一步骤，只不过召回并不是同步进行的，而是异步进行的。

排序这一步的主要区别在于排序的目标和约束。搜索的排序目标是高相关性；而推荐系统的排序比较复杂，相关性因素只占很小的部分，根据推荐系统的产品形式不同，排序也不同。CTR 预估、TopN、浏览等都是重要的排序因子。

基于以上原因，系统架构 3.0 需要实现技术上的统一，业务上分别建立推荐搜索系统，如下图所示。

综上，系统架构 3.0 的技术目标如下。

• 架构标准化：实现标准的架构以及标准的工作流程
• 业务流程标准化：将基础功能抽象成可复用的组件
• 快读迭代：同一个算法可以应用在不同的场景下，不同的场景可以构建灵活独立的实验
• 协作姐耦：划分工程算法团队任务边界，提高写作效率
• 提高系统性能，降低业务放接入门槛，实现系统的平台化

如图，可以从系统 3.0 架构图中可以看出来，系统 3.0 的架构体是基于系统 2.0 架构发展起来的，保留了大量的系统 2.0 架构中使用的分层体系以及工具框架。业务平台被划分为搜索业务平台和推荐业务平台，供业务方接入。

系统 3.0 架构主要由以下几个部分组成。

• 场景层：实际上是一套灵活可靠的实验管理系统，用来进行实验的灰度调度管理，一个实验包含多个组件，一个组件可以用于多个场景，提升算法/业务的迭代效率，快速试错，实现效果提升
• 组件层：将系统架构 2.0 沉淀的一些功能，比如类目映射、地域映射等作为基础组件进行建设，同时新增了 Query 理解的相关基础组件，供不同业务的推荐或搜索使用
• 模型层：将算法的实现模型与业务分割开，提供零基础全异步的算法执行框架，方便算法模型实现
• 人工干预模块：根据业务侧需要，将推荐或搜索结果重新调整，增加、删除相关条目或调整某些条目在列表中的位置
• 基础特征服务：该模块主要负责用户实时数据的处理以及特征统计工作，如基础行为特征（点击、收藏、打电话等），统计特征（点击次数、点击率等）……供系统调用
• 数据层：将来自不同业务的数据统一规划为文本、向量等模型，提供了文本搜索、语义搜索、向量搜索、组合搜索等数据搜索能力，供推荐或搜索使用；开放了数据写入接口，能够将处理后的实时数据写入到数据服务中

综上，总结一下系统架构 3.0 的特点：

• 继承了原有 2.0 的特点，保留了其优势
• 对于推荐搜索的理解更为深入，结合更为紧密
• 解决了推荐候选／排序／训练的算法最重要问题

系统架构 3.0 功能组件化后，能够更加灵活地组装业务流程，实现不同场景的应用，每个模块都像是乐高积木一样，能够进行动态热插拔，形成工作流标准化。

比如搜索的工作流包含了意图识别、数据召回、结果排序三个关键流程：

• 接收到“用户搜索关键词”后会调用基础组件的 Query 处理服务，对用户搜索意图进行识别
• 接着通过基于文本匹配的搜索召回算法从数据集召回数据
• 排序服务会采用深度模型对数据进行精排，最终展示给用户

这个流程并不是一成不变的，根据应用场景的需要，可以调整每个环节采用的组件。

与搜索不同，推荐的工作流中由于缺少搜索词，意图识别的过程被基于用户行为的 UA 组件代替。在召回环节，从不同的数据源召回数据，并融合粗排后，由排序的深度模型对数据进行精排。不同场景下可以根据自身的业务需要完成工作流的定制，比如在“到家精选”的搜索场景下有着更加复杂的工作流，各模块间的依赖交互也更为复杂，所以组件化的功能实现更加有利于业务的发展。

综上，系统架构 3.0 为了对标准化业务模型提供良好的支撑，需要能够保证：

• 系统性能效率，降低系统的相应时间
• 提高系统的可用性，保证系统的可访问性
• 可靠性，即可恢复性
• 可维护性，即可查证、模块化

本节小结

本节我们介绍了本地服务的多业务推荐工程架构的发展过程，在这个演进的过程当中，技术与业务的关系在架构中得到了很好得体现，总结起来有以下几点。

• 技术来源于业务，同时也提升业务发展，业务发展又反过来推动技术的前进，这是一个相互影响相互促进的关系。和业务共同发展的技术才是有生命力的。
• 技术架构的选型，建议是寻找当前最短路径，然后进行不断优化迭代，一口气吃撑是不现实的，也是不合理的。
• 推广某个框架和工具最好的方式不是行政命令也不是请客吃饭，而是大家都是参与者，如同开源项目中，每个人都是它的主人，这样人人维护，人人使用。
• 团队崇尚简单可依靠，说起来容易做起来难，不过有一个好方法就是懂得自己不应该做什么，而不是应该做什么。

《易经》中八卦的六爻是由两个三爻八卦组成，分为内卦和外卦。所谓内卦，就是下边的三爻卦，代表事物发展的内因，外卦就是上边的三爻卦，代表事物发展的外因。辩证法认为外因是变化的条件，内因是变化的根据，外因通过内因而起作用。

系统架构的演化同样需要遵循内因和外因的相互作用，本讲以本地服务为业务背景，讲述推荐系统工程架构的建设方法。道德经中说“执古之道，以御今之有。能知古始，是谓道纪”，希望本讲能对你有帮助，下一节我们将开始推荐系统的实践算法篇的学习。