16 本地服务业务中的推荐系统实战——算法篇

你好，我是大师兄。15 讲我们讲述了同城本地服务的各个业务背景和特点，以及推荐系统工程架构落地和演化过程。这一讲我们主要讲述同城本地服务业务与推荐算法模型的关系和演化过程。

在课程开始前，我们先回顾一下同城本地服务主站业务特点以及推荐场景位所关注的指标。

主站业务是通用的业务形式，由 APP/PC/M 等端口进入本地服务落地页，以流量生意为主。（开环业务，目前产品形态正在从开环向半闭环演进）。

• 推荐场景：列表页、详情页、落地页等；

• 推荐内容：帖子、商家、店铺、商品、标签等；

• 推荐关注指标：CTR、CVR、Call/UV 等。

本地服务主站流量分发问题与特点

主站场景下的核心目标是通过算法场景化和搜索推荐等分发系统，将主站上的信息资产实现对用户的精准触达。

主站的用户核心行为路径：

• 用户直接带着需求或者不带需求（搜索词）进入主要的服务场景——主站的列表页；

• 在列表页上，用户可以浏览帖子标题、价格等内容，并点击帖子详情页查看详细信息、评论等内容；

• 然后发起线上电话沟通或者通过提供的微聊促进线下成交。

在整个过程中，用户产生的数据信息有列表页详情页曝光、点击、电话、微聊、评论等。

主站流量分发目前具有的问题如下：

• 信息同质化严重：主要体现为一是帖子信息堆叠严重，比如一个帖子中一些无意义的内容占据了很大篇幅；二是可区分度差，比如一个发布保姆月嫂的帖子，其中只放了一张正常女性照片和你懂的三个字。

• 人群结构复杂：存在未登录用户、新用户、低活用户等人群，因此，我们需要制定差异化的推荐策略，并针对性地优化推荐模型。

• 决策周期问题：决策长短周期不一，轻重决策共存，当然也存在短期低频、需求周期短的情况，比如单价高的家装、租车等长周期服务用户会花更多时间挑选决策，相对比较谨慎；而要求短时间内快速解决的管道疏通、空调维修等需求，用户浏览几个店家后即可做决策。

• 多行业、多场景、多种类、多目标：本地服务类目繁多，涉及 200+ 不相关行业、10+ 个推荐场景位，推荐内容包括帖子、商家、店铺等，因此，我们需要结合业务特点，实现不同的优化目标（CVR、CTR、Call/UV 等）。

下面我们针对上面提及的问题给出具体的解决方案。

主站流量分发解法

1.信息供给侧，将内容结构化、标签化

上面提到的问题比较多，下面我们先从信息结构化、标签设计及应用、标签挖掘流程这三个层面，重点介绍在针对信息供给侧，如何提升内容描述能力、增加信息区分度的具体实践方法。

1）信息结构化

针对帖子内容雷同严重、能看出大量拷贝的痕迹这个问题，首先我们想到的是在发布的时候直接解决掉。

于是，我们采用了发布结构化的方式进行解决。

首先，我们在内容发布端针对不同服务定义了多种可选内容模板，商家选择对应的模板，直接填写个性化参数即可完成帖子发布。

其次，针对不同的服务类型，我们在产品侧也进行了相关优化，主要分为 3 部分：

• 服务标准化：以搬家为例，根据用户个性化需求，我们实现了更好地辅助用户进行决策的目标。商家通过不同需求项的选择，即可快速完成服务预订，同时也能得到相应的价格预估，大大缩短了商家决策链。比如车辆信息，商家可以选择具体车辆型号、尺寸、可载量等；比如详细服务，可以选择是否有电梯、小件搬运、支持长途、小件搬运等；比如收费单项，可以选择不同里程对应的价格、超里程计算、无电梯楼层加价、随车人员数量等。

• 服务智能定价：系统通过算法根据已选项进行计算，从而输出一个合理的价格区间。在这个计算过程中，算法剔除了市场中出现的过高/过低的报价，用以规范同城的运营机制和列表页展现结果。

• 相册自动分类：通过相册自动分类功能，使得用户上传的图片可以自动分类到不同相册，方便进行回溯。

2）标签设计及应用

标签化是结构化的一个重要方法，我们先来看一个未优化前的列表页展示页面，如下图所示：

从图上来看，各搜索结果的展现信息都是雷同的，信息罗列程度单一，看不出来各自的区分度，也就很难契合用户的关注，用户体验较差。因此，针重点对这个问题我们重点做了信息标签设计，并体现在产品展示层中。

通过需求搜索词进入列表页后，用户还可以通过搜索词匹配对应服务的标签（比如体现家电维修的快速上门的标签、家政服务的老人看护/做饭服务等标签）。

通过标签设计及应用，不仅展现了标准化的服务特点，还能够更好地细化用户需求，从而契合用户关注。

3）标签挖掘流程

下面我们先通过一张图来了解标签挖掘的整个流程，如下图所示：

从图中可以看出，整个标签挖掘的流程是系统先通过帖子等数据源挖掘备选词，再将备选词库融合形成标签词，紧接着这批标签词通过同义词库和归一规则形成基础标签。然后使用算法进行行业消岐，并形成行业标签，最终行业标签在不同场景进行应用。

2.知识化标签体系：挖掘标签间关系

上面我们提到的标签化是相对扁平的信息，无法体现出标签之间的关联关系。如果我们希望挖掘标签之间的关系，此时该怎么办呢？

于是，我们构建了一套知识化标签体系，如下图所示：

初期，通过标题、评论、搜索词等数据源，我们找到了每个行业中的关注维度，然后根据不同维，定义了种子词。然后经过数据挖掘，系统通过短文本相似把对应其他标签词归类到同一个维度下，并不断地滚动迭代。

知识化标签体系的具体搭建过程如下：

• 我们将各标签词与维度词、维度下的种子词进行向量计算，从而得出距离；

• 我们取距离最近的标签词放入维度中继续作为种子词，这样种子词越来越多，后续标签词分维度会越来越准。

• 根据阈值，可能有一部分标签词还不能归类，还需要继续添加维度，然后在进行下一次滚动，直到所有词归类完毕。

这样，标签之间的关系就被挖掘出来了。根据以上挖掘的标签之间的关系、类目与标签之间的关系、维度与标签之间的关系，最终形成了一套完整的场景化标签体系。

3.场景化标签体系

标签体系是信息的表达媒介，也是结构化的基础。

目前，同城的场景化标签体系规模如下：

• 行业标签（40w+）：根据各行业服务维度进行设计，其分类维度对应不同的标签，比如租车、家装等；

• 通用标签（10w+）：包括用户体验相关（态度好、价格满意）、商家服务承诺、平台评估等标签；

• 应用场景：包括标签筛选、热词推荐、找相似、猜你喜欢、智能摘要等。

【用户场景构建】

利用场景化标签体系，我们进行了用户场景构建，原因如下：在老版无场景提示的条件下，我们发现本地服务的登录用户一进入列表页后的跳出率非常高。

经过分析最后得出的结论是，用户确实是带着明确的需求和目的性进入的列表页，因为在默认结果页中没有找到想要的服务，所以选择跳出页面。

既然是用户是带有目的性的，我们何不事先找到契合高频场景的词，这样至少能让用户在默认页产生一次点击，再利用这次点击逐步引导用户产生后续行为。

通过挖掘用户的服务需求，我们发现其和本身的 CMCS 类目体系是交叉、网状的关系，比如用户想找水电改造服务，在标签中对应就是装修建材——>局部维修——>水电改造。

可以看到右图，一开始我们是使用弹窗的形式让用户选择，考虑到这种阻断式提醒非常影响用户体验，优化后，采用了顶部横滑的方式进行展示。

从上图可以看到，用户需求的细化和标签属于一对一的对应关系，用户在横滑模块中选择的功能服务或者使用场景（也是一类标签，这类标签代表用户的在特定场景下的需求，具有很强的用户属性，用户看到后很容易产生共鸣，下文将提到这类标签如何挖掘）就可以对应到结构化标签中，并通过标签进行特定召回。

4.类目标签体系

有用户属性的标签，我们称之为类目标签。因为这类标签描述比较宽泛，具备跨类目属性，所以我们采用了合并、拆分原有类目的方法来建立类目标签体系。

1）类目合并

主要有以下几种方法。

• 需求侧：根据搜索词进行类目预测，并计算出类目预测 PMI（类目词的贡献值）；

• 内容侧：根据帖子标题检查类目词的相似度，并通过 Tagging 计算词频；

• 用户行为数据应用：采用转化行为前 24 小时点击过的 Top3 类目和个数，增加阈值筛选等方式计算类目词频繁项；采用用户随机游走计算类目相似度的算法。获取用户点击商品、电话的点击序列，按照点击类目是否相同分别打分，再根据构造出来的类目图关系，通过随机游走算法产生行为序列，然后通过 SkipGram 计算词向量，最后计算类目词之间的相似度。

2）类目拆分

主要有两种做法。

• 采用通用的知识图谱：比如对家电维修类目进行拆分，因为家电在通用图谱中是有下位词的，如电视、冰箱、洗衣机等，所以根据下位词和模板可以挖掘出是电视维修，还是冰箱维修。

• 采用帖子图聚类算法：首先，根据用户行为获取两个帖子之间的点击、电话序列，同时赋予不同的权重，并构造 I2I 关系图，然后根据图进行聚类，从而得到帖子聚类表。接着将每个帖子对应到一个集合中，再对图进行 DeepWalk 的训练生成帖子向量，然后对集合的 Embedding 进行表征，最后利用表征关系计算集合间的相似度。

通过合并、拆分类目，再结合高频搜索词挖掘，我们就可以找到需求词，也就可以构建场景标签了。

5.用户意图感知

前面我们已经完成了用户场景化分发体系的构建，如果想快速感知用户意图，还需要进行场景化的构建，这一步非常关键。

下面我们通过一张图来看看场景化的整个构建过程，如下图所示：

从图中可知，从用户的需求侧到供给侧编织了一张大网。

• 其中，一端是用户；

• 另一端是已经经过结构化的帖子店铺和商品 SKU；

• 中间通过类目标签（需求侧标签）和内容标签（结构化标签）串起来。

整个场景化的构建过程：通过获取用户画像和点击对应类目的行为，再选择类目对应的结构化标签，召回对应的商家帖子和店铺，即通过信息的结构化快速找到对应服务的 SKU。比如搬家——>公司搬家——>拆装服务——>展示出有拆装服务的优质公司搬家店铺。

长期偏好可以通过用户画像获取，实时意图可以通过意图系统获取（下文介绍）。

因为用户端存在对应的用户画像，所以用户点击对应类目时，可以直接关联到对应的结构化标签中，从而召回对应的商家帖子和店铺。

上图就是整个用户使用流程：用户点击横滑模块的标签后，即可看到已形成结构化的标签列表，通过标签挑选，用户即可快速找到对应的帖子和关心的服务 SKU。

分层优化

刚才说的是场景化构建过程，构建场景化的目的是在默认页面让有明确需求的用户在短时间内找到想要的服务，从而减少用户跳出。只要用户有了点击，我们就有希望明确用户的意图。

除了可以使用默认页面查找服务之外，用户还可以使用搜索或者推荐等功能。因此下面有必要介绍一下在分发系统上的分层优化方案。

如前面我们提到：快速感知用户意图十分关键，而用户意图是树型或网状的关系。下面，我们讲讲如何感知和表征这关系，如何在算法分层上进行优化。

以同城本地服务推荐流程和算法架构为例，一起来看看推荐算法的具体架构，如下图所示。

从图中可知，在线架构主要分为召回层、粗排层、精排层、融合和重排层这四大部分。

• 召回层：从物品库中根据多个维度筛选出潜在物品候选集，并将候选集传递给排序环节。在召回供给池中，我们可以看到多个召回集，整个召回环节的输出量往往以万为单位。

• 粗排层：利用规则或者简单模型对召回的物品进行排序，并根据配额进行截断，截取出 Top N 条数据输出给精排层，配额一般分业务场景，例如对同城本地服务推荐分品类进行配额，整个粗排环节的输出量往往以千为单位。

• 精排层：利用大量特征的复杂模型，对物品进行更精准的排序，然后输出给重排层（融合层），整个精排环节的输出量往往以百为单位。

• 融合和重排层：以产品策略为导向进行融合和重排，例如同城本地服务推荐将商品、SKU、帖子、标签等不同展示元素融合在一个列表中，并且经过去除已曝光、去重、打散等策略，并根据点击回退在列表中插入新的信息来提升体验，最后生成用户可见的推荐列表，整个融合和重排环节的输出量往往以几十为单位。

以上我们阐述了数据生成部分的推荐算法架构，接下来我们着重讨论如何将分层进行优化。

1.召回优化

1）热门召回策略

热门策略是一种非常有效、通用的简单召回策略。下面我将同城本地服务帖子推荐业务中使用的 3 种热门策略总结如下。

• 附近用户热门点击：离线统计最近两个星期用户定位 Geohash 下的帖子的热度，并将帖子按照点击量进行话排序；

• 附近用户热门电话：离线统计最近两个星期用户定位 Geohash 下的帖子的热度，并将帖子按照电话量进行排序；

• 纠偏热单（城市维度）：根据每个用户近一年的点击、电话行为、使用时间衰减离线统计帖子的热度，然后根据 item 在用户点击 Session 中的偏序关系计算每个帖子的 COEC（Click on Expected Click）热度，最终以物品所在的城市作为 Key 存储。

2）协同过滤召回策略

协同过滤策略同样也是一种非常有效的简单召回策略。下面我将同城本地服务帖子推荐业务中使用的协同过滤策略总结如下。

• ItemCF 策略：离线统计最近 30 天用户对帖子的点击行为，然后根据两个帖子的共现计算帖子之间的相似度。线上以用户的点击作为触发源，每个源 id 取 20 条 item，merge 结果，最终取 50 个得分最高的帖子。

• UserCF 策略：根据用户点击、电话行为离线计算用户之间的相似度。然后在线上取 10 个相似用户，并将推荐用户的最近行为合并结果，最终返回所有结果。

因为传统召回方法召回的候选集物品限定在用户的历史行为中，例如常买、附近、历史行为、热门、协同过滤，且难以结合候选物品的辅助信息（比如品牌、品类等 ID 信息），这就使得推荐结果存在发现性弱、对长尾商品的效果差等问题，容易导致推荐系统出现“越推越窄”的问题，制约了推荐系统的可持续发展。

因此，我们还需要引入向量化召回策略。

3）向量召回策略

向量召回策略是将用户和物品通过 DNN 映射到同一个低维度向量空间中，然后通过高效的检索方法去做召回。

向量召回策略主要利用用户属性、上下文信息、以及实时/历史用户行为来进行建模，然后利用深度学习模型建立用户及物品向量，然后通过预测用户向量扩量召回更多相似物品，并为新物品构建向量以便召回，提升现有召回效果。

不管用户是否带着 Query 词进入列表页，此时用户总会有上下文信息，如用户画像、所在场景、点击标签、点击行为等。我们有一套用户意图系统，通过系统改写 Query，可以串出用户意图树，再根据意图树在引擎中召回帖子、店铺列表等。这种改造 Query 词的方式其实是一种布尔召回，召回深度偏低。

因此我们希望通过建立用户意图表征，优化成以向量召回，提高泛化能力，从而提高召回深度。

4）用户意图表征

那怎么做用户意图表征？首先我们需要对近期的帖子文本内容进行清洗、分词、标签化，再通过 SkipGram 形成最终词向量。

不过，这种方式存在问题：整体帖子内容多而杂，表意性稍差。为此，我们引入了业界通用的腾讯 AI Lab 中文词向量，虽然在本地服务场景下无法直接使用，但我们通过在 SkipGram 之前对词向量做了初始化，利用了词向量的预训练结果。

完成这步操作后，在人工评测时效果大幅提升，相似召回率提升 2 倍+；在线上验证应用时，标签推荐 CTR 效果提升了 4%（标签推荐不涉及帖子标题、企业等其他信息，因此可以用来验证词向量是否准确）。

在预训练的基础上，我们将用户的近使用的序列进行了清洗，然后放到模型中训练。

• 在对模型增加行为序列时，也有一些应用技巧，下面我分享一下。

• 针对标签的点击行为数据稀疏这个问题，我们可以做一些前期处理，比如根据时间把长 Session 进行切分，根据长度取 TopN 做数据增广、通过 Dropout 做泛化。经过前期处理后，整体数据训练样本量基本达到预期。

• 为了持续保持用户的原有信息不流失，我们可以根据 Session 生成用户向量，再对用户前一段的向量进行初始化。增加了用户使用序列后，线上标签推荐的 CTR 转化效果提升了 15%，涨幅非常明显。

5）用户意图多目标表征

前面我们提到本地服务的优化目标多样，这些目标在实际推荐效果中都要有一定程度的满足，也就说模型需要平衡多目标，对用户把握更全面。那么，我们应该如何训练最终用户的表征向量呢？

我们使用了多任务学习模型，通过共享部分网络结构，来学习基础通用的表征。而相对多个单任务模型，多任务模型有以下优点：网络结构更小、在线 CPU 使用率更低、支撑更高 QPS、性能稳定性高、存储资源更少。

同时，学习用户的通用表征向量，也可以更方便迁移到其他任务模型中。根据前期的数据准备，对用户行为序列做 Embedding，再接入双向 LSTM，即可根据 Embedding 对用户行为序列本身进行表征。

在完成表征后，考虑到用户行为千变万化，还需要再加一个 Attention 网络，即当用户搜索或者用户本身有这样的标签时，可以及时捕捉到对应行为序列中的变化点，并反应到网络中，最后形成 128 维的用户表征。因此，可以实现根据不同优化目标，可以选择不同网络进行学习。

以 CTR 目标为例，将生成的用户通用表征和 Item 通用表征，一起放在网络中对 CTR 进行优化。

【多目标表征的几点启示】

• 相关任务：多目标学习的各任务之间需要有一定的相关性，否则会起反作用。至于具体是什么样的相关性，在实际应用中需要具体考量。

• 增量学习：前面我们也说到在多目标学习模型中增加了 Attention 网络，而随着时间和用户兴趣的变化，Embedding 表征也会随之变化，比如固定时间间隔自动按照增量、每天级进行更新等，让模型更贴近用户的近期数据。

• 数据稀疏问题：多目标表征可以解决一部分样本稀疏问题，比如帖子 CTR 点击数据多，电话、微聊 CVR 转化数据少，因此可以通过 CTR 数据解决一部分 CVR 数据问题（Share）。

• 模型泛化特征更有效：加了多个任务目标后，其他任务对当前任务有正向作用。通过模型 AUC，在线上测试集中来看，多目标学习优于单目标学习，在训练集中相反，不过这个影响不大。实际上，我们认为多目标学习的作用是在单目标基础上增加了正则项（原本网络训练时也需要加入正则），有一定促进作用。

• 模型效率问题： 比如 CTR 训练任务中有 1W 个物品就需要计算 1W 次，由此可见每次调用时，耗费资源很高。如果最终只需要生成一个 User 表征，其实我们可以只计算一次。

• 样本偏差问题：离线的均值、方差需要与在线保持一致，这一点务必注意。

上图是加上多目标表征做召回的实验效果，从图中可以看到，尽管样本没有发生太大改变，但是 PV CTR、UV CTR 都有 1% 以上的提升。

2.排序优化

1）粗排优化

粗排是排序模块中的一个大数据量初筛功能，它具备计算复杂度低、支持大规模在线预测等优势，这就意味着需要的特征尽可能少，模型尽可能简单且具备一定的交叉表达能力。

那么针对用户类特征、上下文特征、物品静态特征比较多的情况，我们使用浅层模型就可以表达得很好，然后在加入少量用户和物品交叉类特征作为补充（这类特征可依赖模型的自动交叉组合生成）。

排序上优化重点在如何挖掘用户点击的实时意图。

通过收集用户各种行为数据，并做数据清洗、数据存储和权重计算，最终我们将一些行为更新、过期管理、分值衰减等存储在用户意向表中。

说明：这里最终存储的就是用户的行为和对应行为的分值、标签和对应标签的分值。

在统计标签分值时，我们需要从如下三点考虑帖子标签的权重：

• 不重要、无区分度的标签，权重相对较小；

• 根据用户对帖子行为距离当前的时间设置权重，时间越近影响越大；

• 不同行为类型权重不同，如搜索、筛选、电话等需要设置不同的权重。

2）上下文感知

刚才得到的是对用户行为特征的意图挖掘，可添加到线上网络中应用。而网络中还涉及大量的其他特征，如人群、商家、场景特征等。由于用户点击序列不会特别长，点击特征可能存在冷启动问题，所以我们还需要通过更多的场景、商家特征作为补充。

因为这些特征的维度特别高，所以我们需要通过几层网络来做降维，最终形成有上下文关系的用户意图感知。

下面我们通过一张图看一下实时意图特征应用的实验效果：

通过提取帖子中大量的内容标签，并根据用户行为进行标签匹配，从而产生用户所感知的信息，我们发现图中对应场景下的转化效果有一定提升。

3）展示优化

由于帖子信息特别繁杂，且用户意图实时变化，也就是说列表页有时展示的信息不一定契合用户的当前需求。因此，我们制定了一套智能展示策略：基于用户服务标签、用户行为等数据，我们根据用户实时意图对帖子本身进行展示区分，同时改变其结构化信息，以便让展示的内容更契合用户关注。

因为标签、标题、图片、摘要等展示内容会随着用户的实时意图随时发生改变，所以极大地提高了对用户需求的关注粒度，并有效地提升了用户体验。

算法驱动优化

1.算法驱动框架（ADF）

在实现本地服务推荐业务流程的时候，我们发现算法模型的预测响应时长一直居高不下，系统性能也就难以保证。

通过分析得知，每个算法模型预测的平均执行时间普遍大于 20ms，如果有多个模型串行，那么将耗费更长的时间，这就使得响应时间不可控。此时，我们该怎么办呢？

了解到每个算法模型之间相互独立，不存在依赖关系，所以我们可以将串行的算法执行优化为并行执行。算法模型并行化后，通过执行时间最长的算法模型计算，可以极大地减少了响应时间。

不过，异步代码的实现难度较高，代码复杂，并且系统的维护成本也会越来越高。为此，同城本地服务事业群算法策略部实现了全异步的算法驱动框架（Algorithm-Driven Framework，ADF）来降低并行的技术成本，如下图所示：

• Operator ：它是一个可复用的算法执行单位，整个生命周期分为初始化、算法配置、算法执行、结果获取、配置清理五个阶段，每个阶段都有相应的钩子方法，方便算法的实现和扩展。

• Processor : 它主要负责接收请求事件，并且能够根据实验策略配置将 Operator 通过串行或并行的方式组合在一起，以便异步驱动 Operator 执行，并获取最终的执行结果。

该框架通过管理后台、数据库、文件等多种配置方式将算法组合在一起，从而构成实验策略。通过实验策略，我们只需要实现相关接口即可将算法接入系统，从而实现算法的复用。

同时，为了降低系统的维护成本，ADF 实现了算法策略编排的能力。

在初始化的时候，系统通过扫描将已实现的算法模型加载到系统中。应用层能够指定算法能力模型，构建相关场景的实验策略，建立推荐任务，并注册任务上下文管理中，任务编排执行框架，将算法模型编排成指定的实验策略，并通过并行或串行的方式进行资源调度，获取执行结果。

2.事件驱动框架（EDF）

在实现本地服务推荐业务流程的时候，因为推荐系统在数据处理过程中（比如新增文档）需要经过多个不同的处理流程，所以必然会增加新的处理逻辑。此时，如果采用“请求响应”模式，因为各处理器之间间耦合度较高，非常不利于系统的扩展。

为此，同城本地服务事业群算法策略部研发了高性能异步事件处理框架（Event-Driven Framework，EDF），如下图所示：

从图中可知，该框架采用了事件驱动的方案，将新增文档、更新文档、删除文档等对文档的操作定义成相关事件，再由系统将事件分发给不同的处理器进行处理，这样就可以有效地提升系统的可扩展性了。

而且，EDF 还提供了一系列事件的管理的功能，比如事件回溯、事件回放、监控报警等，如下图所示：

通过图中可知，在典型的生产者-消费者场景中，生产者生成相关事件并发布至 RingBuffer 中。

RingBuffer 是预分配的事件数组，它主要采用更新的方式接收事件。

EDF 框架采用多消费者对 RingBuffer 中的事件消费，相同类型的消费者组成一个 Group，多个 Group 组成广播组，事件到达广播组所有的 Group 后，Group 会指派一个消费者对事件进行处理。为了提高处理效率，Group 会根据负载情况动态调整消费者数量。

EDF 框架还通过“消费者屏障”管理消费者之间的依赖关系，上图中屏障 1 与 RingBuffer 交互，Group A、B 向屏障 1 申请事件的引用，并指派 A1、B1 处理该事件。

此外，EDF 还采用了事件预分配机制和无锁算法，使得平均响应时间进一步减少。

• 事件预分配： RingBuffer 的数据结构是预先分配数组，频繁的生产消费对 GC 并没有影响，大大减小了系统的最慢响应时间，更不会因为消费者的滞后导致内存溢出（OOM） 的发生。

• 无锁算法：使用 CAS 机制同步线程，遵守 single writer 原则，一块内存对应单个线程。

本节小结

这一讲讲述同城本地服务业务与推荐算法模型的关系和演化过程，本地服务涉及 200+ 基础行业的方方面面，比如中小商家、务工人员等，都是依托整个平台流量而生存。

因此，我们需要思考如何更好地匹配商家和用户，根据生态更好地进行演化，做到更好的优胜劣汰；需要思考如何把产品规则和算法目标更好地融合。

目前初步的想法是把产品规则前置，减少规则性对算法输出结果的破坏和干扰。