哈啰搜索推荐一体化建设

搜索和推荐可以说无处不在，最主要的特点就是个性化，能根据不同用户不同的喜好给用户推荐不同的物品。推荐的本质是建立user与item的匹配关系，搜索的本质是建立user与query与item的匹配关系。

为了达到最佳的匹配关系，整个解决方案也在不断探索和进步。但不管是什么样的场景，我们解决这类问题的演进路线都是类似的。初始阶段基本以人工运营和热门榜单为主，因为新的系统是没有数据积累的，我们对用户还没有数据上的认知，通常会使用全局或者是行业最热的物品来进行展示。第二个阶段，我们在之前的基础上引入一些简单的模型来做推荐，这时的算法模型是从0~1的，效果提升也是最明显的。第三个阶段，简单的模型已经没有办法充分利用现有的数据，就需要考虑在现有的数据基础上，怎么样去设计更复杂的模型，达到更好的推荐效果。推荐的基础有两点，一是信息要过载，二是必须有可利用的数据。

常见的链路比较类似，分为数据和算法模型部分。整个算法的链路分为召回层、排序层和重排层，数据部分我们会利用一些实时数据、准实时数据或者离线数据，通过特征工程产生user维度、item维度和context维度的特征。这些特征是我们的算法模型进行训练和预估的输入，这样从数据到模型，整个链路就串联起来。

召回是降低后续链路排序压力的重要环节，同时可以保证一定的相关性，避免我们在排序预估的时候，给用户展现出bad case。召回中样本的设计是十分重要的，因为在召回与排序中，我们对于模型样本的设计要区别对待，所以对于召回需要重点刻画它的正负样本。

常规个性化召回有热门召回，LBS、u2tag2i、协同过滤、新品召回等。目前常用的召回都是基于Embedding的框架，如YouTube的召回是以用户点击的item作为标签，做视频的召回。Airbnb对于民宿的召回也是基于Embedding框架，同时做了很多的trick。FM、DSSM都会产生用户的Embedding向量和item的Embedding向量，这两个Embedding向量产生出来之后，我们可以做一些向量相似度的计算，对用户召回比较感兴趣的item。在向量相似度计算中会用到向量引擎，哈啰向量搜索引擎是Milvus。

用户有关键词的召回前面还有query parse，需要对用户的关键词做一些处理，包括预处理、分词、纠错、实体识别等。主要目的是保证文本相关性，我们实现的模型是基于BERT，提升实体识别的精确度，目前已经用在了酒店的关键词搜索中。比如用户输入的query是维也纳上饶高铁站，这时我们需要去识别出用户目的，相当于用户搜的维也纳是酒店名称，上饶高铁站是地理位置，上饶是城市名称。我们依据这三类的实体再分别进行召回，可以满足用户输入的query需求。

精排模型其实就是数据加特征加模型，同时在精排的链路里，我们经常会用到的是一些大规模的离散特征和连续特征，并利用一些比较复杂的模型，因为这时我们要保证精确度。对于精排模型，特征决定了排序的天花板，所以我们要做的第一步是设计符合业务场景的特征，这里就不展开。

我们主要介绍一下哈啰的模型演化路径，前期是一些小规模的DNN模型，模型的参数相对较小，之后我们实现了大规模离散的DNN模型，如DeepFM、DCN、DIN等。目前DeepFM和DCN模型依然是新场景会优先考虑的模型，这类模型简单高效，一般在简单的场景下可以拿到比较好的效果。但随着场景接入越来越复杂，我们需要兼顾多目标多场景的推荐问题，所以我们做了一些ESMM、MMOE、MBN等模型，并且也在尝试用元学习做跨域的推荐。

重排的定位是提升用户体验、保证内容的多样性，同时有一些业务运营的逻辑。虽然这一环节不会很复杂，但它其实最贴近业务，对最终的排序效果影响最大，所以这里的设计需要尽量保证我们模型的结果不会被大范围改变，同时去兼顾用户体验和运营策略。比如说打散，我们去把同类目的商品进行打散；还有曝光过滤，用户多次看过的就不让继续展示。同时对新品做提权等，需要根据不同的业务需求进行设计。

我们面临的问题是新业务的场景越来越多，如果从0到1实现整个链路，需要花费很大的人力成本。如何将现有的算去迅速扩展到新增场景，同时还可以去持续优化我们重点的场景，我们就提出了搜推一体化引擎和算法组件，彻底改变之前单个场景单独定制接入的方式。

常见的解决方案是搜索引擎和推荐引擎分开，但一体化是业界比较先进的趋势。搜索从纯文本相关逐渐走向个性化，推荐从轻内容理解到重内容理解，它们的架构和算法越来越趋同。部分头部大厂如阿里云已经开始尝试一体化的架构设计，但由于历史包袱较重很难彻底。哈啰作为新兴平台类的业务具有后发优势，直接一体化会减少很多重复建设，可以进行部分链路的合并。

一体化引擎可以融合搜索引擎和推荐引擎的主要模块，包含通用的排序模块、召回模块和内容理解的模块。这样一体化引擎有自己独特的部分，也有不同链路之间共用的部分，能大大减少重复的工作，同时提供给业务方可以通过低代码量进行接入。

一体化引擎需要去兼容多种复杂场景，具有很大的挑战。我们考虑到如果要做标准化的引擎，第一步就是要做数据标准化。离线的数据需要去通过数据映射字段映射成标准的数据，实时的数据需要在曝光、点击、下单的事件中做一些埋点标准化的工作，这样到我们算法中的数据都是一些相对标准的数据，就可以做一些标准的处理。

一体化引擎有两个重要的部分，一是配置管理中心，二是线上的链路。它依托于数据的标准化和接入的标准化，会提供服务编排的配置中心，整体的线上链路以QP、召回、排序、重排阶段作为流程的编排骨架，进行各阶段组件的组合。对于新接入的业务系统，它的工作量就很小了，只要去配合引擎做相应的输入以及es数据源的提供，就可以接入我们的推荐能力。

离线部分我们通过SQL的映射，产生一些标准的字段，这些标准的字段通过一些通用的逻辑，去产生用户维度或item维度的特征。而这些特征对于我们的模型，相当于是提供了相对比较标准的输入。召回环节也是一样的，利用这些映射好的字段，进行召回通道的计算，这样通过映射会让不同的场景映射到相同的字段上，我们产生的结果和计算逻辑是一样的。

线上部分召回池我们可以去配置召回的通道及召回的个数，排序我们去配置决策流ID，配置文件可以自动把整个链路包括 QP、召回、排序串联起来，离线和在线的组件和服务编排可以依托于配置文件进行自动生成。

目前算法通过数据标准化和智能组件池已经实现了很多组件。数据标准化我们通过一些字段的映射以及通用的埋点，可以产生标准的用户画像特征、item画像、用户统计的特征、item统计的特征，这些标准的特征进入意图识别组件池或召回组件池以及排序组件池里，相当于有标准的输入，这些组件池提供了不同的模型以及离线的任务，这些离线的任务可以快速利用到其他的场景中。

我们的意图识别组件池实现了分词和实体识别，召回组件池有热门、标签、query召回、item2vec，排序组件池有DeepFM、XdeepFM、MBN等，重排组件池有提权、曝光过滤、打散等。这样业界主流的算法组件都已经具备，整个链路基本上覆盖，接下来我们会继续去开发一些更高阶的组件，最终实现标准化的接入方式，让业务方接入搜索推荐算法能力的效率有很大的提升。

一是商品类的推荐，具有促进成交的属性，我们覆盖了金融借贷、哈啰好物、电动车商城等，提升CTR、GMV等。二是feeds流类的推荐，带有促进用户活跃属性，包括逛逛、电动车社区、电动车用车页等。三是搜索排序，有用户强意愿，需要满足相关性，召回全，我们覆盖了租车、酒店等。总体上我们覆盖了十多个场景，取得了不同程度的效果提升，并且场景还在不断增加中。