如何从 0 到 1 构建个性化推荐？

文章作者：曾钦榜 58同城高级技术经理

编辑整理：周晓侠

内容来源：58技术沙龙

出品社区：DataFun

注：欢迎转载，转载请在留言区内留言。

导读：随着科学技术的飞速发展，互联网被广泛应用于各个领域，而以互联网为基础的招聘模式也越来越受到企业的青睐。互联网招聘具有不受地域限制、覆盖面广、招聘成本低、针对性强、方便快捷、时效性强等优点，现已得到广泛应用，其中，58招聘是互联网招聘行业中规模最大的平台。今天主要跟大家分享下58招聘如何通过个性化推荐技术服务大规模求职者和招聘企业。分享题目是从零到一构建58招聘个性化推荐，主要通过以下三方面进行介绍：

招聘业务介绍

个性化推荐实践

心得分享与规划

——招聘业务介绍——

58招聘业务简介

2018年我国全国总人口13.9亿多，其中就业人口7.7亿，招聘基数庞大。三大产业就业人口占比分别26.11%，27.57%，46.32%，其中第三大产业占比最大，部分发达国家第三大产业占比已达到70%~80%，随着经济的发展，我国未来就业市场和就业分布将发生大的变化。2019年8月城镇调查显示我国失业率为5.2%，其中25~59岁失业率4.5%，同时每年有800多万的应届生加入就职市场。58招聘作为我国互联网招聘行业之首，每天服务于千万级求职者和大中小企业，平台每天生成千万级连接，促成大量求职者求职成功。

58招聘平台主要服务于求职者和招聘方，接下来主要通过求职者的角度介绍用户在整个平台流转的大致流程，具体如下：

基于求职偏好搜索职位并点击查看详情。

投递有意向职位，或通过平台在线微聊工具、电话与招聘方做进一步沟通。

双方达成共识后，进行面试与入职。

相比传统推荐系统，58招聘的业务漏斗更长更深，并且有一部分转化平台无法完全捕捉，形成了58招聘个性化推荐开展的难点及挑战。

58招聘推荐场景类型

58招聘推荐场景主要面向 C 端求职者和 B 端企业，推荐内容主要包括：职位推荐、标签推荐、企业推荐、简历推荐。

C 端求职者的典型推荐场景包括：

App 首页招聘大类页：主要包括职位专区聚合、职位 Feed 流。

类目推荐: 用户点击某个类目后，进行相关职位推荐。

相似推荐: 用户点击某个具体职位后，在下方展现相似职位。

58招聘推荐主要问题

58招聘推荐相对其它行业主要存在以下典型问题：

海量数据计算：大多数公司都存在，此处不做详细说明。

冷启动问题: 58同城服务于多业务，包括招聘、房产、黄页、二手等，求职者进入招聘板块使用招聘功能，由于当前不强制用户填写简历，导致无简历用户冷启动问题。

稀疏性&实时性：58招聘的一部分群体为蓝领用户，他们在平台产生的行为是短时间的、连续的以及稀疏的，可能活跃两天找到工作后就不再活跃。其次，有些用户回到平台，求职意愿可能会发生变化，一部分可能想找别的工作（如之前是服务员，现在想找快递），另一部分可能是因为传统职业存在职位进阶的过程，这些都需要系统思考。

资源分配问题：第一，如何有效识别（企业，求职者）的真实意图，进而合理分配资源产生有效连接，针对不良意图进行差异化对待。第二，招聘对于 C 端和 B 端都是有限的资源，招聘方招聘职位有限，求职者与招聘方交互有限，很大程度上不同于淘宝推荐，因为后者的商品是无限供应的。

——招聘个性化推荐实现——

58招聘个性化推荐实现

58招聘个性化推荐的实现过程与大多数公司推荐模块基本相似，包括用户意图理解、内容召回、内容排序、内容展示四个核心模块。下面将结合业务特性，介绍每个模块实现的关键点。

如何理解用户？

58招聘用户理解主要通过“言”和“行”识别用户真实意图，重点关注的属性主要包括招聘领域求职意向、用户个人属性以及外在形象（如上图左边）。围绕求职者与招聘方在平台产生的内容及行为，我们构建了相应的知识图谱和用户画像。

2.1 无诚意用户识别

在理解用户之前，我们首先需要识别出无真实招聘/求职意图的用户，并进行差异对待。如频繁发布包含联系方式的导流信息、发布高薪诱惑等恶意虚假信息等，将用户引导至平台外进行转化。针对以上业务我们总结了一些特点，主要表现为：

暴露联系方式

内容不成句

高薪诱惑

在平台很“活跃”

针对以上业务特点，我们主要的识别方法包括：

传统的关键词+正则识别方法，如针对"微信"、"QQ"这类联系方式的相关关键词等。

针对变形联系方式，基于拼音+滑动窗口进行识别。

采用命名实体 NER 识别进行挖掘，如 BiLSTM+CRF。

采用相关分类算法进行识别，如 fastText，CNN。

在无诚意用户识别过程中，我们总结了以下心得：

举一反三：问题用户识别是典型的对抗场景，策略构建时需要更多思考对抗能力的刻画，将一些强对抗能力的特征加入到模型中（如文字变形、文字转拼音）。

刚柔并济：差异化惩处不同问题类型的用户。对平台其他用户伤害巨大的群体，结合法律手段严厉惩处；处于问题边界的，则主要通过较柔和的方式处理（如内容展示降权），减少剧烈对抗现象的产生。

2.2 知识图谱构建

知识图谱是一个非常复杂的系统，包括多元异构数据搜集->知识获取->知识融合表示->知识推理->知识管理多个部分，主题及时间因素，我们重点介绍下在 NER 方面的探索。招聘业务场景含有大量的文本内容，通过 NER 技术能够有效提取文本中的关键信息，进一步提高系统的结构化理解能力。

NER 开展经历了两个阶段：

第一阶段：基于平台已有的部分结构化实体词，以及不少半结构化组织的职位描述基础，我们采用 bootstrap 方法，快速迭代进行挖掘，并结合半人工标注，为深度学习构建更完整的样本数据集。

第二阶段：将第一阶段的内容作为 input，核心采用 BiLSTM+CRF 构建实体识别深度网络，有两个优化点取得了较好效果。第一个是输入层基于字到词的优化，构建招聘领域的专有词库。第二个是采用训练样本增强技术，将相近实体词和同类实体词进行替换扩大样本集，并将模型识别的结果有选择的放回训练集重新进行迭代训练，减弱对标注数据集的依赖。目前命名实体识别仍在不断优化，识别准确率平均达到0.75+，部分准确率可达到0.9+。

2.3 构建用户画像

用户画像是个性化推荐系统的基础模块，决定了对用户意图理解的准确与否。基于标签传递思想，我们通过统计规则、传统分类模型和深度模型多种算法结合捕获用户行为的兴趣表达，构建长短期用户画像。

基于统计规则：通过窗口形式，近实时对用户画像进行计算更新，计算时加入时间衰减因子、行为权重因子及标签置信度权重。深刻理解业务场景，进行合理数学设计是关键。如信息列表页的点击数据，在使用时要差异化处理列表页直接展示的显性标签及隐藏在详情页的兴趣标签，避免人为引入噪音。

基于传统分类预测：采用分类算法，应用到用户属性填充、异常用户/行为识别及用户分类多个方面。并非所有的求职用户都会留下较详尽的简历，我们借助历史的招聘简历与用户行为组织样本，可有效预测性别、年龄段、期望工作岗位等用户信息，优化简历缺失或不完善的冷启动问题。同时，针对用户行为的聚焦情况，通过模型能够有效识别出一些异常数据、识别求职目的明确型及发散型两类求职用户，进而剔除掉部分噪音数据提高样本精度，对不同用户定制差异化策略，提升推荐整体刻画能力。

基于行为序列预测：借助统计规则及传统分类，基本建设出一个可用画像，但对用户多个行为之间的信息捕获有限。我们将用户搜索浏览、简历投递、在线沟通等行为组织成行为事件序列，采用 LSTM、GRU、Attention 等训练模型预测用户兴趣，当前还在探索评估阶段。

召回模块

58招聘推荐围绕个体、群体、全局三个召回不断细化演进，不同召回满足不同需要，三者结合服务于各类场景。从2016年到现在，我们先后主要经历了基于上下文内容、协同过滤、精细画像、深度召回几个阶段，演变成当前以上下文与用户画像结合的精准召回、协同过滤召回及深度向量化召回为核心策略的召回模块。

3.1 基于上下文+用户画像的精准召回

该策略是业内十分常用的召回方法之一，核心在于结合用户画像对请求进行丰富改写。绝大部分场景，用户主动搜索或点选的条件有限，借助用户画像中的历史兴趣及知识图谱组织的实体关系，我们对岗位、工作地、薪资、行业等多个维度进行条件扩充或必要改写，多路召回匹配用户的职位内容。

该策略的主要优点：可解释性好、实现时间成本低，缺点和难点是过度依赖标签挖掘的准确性。

3.2 基于业务特殊性的协同过滤算法改进

协同过滤是推荐系统经典的召回方法，通过用户与物品的行为挖掘用户与用户、物品与物品之间的关联关系。招聘业务的求职者数量巨大，且是短时间的稀疏行为场景，我们采用基于物品的协同过滤，同时希望能近实时的将实时行为信息组织进服务。

在技术实现过程中，我们参考了腾讯2015年发表的Paper《TencentRec: Real-time Stream Recommendation in Practice》，赋予职位点击、投递、在线沟通等不同的行为权重进行多行为融合，基于用户行为序列的长度以及用户质量设计用户惩罚因子，同时通过时间衰减因子增强近期行为的表达，这三个因子的设计与 Paper 基本一致。另外针对业务特殊性，我们改进了职位相似度的计算，加入了职位相似度控制，避免求职目标发散的用户影响职位关系的组织。算法上线后，在点击率、投递率方面都取得了正向收益，其中详情页的相关职位推荐提升超过25%。

3.3 Embedding 深度召回探索

协同过滤虽然取得了不错的业务收益，但其依赖于用户与物品的行为矩阵，对于行为稀疏的场景天然表达有限。而恰好，58招聘业务的流量构成中，有一部分是三四五线城市，城市越下沉数据稀疏的情况也越凸显。针对这类问题，我们希望进一步挖掘行为数据的信息，很自然的想到基于深度学习的向量化 Embedding 召回。我们核心参考了 Youtube 的 DNN 召回思想，基于业务现状做了调整优化。

职位向量化：我们将求职者对职位的行为序列看作一系列上下文，利用 word2vector 思想进行向量化表达。Input 部分，包括职位特征、职位所属的企业特征和求职者反馈特征。Output 构建，业务漏斗越深的行为选择的窗口越大，并基于用户平均的行为长度作为窗口设定的参考值。针对无历史用户行为的新职位，使用职位的文本结构化信息，通过历史训练所得的标签向量表达经过 average-pooling 作为初始向量，解决冷启动。

用户向量化：构建一个多分类 NN 网络，Embedding 层将用户发生行为的职位向量化直接迁移过来使用，输入用户的简历及画像信息进行向量训练。最上层理想情况是一个极限分类，以用户真实发生行为的数据作为正样本，未发生行为的数据作为负样本，构建损失函数进行最优化训练。58招聘场景有千万级别的职位，极限分类需要巨大的计算消耗，当前资源无法满足。因此在负样本选择上，我们使用降采样机制，随机从求职者关注的城市及岗位下未发生行为的职位中按一定比例抽取负样本。线上会实时的采集用户行为，以窗口形式对用户向量进行更新。

线上服务：借鉴 Facebook 的 FAISS 实现，线上用户发起请求时，通过求职者的向量表达，去获取与其最相似的 TopN 职位，返回给推荐系统。

Embedding 向量化召回，还处于初期探索，仍需要在样本、输入特征及网络参数调优开展大量工作，期待有更显著的业务收益进一步与大家分享。

排序迭代历史

相比其他推荐场景，58招聘的漏斗更深，并且是典型的双边业务。系统不断优化提升求职者点击、投递职位的同时，还需要关注职位背后的招聘方是否反馈形成了有效双边连接，进而达到更接近求职链条的预测目的。结合不同时期的业务目标，我们先后经历了几个主要阶段。

第一阶段：以提升点击规模为主要目标，从零到一构建点击率预估模型，开发模型建设的基本框架，包括特征工程、AB 实验框架及线上 CTR 服务。该阶段在较少人员的情况下，建立了排序模型及服务的大体框架，在点击层面支撑业务增长。

第二阶段：业务目标深入，从点击过度到单边连接直至双边连接，在 CTR 预估模型的基础上，增加了 CVR 预估及 ROR 双边连接预估。同时在工具上开展了针对性建设，包括特征生产 Pipeline、AB 实验框架升级为可配置化中心及特征模型的可视化分析监控等，解耦算法和工程依赖，支持更多算法和工程人员的并行高效迭代。

第三阶段：围绕深度学习的算法探索，wide&deep、DeepFM、多任务学习、强化学习等，不断提升算法对高维特征的表达能力，提高预估模型的刻画能力。预计在2020年全面落地业务，达到更为理想的迭代状态。

4.1 连接转化预估模型

58招聘转化预估模型是多目标学习，设计实现如上图，底层共建样本及特征，使用不同算法对 CTR 点击率预估、CVR 单边连接预估、ROR 双边连接预估进行建模，最后对多个模型进行融合支撑线上排序。

整体排序实现是业务常见的方法，总结开展过程中比较关键的点：

样本处理：围绕减少样本噪音，我们开展了多个优化。去除异常用户及异常数据，包括非招聘意图的用户数据、误点击数据；增加真实曝光及停留时长埋点，去除用户下拉信息流过程中非真正看见的数据，将停留时长作为样本置信权重加入到模型训练中；基于求职者维度进行采样，去除对同一职位多次正负样本的矛盾可能。

特征工程：关注及监测特征显隐性的变化，尤其是信息列表展示样式的产品调整，需及时进行特征调整及模型迭代。58招聘业务的特殊性，实时类特征很重要，需要关注特征一致性方面的保障机制，避免发生特征穿越现象或线上线下特征不一致问题。

模型：重视模型认知，并不是简单的关注离线 AUC 或者线上转化率 AB 对比，在特征表达上多些分析，迭代过程中重视前后模型的特征比较，能够有效提高模型实验迭代的有效性。

4.2 特征生产实现

特征 Pipeline 的构建，减少了大量特征工程重复工作，显著提高模型迭代效率。其核心功能是实现配置化的方式，集成了样本采样、特征变换、特征组合、特征离散化，整合后得到训练样本，一方面输送给模型进行训练评估，另一方面也输出到分析平台支持可视化分析。

4.3 模型 serving 实现

线上模型服务有定期更新及大量 AB 实验的要求，随着服务演进构建了当前的模型 Serving 框架，实现了对模型的定期自动更新以及模型的自动加卸载功能，同时也具备了更强的扩展性，可接入不同算法的模型实现。离线部分，样本经过特征 Pipeline 构建增量训练数据，模型训练模块会获取 Base 模型文件初始化并进行增量模型训练，模型评估无异常，系统会将模型存储至模型仓库及 HDFS 文件。线上部分，模型仓库增删改模型后，会发起模型热加载或卸载指令更新至线上服务内存；对于线上的排序请求，实时修改相应使用模型的存储生命周期，对于长期无用的模型，模型仓库将自动删除。

模型 Serving 能够自动化管理线上模型，但我们也不能完全托管系统，依然需要关注模型变化。一方面在离线部分的模型评估环节，除了对 AUC 等评估指标的自动监测，也将模型内存大小、模型特征表达作为监测的一部分；另一方面线上监测业务转化指标的变化，当指标发生较大波动时发出警报，人工进行模型检查。

4.4 重排序机制

由于业务的特殊性，以 CTR 预估、CVR 单边连接预估、ROR 双边连接预估支撑排序仍然存在刻画能力不足的问题，体现在以下几个方面：

招聘关系到个人生计及国家民生，是件极为严肃的事情，内容质量是基础保障。但连接预估模型无法有效刻画质量问题，存在一些职位连接效率很不错但属于问题职位，因此推荐系统需要增加质量相关的因子。

转化率高不等同于双边匹配。线上招聘，无法很好追踪到面试及入职环节，求职者与招聘方形成的双边连接，可能是出于其他原因（如对自己或对方的错误判断）。因此，系统需要考虑匹配方面的控制。

资源浪费问题，对于绝大部分用户，求职及招聘都是周期性行为，一个已经招满人的职位可能依然在线上展示。系统还需要增加职位活跃度或周期方面的刻画，减少相应的资源浪费。

针对这些需要，系统增加了重排序机制，通过分段处理手段，在粗排阶段打压甚至过滤掉低质量内容，在重排序对不活跃/不匹配内容进行降权，达到保障平台质量生态、提高有效连接规模的目的。

列表展示内容控制

内容展示方面，我们也结合算法做了一些工作，来提高内容的可解释性、提供更多有价值的信息来辅助用户决策。结合个性化模型挖掘亮点标签，将更深预估模型的核心特征包装成标签形式展示在列表页，如距离多远、职位的福利标签、职位的热门情况等；使用 NLG 文本生成技术，自动生成简短描述进行展示，弥补标题及其简单职位的文本信息不足。