互联网核心应用（搜索、推荐、广告）算法宝藏书

DataFun：成就百万数据科学家！
关于 DataFun：
DataFun 专注于大数据、人工智能技术应用的分享与交流。发起于 2017 年，在
北京、上海、深圳、杭州等城市举办超过 100+线下和 100+线上沙龙、论坛及
峰会，已邀请近 1000 位专家和学者参与分享。其公众号 DataFunTalk 累计生
产原创文章 400+，百万+阅读，11 万+精准粉丝。
关于宝藏书：
本书来源于 DataFunTalk 发布的原创及作者授权的技术文章，精选搜索、推荐、
广告方向文章各 8 篇，490 页，13 万字，希望对从事本方向的从业者和爱好者
有所帮助~
目录
01. 搜索篇
Query 理解在美团搜索中的应用..................................................................... 6
知乎搜索排序模型的演进................................................................................ 25
京东电商搜索中的语义检索与商品排序....................................................... 42
阿里飞猪搜索技术的应用与创新....................................................................56
5G+智能时代的多模搜索技术........................................................................80
知乎搜索文本相关性与知识蒸馏....................................................................92
京东搜索在线学习探索实践......................................................................... 109
阿里文娱搜索算法实践与思考..................................................................... 121
02. 推荐篇
网易云音乐推荐中的用户行为序列深度建模............................................. 138
推荐系统解构.................................................................................................. 161
推荐系统架构治理..........................................................................................185
阿里粗排技术体系与最新进展..................................................................... 207
阿里深度树匹配召回体系演进..................................................................... 228
多目标排序在快手短视频推荐中的实践..................................................... 246
如何将知识图谱引入推荐系统？................................................................. 267
蜻蜓 FM 信息流推荐探索与实践................................................................. 289
03. 广告篇
算力经济时代：阿里展示广告引擎的"柔性"变形之路.............................. 303
阿里定向广告智能投放技术体系................................................................. 320
同义变换在百度搜索广告中的应用............................................................. 360
CTR 预估在动态样式建模和特征表达学习方面的进展........................... 393
大规模图算法在京东广告的实践................................................................. 416
内容理解在新浪微博广告中的应用............................................................. 436
CSCNN：新一代京东电商广告排序模型................................................... 449
因果推断在阿里飞猪广告算法中的实践..................................................... 471
Query 理解在美团搜索中的应用
分享嘉宾：刘亮美团资深算法工程师
编辑整理：吴雪松
出品社区： DataFunTalk
导读：在过去的 20 年中，搜索过程中处理查询的方式以及向用户显示结果的方
式已完全改变。该过程已经从仅基于文本匹配的检索发展到现阶段——尝试基于
对查询的真实语义理解以及上下文，位置，时间，用户的先前短期和长期浏览活
动来获得搜索结果。本文主要介绍美团搜索场景下，查询理解系统的一些建设和
相关的工作。主要围绕以下几点展开：
 Query 理解简介
 实体识别&实体链接
 查询改写
 意图识别
▌Query 理解简介
1. 美团搜索
在介绍查询 ( Query ) 理解之前，我们先了解下美团搜索，左图是美团 APP 首
页的截图，中间是美团承接的业务，可以看出美团的业务非常多，包括了像外卖、
美食、酒店住宿等大家比较熟悉的业务，也有像婚纱摄影、机票预定等相对低频
业务。顶部的搜索框，是美团搜索的主入口，美团的搜索就是通过这个搜索框来
获取用户的查询 Query，在理解查询 Query 后，对接到所服务的各种各样的业务
品类，最后返回给用户想要的结果。
美团搜索是典型的 O2O 搜索，右图显示了对比传统的网页搜索以及电商搜索的一
些差异。
首先是搜索目标，美团搜索的核心是提供服务，包括团单、套餐等本地生活服务。
另外也会对一些信息和商品提供查询服务，像天气或者医美百科等；另外还有商
品，相对于传统电商，美团主要是本地的一些商品，包括周边的便利店，周边的
商场中的商超类的产品，以及周边能配送的商品的搜索。
另外一个重要的特点是基于位置的相关性比较高，因为 O2O 主要是基于本地生活
的服务形态。供给约束方面，网页搜索基本不用考虑；电商搜索的供给是全国的
商家，购买后全国配送；O2O 场景下，从蜂窝到城市到全国这些维度都有涵盖，
蜂窝是类似外卖这种业务，它的配送范围是很有限的，大概可能 3~5 公里的范围；
像美食到餐团购类，是到店里消费，基本是一个城市维度的；另外像酒店旅游这
种业务，它可能是全国性质的供给，所以说它涵盖的范围会比较广。
以上就是美团搜索的大概介绍。
2. QU
下面介绍下查询理解系统。QU ( Query Understanding )，主要利用基础 NLP
能力，对我们的用户输入的 Query 进行分析，产生一系列的基础信号，然后这些
信号会应用到整个搜索链路的召回、排序等各个阶段。
举个例子来说的话，用户输入：杭州东附近的 7 天酒店，可以通过查询的变换，
纠错和扩展，把杭州东扩展成杭州东站，扩大召回。
在往下是成分识别，这个后面也会重点介绍，包括了实体识别、实体链接，它可
以把 Query 再进行一个成分粒度的识别，把杭州东识别成车站类的地理位置，7
天识别成一个商家品牌，通过实体链接可以将杭州东对应的经纬度返回，7 天链
接到具体的品牌 ID 等。在最后是一些业务应用，包括查询意图的识别方面，我们
还需要把它识别出它具体是本地意图，还是异地意图。
右图是我们目前线上应用的搜索结果，可以看到首先它识别出杭州东这个主点，
并链接到了杭州东站这个实体。在意图方面，由于是在北京的搜索，但是我们需
要找杭州东附近的酒店，所以会有异地的提示，最终的结果是在杭州东站坐标点
一定距离半径内召回 7 天品牌酒店。
3. DQU
上图是查询理解 DQU 项目的架构。
公司有非常多的业务，很多业务也有自己的垂搜系统，在业务快速迭代的阶段是
独立运行的，随着业务的不断发展，如何避免低水平重复建设，更好的积累技术、
经验，平台就成了很有价值的工作。目前 DQU 的项目已经支持了公司内大部分
的搜索场景，包括美团点评大搜，还有度假、住宿等业务频道内搜索。
整个框架分三个部分，最底层是基础信号层，主要是 NLP 相关基础信号模块，可
以提供通用和业务个性化的信号输出。中间是业务逻辑层，适配不同的垂搜业务
逻辑。最上层是适配层，对于不同的业务搜索可能有不同的接口，需要接口适配
再返回最终结果。
接下来重点介绍下几个核心的查询理解模块。
▌实体识别&实体链接
1. 实体识别
① 简介
首先是实体识别，对比于通用网页搜索，电商和 O2O 搜索更多的是结构化的召回。
举个例子，上图中间的“如家上地”，需要把它的商家和地址身份进行识别，然
后对应到我们的 Doc 端，通过不同的字段进行召回。
因为在我们的场景下，Doc 端的数据包含了很多结构化的字段，不同字段之间的
语义差距会非常大，如果我们进行全字段检索，经常会出现一些语义漂移的问题。
比如，搜“肯德基”，可能召回一个理发店，因为它的地址字段有“在肯德基对
面”。所以我们需要结构化召回来保证更高的精度。其中 NER 是指导召回的关键
信号。
② 整体架构
实体识别的整体框架，主要分两个部分：下面的离线端和上面的在线部分。
线上的识别来源主要分两部分，一部分是词典的实体匹配，一部分是模型预测，
然后再往上是消歧策略，实体词典匹配，主要解决一些热门和词库里能够匹配的
词，对一些长尾和泛化的词识别，还是依赖于模型。但是这两个部分中间的结果
可能会有一些冲突，所以需要一个消歧策略，包括多粒度、多结果选择。我们主
要通过一些模板规则，进行优先级的消歧，最终输出一个多路的结果，因为某些
query 会有粒度和类别的歧义。
离线部分主要是两个大的部分：一部分是实体挖掘，这个主要是为线上的实体匹
配提供基础的实体库，模型方面主要是一些基础的模型训练、优化相关的工作。
③ 模型迭代
接下来讲一下 NER 模型迭代相关的一些工作。初期线上的模型主要是 CRF，在
19 年引入了 BERT 模型。这里面主要是两个方面的改进，一方面是训练过程，引
入了美团 UGC 的一些数据，用这些评论相关的数据进行预训练，补充 O2O 场景
下的一些语义信息。再就是 fine-tune 阶段，我们除了人工标注语料的数据集，
还有基于用户行为统计的半自动化生成的一些语料，来扩充训练数据。使模型训
练效果，能够更好的拟合线上的应用。
④ 自动标注训练数据
这里简单介绍下，根据词典扩充训练数据的工作。
对于大规模的模型训练，语料是非常重要的一个部分，但是对于 NLP 任务，一般
来说还是比较难以去自动化的获取这些训练语料，我们的一个核心思路是如何利
用已有的标注数据、词典来指导内容半自动化的生成训练语料。首先用原始的人
工标注语料，训练一个 Model A，然后针对线上已有的实体库去预测打分，对打
分有差异的部分，进行校正，然后把校正后的结果合并原始数据，再训练一个
Model B，最终应用到线上。其中的核心就是校正的过程。
它的前提假设是，实体库和模型的质量，都是比较高的，但是其中模型预测和词
典它中间还是有差异的部分，就是我们的模型预测相对于它可以提供更细的粒度。
比如下面这个例子：“兄弟烧烤个性 diy”，它其实是一个商家的名称，因为有比
较全的美团商家库的信息，所以能够通过词典来挖掘出我们的商家信息。
但是模型预测的话，由于兄弟这个词，有影视类的电影，可能是电影名，模型也
可能会识别错误，所以需要根据词典的信息进行修正。修正的方法是对模型预测
的序列，进行轮巡替换，找出替换概率最高的一个，然后作为替换类型，最终生
成一条校正后的训练数据，和原始数据进行联合训练。
⑤ 数据挖掘
另外一个部分就是离线词库的挖掘。
除了已有的商家库和一些结构化数据以外，线上的用户行为，也是非常重要的，
怎么通过海量的用户行为数据，泛化我们的实体库，是我们的核心工作。这部分
工作主要利用我们线上的用户点击日志，结合召回命中信息，来识别出 Query 的
边界和类型，把用户 Query 中识别出的实体成分进行落库，同步到实体库中。
Query 中的实体边界的切分，主要参考该 Query 召回的多个 Doc 结果的命中信
息。由于我们是结构化召回，所以可能存在多个字段同时命中，通过统计所有 Doc
的命中分布情况，来考虑它的切分方式，最终转化成一个整数线性规划的问题，
来寻求一个切分概率最大的方式，具体可以参考文章《美团搜索中 NER 技术的探
索与实践》。有了这个切分边界后，再对它的每一个成分进行二分类模型识别，
把识别概率比较高的目标成分，进行人工抽检，将符合要求的实体补充到实体库
中。最终，通过这样的循环来扩充我们的实体库。
2. 实体链接
① 背景
下面再介绍一下实体链接的一些相关工作，美团搜索场景下的 LBS 属性，决定了
很多用户都有地址类搜索的习惯，所以地址识别也是我们的一个重点。实体识别
把地址成分识别出来之后，后面很重要的工作是把它的经纬度坐标找到，通过半
径距离召回，满足用户搜索某个地址周边结果的诉求。这就需要实体链接把用户
Query 中的文本链接到具体的实体，并返回实体的属性。另外实体链接模块，本
身还可以修正 NER 的结果。
② 整体框架
上图是实体链接的整体框架，它主要分为两个部分：
离线的部分，其核心是对所有物理实体 mention 的挖掘，其实就是实体的一个别
名，用来扩大实体链接召回。
线上部分，首先通过别名进行实体召回，然后对召回的实体进行消歧排序。消歧
主要结合 Query 文本序列的特征、基于地理位置的特征（比如城市和 GeoHash），
还有上下文的一些文本信息进行消歧排序，返回给用户最相关的 Top 实体。
③ 核心算法
核心算法如上图。离线部分，刚才也提到了主要是 Mention 的挖掘，目前基础数
据，主要是商家库的数据、搜索日志、UGC 评论、知识图谱等。Mention 挖掘目
前主要有三种方式：
 抽取式：对已有的核心实体库进行核心词的一个识别，然后再通过核心词
的组合，来泛化出标准实体的一些别名
 挖掘式：主要是通过用户评论和搜索的点击 session 日志，通过用户行为
挖掘用户对于实体的一些别名输入
 生成式：主要是通过 Seq2Seq 的一些模型，自动化的去生产一些泛化实
体的别名
右下角是一些例子，比如说标准的别名，凯德茂望京，能够挖掘出它的一些相关
的子成分（凯德 mall）。
在线消歧部分，主要是一些相关性的计算和消歧排序，不再展开了。
▌查询改写
1. 背景
为什么需要查询改写？主要因为自然语言表达的多样性，首先是 Query 和 Doc
之间表达的差异，用户的 Query 会相对随意，而 Doc 端相对正规，商家和运营
录入的商家介绍等相关字段，会标准化一些。另外一个问题就是一义多词，通常
一个含义的表达会有非常多种输入的方式。
右图是线上真实的搜索日志，是“理发”相关的搜索词。可以看到有非常多的变
换形式。还有一词多义的问题，比如：结婚照，它可能包含两类的含义，一类是
要找婚纱照，另外还有可能是去拍结婚证需要的证件照，如果我们不进行 Query
查询的改写，直接通过原词文本匹配，很可能会漏召回。
2. 技术演进
查询改写这块，技术演进主要分 4 个阶段，最初是基于词典规则，它的优点是精
度高，但是召回率非常低。后面加入了基于用户行为统计挖掘的相关扩召回的方
式，但由于是基于整串的匹配，召回虽然有一定提升，还是没法满足线上用户很
多长尾 Query 的搜索。
为了解决长尾问题，引入了基于翻译模型的统计翻译改写，主要是通过用户行为
日志，训练翻译模型和语言模型，从子串片段级别来解决覆盖问题，极大的提升
了改写的召回。但它的问题是会比较容易产生语义的漂移，因为它主要是基于文
本对齐和文本替换的统计概率，并未考虑语义信息。所以我们又引入了基于 Bert
的语义规范化，进行过滤，很大程度的缓解了语义漂移的问题。
3. 为什么选择 SMT
接下来重点介绍一下我们线上的翻译改写模型。
为什么要选择这样一个翻译模型呢？首先翻译所需的平行语料，在搜索场景下，
比较容易通过搜索日志的 Session 来构造，甚至还可以用 Query-Doc 的点击数
据来补充，通过这样的平行语料，就能够自动化的获取海量的标注数据，覆盖足
够多的语言现象，解决表达多样的问题。
另外翻译模型很重要一个特点，是它能够支持子串级别的替换，并充分考虑上下
文。所以说它能够很好的进行召回泛化。
4. SMT 改写过程
这是 SMT 改写的一个大致的过程。它主要分为三个部分：
最上面是句对挖掘，通过海量的用户行为，包括 Session 、 Query-Title 、
Query-Doc-Query 数据，对这些数据进行特征抽取，然后再结合句对的判别模
型，生成片段级别的对齐语料。
第二部分翻译模型训练，它的输入是上一步生成的对齐语料，然后生成 N-gram
的片段，再结合语义计算和统计规则，去生产翻译模型和语言模型。它主要是通
过 N-Gram 这种方式进行子串级别的泛化。
第三部分是线上的解码和终判，主要考虑性能问题。因为线上替换时，子串候选
解码如果不加限制，会产生组合爆炸的问题。所以结合了 BeamSearch 以及业务
相关的过滤器，例如利用 NER 和实体链接的信息，对商家实体词限制改写，通过
这样的一些业务特征来保证精度。通过路径裁减，返回概率最高的 Top-K 的结果，
进行改写路径的生成。
▌意图识别
1. 背景
目前我们意图模块的核心是识别用户的业务需求，因为我们涵盖的业务品类非常
多，不同的业务，展示模板和展示样式也都不同，比如酒店的查询，可能会有用
户的入离时间展示模板。所以需要把不同的业务需求识别出来，进行多形态的召
回。
上面是我们意图的划分，包括左边的业务意图，例如美食、酒店、旅游等等，会
直接访问业务相关索引进行召回。中间是阿拉丁（开放平台），主要获取一些活
动、第三方结果。最右边还会有一些基于知识内容的信息类召回，比如根据评论
内容召回结果。最下面是对应的一些场景，比如时间、空间、人和事件的场景。
2. 整体框架
意图识别的整体框架，主要分为两个部分：
意图召回。这块是转换为了分类任务，只判断某个查询是否包含某种意图。线上
采用词典匹配+规则+模型的方式进行识别，词典主要包含业务和领域相关数据，
词典和 Pattern 规则，能比较好的解决热门识别，针对长尾部分，主要靠 Bert 模
型来解决泛化识别问题。
意图分布。意图召回完了以后，我们还要知道当前搜索的各个意图的强弱，尤其
是找到主意图，就是图上面部分的意图分布，我们将其转化成排序问题。由于线
上展示的每条 POI 结果，后台都有明确的业务归属，所以我们就可以依据这个业
务归属信息和用户点击行为，获得有标注的训练语料，来训练排序模型。模型特
征主要分为两部分，一是统计类的特征，包括一些 CTR、CVR 及相关的用户行为
的特征。二是 Embedding 类特征，来进行语义的表达。
▌总结和展望
最后总结下，本文主要介绍了美团查询理解系统中的主要模块，包括实体识别、
查询改写、意图识别。查询理解是搜索引擎与 NLP 结合的产物，用来解决搜索相
关的一些文本理解任务。除了文本本身，后续我们还会考虑引入更多包括时空、
用户，场景的信息来做到更深入的理解搜索场景下的用户查询意图。
今天的分享就到这里，谢谢大家。
知乎搜索排序模型的演进
分享嘉宾：王瑞欣知乎算法工程师
编辑整理：郭真继
出品平台： DataFunTalk
导读：搜索，是用户获取信息，找答案最方便快捷的方式。一次用户搜索会经历
Query 解析、召回、排序多个环节，排序作为最后整个过程一环，对用户的体验
有最直接的影响。今天分享的内容是知乎搜索排序模型的演进。
主要内容包括：
 知乎搜索发展历程
 排序算法的迭代升级
 一些未上线的尝试
 未来方向
01
知乎搜索发展历程
1. 知乎搜索
知乎作为一个大型的中文问答社区，有超过四千万的提问和超过两亿条回答，其
中蕴含了丰富的知识、经验和见解，知乎搜索是帮助用户快速获取信息，找到答
案的重要途径，随着媒介的升级，搜索结果的形式也不在局限于图文，视频解答
也越来越多。
2. 知乎搜索算法发展历程
知乎的搜索算法团队成立于 2017 年底，于 2018 年 8 月上线了深度语义匹配模
型。在 2019 年 4 月引入了 BERT 模型，同年 8 月排序模型由 GBDT 升级为
DNN 模型，随后在 DNN 模型的基础上进行了一系列的迭代升级。

3. 知乎搜索架构
一次搜索流程主要包括 Query 解析、召回、排序几个阶段。用户输入 Query 之
后，首先要进行 Query 解析，生成查询 Query Tree 和语义表示向量。之后进
入多队列的召回模块，召回阶段从召回方式上说可以分为倒排召回和向量召回，
在这一环节会筛选出前 400 的文档进入到排序阶段。排序阶段又分为精排和重排
序两个环节，精排阶段通过模型对多召回源的文档进行统一打分，之后将 Top16
的文档送入重排序模型进行位置的微调，最终呈现给用户。本次主要分享精排和
重排序阶段两部分的模型演进。
02
排序算法的迭代升级
1. 由 GBDT 模型升级到 DNN 模型
2019 年 8 月份我们将排序模型由 GBDT 升级到 DNN 模型，这么做主要是考虑
到两点：
 数据量变大之后，DNN 能够实现更复杂的模型，而 GBDT 的模型容量比
较有限。
 新的研究成果都是基于深度学习的研究，采用深度神经网络之后可以更好
的应用新的研究成果，比如后面介绍的多目标排序。
升级到 DNN 模型之后，线上效果有一定的提高。

2. DNN 排序模型结构
我们的 DNN 排序模型整体是在谷歌开源的 TF-Ranking[1] 框架的基础上开发
的，TF-Ranking 使用了 Estimator API，提供了排序任务常见的损失函数和指
标计算实现，比如 Pairwise Loss 和 NDCG 指标，以及通过 Multi-head 支持
了多目标训练。整体的代码结构根据训练流程可以拆分成特征输入、特征转化、
模型打分和损失计算等几个独立的模块。清晰合理的模块划分为后续的快速迭代
提供了很大的方便和灵活性。下面简单介绍下各个模块：
 特征输入模块，将 Query 特征、相关性特征、文档质量特征和历史点击特
征等输入模型。
 特征转化模块，做一些常见的特征处理工作，比如取 log、归一化、onehot
和类别特征转 Embeding 等。
 模型主体结构部分包括主网络部分、 End2End 部分，SeRank[5] 部分，
Unbias tower 部分和 MOE 方式实现的多目标排序部分，后面会做详细
介绍。
3. 多目标排序
搜索排序任务的学习目标首先能想到的就是预测用户点击，我们最初的排序模型
也是这样做的。但是用户点击只是第一步，单纯的点击行为并不能代表用户对搜
索结果的满意，我们需要同时考虑用户在点击之后的一系列行为，比如阅读时长、
点赞、收藏、关注、分享、评论等等。这些行为都可以作为排序任务的训练目标，
由于可选的目标比较多，我们通过分析这些指标与用户留存的关系进行了筛选，
与点击率一起构成了排序模型的目标，开启了我们在多目标排序方面的探索。
① 基于 hard sharing 的第一版多目标排序模型
第一版的多目标排序采用的是共享参数层+任务独立参数层的结构。共同学习的多
个目标是有内在联系的，对一个目标的训练会帮助到其他目标，通过共享底层参
数可以实现这个目的。在共享参数层之上又加了任务独立的参数层，使各个训练
任务之间可以独立更新参数，保证互不影响。需要注意的是，不同目标的训练数
据是不一样的，转化类的目标比如阅读时长、点赞、收藏，这些要用户点击之后
才能发生，所以只在有点击的数据上计算 Loss。另外由于阅读时长呈长尾分布，
需要用对数时长作为训练目标。在多目标模型中每个目标都会对应一个模型打分，
在线上预测是需要多多个分数进行加权融合。至于不同的目标对应的具体权重我
们是通过 AB 实验确定的。
② 基于 MMOE 的第二版多目标排序
在去年年初的时候，我们采用 MMOE[2] 结构对多目标排序模型进行了升级。与
hard sharing 结构不同， MMOE 引入了 Expert，将共享参数层替换为多个
Experts 加权相加的方式，这些参数既是各个任务共享的，又通过独立权重的方
式给了各个任务一定的独立性。这一版的更新在上线之后也是取得了一定的收益。
4. Unbias LTR
在使用用户点击日志作为训练数据时，点击日志中的一些噪声会对训练带来一定
的负面影响。其中最常见的噪声就是 Position bias，由于用户的浏览行为是从上
到下的，所以同样的内容出现的位置越靠前越容易获得点击。以用户搜索小儿感
冒为例，比如同时给用户展示了五条结果，用户在点击第一条之后获得了满足退
出了这次搜索，这时就会生成一条训练数据，第一条作为正样本，其他的作为负
样本，但是其实后面几条结果质量也比较好，如果后面的结果出现在第一条的位
置也会发生点击，所以点击是受到位置影响的。在这种情况下训练数据是有偏的。
对于这个问题，有两种解决思路：
① 降低 Top 位置的样本权重
既然 Top 位置更容易受到位置偏差的影响，那么我们就降低头部样本的权重。
至于样本权重的确定，我们尝试过两种方案：
 根据点击模型预估每个位置的权重，预估出来的结果可能是第一位 0.7 然
后一直增加，到第五位是 0.9
 通过模型在训练的过程中自动学习权重
但是这两种方案上线之后都没有正向效果。
② 对 Position bias 建模
用户实际点击 = 真实点击率+ Position Bias
另一种思路就是考虑 Position Bias 的情况下，重新对用户点击进行建模。既然
用户点击是由文档的真实点击率和文档的展示位置共同决定的，那就将这两部分
分开预测，用文档的展示位置作为特征通过一个独立的 shallow tower 对
Position Bias 进行建模[3]，将其他的 Query 和 Doc 本身的特征输入主模型
结构建模文档的真实点击率，将两部分分数相加来预测用户点击。在线预测时，
只需考虑真实点击率的部分。另外在训练的时候有两点需要注意，一个是最好在
shallow tower 的部分加一些 dropout 防止模型对 Position Bias 的过度依
赖，另一个是只有点击目标会受到位置偏差的影响，所以只需要在点击目标上应
用这个策略，在转化类目标上则无需这种处理。这一版的策略上线对点击比带来
了显著的提升。
5. Context Aware LTR
对于排序任务可以有几种理解：
 Point wise：确定每个文档独立打分，最终根据分数排序
 Pair wise：确定两两文档对的相对顺序，推导出最终排序
 List wise：直接优化待排序的文档的整体顺序
三种不同的方式都有对应损失函数，实践证明，对排序任务而言 List wise loss
优于 Pair wise loss 优于 Point wise loss。
从特征角度我们也可以通过构造一些 context 特征来实现 List wise，比如对待
排序文档的特征取平均值或者中位数作为模型排序特征，实现起来比较简单，当
然也是有效的。
常规的模型对不同文档的打分是相互独立的，我们希望可以实现一个模型在对单
条文档打分时，同时可以考虑到其他的文档。在实践中我们借鉴了 CV 中的 SE
Block[4] 结构，具体到排序的场景就是：以全连接层输出 X 作为 SE Block 的

输入，全连接层的输出维度是 L*C（L 代表 list size，C 代表特征维度），然后
先在 List 维度上做 Pooling，然后经过两层的全连接层之后将输出做 Sigmoid 转
换，映射到 0 到 1 之间，再跟乘回 X。通过 List wise 的 Pooling 操作就可以把
一整个 list 信息融合到每个样本的打分里面，实现 List wise 打分。每一层全连
接层后都可以接一个 SE Block 结构。在训练时有一个需要注意的点是，由于训
练日志只是有展现的一小部分文档，但是在精排线上打分时候选集是比较大的，
所以存在线上线下不一致的问题，而这种不一致对于 SE Block 的计算影响很
大。为了解决这种的不一致的问题，我们在精排之后加了一个重排序阶段，把精
排 Top16 的结果送到重排序模型中。保证 Top16 文档可以完整的加入到训练数
据中，在离线训练时只有重排序模型应用 SE Block 结构，这样就保证了线上线
下的一致性。这一版的策略更新对于头部位置的点击比提升比较明显。
Se Block 结构之所以能发挥作用，本质上是因为在单条样本打分过程中融合了所
有候选集的信息。另外有一种可能的解释是 SE Block 结构实现了某种注意力机

制，输出的 0 - 1 的打分可以看做是某个特征在当前 Query context 下的特征
重要性，而同一个特征在不同 Query 下的特征重要性是一样的，所以通过这种
结构模型可能可以学到这样的信息，来帮助模型更好的打分。
6. End2End 学习
之前我们的排序模型并没有直接使用 Query 和文档的原文作为排序特征，而是
将其输入相关性模型将计算得到的相关分数做为上层排序模型的特征，所以我们
进行了一些 End2End 学习的尝试。
由于我们是使用 BERT 模型计算文本相关性，所以我们尝试了将 BERT 也加入
到 LTR 的模型中进行训练。由于 BERT 的计算量过大，我们实际只加载的前三
层的 Transformer。但是训练时长依然过长，且离线指标无提升。之后我们进行
了第二次尝试，只是将 BERT 编码之后的 Query 和标题的 Embedding 向量
加入到 LTR 模型中，在其上加入 Dense 层进行微调，这种方式最终获得了一
定的线上收益。
7. 个性化 LTR
用户在发生点击行为之前，可能已经产生了很多的行为，比如有过搜索，或者点
击过首页推荐的内容，这些交互行为都可以提供一些用户额外的信息用于排序。
我们将用户近 30min 的搜索 Query 和点击的文档标题用 BERT 模型生成句
向量输入到模型里，跟当前 Query 的 Embedding 做内积，计算最大匹配分数
作为特征，这样操作虽然比较简单，但是拿到了很好的线上收益。除此之外我们
还尝试了一些更为复杂特征交互结构，但是上线之后发现效果都不如这个简单的
策略好。
03
一些未上线的尝试
1. GBDT 特征编码模型
这个思路是 Facebook 提出的[6]，首先用点击数据训练一个 GBDT 模型，利用
模型进行特征分桶和特征组合，将 GBDT 输出的叶子节点编号作为排序模型的特
征，但是这个方案没有线上收益。
2. IRGAN，生成对抗网络模型
利用生成对抗网络训练排序任务[7]，具体实现：实现一个生成网络一个判别网络，
把展示未点击的样本喂给生成器，采样出疑似的正样本（作为判别器的负样本）
和用户真实点击的样本一起喂给判别器。判别器的错误率作为生成器的 reward。
核心思想是希望通过生成器生成的难负样本提高判别器的分类性能。但是实际训
练时发现在一定步数之后模型会训练发散，并不能达到比较好的性能。
04
未来方向
1. Online learning
我们之前发现模型在上线一段时间后指标有逐渐下降的趋势，之后尝试了模型日
更，结果表明日更模型表现较好。提高模型更新频率可以让模型更快的适应新的
数据分布，如果可以实时更新模型预计效果会进一步提高。
2. Graph embedding
用户的搜索 Query 和点击的文档可以构建一个图，用图挖掘的算法有可能从其
中挖掘出更多的信息，提高排序模型的性能。
3. 个性化
我们目前关于个性化的尝试只是通过用户的近期交互行为挖掘了一些用户的短期
兴趣，利用用户的长期兴趣画像，可以在 Query 意图宽泛时对结果做一些个性
化的排序，更好的满足用户的个性化需求。
4. 边缘计算
与云计算方式不同，边缘计算可以利用用户更细粒度的交互信息，通过端上计算
即时的对排序结果进行调整，进一步提升排序质量，是一个非常有潜力的发展方
向。
参考资料：
1.https://github.com/tensorflow/ranking2.Ma, Jiaqi, et al. "Modeling task relationships in

multi-task learning with multi-gate mixture-of-experts." Proceedings of the 24th ACM
SIGKDD International Conference on Knowledge Discovery & Data Mining. 2018.3.Zhao,
Zhe, et al. "Recommending what video to watch next: a multitask ranking
system." Proceedings of the 13th ACM Conference on Recommender Systems. 2019.4.Hu,
Jie, Li Shen, and Gang Sun. "Squeeze-and-excitation networks." Proceedings of the IEEE
conference on computer vision and pattern recognition. 2018.5.Wang, RuiXing, et al.
"SERank: Optimize Sequencewise Learning to Rank Using Squeeze-and-Excitation
Network." arXiv preprint arXiv:2006.04084 (2020).6.He, Xinran, et al. "Practical lessons
from predicting clicks on ads at facebook." Proceedings of the Eighth International
Workshop on Data Mining for Online Advertising. 2014.7.Wang, Jun, et al. "Irgan: A
minimax game for unifying generative and discriminative information retrieval
models." Proceedings of the 40th International ACM SIGIR conference on Research and
Development in Information Retrieval. 2017.
京东电商搜索中的语义检索与商品排序
文章作者：王松林、唐国瑜京东算法工程师
编辑整理：Hoh
出品平台：DataFunTalk
导读：本文将介绍京东搜索场景中的两块技术，语义检索与商品排序。在业界
检索算法基础上，我们提出一系列更适用于电商场景的检索排序算法，在业务
上取得了显著收益。其中的多篇论文已被 KDD/SIGIR 等收录。
01
背景介绍
电子商务搜索是京东等电商重要组成部分，用户通过搜索找到自己需要的商品，然
后下单购买。一个典型电商搜索引擎的架构，包括三个重要组成部分：query 理解、
召回和排序。
 Query 理解：包括 query 的纠错、改写、扩展、分词等。
 召回阶段：给定一个查询词，从商品库中召回有效正确的商品候选集，并将
结果返回给排序。召回方式有很多种，这里我们只介绍基于向量检索的召回。
 排序阶段：给定召回商品的候选集合，根据众多因子对这些商品进行排序，
挑选出最好的候选商品展示给用户。
下面我们分别介绍，基于向量检索召回和商品排序：
02
向量召回
向量检索作为一种信息检索方式在工业界已经被广泛应用，它能解决传统倒排检索
不能解决的问题。倒排通过字面匹配方式召回商品，这种方式存在一种缺陷，不能
召回字面不匹配但语义层面相近的商品，如 query='2-3 周岁宝宝玩具'是无法召
回 sku='托马斯小火车'的。
通俗的讲就是训练一个模型，该模型通过将 query 和 sku 映射到统一维度空间，
在该空间中，相似的商品距离近，不相近的商品距离较远。如上图例子，query=奶
粉，在高纬空间里，相对鞋子、服装、手机，奶粉商品距离 query 更近。这是建
模过程，生成 query 和 sku 的向量数据。我们得到了 query 和 sku 的向量，
接下来就是做检索，返回与 query 距离近的 topK 个 sku。而数据库的商品量非
常多，通常是十亿级，不可能做线性遍历，考虑到时效性，会引入快速向量近似检
索方法，如 KDTree、TDM、LSH、PQ、HNSW 等等，我们采用的是 PQ 算法，
这里不再赘述，网上有很多材料介绍其算法。下面重点介绍我们的模型及在线检索
框架。模型方面不仅要考虑 query-sku 的相关性，我们也对用户行为进行建模，
同一 query 针对不同用户、同一用户不同时刻检索出更具有个性化的商品。我们
使用的是 DPSR ( Deep Personalized and Semantic Retrieval ) 算法，模型融
合个性化和搜索语义信息，我们的论文已被 SIGIR2020 收录。
1. 检索系统 overview
从整体看，离线模型是一个双塔模型结构，query 和 sku 分别有一个 model
tower。Query 端包括了 query 包括 query tokens、user profile、user history
events 等特征。Sku 端包括 title tokens、brand、category、shopid 等特征。
离线索引 ( offline indexing )，使用的是 sku tower，导出 sku 的 embedding 构
建 QP 索引。在线服务 ( online serving ) 使用的是 query tower，模型加载在
tensorflow service，在线 predict query 的 embedding。
2. 模型详细设计
① Two tower model architecture
上面介绍了模型结构，一个 query tower Q，一个 sku tower S，对于给定的
query=q， sku=s，模型计算过程为：f(q,s)=G(Q(q),S(s))Q(q)∈Rd×m 表示 query
的 embeddingS(s)∈Rd×m 表示 sku 的 embeddingG 表示打分计算函数，比如
inner product、L2 distance 等双塔模型训练完后，query 和 sku 的模型相对独
立，我们可以分别计算他们。所有的 sku embedding 都在离线计算，以便快速构
建向量检索索引。虽然 model 是相互独立的，但 query 和 sku 之间使用简单的

点积计算，理论上 query 和 sku embedding 仍然在同一个几何空间中，具有可
比性。
② Query tower with multi heads
我们看到左侧的 tower 和右侧有两点不一样：Projection layer 和 mutli heads，
目的是为了丰富 query 侧的信息。如下图所示，不同的 head 可以捕获 query 不
同的语义 ( query=苹果，语义可以是手机和水果 )，捕获不同的品牌属性 ( query=
手机，品牌可以是华为、小米 )，捕获不同的产品属性 ( query=三星，产品属性可
以是笔记本、手机 ) 等等。
③ Attention Loss
Multi heads 让 query 可以生成多个 embedding 与 sku embedding 计算
score。我们采用 attenion loss 做模型优化。我们标记 query 的多个 embeding
为 Q(q)={e1,e2,...,em}，其中 ei∈Rd，Sku 的 embedding 为 S(s)=g，g∈Rd，
Query 和 sku 的打分计算如下：

其中 β 是 softmax heat 参数。假设 D 表示训练预料，r(qi,si+) 为正样本，r(qi,si-)
为负样本，模型优化的 loss 可表示为：
④ Negative Sampling
我们采用的是用户点击数据，数据量在 10 亿级作为正样本。负样本并未使用同
session 未点击的样本，因为搜索手机，展示了小米和华为手机，不能说未点击就
是不相关商品。负例分为两部分：random negatives、batch negatives。我们增
加了一组超参来调整两者的比例，观察发现 random negatives 越多，召回商品的
popularity 越高，更能吸引用户点击下单，但会降低商品与检索 query 的相关性。

模型训练算法具体如下：
3. 训练优化
我们也尝试过更强大的神经网络，如 RNN、transform 等，得到的效果类似或稍
好一些。然而一个短延时的模型更适用于工业生产建模，这样可以使用更少的服务
器做有效的离线训练和在线服务。模型系统方面，我们也做了一系列训练优化，简
单描述其中的几点：
 实现 c++ tokenizer，以 custom operator 方式加载到 tensorflow，离线
训练和在线服务共用，保证 token 的一致性。
 训练数据压缩，修改训练数据格式，把共用的特征数据加载内存，训练时展
开从而降低数据存储。也便于训练时做负例采样。
 可伸缩分布式，切分大的 embedding，并将 sum up 放到 ps 以解决
worker/ps 带宽瓶颈。
 模型 servable 服务，我们将向量检索和 tfs 合成一个服务，不仅减少一次
网络访问，降低系统 3-5ms 的平响，而且将模型分片部署，从而可以支持
上百个模型同时服务或者 A/B 实验。同时 servable 服务是 cpu 和 gpu
混合部署。
4. 语义检索效果展示
语义检索上线后获得了很好的体验效果，不仅提升了转化，长尾流量降低了近
10%的 query 改写率，也就是说用户不需要多次改写 query，就能获得想要
的商品结果。
03
商品排序
下面介绍下商品排序：商品排序主要是根据用户的输入对商品进行打分排序。商品
排序的传统方法使用 xgboost 等基于决策树的方法从数据中进行学习，但是这些
模型通常有成百乃至上千的数值型人工特征，不能有效的从原始特征比如用户历史
点击购买数据、商品文本和图像中直接学习。近年来，深度学习在各种应用中验证
了从原始特征中学习的有效性，在业界被广泛使用，比如 wide&Deep、DIN 等。
下面介绍一个我们在商品搜索排序中尝试的方法。
1. 双胞胎网络
我们的训练数据来自于用户的搜索日志，通过将同一个 session 中用户购买的商品
( 商品 a ) 和没有购买的商品 ( 商品 b ) 配对起来，并把购买未购买作为最终学习
的 label，从而构造了用户查询-商品对训练集。根据训练数据，我们首先设计了双
胞胎网络结构：
双胞胎网络结构有两个共享参数的模块，每个模块分别输入用户、查询和商品特征，
每个模块采用 ReLU 作为激活函数，最终层的输出一个分数，两个模块的差值和数

据 label 作为交叉熵损失函数的输入。在特征方面，我们使用以下几种不同类型的
特征：
 数值型特征：包括商品销量、用户购买力和用户是否点过、购买过商品等。
 文本特征：包括用户输入的查询和商品名称等。
 用户历史行为：包括历史点击、购买、加购商品 list 等
 商品、用户 id 等
文本特征可以学习到一定的相关性信息，用户历史行为可以学习到个性化信息，id
类特征我们做了 pretrain。
2. 个性化升级
在第一版双胞胎模型中，我们简单的对用户的历史行为做 sum pooling，但是这样
缺乏和搜索商品的交互，无法精准的表示用户的兴趣；为了加强用户的交互，我们
升级了模型的结构，用候选商品和用户历史商品做 attention，从而将静态的 user
embedding 升级为随 query 和当前商品变化的 user embedding。我们还加入
了 Graph 学习方法对 id 类特征 embedding 进行 pretrain，然后加入到模型训
练中。具体方法使用用户的高质量点击行为生成商品 graph，通过 Random Walk
生成训练数据，然后利用 Skip-gram 进行训练，加入 id embedding 可以提高模

型离线指标和收敛速度。
3. 时效性优化
值得一提的是，为了增强排序捕捉变化的能力，提升排序的流动性，我们从三个方
面：特征时效性、模型时效性、线上预估校准进行了优化。
 提升特征时效性：接入商品小时级的点击加购订单等实时信号，训练模型学
习实时变化
 实时在线校准：根据商品全站的点击订单等实时反馈信号，对模型原来的预
测分数及时校准
 提升模型的更新频率：优化训练数据生产流程，推动训练平台升级，提升模
型训练速度
搜索排序是商品检索最重要的模块之一，我们在个性化、时效性、多目标等方向不
断迭代，提升了排序体验，也提升了商品成交量。
04
总结
我们介绍了语义检索召回和商品排序，在京东搜索服务上部署并取得了良好效果。
我们还在尝试一些业内其他流行的方法，比如 GNN、KG、MMoE 等方向，也获
得了不错的成绩。
文章作者：王松林、唐国瑜，京东算法工程师。
阿里飞猪搜索技术的应用与创新
分享嘉宾：林睿阿里飞猪
编辑整理：杜正海、 Hoh
导读：旅行场景的搜索起初是为了满足用户某种特定的强需求而出现的，如机票、
火车票、酒店等搜索。这些需求有着各自不同的特点，传统的旅行搜索往往会对
不同业务进行定制化搜索策略。随着人工智能技术的不断发展，用户对产品的易
用性提出了更高的要求。旅行场景的搜索逐渐发展为一个拥有旅行定制搜索策略
的全文检索引擎。本文将为大家介绍阿里飞猪在旅行场景下搜索技术的应用与创
新，主要内容包括：
 猪搜背景
 基础建设
 召回策略
 思考总结
01
猪搜背景
1. 飞猪搜索
飞猪搜索业务分为两大部分：一是全局搜索，二是行业小搜。右边飞猪界面的全
局搜索就是最上方的输入框。直接对应飞猪内部所有内容的搜索入口，都可以从
全局搜索获得。右图中间部分就是产业小搜的垂直入口。比如搜索酒店机票和旅
游度假产品，一般用户会使用行业小搜，垂直搜索需求。随着飞猪业务的发展，
以及用户需求的变化，流量会从行业小搜逐渐迁移到飞猪的全局搜索上。主要是
因为：
 旅游行业是一个跨类目的需求。用户天然的需要定机票、酒店以及一些网
络的门票，如果全部通过垂直搜索，需要进行多次点击，对用户来说不是
很方便。
 飞猪很多流量是由手淘引流过来的，手淘是一个全局的搜索。所以用户会
习惯性的使用全局搜索来满足他的需求。
 对用户来说，用全局搜索的操作是最方便的，路径最短。
2. 猪搜框架
猪搜框架如图所示，首先通过调用 QP 来获得当前的 Query 理解，以及需要召回
的 Query 生成，然后通过 SP 分页服务调用 HA3 倒排索引来获取召回的结果。通
过粗排序和加权排序将结果通过 LTP 服务做重排序，最后将得到的结果展示给用
户。这里主要介绍下 QP 的工作。
3. QP
QP 即 Query 理解与召回生成服务。在这个服务中，我们面临的挑战主要有：
 性能限制：在业界，通常 QP 阶段只占用整个线上响应时间的 1/10。所以，
对性能要求比较高，响应时间不能过长，需要提供良好的线上服务体验。
 文本理解：我们的 QP 和其他的全局搜索 QP 一样，也需要做传统的文本
理解，提供文本相关性的能力。
 独有挑战：在旅行场景下，会有一些特殊的要求。比如 LBS 与 POI 的理解
能力，能够提供空间上的相关性。
 特征理解：从业务发展角度，我们还需要用户特征的理解，可以提供个性
化的相关性，来满足用户的需求。
02
基础建设
接下来，为大家介绍下飞猪在具体基础建设上的一些工作。
1. Query tagging
Tagging 是 QP 中的一个基础任务。负责的功能是把一个 query 打出目的地和意
图。举个例子，“北京自由行”中“北京”就是用户的目的地，“自由行”是用
户的意图需求，可以看出用户希望的是一个自由行的商品，而不是跟团游这类的
产品，可能会更希望获得一些机票+酒店或者是无购物的产品。
这里的工作，主要分为以下几层：
 数据层：通过离线挖掘出 tagging 词库。
 算法层：通过 Tag 消歧、CRF 等算法进行在线打标工作。
 应用层：在 tagging 上的一些应用，如 query 丢词和 query 改写。
由于线上性能的限制，我们主要依赖于离线的挖掘。这里以我们内部比较重要的
商品 POI 挖掘为例，来介绍下我们离线挖掘 tagging 的工作。
2. 商品 POI 挖掘
① QueryTagging
POI 的挖掘除了商品 title 可能会有一些景点信息外，详情也会包含大量的信息。
因此，我们需要从这些内容中挖掘出有价值的信息，来扩充词表。例如图中的景
点 POI，可以用作索引参与召回，但是详情是非结构化的 HTML 文本，要挖掘 POI
实体，会有比较大的难度。
② 建模方式
我们采用了典型的序列标注问题来解决这个问题。我们通过一些特征，如词特征、
数字特征、类目特征，进行筛选，通过人工标注来训练我们的 CRF++模型。后续
我们还升级成了 Template 下的模型来训练 NER 模型，使我们可以在离线，对接
了大量的文本数据，进行序列标注。最终，我们达到了 99%以上的准确率，召回
率也超过 95%。扩充了大量的没有挖掘出 POI 商品/POI 特征的度假商品，使它
们产生了 POI 的特征，可以更好地为后续的 POI 及检索做出服务。
3. 同义词挖掘
在旅行行业，存在四种类型的同义词：
 翻译类：如“迪斯尼”，可能有不同的中文描述方式
 中英文词：有的用户用英文来描述，而有的用户用中文来表述，但是商家
描述的 title 是英文
 包含关系：比如“普吉”和“普吉岛”，可能“普吉”这个 POI 是“普吉
岛”这个大 POI 下的子 POI

 错别字：比如“国色天香”，在图中应该是“国色天乡”
我们希望可以用一个通用的模型来解决这种同义词关系。
我们的办法是基于用户点击行为，拼接 query 和商品 title，使得 query 和 title 中
的词形成上下文，然后基于 word2vec 的 skip-gram 模型，得到每个词的词向量，
并基于语义相似性，产生每个词 top 20 的候选，同时将问题转换为二分类问题。
另外，在特征工程上，我们会利用中英文的编辑距离、共现数目以及是否包含关
系、余弦相似度等来构建特征。
然后，我们通过人工标注来构建正样本，负样本按照编辑距离倒排随机采样，使
用 LR 模型和 XGBoost 对标注好的样本进行二分类。
最后，我们还会经过一层人工审核，因为同义词的影响面积比较大，如果直接通
过算法挖掘，在线上的效果可能不会特别好。所以我们没有采用复杂的模型，只
是够用就可以了。这样在万级别的人工标注上，我们的准确率可以达到 94%。
4. 纠错
① 背景
对于纠错，刚才提到了词级别的错误，事实上，整个 Query 中也会出现一些错误。
只用词级别的纠错，不能满足用户需求，需要一个全 query 纠错逻辑。
由于 QP 阶段对性能要求很高，现在业界常用的 seq2seq 方法，虽然效果很好，
但整体性能不达标。我们可以在离线利用 seq2seq 来挖掘高频的信息，但在线上
很难应用 seq2seq 的方法来做纠错。
② 方案
我们的方案是采用传统的隐马尔科夫模型，基于统计的方式来做，能够达到线上
的性能要求。将错误分为同音字与形近字，可以获得比较强的可解释性。
 同音字：因为汉字都可以查到拼音码表，我们可以很容易的构建一个同音
字的集合，然后通过一些统计的方式，就能获得同音词生成概率。
 形近字：比较难获得，因为很难判断两个字是否有些相似。我们这里，通
过字体图像和字体结构来解决的。
③ 基于图像
说到基于图像的方式，最直接的方式就是基于 CNN 图像网络的匹配算法。但是
出于性能方面的考虑，这种方法的效果往往达不到我们的性能要求，所以我们采
用了一个比较简单且有效的方法，就是我们直接对两个可能形近的字的图像进行
计算。对形近字而言，我们在标准的字体库中，发现它有两个特点：
如鸟和乌两个字，在字体库里的图直接对比，它们的重合度是非常高的，由于字
体库里的字，它的标准化程度是很高的，可以通过这种方式来进行计算。我们这
里基于图像的方式，就是采用我们对字体库里的两个字来进行每个点的一个具体
的计算。
另外，对于鸟和乌这个字，鸟这个字的每一个点在乌字上找到和它最近的一个点，
作为这两个点相似度，那对于每一个点，我们都可以找到一个距离，然后通过求
和的均值计算，我们就可以得到这个两个字距离的相似度。
通过离线对两个字以各自的图像进行计算，那就可以获得比较相似的一些字。
④ 基于字体结构
另外，我们还会通过字体结构的方式来进行计算。像仓颉、郑码、四角号码的编
码，是基于这个字的情况来做的编码。对于俩个形近字，它们的仓颉码、郑码、
四角号码往往也会比较相似。所以，我们通过序列的相似计算，可以获得这两个
形近字的相似度，然后通过相似度进行阈值计算，就可以得到字形相似的集合。
03
召回策略
接下来为大家介绍下飞猪在召回策略上的一些技术：
航旅召回跟常用的搜索召回有相似的地方，也有不同，面临的挑战主要有：
 用户 query 和商品描述之间存在 GAP
 航旅商品仅百万级，而且城市分割，很容易造成无结果
 召回优化时，很容易导致误召回
 旅行是低频行为，用户行为稀疏，算法样本较少
鉴于这种情况，我们对用户的召回分成了以下四种召回方式：经典召回（同义词
挖掘、相似 query 改写、商品 POI 挖掘）、LBS 召回、向量召回、个性化召回（I2I&U2I
以及向量模型），来满足用户的需求。
1. 经典召回
刚刚已经介绍过同义词挖掘和商品 POI 挖掘，这里主要介绍下相似 query 改写。
以“上海迪士尼乐园门票”为例，其实标准的商品是“上海迪士尼度假区”，而
“黄山风景区”的标准商品其实是“黄山”。在这样的情况下，如果我们直接创
建搜索，可能召回的效果比较差。因而，我们会进行一些相似 query 挖掘，来满
足这种 query 和 title GAP 的情况。
Learning To Rewrite：
我们思路是使用多路改写产生候选集合，然后用 learning to Rank 选取 top K 结
果。
首先假设用户在筛选中输入了 query，这个 query 是比较相似的。因为用户在筛
选中是想要获得他想要的结果。如果用户第一个 query，没有得到想要的结果，
用户会进行一些改写。就相当于用户帮助我们完成了一次改写，我们从中可以学
到用户改写的信息。这里我们是用类似 word2vec 的模型实现的。
另外，从 query 相似度来看，我从文本上也可以获得一个相似的 query 文本。这
里我们采用的是 doc2vec 模型，来获得文本相似性。
最后，通过 query 和 title 点击，可以训练一个双塔结构的语义相似度模型，来获
得 query 和 title 相似性的特征。
通过这三种方式，我们可以获得想要的相似 query 改写的候选。
对于候选，通过一些人工标注及线上的埋点信息，来获得原 query 和候选 query
相似的标注。这样我们就可以训练一个模型来进行相似 query 的排序工作。

最终，我们线上使用的模型是 PS-SMART 模型。加上规则过滤之后，准确率可
以达到 99%。可以影响线上 36%的 PV，对一次 UV 的无结果率可以相对降低
18%。
2. 航旅特色召回：LBS 召回
由于用户是在旅行场景下搜索，用户天然会需要 LBS 相关的信息。如果是差旅用
户，可能会定阿里巴巴园区附近的酒店，如果是旅游用户，可能会定黄山风景区
附近的酒店。这就需要识别用户想要的商品大概在什么样的 LBS 范围内。解决的
方法是通过对 query 中用户 POI 的识别，获取用户的经纬度，进行召回上的限制。
建模过程：
首先会对 query 进行常规的分词，然后在 POI 专用的倒排索引库进行检索，获得
候选 POI 。接下来对候选 POI query 进行特征计算，计算出文本相似性、
embedding 相似距离，以及用户当前位置输入后，与历史点击的商品地点的距离
做特征。然后用特征构建模型算出一个分数，通过一定的阈值得到结果。
最后，我们的准确率可以达到 95%，GMV 和成交都得到了一定的提升。
3. 深度召回：向量召回
① 背景
前面提到的都是一些简单的文本召回，以及 LBS 召回等偏传统的方法。前面说过，
我们的商品按照目的地切换后，还是很稀疏，还会存在无召回的情况。对于这种
情况，我们想到引入向量召回的方式进行补充召回。可以覆盖改写没有的情况，
可以召回一些原来不能召回的产品。
② 向量召回整体架构
向量召回架构如上图。在线通过对 query 进行 embedding。离线通过 HA3 引擎，
把所有的 item embedding 存储到 HA3 引擎中。最后，SP 通过从 QP 获得 query
embedding，进行 HA3 检索，获得需要的商品。
③ 模型结构
模型结构，如上所示：
 query 侧：通过对 query 的文本，进行卷积层特征抽取。
 商品侧：我们主要的工作在这里，除了文本上对用户目的地的需求，对商
品类目的需求也是比较关注的。所以在商品特征上，使用了商品 title 文本
的卷积特征，以及目的地类目 id 的特征。
对这三个特征，我们没有使用简单的 concat，而是使用了 tensor fusion 进行三
个向量的外积，可以让特征更好的融合。
最后，通过全链接层进行特征抽取，计算向量内积。
对于损失函数，我们使用的 large margin loss。对于学的足够充分的 case ，就
丢弃掉，不再进行学习，让模型更快的达到我们想要的效果。
④ 样本选择
在样本选择上，我们对正负样本也做了一些探索。
集团内通用的方法：
 正样本：query 下用户点击的商品
 负样本：未点击的商品
这样的方法更适合在排序上使用，而不太适合召回。以左图为例，用户点击了“上
海迪士尼度假区”，未点击的是下面的商品，虽然可能是由于商品的标题标准化
比较低，用户未点击，但不能说它是不相关的商品。
我们的方法：
 正样本：和集团一样，使用点击的商品
 负样本：随机选取的样本作为负样本
使用随机选择有两方面：一是在全量商品中，进行随机选择；二是在一个类目或
者目的地下，进行随机选择。这样可以提升训练的难度，达到我们想要的效果。
⑤ 模型产出与使用方式
最终产出的分数，也给排序使用了，作为排序的一个特征，取得了不错的效果，
可以排在第 4 位。另外，线上召回可以让无结果率降低 32.7%。同时，扩充了
1.7 倍的相似 query。
4. 个性化召回
为什么做个性化召回？
因为在旅行场景下，会存在一些泛需求搜索。比如搜杭州，我们会对杭州所有的
商品和酒店进行召回。这样大量的召回会给后面的排序造成很大的压力，没办法
根据用户的 query 排出一个用户想要的 item。
另外，还有一种情况是用户搜索的意图不是很明确，可能会存在一些无结果的情
况。对于这种情况，传统的文本相似性、深度召回都无法召回的情况下，可以尝
试个性化的方式，给用户推荐一些商品，直接展示在搜索结果中，提供补充，来
提升用户体验。实践证明，用户也会对这类商品进行点击和购买。
我们的方案有两种方式：
 引入推荐的召回结果，在此基础上进行相关性粗排，得到个性化召回
 构建了个性化专用的向量召回模型，来得到更好的个性化召回结果
整体的方式是将召回池分为个性化召回和文本召回两路：
 个性化召回：通过推荐的重定向、i2i 、lbs2i 以及属性 2i 等方式，来获得
推荐召回结果。
 文本相关性过滤：通过文本相关性的过滤（如关键词命中和向量 cos 相似
度），把推荐召回和当前用户搜索 query 很不相关的 item 过滤掉，展现
给用户比较相关，也是通过用户 i2i 扩展的结果。
个性化召回模型：
 在用户侧，通过用户画像属性和用户的 query，进行特征抽取。另外，我
们引入了用户操作序列，来达到个性化目的。比如用户最近搜索时，查看
的商品、点击的商品、加购的商品以及成交的商品，这些操作的商品序列，
引入到模型中。然后通过用户画像和用户 query 特征向量，对用户历史操
作序列做 attention，就能够从用户操作序列中取出跟用户当前搜索最相关
的商品特征，来满足用户当前搜索的需求。
 在商品侧，也会引入商品特征。如商品 title、商品目的地、商品类目等特
征，作为商品的优选，然后获得一个向量。
 在上层，我们采用刚刚提到的 tensor fusion 来进行特征融合，让不同的
特征更好的融合。
模型优化：
在深度向量召回上，对文本的特征采用卷积模型进行抽取。这里并没有采用卷积，
而是采用了简单的词向量 concat 方式。这是因为通过实验验证，使用卷积学到

的文本特征比较强，整体的个性化效果比较弱，这不是我们希望见到的。所以我
们采用了减弱文本特征的限制，突出个性化特征带来的额外检索效果。
04
总结思考
最后，是我们对工作的思考总结：
1. Query & User Planer
现在我们还是叫 QP，后续我们希望升级成 Query & User Planer，能够更多的融
合用户特征，增加更多的个性化搜索能力。
2. 可解释性升级
我们希望对搜索的可解释性进行升级，不是简单的用文本或者深度向量直接进行
召回。我们希望对用户的意图，进行更多维度、更细力度的理解，能够直接理解
成人类可读的意图。
另外，我们希望对用户的行为做预测。因为用户搜杭州时，可能根据历史点击推
出来的商品也不能满足用户需求。我们后续希望对这类 query，能够预测出用户
想去的景点。当用户搜酒店时，可以预测出用户想去的目的地，更好的满足用户
需求。
5G+智能时代的多模搜索技术
分享嘉宾：李国洪百度资深研发工程师
编辑整理：李斌
导读：2010 年随着 iphone4 的发布，智能手机被广泛使用，从大学生到老人小
孩，移动互联网的发展如火如荼。近两年，5G 技术让下载速度变得越来越快，相
较于传统的文本搜索技术，语音搜索和图片搜索等新型搜索方式出现在越来越多
的产品形态当中。
今天的内容主要分为 4 个部分来介绍多模搜索技术：
 多模搜索：始于移动，繁荣 5G+智能时代
 语音搜索：听清+听懂+满足
 视觉搜索：所见即所得
 “破圈”：无限可能
01
多模搜索：始于移动，繁荣 5G+智能时代
1. 多模搜索的概念
多模搜索包括视觉搜索和语音搜索两种形式。在百度 app 的下方，语音按钮的部
分，是语音搜索的入口。在搜索框的右侧相机的按钮，是视觉搜索的入口。语音
搜索可以很好地替代文字搜索，而视觉搜索，可以帮用户方便的找到图片背后所
具有的信息。
2. 百度为什么在 2015 年开始多模搜索技术的积累
 以 iphone 手机为代表的智能手机时代到来，使得语音输入成为可能。
 4G 通讯网大大提高了上传下载速度，上传图片不再困难。
 我们的网民从中青年开始向两侧的小孩儿和老人扩展。
3. 多模搜索在 5G 新时代产生的变化
 沉浸式体验。在 5G 带宽更加强大之后，我们需要有一些超越视频的更加
沉浸式的体验。
 延时的降低。在 5G 推广开来之后，尤其是借着云边端三个阶段的服务的
部署，包括很多的模型，从云端前置到端，这样的话可能会带来很大的便
利。
 新的硬件。伴随智能音响、蓝牙耳机、智能手表、智能眼镜的广泛使用，
进一步催生多模搜索的用户需求。
02
语音搜索：听清+听懂+满足
1. 语音搜索的目标有三个，听清、听懂、满足
 听清：准确地将我们说话的语音信号转换到文字，这里面临的挑战其实非
常的多：① 环境比较嘈杂；② 方言；③ 声音过小。
 听懂：即使当我们去把语音转换成文字，也不代表我们就能按照传统的搜
索的方法把转换后的文字直接丢给搜索引擎去理解。原因：① 口语化的问
题；② 长尾的问题；③ 连续搜索。举个例子，第一次用户会问“伦敦现
在几点”，但下一次他不会再说“巴黎现在几点”，会直接问“巴黎呢”。
 满足：一些特定的语音入口，比如智能音箱上，我们不太可能会把前十的
搜索结果去给用户都播报一遍，我们只能给用户最精准的 top1 结果。
2. 技术方案
整体这三个阶段大的技术框架如下：
 首先在听清这个环节。从输入角度来看，有两个：① 语音识别。这个阶段
更多的是把声学的信号转换成基础的文本文字；② 语音纠错，语音纠错会
把用户原始的文字表达改变成适合搜索引擎去真正理解的 query。在最后
的内容表达的过程中，会经过一些播报生成、语音合成，使得交互更加的
自然。
 在听懂的环节主要有四个部分：① query 的泛化，这一步的目标其实会把
整个用户的长尾表达，映射到搜索引擎更加好理解的一些比较高频的
Query 上去；② 对口语理解，可以转化为 QA 问题；③ 上下文的理解；
④ 整个搜索 session 的管理
 在满足这个环节层面。站在整个百度通用搜索的肩膀上，在某一些特定的
场景需要给用户一些更精准的一些表达，所以这里面需要智能问答的技术，
还包括知识图谱的技术，最后提供一些特定服务。
03
视觉搜索：所见即所得
1. 目标
视觉搜索要做的事情就是所见即所得，无论是用户通过手机拍摄，或者是通过摄
像头实时摄像看到的一些东西，我们都能给到其背后的内容，这里面大概有三个
挑战。
 交互。交互技术是一个很重要，影响用户整个的交互效率比较高的环节。
 感知。不同于文本搜索把每一段文字或者自己的需求通过比较高级别抽象
的东西去表达出来，视觉搜索需要从像素级来感知和构成更高级的物体级
信息。
 识别。理解整个由像素集合所代表的一个个物体背后的信息。
2. 成就
经过几年的努力，百度取得了比较好的技术积累，实现了全球比较领先的视觉感
知和搜索引擎。从交互上来看，基本可以在 100 毫秒左右，在手机端上就能给用
户一个很好的感知反馈，同时覆盖了 60 多个场景，索引了 8000 多万种的实体，
几十亿的商品，还有 1000 多亿的图片。
3. 视觉技术
整个视觉搜索的技术大概分为三个层面，
 第一个层面是视觉感知，这个层面主要再用户的手机本地计算，这里面包
括 2D 和 3D 的检测，2d 和 3D 的跟踪，包括一些简单的场景识别，还有
支持 AR 定位和渲染。
 第二个环节是视觉识别，当我们在手机端完成这些感知之后，需要对感知
到的这些物体做更详细的信息搜索和满足。
 第三个是基础技术，主要用来支撑上面的感知和识别，包括图像的理解、
文本的理解、视频的理解，还有关于人体、人脸等等一些感知技术，也包
括一些基础的云和端上的性能优化、多模态的 QA 技术等。
4. 视觉感知流程
把视觉感知打造成一个基于视频流的感知计算和 MR 交互的一个框架，这个框架
是完全在端上去计算，主要包含六个流程
 检测与分割。主要是发现画面里面的一些基础的物体，以及它的一些物体
类型。
 跟踪。因为我们要做连续的交互，画面会有持续移动，所以就会需要做一
些跟踪和定位，去保持住跟踪物体的具体位置。
 粗粒度理解。端上对整个流量做一些简单理解，起到流量精准分发的目的。
 AR 展现。在云端搜索结果返回之后，把结果信息通过 AR 的方式展现。
 MR 交互。通过手指或者肢体表情交互，让用户可以与 AR 内容做更进一
步的交互和交流。
 应用场景。最后是支撑已有的几个产品形态，包括动态多目标识别、拍题
搜索、AR 翻译、实时取词等。
视觉感知算法的演进
 从 2017 年开始，我们第一次尝试在端上做物体检测技术，它的目标就是
做轻量级模型。
 第二个阶段是在 2018 年，在做连续的帧检测的时候，解决新的检测稳定
性的问题。
 2019 年开始，我们想进一步提升小物体的检测效果，在 Multi-Scale 检测
和网络结构自动搜索上做了一些工作。
 然后到 20 年会更多的去通过多阶段蒸馏和 anchor free 模型探索，进一
步提升整体的检测效果。
算法迭代
 第一代检测算法：首先在第一个阶段轻量级的阶段，我们选型直接选了 one
stage 的检测方法，使用公开的 mobilenet-v1 结合剪枝增加模型的速度，
loss 在 layer 层面也做了一些简单的优化，并且尝试使用了 focal loss。

 第二代检测算法：刚刚提到我们发现了一个新的问题，在连续检测时检测
的输出会发生很大的变化，这是影响着连续帧的检测稳定性的一个根本的
原因。我们首次提出问题的定义和量化公式，最终结合多帧信息非常好的
解决了检测稳定性问题，同时兼顾了性能。
 第三代检测算法：第三代的主要目的是解决小物体召回，基本上从两个阶
段来入手，第一个就是整体的网络模型结构，yolo-v3 对小物体会更加友
好，第二个是引入了网络的结构化搜索，会进一步提升对小物体的优化。
 第四代检测算法，我们观察到，虽然改进后 yolo-v3 效果已经很不错，但
是与 retinanet-50 甚至更大的模型相比，还是有很大的差距。因此希望通
过蒸馏的方式进一步提升检测结果的准确率。
5. 视觉识别检索的流程
基本的流程是：基于 sift 或者 cnn 提取的特征，然后使用 ANN 进行检索。
我们大概经历了三个阶段的演进：
 第一个阶段是 2015 年刚开始做的时候，基于有监督的方式。

 第二个阶段是 2018 年的时候，我们开始引入了半监督的方式，通过数据
驱动训练图像以及视频的特征表示。
 从 20 年开始，我们从半监督向无监督的方式去升级算法，希望利用到更
多的数据去学习到一个更加适合任务自身场景、泛化能力也更好的特征表
示。
有监督方法存在的问题
 第一个有标注的数据，数据规模往往比较小，而且噪声也相对来说比较多
一些。
 第二点由于它的规模比较小，所以样本多样性往往是不足的。
 第三个问题是通过这种人工标注，有多少人工就有多少智能，标注成本也
是非常高的，而且这个周期也比较长。
无监督方法的选型和演进
 第一种是比较偏向于传统的谱聚类的方式实现，根据向量得到 pair 之间的
相似度，然后将聚类的编号作为数据的 label。
 第二种是以 BYOL 算法代表的，将图片经过多种增强后得到自身的变形，
通过原始图和变形图之间的对比学习，学习到整个图片比较好的特征表达。
04
“破圈”：无限可能
破圈无限可能，未来多模搜索的技术和产品形态会往哪里发展？度晓晓 App 是答
案之一。
度晓晓是在 20 年百度世界大会上第一次发布的多模搜索新的产品，从技术角度
来看它是语音、视觉、文本三大技术领域的一个交汇，汇聚了语音识别、图像识
别，还有智能搜索、NLU 和多轮对话的技术，同时它本身有一个虚拟形象存在，
富含多种情感的语音合成技术，它的背后是百度多种技术方法和产品的融合，包
含着信息和服务搜索，以及互动娱乐的部分。
未来通过更多的整合多模搜索技术，将产生更多无限可能。
知乎搜索文本相关性与知识蒸馏
分享嘉宾：申站知乎算法工程师
编辑整理：许宴铭
导读：大家好，我是申站，知乎搜索团队的算法工程师。今天给大家分享下知乎
搜索中文本相关性和知识蒸馏的工作实践，主要内容包括：
 知乎搜索文本相关性的演进
 BERT 在知乎搜索的应用和问题
 知识蒸馏及常见方案
 知乎搜索在 BERT 蒸馏上的实践
01
知乎搜索文本相关性的演进
1. 文本相关性的演进
我们首先来介绍下知乎搜索中的文本相关性。在搜索场景中，文本相关性可以定
义为⽤户搜索 query 的意图与召回 doc 内容的相关程度。我们需要通过不同模
型来对这种相关程度进行建模。整体而言，文本的相关性一般可以分为两个维度，
字面匹配和语义相关。知乎搜索中文本相关性模型的演进也是从这两个方面出发
并有所侧重和发展。在知乎搜索的整个架构中，文本相关性模型主要定位于为二
轮精排模型提供更高维/抽象的特征，同时也兼顾了一部分召回相关的工作。
2. Before NN
知乎搜索中的文本相关性整体演进可以分为三个阶段。在引入深度语义匹配模型
前，知乎搜索的文本相关性主要是基于 TF-IDF/BM25 的词袋模型，下图右边是
BM25 的公式。词袋模型通常来说是一个系统的工程，除了需要人工设计公式外，
在统计词的权重、词频的基础上，还需要覆盖率、扩展同义词，紧密度等各种模
块的协同配合，才能达到一个较好的效果。知乎搜索相关性的一个比较早期的版
本就是在这个基础上迭代的。右下部分为在基于词袋模型的基础上，可以参考使
用的一些具体特征。
3. Before BERT
基于 BM25 的词袋模型不管如何设计，主要还是只解决文本相关性中的字面匹
配这部分问题。第二阶段引入的深度语义匹配模型则聚焦于解决语义相关的问题，
主要分为两部分：双塔表示模型和底层交互模型。微软的 DSSM（左下）是双塔
模型的典型代表。双塔模型通过两个不同的 encoder 来分别获取 query 和 doc
的低维语义句向量表示，然后针对两个语义向量来设计相关性函数（比如
cosine）。DSSM 摆脱了词袋模型复杂的特征工程和子模块设计，但也存在固有
的缺陷：query 和 doc 的语义表示是通过两个完全独立的 encoder 来获取的，
两个固定的向量无法动态的拟合 doc 在不同 query 的不同表示。这个反应到最
后的精度上，肯定会有部分的损失。
底层交互模型一定程度上解决了这个问题。这个交互主要体现在 query 和 doc
term/char 交互矩阵（中）的设计上，交互矩阵使模型能够在靠近输入层就能获
取 query 和 doc 的相关信息。在这个基础上，后续通过不同的神经网络设计来
实现特征提取得到 query-doc pair 的整体表示，最后通过全连接层来计算最终
相关性得分。Match-Pyramid（右下）、KNRM（右上）是交互模型中比较有代
表性的设计，我们在这两个模型的基础上做了一些探索和改进，相比于传统的
BM25 词袋模型取得了很大的提升。
4. BERT
BERT 模型得益于 transformer 结构拥有非常强大的文本表示能力。第三阶段我
们引入了 BERT 希望能够进一笔提高知乎搜索中文本相关性的表型。BERT 的应
用也分为表示模型和交互模型。
对于交互模型来说，如下左图，query 和 doc 分别为 sentence1 和 sentence2
直接输入到 BERT 模型中，通过 BERT 做一个整体的 encoder 去得到 sentence
pair 的向量表示，再通过全连接层得到相似性打分，因为每个 doc 都是依赖 query
的，每个 query-doc pair 都需要线上实时计算，对 GPU 机器资源的消耗非常大，
对整体的排序服务性能有比较大的影响。
基于上述原因，我们也做了类似于 DSSM 形式的表示模型，将 BERT 作为
encoder，训练数据的中的每个 query 和 doc 在输入层没有区分，都是做为不同
的句子输入，得到每个句向量表示，之后再对两个表示向量做点乘，得到得到相
关度打分。通过大量的实验，我们最终采用了 BERT 输出 token 序列向量的
average 作为句向量的表示。从交互模型到表示模型的妥协本质是空间换时间，
因为 doc 是可以全量离线计算存储的，在线只需要实时计算比较短的 query ，
然后 doc 直接通过查表，节省了大量的线上计算。相比于交互模型，精度有一部
分损失。
02
BERT 在知乎搜索的应用和问题
1. 搜索业务架构中的 BERT
在下图中我们可以看到，BERT 在知乎搜索业务的召回和排序阶段都扮演了比较
重要的角色。交互模型的主要服务于二轮精排模型，依赖于线上实时的计算 query
和 doc，为精排模块提供相关性特征。表示模型又分为在线和离线两块，在线表
示模型实时的为用户输入的 query 提供句向量表示，离线表示模型为库中的 doc
进行批量句向量计算。一方面，doc 向量通过 TableStore/TiDB 和 Redis 的两级

存储设计，为线上排序做查询服务；另一方面，使用 faiss 对批量 doc 向量构
建语义索引，在传统的 term 召回基础上补充向量语义召回。
2. BERT 表示模型语义召回
下面详细介绍下我们的语义召回模型。首先看个例子，对于「玛莎拉蒂 ghlib」
这个 case，用户真正想搜的是「玛莎拉蒂 Ghibli」这款车，但用户一般很难记
住完整的名称，可能会输错。在输错的情况下，基于传统的 term 匹配方式（Google
搜索的例子）只能召回“玛莎拉蒂”相关的 doc，而无法进行这辆车型的召回，
这种场景下就需要进行语义召回。更通用的来说，语义召回可以理解为增加了字
面不匹配但是语义相关的 doc 的召回。
语义召回模型整体是 BERT 相关性任务中双塔表示模型的一个应用。BERT 做为
encoder 来对 query 和 doc 进行向量的表示，基于 faiss 对全量 doc 向量构建
语义索引，线上实时的用 query 向量进行召回。这个策略上线后，线上 top20 doc
中语义召回 doc 数量占总召回 doc 数量的比例能到达 5%+。
3. BERT 带来的问题
BEER 模型上线后，为不同的模块都取得了不错收益的同时，也给整个系统带来
了不少问题。这些问题整体可以归结为线上实时计算、离线存储、模型迭代三个
方面。具体的见上图。
4. 蒸馏前的尝试
针对上述性能或存储的问题，在对 BERT 蒸馏之前，我们也进行了很多不同的尝
试。
BERT 交互模型的部署放弃了使用原生 TF serving，而是在 cuda 的基础上用
c++ 重写了模型的加载和 serving，加上混合精度的使用。在我们的业务规模上，
线上实时性能提高到原来的约 1.5 倍，使 BERT 交互模型满足了的最低的可上线
要求。在这个基础上，对线上的 BERT 表示模型增加 cache，减少约 60% 的
请求，有效减少了 GPU 机器资源的消耗。
另一个思路是尝试给 BERT 在横向和纵向维度上瘦身。横向上，一方面可以减小
serving 时 max_seq_length 长度，减少计算量；另一方面可以对表示向量进行
维度压缩来降低存储开销。这两种尝试在离线和在线指标上都有不同程度的损失，
因此被放弃。纵向上，主要是减少模型的深度，即减少 transformer 层数。这对
于显存和计算量都能得到显著的优化。前期尝试过直接训练小模型，以及使用
BERT-base 若干层在下游的相关性任务上进行 fine-tune。这两种方案，在离线
指标上的表现就没法达到要求，因此也没有上线。
针对 doc 数量过大，存储开销过大和语义索引构建慢的问题。在这方面做了一个
妥协的方案：通过 wilson score 等规则过滤掉大部分低质量的 doc，只对约 1/3
的 doc 存储表示向量和构建语义索引。该方案会导致部分文档的相关性特征存在
缺失。对于表示模型存在的低交互问题，尝试 Poly-encoder（Facebook 方案）
将固定的 768 维表示向量转为多个 head 的形式，用多个 head 做 attention 的
计算，保证性能在部分下降的前提得到部分精度的提升。
03
知识蒸馏及常见方案
1. 知识蒸馏
下面简单介绍下知识蒸馏。从下图中看，我们可以把知识蒸馏的整体形式简化为：
大模型不考虑性能问题尽量学习更多的知识（数据），小模型通过适量的数据去
高效地学习大模型的输出，达到一个知识迁移的效果。实际 serving 使用的是小
模型。
知识蒸馏为什么能有效？关键点在于 soft target 和 temperature。soft target
对应的是 teacher 模型的输出，类似于概率分布，知识蒸馏从 hard target 转为
soft target 的学习有利于模型更好的去拟合标签，引入 temperature 则是为了进
一步平滑标签，让模型去学习到类别和类别中的知识。这里需要注意的是，
temperature 的选取不宜过大，太大的 temperature 会导致不同类别之间的差
异被完全平滑掉。
2. BERT 蒸馏方案
对与 BERT 的蒸馏我们做了大量的调研，并对目前主流的蒸馏方案做了归纳分类。
基于任务维度来说，主要对应于现在的 pretrain + fine-tune 的两段式训练。在
预训练阶段和下游任务阶段都有不少的方案涉及。技巧层面来分的话，主要包括
不同的迁移知识和模型结构的设计两方面。后面我会选两个典型的模型简单介绍
一下。
3. 蒸馏-MiniLM
MiniLM 是基于预训练任务的蒸馏，其是一种通用的面向 Transformer-based 预
训练模型压缩算法。主要改进点有三个，一是蒸馏 teacher 模型最后一层
Transformer 的自注意力模块，二是在自注意模块中引入 values-values 点乘矩
阵的知识迁移，三是使⽤了 assistant ⽹络来辅助蒸馏。
4. 蒸馏-BERT to Simple NN
BERT to Simple NN 更多的是做了一些 loss 形式的设计，使其训练方式更高效。

04
知乎搜索在 BERT 蒸馏上的实践
1. BERT 蒸馏上的实践和收益
前面的介绍中我有提到，在做 BERT 蒸馏前其实已经做了很多尝试，但是多少都
会有精度的损失。因此，我们做蒸馏的第一目标是离线模型对⽐线上 BERT 精度
⽆损。但对 BERT-base 直接进行蒸馏，无论如何都没办法避免精度的损失，所
以我们尝试用更大的模型（比如 BERT-large/Robert-large/XLNET ）来作为
teacher 进行蒸馏。这些多层的模型均在我们知乎全量语料先做 pretrain，再做
fine-tune，得到微调后的模型再做蒸馏。
2. 蒸馏-Patient KD
我们对交互模型和表示模型都做了蒸馏，主要采用了 Patient KD 模型的结构设计，
Student 模型基于 BERT-base 的若干层运用不同的策略进行参数的初始化，去
学习 Robert-large 大模型的方案。
其中知识迁移主要有三部分：student 的预测与真实标签的交叉熵、student 与
teacher 的预测的交叉熵和中间隐层的向量之间的 normalized MSE。
3. BERT 交互模型蒸馏
对于我们选的 teacher 模型 Robert-large ，单纯预训练模型其 nDCG 指标为
0.914，线上之前使用的 BERT-base 是 0.907，若对 BERT-base 的若干 6 层
直接去做 fine-tune 能达到的最高指标是 0.903，对比于 BERT-base 精度会损失
很多。
我们这块做了一些尝试，基于 Robert-large 从 24 层蒸馏到 6 层的话能到 0.911，
能超过线上 BERT-base 的效果。
训练数据方面，我们经历了点击日志数据挖掘到逐渐建立起完善的标注数据集。
目前，相关性任务训练和蒸馏主要均基于标注数据集。标注数据分为 title 和
content 两部分，Query 数量达到 10w+ 的规模，标注 doc 在 300w ~ 400w
之间。
4. BERT 表示模型蒸馏
在 BERT 表示模型上，蒸馏时我们希望对向量维度和模型层数同时进行压缩，但
蒸馏后得到的 student 模型表现不及预期。所以最后上线的方案中，表示模型层
数还是维持了 12 层。在蒸馏时，为了提高精度，选取交互模型作为 teacher 进

行蒸馏。因为交互模型是 query 和 doc 之间的打分，交互模型得到的 logits 与表
示模型点乘后的打分在数量值会有较大差值，所以用 pairwise 形式通过 teacher
差值拟合来进行 loss 的计算。
在维度压缩方面我们做了对比实验，BERT 模型输出做 average pooling 后接全
连接层分别压缩至 8 维到 768 维。如图所示，128 维和 64 维的表现跟 768 维差
别不大，在上线时选择维度为 64 和 128 进行尝试，两者在线上表现没有太明显
的差异，最终选择了 64 维的方案，把模型的维度压缩了 12 倍，存储消耗更低。
5. 蒸馏的收益
蒸馏的收益主要分为在线和离线两部分。
在线方面：
交互模型的层数从 12 层压缩到 6 层，排序相关性特征 P95 减少为原本的 1/2，
整体搜索入口下降 40ms，模型部署所需的 GPU 机器数也减少了一半，降低了资
源消耗。
表示模型语义索引存储规模 title 减为 1/4，content 维度从 768 维压缩至 64 维，
虽然维度减少了 12 倍，但增加了倒排索引 doc 的数量，所以 content 最终减为
1/6，
语义索引召回也有比较大的提升，title 减少为 1/3，content 减少为 1/2。精排模
块需要线上实时查询离线计算好的向量，所以查询服务也有提升。
离线方面：
表示模型语义索引的构建时间减少为 1/4，底层知乎自研的 TableStore/TIDB 存
储减为原来的 1/6，LTR 训练数据和训练时间都有很大的提升，粗排早期用的是
BM25 等基础特征，后来引入了 32 维的 BERT 向量，提升了精排精度。
京东搜索在线学习探索实践
文章作者：刘露、张颖、段学浩、王东旭
内容来源：京东算法架构
导读：随着京东零售搜索业务的快速发展，对数据的时效性要求越来越高，要求
搜索模型有捕捉更实时信号的能力，在线学习体现了业务对模型时效性的追求，
希望能根据在线系统反馈的数据实时得对模型进行调整，使得模型能快速反应环
境的变化，提高在线预估的准确率。
01
背景
目前传统模型的实时训练（如 FTRL 等）无法支持深度模型，这些模型预估的准
确率较低，比较适合一些简单的场景；第二种是类似增量训练的一种方式，可支
持深度模型预估，这种方式以尽可能短的周期进行模型训练和迭代上线，是一种
类实时的更新方式；第三种是以实时更新方式更新模型的局部结构，可支持深度
模型的预估，模型的一部分参数直接参与实时训练。
02
系统概述
 模型预估服务：在加载模型时，分为 static 部分和 dynamic 部分，static
部分由离线数据训练得的到，主要学习 user 和 doc 的稠密特征表示，
dynamic 部分主要包含 doc 粒度的权重向量，这部分由实时的 online
learning 的任务进行流式更新；
 Rank：主要包括一些排序策略，在排序后会实时落特征日志，将当时的特
征写入特征数据流，作为后续实时样本的数据源(feature)；
 Flink 样本拼接任务：将上面的 feature 和用户行为标签数据作为数据
源，通过 flink 的 union + timer 数据模型关联成为流式样本数据；
 Online Learning 任务：负责消费上游生成的实时样本做训练，在训练得
到新参数后更新 PS。
这里我们介绍整个链路的迭代过程：
 经过离线样本拼接之后生成离线样本表，然后在模型训练平台训练之后将
模型推送至模型仓库，同时将离线训练的参数推送至 ps，之后 predictor
load 这个全量的离线模型；
 经过实时样本拼接之后生成实时样本表，经过 flink 的 online learning 组
件将实时的 embeding 参数推入 ps，将 ps 作为 dynamic model 的数
据源；
 预估服务 predictor 加载全量的模型文件和实时训练的参数，提供在线服
务；
 离线模型提供周/日级别的周期模型校正。
03
实时特征和样本处理
实时特征收集的目标是承接搜索在线预估系统所发出的特征数据，对下游屏蔽掉
缓存、去重、筛选、分页等搜索系统特有的业务逻辑，提前滤除掉下游一定不会
使用的数据，构建出标准 Schema 的原始特征流。该组件承接来自于搜索召回、
排序、相关性等模块的实时特征，每秒需处理约 2400W 条特征数据。

实时样本拼接的目标是将搜索特征与用户端的行为埋点实时关联。目前我们的数
据数据过滤后的 QPS 峰值大概在 10w，拼接完产生的样本 QPS 峰值在 5w，该
flink 任务的特点是多流拼接、时间窗口长、checkpoint size 大。我们采用 union
+ timer 的模式实现多任务场景下的样本拼接，该实现策略的特点是可以随意扩
展至 N 流并进行拼接；为了减少与外部存储的交互来降低网络的开销，我们使用
flink 内部的 rocksdb state backend，并且对 rocksdb 的序列化手段和存储进
行了相当的优化。
这里首先列举了一些常见的数据倾斜，比如说 key 的设计不合理、 flink 的
shuffle 方式选择有问题、任务反压、机器资源的问题等，这里我们着重介绍一
下这个任务的一些数据倾斜问题。
无效样本过滤策略，在最开始的时候我们发现某些 subtask 每次都会在固定的时
间点发生 checkpoint 失败的现象，经过排查我们发现在实际的样本拼接数据里
面会有很多的作弊数据，这导致那些 checkpoint 失败的 subtask 处理数据的 QPS
是其它 subtask 的好几倍，过滤了这些作弊数据之后，任务恢复正常；我们还遇
到过的一个数据倾斜现象是这样的：kafka source 所在的 subtasks 莫名其妙
的数据倾斜，机器的各个指标都没有到达瓶颈，经过排查之后是 kafka producer
产生数据的时候 produce 的 key 指定了一个空的字符串""，这种经过 hash 之
后只会产生到 kafka 的固定分区，flink 在接受数据的时候 kafka source 所在
的 subtask 是数据倾斜的，如果后面跟着的是一个 map 操作（forward），那
么后面的 map 也就会数据倾斜。
样本拼接上线之后，任务运行稳定，但是某些 subtask 处理的数据量是一些数据
量少的 subtask 的 1.5 倍，这种其实不算是严格意义上的数据倾斜，但是会造
成资源的一定程度的浪费。利用 flink 中 keygroup 的概念，和 maxParallelism
大小相同，经过调整 maxParallelism 的大小，保证了每个 subtask 上面处理的
数据量相同，解决数据倾斜问题。
由于数据量大，且存储的特征比较多，导致任务的 checkpoint size 达到了 TB 级
别。最开始的时候我们将数据放到了内存里面，但是因为数据量巨大，导致 GC
时间特别长，我们将数据放到了 rocksdb 里面，并且我们对 rocksdb 的
blockcache、 writebuffer 等进行调优，添加了 bloomfilter，使得 rocksdb 的
响应时间优化到了 0.04ms 以内；通过合理设置 checkpoint 的超时时间、间隔
时间和最小暂停时间，使得任务在追数据的时候不至于导致 qps 突增太明显；最
开始做拼接的时候我们将所有的 pvid logid 和特征等值放入了一个 valuestate，
经过 jstack 发现所有的线程都在做序列化和反序列化，其实我们做拼接只要 pvid
和 logid 就好了，因此我们将 pvid 和 logid 放入 valuestate，将特征放入其它
的 state 里面，这样就少了很耗资源的序列化和反序列化操作，减少了很多系统
开销；我们还开启了 flink 特有的本地恢复和增量的 checkpoint 操作来减少开
销。
04
Flink 实时训练
在线学习过程对实时样本具有一定要求，上游任务产生样本数据之后，因为是乱
序的，我们为了保证样本流进入训练时最大程度还原真实事件顺序，利用 flink 的
watermark 机制对样本进行了保序操作，之后我们实现了带有超时时间的
countwindow 来做 online 的 train ，通过 ps 来更新参数， ps 作为线上的
inference 后端来直接查询。
 采用 flink 的 watermark 和 eventtime 作为 timecharacteristic 来保
证顺序是有序的，尽可能的贴近事件当时的发生场景；样本一旦出现延时，
且超过了系统的最大配置，我们会认为该样本不可用，直接丢弃。
 为了允许在线学习任务自主配置每次训练迭代的数据规模，我们内部实现
了带有超时时间的 countwindow 来精确控制每个 batch 的大小；且我们
支持任意维度的 key 组合来实现任意维度的 batch 选择，这样方便实现
session 粒度、item 粒度和 user 粒度的样本等。
 当我们使用 flink 的 keyed state 的时候，采用异步更新的方式更新 ps；
当我们使用 flink 的 operator state 的时候，同步的方式更新 ps。
 目前对搜索算法接入了点击、加购、关注、下单、完成等多个标签流，支
持丰富的标签选择。
 支持样本比例的定制化，支持按照规则触发训练。
 参数更新：首先我们将用离线的 30 天的数据训练出来的模型参数导入 ps，
之后 flink 的在线训练将实时更新参数，该 ps 直接服务于线上。目前在
线和实时共用一套 ps，为了之后的稳定性要求，我们之后会将实时和在线
分开。
 模型校准：为了确保模型的准确性，支持天/周粒度的完整模型更新进行校
准。
05
全链路监控
对于端到端的机器学习，全链路的稳定性是很重要的，任何一个节点出问题都会
影响最后的效果，因此我们建设了全链路监控，保证如果出现了问题能在第一时
间发现并且解决问题。
在业务监控方面，我们的全链路包括 predictor 相关的监控、feature dump 相
关的监控、样本的关联率、样本的延时时间、AB 指标等监控。此外在最终的效
果上加监控数据，保证能从效果上得到一个全链路健康度的认知。
在平台监控方面，实时特征收集、样本拼接、实时训练等 flink 任务，借助于京
东中台实时计算团队提供的监控组件完成了任务的相关监控，保证了任务的稳定
性。这些监控从容器的 cpu、内存等细粒度的方方面面监控，确保我们可以及时
捕捉问题所在。
06
总结
Flink 在实时数据处理方面有优秀的性能、容灾、吞吐等表现、算子丰富易上手使
用、自然支持批流一体化，且已有不少机器学习框架陆续开源。随着机器学习数
据规模的扩大和对数据时效性、模型时效性要求的提升，在线学习不仅仅作为离
线模型训练的补充，更成为模型系统效率发展的趋势。
阿里文娱搜索算法实践与思考
分享嘉宾：若仁阿里文娱高级算法专家

编辑整理：秋林津渡
导读：视频搜索是涉及信息检索，自然语言处理 ( NLP )，机器学习以及计算
机视觉 ( CV ) 等多领域的综合应用场景，随着深度学习在这些领域的长足进
展以及用户对视频生产和消费的广泛需求，视频搜索技术的发展在学术和工业
界都取得了飞速的发展，本文将以优酷为例，分享视频搜索的算法实践，首先
介绍优酷搜索的相关业务和搜索算法体系，从搜索相关性和排序算法的特点和
挑战到技术实践方案的落地，最后会深入介绍优酷在多模态视频搜索上的探索
和实践。
本次分享主要包括：
 视频搜索简介
 基础相关性和排序模型
 多模态视频搜索实践
▌视频搜索简介
1. 业务背景
优酷搜索为整个阿里大文娱提供了一站式搜索服务，范围包括优酷所有搜索入
口，如 APP 和 OTT 等，还包括大麦和淘票票。搜索的内容包括有版权的影、
剧、综、漫影视库，用户上传的 UPGC 视频内容，影人库，演出，小说资讯
等，这些都是文娱搜索业务需求，优酷搜索为其提供统一的搜索服务。
2. 评估指标
搜索排序业务多目标的评估指标，如图所示，可以拆分成 4 个大类。搜索的用
户价值主要体现在 2 个维度：
第一个维度为工具属性，指的是用户将搜索服务作为一个搜索工具，目标是找
准找全。这是用户价值的基础，也是搜索的基础属性。从这个维度去评估搜索
效果的好坏，主要从体验指标去衡量：跳出率、相关性、时效性、多样性等通
用指标。视频搜索可播性是指由于受版权影响，有些视频在平台是不能播放的，
能给用户提供更大价值的是那些可播的视频。此外，会用人工评测的方式对搜
索的效果做横向纵向的对比，来衡量搜索的满意度。
第二个维度为分发属性，能让用户消费更多的内容，主要是视频观看的 VV 和
消费时长，这些指标对搜索是非常重要的，是用户满意度的直接体现。搜索能
够支持平台的宣发价值和广告会员的商业化价值，前提是服务好用户，用户体
验好。
3. 搜索系统框架
上图是搜索系统的整体框架，在 2017 年初步完成了搜索引擎相关中间件服务
的升级，实现和集团搜索技术的战略拉通。从一个 query 搜索过程来理解各
个模块的功能，比如说用户搜"大明风华"，用户在手机上发起这一次请求，接
入搜索网关之后，search planer 把这个请求发送到 QP 服务，即 query 理
解的一个服务，对 query 做意图判定，成分分析，把这些信息传递到中间的
引擎模块去做相应的检索，如粗排和精排的逻辑，将结果返回回来，再到一个
RankService 排序服务。
整个框架中间层是引擎，下面是离线的索引服务，左边是机器学习平台，包括
特征的流式计算，模型的在线学习，后面主要介绍排序服务模块。
4. 搜索算法框架
在引擎端，相关性主要是在 searcher 的精排下实现的，排序模型的介绍主要
是预测模型这一层。整个排序服务包括预测模型、模型融合、业务策略，整体
上保证了搜索体验和效率。
右图是整个搜索算法的大图，通过这里的介绍希望大家对视频搜索技术有一个
全貌的理解，方便大家对后面内容的理解。
 QP 服务在排序中的作用：首先在意图层面，会把用户意图细粒度的切
分出来，对 query 的各个意图做成分分析，比如说 query 是"乡村爱
情赵四跳舞"，经过 QP 服务的成分分析后，判断乡村爱情属于一个节
目名，赵四属于角色，跳舞是一个动作。
 意图识别后是排序和多媒体相关性，这两个内容后面再详细介绍。
 内容召回：主要是多媒体内容的理解，为什么要做多媒体内容理解，因
为视频内容传递的信息非常丰富，不可能用文本标题全面表述，用户在
搜索时表达需求差异非常大，存在语义鸿沟，各个业务的搜索都存在语
义鸿沟，视频搜索中的鸿沟更大，所以不能把视频当成黑盒直接用标题
概述。我们的问题是从什么维度去理解视频？得益于深度学习在各个领
域的全面发展，现在有能力做相关技术，包括 OCR/ASR，对话的理解，
通过 CV 的技术对人物、动作、物体的元素级的结构识别，视频的指
纹，实体关联，比如某个视频是属于哪个 ip ( 电视剧/电影等 )。基于
这些相关技术，不仅仅只是做标题的文本匹配，与相关性匹配密切的关
联起来，能更好的帮助理解视频和视频间的关联关系。
 数据层：有实体的关系数据，能够通过技术挖掘这种关系；内容组织，
通过图谱聚合、时效聚合、内容聚合，把内容聚合成更方便用户浏览的
聚合形态。
▌相关性和排序内容
1. 搜索相关性
这部分定义到一些具体的 query 和 doc 上，理解能够更全面一些。如上图：
 第一类 query，"佟丽娅主演的电视剧远大前程"和 doc 在文本上没有
直接关系。只有通过内容理解的方式才能把这个 query 和 doc 关联
上。
 第二类 query，"法不容情国语"和对应的 doc 没有关系，要结合 NER
和内容理解的方式才能更准确，对 doc 的意图理解更好。
 第三类是语义层面的匹配，相关性这一块是需要多个层次的匹配的。
下面分为 4 个层次详细分析：
 基础特征。比较通用的是 term weight 和匹配矩阵，通过基础特征能
够把文本匹配做的比较好。
 知识特征。对于知识特征的匹配需要其他辅助信息的补充才能做好的，
首先通过内容理解的方式把 UPGC 视频中的一些元数据补充上去，利
用 NER 等技术把视频的标题等成分识别准确。在这些基础之上，我们
做 query 和 doc 之间的结构化的知识匹配，这块体验能够做的更好。
 后验特征。包括基于 query 点击的应用判断，知识结合做意图判断，
意图和 doc 的匹配， Query_Anchor 是从 doc 维度统计的，哪些
query 是和 doc 是有关系的，能做一些文本的补充和意图补充，这种
补充不是纯粹的统计，而是基于浏览模型，比如 UBM 和 DBN 等一

些点击浏览的模型，去消除文本、吸引度的偏差，提高满意度，后面在
相关性特征还会详细的去讲一下。
 语义。主要解决语义匹配，视频搜索存在很大的语义鸿沟，DSSM 表
征形的 sentence 级别的语义向量去做匹配，这块是会在相关性层面
去做。BERT 这一块是做知识蒸馏的方式，这块计算太复杂了，在排序
层做的。 SMT 不是在相关性和排序层面去使用的，是语义的扩展和
query 的改写，能丰富语义内容的召回。点击行为也是做一些语义层面
的改写扩展。
结合这 4 个层次的匹配，是能够把搜索基础相关性的匹配做到一个比较好的状
态。
2. 相关性数据集构建和特征体系
左图是相关数据集的构建流程，为了衡量相关性的效果，需要标注数据集。首
先要有一个标注规范，主要结合实际业务和用户需求来设定，并没有通用的标
准。数据集我们标注了 2、3 年，有几十万的数据，通过外包同学去标注，不
仅标注相关性的等级，还会对同等级的样本做偏序级的标注。我们对标注的质
量和效率比较关注，左边的方式是采用 active learning 的思想去提升标注效

率和质量，降低标注的成本。数据集也分为验证集和训练集，验证集主要针对
特定问题去构建，具有一定的针对性，对不同验证集解决完问题之后，不一定
对线上体验有正向的效果，因为它会带来对其他维度变差的情况，所以我们需
要训练集和回归集的验证。右图是我们相关性算法的主要特征，大家可以参考
下。
3. 语义匹配
我们在 2017 年上线了一个 sentence 级别的语义匹配模型，模型结构比较
通用简单，我们尝试迭代的过程比较多，具体参数是和语料相关的，不同业务
参数差别比较大。需要特别指出，语料样本的选择，对语义模型特别关键。在
日志处理过程中，没有点击的日志不能当作语义的负样本，垂直搜索引擎语义
类 query 相对还是比较少的，需要借助外部的预料做训练，这和我们集团的
一些搜索比如神马搜索，搜索日志对语义搜索效果的提升是非常大的。
表征形的语义模型，有一个好处是，doc 端的特征是可以离线计算的，可以
在相关性层面快速高效的去做语义上的计算，确保基本的语义内容能够被召
回，能够排到前面去，能够送到上层的重排序服务上，ranking service 上还
有比较多的语义内容，能够做一些精细化的语义计算。
4. 排序特征体系
排序特征体系，包括各个业务领域类的，基础匹配类的，query 统计类的。有
一些是视频平台特有的，比如说实时的动态的处于宣发周期的一些特征，对控
制节目的排序，可播性，宣发的效果是特别有帮助的；另外，内容质量的评估
对视频平台是非常重要的，优酷的人工智能部有一个非常给力的 CV 团队，
提供基于视频这种无参考质量的评价框架，能够对低层次的一些特征，比如对
比度，亮度，中等的模糊块效应的失真，并综合各种画面质量去解决 UPGC 视
频失真，模糊质量评价的难点，能够从视觉层面去理解视频，还有封面图/标
题的质量去评判，可以很好的区分好视频和差视频。
在用户层面，用户行为的表征在很多宽泛搜索里都会应用，比如用户在频道页
的搜索排序，OGC 节目宽泛意图的检索场面，用的会比较多。因为在很多通
用的搜索中，这种宽泛意图的比率比较大。
5. 表征学习
再介绍一个我们 17、18 年和达摩院一起把表征学习在视频搜索落地的方案。
上图是表征学习的模型，第一层是特征预编码的编码层，用视频元素、搜索意
图、用户，这 3 类特征去分析。在用户维度，又划分了用户 id 和用户观看视
频的序列；在搜索意图维度，有搜索的 id，搜索词的视频表达和文本编码的
表达。在视频层，包括视频统计特征、视频播放点击量、视频文本编码、视频
在整个 session 期间和其他视频的关系数据，来构建这些不同的特征域。

在第 2 层和第 3 层，这 2 个不同特征域之间的网络结构是相互独立的，通过
稀疏的编码优化能够全链接到第 1 层。可以对高维特征进行降维，把高维特征
信息投影到低维的向量空间中。第 4 层把不同域的表征信息，内部的编码，综
合到一起，形成一个综合的多模态的向量融合，再经过上面的 2 层的全链接实
现搜索用户意图和搜索视频维度的排序。
整个模型在性能优化后再计算层面是没有什么性能问题的，上线后分发效率提
高明显，分发 ts 观看时长增加。
我们在上线后同样看到了一些问题：这种单一目标的排序模型，它的优化目标
是 ts，就会忽略一些基本体验。比如，相关性约束对整个体验来说不一定在
提高用户体验，可能在头部的一些效果上，我们行为比较多的一些搜索 query
上体验是提升了，但是中长尾的一些效果上其实是比较难以保证的，所以后面
我们也是做了不同的尝试，把表征学习和其它的一些维度的排序效果相融合。
6. 多目标 Deep LTR
上图为 19 年在排序方面的一些实践，多目标的深度排序学习。这里的多目标
包括：相关性目标，rank 的 loss，entity loss。为什么有这些目标呢？我们

其实是做一个整体的目标学习，我们要确保涵盖相关性技术体验的 loss，分
发效率的排序 loss，实体匹配上的 loss。相对于表征学习的单一目标，我们
这里要实现一个端对端的多目标的。
样本标注方面要综合时长和播放完成比，如果我们按照存点击数据，很多情况
是和 ts 目标不一致的。如果只考虑视频时长，那么长视频就会被放在前面，
如果只考虑播放完成比，那么短视频就会被放在前面，因为短视频就几十秒，
很快就能播放完，长视频几十分钟，有的几个小时，不容易看完。所以我们会
综合时长和播放完成比，对时长做分段的处理，在相同时长下作横向比较，形
成一个不同时长视频的 label 分级，引导目标去学习。
这里正负样本采样比例 1:8，是通过我们不断迭代调整的结果，并没有一个通
用的方法。
▌多模态视频搜索
1. 多模态视频搜索
多模态搜索就是将语音，文字，图像等各种模态集中起来一起搜索。学术上也
有很多和多模态搜索关联的，比如实例搜索，给定一个实例图像，搜索相关的
视频片断，将视频转成文本，VTT 任务；AVS 视频搜索，输入一个文本，在
视频中搜索相关的视频。这和我们今天的主题多模态视频搜索是非常契合的，
学术界的方法也是比较多的，如把 query 和视频都映射到中间的一个维度，
一个概念空间里面，再做相似度的匹配排序；最近也有一种思想是 video bert，
采用 transformer 的思想把 video 通过端对端的解决方法，基于多模态视频
搜索技术可以有很多新的搜索体验，下面讲一些优酷的实践。
刚刚讲的学术界方法对短小视频搜索效果是比较好的，但对长视频很难做到准
确，视频很长，覆盖的范围很广，用这种表征的方式不容易覆盖那么多丰富的
内容的，所以对工业界的视频搜索，不是端对端的解决方案，现在的做法是将
视频模态信息通过降维的方式，都转换成文本的模态，对视频内容做细粒度的
内容拆解，将图像，动作，人物，声音这些背景信息，通过 CV 检测方法识
别出来，去做标签化，去完成降维。另外一种降维的方式是通过 OCR 和 ASR，
光学文本的识别和语音识别的技术将视频中的对话信息转化成文字，关键字和
主题的抽取，再去形成事件的分析和概念主题的理解。
一个完整的视频可以分出不同的片段，然后形成 shot，关键帧，关键元素，
通过对关键元素的分析，可以把动作场景人物做一些识别。举个例子，如上图，
通过人脸识别可以识别出这个片段中出现了哪些人，"周六夜现场"能检测出岳
云鹏，陈赫；"晓说"能检测出高晓松，通过 OCR/ASR 可以把视频中的对话
结构化出来，然后做一些关键词的抽取。
接下来将作更深次的讨论，如上图，从视频标题看是陶瓷，如果不做内容结构
的分析，根本不知道里面在说什么。所以要对文本进行分析理解，在分析理解
时，会有一个难点：这么多文字，需要一个完整的实体知识库，视频内容涉及
的领域非常广，包含全行业的丰富的实体。辅助我们抽取核心内容的元素，比
如"伯特格尔"是谁，是个人物，"塞夫勒"，"麦森"这些地名需要理解，以及实
体链接和实体之间的关系的推理。这个视频是介绍欧洲陶瓷发展历史的，欧洲
陶瓷是从哪里开始的，是从"塞夫勒"开始，是由"伯特格尔"这个炼金师发现出
来的，很多对话内容是通过主体引用，要理解指代的实体，上下文引用的主体
是需要识别出来的；另外一个就是实体之间的关系，比如"塞夫勒"、"麦森"是
欧洲的城市，和中国，日本是什么关系，这种实体之间的关系是需要有的，否
则对讲的什么事情是很难理解的，需要知识图谱辅助。在实体知识库的支撑下，
候选的关键字通过分类模型得到关键字分级，分成核心关键词，相关关键词，
提及的关键词，分完级之后，在相关性匹配上做的更有针对性。
2. 视频元素级知识图谱
前面是视频理解的方式，如右图视频标题是李健 -《风吹麦浪》( 春晚歌曲 )，
但是他是和孙俪一起唱的，标题里没有孙俪，用户经常搜索的内容是"孙俪李
健合唱的风吹麦浪"，我们需要通过人物识别的方式把视频中的关键人物识别
出来。在视频搜索中，需要多模态信息的辅助的，才能提高搜索准确率。左边
是"甄缳传"，通过视频元素级识别，可以把关键人物识别出来，并且可以把人
物和角色，人物和 ip 之间的关系获取出来，检索时可以将具体人物出现的关
键位置检索出来，以及台词，歌词，内容关键的一个场景的起止时间，如果用
户在搜索"甄子丹的打斗视频"，我们有相应的内容视频的聚合数据，用户可以
搜到开始打斗的起始时间的。
3. 效果案例
再举几个内容关键词在多模态视频搜索中的应用，如上图，搜索"军情解码张
召忠"，搜索结果中标蓝的这些是通过内容理解，人脸识别，多模态搜索召回
的。搜索"军武次位面虎式坦克"，通过对话理解提取出来的关键词，搜索"晓说
以色列"也是类似的。这部分在搜索所占的比率不是很大，但是触发的效果还
是非常明显的，效果提升 100%。
多模态视频搜索的应用场景是非常广泛，目前还没有做到故事级别的理解，这
块是需要继续努力的方向。
网易云音乐推荐中的用户行为序列深度建模
分享嘉宾：章莺网易云音乐资深算法工程师

编辑整理：汪方野
导读：近年来，网易云音乐作为一匹黑马迅速在移动音乐 APP 占据市场，2016
年用户量就突破了 2 亿，而这与它优质的推荐系统必不可分。网易云音乐推荐系
统致力于通过 AI 算法的落地，实现千人千面的个性化音乐推荐系统。本文将重点
介绍推荐系统在云音乐的落地实践，以及在音乐推荐系统中遇到的挑战和解决方
案。使大家了解音乐场景下的多行为域的序列建模，包括用户多兴趣点挖掘、多
空间长短期兴趣建模，以及音乐场景下的用户兴趣演化网络建模。主要内容包括：
 网易云音乐简介
 召回体系探索
 精排模型演化历程
 音乐推荐场景 AI 思考
01
网易云音乐简介
1. 关于网易云音乐
网易云音乐是专注于发现与分享的音乐产品，依托专业的音乐人、好友推荐、算
法推荐，以及社交功能，为用户打造全新的音乐生活方式。网易云音乐有一个非
常受用户喜爱的乐评社区，加深了人和人之间的联系，用户会经常分享与歌曲有
关的想法，形成了一个比较温暖的社区。另一个受用户好评的是云音乐精准推荐
功能，它有很多推荐场景供用户进行选择，可以帮助用户快速发现更多更优质的
歌曲，让我们千万的曲库，能够分发到每一个属于他的用户。同时，为了音乐产
业的发展，我们对音乐人进行了大力支持。目前我们音乐内已经入驻了 10 万+的
音乐人，每年可以产出 2 万多首原创歌曲，给音乐人创造了良好的音乐环境。
以 UGC 用户创建歌单，使云音乐打破了传统专辑歌手分类组织的方式。以歌单
为核心的播放模式，可以以社交化的分享和个性化的推荐来解决用户发现寻找音
乐的需求。19 年，推出了 MGC 的歌单形式，通过算法来动态生成各种主题的歌
单，这种全新的形式给用户带来了全新的体验。使我们可以有更多优质的歌曲在
歌单中得到有效的曝光。同时，我们还推出了 MLOG，一种图片音乐文字相结合
的产品，让音乐不仅可以听，还可以看和玩。
2. 多形式推荐场景
回到我们最关注的音乐推荐算法：在云音乐内有非常多形式的推荐场景，供用户
自行选择。
 每日推荐：以列表形式展示，该场景会比较关注用户长期的偏好，让用户
每天在这个场景中获得他喜欢的歌曲。
 私人 FM：一种流式推荐方式，能根据用户实时播放行为去分析用户对之
前对推荐歌曲的反馈，从而去影响后续要给他推荐的内容。对于那些想要
寻找一些新奇新颖歌曲的用户，这种方式会是很不错的场景。
 歌单推荐：同时对于歌单这种特有的播放形式，在首页和歌单广场上，也
会进行丰富的推荐。
3. 音乐推荐 VS 电商推荐
大家可能对电商领域的推荐系统更了解，并且有很多团队做出了比较优秀的工作。
所以，我们在音乐领域内想要完成一个推荐系统，与电商推荐系统有哪些不同？
又有哪些差异？
两种推荐系统的相同点：
 都是帮助用户去更快速的获取他们想要的资源
 都是以用户使用体验为导向
但是这里的资源在电商领域是商品，而商品具有特定的功能和用途。所以对用户
来说，有一个特定的现实作用。而对于音乐领域，一首歌曲，该怎么去理解？每
个用户对歌曲的理解是千差万别的，如何把握住用户对音乐的感受是我们非常关
注的。
其次一个非常大的不同点在于：商品是不可重复消费的。例如用户购买了一台电
视机，可能在较长的一段时间之内，用户没有电视机的需求了。但是对于音乐来
说，完全可以重复消费。比如一周之前听过的歌曲，可能今天还在听；昨天听过
的歌曲，今天还可以单曲循环；甚至一个月之前一年前的那些老歌，都能拿来反
复的进行播放。这一点就是非常大的不同。
同时，消费一首歌曲的时间成本是远高于点击商品的。可能几秒钟之内就曝光了
非常多的商品，并且可以通过浏览商品的图片查看商品的标题。用户就能在短时
间之内大致的了解到这些商品。但是歌曲就不一样，用户可能会对歌手有一定的
了解。但是在很多情况下，演唱者对用户是陌生的。只有真正的去播放这首歌曲，
甚至是需要播放到中间的副歌部分，才能真正感受到这首歌曲，对他的感觉，这
就需要 1~2 分钟的消费时间。所以很多时候，用户历史的歌曲消费行为，包含着
非常多的信息。如何把其中的关联关系挖掘出来，是我们研究的一个重点方向。
02
召回体系探索
接下来介绍下，我们在召回体系中做的一些探索和想法。
云音乐召回系统简化框架：
我们会从数据库中清洗、抽取用户行为序列，对用户进行偏好分析，对歌曲进行
理解，以及对行为训练的深度建模。我们会从多个角度来进行歌曲的召回。之前
云音乐做的部分召回算法，主要以 CF 协同过滤为主，我们在协同过滤算法中，
也做了非常多的创新和优化，并取得了显著的效果。但是我们也非常想从用户自
身行为中挖掘到隐式的信息。
问题思考：
所以在准备建立我们全新召回体系时，我们带着两个思考。
用户的兴趣点在哪里能够体现出来？用户的兴趣是单一不变的吗？
对于这两个问题，我们进行了比较多的调研和数据分析。最终，我们找到了两个
方向：
 一个是从用户的听歌记录中挖掘用户的兴趣点，就像前面说所说的音乐消
费时间成本，从听歌记录中抓住用户的偏好
 其次用户对音乐的感受是非常多样化的，并且会随着时间和用户的兴趣产
生偏移
基于这两点，为大家介绍云音乐结合音乐相关知识的一些召回算法，并且其中的
一些召回算法成功的在云音乐上线了。
1. 实时兴趣向量建模
首先介绍实时兴趣向量召回模型。这个模型大家应该比较熟悉，原型就是 youtube
提出的视频召回模型。这个模型会将用户和歌曲映射到同一个低维度的向量空间
中，计算用户和歌曲的相似值，取 top-k 作为最终的结果。这个模型首先会对性
能有个比较大的要求，因为推荐的歌曲池比较大，所以要有一个比较高效的向量
检索引擎。云音乐自研了 n-search 系统，给这些向量召回的模型提供了技术上
的支持。
在这个模型上，我们做了一些优化：
其中一个优化是使用了 self-attention 来代替原有的 average-pooling。因为在
云音乐里面，歌曲经常是以列表形式播放的，所以我们更需要关注的是列表中歌
曲之间的关系。因此，我们使用了 self-attention 的网络结构来挖掘内部间的联
系。
另一个优化是对于原有的搜索序列，我们会用点击的序列代替。因为我们最开始
发现搜索这个序列，因为有 query 先验的信息，最终召回结果会非常依赖这个序
列数据，很容易造成过拟合。所以我们转向了用户的另外一种主动形式，选择了
用户点击歌曲的序列。因为从数据上会发现经常有些用户会将音乐一直播放着，
成为一种背景音乐的形式，或者像是商场之类的公共场所，会不停地循环播放。
但是，如果用户有点击，说明当前点击的歌曲是在用户主动意识下的一个行为，
提高了置信度。
在这两点优化下，最后召回模型的效果比之前表现的会更加优异。例如，用户实
时点击并播放了一个电子歌单，我们能及时给用户召回这个电子风格的歌曲。在
模型中我们还对样本做了一些处理。比如说刚刚提到的商场播放歌曲，可以看作
一种机器人行为。网易云音乐有为数众多的用户，他们的行为会非常的活跃，所
以我们避免这些活跃的用户和机器人的行为影响最后的训练，我们会对每个用户
限制样本的数据，避免负向影响。同时，我们在用户侧引入了非常丰富的用户画
像信息，对于没有行为序列的用户，也可以触发这个召回模式，为这些用户召回
歌曲。
2. 动态多兴趣建模
动态多兴趣挖掘模型：这个模型中，会将用户的行为序列作为输入，通过信息胶
囊网络抽离出用户信息向量，也就是上图中间的网络结构。因为用户听歌记录其
实是多样丰富的。比如说用户会在早上会听一些节奏比较欢快的歌曲，下午工作
时可能会听一些舒缓的慢歌，周末可能会听一些摇滚的歌曲。所以我们需要通过
建模，把用户内部的多个兴趣点挖掘出来。如果用户行为序列并没有那么丰富的
话，可能它内部隐含的信息就相对比较少。此时，会选择动态的兴趣数，根据序
列的长度来进行自适应的选择。这个模型在训练的过程中会使用 attention 的方
式，把 target 信息利用起来。而在 serving 阶段，我们是没有 target 信息的。所
以在这里对于用户的每个用户的兴趣向量，我们都将进行 topk 的召回。这个模型
对于口味丰富的用户来说，能够训练出比较多的兴趣点，像粤语类的歌曲、英文
的摇滚，欧美电子这一类的风格。
3. 音乐知识图谱
利用知识图谱的召回。我们的知识图谱，建立了音乐数据中不同实体之间的关系。
这里面每一条知识表示主谓宾的三元组，比如说某一首歌曲是属于某张专辑的，
而这张专辑又是某一个电视剧的原声音乐，这时我们会通曲库内部和外部的信息
挖掘，逐步地把整个音乐知识图谱建立起来，可以得到不同实体之间一步两步甚
至多步的关系，比如表面上看起来可能毫不相干的两个艺人，因为这两位艺人同
时给同一个电视剧演唱的关系，就形成了一个关联关系。或者像一个综艺节目，
例如我是歌手，参与不同季的歌手也可以形成关联关系。我们可以通过用户历史
行为，关联到其他不同的实体歌曲，从而进行召回。而且音乐知识图谱中，不仅
包含了歌曲这种实体。还包含视频、MV、MLOG 这些不同实体的信息，这些对
于其他实体的推荐提供了有力的支持。
4. 长短期兴趣挖掘
长短期兴趣挖掘模型：我们基于 SDM 模型进行了非常多的改进，在原始的 SDM
模式中，会通过一个门结构来进行长短期兴趣向量的加权。但在我们真实的实践
中，发现了一个问题，我们把这个门结构中的权重打印出来，发现长期兴趣的权
重非常小，最终用户加权的向量表示基本只包含了短期的兴趣，而对长期的兴趣
影响非常小。这和我们最开始想要挖掘长期兴趣的目的是不符的。
经过非常多的尝试后，我们最终将用户的性质分为长短两个兴趣空间。在长期兴
趣空间和短期兴趣空间中，分别计算它的 loss，解决了我们最开始的问题。由于
我们建了两个空间，我们在 side information 上做了比较多的尝试，扩充了非常
多的 wide 类的特征。在整个建模过程中，我们对 feature 的输入也会进行一些优
化。用户对一首歌曲，如果是具有重复播放的偏爱，他可能是因为喜欢演唱这首
歌曲的歌手，或者喜欢这个歌曲的风格，或者语种是他非常感兴趣的。上层的信
息一直影响用户感受，所以对于长期的信息建模过程中，我们将歌曲的信息进行
了一个上浮，把歌曲的画像进行了详细的建模。这个模型，也是融入了云音乐算
法团队很多的思考和对音乐本身的理解，最后有效的权衡了音乐传感器的兴趣。
5. 为什么需要多路融合召回？
除了以上介绍的召回模型，我们还有非常多的其他的召回方式。为什么音乐推荐
需要多路融合召回？答案是我们算法对音乐的理解，因为音乐的本质是情感的寄
托。可能这句话会比较抽象，从歌曲和用户两个角度来具体解释下：
歌曲会有非常多的标签，像常见的语种、风格，就有非常多的类别。而场景情感
主题这些标签，是基于用户对这些歌曲的感受来分类的。而且同一首歌不同的用
户也会听出不一样的感受，所以这就需要我们将歌曲的不同维度、用户的偏好来
进行充分挖掘，精准的找到用户喜欢这首歌的点在哪。然后我们也可以从歌曲的
评论区中，发现很多用户评论表达的一些情感，比如这里有用户说："这首歌曲他
听了非常多年，还是一直很喜欢"。所以说用户的情感是一直存在的，算法要做的
就是对这些情感进行唤起，来加强用户对于情感的表达。
03
精排模型演化历程
下面分享云音乐在精排系统中关于用户行为序列的一些深度建模经验：
行为链路：
在具体介绍精排模型之前，简单介绍下用户在云音乐中的行为链路。我们以每日
推荐场景来做具体的介绍。用户进入日推，首先歌曲会得到曝光。用户可能会点
击某些歌曲，也可能直接进行了播放。在播放的过程中或者结束时，用户会进行
显隐式的反馈。比如进行收藏行为或者是切歌的行为，甚至可以将歌曲标注为不
感兴趣，当然也可以什么都不做，继续播放下一首。在用户整个行为里面，可以
看到收藏、点击、完整播放，这些 action 是属于用户正向的反馈；而曝光不播放
或者是曝光时间非常短，不感兴趣的，都是一些负反馈。对用户这些行为进行累
积，我们可以对他之前的语种偏好、风格偏好、艺人、年代热度等等，进行重新
调整，从而更好的进行下一次推荐。
云音乐精排模型迭代历程：
云音乐精排模型的迭代历程，时间跨度比较久。最开始从最简单的线性模型开始，
有比较强的解释性，并且符合当时快速迭代的需求。但是它的缺点还是比较明显
的：表达能力非常有限。所以在此基础上我们逐渐在这个方向进行优化。对于模
型的拟合能力，希望有更进一步的加强。在后期，也逐渐的引入了外部的特征，
我们做了比较多的特征交叉，使我们的特征维度达到了很高的级别。最后，利用
参数服务器成功将 FTRL 模型在云音乐中得到了一个上限，模型记忆类的特征使
得整个模型的刻画能力得到了非常大的加强，但因为特征维度过大，计算的复杂
度很高，逐渐向深度神经网络进行发展。全连接网络和一些 cross 的操作使得模
型的表达能力变得更强。我们慢慢将用户的行为序列考虑了进来，学习用户行为
序列中隐藏的关系。
整个过程中，也是我们对业务理解逐渐加深的过程，所以模型也会复杂化。后面
要分享的是我们在深度时序网络阶段中，结合用户相关的行为数据，做的一些创
新和优化。
1. 用户行为序列建模
首先尝试的是深度兴趣网络模型，这个模型和之前所尝试的模型，一个比较大的
突破，是在用户行为序列数据上的处理。之前会将用户序列行为的 embedding
向量进行 sum pooling 操作。这种压缩方式，会造成一些程度上的信息丢失。对
于相当重要的 embedding 向量，可能就没有办法完全突出自己的信息。所以我
们在建模的过程中引入了 attention 机制，attention 机制的本质可以认为是一个
加强的求和，可以让模型更加关注到它认为有用的信息，着重的影响本次推荐的
行为。每一首在行为序列中的歌曲，我们也会刻画的比较丰富。对于歌曲画像，
我们会包含歌曲的 embedding 向量、风格、语种、艺人信息、专辑信息等等。
丰富的歌曲画像，可以让模型更好的关注到用户本次点击的兴趣点在哪里。
2. 用户兴趣演化模型
在做推荐系统的过程中，很容易体会到一个现象，就是用户越新的行为，能够反
映用户当时的兴趣，对于推测之后的行为发挥的作用也是越大的；旧的行为发挥
的作用就相对弱一些，这说明用户的兴趣是在不断变化的。特别是在音乐中，外
界的流行趋势会发生非常大的改变。可能在几年内，甚至是几个月内流行的方向，
就发生一次非常大的改变。同时，用户自身的兴趣，也会发生变化。所以我们在
模型中，如何捕捉用户兴趣的演化路线？于是有了用户兴趣演化模型：
我们将 attention 机制继续延用了下来，并且加入了 ARGRU 网络结构。两者相结
合，既保留了原先的注意力机制，又能捕获用户歌曲兴趣发展的路径。在这里我
们使用的序列，是用户实时完整播放的序列。他使用了一个实时数据，所以在线
上预测时，我们可以对用户实时的行为得到快速反馈。另外，我们在做播放序列
长度时，也进行了一些探索。很明显，如果播放序列越多，包含的行为也就越多。
但是过长的数据，在实训模型中容易造成梯度消失问题，如何将更多行为融入进
来，是我们接下来要思考的一个方向。
3. 基于会话的多行为域模型
前面的学习建模过程中，我们使用的都是用户整体的行为训练，忽略了序列内部
的机构。用户的行为序列是由多个会话组成的。然而往往用户会话序列内部，性
质偏移比较小，目的性会比较一致。但是在会话之间有着比较明显的差异，所以
我们会进行 session 划分。我们可以得到用户 session 内部的投入行为以及
session 之间的递归行为。这样的划分，从序列演化到 session，可以关注到更长
远的行为数据。在音乐场景，我们对 session 的划分，主要分为两个点：
 一个是因为音乐它有非常多的推荐场景，每一个推荐场景使用目的都是有
差别的。用户选择不同的场景，都是基于用户主动意识，所以我们通过场
景就可以将序列进行一个初步的划分
 其次，听歌过程中，用户会有一定的疲劳感。如果时间过长的话用户的注
意力可能就不会那么集中，所以我们对 session 的最大时长做了切割
这两点是我们对 section 数据的处理。
我们在模型中做了更大的尝试，考虑了用户更多行为域的行为模式。之前我们所
使用的用户行为都是完整的播放歌曲序列，在这里我们加入了一个红星收藏序列
和跳过序列。为什么我们要将用户不同的行为序列考虑进来。我们观察播放的整
个详情页，里面有很多的控件，比如收藏按钮，表示用户将歌曲加入红心收藏歌
单中，这是用户非常强烈的行为。同样下载歌曲或者分享，都是明显的正向行为。
对于评论信息，我们要具体分析评论的内容，利用 NLP 技术进行情感分析，去判
断用户真正情感。如果用户对这首歌曲标了不感兴趣，甚至是拉黑了歌曲或者艺
人，那么这就是显著的负向行为。还有比较隐蔽的负向行为，就是用户在播放的
过程中进行切割操作，这是一个没有消费完全的状态，对用户来说是不好的体验。
所以我们会通过对用户行为的不断扩充，把用户正向和负向的行为，进行完整的
刻画。
4. 再说音乐推荐 VS 电商推荐
回到最开始我们提到的，两个推荐系统的差异。这些问题，其实在刚刚介绍召回
和精排系统中有提到。对于音乐资源我们会从各种维度进行偏好的分析，建立一
个比较完善的歌曲画像。同时，虽然这次分享没有提到，但是云音乐也利用了 NLP、
图像、音频等技术，从内容上去理解歌曲本身。对于是否可以重复消费这个问题
上，我们会关注用户长期的兴趣偏好，达到长短期用户兴趣的动态平衡。对于用
户的行为序列，进行显隐式的拆解，刻画用户真正的行为意图。对于长短期兴趣
和用户行为确认这两个方向，还是有很多的发展空间的，这也是之后我们需要继
续努力的研究方向。
04
音乐推荐场景 AI 思考
最后分享下在音乐推荐场景下对于 AI 算法的思考。音乐是反映人类现实生活中，
一种情感的艺术；AI 是一个理性的产品，它为人们提供便利的生活。理性和感性
的结合，并不是相互抵消的过程，反而能发挥出更大的效果。我们认为健康良性
的音乐系统 ( 如图所示 )，通过 AI 技术，可以帮助用户去发现更多感兴趣的音
乐，让用户能够沉浸在音乐带给他的快乐当中。更多用户的使用行为可以帮助我
们挖掘更多长尾歌曲，挖掘那些小众但是优质的音乐，使优质的歌曲都能得到合
理的分发。我们的推荐歌曲池也会变得更多更好，可以更好地服务给用户。以上，
就是我们的网易云音乐推荐团队对 AI 和音乐的理解。
推荐系统解构
分享嘉宾：姚凯飞观变科技 CEO
编辑整理：陈家辉
导读：由于移动互联网时代用户每时每刻都会产生海量信息，伴随着大数据技术
的快速发展，使得企业能够迎合用户的痛点，分析用户喜好，进行商品推荐。推
荐系统诞生的益处：从用户角度，推荐系统可以缓解信息过载带来的时间成本；
从企业角度，可以帮助企业进行精准营销，解决长尾营销，最大化收益。因此推
荐系统的好坏对于互联网企业来说至关重要。
本次分享主要是以电商平台为例，从以下几个方面对推荐系统进行解构：
01
推荐概述
1. 工作思路
对于电商平台来讲，一套完整的电商流程应该包含以下完整流程：
推荐系统作为电商平台的一个子系统，其价值体现在商品与用户的匹配上，而匹
配的效率与质量对于电商平台至关重要。
2. 推荐系统面临的挑战
多场景、多目标、考虑生态、场景间目标的差异
电商推荐系统的优化往往是多目标的，这个体现在场景和优化时效维度；在不同
场景间，推荐系统的目标侧重点也是不一样的，比如有的目标是提高用户在页面
的停留时间，有的是提高用户短时间内的消费，比如猜你喜欢、购物车、商品详
情页的推荐坑位。而从优化的时效维度来看，比如从短期来讲，目标有点击率、
转化率和客单价等，从长期来讲，目标需要考虑留存、复购等指标。不仅如此，
电商平台需要兼顾用户、商家、平台三者的利益，构建长期健康的生态。由于电
商业务的购物链路较长，往往用户需要先浏览、点击、加购、下单、支付、履约
配送、收货、评价/退货等环节构成，所以推荐系统往往需要将各个环节纳入其中。
当然在其它业务类型的推荐系统中，也存在着链路长的挑战。如招聘行业的推荐
系统，给候选人推荐合适工作只是第一步，后面还会伴随着长时间的简历投递，
招聘人员的审核和邀请，参加面试，最终入职或者进行下一家的应聘。社交场景
也类似，这种推荐系统存在这双向匹配，比电商平台的单项匹配链路更长，挑战
也更大。
数据闭环
对于电商企业来说，数据是核心，是驱动业务迭代的关键点，从用户、商品、商
家维度，需要持续积累和采集。从用户的角度，存在浏览、点击、成交、评价、
物流全链路闭环数据。从商品角度，有潜力、新品、老品、衰落、下架等信息。
从商家角度，也有价值、非价值和灰黑商家等。
3. 推荐系统中的关键因素建模
我们以电商推荐场景为例，用户的行为旅程包括浏览、点击、加购、购买以及长
期的复购行为，大致可以由下图表示：
推荐系统首先需要在点击（也即流量的转化）这一环节进行建模，引导用户进入
商品详情页，同时对详情页的加购/购买建模，依次引导后续行为。
另一个角度，从上面 PPT 下半部分的公式出发，产品运营可以被结构为以上三个
模块，流量、转化、x 因素(回访、复购)等；长期来讲， X 因素非常关键，即复
购回访的长期价值，只有长期生命周期价值高才能给企业带来持久收益(n 为时间
/天，x 的少许增长可以带来长期巨大复利)。
结合上述用户旅程和公式拆解，如果想将 V 做大，自然的，我们需要构建转化率-
访购率-毛 GMV-净 GMV-留存率-复购等关键节点的建模，并且这个也是推荐系
统的观测指标。
在系统更大维度，我们需要关注长短期收益、用户/商家个体满意度和总体满意度
以及兴趣探索成本、流量效率与商品/商家成长等维度。
02
推荐系统拆解
1. 基本架构
我这里拿一个前几年我刚开始入门推荐系统时候的架构：
最开始的阶段是召回过程，分为多个模块；实时模块会拿到用户实时的信息，比
如用户实时点击、收藏、加购的商品，并获取这些商品的相似商品；历史模块会
获取用户的历史信息，如历史的购买行为；画像模块则会获取用户的静态信息和
偏好标签，如用户的设备型号、年龄、性别、类目偏好等；最后还会包括现在以
及过去的热门商品等。
在经过这些召回的过程后，我们会进行一层过滤。比如曝光过滤，即某个类目已
经曝光了一定次数，但是用户都没有点击，隐式表明用户不感兴趣。还有用户购
买过滤，即已经购买过的短期内不再推荐。同时还有购买率过滤、性别过滤等等。
经过过滤阶段后，我们可以对过滤后的商品进行一定的预估。如点击率、转化率
预估等。同时可以考虑单价，多样性以及新品率等影响进行排序。随后我们可以
通过规则或者模型，将这些粗排后的物品统一得分进行融合，最后再经过精排阶
段给出最终得分，这个阶段还会增加一些业务规则进行强控，比如考虑多样性的
打散、出于运营需求的置顶等。
上述是大致推荐系统的简单介绍，不同的业务和团队，在构建过程中也存在模块
的差异，推荐系统没有特别强的标准存在。
2. 召回策略
主要策略包括：
① 实时行为召回：在线实时捕捉用户对商品的点击，收藏，加购，购买等反馈行
为，并召回相似商品，迅速抓住用户的短期购物需求。
② 历史行为召回：离线分析用户对商品的历史点击，收藏，加购，购买等反馈行
为，并召回相似商品，兼顾用户的长期购物需求。
③ profile 召回：从性别，年龄段，设备等多个维度，在线和离线同时对用户进行
画像，并召回相对应的热门商品。不要小看这个召回，非常关键，往往新用户需
要用这些静态信息和标签来做召回，往往可以快速圈定其圈层进行精准的探索和
数据反馈，比如 5-6 线城市和北京西二旗的用户往往大概率兴趣差异较大。这层
召回是全局热门召回的更精细化拆解。
④ 热销&趋势召回：分析商品的长期和短期销量变化，召回爆款和近期热点商品。
 召回模块特别重要，因为召回的来源/相似分可以作为排序特征(推荐日志
落盘-回看/溯源机制)
 召回作为漏斗的顶部，好坏对漏斗底部(排序)的影响很大。
3. 排序策略
排序阶段的影响因子较多，可以作为特征，也可以独立在外作为排序因子存在。
比如以下的一些因子：Ctr Cvr Price、Ctr Ts、Match Score、Trigger score time
decay、Match type ctr cvr、Match type score、...
当然针对不同的产品有不同的侧重点，比如电商的内容差异较大，甚至同是内容
也会因为产品形态存在差异，比如快手的双列可以考虑点击率建模，而抖音单列
下滑不需要考虑点击率建模。甚至还需要考虑多样性，惊喜性，新颖性等更多的
指标。并且建模过程可以尝试 end2end 或单独建模的方式，这里面需要考虑的是
稀疏性、正负比例、预估不准等问题。
如果一个指标不够，还可以考虑多个指标的结合，形成新的指标。如电商场景下，
gmv 这个指标，可以用 CTR α *CVR β *Price γ 代表 gmv，那为什么还需要α、β、
γ呢？因为如果 ctr 和 cvr 估计是准确的， α、β、γ均为 1 的排序公式是可解释
的，你把这几个指标的分子分母拆开就看到了，相乘以后就是 gmv。但是由于模
型各自的准确率差异，导致了我们需要学习这几个参数，理论上建模越准确的指
标系数越大。而这三个系数如果相对稳定可以通过离线统一参数学习的情况完成；
如果不稳定，可通过强化学习来解决这个超参的设定。
可参看下图的电商场景建模的相关排序因子，当然部分因子作为特征可纳入排序
模型。
4. 排序阶段还有一些常见的原则
① 针对不同的召回策略，主要秉持“短期行为优先，兼顾长期行为”，“保证多
样性，避免过度个性化”原则。算法上主要通过长短期用户行为密度建模，正负
反馈反向调节等手段来实现。
② 不同排序因子(商家质量/分发宽度及强度等等)可共用一套底层表征。
③ 覆盖率：通过类目，品牌，频道，场景等多粒度的打散重排，最大化各个维度
的个性化覆盖率。
④ 疲劳度：通过引入一定的随机因子，针对不同个性化程度，建立合理的轮转机
制，保证一定的新颖性。
⑤ 转化能力：通过对用户，商品，会场等多维度采集特征数据，训练点击转化和
交易转化模型。大促期间根据不同的阶段，采取差异化的处理策略。比如预热期
强化点击转化，正式售卖期则强调交易转化。
5. 更加精细化的排序
① 考虑到召回和排序的压力，可以再精排和召回中间加一层，少量核心特征+简
单模型进行粗排。
② 多过程建模：如直接购买还是收藏比价使用模型判断。举个例子，在购物车推
荐中，用模型来操控推荐策略。在购物的流程中，通过数据分析可以发现，有一
部分用户是希望通过加入购物车来进行比价，还有一部分用户加入购物车是直接
购买。通过模型来判断用户的行为，比如用户一直添加同类目的商品，那么比价
的概率就高一些。如果判断出用户是直接购买，那么就尽量推荐相关商品，如果
是比价用户，就推荐相似物品。
③ 粗粒度召回：离线产出不同类目下的精品数据，作为召回补充和兜底
④ E&E 探索解决低置信度预估模型问题
6. 模型演进
模型的演进路线可以由下图表示：
而模型的时效性也从天级别，慢慢演化成小时（一天几次），再演化成近实时级
别，而目前主流的推荐系统都是实时级别。
目前模型的演进已经进入到深度学习时代，各个大厂提出的新的深度学习架构也
层出不穷：
这里不对于模型具体结构过过多展开，主要趋势就是通过时序、行为特征的使用，
通过 embedding、LSTM、attention、tansformor 等结构提取特征信息，拟合
用户兴趣，提高预测精度。
7. 特征构建
这里主要解构一下电商推荐系统中特征的构建方式：
初级的方式，一般大家会对用户和商品进行一些用户画像，然后作为特征加入模
型。但是长期来看，匹配类的特征非常重要，比如待排序的商品和用户历史行为
的一个关系，上面提到的模型中，DIN 和 DIEN 都很好的使用了这种行为序列。
匹配特征一般是与点击特征结合在一起的，比如用户对于某个商品的点击，对于
某个类别的点击，某类用户对于商品的点击等等。可以总结为下图：
8. 评估方式
针对于召回的评估方式，绝大部分都是通过命中率、准确率、覆盖率、F1-score
等方式评估，参考下图：
但是因为推荐系统是串联的，我们往往需要考虑到前置模块对后置模块的影响，
比如召回对于排序的影响，下图是 LinkedIn 的方式。

03
系统&全局生态
1. 推荐功能决策链路
做一个推荐功能之前，我们需要对这个产品功能的作用进行一定的决策，如：
 推荐功能对该产品有无价值 ( 可以 )
 价值多大 ( 值得 )
 成本和收益 ( 现在 )
 优先级 ( 怎样 )
同时还要对推荐功能的工程上的要求进行决策，如推荐系统的实时性做到毫秒级
是否有必要。是否是毫秒级，应该以用户的使用习惯来决定，如 80%的用户其实
都是秒级需求，没有必要做到毫秒级的响应。
2. 场景串联与用户旅程
不同的场景需要兼顾业务定位，进行场景间差异化。场景单独优化时往往召回、
排序策略会趋同，带来局部增益与全局增益最优的冲突，解法往往是产品业务层
的干预与算法场景通信两种手段。
3. 方向&外围
从系统和生态全局来看，建设推荐系统既要考虑短期的 gmv 等指标，更要考虑长
期的发展 ( 回访、复购、netGMV ) 。因此需要从更多的层面考虑推荐系统的建
设，如：
① 供应商、seller 等级建设，流量分配，运营机制。对于高登记的 seller 需要有
更好的流量，但是对于等级较低的 seller,也应该分配流量，帮助其提高等级。
② 商品理解&建设: 良好的后备力量。每个商品都有生命周期，虽然可能旧款的
商品质量很高，但是我们在推荐的时候也要对新品进行流量分配，进行新品测试、
流量扶持。
③ 智能投放: 低延时、高效率展现。在考虑商品的流量分配时，还需要对用户的
意图、兴趣、负反馈、视觉窄化进行考虑，不能不顾用户的体验。
④ 生态多目标，包括用户体验，如回访、活跃度、复购率、分群倾斜等，也包括
商家层级、价值、收益、良性竞争等目标，同时还需兼顾平台收益。在增长过程
中，一定需要兼顾上述若干指标，若置之不理，则最终用户、商家都会流失，最
终让产品僵化。
4. 生态多目标
从推荐系统的构建之初，我们就需要从以下角度去关注系统，设定合理的目标和
观测指标。不能什么都是先污染后治理，两眼一抹黑。在增长过程中，一定需要
兼顾上述若干指标，若置之不理，则最终用户、商家都会流失，最终使产品僵化。
从用户体验角度，我们需要关注回访、活跃度、复购率、分群倾斜等；从商家角
度，需要考虑商家层级、价值、收益、良性竞争；最后我们还需要关注平台收益。
04
话题探讨
下面我们在逐个结合业务展开一些相关探讨，这些探讨想要让大家了解到推荐系
统构建过程中，对业务拆解的重要性。
1. 分群
根据用户的活跃度及行为密度进行分群，并对分群后的用户投放对应的热销进行
兜底补足，或者作为主召回源。其中用户行为较多（交互过的物料个数和品类/
主题较多）时，作为兜底召回做补足；而部分用户行为过少(新用户或刚进入 APP
行为数较少的)，可以作为主召回策略，这时候可以做更精细化地数据集。
比如针对国家/地区、性别、设备这些新用户也可收集的静态标签分别做热销数据；
比如印度、男性、IOS 的用户 A 和印度、女性、Android 用户 B，使用的热销列

表是不一样的。其实其它分群策略也非常有用，比如购买力分群、兴趣分群；群
体对类目的强偏好和弱偏好均可以在推荐中使用。强偏好基本就是喜欢看、喜欢
买什么品类就具有这类偏好；弱偏好就是某类人群从来不会交互或者交互过低的
类目，利用统计概率进行显著性检验，可以挑出群体显著不关心的品类，在推荐
过程中少推荐或不推荐。
2. 电商同店铺用户行为
 做一下分析，看一下进入店铺页的用户后续的行为，可以酌情加重同店铺
商品 trigger 的权重（实时获取），往往很多店铺有包邮门槛，这时候同店
铺召回是满足包邮诉求。
 同店 x2i(i2i、c2i、b2i 等)可以做一个很好的实时上下文强化，这里 trigger
数量和召回数量都需要进行控制。
 考虑在 rank 的时候对每个召回源和召回分数进行埋点，在训练模型是考虑
进行，这样就可以进行很好的多召回源融合，当然这个不是同店的情形也
可以用。
3. 购物车推荐策略
在购物车场景，通过数据分析你会发现用户加购商品基本有 2 种用户，一种是对
比，另一种是马上要买了再凑个单。这时候引入意图建模，通过实时的数据收集，
对于用户加入购物车的商品进行意图预测，然后在 i2i 召回策略中使用不同的召回
控制，比如召回相似和相关搭配。
这里推荐的策略可以考虑用加权融合的方式，对于相似和相关搭配召回源，根据
预测的意图强弱进行比例调整；如果有埋点支持，还可以结合实时埋点，在排序
层考虑上述融合。
05
总结
需要明确的是，业务效果好的并不一定是复杂算法, 建立推荐系统需要遵循“假
设->分析->策略->效果”的流程。在出现的 badcase 中，需要回顾案发现场，
在产品增加埋点，跟着数据走(实时) 。迭代模型需要跟着业务走，在 badcase
中发现新的思路。系统化地思考全局收益、场景串联、局部与全局最优的情况。
最重要的是合理的指标，从健康生态系统的定义出发。以上就是此次分享的主要
内容，谢谢大家阅读。
推荐系统架构治理
分享嘉宾：李瀚第四范式架构师

编辑整理：马瑶
出品平台：第四范式天枢、DataFunTalk
导读：在数字化革命和 AI 赋能的大背景下，推荐场景逻辑越来越复杂，推荐细分
场景越来越丰富，对业务迭代和效果优化的效率有了更高的要求。推荐系统业务
和技术在传统架构支撑下自然堆砌，变得越来越臃肿，开发维护困难，推荐系统
在应用架构上正面临新的挑战。本文就第四范式在智能推荐系统架构方面的探索
实践，聊一聊在应用架构治理方面提升推荐服务开发维护效率，增强系统灵活性
和扩展性的新探索。重点探讨在开发推荐系统乃至智能系统领域时遇到的问题，
解决方法及未来的发展趋势。主要内容包括：
 推荐系统业务现状、趋势及挑战
 "治理"的指导思想
 Flowengine 架构
 应用 Flowengine 后推荐的架构
 实例演示
01
推荐系统业务现状，趋势及挑战
1. 推荐系统业务现状
从图中我们可以看出，推荐系统大体可以分为三个阶段，最初的探索阶段，早在
2010 年左右，已经有了千人千面的说法，现在我们在学习推荐系统时，看一些
文档或者资料，大都会拿亚马逊基于协同过滤的推荐、豆瓣基于标签的推荐系统
做介绍，它们都是早期推荐系统应用在工业界的代表。到了第二阶段 ( 普及深入
阶段 )，淘宝、京东以及一些垂直行业开始大范围尝试个性化推荐，此时，工程
架构，算法策略层面都有了一些新的发展，比如一些大型推荐系统已经开始向实
时特征，实时模型方向进行探索，以提升时效性，从而达到更好的推荐效果。到
了第三个阶段 ( 规模化精细化阶段 )，进入移动互联网时代，推荐已经不仅限于

PC 端的单一场景推荐，出现了移动端及多场景的推荐需求。现今，从拼多多、快
手、抖音的推荐，再到百度、头条的信息流推荐，推荐系统已经成为一个网站的
灵魂，驱动着各种各样的业务场景，在这一阶段，智能化，工程化，标准化，注
重开发效率和成本已成了技术探索的新方向。总体看来，推荐系统的发展趋势是
一个从无到有，从有到精的过程，不管是工程，算法或者场景业务都有了深入的
发展。
2. 业务趋势
推荐系统从业务方面来说，呈现四个趋势：
① 场景更丰富：早期做推荐的时候，推荐的开发门槛和成本很高，一个网站集中
精力维护好一个场景，那时最经典的场景可能就是主页下方的"猜你喜欢"。到了
现在，多端，多个资源位，更多的细分场景都会有推荐需求。举个例子，从进入
页面的"猜你喜欢"，导航九宫格的推荐，再到列表页或下单页的"看了又看"，"买
了又买"，乃至在一个资源位上多个时段都有个性化的需求。在技术层面上，过去
一个系统支撑一个场景或者一种模式，或者为了简单，一个架构，一个数据流，
一个模型勉强应付多个场景，已无法满足业务精细化运作的需要。现在，一个推
荐系统需要支持很多的场景，不同的场景也需要有不同的数据流，业务逻辑，模
型来深入刻画；另一方面，早期做推荐系统是一个门槛很高的事情，对工程、算
法的要求比较高，且业务逻辑高度定制，很难标准化、低门槛的开发，而现在随
着场景越来越丰富，推荐需求的旺盛增加，原来的工作模式已不能满足需要，推
荐场景开发需要向灵活化，标准化，规模化发展。
② 运营更精细：从简单规则 ( 比如像置顶，置底，黑白名单过滤 ) 向复杂规则
转变，通用规则向个性化规则转变；技术主导变为技术+业务联营。推荐系统的效
果好坏不再全是技术主导，业务也利用内容物料，规则玩法等运营手段发挥重要
的作用。
③ 服务更实时：早期推荐模型都是基于历史数据采用离线批量的方式构建，离线
的特征，离线的模型，导致系统时效性差，用户实时或近实时行为的影响无法体
现在推荐的结果中，用户体验不好。让用户能够更快感受到变化，批量非实时向
流式实时闭环推荐发展是推荐效果提升的必然趋势。
④ 未来的重要趋势：系统更智能，更知心。早期的一些简单算法或者规则，被更
丰富，更复杂的 AI 算法所替代。推荐系统与 AI 结合的越来越紧密。推荐系统已
经成为 AI 赋能的重要场景之一，如何构建一套对 AI 友好的推荐系统，在技术上
也是一个很大挑战。
3. 带来的技术挑战
① 当前推荐系统的基本架构
在前面所讲的业务大趋势下，推荐系统技术层面正面临一些挑战。我们先了解一
下当前推荐系统的基本架构，一般分为五个板块：
 数据流：推荐系统的特点就是高度和数据流相关，那么技术层面要解决数
据怎么来，数据怎么用，数据怎么加工处理，正确性和时效性如何保证等
问题。
 离线板块：系统内涉及到一些数据加工，任务处理，模型生产，指标报表
等离线任务，怎么协调这些任务有序高效进行，并获得正确有效的结果。
 在线板块：推荐系统对外提供实时推荐的能力，涉及到诸多的在线处理过
程和规则。如何在适应业务快速变化的同时保证可用性和性能是至关重要
的。
 AI：当下推荐系统的重要组成部分，其包含整个 AI 模型生成到服务的全生
命周期。如何从系统层面支撑 AI 全生命周期以及如何有机集成进系统是一
个挑战。
 基础设施：推荐系统是一个多领域交叉的综合应用，需要有众多的中间件、
基础组件做支撑，如何管理和运维，减少依赖，有效利用是一个重要的命
题。
上面说的五大板块，对照起来实际上就是这张示意图。虚线框是数据流，蓝色框
是离线部分，黄色框是在线部分，绿色的是基础组件。相较于简化的示意图，在
实际系统中，会变得更加复杂。比如就日志或数据收集这一部分，日志就可能因
为来源，收集方式多样，导致开发，维护和管理的复杂度激增。各家公司的推荐
系统涉及到大量的应用服务和中间件，它们的技术选型，实现方式，部署方式并
不完全一致，但是整体逻辑结构却是可以映射到刚才提到的五个板块内。但是这
样的架构存在什么问题呢？我们可以结合四个趋势来看，如果只针对性的支撑一
个场景，这样是可以的，但是当场景变得更多，更精细，问题便出现了。比如"
猜你喜欢"，"看了又看"，召回物料可能不一样，召回的算法逻辑可能不一样，精
排模型可能不同，甚至整个处理流程也可能不一样，而它们却在一个代码模块中，
各场景的逻辑必然会形成耦合，互相影响，继而影响系统稳定性。另一方面，因
为板块割裂，很多领域逻辑分散在服务或中间件中，比如数据处理一般采用
Azkaban/Airflow 一类的中间件系统去调度处理任务，这就不可避免的将业务逻
辑用大量的胶水代码封装在中间件系统中，如果一个开发者想要了解一个推荐系
统的业务流程，就会变得非常困难。随着业务的不断发展，这一现象会加剧，大
量的场景规则，服务，运营策略，算法模型越来越多，最终导致系统难以维护，
变成谁都不敢动的“老古董”。
② 当前推荐系统面临的技术挑战
我简单的总结了一下，主要有四方面的挑战。
a. 开发运维部署迁移困难，曲线陡峭，效率低下。因为推荐系统等智能系统，都
涉及到大量的基础组件和服务，各有特点，缺乏一体化的管理运维手段，如何把
完整系统搭起来并管理，期间中间件或者服务出问题，都可能会导致系统不可用。
这对于没有丰富的组件维护经验或者人力不足的团队来讲，是一个巨大挑战。
b. 这实际上是一个应用治理的问题，服务，流程，规则，策略，数据，产物繁多，
组织管理困难。图中任何一个框是一种服务，也可能是若干个服务，这些服务之
间的依赖不直观，很难管理。数据流逻辑繁琐复杂，系统有很多的离线数据流，
在线的数据流，还会产生大量数据产物，缺乏标准化的管理，极易出错。不同场
景的差异化难以组织，不同的服务，策略间相互影响，其中一个可能表现就是在
一个服务模块代码中因为要处理不同场景的逻辑而产生大量 if 分支逻辑。从架构
上讲，一个好的场景服务应该是纵向切分的，不同的场景是不同的系统，场景间
互相隔离，但这又会导致系统资源浪费，管理上面也很麻烦。因此，需要采取更
加系统化的方法去治理它。
c. 系统涉及到数据/在线/离线/AI 各个领域，技术栈割裂，整个推荐流程需要大
量的胶水代码来整合集成。而胶水代码的一个特点就是难以复用，不同人之间也
难以维护。这样的割裂突出表现在以下三点：
 众多领域技术，彼此割裂，难以集成
 数据质量难以保证，效果也无法保证
 定制性胶水代码驱动，无法复用，迁移
d. 大量重复程序化工作难以避免。在面临支持多个场景的情况下，表现很突出。
落地一个新的场景，可能需要各个系统配合开发，部署，而且这个过程是高度重
复和繁琐的，最终导致成本很高。这也是现在大一点的公司，为了效率和标准化，
开始推动推荐系统中台化建设的一个原因，其目的是能够在一个平台上低成本的
完成场景的快速开发和应用。
上述这些问题的表现都可以用一个字来总结，那就是"乱"。
4. 如何戡"乱"
那么我来讲一讲如何戡乱，首先我们深入分析一下乱的原因。
① "乱"的原因：
a. 智能系统特有的复杂性，涉及到庞大的服务依赖，数据依赖，知识依赖。推荐
系统涉及到的服务模块很多，而一个服务又涉及多个依赖，整个服务的依赖关系
就会很复杂，从而管理上就需要很大的成本。数据依赖层面，系统涉及到大量的
原始摄取数据，中间加工数据，以及最终的结果服务数据，数据的质量对最终的
推荐效果影响是至关重要的，而这种依赖又非常的隐含，极易出错还难以排查。
最后，特别提出"知识依赖"这一概念，推荐系统一直以来在应用系统中以其技术
复杂性著称，其在工程上，策略上，数据处理上，算法模型上，有很多模式经验
及潜在技能门槛。但这些知识在系统中是隐性的，存在于架构师、专家的脑袋里
面，并没有固化和沉淀到系统内。强依赖架构师凭借自己的认知和经验去构建，
驱动整个系统流程。而正是因为是人来主导，那自然会随着人的水平的高低以及
偏好，产生实现上的差异，难以沉淀和继承，后期持续演化也会很脆弱。
b. 领域架构缺失现有的框架都在解决局部问题，需要抽象出一层专门解决推荐
场景应用开发领域自身的问题。比如 Airflow 是做离线任务调度领域的平台工具，
Flink 是做数据处理领域相关的框架，这两者都是各自领域很优秀的框架或平台，
但是要解决推荐领域的问题，他们都只能解决其中部分子领域问题，缺失一个面
向推荐领域的一体化平台或框架，其结果就是从业务问题直接穿透到子领域层，
在实现上，缺乏抽象和隔离，使用胶水代码将下层服务拼接在一起完成逻辑实现。
虽然子领域框架能够解决了一些局部问题，但它们之间如何协同，管理，以及在
其之上更有序的解决推荐领域层面的业务问题成为了如何让架构更好服务场景业
务的关键。所谓戡乱，就是需要形成一个中间推荐场景开发的领域层，承接服务
依赖，数据依赖，知识依赖，并协调子领域服务更有效工作。
② 这一层应当如何做？
a. 统一的场景开发和管理接口。对于上层来讲，开发一个"看了又看"，"买了又买
"等不同的场景，开发过程和接口应该是相似的，只需要面向这一层开发，无需关
注下层细节。
b. 统一的底层架构和集成标准。下层非常复杂，涉及到众多子领域，作为开发者，
常常在选型和集成上犯难，也无法将它们协调起来，那么我们需要这一层能够把
复杂度给屏蔽掉，开发者面对的是统一的数据结构和接口规范，而无需关注具体
的执行层选型和实现。
c. 领域内要素治理：
 合适粒度的领域实体抽象及实现。在推荐服务中，有大大小小的服务，规
则，策略及数据，我们称之为领域资源要素，它们需要有合适的领域抽象
和粒度，粒度不能太大，也不能太小。是一个规则那么我们就用规则去承
载，如果是一个服务，那么我们就应该用一个服务来承载。这样能够在提
供灵活性的同时，控制整体复杂性
 统一灵活的管理方式。我们需要针对领域要素有统一灵活的管理方式，领
域的业务逻辑通过统一的编排管理方式来构建。
 成熟可复用的单元。资源要素的载体是成熟可复用的单元，组件、策略等
避免重新开发，产生重复的成本，应该通过复用让使用者更低成本使用。
有几个指导思想，来指导我们具体应该如何将这一层做好。
02
推荐系统"治理"的指导思想
1. "治理"的指导思想
① 声明式 ( Declarative )：解决复杂系统，复杂流程管理的灵丹妙药。早期在
没有 k8s 的时候，微服务运维管理是一个复杂的过程，需要人工编写很多的脚本
完成应用的部署更新扩缩容等工作，使用者必须明确描述其所有操作细节。因为
相对于声明式，这种过程命令式的运维脚本，需要使用的人要能够掌控过程执行
所有细节，这对于大型复杂系统来讲是一个很大挑战。声明式编程的思想流行会
使这样的工作大大简化，服务负责内部自身复杂运行逻辑，上层使用者只需要声
明出自己的目标即可，系统自动帮你完成，无需关注其达成目标的具体过程。就
像 SQL 一样，之所以大家用着觉得简单，其很大原因是 SQL 就是一个声明式的
编程语言。这一思想已经逐步成为架构师解决复杂系统管理的推荐思路。比如，
当下很热门的运维部署框架 Ansible，运维人员只需要按要求编写安装部署剧本，
系统就会自动安装和部署相应的服务。
② 框架平台：在目标定位上，是开发一款工具，还是开发一个框架平台，会直接
影响到我们的系统设计决策。工具的特点是被集成，可以为使用者提供更灵活有
效的手段解决具体问题，但对于使用者本身有比较高的要求，最终结果如何，高
度依赖使用的方式。而对于框架来讲，将实现过程让渡给框架，开发者无需了解
全过程，只需要按照框架提供的规范进行开发即可，这一定程度约束了开发者的
行为，也降低了上手门槛，这实际上是依赖反转思想的体现。我们提到的知识依
赖，就可以通过框架或平台把它们沉淀下来。而使用者自然会在框架的帮助下，
使其开发的系统是相对可靠的。比如 web 开发框架 Spring，亦或是持续集成平
台 Jenkins，它们的作用就是提供一个领域业务模式或流程，能够使得初学者只
需要掌握平台或框架的使用便能在其领域达到一个比较高的水平，获得方法论指
引，避免前人的错误。
③ 组件化：其特点是标准化，复用性和灵活性。框架和它是依存关系，是它的契
约，组件是按照契约去实现及被集成。
④ 低代码 ( LowCode )：特点是简单，快速。当下比较热门的概念，一个框架
或者平台，不需要写代码或者少写代码就能够完成开发，是基于框架开发基础上
的更进一步，能够将业务过程，核心逻辑封装成一些低代码的模块，这对于简单
化业务过程，降低使用门槛有很大的帮助。
2. FlowEngine
基于上述的挑战及解决思路，第四范式研发了这样一个声明式的、低代码的、组
件化的智能场景开发和管理的框架平台。在这个框架基础上可以快速开发和管理
推荐等智能场景。
03
Flowengine 架构
接下来简单介绍一下 Flowengine 架构，它位于场景业务服务和子领域执行层之
间。它的出现其目的便是将我们缺失的领域层补充上。
1. 表现
Flowengine 提供了一套声明式 API，可用来创建，管理智能场景 ( 推荐 )，表
现为以下方面：
 场景沉淀，迁移，快速构建。在框架无状态的前提下，将应用逻辑，业务
规则和服务依赖保存成一个方案文件，从而做到可以在不同的 Flowengine
平台下无痛迁移分享。
 领域要素 ( 组件，JOB，FUNC 等 ) 的管理，集成，更新。提供要素的
开发，发布，集成，运行等全生命周期管理，使得其能够在明确的标准下
被集成和管理。
 业务逻辑编排 ( 批/流/在线 pipeline )。场景业务逻辑是对领域要素的逻
辑编排，这就使得其天然具备敏捷性，业务上也能做到垂直切分隔离，却
共用相同的执行底层。在业务隔离和资源共享层面达成了统一。
 预置核心组件及标准流程方案。简单的业务可以通过已有方案自动的生成
推荐服务，达到开箱即用的目的。如果存在场景差异也可以在此基础上进
行修改和完善，但修改过程仅仅发生在方案场景层面，从而有效的控制了
修改风险蔓延，做到了框架与方案的分离，从而在易用性，规范性与灵活
性，差异性上达成了统一，这个在传统架构上是一个不可调和的矛盾。
 标准化的底层集成方式，上层简单，下层开放。标准化的底层集成方式，
均采用业务组件或技术组件的方式集成，对上层呈现为可被 pipeline 编排
的资源要素，使用者无需关注执行层差异。这样就保证了上层是接口简单，
下层是开放的。
2. 构成与基本实现
简单说一下它的构成：
 Flowengine-Hub：用于存放方案，组件，FUNC/JOB 等资源要素的仓库。
 EngineManager：用来管理和监控引擎并作为适配层屏蔽下层复杂度。
 EngineKernel：单个引擎的核心，用于管理当前引擎领域实体，业务流程，
并提供运行环境及通信支持。
 Flowengine-Data：一个 AI/BI 为一体的数据服务，用于管理引擎数据、
元数据及对外提供统一的数据流服务。
基本实现：
 基于 k8s 微服务管理。从大的架构上看，Flowengine 是一个 CloudNative
架构，通过利用 k8s 的能力，实现了引擎内微服务的管理及动态化。一个
引擎是由一个或者多个微服务共同组成，运行组件的标准格式是在 docker
镜像基础上再封装而来，天然容器化友好。另外，在 Docker 和 k8s 的支
撑下，框架对于基础环境的复杂性有了很好的适应能力。
 在计算引擎层面，集成了 Spark，Flink 以及自研的模型训练 ( GDBT ) 等
框架，通过进一步的集成优化，使得开发者无需关注这些框架的使用细节，
通过统一的编程接口便能够完成开发。
 批流一体的数据流管理及元数据管理，引入数据摄取，加工，服务三个过
程，抽象出一，二，三级表的抽象表概念，开发者无需关注数据的存储和
计算细节，采用统一的方式完成数据流开发，从而降低开发的复杂度及分
散性。
 业务编排框架。提供批，流，在线三大可视化业务编排能力，使得业务逻
辑开发变成了无代码的拖拉拽操作。另一方面，通过集中的编排管理及任
务分发，解决了场景业务逻辑散落在各个执行组件中的问题。在引擎层便
能够管理业务全过程，这对于后期开发维护都大有帮助。
接下来我们介绍一下应用 Flowengine 之后的架构是什么样子的。

04
应用 Flowengine 后推荐的架构
1. 业务分解与技术映射
业务分解：如图，业务上一个推荐的场景大体是这样的，它包含在线的业务流程，
这一个流程大体可以分为召回，过滤，粗排，精排等几个部分，这里通常会因为
业务过程的变化而变化。另一块是数据处理及离线处理，这里会有数据怎么获取，
加工，以及提供给在线服务使用的逻辑。它也会随着业务变化而变化。最后一部
分，对于智能推荐，人工智能的作用举足轻重，它包含数据接入处理，特征工程，
模型训练，模型服务等多个过程，这其中也包含了离线和在线等诸多服务模块。
技术映射：那么，对于上述分解出的三大业务部分，在 Flowengine 框架上如何
映射呢？转化到 Flowengine 上面，我们用引擎的概念来映射，一个推荐场景就
是一个引擎，如图，这个引擎我们可以起名叫 reco-engine，这个引擎里存在一
个在线编排的 pipeline 叫 reco-func-pipeline，而它就具备把推荐服务流程通过
编排表达出来形成在线服务能力。Flowengine-Data 支持数据的接入，它提供数
据的摄取和服务的能力，比如说是 kafka 数据引入，ES 或者 Mysql 的服务输出，
并提供数据表之间的处理能力，开发者只需要关注数据流本身的处理逻辑，而无
需关注数据的存取和调度。而对于 AI 模型服务来讲，它也是一个引擎，在引擎内
部便能完成 AI 模型从开发到部署的全流程。场景引擎 reco-engine 只需要在需
要模型服务时调用该 AI 引擎的服务即可。这样我们一个推荐的场景就变成了一个
主场景引擎及若干 AI 模型引擎构成，而它们的底层资源管理和调度都无需场景开
发者关心。和我们之前讲的传统架构比，结构上清晰了许多，而这一切都归功于
必要的领域层抽象。
2. 带来的价值
接下来我们总结一下应用了 Flowengine 之后带来的价值：

 面向 Flowengine 声明业务过程，简单，统一。声明元数据，声明编排过
程。我们不需要管理执行层的具体细节，使得复杂度大大降低，业务过程
也变得更加标准化。
 服务及中间件数量减少，资源消耗减少，维护方便。推荐系统因为业务上
的发展，会增生很多小服务，这些服务管理麻烦，还占用资源。比如说推
荐系统一般会一个兜底的服务，定期生成静态的推荐结果，用来在正常推
荐响应失败时降级出推荐结果。在 Flowengine 的支持下，可以通过创建
一个离线的 pipeline 解决这类需求，那么这样的小服务就可以避免。
 逻辑分层，合适的拆分粒度。服务，策略，脚本，配置都能够合理安排，
体现最小知识原则，其灵活性，复用性更强。
 减少大量胶水代码和重复代码，串联流程基于编排框架，无需再自己管理
流程，声明配置即可，低代码，效率高，好管理。开发方案和使用方案分
离，分工会更加清晰，也便于经验及方法论传递。
 场景纵向隔离，便于业务差异化发展，业务不能绑架技术，技术更不能绑
架业务。在引擎层面做到相互隔离，一个引擎就是一个场景，开发，升级，
变更都能够互不影响。
 服务运维，环境迁移部署更便利，CloudNative 架构，无状态设计，方案
可导入导出。从解决思路上讲，Docker 解决了单一服务的迁移问题，而
Flowengine 解决场景的迁移问题。
最后给大家做一些实例的展示。
05
实例演示
Flowengine 支持页面、SDK 和 CLI 多种操作方式。左侧是引擎 Web 管理界面
和 CLI 截图。右侧是一个应用方案包结构，包含了应用的定义 meta_info.yaml
以及依赖组件的定义。
下图是 Flowengine-data 的管理界面，可以管理数据表及数据摄取，加工，服
务的处理过程。
最后是业务编排的操作界面。它包含离线编排，在线编排，流式编排。
06
总结
随着智能场景越来越多，原来项目式，单点式的场景开发维护，必然导致整体研
发成本的爆炸性增加。正如十来年前，web 应用的大发展，催生了大量优秀的
web 开发框架一样，智能场景应用的大发展也将会重演这样的历史。Flowengine
正是我们在这一领域的探索，以我们对智能应用的架构理解，构建一套加速开发
和运维过程的框架平台，跟进未来的发展趋势。
阿里粗排技术体系与最新进展
分享嘉宾：王哲阿里巴巴
编辑整理：乐远
语音朗读：蒋志新
导读：在搜索、推荐、广告等需要进行大规模排序的场景，级联排序架构得到了
非常广泛的应用。以阿里的在线广告系统为例，按顺序一般包含召回、粗排、精
排、重排等模块。粗排在召回和精排之间，一般需要从上万个广告集合中选择出
几百个符合后链路目标的候选广告，并送给后面的精排模块。粗排有很严格的时
间要求，一般需要在 10～20ms 内完成打分。在如此巨大的打分量以及如此严格
的 RT 需求下，粗排是如何平衡算力、RT 以及最后的打分效果呢？本文将为大家
分享粗排技术体系以及粗排最新进展 COLD，目前 COLD 排序系统已经在阿里定
向广告各主要业务落地并取得了巨大的线上效果提升。
本文的分享，主要围绕下面几点展开：
 粗排的发展历史
 粗排的最新进展 COLD
 粗排技术的总结与展望
01
粗排的发展历史
首先和大家分享下粗排的发展历史。
1. 粗排的背景
什么是粗排？一般的话，一个大型的工业级排序系统都会采用多阶段的排序架构，
通常会包含四部分：召回、粗排、精排和重排。以阿里巴巴定向广告为例，召回
的规模一般是千万左右，而粗排打分规模一般是一万以上，精排和重排的规模一
般是上百左右。粗排是处于召回和精排的一个中间阶段，目标是在满足算力 RT
约束的情况下，从上万个广告集合中选择满足后链路需求的候选广告集合。
粗排和精排有两点不同：
 算力和 RT 的约束更严格：粗排的打分量远高于精排，同时有更严格的延
迟约束，阿里巴巴定向广告的要求是 10-20ms
 解空间问题更严重：粗排和精排训练的时候使用的都是展现样本，但是线
上打分环节粗排打分候选集更大，打分阶段距离展现环节更远，因此粗排
阶段打分集合的分布和展现集合差距相比精排更大，解空间问题也更严重。
2. 粗排的两大技术路线
粗排的技术路线其实就是解决粗排一般该怎么迭代的问题，由于粗排是处于召回
和精排之间的一个模块，因此粗排本身的迭代会受到前后链路的制约，因此需要
站在整个链路的视角来看待这个问题。纵观整个链路，粗排一般存在两种技术路
线：集合选择和精准值预估。
① 集合选择技术
集合选择技术是以集合为建模目标，选出满足后续链路需求的集合的方法，该技
术路线在召回非常典型，这其实也非常符合粗排的定位。该方法优点是算力消耗
一般比较少，缺点是依赖于对后链路的学习，可控性较弱。
什么叫可控性？也就是说如果希望进行一些调整的话，由于这种方式依赖于通过
数据回流对后链路进行学习，而数据回流往往比较慢，同时对数据量也有要求，
可能需要后面链路的这些策略调整影响到比较大的流量之后，粗排才可以学习到，
因此这种方式可控性比较弱，是偏被动的一种方式。
这种技术路线有以下常见的几种方法：
 多通道方法：类似于召回，针对不同的目标构建不同的通道，然后分别选
出不同的集合，然后再进行合并选择。
 Listwise 方法：一般是直接建模集合的损失，典型算法如 LamdaMART。
为了更好理解 listwise 算法，这里提一下 pointwise 算法和 pairwise 算法，
pointwise 算法一般是点估计的方式，训练过程只考虑单条样本；而
pairwise 算法训练过程中会考虑当前样本和其它样本的相互关系，会构造
这样的 pair，并在训练的过程中引入这方面的 pairwise loss，训练目标可
能是正 pair 排在负 pair 的前面；Listwise 更近一步，在训练的时候会考
虑整个集合，会希望整个集合的指标如 NDCG 等达到最大化，如
LamdaMART 算法。
 序列生成方法：直接做集合选择。一般包含集合评估器和集合生成器，算
法过程如下：首先，用评估器对所有的 item 进行打分并选择一个得分最高
的，作为集合中的第一个商品。接下来，再挑选第二个商品，把第一个商
品和所有可能的第二个商品进行组合，并用评估器进行打分。之后，选择
得分最高的集合，并持续使用类似于贪心的方式不断的搜索，最终得到一
个最优的集合。
② 精准值预估技术
精准值预估技术直接对最终系统目标进行精确值预估，其实也就是 pointwise 的
方式。
以广告系统为例，建模的目标一般是 ECPM，即
ECPM=pCTR*bid
利用预估技术预估 pCTR，然后预估 bid，最终根据 ECPM 来进行排序，在粗排
的话就是取排序的分最高的 topK 作为最终的集合。这种方式的优点是可控性强，
因为是直接对整个目标进行建模，如果建模方式做了调整的话，可以直接调整排
序公式，调整预估模型，对整个链路的掌控力更强。缺点就是算力消耗比较大，
而且预估越准确，算力消耗也越大。
3. 粗排的技术发展历史
粗排在工业界的发展历程可以分成下面几个阶段：
① 最早期的第一代粗排是静态质量分，一般是统计广告的历史平均 CTR，只使
用了广告侧的信息，表达能力有限，但是更新上可以做到很快。
② 第二代粗排是以 LR 为代表的早期机器学习模型，模型结构比较简单，有一定
的个性化表达能力，可以在线更新和服务。
其中①②可以合称为“粗排的前深度学习时代（2016 年以前）”。
③ 当前应用最广泛的第三代粗排模型，是基于向量内积的深度模型。一般为双塔
结构，两侧分别输入用户特征和广告特征，经过深度网络计算后，分别产出用户
向量和广告向量，再通过内积等运算计算得到排序分数。
③ 称为“粗排的深度时代-向量内积模型（2016）”。
向量内积模型相比之前的粗排模型，表达能力有了很显著的提升，其优点：
 内积计算简单，节省线上打分算力
 User 向量和 Ad 向量离线计算产出，因此可以做的非常复杂而不用担心在
线 RT 问题
 双塔结构的 user 侧网络可以引入 transformer 等复杂结构对用户行为序列
进行建模
然而仍然有许多问题：
 模型表达能力仍然受限：向量内积虽然极大的提升了运算速度，节省了算
力，但是也导致了模型无法使用交叉特征，能力受到极大限制。
 模型实时性较差：因为用户向量和广告向量一般需要提前计算好，而这种
提前计算的时间会拖慢整个系统的更新速度，导致系统难以对数据分布的
快速变化做出及时响应，这个问题在双十一等场景尤为明显。
 存在冷启动问题，对新广告、新用户不友好
 迭代效率：user 向量和 item 向量的版本同步影响迭代效率。因为每次迭
代一个新版本的模型，分别要把相应 user 和 item 向量产出，其本身迭代
流程就非常长，尤其是对于一个比较大型的系统来说，如果把 user 和 item
都做到了上亿的这种级别的话，可能需要一天才能把这些产出更新到线上，
这种迭代效率很低。
针对向量内积模型的问题，也有很多相关的改进，典型的如下面这个方法。
向量版 Wide&Deep 模型，deep 部分仍然是向量内积结构，wide 部分引入基于
人工先验构造的 user 和 ad 的交叉特征，一定程度上克服了向量内积模型无法使
用交叉特征的问题。然而该方法仍然有一些问题，wide 部分是线性的，受限于
RT 的约束，不能做的过于复杂，因此表达能力仍然受限。
另外一个典型的改进方法是向量内积模型的实时化， user 向量通过线上打分实
时产出，ad 向量仍然离线产出，但是更新频次增加。
通过实时打分，可以引入实时特征，实时性加强。然而实时打分使向量内积模型
的 RT 和算力优势减弱，user 模型处于 RT 的约束不能设计的很复杂，而且该方
法还引入了新的打分模型和 ad 向量版本不一致的问题。
④第四代 COLD，下一代粗排框架（2019）-算力感知的在线轻量级的深度粗排
系统。下面将详细介绍该模型。
02
粗排的最新进展 COLD
前面粗排的相关工作仅仅把算力看做系统的一个常量，模型和算力的优化是分离
的。我们重新思考了模型和算力的关系，从两者联合设计优化的视角出发，提出
了新一代的粗排架构 COLD ( Computing power cost-aware Online and
Lightweight Deep pre-ranking system )。它可以灵活地对模型效果和算力进行
平衡。COLD 没有对模型结构进行限制，可以支持任意复杂的深度模型。这里我
们把 GwEN ( group-wise embedding network ) 作为我们的初始模型结构。
它以拼接好的特征 embedding 作为输入，后面是多层全连接网络，支持交叉特
征。当然，如果特征和模型过于复杂，算力和延时都会难以接受。因此我们一方
面设计了一个灵活的网络架构可以进行效果和算力的平衡。另一方面进行了很多
工程上的优化以节省算力。
总结为以下几点：
 基于算法-系统 Co-Design 视角设计，算力作为一个变量与模型进行联合
优化
 模型结构没有限制，可以任意使用交叉特征
 工程优化解决算力瓶颈
 在线实时系统，实时训练，实时打分，以应对线上分布快速变化
1. 模型结构
① 特征筛选
精简网络的方法有很多，例如网络剪枝 ( network pruning)、特征筛选 ( feature

selection)、网络结构搜索 ( neural architecture search)等。我们选择了特征
筛选以实现效果和算力的平衡，当然其他技术也可以进行尝试。具体来说，我们
把 SE (Squeeze-and-Excitation) block 引入到了特征筛选过程中，它最初被用
于计算机视觉领域以便对不同通道间的内部关系进行建模。这里我们用 SE block
来得到特征重要性分数。假设一共有 M 个特征，e i 表示第 i 个特征的 embedding
向量，SE block 把 e i 压缩成一个实数 s i 。具体来说先将 M 个特征的 embedding
拼接在一起，经过全连接层并用 sigmoid 函数激活以后，得到 M 维的向量 s：
这里向量 s 的第 i 维对应第 i 个特征的重要得分，然后再将 s_i 乘回到 e_i，得到
新的加权后的特征向量用于后续计算。
在得到特征的重要性得分之后，我们把所有特征按重要性选择最高的 top K 个特
征作为候选特征，并基于 GAUC、QPS 和 RT 指标等离线指标，对效果和算力进
行平衡，最终在满足 QPS 和 RT 要求情况下，选择 GAUC 最高的一组特征组合，
作为 COLD 最终使用的特征。后续的训练和线上打分都基于选择出来的特征组合。
通过这种方式，可以灵活的进行效果和算力的平衡。
注意 Se Block 仅用于特征筛选阶段，线上模型不包含该结构。
② 基于 scaling factor 的结构化剪枝
此外 COLD 还会进行剪枝，做法是在每个神经元的输出后面乘上一个 gamma，
然后在训练的 loss 上对 gamma 进行稀疏惩罚，当某一神经元的 gamma 为 0 时，
此时该神经元的输出为 0，对此后的模型结构不再有任何影响，即视为该神经元
被剪枝。
在训练时，会选用循环剪枝的方式，每隔 t 轮训练会对 gamma 为 0 的神经元进
行 mask，这样可以保证整个剪枝过程中模型的稀疏率是单调递减的。
这种剪枝方法在效果基本不变的情况下，粗排 GPU 的 QPS 提升 20%。
最终模型是 7 层全连接网络。
2. 工程优化
为了给 COLD 使用更复杂的特征模型打开空间，工程上也进行了很多优化。在阿
里定向广告系统中，粗排的线上打分主要包含两部分：特征计算和网络计算。特
征计算部分主要负责从索引中拉取用户和广告的特征并且进行交叉特征的相关计
算。而网络计算部分，会将特征转成 embedding 向量，并将它们拼接进行网络
计算。
① 并行化
为了实现低时延高吞吐的目标，并行计算是非常重要的。而粗排对于不同的广告
的计算是相互独立的，因此可以将计算分成并行的多个请求以同时进行计算，并
在最后进行结果合并。特征计算部分使用了多线程方式进一步加速，网络计算部
分使用了 GPU。
② 行列转换
特征计算的过程可以抽象看做两个稀疏矩阵的计算，一个是用户矩阵，另一个是
广告矩阵。矩阵的行是 batch_size，对于用户矩阵来说 batch_size 为 1，对于
广告矩阵来说 batch_size 为广告数，矩阵的列是 featue group 的数目。常规计
算广告矩阵的方法是逐个广告计算在不同 feature group 下特征的结果，这个方
法符合通常的计算习惯，组合特征实现也比较简单，但是这种计算方式是访存不
连续的，有冗余遍历、查找的问题。事实上，因为同一个 feature group 的计算
方法相同，因此可以利用这个特性，将行计算重构成列计算，对同一列上的稀疏
数据进行连续存储，之后利用 MKL 优化单特征计算，使用 SIMD (Single
Instruction Multiple Data)优化组合特征算子，以达到加速的目的。
③ Float16 加速
对于 COLD 来说，绝大部分网络计算都是矩阵乘法，而 NVIDIA 的 Turning 架构
对 Float16 和 Int8 的矩阵乘法有额外的加速，因此引入 Float16 计算对提升性能
非常必要。但是 Float16 会损失计算精度，特别是在 sum-pooling 的情况下，

数值有可能超出 Float16 的范围。为了解决这个问题，一种方式是使用 BN。但
是 BN 本身的参数范围也有可能超过 Float16。因此只能使用混合精度的方式，
对于 BN 层使用 Float32，而后面的层使用 Float16。另一种方式是使用参数无关
的归一化方式，例如 log 函数。但是 log 函数不能处理负数，并且输入值接近 0
的时候会输出绝对值较大的数字。因此我们设计了一种分段平滑函数，我们叫做
linear_log 来解决这个问题。
从函数图像可以看出，linear_log 函数可以将 Float32 的数值处理到一个比较合
适的范围。所以如果我们将 linear_log 函数放到第一层，那么就可以保证网络的
输入参数在一个比较小的范围内。具体实践上，linear_log 函数对 COLD 模型的
效果基本没有影响。使用 Float16 以后，CUDA kernel 的运行性能有显著提升，
同时 kernel 的启动时间成为了瓶颈。为了解决这个问题，我们使用了 MPS
(Multi-Process Service)来解决 kernel 启动的开销。Float16 和 MPS 技术，可
以带来接近 2 倍的 QPS 提升。另外，使用阿里自研的含光 800NPU 专有硬件，
替代原来的 GPU，QPS 进一步提升约 1 倍。
3. 在线服务架构
COLD 没有限制模型的结构，训练和在线打分都是实时化的，可以带来以下两个
优点：
 在线学习的引入使 COLD 与向量内积模型相比，可以更及时的响应数据分
布的变化，对新广告冷启动也更为友好。
 实时架构对于模型迭代和在线 A/B 测试都更有利。向量内积模型由于用户
向量和广告向量需要提前计算好，在线 A/B 测试也更为困难。实时架构也
使 COLD 模型可以更快的更新，避免了向量内积模型的更新延迟问题。
4. 实验结果
这里 COLD 模型使用了 7 层全连接的网络结构。离线评估指标除了 GAUC 之外，
还包含了 top-k recall，用于评估粗排和精排的对齐程度。
其中 top k 候选集合和 top m 候选集合均为粗排的输入打分集合。top k 集合是
粗排选出的，而 top m 集合是精排选出的，排序指标是 eCPM(eCPM =
pCTR*bid)。这里的精排模型是 DIEN。我们使用 QPS (Queries Per Seconds,
which measures the throughput of themodel) 和 RT (return time, which
measures the latency of model)来评估系统性能的影响。
① 模型效果评估
离线效果评估可以看到 COLD 在 GAUC 和 Recall 上都优于向量内积模型。在线
效果上，COLD 与向量内积模型相比在日常 CTR +6.1%,RPM + 6.5%。双十一
CTR+9.1%，RPM+10.8%，提升显著。
② 系统性能评估
从上面表格可以看到，向量内积模型的系统性能最好，而精排的 DIEN 的系统性
能最差，COLD 则在两者之间取得了平衡。
COLD 在得到特征重要性分数以后，会选出不同的候选特征，并基于离线指标进
行特征选择。第二个表列了几组供选择的特征，可以看到 COLD 是考虑效果和系
统性能以后的折中。
Table 5 表明，工程优化上引入 Float16 和 MPS 优化以后，QPS 提升了 1 倍，
效果显著。
5. COLD 的进一步发展
那么 COLD 的后面进一步怎么发展？答案是与精排进行更加深度的整合。目前粗
排和精排都是各自独立迭代的，这样会造成一个前后不一致的问题，会带来一个
链路的内耗。而且粗排和精排维护两套流程的话，本身维护成本也很高，尤其是
像阿里巴巴定向广告这边，业务多而且复杂。另外，COLD 和精排一样都是非常
实时化的架构，这使得粗排和精排进行更深度的联动成为可能。
具体如何进行更加深度的整合呢？这里我们直接将粗排和精排的生产流程合二为
一，联合训练，共享部分参数。另外也会借助特征蒸馏的方式，使用精排训练过
程中的得分来指导粗排。在这个基础上，尝试引入精排参竞日志，对于未展现样
本借助精排得分进行辅助学习。为什么引入精排参竞日志？其实前面提到过，因
为粗排除了 RT 还有一个就是解空间的问题，粗排本身见到的集合比精排更多，
但是它本身模型的能力却比精排更弱。所以为了缓解这个问题，引入精排参竞日
志，这部分日志本身是没有 label 的，可以利用精排在这些 label 上进行打分，通
过蒸馏的方式来引导粗排进行学习。为什么说这种方式在一定程度上能缓解解空
间的问题？其实是建立在精排的模型能力比粗排更强，这个强很大程度体现在精
排对交叉特征的利用上，在这种情况下，对于很多没有展现的 user 和 item 的 pair
对，精排相比于粗排其实是可以给出更精确的预估的，在这个前提下，借助精排
更精确的预估分数，然后对粗排进行指导，在一定程度上是可以缓解解空间问题
的。
这种方案的好处是将粗排和精排的流程合二为一，粗排精排模型一起训练，一起
产出，这样可以提升粗排和精排的对齐程度，解决前面提到的因为前后链路不一
致造成的链路损耗问题。另外引入精排参竞日志，在一定程度上也能缓解解空间
问题。而且还有一个好处就是降低运维成本，减少了训练资源，提升我们的迭代
效率。
03
粗排技术的总结与展望
最后做一下总结，目前整个粗排基本已经全面迈向深度学习时代，而且深度学习
时代的粗排主要存在向量内积和 COLD 两种主流技术路线。没有最好的算法，只
有最合适的算法。不管是 COLD 还是向量内积，其实都有它适合的场景。有的团
队在向量内积这条路线上持续迭代，其实也是受到本身算力 RT 的一些限制，包
括本身工程团队等各方面因素的影响。而且很多团队的精排也还是向量内积结构，
粗排就没有必要升级到 COLD 了。
最后，展望一下粗排会怎么发展。粗排未来会存在两种可能的路线。
一个是粗排精排化，也就是说精排技术持续向粗排迁移，粗排和精排的界限逐渐
模糊，走向更深层次的整合和一体化。其实可以看到，粗排的迭代历程本身其实
就是一个粗排精排化的过程，一般很多技术如向量内积，都是先在精排落地拿到
效果后，再逐渐向粗排迁移。而且算力也会更深度的参与到整个模型的迭代过程
中，未来可能的话甚至不会再分粗排和精排，精排本身可能会在引入算力作为一
个约束的情况下，通过 AutoML 等方式，产出多个不同算力版本的子模型，粗排
只是其中一个，跟随精排自动升级和迭代，从而实现全链路算力和效果的平衡。
甚至算力足够大的话，可以不需要粗排了，直接用精排打分就可以了。
另外其实还存在另外一条路，就是回归集合选择的本质，以产出符合后链路需要
的集合为目标，真正以集合为对象进行建模。这里需要清楚粗排的目标是什么？
粗排的目标是选出后链路需要的集合。而目前粗排精排化的迭代思路其实是在做
ranking，但是粗排其实只需要一个 top k 的集合，集合内部无序就可以了。而粗
排精排化这种方式消耗了很大一部分算力在 TopK 的内部排序上，很多算力消耗

在 Top1 和 Top2 怎么排好，从计算角度来看是一种资源浪费。当然这条技术路
线还比较新，目前还在探索中。但是这个方向是一个很有希望的方向，因为它回
归了粗排的本质，直接面向粗排的最终目标，因此在算力的利用率和最终的天花
板上是更高的。
参考资料：
【1】Covington P, Adams J, Sargin E. Deep Neural Networks for YouTube
Recommendations. RecSys. 2016.
【 2 】 Zhe Wang, Liqin Zhao, Biye Jiang. COLD: Towards the Next
Generation of Pre-Ranking System
阿里深度树匹配召回体系演进
分享嘉宾：卓靖炜阿里巴巴
编辑整理：成鑫鑫
导读：目前不管是广告还是推荐业务，最底层的技术都是检索，由于候选集合非
常大，可能从千万甚至亿级别取出数十个用户感兴趣的商品。在算力和时间复杂
度的约束下，往往采用分阶段漏斗的算法体系。具体来说就是分成召
回 ( match ) 以及排序 ( rank )。本文主要介绍阿里在 match 阶段的最新实践—
—深度树匹配，分成几个部分:
 检索召回技术现状
 深度树匹配（TDM）技术演进
 TDM 业务应用实践
 总结与展望
01
检索召回技术现状
1. 互联网业务中检索召回技术的发展
对于 match 这一部分来说，我们的核心问题是要从一个大规模的候选集合里面高
效检索出 topK。单点计算消耗和所需计算次数决定了系统性能边界。我们需要在
实际设计系统的时候考虑两个平衡，首先是我们的对于每个 item 使用模型打分，
有单点计算消耗的约束，从广告库里面解锁商品，有计算次数上限，我们需要保
证在现有的系统性能边界下，无论是单点的计算消耗以及所需的计算次数，他们
的乘积不能超过这个性能边界。
2. 两段式 Match 的经典实现

在我们系统里面最早期的是一个经典的两段式 match，例如基于商品的协同过滤，
就是说对我们对于每一条用户的请求我们去找到用户历史的 item，然后再通过这
些 item 查询离线计算好的 I2I 相似关系表找到我们需要召回的 item，并且最终做
合并取 topK。这个方法它的优势在于模型非常简单，而且实现成本非常低，我们
所有的迭代只需要在离线计算一份 I2I 表就完成了。但是它的缺点也很明显，因为
是一个两段式的召回框架，整个过程是没有办法联合优化的，有一些很多先进的
模型，像深度神经网络没有办法很好的应用，导致召回效果受限。一个很自然的
想法是我们是否能把这种两段式的检索升级成为一段式，并且对整个全库做一段
式检索。
3. 内积模型向量检索
基于上述思路，有一个非常广泛的应用是通过内积模型来做向量检索，具体思路
就是我们基于用户以及商品特征的 embedding 去设计一些网络，类似双塔这样
的结构，然后根据这些 embedding 去计算内积的相似度，这样就把 match 阶段
对候选商品集合召回的问题转化成一个单点打分以及分类这样一个问题。
具体实现是三个阶段：
 首先离线训练双塔模型，得到 item embedding；
 训练完成之后，对这些 item embedding 做聚类，并且根据乘积量化去构
建索引；
 在线上使用时，对于每一条用户请求能够计算得到 user embedding，然
后在已经构建好的索引里面去进行查找，得到 user embedding 最接近的
K 个 item，作为 top K 的召回。
这样一个流程它的优势非常显然：面向全库一段式检索，从数据里面获取一些发
现能力，而不依赖于用户历史行为触发。但是它的缺点也很明显，对于我们使用
的模型结构上有一个非常强的约束，就是我们的模型必须是类似双塔这样的结构，
最终 user 以及 item 的相似度必须由内积来计算，这样对于模型能力有一个很大
的局限。我们有过好几版升级，最早是类似双塔这样的內积模型，接下来是 DIN
和 DIEN，分别是把 attention 的机制引入了 CTR 预估问题里面，如果我们只看
auc 的话，引入 user 和 item 之间的交互模型的性能有一个比较大的提升。
这里面启发我们一个自然的思考，如果我们想要把更加先进的模型引入到 match，
那么我们应该怎么做？第二个问题是我们在向量检索模型里离线做索引构建的时
候，它的目标与我们在线上使用的时候检索目标是完全不一致的，离线索引构建
的时候优化目标是最小化 embedding 近似误差，但是实际上线上想要的是最大
化 topK 召回率，彼此之间有 missmatch，所以一个很自然的想法，我们是否能
够把这两点统一起来联合来优化，然后这启发了我们去做深度树匹配召回这件事
情。
02
深度树匹配（TDM）技术演进
模型能力的升级需要相应的索引结构升级来支持,我们需要设计一个通用的索引
结构，使得能够支持任意复杂的模型来做召回。对于 user 和 item 之间复杂交互，
如果不依赖双塔这样的模型结构，我们需要什么样的索引结构?
首先，想到散列表，但是散列表同样基于距离度量，融合先进模型比较困难。加
入选择图的话，对于模型结构没有任何要求，但是图的一个问题就是它结构非常
复杂，并且在图上做检索很难有确定性的检索次数的控制，会存在指数爆炸的问
题，所以我们最后选择了树。树的结构相对简单，可以通过控制树的层高来控制
检索次数。
1. 深度树匹配的提出
我们提出了深度树匹配这样一套技术，它的基本想法就是我们把所有 item 商品库
聚合成为一个层次的兴趣树，把从商品库里面的检索转换成一个在树上做检索的
过程。
比如说是一个二叉树，由于树的特性，我们能把从十亿商品库里面挑商品的问题
转化成在树上做 30 层的检索问题，这样的话计算次数就会大大减小。
虽然有这样一个想法，但是我们后续需要解决非常多的问题:
 如何基于树实现高效检索
 如何做兴趣建模保证树检索的有效性
 如何学习兴趣模型
 如何构建和优化树索引结构
2. 基于树的高效检索方法—Beam Search
我们让叶子节点表示全部商品，中间节点表示商品的粗力度的聚合，比如是对于
兴趣的聚合，这样的话我们通过构建一个完全平衡二叉树就能够保证这棵树自顶
而下的兴趣划分是从粗到细的。在这棵树上就能够通过 Beam Search 实现一个
启发式检索的方法来找 topK 叶子节点，它的时间复杂度是 logN, N 是总的商品
个数，计算性能是符合线上开销的,那么一个很自然的问题就是怎么保证这样的检
索出的就是全局最优?
3. 最大堆树：支持 Beam Search 检索的兴趣建模

我们提出了一套方案，要求模型保证用户的兴趣分布必须服从最大堆的性质
 最大堆树下当前层的最优 TopK 孩子节点的父亲必然属于上层的父辈节点
最优 TopK；
 最大堆树保证 Beam Search 检索得到的 TopK 一定是全局最优 TopK：从
根节点递归向下逐层挑选 TopK 和扩展其子节点至叶子层。
4. 最大堆树的模型学习
如何学习中间节点的兴趣概率？
 叶子层节点兴趣：用户对叶子节点的行为数据构建序标签
 中间层节点兴趣：基于最大堆定义可推导每层的序标签
 用深度学习模型拟合上述两个序标签
采样方案：
 叶子节点：用户行为的隐式反馈来建模叶子节点的兴趣概率
 中间节点：
传递性：叶子正样本上溯祖先仍为正样本
层次全局性：在每一祖先层随机负采样
5. TDM1.0：容纳任意先进模型
最大堆树的训练模式和检索模式为容纳任意先进模型提供了坚实的理论基础和强
大的效率保证。我们主要做的工作是在最大堆树这样一个约束之下，我们引入了
一些更加先进的模型,它跟双塔模型最大的区别在于我们模型里面考虑了用户的
特征以及 Item 特征的交叉，它不是一个双塔结构，这里面用户特征简单来说就是
用户历史的 Item 行为序列商品特征。商品特征比如商品的 ID，如果是在树里面
非叶子层的话，它就是 node 的 ID，在这种模型结构里面，我们把用户的历史行
为拆分成一系列时间窗，然后我们在每个时间窗里面做一个基于 Item
embedding 的 attention，然后得到最终的 attention 向量。在这种模型结构之下，
我们利用到了用户以及 item 之间的交叉信息，所以它的模型能力是比双塔结构强
的。
然后在这种情况下，我们在训练的时候就用之前所说的最大堆树学习的方法，把
它拆分成 H 层的分类问题，在检索阶段的话，直接用 Beam search，然后对这
棵树检索，得到我们最终想要的结果。大概在两年前，我们已经到线上后取得了
大概两位数的一个性能的提升。
6. TDM2.0：模型&索引联合学习
在 1.0 的时候，我们是在给定的一个树的范式之下，只考虑模型的学习，但其实
树的结构本身对于我们召回结果有非常大的影响，比如说考虑左下角这样一个例
子，在一些女装女鞋男装拿些这样个商品集合里面去构造一棵树，那么在这种情
况下，树构造有两种办法，一种是把女装和男鞋做一个聚合，然后把女鞋和男装
聚合，但这种方法可以看到它得到的聚合其实是没有什么意义的。一个更加合理
的划分方法是把女装和女鞋、男装和男鞋划分到相同的树节点，这样的话对于高
层的非叶子节点我们就有一些抽象的含义。
所以我们在 2.0 想要解决的问题就是如何对模型以及索引做联合的学习，这个问
题抽象出来，其实就像右上角所示。所以在这种情况下，我们整个树模型的学习
过程就可以看成是对两项的优化问题。一项是模型的参数，也就是对带权二部图
的最大匹配问题，我们用了贪心的算法，最终得到一个分段式树学习算法。这就
是我们在 2.0 所做的一些基本事情。

7. TDM3.0：模型&索引&检索联合学习
不论是 1.0 还是 2.0 都有一个问题就是训练和检索的目标偏差。训练的目标：拟
合每层兴趣多分类的概率。正样本上溯路径节点+同层随机负采样。检索目标：召
回率最大，自顶而下的 Beam Search 集合,每层只集中在头部打分节点部分。
一个最典型的例子就是我们在训练的时候，所用到的样本是一部分上述的正样本
以及一部分随机采样的。没有考虑到在线上检索的时候，实际上是自顶而下的一
个扩展的方式，每层用到的 Item 其实是相对打分比较高的那一部分，这就会导致
我们在检索中可能检索到的某些 Item 在训练的时候没有得到充分的训练。我们希
望把线上检索的目标以及过程完全考虑到训练中，保证我们离线训练以及线上使
用的一致性。这样的话，实际上我们又从兴趣分类建模这件事情重新回到对于集
合召回建模这个事情上。
为了达到这一点，我们做了以下两件事情。
对检索过程建模：对齐数据分布
首先第一是我们对采样方式做了一个升级，就是我们不再通过正样本加负样本采
样这套方式来构造我们的训练样本，我们直接对我们这棵树做一个 BeamSearch
检索，然后以检索出来的这些 topK 集合作为我们的训练样本。这样我们在离线
训练时和在线 Serviceing 的样本产生逻辑以及样本分布是完全保持一致的。
对检索过程建模：对齐训练目标
我们做的第二件事情就是说我们对于本身模型学习的目标做了一次改造，确保我
们能够满足最大堆约束，也就是保证我们的 BeamSearch 的局部最优一定是全局
最优。我们与之前的方法做一个对比，在之前的方法，我们对于节点的标签的设
定就是它本身以及它的上溯路径全部标为 1，然后剩下的节点全部标为 0 作为负
样本，从里面随机采样作为它的训练样本。我们后来发现这样一个设定方式，其
实并不符合最大堆的需求，我们对它做 BeamSearch 得到的 topK 也不是全局的
最优。所以我们换了一个样本构建的方式，就如右图所示，比如说这里面蓝色节
点都是我们检索到的集合，那么我们对于每个节点的标签，我们不只依赖于本身
item 用户是否点击了这个行为，每个节点的标签还依赖于从它的子节点上溯的标
签，以及模型对于它的子节点的一个预估分数。
8. Beam Search 下理论最优的训练范式

我们做了上述两版升级，就得到了一个在 BeamSearch 下理论最优的一个训练方
式，具体来说就是我们以 BeamSearch 来构造我们的样本集合，我们通过基于打
分上溯的方式去设计每一层样本的拟合目标，还是一个 H 层的但是存在上下层依
赖的这样一个分类问题来做我们的模型的训练。他的训练方法也是一个循环迭代
的方式，就是我们输入原始样本的 minibatch，使用当前的模型做一遍采样就是
做一 BeamSearch 检索，得到每层的样本，然后采用目标构建的方式，对于这个
样本里面的每一个节点得到它的一个模型的标签，得到标签之后类似一个二分类
问题设计一个 loss，然后去对参数更新，然后如此反复迭代，直到收敛。
9. TDM 显著性效果
离线的话我们也做了一些公开数据集的测试，可以看到不管是从 1.0、2.0 以及
3.0，它的召回率都有一个显著的涨幅，跟现有的方法，比如说 ITemCF 以及
YoutubeDNN 这两个经典的方法来比，有个非常大的提升。
我们在每个阶段的思考也有一些论文产出，如果大家对具体的细节感兴趣的话，
可以参考我们的论文。
10. TDM 在定向广告场景落地实践

最后，讲一下我们在定向广告场景的一些落地使用，广告业务本身它有非常显著
的一个特点，就是我们商品召回的有效性其实比较低的，因为存在广告主的预算
是否花光，商品的上下架以及投放的时间的影响。所以这导致了在广告里面，我
们候选广告集合它的动态性非常强，但是 TDM 这样的树结构，是一个相对比较静
态的结构。
所以在实际中我们采用了静态树结构加动态的正排倒排表这样一个实现方式。具
体来说就是我们本身这个树的结构是以正常的商品作为叶子，我们在这样的结构
之上做了一个实时的商品以及广告的倒排表，以及广告本身的信息做正排表。我
们在线上 Servicing 的时候，树结构是保持不变的，我们根据实时的变化去实时
更新广告正排倒排表的顺序结构，这样使得整体能够保持一个比较高的召回有效
性。
04
展望
最后是总结与展望，然后我们还是回到我们本身检索这样一个问题，因为算力的
约束，导致形成了大家都认可的一个分阶段漏斗的形式，就是把整个检索过程拆
分成召回以及 rank 这两个阶段。在后续的话，我们希望也把 TDM 这一套技术把
它做得更加扎实一点。大概是三个维度，首先是检索结构上，我们希望利用图对
本身树这样一个召回结构做一些近似的扩展，第二我们希望它能够去对多种目标
进行召回，比如说多考虑一些多样性发现性这些指标，另外还有一点是我们希望
能够把这种形式做一些可解释性的推荐。
最后回到检索问题本身，未来算力&算法升级使得检索不再是瓶颈，Match+Rank
分阶段漏斗式体系该如何发展?我觉得可能是把 match 和 rank 作为一个整体，用
一个整体的技术方案去实现从千万级百万级量级到个位数或者十位数这召回，也
就是所谓的合久必分，分久必合。
多目标排序在快手短视频推荐中的实践
分享嘉宾：郑东博士快手推荐算法技术总监
编辑整理：于洋
导读：快手是中国领先的短视频和直播社区，拥有超过 3 亿的 DAU 和丰富的社
交数据。快手秉承的价值观是真实、多元、美好、有用，致力于提高每一个用户
独特的幸福感。而推荐覆盖了快手大部分流量，极大地影响整体生态，并直接作
用于 DAU 和 APP 整体时长。短视频推荐需要更多地考虑生态，优化目标和约
束非常多，包括消费侧指标、生产侧指标和社交侧指标。本文主要讲解多目标排
序在快手短视频推荐中的实践。包括以下几个模块：
 快手短视频推荐场景介绍
 多目标精排：从手工融合到 Learn To Rank
 复杂多目标：Ensemble Sort 和在线自动调参
 重排序：Listwise、强化学习和端上重排序
 总结和展望
01
快手短视频推荐场景介绍
1. 关于快手
快手主要的流量形态有 4 个页面：
① 发现页：致力于让用户看见更大的世界，分为单列和双列两种形态。
 双列点选模式，给用户提供选择的自由
 单列上下滑浏览，给用户沉浸式的浏览体验
② 关注页：一个半熟人半陌生人的社区，是私域流量的入口，比如和自己的好友
互动，浏览关注订阅的生产者作品。
③ 同城页：带给用户身边触手可及的生活。
在这些流量分发的场景中，推荐算法是起着核心主导作用，直接决定了用户的体
验。
2. 排序目标
快手短视频推荐的主要优化目标是提高用户的整体的 DAU，让更多的用户持续使
用快手，提升用户留存。在具体的排序建模过程，提升使用时长/正向反馈，减少
负向反馈，可以提高用户留存。从上图中部曲线可见，留存提升在累计一段时间
后会带来 DAU 的置信显著提升。此外，在推荐中，用户反馈分四类：
① 隐式正反馈，用户行为稠密，如用户在无意间的行为——播放时长、有效播放、
播放完成率、完播、复播等；
② 显示正反馈，需要用户有意识地做出反馈，不同用户间的行为密度差异比较大，
如收藏、下载、关注、点赞，发表正向评论等；
③ 隐式负反馈，用户行为稠密，如短播放、用户终止一次 session 等；
④ 显示负反馈，需要用户显式表达，如不感兴趣、负向评论、举报等。
而推荐的目标是提高正向反馈、减少负向反馈，提高用户体验。推荐分召回、粗
排、精排、重排几个环节；在排序阶段，模型预估用户对内容的个性化偏好，比
如，对上述各种用户反馈的预估值，然后，用机制策略将预估值融合成一个排序
分，对视频排序。
02
多目标精排：从手工融合到 Learn To Rank
1. 手工融合和简单模型融合
粗排/精排的个性化多任务学习模型，能预估 20 多个不同的预估值，如点击率、
有效播放率、播放时长、点赞率、关注率等，那如何用它来排序呢？从多任务学
习到多目标排序，中间有一个过渡，即如何把这些预估值融合成一个单一的排序
分？快手推荐追求时长、点赞、关注、分享等多种目标，以及减少不感兴趣等负
向反馈。通过合适的排序目标和机制设计，获得多目标的协同提升。下面，分别
介绍这边 Stage1 的把不同的预估值做一个线性加权融合和 Stage2 的基于树模
型的 ensemble 打分两阶段工作。
Stage1：手动公式融合
该方法的缺点是过于依赖规则设计；依赖人工调参，且维护成本高；固定权重，
缺少个性化、场景化。
Stage2：树模型规则 Ensemble 融合
 使用 GBDT 模型，引入 pXtr、画像和统计类特征，拟合组合 label：
 采用加权 Logloss：
 上下滑无负样本，通过拷贝正样本实现对目标无偏估计
 等价于将叶子结点转换为打分规则，得到打分的 Ensemble，也叫 RuleFit
该方法的缺点是树模型表达能力有限，且无法 online learning。
上线效果：同城页短视频时长提升 4.5%
2. 超参 Learn To Rank
由于树模型的表达能力有限，进而考虑用 DNN 类的网络模型学习打分函数：使
用拟合组合收益 label：
首先，介绍一个简单的双塔形式的 DNN，如上图右侧网络结构所示，视频塔直接
把各种个性化预估值拼在一起，形成一个 24 维向量；用户塔的顶层向量通过网
络学习，产出一个 24 维向量。最后，对视频塔和用户塔产出的向量做内积，损
失函数采用加权 Logloss：
由此，相当于通过学习线性加权的超参数去拟合最终的组合收益。其次，用户特
征选用了一种比较轻量级的方式，比如对用户划分不同的时间窗口：过去 1 分钟、
5 分钟、15 分钟、...、2 小时，每个时间窗内，对推荐给他的视频，根据用户的
反馈拼接成一个向量，这些反馈包括有效播放、点赞、关注、分享、下载、观看
时长等，最后，将各时间窗口对应的反馈向量和 ID 类特征一起输入到用户侧网络。
上线效果：App 时长提升 0.2%
3. 端到端 Learn To Rank

上述双塔形式的 DNN 及其轻量级的特征表达，依然限制了模型的表达能力。继
而，考虑端到端学习，主要尝试了 Pointwise 和 Pairwise 两种形式。
① 对于 Pointwise 形式，把 user_id、行为序列等都作为原始输入特征，同时，
融入 pXtr 特征，使用精排模型来学习最终的组合收益。因为这种方式支持更复杂
的特征抽取和网络结构，如 attention 结构，所以模型的表达能力更强。
上线效果：App 时长提升 0.6%，互动提升 2~4%
② 对于 Pairwise 形式，在一次用户请求返回的 6 个视频之间，对每种目标都如
下操作：先通过该目标的正样本和负样本构造偏序对，再使用 DNN 网络学习偏
序对的打分，对打分做 sigmoid 变换，最后通过交叉熵损失产出 loss。下述公式
表示的是 like 目标：
对不同目标的 loss 线性加权，从而可以兼顾多个目标间的权重：

在效果上，上述做法某种意义上可以看做对不同目标的 AUC 加权求和。因为 AUC
本质上是一个偏序的关系，即正样本和负样本之间的偏序。
上线效果：App 时长持平，页面互动提升 2%~7%
03
复杂多目标：Ensemble Sort 和在线自动调参
前面介绍的是纯粹用模型的方式做多目标排序，但在复杂的业务场景可能不把所
有优化的目标都放在模型里。纯用模型的方式做排序，成本比较高，整个线上也
会比较繁重；包括一些生态上的调节、一些专项调节都不太方便。接下来，介绍
下在复杂的业务场景下，快手是如何做动目标排序的。
1. Ensemble Sort
在上图左侧表格中给出了一些复杂目标，包括用户的互动和时长的多目标线性加
权公式，还有分享后带来的外部效用和用户本身分享效用，其中，外部效用包括
用户在外部社交网络传播对快手 DAU 的贡献等等。

对多种不同打分逻辑常规融合方法是做线性加权：
该融合方法存在的问题是不同 Score 之间含义、量级和分布差异较大；显式反馈
如点赞率等在不同用户间差异巨大，难以适应统一权重；并且依赖模型预估值绝
对大小，预估值分布变化时需重新调节或校准。
在此基础上，尝试在各子项分内做 Normalize 的优化，如把子项分转化为序。具
体地，把用户的个性化预估点赞率从小到大排序，把每个具体的值映射成它的序，
再把序折合成一个分数，不同的序映射到不同的分数，这与 GAUC 目标一致。
该做法把不同量纲且分布差异巨大的分数 Normalize 到同样维度，可兼容含义差
异巨大的子项分，保证各子项分权重在同一量级调节，并且隐式反馈的预估分在
不同用户上做到了某种自适应调节。同时，这种序和 AUC 的预估值也是一致的，
能很好地和线上模型的效果保持一致性。通过以上的方式把多种不同的打分策略
融合在一起，适用于快手线上复杂的业务场景。
上线效果，App 时长提升 0.6%，页面互动提升 2~3%
2. 在线自动调参
上述 Ensemble Sort 里的线性加权系数主要依赖手动调参，优点是简单轻量且可
解释性好，缺点是效率低且依赖工程师经验；如果有两三个参数，可能人还能处
理过来，但参数扩充到 10 个/20 个之后，很难手动判断参数之间的关联进行全局
调优；并且这些固定参数很难在不同人群上做到个性化和场景化。
解决上述问题的一种方式是 Learn2Rank，即用一个模型离线学习各反馈的组合
权重。
 优点是这是一种 off-policy 方法；数据利用率高，100%的样本都可以被
使用，模型的自由度和复杂度较高，比如 Learn2Rank 可以容纳 item
embedding，并使用稀疏特征，可训练千亿规模的参数。
 缺点是优化的离线 AUC 无法直接对标业务指标。因为这个过程做了很多的
简化，比如从精排到最终吐给用户，中间还有重排、多样性的影响，还有
后面的一些和其他如商业化/运营流量的融合等等，所以该方式难以考虑到
线上复杂多模块间的完整影响。此外，线下训练数据和线上也存在不一致
性。
除上述方法外，其余优化
的离线学习方法，如一些非梯度优化算法：PSO(粒子群算法)、ES(进化策略)等，
即每次产生一组超参数(a,b,...,h)，算一下该组参数对应的评估目标：组合 AUC
多轮迭代收敛后，选择 AUC 加权和最大的。
上述离线方法都有具有和 Learn2Rank 类似的缺陷，为了解决该问题，我们这边
开发了在线自动调参框架。自动在线调参的工作机制如上图左下角所示，即在基
线附近探索生成 N 组参数，传给推荐系统后获得这 N 组参数对应的展现给用户的
差异化排序结果，从而获得用户不同反馈，收集这些反馈日志并做 Reward 统计，
最终输给 CEM/ES/BayesOpt 等调参算法产生下一组更好的参数。经过不停迭
代，参数即可逐渐向一个多目标协调最优的方向前进。
 优点是直接优化线上指标，灵活性高且反馈迅速，并且算法把推荐系统当
作一个黑箱，无需关心内部细节，可以做多场景联合优化，不限于 ranking，
在召回等场景也可以用。
 缺点是需要线上拿出一部分流量做探索，用户有感知，会影响少部分用户
体验；每组几万或几十万的用户积累几个小时的数据，只能产生一个样本
点，由此数据较稀疏，受噪声的影响较大，特别是一些稀疏的 label，如分
享、下载、收藏等稀疏 label；能容纳的参数量较小，一般几十到数百，
相对离线学习的参数规模小很多。
接下来，介绍下在线自动调参的具体实践。
线上给 5%流量做探索，每次探索几十组参数。在每次分发时，探索组和基线组
同始同终，以基线组的样本量为准，每轮收集固定数量样本。这里，收集固定数
量样本是因为白天的高峰期和夜晚的低峰期流量大小不一样，如果按时间尺度去
划分，可能不同时间的样本量大小差异会产生方差噪声。
Reward 设计模块主要是衡量在每组参数下，时长和互动指标相比基线的涨跌幅
度。比如，观看时长涨了 3%，而点赞跌了 5%。此外，这里区分了收益项和约束
项：
 收益项是主要优化目标，比如视频观看时长、个人页停留时长、评论区的
时长等。
 约束项包括各种互动，比如播放、点赞、关注等。约束项使用非线性约束：
阈值内做线性的弱衰减，可以用一些约束轻微的去兑换时长；超出阈值的
做指数强衰减，避免约束项过分被损害。
调参算法主要开发了离线优化使用的各种超参优方法，包括交叉熵算法
(Cross-Entropy Method,CEM)、进化策略(Evolutionary Strategy,ES)、贝叶斯

优化 (Bayes Optimization) 、高斯过程回归 (Gaussian-Process
Regression,GPR)。这里，主要介绍下实践中常用的 CEM 算法，右侧图例给出
了该算法的工作流程：从参数初始的高斯分布出发，一般均值选为线上基线参数，
方差手动设置，然后根据该高斯分布随机生成 N 组参数，每组参数都做在线 AB
测试、收集反馈、计算 Reward，选择 Reward 最好的 TopK 组参数，并统计着 K
组参数的均值和方差，并对方差做微小扰动(防止过早陷入局部最优)后得到新的
高斯分布，根据新高斯分布继续采样获取新样本...经过若干次迭代，最终会收敛
到一组较好的参数。该算法的优点是简洁、高效，超参很少；0 阶方法，TopK 选
取只依赖 Reward 的序，不需要对 Reward 的数值大小进行建模，对噪声更近鲁
棒；参数通过高斯分布扰动探索，偏离基线越多的参数选中的概率越小，线上指
标相对平稳。
在实践中，困扰比较多的是噪声。噪声主要来源是数据稀缺和稀疏 label。比如把
5%的流量分 100 组，相当于十万量级的用户几小时的样本量只能生成一个样本
点，并且每组参数只相当于线下 1/2000 的流量，这么小的流量做 AB 测试方差

会比较大。上图右侧展示了“随着分组数的增加，不同互动类型的波动”，如播
放量波动范围 0.4~1.2%，点赞量的波动会更大一些，因为稀数 label 的波动性可
能会更大一些。
相应地，降噪方法包括：增加探索组的流量、减少分桶数；增加每次累计的样本
量，如从两个小时的累计样本量增加到四个小时的累计样本量；用 PV 粒度替换
UV 粒度分桶，因为一个组 UV 可能就几百万，而每个用户每天会有几十刷，使用
PV 样本量就翻很多倍，所以使用 PV 的方差也更小，图中红线给出了按 PV 采样
分桶得到的方差，可以看到，方差都更小些。
除个性化排序场景外，我们也在其余更多场景尝试了超参优化方法，比如，召回
源配额分配时，主要调控召回源的数量多少、耗时及总收益的最大化；粗排和精
排的排序权重参数；Ensemble Sort 的排序权重；重排的多样性权重参数等。在
线多场景联合调参，精细寻找系统最优。
此外，考虑人群和上下文的个性化和场景化调参，比如通过一个广义线性模型来
根据特征计算参数，类似 Contextual Bandit；引入用户画像特征，比如年龄、年
龄段、性别；还有上下文特征，比如一天的上午、中午、晚上来刻画这些参数的
变化。这样，需要调节的参数就从个性化的权重参数变成了各个特征的权重。
上线效果：在排序权重参数优化场景，提升 App 时长 0.5%
04
重排序：Listwise、强化学习和端上重排序
介绍完精排，接下来介绍重排序相关部分。相比精排，重排序最大的特点是需要
考虑视频之间彼此的影响，即用户可能因为看了 A 视频对 B 视频可能会促进、也

可能会有损，比如看了一个风景的视频，紧接着再看一个风景的视频，它的效用
就会降低，而如果看一个差异较大的互补的视频，有可能会提高它的效用。
1. Listwise Rerank
首先，采用类似 Learn2Rank 的学习方案：对精排层返回的 Top6 视频做 Rerank，
使用 transformer 进行建模，刻画视频间相互影响：把 6 个视频做特征抽取后，
经过 transformer 层的 encoder 得到 embedding 表示，再经过评估层得到输出，
损失函数采用 Weighted Logloss。实践中，前序视频对后序视频的播放和效用
有影响，比如在上下滑场景，看了前面的视频可能会对后面的视频有影响，但看
了后面的视频不会对前面的视频有影响。但作为一个组合收益，需要前后组合决
定总收益。比如把五个爱看的视频和五个不太爱看的视频放在一起，如果前五个
全是爱看的，而后面五个全是不爱看的，可能用户翻到第七个视频时，就会退出；
但如果把爱看和不爱看的夹杂着放，有可能用户能看完十个视频，可能还会从之
前五个不爱看的视频里探索出一个新的兴趣，即这种组合的收益会有更大的提升
空间。
对于离线效果评估，我们对比统计了“做 transformer 后推荐结果的 AUC”和
“DNN 基线，即精排模型给出排序结果的 AUC”，从上图左下角表格可见：在
不同位次上，从第 1 位到第 6 位，随着位次增加 AUC 逐渐提升。即考虑前序视
频对后序视频的影响，能改善后序视频的推荐体验。
上线效果：App 时长+0.3%，互动持平或上涨
2. 强化学习 Rerank
上述介绍的 Learn2Rank 方式的 top6 重排序整体优化空间较少，所以我们又尝
试了使用强化学习做 Rerank。
具体做法是从精排后的 Top50 里选出 Top10，通过序列决策的过程，从前向后
依次贪心的选择动作概率最大的视频。比如上图左上角表示的过程：有 4 个候选
集 a、b、c 和 d，先选出排序分最大的 b，把它作为一个上下文特征；然后选出
第二大的 c，然后把选出的 b 和 c 作为上下文特征；再选第三个视频......选择视
频时，reward 会兼容相关性、多样性及一些约束项。
根据序列决策的思想，上图右侧给了一个 LSTM 网络结构来建模前序视频对后序
视频的影响。DNN 网络同时输出 Policy 和状态值函数 Value，这里 Policy 是通
过 Softmax 计算选择每个候选视频 (Action)的概率后，选择概率最大的视频。
Policy 具体实现上，在挑选每个位置的视频时，把前序视频的作用编码成一个
embedding 向量，对候选集的每个视频做预估和 softmax 变换，最后会选择最
大的。
选用策略梯度法解决该强化学习问题：对策略取 log 后求梯度，再用 Advantage
函数加权求和：
其中 A π (s t ,a t ) 是 Advantage 函数。进一步，使用 GAE 降低偏差，通过 reward
和状态值函数组合得到 GAE：
上线效果：App 时长提升 0.4%，新设备次留+0.4pp

具体训练时，没做 experience-reply，因为不同用户的样本间天然没关联，所以
不需要额外的去关联。而是使用一个仿真器帮助训练，好处是使用仿真器做探索
学习效率更高，基于仿真器做离线学习，再上线会更安全，使用 On-Policy 相比
Off-Policy 训练会更稳定。上图右侧给出了一个排序策略作用后，不同的模式样
例：离线日志有用户快速划过、播放、播放后的点赞行为，通过一个较好的策略
能把好模式排在前面。
3. 端上 Rerank
上述介绍的是在云上服务器做 Rerank ，同时，我们也尝试了在客户端上做
Rerank。
在端上做 Rerank 的具体方案是一次用户请求下发更多视频到客户端，比如从一
刷下发 6 个提升到 20 个；在端上部署一个轻量的模型，根据用户对每一个视频
的最新反馈实时调整，每一滑实时从候选集中选择最佳的视频。端上 Rerank 的
优势有如下几方面：
 用户对当前视频的反馈，可以立刻影响 Next-One 推荐，不必等到
PageSize(=6)再去服务端刷新；
 上下滑场景替换后续视频后，用户无感知；
 可以利用端上丰富的特征，包括一些数据量大、隐私等不便于上传到云上
的特征；
 端上实现了实时推荐，所以 PageSize 可以变大，降低对服务端的请求压
力和资源消耗。
具体结构设计如上图右侧图例，模型用 TFLite 格式，客户端启动时一次性拉取；
在每刷请求视频时，把存储在 PS 服务端的 SparseFeatureEmbedding 及其他特
征一起下发至客户端。
上线效果，App 时长+1%，服务端 QPS-13%，互动指标也显著提升。
从云端下发到客户端的特征，包括用户特征、视频特征、用户实时反馈序列、视
频服务端的各种静态模型预估值和设备特征等，如上图左上角表格所列。
网络结构如上图右侧所示，通过两个 transformer 结构分别建模用户实时反馈和
视频 ID embedding 序列、用户实时反馈和 Xtr 序列；使用 Multi-Head
Self-Attention 结构构建高阶特征交叉；损失函数选用加权 LogLoss：
05
总结和展望
以上介绍了快手在多目标排序方面的部分工作，接下来给一个总结和展望，包括
粗精排阶段的多目标排序、在线自动调参和重排序几方面。
在多任务学习方面，后续打算解决的问题包括：训练过程不同目标间的差异导致
的梯度冲突问题；帕累托最优的权重设计，在训练过程中根据训练目标难易程度
动态调节权重；对 MMoE 升级，比如用 Task-Specific Expert。
在线自动调参方面，后续打算解决的问题包括：对稀疏 reward 采用更好的处理
方式，对噪声做更好的抗性处理；优化留存等更稀疏更有挑战的目标；把交叉熵
这种 0 阶方法升级到 1 阶。
在重排序方面，后续的工作计划：用 Beam-Search 替代贪心搜索，控制线上耗
时；在重排序过程，更好的融合相关性和多样性，端到端学习；除了上述，建模
上文对下文的影响外，上下文协同的收益还有提升空间；如何在端上更好地做实
时行为建模、引入丰富特征、云和端的配合等。
如何将知识图谱引入推荐系统？
分享嘉宾：王鸿伟斯坦福大学博士后

编辑整理：屈垠岑
导读：在信息爆炸的互联网时代，推荐系统可以理解用户的个性化偏好和需求，
帮助用户筛选出自己感兴趣的产品和服务。然而，传统的基于协同过滤的推荐系
统无法解决数据稀疏和冷启动问题。知识图谱是一种表示实体之间的复杂关系的
异构图。在本文，我会介绍如何将知识图谱作为辅助信息引入推荐系统，以解决
传统方法的缺点和提升推荐系统的性能。主要介绍：
 推荐系统
 知识图谱
 知识图谱辅助推荐系统
01
推荐系统
推荐系统的目标是满足用户个性化需求，降低用户筛选信息的难度。推荐系统有
着广泛地应用，在 MDB 的电影推荐中可以推荐更多人喜欢的电影，在 Amazon
的图书推荐会推荐与当前书相似的书，Booking.com 会推荐可能会感兴趣的旅游
的目的地，Quora 上对用户可能感兴趣问答的推荐，Tik tok 上对用户可能感兴趣
的短视频推荐，以及音乐网站对用户可能感兴趣的音乐推荐。
推荐系统有两大任务，评分预测和点击率预测。
 评分预测是给定用户对物体的打分，可以直接地反应用户喜好程度，因此
称为显式反馈（Explicit feedback）
 点击预测是给定用户对物体的点击情况，并不能显式地反应出用户偏好，
因此称为隐式反馈（Implicit feedback），隐式反馈收集难度更低，因此
真实线上环境中常用 Implicit feedback

1. 协同过滤 collaborative filtering
协同过滤（Collaborative Filtering, CF）假定相似用户有相似偏好，根据用户历
史行为算出用户相似度，并用相似度加权平均其他用户的评分来预测该用户未打
分物体的评分。
CF 存在的缺点：
 用户、物体矩阵存在稀疏性，用少量数据预测大量缺失的数据存在过拟合
的风险。
 冷启动问题，难以解决新用户和新物品没有历史数据的情况。
2. CF + Side Information
通过引入辅助信息（Side Information）来解决协同过滤存在的问题，常用的辅
助信息包括社交网络比如微博间关注的关系、用户物品的属性信息、图片文本音
频视频等多媒体信息、上下文信息比如购买时的位置时间信息。
02
知识图谱
知识图谱（Knowledge Graph, KG）也可以看作一种辅助信息，KG 是一种有向
异构图，它的节点表示实体，边表示实体间关系。一个 KG 通常包含多个三元组，
形如（head, relation, tail），表示头实体与尾实体存在某种关系。我们假定推荐
系统中的物品也是一个 KG 中的节点，因此 KG 提供了物品和物品之间的关系。
1. 知识图谱实例
以电影推荐为例，一个用户看过的电影可以靠 KG 中的实体连接到其他电影，通
过合理推断，可以认为用户也会喜欢与该电影紧密连接的电影，因此从电影的属
性和特征出发，一个 KG 可以帮助我们合理地推测用户的兴趣。
以新闻推荐为例，可以通过用户阅读过的新闻实体，利用 KG 重复扩展并连接到
另一条新闻。虽然下图中上下两条新闻字面上没有重合，但可以通过常识知识图
谱进行判断关联非常紧密。
2. 知识图谱嵌入 Knowledge Graph Embedding

知识图谱嵌入（Knowledge Graph Embedding, KGE）可以解决知识图谱作为
复杂图结构难以直接利用的问题，KGE 可以学习 KG 中实体关系的低维向量表示。
常用转移距离模型（Translate Distance Model）
TransE 目标是使 head 实体 embedding 加上 relation embedding 接近 tail 实
体 embedding。
TransH 解决一对多多对多关系，通过计算 head 和 tail 实体 embedding 在关系
embedding 上的投影，计算投影之间的关系。
TransR 通过将 head、tail embedding 转换到 relation embedding 空间，是转
换后的投影满足三元组的关系。
03
知识图谱辅助推荐系统
Knowledge-Graph-Enhanced Recommender Systems
问题定义（Problem Formulation）：给定用户集合、物品集合、用户参与标签
^
，以及相关知识图谱 G，目标为预测用户点击概率 y u v 。
知识图谱嵌入方法分为两类：
基于嵌入方法（Embedding-based methods）
首先用 KGE 的方法处理 KG，得到实体、关系的 embedding，利用推荐系统的
方法得到物品、用户的 embedding，设计一种模型来融合四类 embedding。

基于结构方法（Structure-based methods）
将 KG 和用户物品交互的图结构概括在一个统一的框架下，挖掘图结构信息。
1. Deep Knowledge-aware Networks

embedding-based 方法（ H. Wang, et al. "DKN: Deep knowledge-aware
network for news recommendation." WWW 2018.）
① 框架
给定新闻数据，使用实体链接提取出相对应的实体，利用给定实体取出完整知识
图谱的子图，用 KGE 的方法处理子图，得到实体 embedding。
将邻居实体 embedding 平均得到该实体的 embedding 表示。

 Knowledge-Aware CNN
Kim CNN 用来学习句子的 embedding。给定句子中有 n 个词语，词嵌入维度为
d，使用 3 个长度为 d 宽度为 2 的 1 维卷积核处理词嵌入矩阵，再用 4 个宽度为
3 长度为 d 的一维卷积核处理词嵌入矩阵，对最后一维进行 max-pooling，将池
化结果 concat 后得到的向量作为 sentence embedding。

Knowledge-Aware CNN（KCNN）是对 Kim CNN 的扩展，输入为三个
embedding，包括 word embedding、entity embedding 和 context
embedding。如果 word embedding 中单词对应一个实体 entity embedding 中
对应位置为学到的实体 embedding，如果不对应实体则用 0 来填充。此时的卷积
核高度变为 3。
 Attention-Based User Interest Extraction
给定用户历史新闻数据和候选新闻，判断用户是否对候选新闻感兴趣。先使用
KCNN 的方法学习新闻 embedding，并用 attention net 来判断以前读过的新闻
对候选新闻的重要程度，attention network 通过将向量拼接并经过 dnn 来计算
最后的权重，利用 attention net 的权重加权用户历史数据可以得到用户的
embedding，最后将用户 embedding 和候选新闻 embedding 拼接并通过 dnn
得到点击候选新闻的概率。
② 实验
使用 Bing News 作为数据集，KG 使用微软 Satori。Bing News 数据集中标题平
均词数量为 7.9 个，平均实体数量为 3.7 个。

实验结果如下图，（-）代表没有使用 KG 的方法，可以看到 DKN 方法显著地好
于其他 baseline 的方法。
2. Multi-Task Feature Learning for KG-Enhanced RS
embedding-based 方法（H. Wang, et al. "Multi-Task Feature Learning for
Knowledge Graph Enhanced Recommendation. " WWW 2019）
① 框架
多任务学习框架，下图左为推荐系统的框架，下图右为 KGE 的框架。

由于知识图谱中的实体就是推荐系统中的 item，可以认为它们的 embedding 存
在特定的关系，因此使用 cross&compress units 来建模实体和物品 embedding
之间的关联。其中 cross 操作将计算向量内积得到矩阵，compress 操作通过将
矩阵压缩为向量。
推荐系统用 MLP 处理用户 embedding，并使用 cross & compress 计算物品的
embedding，最后拼接来计算点击概率。
KGE 模块中，使用 cross & compress 处理 head 实体 embedding，使用 MLP
处理关系 embedding，拼接后通过 MLP 计算 tail 实体的预测值，并以 embedding
预测值和真实值之间的差距作为损失函数。
因此，整体的损失函数分为三块：推荐系统的损失、KGE 的损失和正则损失。
② 实验
分别在四个数据集上进行了实验，实验结果好于其他方法。
3. RippleNet: Propagating User Preference in KGs
Structure-based 方法，以跳数来表示用户的兴趣传播，类似于水滴的传播过程，
因此称为 RippleNet 。（ H. Wang, et al. "RippleNet: Propagating User
Preferences on the Knowledge Graph for Recommender Systems.” CIKM
2018.）
① 框架
输入为用户和物品，输出为用户点击物品的概率。利用用户的历史点击数据 v u ，
将 v u 沿着 KG 向外传播，得到历史点的邻节点 t 和关系 r，并利用下式计算邻节
点 t 与候选物品 v 的关联概率。
利用关联概率加权平均得到用户的一阶表示，不断重复传播过程，得到多个用户
embedding，将其相加作为最终用户 embedding，最后使用用户 embedding
和 item embedding 内积的 sigmoid 激活结果作为最终的点击概率。
在给定 KG 和用户物品历史数据时，基于最大化后验概率来计算模型参数，利用
贝叶斯方法将概率公式拆为三项。
第一项为模型参数的先验分布，采用高斯分布作为先验。
第二项为给定模型参数判断观测知识图谱的可能性函数，即通过头实体、尾实体、
关系 embedding 的乘积来模拟出现的概率，如下图公式。
第三项为给定 KG 和模型参数判断用户历史行为的物品点击概率函数，为伯努利
分布，如下图公式。
将概率公式取负对数后得到最终损失函数。
② 实验
实验结果好于其他方法。
4. Knowledge Graph Convolutional Networks
Structure-Based Methods (H. Wang, et al. Knowledge Graph Convolutional
Networks for Recommender Systems. WWW 2019.
H. Wang, et al. Knowledge-aware Graph Neural Networks with Label
Smoothness Regularization for Recommender Systems. KDD 2019)
① 方法
KG 中的边不存在权值，因此引入，通过用户 embedding 和关系
embedding 的内积，将权值引入 KG。
逐层传播的函数如下图，其中 A u 为每个用户 u 的 KG 邻接矩阵， D u 为 A u 的对角
矩阵， H l 为第 l 层实体 embedding，W l 为参数矩阵。

最终点击概率如下图公式计算。
② 实验
实验结果如下图，一般使用 KGCN-sum 的方法效果最好。

5. 比较
在性能方面，KGCN 性能最好，DKN 表现最差。
在可扩展性方面，embedding-based 方法可扩展性更好，因为 embedding 方
法可以复用，而 structure-based 方法在面对新的物品、用户时需要对整个方法
需要重新训练。
在可解释性方面，我们认为 structure-based 方法的图结构比 embedding 更直
观。
04
总结
知识图谱可以作为解决数据稀疏性和冷启动问题的一种新的推荐系统辅助信息，
引入知识图谱辅助推荐系统，可以提高推荐系统的准确性、多样性和可解释性。
蜻蜓 FM 信息流推荐探索与实践
文章作者：季飞蜻蜓 FM 推荐技术负责人
内容来源：作者授权
导读：如今的推荐系统在互联网中随处可见，无论是刷抖音、逛淘宝还是看新闻
背后都有强大的推荐系统的支持。音频行业的内容如何分发？如何提高用户发现
音频内容的效率？蜻蜓 FM 作为国内首家互联网音频媒体平台，在音频行业深耕
了 10 年，对此也有一些沉淀和经验想要和大家分享。
主要内容包括：
 蜻蜓首页场景怎样从人工运营演进到个性化推荐
 蜻蜓信息流推荐由哪些算法组成，彼此怎么配合
 整体推荐系统架构及算法模型如何部署到线上
 蜻蜓信息流推荐场景后续发展的一些思考
01
场景
1. 人工推荐时期
早期蜻蜓首页流量的分发是以模块形式展示，每个模块可配置横排和竖排的个数。
此时只有个性推荐模块的内容由推荐算法生成，其他模块则是由运营人工维护。
模块中的内容需要运营定期进行更换，展示内容的更新完全依赖人工，效率显得
很低。
为了提高运营人工工作效率，我们引入了策略推荐。
2. 策略推荐时期
策略推荐时期运营的工作由之前每天更新模块中的内容，变成了为模块绑定内容
库和选择合适的排序策略。内容库中的内容是由配置的分类、属性动态生成和更
新，运营为单个模块的配置基本可以做到了一劳永逸。
模块之间怎么排序？模块中的内容排序策略怎么选才能收益最大化？成了新的挑
战。
3. 个性推荐时期
通过数据发现个性推荐模块效率高于其他策略推荐的模块，首先尝试了扩大个性
推荐模块中内容的数量，由 3 个变 6 个。验证了对首页整体效果有提升后，把多
个模块合并成一个信息流的个性化推荐的想法应运而生，线上 AB 实验结果表明
信息流的个性化推荐各项指标均高于多个模块的策略推荐。信息流的形态是单排
还是双排？经过 AB 实验，最后选择了效果更优的双排。
个性推荐时期运营对于少数专辑依然会有流量扶持、推广的的述求，在个性化推
荐的基础上增加了投放系统。投放系统中还支持通过不同标题、封面对单个投放
计划生成多个创意，多个创意之间数据表现好的沉淀下来推广到更多的场景中。
运营不再局限于选择内容，更为重要的是重新组织创造了内容，充分发挥出了运
营在想象力、创造力上的价值。
4. 小结
首页场景经历人工推荐、策略推荐、个性推荐三个阶段。策略推荐基本解决了人
工效率问题，个性推荐进一步解放人力的同时也带来了数据指标的显著提升。
02
算法
伴随着首页场景的演进，蜻蜓的推荐算法也在不断的完善和迭代。
1. 推荐算法流程
推荐算法的流程大致如下：内容池中达到推荐标准的内容的有几十万个，召回层
从中选出用户可能喜欢的几千个进入粗排层，召回层的覆盖度决定了整体推荐内
容的覆盖上限。粗排层从召回结果中挑选出几百个给到精排层，粗排层主要为了
减小在线算力减轻精排的压力。精排层选几十个给到重排层，精排层专注于推荐
的准确性。最后，重排层对推荐结果进行重新排序给到用户，这一层兼顾准确性
的同时还需要保证多样性。
级联结构简单，分工明确。兼顾了覆盖度、性能、准确性和多样性。
2. 多路召回
熟悉了推荐的算法的大致流程后，首先，我们来了解一下多路召回。多路召回在
蜻蜓主要分为三类：基于内容、协同过滤和 Embedding 向量召回。基于内容的
召回包括热门、属性、上新策略的召回；协同过滤包括 User Based 和 Item Based；
Embedding 向量召回有 Word2vec 和 Bert。召回环节处理的数据量大，复杂度
不能太高，多路召回的设计可以方便加入新的策略或者算法。我们在实践中发现，
早期建立完善指标，追踪每路召回的效果，有助优胜劣汰；召回的效果并不是召
回算法越复杂越好，不同的业务特点不一样适合的召回也可能不一样，比如蜻蜓
当下表现最优的召回来自 ItemCF 和热门；随着召回的算法越加越多，新的召回
需要与现有召回有差异性、互补才会有存在的价值。召回环节还会承载业务及平
台建设的使命比如用户和物品的冷启动、业务流量扶持等，召回环节的好坏直接
决定了后续环节的上限。
3. 粗排
接着是粗排，早期的推进系统中粗排常常用简单的融合策略进行，实践中发现粗
排中引入算法是值得的。策略的组合较多测试周期长，双塔模型的应用既解决了
多路召回组合的效率问题，又避免了精排的性能问题。
双塔模型扩展性好便于自由添加自定义的网络，User 和 Item 塔解偶，同时点积
的计算所需算力小。在蜻蜓为了保障粗排推理数据的实时性，User 向量的生成及
点积的计算都是实时的。粗排的加入在数据指标指标上也获得了不错的收益，其
中信息流 UV 收听转化率增加了 3.54%，人均收听时长增加了 5.44%。
4. 精排
然后是精排，精排往往在推荐系统中最受关注，精排直接对准确性负责，相对容
易拿到直接的收益。我们在精排的投入相对较大，从中获得的收益也相对颇多。
蜻蜓的精排经历了三个阶段：线性模型的逻辑回归和 FM、树模型的 XGBoost 以
及神经网络模型的 DeepFM。
XGBoost 迭代时间最久，其中模型参数的调优、特征挖掘（包括交叉特征和实时
特征的引入）、日志数据的准确性优化以及实时排序，这些整体给在线收听数据
带来了近 35%的提升。XGBoost 之后我们尝试过许多模型包括 XGBoost+LR，

Wide&Deep 等均没有取得预期的收益，在 DeepFM 上的尝试探索则获得了 9.3%
收听相关指标的提升。DeepFM 顺理成章地成为了精排模型的主力，也开启了蜻
蜓推荐算法在深度学习道路上的大门。
5. 重排
最后是重排，重排跟召回一样承载了很多业务向的目标和期许。这里主要讲一下
多样性，提升多样性一方面希望打破推荐系统的信息茧房，另一方面也希望提升
用户的长期使用体验。开始是通过打散策略实现，当前主要是 MMR 和 DPP 两个
算法在尝试迭代，实验中 MMR 表现优于 DPP，这里简单介绍一下。MMR(Maximal
Marginal Relevance)最大边际相关性算法，保证相关性的同时提高多样性。通
过λ参数来调节多样性和相关性的权重，λ越大相关性越高，λ越小则多样性越高。
MMR 算法中有两个相似度，用户和物品的相似度用精排的打分值来表示，物品
之间的相似度基于协同过滤的物品相似度。重排的预期是达到帕累托最优，在其
他指标都不降低的情况下，提升多样性指标。
最终也达到了预期，人均曝光专辑数量增加 8.84%，人均收听二级分类数量提升
7.06%。
03
架构
1. 整体架构
推荐系统能高效稳定地运作，离不开优秀的架构支持。蜻蜓的推荐架构是典型的
三层架构，即离线、近线、在线三层。离线层负责数据的处理、模型的训练以及
数据报表；近线层实时特征处理、召回、粗排；在线层承载了用户请求响应、精
排、重排以及投放系统等业务逻辑。
2. 算法模型部署
算法模型如何高效地部署到线上？是算法和工程同学共同面临的挑战。开始的时
候我们的模型预测服务和推荐 API 都是用 Golang 实现，特征的获取处理在推荐
API 测完成，模型预测服务负责加载模型并对对获取的数据进行预测。在线特征
拼接处理使用 Golang，离线特征拼接处理使用 Scala，跨语言的对齐与校验耗费
了开发很多的时间。离线和在线能否公用一套算子进行特征的拼接与处理？为此
我们将模型预测服务切换成了 Scala 的 Play 框架，基于 Scala 开发出了一个
feature 获取处理的库，给 Spark 和 Play 共同使用，保证了特征处理逻辑层面的
一致性。同时，模型预测服务中增加了对多模型、多版本的支持以及模型的自动
更新进一步提高了模型部署的效率。
04
展望
首页信息流推荐从 0 到 1 建立起来，迭代、优化、完善到现在取得了不错的增长，
面向未来还有许多工作需要我们去尝试和探索。内容方面，如何帮助新品内容一
步一步变成曝款，产品、研发、运营如何合作建立出完善的内容生态系统；业务
方面，信息流支持的业务越来越多包括专辑、直播、听单、节目、广播等，多业
务如何更好的融合在一起也是一个挑战；用户方面，新用户的冷启动，沉默用户、
潜在流失用户如何激活还有很长的路要走；算法方面，模型的训练如何做到更加
实时，多目标的排序是否有望代替单目标排序。这些都将是我们接下来探索的方
向。
算力经济时代：阿里展示广告引擎的"柔性"变形之路
文章作者：阿里展示广告技术团队
内容来源：作者授权
序曲：纵观这两年业界技术的演化趋势，几乎主流的团队都已经完成了深度学习
为代表的技术升级，进入到算力吃紧、模型红利放缓的新瓶颈期。去年在《深度
学习推荐系统》序言一文中，朱小强老师对工业级深度学习技术迈入新的 2.0 进
阶阶段的特征做过一些探讨：
可以预见，在工业级深度学习 2.0 阶段，技术演进的模式将再升级：从算法视角
的实践和问题驱动，进一步拓展到更宏大的技术体系整体思考：领域问题特性、
数据、算力、算法、架构及工程系统等将被纳入统一的思考框架中，成为技术创
新的发力点。
从 2018 年开始我们团队就开始做相应的布局。除了在算法层面持续开辟纵深战
场外，对于"算力"这件事我们做了大量细致的工作，这几年支撑了我们的核心广
告模型一路从 DIN(2017) 、 DIEN(2018) 、 MIMN(2019) ，升级到今年的

SIM(2020)、CAN(2020)。值得一提的是，在业界普遍陷入滞涨的这个阶段，今
年我们一年内完成了 SIM 和 CAN 两个大版本主模型的研发和全量上线，同时叠
加在主模型之上的多场景、多目标建模也都有所突破，核心场景取得了 CTR/RPM
累积提升超过 20%的巨大收益，这是继 2017 年 all in 深度学习之后我们达到的
第二个技术创新小高峰。
印象中直到今天，还有不少同学对我们宣称 DIEN 这样的复杂模型能够在广告系
统全流量服务报以怀疑的态度。的确，在这种大规模的广告系统中支持
GRU-based 模型的在线实时 inference，即使是 18 年模型生产化之初我们的工
程同学也是有担忧的。然而实际情况是，相比于今年的 SIM 及 CAN 模型而言，
DIEN 的 inference 算力需求不过是开胃小菜了。另一方面，不仅仅是 ranking
模型，我们的广告召回模型、粗排模型，甚至后链路的机制策略、rerank 模型等，
都面临着相似的恐怖算力激增挑战。如何解决这个问题呢？18 年的时候我做过一
个断言：
占领算力效能的制高点，将成为头部团队在工业级深度学习 2.0 阶段算法继续创
新突破的胜负手。
幸运的是，经过近 3 年的辛苦跋涉，我们终于在转角处闻到了蔷薇的花香。近期
我们陆续开始把一些成型的工作总结和分享出来，希望能够给大家带来一些启发，
如：model design 和 model inference 相结合的 MIMN；算法与系统 co-design
思路下重新设计的粗排系统 COLD；以及被今年 DLP-KDD 2020 收录且评选为
best paper runner-up 的"个性化算力"分配算法 DCAF。
如果说以上工作更多 focus 在局部模块进行了 algorithm 和 system 的
co-design，那本文则是我们这一思想的更深度推进：进一步发展"个性化算力"
技术，将算力融合到广告引擎的设计中，形成更全面立体的算力解决方案，同时
也给古典的引擎系统赋予了全新的动力。"算力经济时代" 看起来有点标题党，但
我认为这是对算力在这个时期技术版图中重要性的最好注解了。
以下是本文的具体内容，来自阿里展示广告技术团队 ( 致谢相关兄弟团队的大力
支持 )。友情提醒，它解决的不是传统的算法或者引擎领域问题，因此不一定适
合所有读者。哪怕是广告、推荐领域的从业者，如果没有接触或者思考过这类命
题，亦或是对引擎系统的细节了解不多，读起来也会有点艰涩。
01
导读
时间的焦距拉到 5 年前，谁也不会预料到以深度学习代表的 AI 变革，对业界技术
的重塑力度会如此之大、如此之深。这背后的一个重要变量是"算力"。随着深度
学习技术的大量创新，广告、推荐等在线引擎系统中的架构和算法复杂度迅速飙
升，对算力的需求出现了爆发式的增长。以阿里展示广告系统为例，相比于 5 年
前的精排模型，其在线算力的需求暴涨了近 2 个数量级[2,3,4]。如此惊人的算力
需求增速，仅仅靠 GPU/NPU 等硬件的演化已然不足，更不用说硬件本身已经在
逼近摩尔定律极限。
面临着算力供给触及瓶颈的巨大危机，我们看到不论是工业界还是学术界都在积
极寻找解法。阿里展示广告团队从 18 年起就开始布局算力效能技术的研发，目
前已经迈入了第 3 代算力效能体系的阶段：
 算力效能 1.0 阶段 ( 2018 )：聚焦单点工程优化及模型瘦身优化等技术

 算力效能 2.0 阶段 ( 2019 ) ：将 Model Design 和 Engineering
Optimization 结合，通过算法-工程 Co-design 方法论的深度实践，带来
了显著红利
 算力效能 3.0 阶段 ( 2020 )：从引擎单模块进一步拓展到系统全链路，用
"个性化"算力的思想去重新审视和改造了整个广告引擎系统，为古典在线
引擎注入了新的活力，让它变得更加"柔性"：充分提升给定算力的性价比，
让其在面临任意复杂、动态的业务需求和流量环境时能够自适应地做到算
力最优使用。
结合了算力效能视角的展示广告引擎，我们命名为 Transformers（致敬变形金
刚），本文将分享我们的实践经验和思考。值得一提的是，算力效能感知的柔性
广告引擎 ( Computing Power-aware Transformers Engine ) 今年已经真正
落地于阿里展示广告业务：
 业务效果上：仅广告精排的个性化算力优化就能够带来 RPM 持平下算力
节省 25%、同等算力下 RPM 提升 2%的收益[1]；
 系统能力上：具备柔性能力的广告在线系统平稳地应对了双十一的各种流
量波动和日常的各类系统异常，大幅提升了系统稳定性和运维效率。
02
开胃菜：先来看看算力分配这件事
我们可以从微观和宏观的层面来理解在线系统的算力分配问题。
 微观上：在某一时刻，不同流量的价值不同，算力消耗也不同——也就是
算力性价比不同。我们可以根据算力性价比，为每个流量分配更合理的算
力 ( 计算资源/Latency 约束等 )，从而在系统总算力的约束下，实现业
务收益的全局最优。
 宏观上：由于流量大小和分布会随时间不断变化，那么在总算力约束下，
算力分配策略也需要动态调整，来保持业务收益的动态最优。这种微观和
宏观相结合的视角，能够有效地帮助我们拆解问题。
图 1：算力分配的微观&宏观视角
Transformers 引擎的核心理念，就是将算力分配纳入到系统的设计范畴。对于古
典广告引擎而言，其使命是确保引擎系统能够准确地实现和运行业务逻辑。对任
意一条流量请求，原则上执行的计算逻辑是一致的 ( 这里仅考虑算力差异化视
角 )。在资源充足时这是合理的策略，但在算力紧张、需要腾挪资源甚至算法策
略降级才能在特定的系统资源约束下完成业务逻辑时，这背后就隐藏着巨大的效
能空间。以广告系统为例，我可以选择：
 开足算力对每条流量做最精细化最复杂的计算，对超出系统算力的部分流
量做丢弃操作；
 对不同价值的流量做差异化的算力规划，确保系统对每条流量都有效服务。
哪种策略是最优？这就是 Transformers 引擎的目标：在有限的资源中做"柔性"
算力伸缩，确保业务收益最大化。
03
形式化：算力分配的数学化表达
我们来具体分析宏观、微观两个层面的算力分配问题。首先，我们需要具象化地
理解"算力"。系统算力往往被计算相关的参数控制，包括算法策略参数 ( 检索
token 数/打分 doc 数/模型版本等 ) 和系统性能参数 ( 线程数/缓存规则等 )，
在线系统通常会包含很多这样的算力参数。我们用"档位"来描述这些算力参数的
取值，不同档位代表不同的算力消耗。档位选择的过程就是算力分配的过程。对
某个算力参数来说：流量 i 需要在 K 个候选档位中选择一个档位，其中第 j 个候选
档位 action i , j ，将会带来 cost i , j 的算力消耗和 value i , j 的业务收益。
 微观层面：对某一时刻 t，若用 s(i)表示流量 i 选择的算力档位，那么该时
刻的算力分配问题，可以描述为该时刻的 N(t) 个流量的总算力消耗
在不超过总算力约束 C 的前提下，如何最大化总业务收益
的问题。
图 2：算力分配问题定义
 宏观层面：对不同时刻 t，流量大小 N(t)在不断变化，但系统的总算力约
束 C 通常会相对稳定。我们将某一时刻在约束下的
策略推广到所有时刻，理论上就可以实现动态的算
力最优分配。
在下文中，我们将分别介绍特定时刻下的算力分配算法和考虑宏观变化下的系统
实现。
04
静态算力最优分配：DCAF 算法
首先我们来看某一时刻的算力最优分配求解。延续上文的形式化定义，将算力配
置选择 s(i)用 one-hot 向量的方式表示为待优化变量 xi ，即：
则优化目标和约束定义如下：
1. Lagrangian 求解思路
这里为大家介绍我们团队自研的 DCAF 个性化算力分配算法。我们使用
Lagrangian 方法来求解这个带约束的优化问题，引入额外变量λ：
并相应地构造对偶函数 g(λ)：
可以看出，对于任意给定的 λ ，对偶函数 g( λ ) 在
时最优。
注意：每个流量 i 的最优档位 s(i)可以独立求解，因此非常适合在实际的分布式系统
中进行线上服务。
2. λ的含义：算力边际收益的约束
对于流量 i ，在给定 λ 下，若档位 j 优于档位 j' ，则有
，即 △ value j ' → j /△ cost j ' → j ＞
λ。也就是说：一个档位相比另一档位更优，当且仅当其算力边际收益△value/
△cost＞λ。因此，可以认为λ是对算力边际收益的约束。
图 3：算力消耗-收益曲线 ( 边际收益递减 )
不难看出，λ越小 ( 放宽性价比约束 ) 最优档位 j 就越大，对应的算力消耗和业
务收益也越大，反之亦然。因此，总消耗和总收益会随着λ减小而单调递增，而整
体算力性价比会随着λ减小而单调递减。
3. λ的求解：算力约束的临界状态
知道了λ的含义，接下来看使得 g(λ)最优的λ如何计算。由单调性和算力约束可以
想到，尽可能地多用算力可最大化价值。而稍加整理也能看到 g(λ)的现实含义就
是"已使用算力的总收益"+"λ倍的剩余可用算力"。通过分析λ减小/增大时这两部
分的增减量，可以发现当算力恰好被用完时，此时 g(λ*)取
到极大值。由弱对偶性可知，此时的 g(λ*)对应的解也正是全局最优解。
因此，在离线静态求解λ时，利用算力总消耗随λ减小而单调增加的性质，我们只
需通过二分查找去找到最接近算力约束 C 的λ即可。而面对在线流量的连续变化，
我们也无须每时每刻重新求解λ，只需根据每一时刻的算力消耗和算力约束的相对
关系，对λ进行实时微调即可——全局维护当前时刻的λ t 并统计当前时刻的总算力
消耗。若当前时刻总算力消耗超过了 C，则在下一时刻通过上
调λ t + 1 来降低算力消耗从而满足约束，反之亦然。由此，在流量平稳时，通过动态
维持总算力消耗恰好满足算力约束，几乎可以保证每时每刻系统都处在最优的算
力分配状态；而当流量突变时，系统也可以在较短时间内调整到满足约束的状态。
具体的系统方案将在下面章节展开。
4. 流量价值/消耗预估和最优档位求解
当在线流量 i 到来时，只需要得到各档位预估的流量价值 value i , j 、算力消耗 cost i , j ，
以及当前的λ，就可以计算出最优档位。那么流量价值 value i , j 和算力消耗 cost i , j
如何预估呢？
对于流量价值预估，可以通过分场景或者分用户统计历史 RPM 均值。对于算力
消耗预估，取决于算力参数的选取，通常只要找到可量化的算力指标并且在档位
间相对可比即可 ( 例如，召回阶段选取检索标签数、海选广告数作为参数，预估
阶段选取特征数、广告数作为参数 )。以精排阶段的算力分配为例，个性化算力
分配可以在广告 RPM 收益不折损的情况下，节省 25%的精排打分算力。而相比
不做个性化算力分配，在同等算力下可以提升广告 RPM 约 2%。个性化算力分配
为业务增长打开了显著空间，并且该算法方案不局限于单个模块、单个算力参数，
可以推广到整个系统。关于 DCAF 算法的更多细节，可以参见我们的论文[1]
05
动态算力最优分配：AllSpark 架构
1. 实时反馈调节
以上介绍的 DCAF 算力分配算法，可以在微观层面解决某一时刻的算力最优分配
问题。该方法如果推广到所有时刻，在宏观层面实现动态的算力最优分配，关键
点在于让"作为算力性价比约束的λ"动态保持最优——λ过大则有可能算力用不完
出现浪费，反之λ过小则有可能超出算力约束。上文已经提到了"根据每一时刻的
算力消耗和算力约束的相对关系，对λ进行实时微调"的思路，那么就需要让在线
系统具备实时反馈调节的能力，一方面争取让算力"恰好用完" ( 既满足算力约束
又不浪费 )，另一方面确保系统稳定可用 ( 对于高可用低延时的广告引擎系统来
说，"算力约束"不仅指的是计算资源的约束，还包括了 Latency 的约束 )。因此
我们选择了"模块调用失败率" ( 由资源不足和其他异常导致的调用超时和错误 )
作为主要调控指标，根据实时反馈的模块失败率来调节全局的λ，从而实现动态的
算力最优分配。当然，这里的调控标的指标在不同的引擎系统中可以选择不同的
锚点，一个可供参考的原则：选择对算力的波动最敏感的系统指标。
2. 系统设计实现
DCAF 算力分配算法中的λ、最优档位 j 是针对每个算力参数的，也就是这个参数
在所有流量上共享一个全局的λ，也可以认为所有流量的平均档位对应一个全局的
λ。为了便于理解和简化实现，在线系统可以考虑直接对每个参数的平均档位进行
实时调节。另一方面，为了实现系统整体的算力最优分配，系统的每个模块都定
义了不止一个算力参数，这些参数如果分别独立地自我调节，一是非常复杂，二
是不容易形成全局最优。因此真实场景中的算力参数设计需要考虑更加全面。例
如我们采用了模块失败率作为主要调控目标，那么就可以把同一模块内所有按失
败率调节的算力参数聚合成一个调控单元，一个调控单元由一组 { 调控目标、调
控策略、平均档位 } 组成，单元内的所有参数共享调控策略和平均参考档位。
再回到系统设计。实时反馈调节系统可以认为是在线引擎的非侵入式控制器，它
既是一套独立的框架，也能够与在线引擎系统密切配合，共同实现算力调节的能
力。我们将整体框架取名为 AllSpark ( 来自于《变形金刚》中的"火种源"，能够
赋予机械生命，使它们具有变形的能力 )。AllSpark 框架主要由四个部分组成：
调节链路、反馈链路、控制面板、监控视图。
图 4：AllSpark 动态算力框架
 调节链路：调节链路包括中控 Controller 和嵌入在应用模块中的 Agent。
Controller 收集所有模块一段时间内各种调控目标 ( 失败率 / Latency /
QPS / CPU 水位等 ) 的实时指标，并根据一定的调控策略给出每个调控
单元的平均档位建议，起到动态调节λ的作用，同时让各模块满足算力和可
用性的约束。Controller 作为算力调节的中控，需要做到稳、准、快。为
了满足这些要求，Controller 支持了 PID 控制算法、单步控制、个性化规
则等多种调控策略，以及去噪、防抖等平滑机制。Agent 是嵌入在每个应
用模块中的 SDK，它通过从 Controller 主动拉取该模块所有调控单元的平
均档位等调控信息，来确保该模块在平均档位的建议下安全运行。同时，
Agent 还为每个模块提供了个性化调控的 API，可以让各模块自己实现流
量粒度的各种个性化算力分配策略 ( 例如 DCAF 算力分配算法和基于用
户质量分的分配算法等 )。甚至还可以在 Agent 中实现下游模块的流控能
力。可以看出，Controller-Agent 的两级调控机制，既保证了每个模块整
体满足算力约束，又能够针对不同流量做个性化的算力分配。
 反馈链路：各模块用于算力调控的指标会通过反馈链路采集到 Controller。
反馈链路包括采集和存储两部分，我们使用 Prometheus 收集应用容器中
的状态数据，写入时序数据库存储，并为 Controller 提供查询接口。整个
链路目前具备 5s 左右的反馈时效。
 控制面板：控制面板是人工介入 AllSpark 的接口，用于分模块/调控单元/
场景多层次地配置和管理 { 调控目标、调控策略、算力档位 }，可以根
据情况决定每个参数使用固定档位还是动态档位，并且通过版本控制以及
分集群的发布管控，实现可灰度、可回滚的能力。
 监控视图：可以想象，整个系统中数以百计的算力参数实时动态地变化，
如果没有完善的监控和异常发现能力，系统随时可能陷入失控的状态。监
控视图用于透出每个算力参数的实时/历史平均档位，并且将档位的异常变
化对接到监控系统中，让整个 AllSpark 系统具备可观测的能力。
3. 系统柔性表现
我们以双十一大促当天展示广告系统的表现来说明 AllSpark 系统的柔性能力。展
示广告场景在双十一零点高峰时段有十倍于日常流量的洪峰。零点之后，流量呈
阶梯状逐步回落。往年为了扛住流量洪峰，需要手动推动策略降级预案，并且需
要根据流量的变化推送不同版本的降级预案，实现流量和算法策略的最优组合，
来确保业务收益最大化。问题在于人工操作的成本很高，风险也很大。AllSpark
的上线使得双十一的保障有了很大改观。零点时段只需要推送一个基础版本的降
级预案保护，然后通过 AllSpark 根据流量的变化自适应地调节算力，就可以实现
系统在高水位下的平稳运行，同时确保了零点黄金时段的业务效果。事实上，仅
零点附近 1、 2 个小时的系统服务能力增强 ( 用更强的算法策略服务更多的流
量 )，就给我们的广告收入创造了千万人民币规模的收入增量。
图 5：2020 双十一大促系统表现示意图
除了能够在大促期间柔性应对各种流量洪峰之外，AllSpark 在系统的日常稳定性
保障上也发挥了重要作用。当系统偶尔出现局部模块的超时抖动时，AllSpark 能
够自动降低问题模块的算力负载、加速问题恢复，从而将故障隔离在局部，确保
系统整体的健壮可用。
06
Beyond 算力：再看 Transformers 柔性引擎
个性化算力分配算法+自适应动态算力系统相结合，使得广告引擎系统具备了柔性
能力。这样的系统就像变形金刚一样，能够自动变形成最适应环境变化的状态，
因此我们也把被赋予了柔性能力的在线系统称作 Transformers。事实上，跳出算
力视角看 Transformers 柔性系统，它同样赋予了更多的想象力和可能性：
 多场景调控：Transformers 不仅能在时间维度的静态和动态层面实现算力
最优分配，还能够在空间维度的多场景复杂业务系统中起到算力调控的角
色。由于不同业务场景的流量规模和流量价值差异很大，从安全隔离的角
度通常做法是分场景独立地部署系统。那么如何为每个场景分配合理的算
力并且动态维护最优呢？这往往很难，而且对一些场景快速变化的响应速
度是不足的。Transformers 给我们提供了一条新的解决方案：无须多场景
独立部署，由一套统一的系统 ( OneEngine ) 高效承接各种异构的流量，
从而可以自然地将 DCAF 和 AllSpark 的能力从单场景推广到多场景，多
场景资源共享的同时实现跨场景的全局算力最优分配、业务收益最大化，
以及系统整体平稳可用。
 业务系统大脑：Transformers 柔性系统区别于传统的负载均衡、自动化限
流降级等系统层面的解决方案，它站在业务系统的全局视角，追求算法策
略的算力最优分配、业务收益最大化，同时让系统在计算资源利用率、
Latency 等系统指标上达到最优平衡。可以看出，Transformers 实际上扮
演了业务系统运行时大脑的角色，这也是我们对在线系统未来演进方向的
判断和探索。
Reference：
[1]. Jiang et al, DCAF: A Dynamic Computation Allocation Framework for
Online Serving System
https://arxiv.org/abs/2006.09684
[2]. Pi et al, Search-based User Interest Modeling with Lifelong Sequential
Behavior Data
[3]. Wang et al, COLD: Towards the Next Generation of Pre-Ranking System
[4]. Zhou et al, CAN: Revisiting Feature Co-Action for Click-Through Rate
Prediction
https://arxiv.org/abs/2011.05625v1
原文链接：
https://zhuanlan.zhihu.com/p/340467381
阿里定向广告智能投放技术体系
分享嘉宾：靳骏奇博士阿里巴巴算法专家

编辑整理：李春雷
导读：随着经济数字化地快速发展，互联网广告在赋能商家营销、帮助消费者高
效了解商品和服务、以及商业平台的变现等方面扮演着越来越重要的角色。互联
网广告生态中，广告主通过付费在媒体上对目标用户进行营销信息传达来完成营
销过程。其中，广告主通常希望在有限的资源投入下最大化营销效果。然而流量
环境、其他参竞广告形成的竞争环境的复杂性、以及广告投放策略中出价、目标
人群、资源位、投放时间等变量的巨大组合复杂度，使得最优广告投放策略的计
算与执行充满了挑战。通过本文，我们将从更好地帮助广告主做营销的视角出发，
比较系统地介绍阿里妈妈定向广告团队基于广告主投放需求不断技术创新，建立
起的一套持续演进的广告智能投放体系，具体包括预算约束下的报价策略、多约
束下的报价策略、合约保量报价策略、基于长期价值的序列投放报价策略、跨渠
道智能投放策略等核心技术能力的算法与实践经验。
01
背景介绍
今天主要分三个部分，第一部分先介绍广告业务的背景，第二部分会沿着如何帮
助广告主更好地做好营销的历史脉络，讲解智能投放体系和技术的演进过程，最
后会给出整个演进的总结，以及对未来的展望。
1. 广告业务背景概述
首先广告是什么，我把它抽象成了这样三个部分，在广告生态里，包括广告主，
媒体（或者广告平台）和用户。广告的逻辑就是广告主在媒体上付费，通过媒体
对目标用户进行营销信息传达，影响用户，让用户购买广告主的商品，形成信息
和金钱的流动，也形成用户广告之间物质的流动。
作为一个广告平台来说，在中间起到了一个很重要的桥梁作用。一方面是要能够
给广告主提供足够多的功能，让广告主表达诉求，然后广告主也要通过合适的方
式向媒体付费。
另一方面，媒体还要基于广告主设定的策略，决定把广告投放给谁。所以媒体在
中间起到桥梁的作用，要设定好广告对接机制，向广告主售卖的机制，以及把广
告主的物料用怎样的投放策略投放给用户。
为什么需要这个机制？因为流量类型多种多样，售卖的时候，既可以按点击去卖，
也可以按展现去卖。卖广告的时候，可以卖给品牌类广告主，或者卖给效果类广
告主。另外卖流量的时候，怎么去收费呢？
其实这些问题都是需要去想清楚的，因为只有把这些事情想清楚了，这个商业模
式才能够确定下来，才能够迎合当前市场的整体需求。
这里要考虑的角度是两方面，一方面就是媒体自身业务，要思考它的发展，然后
去设计符合媒体自身的机制，包括商业化率，如何去介入，整个坑位的布局，出
价，溢价等等。另一方面就是广告主方面机制的考虑。媒体以什么样的方式给广
告主定价？广告主是手动类的出价？还是以合约的方式，让平台来去帮广告主计
算出价等等。这两方面都有非常多的概念要去考虑，才能把商业模式确定下来。
除了考虑机制之外，还要去思考这个平台如何帮助广告主选择合适的广告投放策
略。
场景一：CPM 计划
有的客户说我要以 50 元的 CPM 出价，在手机淘宝上首猜 1 坑投放 3 天，预算
没有上限。这是一个以 PV 曝光为出价的方式购买广告，收费也是要按 PV 的方式
计费。
场景二：合约计划
有的广告主要以 60 元的总价格在 1 天内购买 1000 个展现。广告主不关心单条
流量的情况，只关心整体的投入和产出。在这样的设定下，平台就一定要保证广
告主的投入和产出结果，这种就是合约类的计划。
场景三：序列投放计划
这是我们今年的一个创新：有的客户说要投一个广告计划，这个计划可能投放很
长时间，对用户可能会产生多次的曝光和持续的影响，希望通过这种持续的影响，
能够优化累计转化数。这种在广告策略上不一定追求短期的收益最大化，而是要
去追求一个长期累积的收益最大化。
所以这里会迎合不同广告主的诉求，平台需要具备给出不同的广告投放策略的能
力，提供一个成体系的工具，服务好广告主。
2. 广告业务迭代的历史脉络
阿里妈妈的广告体系也经过了很长时间的积累和迭代。从 2016 年开始，在售卖
机制/投放方式上，从最朴素的 CPM/CPC 类的广告到衍生出来在流量粒度上能够
去预估价值，并且基于预估出来价值去对流量粒度做出价调整，衍生出来
OCPM/OCPC 这样能力。为了保证广告主的结果的确定性，又有了合约保量的能
力。这些 CPC/CPM/OCPC/OCPM 其实还是依托于广告主手动出价，它有运维
的成本。在这个基础上我们又做了升级，让广告主只表达一个整体的投入和结果
的预期，这样平台能够结合预期去自动的帮广告主在每条流量上出价，所以又有
了 BCB ( Budget Constrained Bidding ) ，就是预算约束下自动出价和 MCB
( Multi-Constrained Bidding ) 就是多种约束下的出价。

我们今年有一个新的工作就是叫 Multi-Channel Sequential Budget
Constrained Bidding。我们可以跨各种渠道，通过序列的投放广告影响用户，然
后形成预算约束下的效果最大化，所以整个发展的脉络的能力是不断升级。从优
化目标上，我们也是从最早的优化通用的展现/点击，到优化成交/ROI，到优化电
商系统里面用户对商品的加购/收藏/关注以及任意的后验目标，包括从短期价值
到任意的长期价值的优化，所以优化目标能力也是在不断地演进的。我们这些相
关重要的工作，也在国际会议上有论文的发表，包括 KDD，CIKM，ICML 等等。
3. 广告业务技术能力总结
这里把我们积累的能力做下总结。最早的时候，广告主在广告平台上朴素地按照
PV 或者点击出价。这种出价其实是一视同仁，比如所有 PV 都值 1 元，所有点
击都值 0.5 元。在这个基础上，我们做了 OCPM/OCPC 的升级以后，每个 PV/
点击的价值就可以去做实时地预估。做了预估以后，比如广告主认为一个点击值
0.5 元，而我们认为点击的价值更高，就可以把 0.5 元调整到比如说 0.7 元。如
果这个点击价值低，可以帮广告主把 0.5 元调整到 0.3 元，所以就实现了流量粒
度的价值预估和优化。进而再去升级到 BCB，对结果也能有一个提前的确定性保
障。考虑到流量波动是很大的，尤其是像双十一或者 618 这样的大促，广告主对
销售 KPI 和最终结果的保障性有强烈的要求，他在这一天必须把这钱花出去，拿
到这么多流量。我基于对过去的流量和未来流量的规律把控，能够帮助广告主去
保证它的效果，就迎合了广告主的诉求。预算约束下综合出价，就是帮广告主从
手动挡升级到自动挡。多约束下自动出价，就是我们除了帮助广告主去满足预算
的约束，有些广告主他不希望自己的一个 PV 或者一个点击的花费太高，所以他
会提出一个点击必须在 1 元之下，一个 PV 必须在 0.1 元之下，这种其他的额外
约束，在我们平台现在也是可以表达的。表达了之后，这些约束我们都会帮他满
足，然后具有一个相应的自动出价的能力去把这个计划投放出去。
到了 2019 年的时候，我们也推出了合约与 RTB（real time bidding）环境的优
化。这个合约就是我们要去提前保障广告主结果的确定性。但是这种合约在很多
广告平台里跟 RTB 实时竞价是隔离开的。合约就是这份流量约定好就这么卖了，
而实时竞价就是按实时的竞争拍卖结果卖，但这种割裂的方式显然是不符合市场
经济，而是用计划经济的方式把两种模式强行分开，然后分别去做优化。最好的
市场经济方式是把合约跟 RTB 直接混合起来，然后用市场自己调整的方式去得到
全局的最优化。
但这个也带来很大的挑战，因为 RTB 的波动，势必对合约会产生一些不确定的影
响，那么合约还能不能保证广告主的结果？并且合约和 RTB 混合起来，是不是能
做到全局的收入的优化？所以这都是很有挑战的问题。
今年我们提出来序列投放优化长期价值，很多用户看广告不仅是看一次。但是很
多广告平台有频控，用户只能看一次广告，再来广告曝光，就简单粗暴地不允许
用户看了，用这种很生硬的方式进行频控。但根据我们的统计会发现，在电商领
域有很多用户，第一次看广告，是不会去购买的，但是第二次看了广告，可能就
购买了，而且可能超过 50%的购买都是发生第二次广告曝光或者第三次广告曝
光。这也就出现一个问题，有的用户确实让他只看一次是合理的，因为他这次没
有兴趣，以后就没兴趣。但是有的用户给他多看几次，他的心智会有加强，反而
会形成一个累积的购买结果的最优。所以我们今年也推出序列投放，就是希望能
够去挖掘用户的长期价值，让广告系统再去评估广告投放或者不投放的时候，不
再单一的看这一次 ECPM 单次的最大化，而是要看整个长期对用户序列的运营是
否能做到最优化，对序列化投放基于长期价值这个角度去优化广告的投放。
最后，我们今年也有一个很重要的产品叫 AI 智投，解决广告主的一个很大的痛点。
广告主现在可以有很多的营销平台，去投品牌广告，搜索广告，还有定向广告。
所有这些广告，广告主从传统的角度来看，只能把自己的广告预算按照过去的经
验去分拆到这三种不同的渠道上面，然后在不同渠道内部，再做相关的人群设定、
出价设定方面的优化，但是不同的渠道之间怎么做整体优化呢？这也是一个很重
要的问题，所以我们从单渠道的优化走向各种各样多渠道的全局优化。整个所有
的功能升级，在接下来的智能投放体系和技术里面，我会一个个给大家做一个简
要的介绍。今天我们也重点介绍背后的算法核心思想，因为我们大部分的工作都
是有相关论文的发表，所以对于里面一些数学的细节，大家可以去看论文。
02
智能投放体系和技术
1. OCPC/OCPM
① 广告主需求
广告主说：“我已经习惯了 CPC，在此基础上，能帮我做点别的吗?”在这个基
础上，我们可以做 Optimized Cost Per Click ( OCPC )。
② 优化方案
第一，广告主对 CPC 出价，是所有点击一视同仁的，但不同的点击其实价值是不
一样的，按统一的出价其实很不合理。
第二，广告主有时候有多维度的优化诉求，不单单只想拿更多点击，可能还有点
击之后的转化价值，比如说购买/加粉，这些诉求广告主也是希望优化的。那么基
于这两点，OCPC 就可以在广告拍卖机制下借助系统的能力进一步优化客户价值。
那么它是怎么做到的？我们看在 GSP 拍卖机制里面，传统的广告排序依赖的分数
叫 ecpm，那么它的在 CPC 广告里面它的计算公式是 ecpm=org_bid（广告主
的原始出价）*pctr（这条流量的点击率），然后就会按照这个做排序。在激励兼
容的机制里面，广告主的原始出价是基于一段时间一个流量的平均价值基础出价
的。广告主可能上午 10 点开了这个计划，他认为从上午 10 点到晚上 10 点这 12
个小时每个点击的平均价值就是 0.9 元，所以他就出了一个 0.9 元。这是基于一

段时间的流量的平均的评估，显然是有缺陷的。在平均的意义上，广告主的出价
跟流量价值确实达成一致了，但是在单条流量上，对广告主的价值有可能是有差
异的。比如广告主如果关注的是点击之后的转化价值，那么有的点击背后是能够
形成高转化的，有的点击背后是不能形成高转化的，因此不同的点击背后价值就
不一样，相应的出价也应该不一样的。造成缺陷的一个主要原因是广告主不能对
单条流量去评估价值，因为他不能钻到我们的系统里面来观察每一个流量的价值，
靠人肉是做不到这一点的。所以改进的办法就是我们要对广告主原始出价做一个
调整，把它变成一个叫做 optimized_bid，那么 optimized_bid 就是在广告主的
原始出价 org_bid 的基础上去乘一个因子，这个因子是 pValue/baseValue。分
子 pValue 就是在单条流量上，我们利用系统里面的机器学习模型，能够实时地
去感知流量用户的信息和广告的信息，然后利用这两个信息去给出单条流量的价
值。它放在分子这个位置，说明 pValue 如果高，流量价值就高，可以往上调一
点价格。如果 pvalue 低，那么这条流量价值低，可以往低调一点价格。pValue
是需要有一个锚定点的,锚定点就底下的 baseValue，baseValue 是基于历史的数
据去评估广告主表达的流量的平均价值，比如它过去所有这些流量的平均的转化
率是多少，或者平均的关注率是多少。这里 pValue 和 baseValue 是一个点击后
的价值，这个客户是需要通过在平台上去表达的。比如说他是想去优化转化，或
者想去优化收藏，或者想优化关注。有了这样的一个基于 pvalue 和 basevalue
对 org_bid 的调价，在我们新的 ECPM 排序机制下，就可以用 optimized_bid
的去做排序。
③ 效果评估
在这个情况下，广告主和平台是双赢的。对广告主来说，相同预算下，价值回报
上涨，ROI 提升了。因为他以前买这个东西都是一视同仁的，现在可以选里面最
好的东西去买，除此之外也给广告主提供了多维度的价值优化，比如优化转化，
或者优化关注。对于平台来说，广告主 ROI 提升了以后，他肯定觉得在这个地方
投资回报率高，应该投入更多的预算，然后获得更多的回报。那么广告主意愿的
加强，也会对平台带来收入的增长。所以整个 OCPC/OCPM 也是很类似的一个
思想，它的核心理念就是这样。
2. BCB（Budget Constrained Bidding ）
① 广告主需求
广告主手动出价之后，我们怎么帮助广告主把手动的出价的价值精细化到流量的
力度？有的广告主说自己还要去评估平均价值，运维成本很高，而且广告主经常
有很多商品，要开很多计划，计划里面又有非常多的定向人群，或者是买词，那
么每个人群或者词上都要去调价，操作成本就非常高。所以广告主能不能就花这
么多钱，然后帮他达成一个最优化的目标？比如“我每天可以花 1000 元，能帮
我买到尽量多的粉丝吗?”。广告主不想去关心具体怎么出价，让平台去帮助他去
自动出价。
② 优化方案
针对这个需求，我们推出了相应的产品叫 Budget Constrained Bidding，就是在
预算约束下自动地出价。这里我们给出一个生动的例子，让大家看一下它是一个
什么样的概念。
比如我们的目标是在广告主有六美元的预算约束下，要尽可能去获得足够多的点
击。底下横坐标轴是时间，就是广告计划，比如今天凌晨 0 点开始投放了，到今
天 24 点结束，那么在这 24 个小时里面，一共有这么多蓝点流量让广告主去竞争。
这些蓝点代表的流量的市场成交价都不一样，有的是 1 美元，有的是 2 美元，有
的是 3 美元。对于广告主来说，为了获得更多的点击，即想要更多的蓝点儿，他
应该怎么去出价呢？广告引擎里面的“小机器人”，根据自己的算法，就会沿着
时间，对于每一条流量会做判断这个蓝点要还是不要。
 小机器人看到第 1 条流量的成交价格是 1 美元，觉得这是一个很高的性价
比。因为 1 美元就可以拿到一个点击，所以它就会把它拿下，之后预算就
从六美元变成了五美元。
 然后接下来他又遇到第 2 个流量，这个点击要花 3 美元，性价比就非常低，
决定不要这个流量了，那么红色就不竞得。
 再接下来它又看到一个 2 美元的点击，觉得性价比还不错，所以这个也拿
下。
 然后我们的预算就进一步减小，现在只剩 3 美元的预算了。然后又有一个
低成本的流量，拿下。
 然后第 5 个蓝点的价格很高，不要。
 然后，第 6 个蓝点又拿下。
 最后一个不要。
这个时候今天所有的流量也就结束了，预算也花光了。
从结果来看，我们这个算法把所有 1 美元和 2 美元的点击全部都拿到了，3 美元
点击都扔掉了。从一个点击上的成本来看，它把性价比最好的流量全都拿到手里
面了。所以这就是 budget-constrained-bidding 的概念，具体它的算法是怎么
去设计的呢？
首先我们要形式化这个问题，在给定预算 b 的前提下，要尽量拿到最多的价值。比
如，这里要拿到最多的点击，那么在竞价广告里就变成了系统要对每条流量出一个
报价，让最终的目标函数最大。底下的 maximize 的 bi 是对每条流量上的出价 ( i

指的是零到 24 小时所有的流量 )。这里的“1”是一个示性函数，ci 是这条流量的
市场成本 ( 即市场成交价 )。如果 bi 出价大于市场成交价，那么这条流量就竞得了，
这个示性函数就取值为 1。如果出价小于市场成交价，就没有竞得，示性函数就是
0。旁边 vi 是这条流量的价值。如果 i 定义的是 PV 粒度的流量的话，这是一个 CPM
广告的建模方式，这里每一个示性函数取 1，就说明曝光 PV 拿下了。vi 就可以理解
为曝光的价值，比如说 vi 如果是点击价值，那么用户点击了，vi 就是 1，如果没点
击，vi 就是 0。底下的约束也是一样的。对于所有流量来说，每一条竞得的流量对
应的 ci 是市场成交的价格，所有流量市场成交价格加起来，不能超过总的预算。所
以这个就是预算约束下的价值最大化的建模。如果我们把这个示性函数当做一个变
量，比如说把它当做 x ( x 可以取 0 或 1 )，它其实就是一个线性的优化问题。在优
化问题方面，张伟楠老师的参考文献里面从连续空间做了分析，最后得出这个问题
的最优出价公式 bi*=vi/λ*。他的分析办法，是把它看作一个原问题，然后用拉格朗
日的办法把它转换成一个对偶问题，然后对对偶问题去做分析，得到最优的出价，
就等于单条流量上的价值除以一个固定的参数λ*。大家要注意这个地方的λ*，就是 0
点到 24 点的 24 个小时里，对所有的流量λ*都是一个固定的值，然后 vi 就是每一条
流量的价值。所以它的直观的含义就是：对于任何一个流量来了，流量的价值高，
我出价就高，价值低，出价就低，出价跟价值完全是正比例的线性关系。线性关系
的系数就是 1/λ*，λ*可以通过历史数据，对线性问题直接去求解。这个求解也是非
常容易的，直接能得到一个最优λ*，但是实际情况其实会更复杂一些。我们可以从
下图看出，在实际广告投放的时候，在一天的 24 小时里面，首先，流量的波动是
很大的。其次，我们可以看出不同小时的出价波动也很大。我们再看红线跟蓝线，
天与天级别之间它的差异也很大。所以根据历史数据，虽然利用规划类的软件就能
把λ*解出来，但它不一定在明天还能够适用。所以λ*求解既要结合过去的数据，也要
结合当天实时的数据，这个解法一般可以用反馈控制的方式去解，也可以用一些强
化学习的方式去解。λ*的含义是什么？其实它是一个性价比的阈值。我们看到 bi*是
出价，如果按照广告的二价计费，小于 bi*的最后市场成交的流量都会被拿下。我们
可以看到λ*=vi/ci，vi 是流量的价值，ci 是流量的成交价成本，vi/ci 其实就是性价比。
那么处于λ*这个性价比之下的这些流量 ( 每一个蓝点都是一个流量 ) 都会被竞得，
因为这些流量的最后的 ci 一定是小于 bi 的。那么处于λ*之上的就一定会被扔掉，因
为他们的 ci 是大于 bi 的。所以按照 bi*=vi/λ*的公式去出价，最后的结果就相当于把
全天流量里面性价比最高的这部分流量都给竞得了，然后性价比低的流量就全部扔
掉了。不管是你用反馈控制，比如大家熟悉的 PID 的算法或者强化学习控制，它背
后核心就是在找λ*，要在所有波动的环境里面去把最好的λ*能够稳定地找到。
我们团队的吴迪老师在 2018 年的时候发表过一篇论文，用强化学习解决前面提到
的整个流量波动的问题。强化学习建模里，消费者的流量不断请求广告引擎，构建
了不确定的交互环境。模型包括 Agent ( 智能体 )，就是我们的广告算法。模型的

状态指的是广告计划 ( 比如当前的一些预算，或者历史的平均 CTR/CVR，以及包
括剩余没有花费的预算等等 )。智能体的 action，对λ去做调整。DQN 可以设计成
两个输出端子，一个端子是对λ上调一个αt，另一个端子对λ下调一个αt。当然你也
可以把它设成 A2C、A3C 等等，设计成一个连续函数的 action 输出。
总而言之，action 这边调λ，然后整个建模我们是用一个 model free 的方式去做，
一个 time step 可以认定为 15 分钟，那么一个 time step 里面所累积的所有的回报
的 value，比如所有的点击量或者所有的购买量，当做 reward。在这样的一个强化
学习的设定下，我们搭建了一个离线的训练平台。在离线训练平台下，我们可以把
过去的日志做一个回放，依托强化学习的建模，用 DQN 或者 A3C 等模型去训练。
在线的时候，就把训练好的模型部署上去。实际做的时候会发现一个问题，这种预
算约束下，让一个强化学习的智能体去探索的时候，有可能出价高一点，就能在某
个 time step 拿到非常大的价值。因为这个也是显而易见的，你出价高，拿的流量
多，当然价值就多。但是因为是有预算约束的，强化学习算法可能会比较短视，在
短期内它可能没有触达预算的上限，就拼命地去拿流量，觉得现在的 reward 很高
就很好。但是算法跑到中间的时候发现预算花光了，后面的流量都拿不到了，这样
的话这个算法就相当于是探索出来一个次优的路径。但是强化学习的整个序列探索，
想让它自己去不断探索，探索出前面省吃俭用，到了后面刚刚好，又能最后把钱正
好花光的算法或者路径，这其实是非常难的，所以在 reward 的设计上就要去巧妙
地构思。我们组的同事也提出了一个方法，实践中既能保证效果，而在理论上也是
非常棒的。把它的每一步获得的 reward 都跟整个序列获得的整体的 reward 做了
一个关联，这里面 RT 它不再是一个 time step 15 分钟的结果，它是把整个序列的
reward 都能够反映到里边，但是它反映过来以后还给出了一个理论的证明，叫
reward shaping。在 shape 以后的 reward 情况下，我们得到最优策略跟原始严
格的强化学习建模定义的最优策略，是严格一致的，所以这个 reward 极大的加速
了这个问题的收敛。
③ 效果评估
我们可以看到这张曲线图，底下红线就是按照最原始的 reward 去训练，训练了很
多 time step，它的 reward 一直处于很低的，收敛得非常慢。但是如果加了我们的
reward-shaping 之后，它 reward 就上升得非常快，收敛得非常好。然后左边这
张图，我们用基于强化学习捕捉流量变动，出价变动,天级别之间变动的方法，叫做
DRLB(Deep RL Bidding)，加粗的线也比其他传统的方法要好。这些传统的方法包
括 FLB(fix linear bidding)，用过去的历史日志，得出过去认为的最优的λ0，放进来，
然后还有一些启发式的规则的，比如 BSLB 等等。用强化学习去做能得到一个非常
好的效果。
3. MCB
① 广告主需求
刚才提到的是预算约束下的情况。广告主除了希望预算约束，还希望点击成本也
不要太高。比如说：“我每天可以花 2000 元，能帮我买到尽量多的成交吗? P.S.
根据经验我希望点击成本不超过 1.5 元”。
② 优化方案
在这个问题里面，我们的建模和刚才类似，目标函数还是要最大化整个流量的
value，约束里面第一项还是预算的约束。第二项就是某种成本下的约束。这里的分
子是所有流量的最后成交价格累积起来，相当于是总的投入(即总的消耗)，分母的
wi 就是某种单位。比如说这个里面是 PCTR，分子是总消耗，分母是总点击量，得
到的就是一个平均的点击成本。广告主希望平均一个点击，成本不能超过 1 元钱，
这个约束就会让平均点击成本不会超过 cw。该问题也用对偶的办法，可以分析出来
它的最优的出价形式如下：
我们团队的杨迅同学，在 KDD 发表了一篇论文给出了这个对偶公式的推导，大家
可以去参考。公式的第一项乘以 vi 的，关注的是这条流量的价值。第二项是 wi*Cw，

关注的是这条流量出价对于平均成本的影响。所以这里面的拉格朗日的对偶的变量
p*、q*，它就起到了去权衡这两个项目的作用。p*、q*一旦求得以后，那么就在一天
里面都是固定不变的，它的解法也可以包括两种。一种是基于强化学习的解法，跟
刚才我们提到的很类似，可以把一些 reward shaping 的思路借鉴进来，只不过在
这个里面要把第二个约束也考虑进来。可以在 reward 里面把底下平均成本的约束
PCW 也加进来，如果最后违反了平均点击成本，就给一个惩罚，如果没有违反，
就不给惩罚。通过这种对 reword 的干预,实现多约束的情况下的强化学习求解。还
有一种方式就是基于反馈控制的办法。
经过我们的分析，我们发现 p*和 q*,对于预算约束和平均点击成本的约束的影响,是
可以解耦控制的，即可以分别控制 p*和 q*从而分别去影响预算和平均成本，在理论
上证明是可行的，然后就可以独立地去搭两个 PID 做控制。除了帮助广告主满足多
约束，优化某个目标（优化，就是你不能保证结果）。那么还有一类投放策略，既
能满足广告主的预算约束，还能保证最后给多少曝光或者多少点击，就是合约保量。
比如广告主说：“我要以 60 元总价格在 1 天内购买手机淘宝首猜 1 坑 1000 个展
现。我们可以事先签订合同，但完不成要给我赔偿!我很好奇你们是怎么分配流量
的？”
对于整个平台来说，我们希望把合约保量的计划跟 RTB 的计划能够混合起来，让他
们统一在市场经济下，去竞争做优化。
那么这个问题是怎么定义的？我们这里优化的目标包含三项，第一项 RGC 就是合约
保量的目标，第二项 QGC 就是合约保量拿到流量的平均质量，第三项 RRTB 是市场实
时竞价下的收益，我们希望把这三项加起来联合去做优化。这里 RGC 是合约保量的
收益是怎么定义的？下面我们给出式子：
c 是保量的单位花费，d 是要保多少量的需求。所以 cj*dj 按道理说就是你保量能够
达到的总收入的上限。但是你如果保不住量怎么办，那么这里 pj 就是缺量的惩罚，
你要赔广告主多少钱呢？yj 就是你最后的缺量，所以 pj*yj 是最后如果没有保数量，
缺了这么多量，要赔给广告主的钱，所以 RGC 就是合约这一块的总收入。QGC 这里的
λj 是一个权衡因子，是固定常数，用来权衡合约保量的流量质量的重要程度。这里
的 xij 就是第 i 条流量对于第 j 个保量计划,要不要去竞得这条流量的示性函数。Qij 这
里说的就是这条流量价值，比如这条流量的 PCVR ( 转化率 )，那么 QGC 在这里是
为了优化平台收入时不能让合约保量的这部分流量质量太差，不然广告主它每次一
买合约，发现最后合约的效果跟 RTB 效果差异非常大，合约的质量永远很差，未来
他就不会愿意去买合约产品了。虽然你能保证确定性，但你买的都是很垃圾的流量，
这是非常不合理的。所以 QGC 的功能就是要保障合约这部分的流量质量。RRTB 的 bi2
就是最后 RTB 的二价，这个二价就是我们通常所理解的 RTB 最后竞得带来的平台
收入。
这个问题如果展开，其实也是一个线性的优化问题，用对偶分析，会发现对第 i 条
流量，第 j 个合约计划的最优出价就等于λj*qij +αj*，αj*就是要求的最优对偶变量。根
据前面的思想，我们也可以去给出一套强化学习的解决方案，或者大家也可以去尝
试用一些解耦的 PID 的控制方案。
③ 效果评估
这张图是我们用了一套强化学习的方法，能够比传统的一些固定的α*的出价有更好
的效果。这个里面 PID 可能要注意必须站在一个全局的视角去做反馈控制。因为这
个时候涉及到的是很多个智能体在一起配合，所以这里到底应该牺牲谁，应该保障
谁？其实这个并不是一个严格的单增单减的关系，在这种情况下，你一定要有一个
全局的调整，才能保证你最后得到α*真的是面向全局最优的。
4. MSBCB
① 广告主需求
如果广告主问：”有的用户需要多次曝光才会购买，预算有限下我应该如何投放?”
② 优化方案
如图所示，有的用户可能第一次访问平台它被曝光了，那么他这个时候才稍微对
这个商品有一些心智，那么再去看广告的时候，他就感兴趣了，可能就加到购物
车里面了，那么第三次看这广告的时候，他最后就决定购买了。
对于这种情况下，我们应该怎么去优化广告投放呢？这里面也给出了一个建模的
方案。
这里定义了 VC 和 VG 两个概念。某一个固定的广告，对于某一个用户 i，有一套运营
用户的策略πi ( πi 是指如果广告跟这个用户在这一周内比如能接触 5 次，这 5 次里

应该选哪几次去投放，哪几次不要去投放 )，投放以后最后整个序列的整体预期回
报就是 VG。那么整个序列最后期望要投入的广告的消耗是 VC。所以 VG 是期望的长
期的价值 Long Term value，VC 是长期的成本 Long Term cost，都依赖于这个广
告对这个用户运营的策略πi。优化目标也是显而易见,类似于前面的 budget
constraint bidding，他的变量有两方面。第一，要去选哪些用户 ( 即 xi ) ？第二，
对于选定的这个人，我要用怎样的策略πi 去运营用户的序列？它其实整个把频控这
件事情包括进来了，那么约束就是我要选哪些用户，以及我对用户的运营策略下，
整个序列的所有的成本要小于等于预算。那么最后既要优化选哪些用户，又要优化
对不同的用户之间用怎样的策略去优化它，这肯定是一个约束下的优化，又是一个
序列决策的问题，它的解的组合空间非常大，求解起来也非常难。我们实际是怎么
求解呢？我们把它分成两层求解。
第一，选用户假设已经找到了对用户最好的运营策略πi，我们应该怎么挑用户？跟
前面方式也是很类似的，依托性价比最优去选就好了。所谓性价比就是用户的长期
的价值/用户的长期的成本，然后对用户从高到低去选择就可以。在实际情况中，因
为流量粒度很细，所以这种背包的贪心算法基本是可以取得 99%比率接近最优解
的。第二，运营用户当你知道怎么去选用户之后，对一个用户你应该用什么样的策
略πi 去运营它呢？我们刚才看到选用户的时候，选性价比最优的用户。直观的一个
想法是把每一个用户的性价比运营到最大化是不是最优解呢？这里我们给出了一个
结论，不是最优解！
为什么呢？我们给了一个示意图，这个示意图你可以看作是个大背包，背包里每一
个长方形代表一个用户。每一个长方形的高度,就是整个序列下来的总消耗，它的面
积就是整个序列的总回报。那么底下横轴就是面积/长方形的高度，得到的性价比。
背包已经按性价比从高到低，把用户一个个叠罗汉的方式摞起来了，整个高度累加
起来就是它的预算。整个按性价比优选的话，虚线之上的就相当于被挤到背包之外
的，外面的性价比较低的用户就不要了，而虚线以下的性价比高，都已经装进来了。
这个时候我们来看最下面的蓝色长方形，已经是把用户运营到了性价比最高的状态。
如果对它的运营策略πi 做一些调整，让性价比下降一些，底部蓝色长方形的高度（即
期望的成本）上涨一些，头部低性价比的用户就会被挤出去一些。二者一加一减的
高度虽然相等，但是我们挤出去的是低性价比变化量，获得了更高的性价比增量。
通过牺牲最下面长方形用户的性价比，从最极致的状态稍微下调一点，整个背包的
容量就增加了。我们也有一系列理论推导，最后能给出一个严格的理论证明。对用
户运营的时候，用户运营的长期的 return 目标函数，要按照：
去运营，那么最后就能得到整个背包的最大。而且我们两阶段的优化既要去挑用
户，又要去对单个用户去做运营，这个来回迭代的算法，我们也严格证明了这个
算法能够收敛到全局唯一的最优解。
我们的这个工作被 ICML2020 会议接收，感兴趣的朋友可以去参考我们的论文。
③ 效果评估
左图中，当考虑到用户跟一个商品反复交互有这种序列效应的时候，表示长期价
值效果的红色的线是显著高于表示短期价值效果的蓝色的线。从右图可以看出，
红色的线（代表目标函数策略）的确是比蓝色的线（按照"性价比最大化"的思路
运营用户）也要高出一截。我们也跟传统的 Constrained 的一些方法去做了对比，
在线上我们也取得了 10%的 ROI 和 GMV 的增长。
5. CCSA
① 广告主需求
上面介绍的很多都是在局部的一个渠道去投放。广告主预算如何在搜索、推荐和
品牌广告渠道最优分配呢?
② 优化方案
当广告主面对不同的渠道的时候，怎么能够在整体上去做最优化？这个问题的建模
可以看作 i 从 1 到 N，广告平台有 N 种投放渠道，每个渠道都可以投入预算 xi，你
可以获得渠道最后给你的回报 fi。那么目标就是在所有渠道的预算 xi 加起来小于等
于总预算的情况下去最大化整体的渠道回报之和。广告主面对各种复杂的广告平台
操作，还要再去联合优化，这种操作是很难实现、很难评估的。
所以我们可以把它集中到一个非常简化的、操作便利的单一的操作接口上，广告
主只要去通过 minimal 的操作接口，就可以去设定投入，然后 minimal 的操作接
口就可以控制所有的渠道去实现整个渠道的最优化。从整体视角来看，最终广告
主投入比如 1000 元的一点点边际的预算，在各个渠道里带来的增量的边际回报
是相等的，这个状态就是最优的了。
但实际去做的时候，因为各个渠道是很粗的粒度，你是很难去控制到各个渠道里
面的一些具体的操作的，至少在系统的复杂性上会带来很大的难度。所以我们目
前阶段性的方案是中心的 minimal 的平台对各个渠道通过下发预算分配或者利润
要求等粗粒度的控制策略，然后去影响各个子渠道的投放策略，各个子渠道就可
以去用 BCB/MCB 或者序列投放等等去优化它们的策略，然后通过这种方式实现
了一个大一统的优化，各个渠道之间的这种系统的耦合上也是比较低的。
③ 效果评估
这里给大家做一个宣传，阿里妈妈今年推出了 AI 智投的投放产品，这比客户自己
去各个渠道去分预算投广告，投放的效率能够提升 50%，这是一个很大的提升！
03
总结与展望
最后，总结下阿里妈妈广告系统的迭代历史，我们经历了从粗放式价值评估，到
精细的单条流量价值预估和优化升级，以及从单一到多维的目标的优化，从不确
定到对广告主有合约保量确定的结果保障，以及从广告主自己手动调出价到广告
主只要设定预算，我们就自动帮它运维的这种升级，以及从单一的预算的约束，
到包括各种成本约束（比如曝光成本，点击成本约束）的控制能力，从短期的价
值优化到长期的价值优化，以及从单个渠道的优化到全局所有渠道的整体优化。
面向未来，我们会继续深挖客户的痛点，从数据智能，机制设计，算法升级和产
品迭代方面进行全方位的体系和技术升级。
同义变换在百度搜索广告中的应用
分享嘉宾：连义江博士@百度
编辑整理：王成林
导读：关键词匹配位于整个搜索广告系统的上游，负责将 query 和 keyword 按
照广告主要求的匹配模式连接起来。该问题面临着语义鸿沟，匹配模式判定和可
扩展性方面的挑战。在本文，我们会就同义变换这个主题展开讨论，讲述如何用
数据驱动的方式做同义变换，如何将知识推理融入到变换中，以及如何用这些技
术解决匹配问题中的核心挑战。
01
背景介绍
1. 搜索广告
搜索广告中有三个角色，分别是用户、广告主、搜索引擎。
 广告主侧会向引擎提供物料，同时竞价关键词。比如一个做双眼皮的美容
机构，会买例如“双眼皮手术多少钱”、“双眼皮手术的价格”、“双眼
皮手术哪家好”等关键词。这些关键词会被提交到搜索引擎。需要指出的
是，这里说的关键词不是我们通常所说的关键词，而是指广告主购买的
query。
 用户侧会提交 query，比如“双眼皮手术多少钱？”。
 搜索引擎在收到 query 之后，会对 query 和关键词进行匹配，把广告主的
广告创意拉取出来，综合考虑 ( bid, quality, ctr ) 等因素选取有限的广告
进行下一轮的拍卖，最终胜出的广告会被展示出来。
2. 广告主的竞价语言：匹配模式
和其他广告不一样的是，搜索广告会提供特定的竞价语言，即匹配模式。广告主
可以控制这些关键词对应的匹配模式来控制竞价的精准度。主流的搜索引擎一般
提供三种匹配模式：精确匹配、短语匹配和智能匹配；其定义如图所示。一般的，
这三种匹配模式，从上到下，触达范围由窄到宽，精准度也从高到底，相应的，
出价也会从高到低。
举一个例子，如果广告主购买的关键词是“双眼皮手术的价格”，并且指定其匹
配模式是精确匹配的话，当 query 是“双眼皮手术多少钱？”时，广告主的关键
词会被匹配到，而“双眼皮手术疼吗”则不会被匹配到。
3. 广告主的账户结构
再举广告主的账户结构的例子给大家看一下，广告主会投放若干计划，在计划下
有多个投放单元，在投放单元中，有关键词、出价和匹配模式，在单元下广告主
会提交若干创意。可以看到关键词是处于整个树形账户结构的底部，我们匹配的
工作会从这个账户底部开始进行，包括索引和匹配。
4. 搜索广告系统概览
在搜索广告系统中，广告的触发分三步走：
 第一步是进行“关键词匹配”，目标是为每个匹配模式召回尽可能多的关
键词。
 第二步是在关键词匹配成功后获取广告内容，确定广告对应的广告主、出
价和广告创意。
 第三步是广告排序阶段，基于匹配质量，出价和点击率等因素，选择有限
的广告进入拍卖，最后胜出的广告被展现出来。
5. 关键词匹配问题
本次分享的重点是“关键词匹配问题”，抽象来说，这个问题的输入是 query、
匹配模式、关键词库，输出是满足匹配模式的全部关键词，限制是匹配模式。例
如输入是“双眼皮手术多少钱”，在精确匹配模式下，产生的典型目标召回关键
词是“双眼皮手术的价格”、“双眼皮手术多少钱”、“割一个双眼皮花多少钱”
等。
6. 问题挑战
关键词匹配问题的挑战有：
Semantic Gap：用户和广告主用不同的方式来表达同样的意图。例如“双眼皮
手术的价格”和“双眼皮手术多钱？”是同一个意思，但是他们会用不同的字面
来表达。这也是 NLP 中一个基础又很重要的问题。
匹配模式的判定：是搜索引擎广告面临的独特问题，用来判定是精确、短语还是
智能匹配。这是产品的根基，由产品对广告主的契约保障。
工程性能：可扩展性，由于 query 和关键词的量都非常大，无论在线还是离线，
计算资源都非常有限，这给很多功能实现带来了挑战。
02
同义变换的应用场景
同义变换的应用场景主要有：
1. 同义匹配
首先是产品定义的同义匹配问题，在刚刚提到的三个匹配模式中精确匹配和短语
匹配与其是直接相关的。一般情况下，一个 query 可以有无数个同义变体。例如
一个 query 是“双眼皮手术多少钱”，简单的变体是“双眼皮手术多少钱呢？”，
一个更为复杂的变体是“拉一个双眼皮大概需要多钱？”。如果在一个开放域中
变换的话，一个 query 可能有无穷无尽种同义的变体，而我们主要关心的是在封
闭集合上的变换能力，即将 query 同义变换为 bidword 集合中的某一个。
2. Keyword 端
队列压缩：
另外一个应用场景是在 Keyword 端，在关键词匹配中，给定一个 query，我们通
常会触发得到大量的候选关键词，这些候选为了保证质量，都需要经过模型校验
计算来确认。我们的思路是基于同义关系压缩的方法减少计算候选。在上图的例
子中，一个 query 触发 4 个关键词候选，通过离线计算 A1 和 A2 是同义，B1 和
B2 是同义，那么线上只需要校验 A1 和 B2，当 A1 通过校验后再扩展回去。这样
可以极大地减少判别模型的计算压力。
基于代表元来触发：
更为激进一点，我们可以用基于代表元来触发。通过对原始词库进行同义压缩，
例如对 A1，A2 和 B1，B2 进行同义压缩成 A1 和 B1，可以降低 keyword 端的
量，只需针对 A1 和 B1 进行触发。在线上使用中，我们采用基于代表元来触发，
然后再扩展回原始词库。
3. Query 端：规范化+改写
在 query 端，我们可以进行规范化和改写。一般的搜索广告都会针对高频 query
做离线的充分计算放到一个高频词表。当 query 来了之后，先去查表来看是否有
结果命中。我们可以针对高频 KV 词表中的 key 做同义规约变换，从而提升 key
的命中率。KV 词表中，K 就是关键词，V 就是触发的结果。例如 Q1 原来的触发
结果是 A、B、C；Q2 的触发结果是 D 和 E，在同义规约后，Q1 和 Q2 的触发结
果是 A，B，C，D，E。相对于原来 Q1 只命中 A，B，C 而言，规约之后提升了
^ ^
命中率，同时整个词表只需存储规约 Q1 和 Q3 来减少 key 的量级。
03
如何做同义匹配？
—— 以精确匹配场景为例 ——
同义匹配的方案：
在同义匹配中，以精确匹配场景为例，首先可以从规则出发，进行短语粒度的同
义替 ( 例如双眼皮=重睑手术，多少钱=多钱 ) 或者进行句子级别的 pair 挖掘。
今天分享的主要内容是通过数据驱动的模型来提高泛化。主要为三步走：寻找同
义数据源、训练模型并基于模型来泛化。
第一步：寻找大型同义数据源
在如何选择大型同义数据源方面，一方面可以利用系统外部数据，例如搜索点击
日志、Session 日志、协同过滤和规则替换。另一方面可以使用系统内部数据，
例如商业点击日志。
① 数据选择的困惑：
在数据选择方面会产生一些困惑，使用系统内部数据可以泛化出增量吗？因为使
用最大似然的方式求解就是使用模型来拟合数据，例如使用翻译模型或者图模型，
top1 decode 的结果就是该数据，这个过程好像无法产生增量数据，会陷入
feedback loop 中。事实上可以使用系统内部数据也可以泛化出增量，因为我们
实际应用中是做 1 对多的 decode，在图模型中我们会近邻检索出不止一个候选。
下面举例来说明泛化带来的 delta。
② 泛化带来的 delta：
在上图中，训练样本 1 的 Q1 是“双眼皮手术多少钱？”，B1 是“双眼皮手术的
价格”。训练样本 2 的 Q2 是“双眼皮手术大概多少钱”，B2 是“双眼皮手术一
般多钱？” 。使用 S2S 模型来对样本进行训练，然后对 Q1 做 Decode，由于
Q1、B1 是在训练样本 1 中，所以首先能够得出 B1，同时由于 Q1 和 Q2 相似度
比较高，所以也能够获取结果 B2，如果模型的泛化能力足够强的话，说不定能得
出 B3。
第二步：训练模型
在训练模型中可以选择 S2S 模型，双塔模型 ( 即语义的度量模型 )，或者图模
型。
第三步：基于模型来泛化召回
最后是基于模型来泛化召回，使用模型的自反馈来进行泛化，以前 Q1 有 3 个召
回的结果 A，B，C。基于模型，定向在关键词库中做召回，有可能把 A1 和 B1
也召回出来。图中的蓝色标记都是泛化出来的结果。
04
基于 S2S 来泛化
1. 思路
基于 S2S 的泛化，建模本质就是一个翻译模型，进行逐词翻译，对 Query 进行
编码使用 embedding 来作为输入。
2. 该建模的优缺点
该建模的优缺点：
优点：
 采用端到端的建模，尤其是在语料充分的情况下，质量会非常好，同时简
单，只需要获得一些正例即可。
缺点：
 效率比较低，因为是用翻译的方式来做检索的工作，逐词生成。一个 query
通常有上千种同义变体的关键词，纯靠 decode 几乎不可能完成。同时如
果数据不作清洗的话，冗余度会非常高。
 定向翻译，因为翻译本身是开放式的，不能保证 decode 出来的东西都是
关键词。
 训练和预测是不一致的，训练时一对一，目标是一对多。
3. 解决效率问题：同义规约
解决效率问题，可以使用同义规约的方式来解决，直接翻译的话，冗余度是很高，
如果 query 是“割双眼皮手术多少钱”，类似的 query 有很多，例如多一些空格，
少一些空格，多一个标点符号，多些副词，感叹词等。所以我们可以对 Query 和
Keyword 空间，先都进行归一化，然后在规范化的空间中来做匹配。
4. 如何做规范化
具体进行规范化的步骤是，基于冗余词性的去除。例如副词、标点符号的处理；
还可以采用同义模型来进行校验；更进一步的是做 bag of words 的处理。其效
果是可以极大的压缩训练数据、减少冗余翻译、相同的时间内生成更多的同义候
选。
5. 解决效率问题：同义扩展
还需要解决的一个问题是同义扩展，因为 NMT 很慢，增大 beamsize 来扩大召
回量是不现实的。可以采用基于同义关系来扩大召回量。
6. 更好的泛化：基于概念来泛化
我们知道，数据驱动有自己的硬伤：那就没有数据就驱动不了。我们的模型最后
往往只学到了数据上的共现，却缺乏概念抽象的推理功能。例如对于样本“北京
双眼皮手术的价格=在北京做个双眼皮手术大概多少钱？”直接训练 DNN 模型，
我们很难泛化出这样的 case：乌鲁木齐修眉的价格 =在乌市做个修眉大概多少
钱？。而我们希望模型是有一定的能力来抽象知识并做推理泛化的。
一些解决的思路：
解决的思路有 UNK 问题，使用 copyNet 和 pointerNet。还可以做一些概念实体
识别的事情如下图所示：
我们首先把原始的数据先转换到概念空间中去，然后在概念空间中做泛化，然后
对泛化后的概念模板填充实体，得到最后的召回结果。
具体流程：
在线上一个 query 来了之后，我们先对 query 做标注，然后得到这个 query 的概
念形式，和概念对应的填充值，然后我们定向对 keyword 概念库来召回同义的概

念形式，最后填充概念值得到最后的结果。比如 query 是“乌鲁木齐纹眉多钱”，
可以分析得到对应的概念形式是“【地名】【美容项目】多钱”，我们在关键词
概念库中可以召回“在【地名】做【美容项目】需要多少钱”的概念候选，填充
完实体后可以召回在【乌市】做【纹眉】需要多少钱。
05
基于度量模型来做同义泛化
1. 基于语义度量来做同义泛化
还有一种方式是基于语义度量模型来进行同义泛化，大致的意思就是把翻译模型
换成语义向量模型，检索过程是在语义向量空间中寻找 K 近邻。
2. 在度量语义空间中召回同义变体
方法的实现思路是：
 投影到共同的语义度量空间中
 寻找同义的 query-keyword 在度量空间中的近邻
分两步来实现：
 投影
 寻找 k 近邻
获得投影算子：
投影算子有很多，例如 BOW、CNN、RNN 或者 Transformer；度量口径可以考
虑欧式距离或者余弦相似；在数据方面，因为最后我们会在整个全量空间中做语
义检索，和之前的翻译模型不同，我们需要同时考虑正例和负例，并且要精心的
去设置负例。
寻找近似 K 近邻：
在投影模型训练出来之后，进行 K 近邻的查找。首先是基于度量对空间做划分，
在 query 来了之后，可以快速定位到所在分桶。在此过程中可以用层次 kmeans
构建树形索引，然后 query 来了可以在 log(N)时间内定位到分桶。
06
基于图模型来做同义泛化
1. 匹配问题可以看做是 Link Prediction 问题
基于图模型来做同义泛化也是一个很好的方案，可以把匹配问题看作 link
prediction 问题，把 query 和 keyword 看成 node，匹配模式关系看成边。用图
来求解匹配问题，我们可以引入更多的数据，因为平时我们使用最多的都是一些
简单的线性数据，如用户点击数据，其实更为海量的数据是以图的形式存在的，
如用户的 seesion 日志和广告的购买账户层级数据等等，这样融合在一起形成一
个很大的图，我们可以把数据都融入到网中进行训练。
2. 基于图表示来做匹配
基于图表示来做匹配分为三步走：第一步是构造图，其次是计算每个节点的低维
表达，最后是为每个阶段寻找 K 近邻。
3. 基于递归图网络来计算表达
图网络可以选择的方案有很多，比如我们可以选择基于递归图网络来计算表达。
在递归图网络中，每一个节点的向量都是由其邻接的节点的表达聚合而来，这样
表达的好处是节点之间多跳的邻接关系，还有一对多的关系可以同时考虑到建模
道中来。比如对 E 节点而言，可以通过节点 B、N、F、C 聚合向量来表达，同
样的，递归下来，每个邻居也可以这么做。比如节点 N 可以通过节点 P、M、G、
E 来表达。两次传播之后，二跳的信息 G 就传到了 E 的节点表达中去了。
4. 总结
简单总结而言，基于数据驱动的方式做同义变换一般是基于种子数据抽象出一个
模型，通过模型来进行泛化得到 delta 数据。在这里，数据是源，模型是媒介，
什么样的数据就会有什么样的泛化结果。这种简单的 delta 泛化方法在实际中可
以很好的保持匹配模式。如果你的数据是 Phrase match 的，那么泛化出来的一
般也是 phrase match 的。但是在此过程中，因为输入数据的准确性和模型自身
的问题， delta 泛化不可能是百分百准确的，中间很有可能产生 bad case。

07
同义判定
如何对 bad case 进行过滤，是一个同义判定的问题。
1. 匹配模式判定
在精确匹配模式中，如何判定 query-keyword pair 是不是同义变体关系
( paraphrase identification ) ？
一种直观的想法是可以基于同义词对齐来做：这种方式的准确率高，但是召回出
来的结果很少，举个例子如“女人生孩子后腹部有赘肉怎么办？”，keyword 是
“产后如何减肚子”。那么“女人”这个词很难找出对应的关系出来。此时需要
一个泛化能力强的模型来做这样的事情。
例如训练一个分类模型，输入，label 是 0 或 1。
 Feature-driven 的方式是人工特征+少量标记数据+浅层模型；
 Data-driven 方式是 transformer + 弱监督预训练+domain finetuning。
问题的难点：
这个问题的难点，一方面因为 F 是一个全领域内的同义判别模型，在搜索场景中，
query 和 keyword 的量很大，而实际中只能够拿到很少的标注数据，这么少的
标记数据很难把方方面面的 case 都照顾到。另一方面，我们需要大量的知识来
提升召回和准确。很多同义关系知道的话，对应的 case 就可以召回出来，如果
不知道就完全召回不出来。此时模型需要很大的 capacity 来记忆和泛化全领域的
知识。
2. 特征驱动的小模型
在特征驱动的小模型中，利用人工定义特征：
 词粒度的匹配度计算，如 max matching length，miss/match 和 bm25
 命名实体的相似度、句法依存和文档分类
 语义相似性，如基于搜索点击数据的 DSSM
 搜索检索结果的相似度
在数据方面，需要少量的人工标记数据。模型一般是是浅层 DNN 和 GBDT 之类
的树模型。
3. 数据驱动的大模型
在数据驱动的大模型中，包括多阶段预训练 finetuing，在百度使用的是 ERNIE
Large+弱监督数据+人工标记数据的多阶段预训练加 finetuning 的方式。
数据方面：
 需要海量的弱监督数据例如用户侧的 query-query ，商业侧的
keyword-keyword 和 query-keyword
 少量人工标记数据。因为标注成本比较高，在标注数据之后，最好做一下
主动学习和数据增强
训练方面：
 使用多阶段预训练+finetuning+对抗学习来提高鲁棒性
从结果来看，其效果远超特征驱动的模型，因为是大模型容量+海量的数据预训练
让模型学到海量的同义知识，此外，Transformer 的多头注意力起到软对齐的作
用。
4. 为标记样本做最充分的数据增强
刚刚提到为标记样本做最充分的数据增强，增强技术在图像中使用较多，在 NLP
中使用较少，可以基于同义变换来增强，另外可以使用概念标注来进行增强。
5. 提升鲁棒性：基于对抗样本来防御
另外一方面，我们迫切需要提升模型的鲁棒性，传统的模型都是基于经验风险最
小化来训练，这本身保证不了模型的鲁棒性，比如模型在小扰动下预测的稳定性。
例如下面的例子，在图像分类的模型，对熊猫 x 进行预测的效果很好，在输入端
加入一些微弱的的白噪音扰动之后，人可以识别出来，但是模型很快就把它识别
成了其他动物。
基于对抗样本来防御：
一种提升鲁棒性的方法是基于对抗的样本来做防御，通常 GAN 是为了提升生成
模型的精准度，其实 GAN 也可以判别模型的效果提升，我们可以在原始样本的
基础上，生成一些对抗样本，最后混合起来作为模型的输入，以此来提升模型。
对抗训练是鞍点优化，在输入空间做梯度上升，在参数空间做梯度下降。
6. 开放的问题
但是事情还没有结束，在攻击对抗训练之后，只能保证样本 x 1、x 2 和 x3 的邻近空
间有鲁棒连续的结果。那么剩余的其他空间呢？我们知道 query 叉乘 keyword
是一个非常巨大的空间，在这么大的空间上的其他盲区怎么办？这个是一个开放
型的问题。之前我们使用的海量的弱监督数据其实是起到了这里的盲区补充的作
用。
08
总结
最后总结一下，本次分享的主要内容是关键词匹配的大背景、同义变换的应用场
景（包括同义匹配、keyword 队列压缩、Query 规范化和改写）和如何做同义变
换（包括规范化和知识推理），最后讲的是如何做基于 ERNIE 和对抗训练来做同
义判别。
CTR 预估在动态样式建模和特征表达学习方面的进展
分享嘉宾：秀武阿里高级算法专家
编辑整理：Hoh Xil
导读：富媒体时代，广告的样式需要千人千面，广告产品形态呈现多样式、多
物料组合形态，对 CTR 预估提出了巨大的挑战；针对这个问题，我们提出了
一种动态样式组合优选加 DSA 模型，并结合分位置拍卖技术，较完美地解决
了组合样式优选的问题。
另外，传统的 CTR 预估较少能挖掘特征之间的交互信息，我们提出一种
MCP 模型，通过辅助的网络结构来学习更好的特征表达，同时在线上
inference 时不会产生额外的计算消耗。
综上，本次分享的内容主要包括：
 动态样式 CTR 预估建模
 特征表达辅助学习
01
▬
业务背景及 CTR 介绍
1. 智能营销平台业务背景
我们的主要业务是搜索广告和信息流广告。搜索广告主要通过搜索 query 触
发，信息流广告是在没有 query 的情况下展示广告。
一个通用的商业广告系统，如右图所示：
 前端 server：包括媒体接入、广告样式封装等
 Server A：策略的中心 Server，实现各个下游 server 之间的连接，
以及排序和过滤等策略
 Server C：Server A 会先让 Server C 计算出一些候选的拍卖词或者
广告集合 ( 在搜索广告中称为触发，在信息流广告中称为定向 )
 Server B：广告检索，检索出广告的具体信息，并请求 model server 进
行 Q 值计算
 Model server：进行各种 Q 值计算的 server
 我们可能还会用到用户维度的实时信息，所以我们还有用户特征
server 和用户信息存储等基础架构。
整个商业广告系统是由做工程架构的同学来维护架构，策略同学进行策略的迭
代优化。接下来会讲下商业系统中非常重要的部分，也就是 CTR 预估。
2. Click-Through Rate ( CTR ) 预估
CTR 预估的重要性：
 Ad selecting：用 CTR 预估做广告漏斗的选择，也就是从检索出来的
广告中选出一部分广告进行精排。
 Ad ranking：CTR×bid 排序，CTR 估的越准，排序效率越高。
 Ad charging：广告计费，根据 CTR 进行广告计费计算。
在线广告的点击率 ( CTR ) 预估问题是构建一个预测模型，来估计给定用户
给定广告的点击概率。如图中表格所示：
给定用户 ID、用户属性 ( 如：年龄，性别，兴趣等 )，给定广告 Title，通
过用户的行为反馈，可以收集到这个广告用户点击/未点击，作为训练样本就
可以训练出一个模型 ( 一个非常复杂的非线性函数表达形式 )，然后推送到
在线的 model server 进行实时的 CTR 预估。
CTR 预估的问题看似简单，但确实是业界重点研究的方向，主要从如下几个
方向展开：特征优化，模型算法研究，模型应用的创新。
3. CTR 相关工作
回顾下业界常用的模型结构：
 逻辑回归模型 ( LR )：模型简单，容易实现，早些年非常流行。
 因子分解机 ( FM )：FM 模型增加了二阶项，可以做一些特征两两交
互的学习工作。
 深度神经网络 ( DNN )：最早以 Google 的 DNN 模型为代表，从结
构上对特征做 Embedding，再接几层全连接神经网络，由于我们是分
类问题，所以最后用 Sigmoid 计算 CTR 预估值。
 Wide&Deep：DNN 在泛化和推理上效果比较好，但是在广告系统中，
更希望有一些记忆的特性 ( 如果一个用户对广告有频繁的点击行为，
我们希望记住他 )，于是引入了 LR 的组件，来实现记忆的特性。
 DeepFM：华为基于 Wide & Deep 模型，又提出了 DeepFM，将 LR
升级为 FM，同时在 DNN Embedding 学习时，联合 FM 进行学习。
 后面还有 DCN，以及阿里的深度兴趣网络 DIN 等等。
我们团队的模型现状：
 大规模离散 DNN 模型作为基本的模型框架
 支持 Wide&Deep，DeepFM 模型结构
 自研了时空 DNN，深度记忆网络结构，可以更好的处理用户历史行为，
在 CTR 预估中起作用
 在特征 Embedding 学习方面，自研了 MCP 网络
02
▬
动态样式 CTR 预估建模
——CTR 预估如何赋能广告样式升级？
1. 广告产品样式升级
在前几年，广告样式主要是普通的样式：标题+描述，信息量非常少，用户真
正感兴趣的内容，需要在落地页中呈现。
近期针对样式方面，我们做了很多的产品升级，如右图所示，增加了商品列表、
图文混排、子链 ( 分组 ) 等样式。这样做的优点：
 更多信息前置，内容更吸引人，带来点击率的大量提升
 可根据用户意图个性化选择样式和物料，千人千面
 转化信息前置，提升转化效率
2. 动态创意的组件化
广告产品样式升级主要是通过动态创意来实现的，动态创意包含样式布局和组
件两个要素。如左侧的广告，我们将它拆成元素，有标题、图片、描述和分组
等各种子链区，我们将它定义成样式布局。有了样式布局之后，我们需要做的
就是填充，比如从广告库中找到标题，填充进去，同时把图片、描述等等也一
一找出填充进去。这样的方案对广告主来说是很省时省力的，因为广告主主要
关注的是内容的提供。对于内容的提供，我们也提出了策略的解决方案，广告
主只需要提供一些基础的内容，我们可以用算法生成一些相近的物料。对于组
件的样式不需要广告主定制，我们有专业的样式产品团队进行样式设计，然后
由策略团队做样式的策略优选，来确定哪种样式是最好的。
动态创意从产品逻辑上来看很简单，但是从策略上来讲是巨大的难点，首先要
确定哪种样式加物料的组合效果最优，而且针对不同用户和广告主最优；其次
还要考虑同屏展现下的最优组合。所以我们提出了整体的解决方案：先通过样
式+物料组合优选，确定每个广告的动态创意组合，然后通过 DSA 模型建模
分位置拍卖过程。
3. 样式+物料组合优选
首先介绍一个最基本的解法：
一个广告要展示的时候，我们第一层要选 Layout，确定样式的布局；选定
Layout 之后，要选定每个容器中放哪个物料，从图片到描述，到标题等等，
整个计算就是一个多连乘的公式，在线上如果要实现这一套计算，特别是每种
实际展现的样式我们在计算 CTR 时，单次检索的 CTR 预估次数会超过百万
次，致使单个广告 CTR 预估组合爆炸。并且不只是单个广告，我们检索可能
会检索出上千条广告，哪些创意要进入样式+物料优选，也是非常难的问题。
因此简单的样式优选难以实现，对性能挑战非常大。
4. 一种简单的算法升级
针对上面的问题，先看一种简化的解决思路：
 广告检索，基于原来的检索逻辑，先检索出来创意 ID
 CTR 预估，筛选广告，不计算样式和物料内容，只计算基本的 CTR 预
估值
 广告精排，确定展现队列，排序之后，在搜索广告系统中，可能只剩下
了少数条广告
 样式和物料选择计算，确定最终的创意样式
这样做的优点：
样式+物料计算的候选广告大大减少。
同时，缺点也非常明显：
 CTR 预估没有体现样式和物料带来的加成，使策略最优的效果没有体
现出来
 样式之间的相互影响没有体现出来，一个强样式排在前面时，会使后面
的广告 CTR 预估受影响。业界有很多论文在做这块内容的研究，大家
可以了解下
5. 样式+物料选择建模
因此，我们将问题进行定义：动态创意优选 = 组合爆炸 + Ranking ( eCPM
最大化 ) + EE
 针对组合爆炸的解法是运用贪心算法+EE。这里的贪心策略是将物料组
装的形式分层次来做，比如先选定标题，再放图片，进而放入描述，放
入子链，...，而不是整个展开来计算。如左图所示，树中每一个节点代
表一个容器，每一条从 root 到叶子节点的路径就是一个完整的样式。
 针对 Ranking ( max-eCPM ) 的解法是：CTR 预估+广告 EE 机制
优选策略：
① 每层容器优选
 组件多元关系 ( 互斥规则 )
 CTR ( 组件 )
 Ranking ( max-eCPM )
 剪枝 ( EE )：每层留多少个节点
② 每层优选使用前文信息 ( 上一层容器 )
③ 样式优选结束后进行组件物料优选
这里用到的算法和 Model：
 CTR 预估：DNN
 CTR 预估中的 EE：汤普森采样
 剪枝 EE：目前这部分还没有做，未来我们准备用深度强化学习 ( DRL )
来做剪枝，来决策哪些内容可以提前去掉，不用参与计算
6. 一种改进的算法流程
前面的算法，已经解决了大部分的问题，当然还有一部分问题没有解决掉，进
而我们又引入了 DSA 动态广告排序过程。
整个广告计算流程：
 基于原来的检索逻辑，检索出来创意 ID
 CTR 粗排预估，进行广告初选，筛选 Top N 广告
 针对 Top N 广告进行样式和物料组合优选，确定候选广告的样式+创
 PSA 机制按位置从上到下逐个计算广告展现
 DSA 模型考虑 rank，样式，物料，上文广告等信息计算精确的 CTR
这里的改进是增加了新模型 DSA，可以在上游 Q 值输入的基础上，增加上
文，位置，样式，物料等相关特征。另外，我们对 CTR 模型和 DSA 模型是
分别独立进行训练的，这里会存在一些问题。
7. CTR 粗选模型 + DSA 模型联合训练

独立训练存在的问题：由于是独立训练，两个模型都存在幸存者偏差，那么
CTR 预估模型中的选出的最好的广告，并不代表在 DSA 模型中就是排的最
好的，这两个模型解的不一致性就会带来策略的损失。
近年来，Multi-task Learning ( 多目标学习 ) 领域比较火，也是用来解决这
个问题的，所以我们引入了 Multi-task Learning 算法。针对前一版的改进
是两个模型联合一起训练，在特征层面可以 share embedding，在网络结构
上是两个共生网络进行联合训练。
这里一个小的 trick 是：有些特征在 DSA 阶段，不需要重复计算，所以我们
会把上一阶段的 Q 作为下一阶段的输入去使用。
8. 小结
本节内容小结：
 在动态样式产品升级的情况下，CTR 预估会面临组合爆炸的难题
 为减少计算量，可以先计算出广告展现队列 ( 减少样式物料优选的计
算量 )，然后再进行样式和物料选择
 即使单个广告的样式和物料优选也会面临计算量非常大的问题，所以引
入了贪心 + EE 的策略，逐层筛选最优结果
 先计算广告队列再进行样式和物料优选时，样式和物料的效果不能影响
排序，不是最优结果，收益不能达到最大化
 因此，引入 PSA 机制和 DSA 模型，将样式优选和排序过程融合起来，
能大幅提升效果
 DSA 模型可以和上游模型进行联合建模，进一步提升模型效果
03
▬
特征表达辅助学习
——CTR 模型的 Embedding 能否学习得更好？
1. 深度匹配、关联与预测网络 ( DeepMCP ) idea
常用的 CTR 模型结构，如左图，模型就是在学一个映射的网络，来实现特征
输入到 CTR 的映射形式。传统的模型是解 Feature 到 CTR 目标值的关系，
即使后面的 FM 模型，也是在解两两特征如何影响 CTR，并没有建模特征表
达是否相似。因此是否可以建立特征表达之间的约束学习，使模型具有更好的
泛化性？
我们的解决办法是在 CTR 网络结构中引入辅助的网络结构 ( DeepMCP )，
对特征和 CTR 之间的关系，以及特征和特征之间的关系进行建模。其中特征
和特征之间的关系，主要包括：用户和广告之间的关系以及广告和广告之间的
关系。
2. DeepMCP 概览
具体的解决方案是在原来预测网络的基础上，加入匹配子网络和关联子网络。
目标是学习具备好的预测能力和表达能力的 Embedding 模型。
DeepMCP 的优点：
 训练时，三个子网络均被激活
 线上做预估时，只有预测子网络被激活，不需用到两个辅助子网络，不
会消耗额外的线上计算性能
3. Motivating Example
背景动机：
如上图，u 代表用户特征，a 代表广告特征。用户 u 1 点击了广告 a 1 和 a3 ，
用户 u 2 点击了广告 a1 ，实际场景中，我们可能会需要预测用户 u 2 对 a 3 的点
击率，在之前的网络中，用户 u 2 和 a 3 在 Embedding 表达上没有任何的关
系，所以很难预测 u 2 对 a 3 的 pCTR。有了辅助网络之后，由于 u 1 和 a 1 的
Embedding 与 u 2 和 a 2 的 Embedding 比较像，可以推导出 a 1 和 a 3 的
Embedding 相似，最终更有可能准确预测出 u 1 对 a3 的 pCTR。
4. 细节
上图为 DeepMCP 的网络结构图，三个子网络共享 Embedding matrix。下
面将整个网络拆开分别进行介绍：
① 预测子网络
预测子网络就是传统的网络，给定一些特征，然后接几层全连接层，再通过
Sigmoid 生成 CTR 值，最后得到 Prediction loss。这里的预测子网络可以
替换为任意 CTR 预估模型，比如 Wide&Deep、DeepFM、Deep and Cross
Network 等等。
② 匹配子网络
匹配子网络主要是建立用户和广告之间的关系，广告是否一定程度上匹配用户
兴趣。我们把用户特征和广告特征分别经过几层神经网络，映射到两个相等维
度的 Embedding，再通过 tanh 激活，计算相关性得到 Matching score，
最后得到 Matching Loss。这里用到的不只是用户 ID 和广告 ID，而是用户
和广告相关的所有特征，因为我们是要辅助的学习特征的表达，而不是推荐系
统中只对 ID 进行学习。
③ 关联子网络
关联子网络是建模广告和广告之间的关系。我们首先要构建广告和广告之间的
关系，这里借鉴了图网络的思路，但是我们用到的是用户在 context window
一段时间内的点击序列，跟点击序列不相关的广告用随机负采样的方法
( skip-gram model with neg sampling ) 做负样本，这种方法跟 word2vec
算法的核心思想比较类似。收集完序列之后，把当前广告作为 target ad
features，用户点击的广告作为 context ad features，随机负采样的作为
Neg ad features，输入到网络中。网络的目标是当前广告跟历史点击的广告
学到的 Embedding 表达尽量接近，随机负采样的表达不接近。将得到的正
负样本的 loss 加起来就是 Correlation loss。
④ DeepMCP
对于整个网络，所有 loss 加一起的时候会有调制，我们加入了 α ( 对应
Matching Loss ) 和 β ( 对应 Correlation Loss ) 两个参数。调制参数的
调整是在 validation 数据集上监测 AUC，最佳参数在最高 validation AUC
处获得。在线上时，只使用预测子网络。
5. 实验
① 预估效果
我们分别在公开比赛数据集 Avito 和公司业务数据集，通过对比基础模型
( LR、FM、DNN、PNN、Wide&Deep、DeepFM )，并对我们的网络进行拆
解，DeepCP 代表只加入了一个 Correlation 网络，DeepMP 代表只加入了
一个 Matching 网络。可以看到 DeepMP 效果优于 DeepCP ，整体上
DeepMCP 效果最好。最终上线的时候，我们采用的是 DeepMP，在预估准
确性和模型复杂度之间达到了最好的折衷 ( best compromise )。在线 A/B
test 时，CTR2 + 2.9%，CPM1 + 0.9%。
② 调权参数的影响
经过测试，我们发现 Matching 部分的权重要大于 Correlation。
③ 网络参数的影响
这里主要是指 MCP 辅助网络的层数，主网络的层数根据业务来定。
6. 小结
本节内容小结：
 传统 CTR 预估模型主要是建模 feature-CTR relationship
 DeepMCP 额外建模 feature-feature relationship
( i.e., user-ad 和 ad-ad relationships )
 DeepMCP 是一种多目标学习 ( multi-task learning ) 框架
 DeepMCP 包含预测、匹配、关联三个子网络
 当三个子网络在 target labels 的监督下联合优化时，学到的 feature
embeddings ( representations ) 既具有好的预测能力，又具有好的
表达能力
 实验结果表明匹配子网络比关联子网络带来更大的效果提升
 最终我们选择了 DeepMP ( pred+match )，在预估准确性和模型复杂
度之间达到了最好的折衷 ( best compromise )
本次的分享就到这里，谢谢大家。
大规模图算法在京东广告的实践
分享嘉宾：张泽华京东算法工程师
编辑整理：王文婧
导读：京东的 9N 算法框架已经被广泛应用于推荐广告、搜索广告、以及其他的
站内外广告场景。本文将为大家介绍如何实现大规模的图算法在京东广告场景的
落地实践，主要内容包括：
 基础介绍
 9N GRAPH 工业化 End2End 算法解决方案
 算法建模：BVSHG
 未来展望
01
基础介绍
1. 电商推荐问题的特点
电商场景下推荐系统的问题特点：
 用户的行为少：电商是一个典型的货多人少的场景，用户行为非常稀疏，
且具有“极度长尾效应”，这个效应我们后面会展开详细讲。
 商品的规模大：前面说了货多人少，整个平台的商品规模能达到数十亿，
算上冷门商品及历史商品的话，甚至能到百亿规模。对于推荐问题来说，
数十亿的候选商品集合实在是太大了。对于工程同学，算法同学都是一个
不小的挑战。
 用户的需求识别难：电商不像新闻、媒体类的场景，这些场景的用户需求
和反馈都是来自于线上，比如某某上了热搜，这种场景下，信息源来自线
上，用户的反馈也会作用于线上，相对单纯一些；而电商场景，大家的购
物需求的产生和具体消费其实是在线下的，比如今天家里做饭少了一瓶酱
油，这种信息，线上系统很难感知到。
 用户的兴趣转移快：用户的购买行为完成后，兴趣会呈现不规则的快速转
移，举个例子，有些用户买了一台电冰箱，按道理说这是一个大件儿，重
复购买的周期很长，日常生活中不会有人每天都去看，都去购买的，但是
中国消费者有个奇特的行为，叫做“我再回去看看买亏了没”，没事儿就
回去刷一下商品看看价格。再举一个有意思的例子，用户买了一部手机，
那是不是有可能购买手机壳、手机膜这种搭配呢？确实有不少消费者这么
干的，但如果赶上 618 大促节，你会发现用户的上一个行为是去买手机，
下一个兴趣就是关于如何买拖把和抹布，这就是用户兴趣以及时效性带来
的挑战。
 热点更新快：尤其是现代电商网站每天有新品，每周有活动，每月有节日，
半年一大促，用户对新品的交互行为更为稀疏，想要让模型和算法学到甚
至能有预测能力，简直难上加难。
2. Why GRAPH？
刚刚介绍了电商推荐的问题和难处，我们回到推荐的本质上来思考这个问题，对
于推荐系统来说，其中的重要参与方就是用户和商品，而推荐系统的本质就是在
找用户和商品的关联性：
 以用户方来说：人与人之间存在天然的关系图谱，不论是显式的这种朋友
亲属还是隐式的社交关联等等，相信很多偏社交属性的公司早就深入研究
过人与人之间的图关系了；
 以商品方来说：商品本身的材质、属性、价格本身就存在关联，甚至是同
品牌、店铺、竞品的关联关系等等，通常很多偏新闻和资讯类的公司早就
已经构建了知识图谱。
能否将用户图和商品图连通起来，利用用户和商品关联性，构建成一张充满不同
关系边的图？这就是一张简单的 U-I 二部图，如上所示。
02
9N GRAPH 工业化 End2End 算法解决方案
如何把这张 U-I 图在工业场景下完成落地和应用？我们实现了一整套 9N GRAPH
工业化端到端的算法解决方案，它不仅包含数据能力、算法框架、算法模型还有
一系列的应用。
实现工业化场景的端到端学习，我们遇到了不少挑战，这里举几点出来：
 在数据和样本层面，我们遇到了超大规模的图样本生成及存储问题、图的
在线服务以及服务内图信息时效性的问题。
 在训练框架层面：如何实现一个训练框架，以及大规模图如何在工业场景
中训练，我们基于 9N Lite 框架进行了延伸开发，实现了 9N GL ( 即 Graph
Learning )。
 算法建模层面：如何解决端到端建模以及主模型和图模型联合训练，我们
提出了一个典型建模方法，最终也在业务场景上落地取得了收益。
9N GRAPH 的整体方案如右图所示，它包含 6 个层次，图中暗黄色的部分包含图
学习的多元化，图的探索和创新，是我们还在进行中的部分，其他颜色部分已经
在提供稳定服务了，其中浅黄色是在线工程团队帮助我们一起建设的在线图服务。
1. 9N GRAPH 数据&样本
① 如何实现大规模的图样本生成及存储问题？
通过对电商场景的用户行为进行分析，我们发现：行为数据呈现“极度长尾效应”，
换句话说是“旱的旱死，涝的涝死”。像图中呈现的，在 99 分位数之上的用户
行为居然差不多等于剩下的所有用户行为之和。
这种现象，对于传统的深度学习来讲，其实很不友好，传统的深度学习建模方法，
和训练策略比较适用于中高活跃的用户，他们的行为数据较多，但又不过分集中，
在多轮迭代的训练方式下，数据利用效果好。
反过来看，对于 99 分位数之上的那些极度活跃用户，他们的行为数据过于丰富
( 比如单日浏览了好几百个上千个商品 )，在工业场景上通常会因为工程性能问
题做出截断，导致仅有少数最近期的行为信息参与在线预估，反而会导致建模失
真，效果不佳。
对于长尾用户，他们的行为稀疏，甚至还有不少的噪声，建模较难，数据利用的
效果也很差。
我们希望用图的方式，解决这两类数据失真的问题：
 对于极度活跃用户：我们通过图的方式记录下来他的行为，在进行预估时，
通过各种采样的方法，让采出来的信息不像截断那样仅包含最近期的，还
有大量长期的信息。
 对于长尾用户：通过图的方式进行不同层面的信息抽取，增加泛化能力，
增强对长尾用户的建模能力。
以最简单 U-I 二部图为例，我们将用户大量的历史行为，通过 U-I 关系抽取模块，
建立起图关系数据差不多有 400TB 左右；又通过训练日志进行 label 处理，两者
进行关联后，形成图训练样本，通常能达到 800-1000TB；然后送入到模型训练
框架中，进行主模型和图模型的联合训练。
② 如何解决图服务及信息时效性问题？
高实时的信息可以带来不小的效果提升，因此在线的服务中除了需要包含历史长
期的图信息外，还要对最近期的信息有感知，所以我们设计并实现了一套秒级别
更新的在线服务。如上图所示，上面一条通路是包含数月信息的长期图信息，下
面的这一条通路是秒级别的实时信息更新，最终打造成了一个高时效性的图数据
服务系统。
2. 9N Lite 算法框架 Overview
接下来看如何实现一个训练框架，以及大规模图如何在工业场景中训练问题。
我们在介绍大规模图训练前，先介绍下 9N ( 即九数 ) 算法框架整体，因为图训
练也是基于这一套实现的。
九数算法框架是一个使用 Tensorflow 作为后端计算引擎的、深度定制的、支持
弹性扩展和高性能推理服务的算法框架。它基于广告精排的任务特点研发的，支
持了数年来京东广告的高速迭代发展。它包含四大基础设施：
 模型数据流：流批一体、离在线一体化的高性能数据流系统
 算子库：解决了特征系统及多模态、多业务的高性能实现
 核心训练框架：支持了多种业务场景，9N Lite 中不仅支持了复杂的有监
督深度学习，还额外扩展支持了 9N RL 强化学习、9N OL 在线学习、9N FL
联邦学习、9N GL（图学习）。
 NormGuard ( 一站式模型管理、检测、推送平台 )：是模型管控中心，
也是一站式模型检测及推送中心，还支持了模型指标的异常检测等等。
3. 9N GRAPH End2End 训练
如右图所示，从下向上看，整个 9N GL 框架做了多个层级的模块抽象，通过
subgraph 的方式，抽象出了训练日志相关的子图结构，通过 unify interface 抽
象出了各种图算子，通过 encoder 抽象了多种信息聚合方式；
整个 9N GL 将外部数据与样本关联的图信息抽象成了 SubGraph，支持多种不同
形式的 SubGraph，不仅可以支持数据样本级别，甚至可以直接关联到在线检索
系统甚至图引擎。
9N GL 也支持多种方式的主模型+图模型训练模式，多阶段训练以及端到端联合
训练。
9N GL 中的 API 设计相对简单易用，主要包含有几个层次的训练接口：
 图结构的点、边设计，支持多种行为类型，属性类型
 图的采样方法种类包含有随机、带权、Meta-Path 等等
 图算法层面包含有常见的 GNN 和 Graph Embedding 两大类
左侧是一段实例代码，仅需简单的函数调用，即可完成图解析，图邻居获取等操
作。
4. 图在推荐、电商场景的典型 End2End 建模思路

接下来，向大家介绍一下图在推荐、广告场景中的典型端到端建模思路。
以 CTR 模型为例，在信息源部分引入用户和商品的交互图结构化信息，通过图的
统一操作接口获取出建模所需要的图特征，然后经过特征编码器编码为常见的 id
类特征，后续可以通过一系列的 Graph Encoder 获取到用户、商品的高阶关系
表征。
此外，在异构图网络中，我们可以对不同语义空间进行节点信息聚合，来捕捉到
用户的潜在行为意图。
当然，以上是一个常见的 End2End 联合建模、联合训练的思路。接下来的部分，
给大家详细介绍我们提出的一个具体模型 BVSHG 是如何做的。
03
BVSHG
1. BVSHG：业界常见图算法 Graph Embedding

我们在详细介绍 BVSHG 模型之前，还是先来看一下业界常见的图算法和图应用。
首先是 Graph Embedding 类算法，顾名思义，GE 类的算法本质上就是将低阶
特征进行 Embedding 化，业界常用的有 DeepWalk、Node2Vec、LINE、EGES，
他们的思路大同小异，如下图举例来说：
 将用户的行为序列按某种标准拆分
 将拆分后的 item 构建一张同质图
 在图上随机游走，生成不同的游走序列/游走词
 按不同应用送入到类似于 Skip-Gram 的结构中
但这种做法通常适用于无监督学习，其监督信号与最终目标通常不一致，只适用
于多阶段训练。也没有充分发掘高阶的潜在关联关系。
2. BVSHG：业界常见图算法 Graph Neural Network

我们再来看下 GNN 系列的常见算法和模型。
主要有这几类：U-I 二部图、用户 session 图、社交网络、知识图谱。
在建模中也通常是围绕 U-U、U-I、I-I 三大类关系进行特征及属性关系挖掘。但
他的好处是可以结合最终建模的目标进行端到端学习。
3. BVSHG：Multi-behavior Multi-view Session-based Heterogeneous GNN
以上的两类建模适用场景不同，我们在其中发现存在一些不足，如：
 朴素的 U-I 关系图中并没有充分利用 Side Information（如商品的类别，
商品的品牌、商家店铺等等）
 U-I 之间的关系类型很丰富，不仅仅是常见的点击、购买关系，在用户与
商品的长期交互中，往往存在加购、分享、打赏、点赞、收藏等等。
 常见的 Session-Based Transformer 建模，并没有考虑 Item 间丰富的关
联关系，也没有考虑 session 之间的关系。
 针对我们之前跟大家提及的“极度长尾效应”，不同用户的行为序列长短
差距很大，在工业化场景下，出现的效果与性能 Trade-off 难题。
而我们非常贪心地希望既要对短期用户行为序列建模，又要对长期用户商品交互
信息的多视图抽取，还要在一定程度上解决序列化建模带来的性能挑战。
作为成年人，想全都要！因此我们提出了 BVSHG，即 Multi-behavior Multi-view
Session-based Heterogeneous GNN 建模方式。它的大致示意图如下，左侧
为图信息的构建，右侧为图建模方式图，接下来我们会分部分详细讲讲。
① BVSHG：Long-term Multi-Behavior Session Heterogeneous Graph

首先，我们重点讲讲如何构建的这一张长期用户多种行为 session-based 异构
图。
这是一张多元异构图，在图中你可以看到至少 4 类节点，比如红色的 User 节点，
蓝色的 Item 节点，黄色的 Category 节点，绿色的 Brand 节点等等。
此外，构图时，我们采用了用户和商品、类目、品牌之间复杂的交互关系，比如
上方的这个白色框中描述的是我们构建图时候用了用户的长期浏览 session 关
系，比如 session1 中包含 item 序列，对应的 category 序列，对应的 brand 序
列；
下方的框中，描述的是我们采用了用户的长期复杂行为数据，比如 User1 分享了
Item4，也就分享了对应的类目 C3 和对应的品牌 B3；
在右侧的图中，可以看出来，U1 对 I1、I2、I3 都有浏览边连接，但是对于 I4 有
share 分享边链接，U2 对 I3 有 AddCart 加购边链接。而图中的 I1、I2、I3 之
间由于存在同一个 session 内，有共同出现的关系，有共现边。
右侧中间的图描述的是 User 跟类目之间的边情况，右下方的图描述的是用户和
品牌之间的边的情况。
在此特别说明的是，我们只有一张包含多种节点、多种行为边的异构大图，右侧
的三个小图，是在大图中截取的一小段示意图。
当然了，在构建这张大图的时候，我们也有一些超参数需要调节，比如 session
切分的时间准则，通常采用 30min 作为 gap，但是并不是最优。
② BVSHG：Multi-Behavior Sample
这一页我们的模型分为三个部分：
 传统主模型部分，包含有 UserFeature、ItemFeature、ContextFeature
经过像 DCN 等经典结构后，计算出一个 Embedding
 图模型输出一个 Embedding
 短期用户 session 信息经过 Transformer 输出一个 Embedding
将上述 3 个 Embedding Concat 在一起，最终经过 MLP 输出 pCTR。
我们先重点介绍红框中的部分，这部分是我们的 TargetUser 从我们的大图中采
样找到的交互过的 Item，排成一个 list，用作 target user 的一种表达，也可以简
单理解为 1 阶邻居。
对于 target user，我们首先采用 Behavior-Weighted Random Sample 的方
式采样得到他的一跳 item 邻居，具体而言，该采样方式通过业务自定义的行为
权重，对用户的不同行为类型的邻居节点进行加权的随机采样。而对于 target
item 以及第一次采样得到的 user 的一跳 item 邻居，我们采用同质采样
（Homogeneous Sample）的方式，从图中得到相同类型的邻居节点。
③ BVSHG：Multi-View Attention-Based Item SAGE
现在，我们重点介绍 BVSHG 的精髓，Multi-View 信息的抽取和 Attention 玩法。
对应到上方的 I1，我们在大图中，找到 I1 的 i-i 关系表征，也找到 I1 对应的类别
C 的 c-c 关系表征，同理，我们也找到了 I1 对应的品牌 B 的 b-b 关系表征，这
三段向量与 I、C、B 构建出相应的 Attention 变换后 concat 在一起，形成一个
O。
同理，I2、I3 到 In 形成 O2、O3 到 On
同理，TargetItem It 形成 Ot，将 O1~On 的向量与 Ot 进行 Attention 计算。
④ BVSHG：Transformer-based Short-term Behavior Modeling

上图的红色框中，我们仍然借用 Transformer 对用户的短期行为 local session
进行序列关系的抽取，用来提取短期兴趣。
我们的 BVSHG 的思路大致介绍完毕了，模型结构虽然复杂，但是建模思路比较
清晰容易理解。
4. 业务效果
我们将 BVSHG 模型在京东推荐广告的精排场景进行了实验，模型的点击消费有
相应上涨。当然模型结构也可以作为抛砖引玉，图表征信息与主模型可以采用多
种方式进行交互作用，End2End 训练。
5. 图算法的其他玩法
我们再来看看我们尝试过的其他图算法的玩法：
 我们借助实时图，建立了 User Item 之间的二部图，并实时更新图内点边
关系，从中发掘出了连通的节点簇，我们以最大团、正则化割构成更加合
理的兴趣簇的分类标准。
 在工业化场景上，很多时候，数据中是存在缺失和错误的，我们利用了 U-I、
U-C 的事实图，两者进行联合修正，对数据做了增强和清洗。
04
未来展望
未来展望，我们最近一年在图上玩了不少花样，但总起来看，还有两个点我们还
有很强的兴趣继续探索：
 AutoML on Graph，由于我们构建一张图，进行联合建模的试验调试成本
高，尤其是在超参的调试上耗费了不少人力，亟待一个可以解放人力的超
参调整方法，我们后续希望借助 AutoML 的方法用资源换人力加快实验迭
代速度。
 基于图的强化学习，开篇我们找到了推荐系统的本质问题是在解决用户和
商品之间的关联关系，但这种关联关系既有短期的、也有长期的，但业务
评价标准更多是短期内能带来多少点击、多少商品购买，很难对长期的奖
励进行评估和建模，我们目前正在结合 RL 的方法，对用户长期购物路径、
对京东购物的喜好性分析、品牌影响力分析等等问题进行尝试中。
我们一系列关于广告、推荐算法的探索及工程实践将不止于图，9N AI 团队后续
也会尝试通过开源或分享的方式进一步与同行更好地交流和互相学习。
内容理解在新浪微博广告中的应用
嘉宾：陈兆基微博资深算法专家
整理：付一韬
来源：DataFunTalk
导读：做算法的人常说"数据为王"，而对于做广告的人来说，内容理解则是广
告投放的基础。本次分享将介绍在微博广告中，内容理解起到了哪些作用。主
要内容包括：
 广告系统及微博内容商业化简介
 内容理解能力不足引发的问题
 构建内容理解能力以及具体商业应用
01
广告系统及微博内容商业化简介
1. 广告系统各方利益诉求
广告投放实际上是广告主、广告平台以及用户三方利益分配的问题，因为需要
平衡三方的利益诉求，所以广告平台的核心任务是如何在尽量不打扰用户正常
的内容消费流程下达成尽可能多的广告主投放 ROI。
2. 广告投放核心任务
简单来讲，广告投放核心任务是让用户在合适的时间看到适合的广告。我们可
以拆解成三个部分，分别是：
 谁在看：对用户的追踪，对用户的历史数据收集及各种用户画像的挖掘；
 看的是什么：理解当下用户在平台上消费/交互过的内容；
 适合看什么：根据上面两部分加上其他信息，会针对该用户当下适合看
什么广告进行投放。
3. 非内容场景
在微博中，非内容场景主要是关注流/热门流。它主要的特点是内容多样，上
下关联性弱。在这样的场景下，用户对于流内内容没有太多的预判，广告也不
一定需要和紧挨着的自然内容有联系，所以这种情况下广告投放更偏向于选
人。
4. 内容场景
与非内容场景对应的是内容场景，主要包括正文页、评论和搜索等场景，用户
通过对特定内容消费进去该场景。在这样的场景下，投放广告对内容的相关性
有要求，所以内容理解对这类场景下广告投放的影响更为显著。
02
内容理解能力不足引发的问题
1. 问题及难点：针对单一内容
首先，针对单一内容/单一广告由于内容理解能力的不足会引发以下几个问题：
 营销内容监管：用户有时会抱怨平台的广告太多。经过日志分析，我们
发现除了通过广告系统投放出去的广告外，曝光记录中还包括用户关注
账号自行发布的营销目的较明显的"自然博文"，所以这个时候用户刷微
博的时候会认为这些都是广告，比如下图左侧中某明星在双十一发布了
一篇自然博文就带有明显营销属性。我们的解决方案是将非广告营销内
容通过模型自动识别出来，而这方面的难点就是每天发博量太大，而且
缺乏标注。
 内容展示时机把握：这个主要体现在相邻自然内容传递的情感不一定适
合做营销内容展示，比如下图中间上下两条自然内容都是关于某品牌的
概念机，但上面一条说它"没有实用价值"，是一条负面的博文，而下面
是一条正面的博文。如果下面是一条商业推广的广告，则当下并不是一
个好的展示时机。我们的解决方案是对自然内容进行情感分析和实体标
注，在广告投放是进行规避。难点是微博会"创造"新的表达方式，比如
2018 年的"锦鲤"事件。
 效果评估中的噪声：如果不对特定内容进行识别，那么创意模式引起的
特定指标表现"虚高"或"虚低"。比如下图右侧上方是一条"骗点击"的广
告素材 ( CTR 虚高 )，而下方是一条通过内容内嵌导流信息 ( CTR 虚
低 )。我们的解决方案是识别/标注特定内容模式，其中难点主要是广告
主会对创意进行不断迭代，我们也需要对模型进行不断的迭代。
2. 问题及难点：非单一内容
其次，针对非单一内容由于内容理解能力的不足会引发以下几个问题：
 营销内容同质化：主要的问题是违规内容暴力闯审，频控/负反馈失效，
比如下图左侧中的两个营销内容，乍看一眼两个广告是一样的 ( 发布
视频相同，文字相似 )，但是发布营销内容是不同账号的，这样用户对
一个广告点了不感兴趣，还是会刷到相似的广告。我们的解决方案是识
别标注相同/相似营销内容，而难点是在不同场景下面相同/相似的定义
是不同的。
 自然/营销内容不完全匹配：微博中娱乐明星/幽默搞笑/时事新闻是每日
自然内容曝光大头，这样商业属性并不明显，比如下图中间是微博的热
搜榜，这些自然内容所对应的标签是很难进行广告投放。我们的解决方
案是构建统一的商业内容标签体系，对自然内容进行商业属性挖掘，并
且基于这个进行广告投放。这里的难点是缺乏标注，覆盖率低。
 优质内容生产门槛制约中长尾广告：中长尾的广告主缺乏相应能力/资
金创建高质量营销内容，对于任何平台来说广告收入主要来源于一小部
分头部广告主这是不安全的，所以通常情况是要拉进来中长尾的广告
主。我们的方案基于过往效果好的广告，智能生成/推荐创意内容，而
难点就是现有模型能力与实际应用是有差距的。
03
构建内容理解能力以及具体商业应用
1. 内容理解任务
内容理解任务的定义：对于给定内容 ( 文本/图片/视频 )，通过算法完成几类
的事情：
 分词/实体识别：基本的分词和实体识别 ( 人名、地名、品牌等 )；
 情感分析：识别内容中的正负面情感，针对负面内容还需要进一步的判
定，例如对于全局负面 ( 空难、车祸… ) 是否出广告，针对特定品牌
负面内容不适合出特定品牌的广告，但不影响出其它品牌的广告；
 相似判定：给定两篇内容，判定是否相似，或者给定一篇内容和查找范
围，返回这个候选范围与之相似的内容；
 内容分类：构建一套商业的标签体系，基于不同的内容类型训练分类模
型，其中文本的分类和图片的分类最终结果融合是一个难点。例如卖手
机壳和卖手机的广告在图片上面是很难区分的，所以需要搭配着文案进
行区分；
 特定内容识别与生成：包括关键词识别、创意模式识别、智能创意生成
和基于微博内容构建明星品牌知识图谱。
2. 基于内容的广告投放
基于内容的广告投放是针对内容场景，除了在已有人群定向之外，增加利用内
容理解的方式进行广告投放和优化的能力，主要分为：
 标签构建：在标签构建中需要有区分度将内容分开，并且需要合适的颗
粒度来保证标签不会太细导致投放无法产生足够的曝光；
 对内容进行标注：有了上面的标签体系之后，需要对内容进行标注，我
们目前有两个模型：
1. 快速响应模型：基于公开语料来作词向量和倒排索引来应对搜索或
新发热门博文等；
2. 深度模型：基于 Bert 通过微博语料进行分类任务的 fine-tune，但
是由于性能的问题无法满足直接用于线上 inference 的延时需求，但
可以通过高速 KV 存储构建缓存，将深度模型的结果倒入线上投放；
 基于内容广告投放：将内容的标签打好之后，可以根据内容进行广告的
投放：
1. 隐式优化：在满足广告主人群定向的条件下，根据当前的内容进行
广告的优化，比如一个用户身上有两个标签 ( 汽车和数码 3C )，当用
户刷到了汽车相关的内容，在这个场景下面投放汽车相关的广告效果会
更好；
2. 显式优化：开放内容标签给广告主，将广告投放在选定内容标签对
应的内容相关广告位，这时并不关心当前请求对应用户画像标签属性。
上图是我们内容定向的简单流程图。
3. 明星品牌知识图谱构建及应用
对于为什么要做明星品牌知识图谱，主要原因是娱乐明星是微博内容的护城
河，而品牌广告是微博收入的核心，所以希望利用微博数据挖掘明星和品牌之
间的商业联系，更好的将这两者结合在一起。
构建明星品牌知识图谱的几个方面：
 实体：包括明星 ( 性别/年龄/别名 )、作品 ( 年代/分类/粉丝 )、品牌
( 别名/行业/粉丝 ) 等实体；
 关系：包括明星"代言"品牌、明星"参演"活动、品牌"赞助"活动等等；
 应用：有了上面的实体和关系，我们会基于 Neo4j/CQL 搭建在线查询
服务，对明星/影视作品相关内容进行商业拓展，并针对相似账号进行
投放推荐。
上图是我们明星/品牌知识图谱的一部分，我们看下上面可以怎么进行应用。
针对输入的 query "朱一龙"，我们可以通过上图左侧的图谱定位到朱一龙"代
言"味全酸奶，如果味全酸奶在微博投放广告就会出相关的广告，否则可以根
据味全酸奶对应行业信息出相似的广告。
另一方面实体还可以有竞争关系，例如上图右侧的图谱，宝马跟其他汽车的实
体存在"竞争"关系，宝马如果希望对投放内容进行"竞品"排除，可以根据图谱，
避免宝马广告出现在提及其他"竞品"的内容对应广告位。
04
总结与展望
在微博商业化中，我们对内容理解有以下几方面应用：
 构建统一内容分析/表达能力：针对文本/图片/视频这些内容使用算法进
行分析/表示，例如分词、关键词识别、文本向量化等等；
 统一向量表示：基于特定任务进行向量 fine-tune 来获得文本/图片/
视频的向量化表示，并将这些向量化进行融合；
 提供基础内容理解服务：基于获取的统一向量表示可以完成对基础内容
的理解，比如相似性判定、内容分类等等；
 灵活支撑各种商业场景：基于上面的基础内容理解服务，我们可以灵活
支撑上层各种的商业场景，例如隐式内容优化、显式内容售卖。
CSCNN：新一代京东电商广告排序模型
分享嘉宾：刘鹄京东算法工程师
编辑整理：李沛欣
导读：随着电商平台对图像信息的大量引入，通过图像分析来进行广告点击率判
断就成了新的趋势。本次分享的主题为 CSCNN：新一代京东电商广告排序模型，
主要介绍视觉信息在 CTR 排序模型中的应用。一方面，我们将介绍在工业场景下
使用 CNN 将图像加入 CTR 模型联合建模的方法；另一方面，我们指出传统用于
分类任务的 CNN 并不适合电商场景。将电商场景中丰富的、具有强视觉先验的"
商品类目标注"作为 CNN 输入的一部分，将有效降低 CNN 训练的难度，提升排
序效果。模型于 2019 年上线，是京东搜索广告业务中收效较好的一种算法，也
入选了今年的 KDD 论文集。在介绍方法的同时，本文还介绍了一些点击率模型整
体优化方案，有助于帮大家对这种算法在整体点击率模型框架中所起到的作用有
更加深入的理解。
本次分享主要包括以下内容：
 背景介绍
 CTR 模型的优化方向
 基于视觉信息的 CTR 广告预测
 我们的工作：CSCNN
 效果展示
01
背景介绍
京东搜索广告依托于京东和京准通的数字营销平台实现搜索场景下的流量变现，
每天帮助数百万的广告主触达数亿的京东用户。
1. 京东 9NAI 平台
京东广告算法团队主要做京东电商平台下全场景的广告流量变现，包括的业务
线包括搜索、推荐、站外、线下、品牌，360 营销等等。用到的主要的模型，
除了 CTR 模型，还有 CVR、出价、图像、创意模型等，这些都依赖于京东自
研的 9NAI 的机器学习平台。该平台拥有离线训练，离线预估，线上 inference、
模型的发版等功能。整个平台的内核基于 TensorFlow 框架搭建，并根据业务
进行了性能优化，离线训练的调度则基于 k8s 开发。
2. 电商环境下优化 ECPM 的主要方式
上图是京东搜索广告的直观的展示界面。当用户搜索 Query 为 "连衣裙 "时，
前序模块会召回 n 个广告，都是和连衣裙的 Query 强相关、符合 Query
约束的商品。
ECPM 排序的主要工作是 n 个广告内部顺序的精排。在广告场景下，排序的指
标就是平台的营收。
具体来看，作为 CPC 广告，广告主为每次点击支付确定的出价 bid。因此每次
展现平台所获得的价值，就等于用户点击广告的概率再乘以这次点击的出价，
即 ECPM ( effective cost per mile，千次展示期望收入 )。但是有时需要考

虑 Query 下所有展现给用户的商品对平台带来的总价值，即此时需要优化所
有展现给用户广告 ECPM 的和。但由于用户 Query 为"连衣裙"时，用户的下
拉深度有限，所以该问题是有约束的优化：在用户看到有限深度广告的前提下，
极大化用户对平台的总营收。
如果展现给用户广告之间的 CTR 条件独立，可以通过贪婪方式求解优化，即：
按 ECPM 从大到小依次展现给用户，这样 Query 下的整体收入最高。
而 ECPM 中的第二项 bid 是由广告主给出的。假如用 ECPM 的序作为训练和
预估的指标的话，广告主可能通过调 bid 来 hack 模型系统。为避免这种情况，
我们一般在离线时采用 AUC 作为训练和评估指标，通过训练 CTR 排序效果更
好的模型，来间接提升线上 ECPM 排序和线上收入。
02
CTR 模型的优化方向
CTR ( Click-Through-Rate ) 即在建模展现这条广告的情况下，用户点击的
概率。在搜索的场景下，该概率可以描述成依赖于 4 个不同类型输入的函数：
 Query：描述用户搜索意图。
 用户侧特征：描述用户的兴趣、偏好。
 商品侧特征：描述这个商品是否优质。
 context 特征：描述用户搜索时属于怎样的场景，是上班的时候搜的还
是周末搜的，此时是否有活动。
1. 特征工程与提取数据
特征工程主要包括以下几点：
多模态信息建模：
 人工特征：一般在构建 CTR 模型的初期，会花很多精力做人工特征，
比如说 ID 类的或者是实数的特征。通过构建有区分性的特征来优化模
型的效果。
 文本特征：描述细粒度 Query 中的用户意图。
 用户侧特征：对用户和商品之间关系的建模。比如说对用户序列进行建
模，或者是对用户和商品之间的交互关系做图表示建模。
 图像特征：它和前面的信息源的模态不同，但在多媒体的场景下，图像
一般是和文字一起构建完整的商品信息展现给用户，所以这部分的建模
也很有必要。
特征的交叉：FM 、FFM、DCN 等替代繁重手工特征交叉的方法。
解决过拟合问题：解决特征长尾稀疏时，embedding 的过拟合问题。
2. 对 CTR 模型做目标函数刻画
度量学习问题：之前给出的搜索场景不是很适合做 pointwise 的模型，主要的
原因在于在搜索的场景下，候选集很有限。比如说搜连衣裙的时候， n 个商
品都是连衣裙，并不需要区分用户点击连衣裙商品和鞋子商品的概率的高低，
因为它没有可比性。所以在搜索场景下，做得更多的是在小候选集下的优化过
程，此时需要做一些 Query 下的 AUC 的训练和预估。
Selection bias 问题：主要描述的是在电商场景下会出现一些训练集和测试集
不一致的情况。测试集指的就是线上预估的集合，因为在线上召回几百个商品，
要对这几百个商品进行排序的情况下，因为实际上一页展现的商品有限，可能
最终展现给用户只有头部的这几个有 label 的商品。所以在离线评估的时候，
只能评估这几个商品的使用情况，但是在线上 Serving 的时候需要对整体进行
排序，就要解决 Selection bias 的问题。
长期回报问题：在上一页 PPT 中给出了一些简单的假设，是当上下的商品没
有耦合关系的情况下，可以做贪婪 CTR 模型。如果有耦合关系，可能就要对
搜索词下的整个用户对电商平台产生的回报，即加和的 Reward ( 长期回报 )
建模。
3. 结合系统架构的工作
Online Learning：线上系统中数据分布式是时变的。工程上的传统方式是做
定期重启的全量训练。但由于数据量大，训练很慢，依然会导致训练和预估存
在时间/分布的 gap。online-learning 是一种很有用的方向，通过流式的数据
预处理和训练，使模型紧跟线上分布，解决时变带来的 gap。
线上分布式 serving：由于单机内存的限制，线上模型的体积会受到约束。我
们通过分布式和模型并行支持 TB 型的模型的加载，同时保证模型各部分参数
版本一致性。放开了线上内存的限制，增加模型的表达能力。
线上 gpu serving：放开线上计算复杂度的限制，有助于使用更深的更复杂的
模型结构来增加模型的表达能力。
所以说从整体上来看，本研究所探讨的使用视觉信息提升排序模型效果的工
作，主要还是集中在第一部分——特征和数据建模中多模态的建模。通过优化
这些图像的特征建模，能够得到商品侧更好的展现效果，进而提升用户对于商
品的点击率。
03
基于视觉信息的 CTR 广告预测
1. 视觉信息在商品展现中给人呈现的印象
具体 Intuition 可以从这张图中看出来：在整个搜索版面中，每个商品都是图
文结合的。商品主图的版面很大，有很强的视觉冲击力，而且主图中会包含很
多细节信息，比如说材质、纹理、款式等，这些信息是难以通过 title、ID 类特
征或者是一些属性信息体现出来的，只能通过图像来提取这些细节信息进行建
模。而且在训练的过程中，只对这些 ID 类特征进行辨别，可能还会遇到一些
稀疏或者冷启动的问题。假如使用 CNN 来提取图像特征的话，更有可能来避
免这些事情来提升模型的泛化性。
2. 使用图像建模的瓶颈
工程实现较为困难：此前用到的一些点击率预估模型都是比较简单的 MLP 的
模型，他们其实训练和 serving 都是非常快的。但是加上 CNN 之后，训练会
出现性能瓶颈，导致模型更新周期更长；serving 也会出现非常严重的性能瓶
颈，可能会直接影响线上服务的时迟。
建模效果收益有限：
在使用图像特征之前，我们已经提了很多的商品侧的特征，传统建模方式不能
完全保证从图像中来获取到的是增量细节信息。假如只提取到一些和已有属性
或者类目重复的信息，那么引入 CNN 直接建模图像的意义就很小了。
和传统图像的任务不同，例如检测分割或者是分类问题的监督信号非常强，但
点击率预估是一个监督信号很弱的场景。用户点或者没点二分类场景中，本身
就是包含了一定的 random noise。在这种监督信号不强、有噪的情况下，训
练好 CNN 是困难的。
3. 问题的解决
下面我们主要针对这两点做了一些已有方法的调研。
 固定提取 embedding 图像：不做二阶段的训练，从而规避前述问题。
但是固定的 CNN 提取出来的特征，无法保证和已有的属性、类目信息
不产生交叠，因此 CNN 提供的增量信息有限。
 端到端的 CNN 和 CTR 模型联合的训练：绝大多数工作还都是在做离线
的评估，很少有做工业级数据的线上 serving。所有工作都直接将传统
用于图像分类的 CNN 直接拼入 CTR 模型中，并没有做任何结构的改进
以适配当下问题 ( 后续会说明传统 CNN 解决 CTR 问题的不足 )。
 pre-training：使用图像分类/只基于图像的 CTR 问题，做 pre-training。
以期获得二阶段更好的效果。
04
我们的工作： CSCNN
接下来介绍的是在 KDD 2020 上发表的：专门用于视觉感知的电子商务中
的点击率预测场景下的类别特定的神经网络。
研究实验数据集来自 JD.com 中的广告展现、点击日志，前 32 天的 100 亿样本训
练，第 33 天的 50 万条样本测试。我们也在 JD.com 上数亿活跃用户的在线场景
中做了 AB 测试，结果表明本方法可以显著提升线上效果。目前本方法已经在
JD.com 最大的广告位上达成了全量。
1. 研究的出发点： CTR 模型建模本身存在的问题
传统使用 CNN 引入图像信息的模式，属于 Late Fusion。这种方法从 CNN 提
取出 embedding，再和已有的特征一起参与 CTR 的模型建模，本身就存在
一些问题。
 信息浪费：在建模图像之前，模型通过类目等 id 类特征就已经知道这
个商品是连衣裙了。而这些视觉先验现在还没有加到 CNN 的建模中来，
即这部分的信息被浪费了。假如知道这些先验，CNN 的任务就会更简
单些。换句话说，CNN 的任务应该是：在知道该商品为连衣裙类目的
情况下，提取出连衣裙相关的特征、捕获连衣裙的细节。假如能把已有
的视觉先验加到 CNN 的输入中，CNN 的训练和 serving 效果都会更
好。
 包含与类目无关的信息：如果把这些有视觉先验的信息提前告诉 CNN，
它就有可能避免提取到一些与类目无关的信息。对于连衣裙图片，可能
背景中有一些和类目相关性不高的物品。我们可以根据类别先验，避免
将背景噪声耦合进来。
综上，我们整体的方向就是通过已有的图像之外的视觉先验，帮助 CNN 的学
习。
2. SENet 作为特征再校准模块的作用
前期的调研中，我们发现 SENET 的思想和我们有些类似。做图像的同学都比
较清楚，SENET 是被插在每个卷积操作的 Feature map 之后，有点类似于
Self-attention 的小模块。首先把它的空间的尺度给压掉，得到 c 维的向量，
再做 c 维向量内部的交互，得到 c 维的 scale 乘到 c 维的 feature map 上。
举个例子，我有 c 个 Feature map ( 特征图 )，通过内部的交互来决定哪个
特征图应该加强，哪个应该减弱。这是一种类似 self-attention ( 自注意力机
制 ) 的 Feature map recalibration ( 特征图再校准 ) 的问题。在点击率预
估的问题中，recalibration 就有点像做特征选择。可以认为这 c 个特征图是表
示图像不同方面的信息，通过自注意力机制的方式去进行选择。但是有没有可
能把这些类目的信息或者是从其他地方得到的视觉先验加进来，做一些基于视
觉先验的特征选择呢？答案是肯定的。
3. 类目特定的卷积神经网络： CSCNN
Category Specific CNN ( 类目特定的卷积神经网络 )，具体的操作方式和
SENET 稍微有点类似。
还是以连衣裙特征提取任务为例，当给定类目是连衣裙时，可以把连衣裙的
embedding 加到 channel-wise attention ( 通道域注意力机制 ) ，以及
spatial-wise attention ( 空间域注意力机制 ) 的过程中。这种方式相当于为
输入的 feature map 提取和 category 有关的 channel 和 spatial feature
( 空间特征 )。或者说是在卷积的每一层之后，通过引入 category 的信息做
category specific 的 feature recalibration 。进而实现 category specific
的图像特征的抽取和图像特征选择。
这种逐层引入 category ( 类目特征 ) 的视觉先验到 CNN 里面的方法，可
以认为是在 CNN 逐层提取越来越抽象信息的过程中，不停地加入类目相关的
特征选择。最终 CNN 提取出来的视觉信息就是一种类目相关的信息，或者说
是把很大的图像信息抽取问题特化成小类目下的图像特征抽取问题，进而简化
CNN 的学习任务。
具体来讲，上面是具体的 channel-wise attention ( 通道域注意力机制 ) 的
实现方式。和 SENET 很类似的部分是在这里——通过 Feature map 来做一
些 average pooling ( 平均池化 ) 和 max pooling ( 最大池化 )，得到 C 维
的向量。而后又拼上 category embedding，从而相当于在前半部分得到全局
的图像特征表示。经过全连接，得到类目特定的通道域侧的加权系数。平均池
化和最大池化这两路加起来，经过 sigmoid 函数来得到通道加权系数，加权后
得到 channel 的 refined-feature map ( 提纯特征图 ) 。类似地还做了
category-specific Spatial Attention module ( 类别特定的空间域注意力机
制模型 )，它的方式就是把 channel 的这一维 average pooling 或者 max
pooling 掉，再拼上同样大小的 category embedding，经过卷积的方式，提
取到 spatial 的加权系数，最后得到 spatial 的 refined CNN Feature Map。
通过这两种不同的模块，我们在卷积的过程中，在每个 feature map 后，都
做了类目先验相关的特征抽取 ( 特征选择 ) 以提升 CNN 的学习效果。
3. 用 9NAI 进行的工程实现
再介绍一下为了解决前面说到的一些工程实现的问题，和对应的加速方法。
这张图是模型系统的简化图。从右下角开始看，特征通过线上 feature dump
下来。由于线上预估时实际上没有用到图像，所以这部分特征里也是没有图像
的。
经过对相同商品 ID 及其图像特征的离线拼接，特征中就同时包含了图像特征、
类别特征等三部分的特征，融到一起得到了一个端到端的带 CNN 的 CTR 预
估训练模型。
端到端训练之后，会产生这样一个问题：CNN 部分线上 serving 缓慢。我们
采用了一种空间换时间的加速方式。具体是我们先对全站商品的 CNN
embedding 进行离线预估，形成词表，把这个词表和模型的其他部分一起加
载到线上的系统中，线上就可以直接通过商品的 ID 来查到商品的 embedding。
之所以这样做，是因为统计发现广告主更换商品主图的频次很低。每天更新模
型，每天使用最新的 CNN 产出线上用的 Lookup Table ( 查找表 )，对这种

低频变化的主图是稳定可靠的。在线上通过 20G 的查找表，我们在 CPU 的机
器上实现了 20 毫秒以内的 tp99 ( 99%以内网络需求的最低延时 )。
4. 离线训练加速
加入 CNN 之后，原来可能一天能训练好的模型需要数天时间才能训练好，CNN
在这部分的离线计算瓶颈比较大。
具体进行离线加速的方式包括两部分：
 按照商品的主图进行聚合。我们将至多 25 个对应同商品的不同的请求
聚合 ( 他们可能是来自不同用户的，但是他们看到或者点击了相同的
商品 )。这批聚合了的请求在训练的过程中由于图像是相同的，所以
CNN 这部分只用 forward 和 backward 一次。这种方式在不影响离线
训练效果的情况下，能极大提升离线训练效率。
 单机 4 卡的同步更新。做这件事情的主要意义是可以节省 CNN 梯度回
传的次数，4GPU 只回传一次梯度，节省了 PS 框架下 server 传输成
本，进而提升离线训练速度。最终在百亿规模的训练集上我们可以在
24 小时内完成离线训练。
05
实际效果
接下来介绍整个算法以及工程架构在线上和公开数据集上的实际效果。
1. 算法模型在公共数据集中的效果
在公开数据集的实验用了比较简单的 CTR 模型，来检验图像特征提取的这部
分究竟起到多大的作用。这里没有看它和 CTR 模型的耦合，基本只关注图像。
以亚马逊的数据集为训练集，每个子类里边都有几十类的商品，采用 AUC 评
估指标，主要的对比方法分成以下几种：
 不依赖于图像的方法；
 依赖图像的方法；
 在图像之外加入类别信息的视觉先验的方法。
和我们最接近的方法是 SCA，它是在 image caption ( 图像描述 ) 方向的工
作，在卷积的后几层加入空间域和通道域的注意力机制。
对比之后发现，加入图像信息相比不加图像有非常大的 AUC 提升。通过
Fintune ( 迁移学习 ) 的方法也比非 Fintune 的方法好，主要的考虑是来自
于非迁移学习的方法可能提取出来的特征可能和已有的特征是有关系的，所以
做迁移学习效果更好一些。
这三种方法就是加入类别信息的方法。虽然已有工作也加入了类别、视觉先验，
但是他们都采用了 late fusion 的方式：CNN 并不知道这些类别的先验，CNN
提取了特征之后，再和这些类别、视觉先验进行耦合建模。
后两种方法都将类别先验加到了 CNN 里。SCA 虽然是在图像描述中取得很好
的效果，但是由于它无法很好地加到每一层的卷积后，对于简化 CNN 学习效
果并没有我们好。我们在所有的指标上都大幅领先了 state-of-the-art。
我们进一步回答了 category specific 模块对所有的 CNN 架构、注意力机制
的普适性。无论是 CNN-F 还是 inception，SE 还是一些 spatial attention 的
模块，加入了我们的 category specific 机制都可以得到一致的效果提升。
2. 算法模型在工业数据集中的效果
工业数据相比于公开数据有很大的不同，主要有两大特点：
 数据量非常大：150 亿的数据，3000 多类别数，还包含各种各样已有
的人工提取的特征。
 工业数据的特点：长尾、稀疏。
这里我画了几个特征的例子。比如 Query 这个特征，有 90%的 Query 出现的
次数不足 10 次。在这种非常稀疏的场景下，特征泛化性差，过拟合和冷启问
题严重。
我们的建模基础——CTR model 是三层的 DCN 的模型，提取图像信息的网络
采用了 Res18 的网络。我们在它的基础上进一步增加了 category specific 模
块。
研究发现，在基础的模型下，加入这种固定的 CNN embedding 已经有了一
些提升效果，但并不是很大。在加入了 Fintune 迁移学习之后，得到了进一步
的提升。再加入 CBAM 的模块，以类似 self-attention 的方式来决定哪些特
征应该加强或者减弱，整个模型效果又得到一点点提升。但主要的提升还是来
自于最后的 CSCNN，通过加入类目特定的视觉先验来帮助 CNN 的学习。目
前 CSCNN 已经在京东搜索广告上全量，每天服务数亿用户和数百万广告主。
因果推断在阿里飞猪广告算法中的实践
分享嘉宾：观宙阿里飞猪算法专家

编辑整理：王吉东
导读：在飞猪搜索 CPC 广告业务中，广告策略不仅需要考虑 CPC 消耗和广告主
ROI，平台整体营收 ( 即 CPC 消耗+自然交易抽佣 ) 也是不能忽略的优化目标。
传统上基于广告 pCTR、pCVR、bid 等因子的策略算法仅仅从广告曝光本身来对
广告主、平台和用户的利益进行优化，难以准确调优这一平台整体目标。我们通
过引入因果推断技术，将广告投放建模为对搜索产品的干预 ( intervention )，直
接预测广告投放与否对业务目标产生的 uplift 效应，作为下游优化问题的线性奖
励 ( rewards ) 或约束 ( constraints )，以支持各类线上策略。在本文，我们从
其中预算分配策略的视角，介绍飞猪广告算法如何利用广告效应模型进行业务目
标优化，同时也介绍模型底层特征 ( 如 CTR、CVR ) 的一些建模经验。主要内
容包括：
 平台视角下的广告预算分配
 因果推断技术
 因果推断在广告策略中的实践
 未来思考
01
平台视角下的广告预算分配
1. 预算分配：多目标优化问题
广告策略（或者说预算分配），本质上是一个多目标优化的问题。下面结合一个
示例简述一下这类优化问题的目标和约束。
从平台角度上来讲，预算分配的优化目标往往是包含多种复杂的因素的函数：
 平台变现效率（即 ecpm）
 广告点击率（ctr a d ）
 广告转化率（cvr a d ）
 广告主收入（gmv a d ）
 平台利润（revenuea d ）
同理，从约束角度看，主要包含以下约束：
 广告主总预算（budget）
 投放计划的投资回收率（ROI）
 点击率下限（ctr t h r e s ）
 广告主收入下限（gmv t h r e s ）
 平台利润下限（revenue t h r e s ）
另一方面，对于平台中的不同的业务，不同的用户，甚至不同产品不同的投放单
元，具体的目标和约束也会存在较大差异。针对不同的目标和约束，需要使用不
同的因子加以控制。
2. 常用控制方法和控制对象
常用的控制算法包括：
 PID：最常用的一种传统的工程方法
 对偶法：基于线性规划求解拉格朗日系数，得到影子成本，通过影子成本
进行线上控制
 线性插值法：通过历史数据拟合控制变量与目标变量的关系
以上提到的几种方法有一个共同的特点：都基于线性模型，因此，要想达到有效
的控制，就需要线性因子。
常用的控制对象包括：
 广告主的出价（bidding）
 CTR/CVR 准入下限
 参竞概率
3. 使用因果推断的语言建模
广告策略问题，常用的策略因子包括：
 CTR 预估（pCTR）
 CVR 预估（pCVR）
 出价胜出概率分布（Bidding Landscape）
然而，以上的策略因子具备局限性。以 GMV 为例，对平台 GMV 进行控制，仅使
用 pCTR、pCVR 等策略因子是不够的。因为从业务角度看，在电商领域，原生广
告和产品（包括搜索、信息流等）的相似度很高，因此广告投放的分布和对应原
生产品的分布是相似的；这样带来的结果就是，当广告的 CTR/CVR 高的时候，
自然产品的 CTR/CVR 往往也会很高；我们不能基于较高的 CTR/CVR 预估结果推
测广告投放的真实效果。
基于此，引入本文的主题——使用因果推断建模。
 公式中的参数 T 可定义成是否投放广告的 indicator 变量
 模型控制目标是平台的收入（即 GMV）
 建模问题定义为广告投放对平台 KPI 的影响，即在给定特征的前提下，投
放广告的 GMV 减去不投放广告的 GMV 得到的收益
只有通过建立上述模型，才能优化广告投放的真实效果，实现平台和广告主的共
赢。该模型涉及到的因果推断技术，将在下一章节详细阐述。
02
因果推断技术
1. 基本问题
将前文所述的模型抽象成上图所示：我们需要建模的是 T 对 Y 的影响（T 即是否
投放广告这个动作；Y 是平台的某项 KPI，如 GMV）。
然而影响平台建模的因素很多，比如不同活跃度的用户、不同的时间段、不同的
行业等，都会影响广告在搜索推荐中的转化效率。
2. 影响因素的控制和约束
如何在这种复杂的数据关系中提取出广告投放对平台的 GMV 产生的影响？一个
较为朴素的方法就是控制变量法，即人为控制和约束除了广告投放之外的其他相
关因子。
具体来说，有两类实现路径：
① 随机实验（切断 X->T）：假设 T 是随机分配的，即 T 与任何变量独立；
② 特征工程（切断 X->T，X->Y）：假设 X 包含所有的 confounders。
 定义 confounders：同时影响 T 和 Y 的变量
 若给定 X，则不同 treatment group 下影响 Y 的协变量分布相同，即 X->Y
是天然的随机分配
基于以上这两条假设，从数学上理解，其核心是比较投放广告与否的前提下，平
台 KPI 的期望：
由于 X 与 Y/T 独立，故添加条件概率不影响最终的期望值；这样，待求解的期望
值等同于实际样本分布的期望。从因果推断角度看，这是个比较理想的情况：从
观察数据上得到的模型，和我们期望的因果效应相等的时候，就可以直接使用机
器学习模型解决问题。
抛开数学公式，从常识角度也能解释以上假设：每组特征下可视为随机实验，得
到局部的无偏估计；那么任意样本上的效应，可以在相应的 X 的分布上积分得到。
3. 从机器学习视角审视
前文简述了一些因果推断领域的技术背景，下面从机器学习视角审视这个问题，
将会遇到两个挑战：
样本结构方面，对两组样本（T=0 和 T=1）的分布要求更加严格：
 对于一般的预测问题，只需要保证样本整体无偏，即可预估
 对于因果推断问题，除了样本整体无偏，还需要要求两组样本的结构相近；
否则会存在误差累计效应
对变量 T 的推断准确度要求更高，这并不是机器学习所擅长的工作：
 传统的统计模型，通过对数据引入假设，可推断参数分布
 大数据时代的算法模型，往往关注预测精度而非统计推断能力
4. 样本结构问题
基于前文提到的两个挑战，首先讲述样本结构问题的处理办法。
从业务角度列举一个简单示例：控制目标 Y 是归一化（即单 UV 转化）后的平台
GMV；处理组和控制组的用户分布有明显差别（处理组的用户价值较高，控制组
的用户价值较低）。
有 3 种方法可以解决这类问题：
① 随机实验
 选取部分流量，线上广告随机投放，不采用任何策略
 成本过高，难以落地
② 后采样
 通过重采样方法，使两组样本分布一致
③ 特征工程
 机器学习常用方法
 假设 X 包含所有的 confounders，则虽然两组样本的 P(T,Y)不相同，但
P(T,X,Y)相同
 实际很难做到，且对样本也有较高要求
在后面的章节中会详细介绍以上方法在广告策略实践中的具体应用。
5. 变量的统计推断问题
第二个问题是变量的统计推断问题：在大数据时代常用的复杂模型中，如何精准
推断某一个变量的效应？具体到我们的广告策略场景上，就是如何推断广告是否
投放这个干预变量对平台的 KPI 产生的影响。
这类问题其实是很多学科里面临的一个终极问题，很难得到真正解决。具体到工
程实践上，我们可以通过一个模型结构先验和 loss 设计，促使模型对这一单变量
学习到正确的效应。
03
因果推断在广告策略中的实践
1. 特征工程
先从前文提到的两大分支（特征工程，样本重采样）入手，具体讲述工程落地的
方法。
特征工程方面，目标是捕捉到所有的 confounders（即影响到广告是否投放，以
及影响到我们的平台效率的所有特征）。
首先参考广告系统里其他常见工作，例如广告的 CTR/CVR 预估模型；该类模型
对广告效率的预估，会预先将原始的复杂特征做汇总。基于此，整体的思想就是
基于原生的广告搜索模型做迁移学习。
然而，搜索推荐的信息流和广告策略的数据，两者的分布往往存在差异；因此会
涉及到模型的泛化性能问题，需要对模型的拟合精度和泛化能力做权衡。具体来
讲，通过策略采样的方式（模型结构类似 CTR/CVR 多任务模型，但是样本和模
型训练方式完全不同于 CTR/CVR），将原生信息流样本和广告样本作为两个任务
分别学习，最后通过 loss 融合实现多任务学习。
对于刚刚提到的模型精度和泛化能力的权衡的问题，我们采用
in-batchre-sampling 的方式，对于每个训练 batch，通过超参去动态调整原生
样本和广告样本的占比。
除了刚刚详细介绍的 CTR/CVR，特征工程还包括广告系统中常用的 Search Rank
Queue（原生产品队列）、用户画像等，在此不做赘述。
2. 样本重采样
除了特征工程，另外一部分就是样本的重采样。对于纯观察数据，如何在避免 AB
实验的前提下，通过重采样方法在投放广告和不投放广告这两组的样本中构造相
似的分布。
样本重采样常用的方法包括：
① Propensity Score Weighting/Matching（倾向评分加权/配比法）：
 基于样本被分配到处理组的概率进行重采样
 采样结果与随机分组相似
 Propensity Score 本身的准确度难以估计，不仅是用户行为用户偏好的高
维分布，还受到广告本身的很多策略甚至一些产品业务规则的影响，较难
进行机器学习建模，因此实际应用很难
② Original Space Matching（原始空间匹配法）等：
 避免预估 Propensity Score，直接在特征空间进行匹配
 需要注意分析样本分布
 实际应用可行
以上述搜索结果页为例，每个商品都可以得到一个模型预估值（pCTR）。可以将
整个页面 pCTR 的分布作为特征，用特征向量 Vmatch 表示；
首先对控制组（即未投放广告）的样本进行全量的索引构建；接着对处理组（即
有投放广告），按照控制组的向量索引，使用 KNN 方法查找最相似的 K 个没有

广告投放样本，进行配对。将控制组样本和处理组样本进行两两配对以后，很容
易通过对比两组对应样本的转化率或 GMV 来描述广告投放与否对平台 KPI 产生
的影响。
3. 模型设计
从模型设计角度，如何捕捉单变量的影响效应？前面提到过，这个问题很难得到
真正的解决；但是我们有几个启发式的方法可以得到落地应用：
 借鉴 ResNet 思想，通过单变量 embedding，结合深度网络短接（shortcut
connection）将其接入到网络的最后一层，从而避免复杂的非线性因素的
干扰
 借助迁移学习中的领域自适应技术（Domain Adaption），通过多任务学
习来实现。具体来说，是将两组样本的投放广告与否，当作 Multi-task 的
方式处理
 引入正则项（包括 Structure Regularization、Task Regularization 等），
借助对业务的先验知识，对任务的 loss 加入正则项，促使模型学习到广告
投放的效果
4. Uplift Evaluation 简介
因果效应模型的评估，和常见其他用户模型的评估相比，最大的难点在于，每个
样本都没有相反 label。对于这类问题，业界常用分位数分析法进行评估，即对于
每一类样本，按照广告效应的预测值，从大到小来进行分桶（上图左侧，分了十
个桶）；每个桶内聚集广告效应的预测值相近的样本（包含不同的 label）；将每
组样本内的 label 的平均值相减，得到该组样本的 uplift。

上图是个理想的情况：左侧贡献比较大，右侧贡献比较小，甚至是负的。基于柱
状图做累计分布计算，得到下图：
这个图和常规预估模型中的 ROC 曲线形似；同样，曲线下的面积（AUC）越大，
模型预估效果越好。
5. 模型 baseline： Direct Method
假如我们直接做预估模型，选取 SRP（结果搜索页，一部分是广告，一部分是非
广告）的特征，和广告本身的特征（包括 pCTR、 pCVR，以及单个 treatment
的 embedding）；模型预测某一条用户请求是否产生订单（listing to order）的
概率。
这类常用的预估模型，是将“广告是否投放”这一 treatment 作为一般特征。模
型的 baseline 是基于 pCTR/pCVR（包括最好商品的 CTR/CVR，以及广告商品
的 CTR/CVR 和最好商品的 CTR/CVR 的差距）进行预估，预估任务的 AUC 还算
理想（0.736），但是评价广告效应的 Uplift Qini 指数是负值；增加 DNN 后 AUC
有所提升，但是 Uplift 指数会变得更差。
由此可见，预估任务的预测能力和对广告效应的评价能力并非正相关。
模型加入样本匹配后（表格最后一行），将样本调整成近似随机实验的样本，可
以看出广告效应的预测能力就变成正向了。以上实验说明了针对 Uplift 进行建模
优化的必要性。
6. 模型改进思路一： Direct Method with shortcuts
将所有特征都连到一个 DNN 里面，采用了 ResNets 的思想，如上图所示：左侧
网络对用户搜索请求预期的转换效率进行建模，右侧网络对“广告是否投放”产
生的影响进行建模，最后通过线性模型加以合并。对于广告效应的推断方面，这
种模型相比于 DNN 会有一定的提升（uplift Qini 指数提升至 0.6）。

7. 模型改进思路二： Dimain-Adaption: Multi-task Learning
前文提到的建模方法都是将单变量 treatment 当作一种特征，建立基于网络结构
的模型，这类基于网络结构的模型在特征权重拟合方面会受到模型结构以及数据
的限制。
这里尝试换了一个思路方向，借助领域自适应中的多任务学习方法，将“是否投
放广告”作为两个不同的任务（而不是一个任务中的二级特征）进行分别预估，
通过建立完全不同的网络来学习“是否投放广告”产生的效果。在重采样后的样
本拟合后，uplift 指数可提升至 0.11。然而这种方法更容易对数据分布过拟合，
从上图的右表也可以看出，对于未重采样的原始样本，uplift 指数反而会更差。
8. 模型改进思路三： Effect-Net
最后一个就是显式建模单变量 treatment 效应，即从模型的结构上体现目标效应
的作用方式。类似于前文所述的改进思路一，使用两个网络分别对预测效果和广
告投放相应；与思路一不同的是，在模型结构上可以显式地体现出业务理解的先
验，即最后一层的模型融合部分，显示地将控制组的输出与 uplift 相加，得到最
终的预测值。使用 Effect-Net 方法，由于强先验知识的引入，在原始样本（即未
重采样的有偏样本）的表现效果最好。
04
未来思考
1. 因果推理与深度表示学习之间的关系
基于已有的工作，学界提出了以下几点思考：
 怎样的表征是有利于因果效应的估计的？
 怎样理解表征与 confounder 的关系？
 表征学习在 debiasing、模型泛化等问题中的应用
基于以上几点，目前对于表征学习和因果推理方面的前沿研究方向主要是
Balanced Representation Learning。
2. Balanced Representation Learning
Balanced Representation Learning 本质上仍然是一种多任务学习，将投放广告
组和未投放广告组进行分别建模，进而将两个数字相减，得到因果效应。之所以
称之为 balanced，其实是在目标上加了一个约束，促使两组样本上学习到的表征
分布相似。
然而实际情况中，两组样本的分布是存在分布差异的。主动约束 IPM 的做法存在
方法论上因果倒置的问题：随机或自然实验中，正是因为实验分组与协变量的独
立性，带来了各组样本分布的相似性，而反过来在模型训练中通过目标函数的构
造来获取分布相似的表征，能够带来准确的因果效应估计，是值得怀疑的。
从另一个方面看，在学习相似分布的过程中，必然要求模型忽略掉部分
confounder 的效应，这又进一步违背了因果推断中条件独立的假设。类似的工作，
现有的改进方法和改进思路或多或少存在不足，这一方向存在很大的改进空间；
团队也在着手这一方向的深入研究。

互联网核心应用（搜索、推荐、广告）算法宝藏书

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

互联网核心应用（搜索、推荐、广告）算法宝藏书

Uploaded by

Copyright:

Available Formats

DataFun：成就百万数据科学家！

DataFun 专注于大数据、人工智能技术应用的分享与交流。发起于 2017 年，在

北京、上海、深圳、杭州等城市举办超过 100+线下和 100+线上沙龙、论坛及

峰会，已邀请近 1000 位专家和学者参与分享。其公众号 DataFunTalk 累计生

产原创文章 400+，百万+阅读，11 万+精准粉丝。

本书来源于 DataFunTalk 发布的原创及作者授权的技术文章，精选搜索、推荐、

广告方向文章各 8 篇，490 页，13 万字，希望对从事本方向的从业者和爱好者

CTR 预估在动态样式建模和特征表达学习方面的进展........................... 393

在介绍查询 ( Query ) 理解之前，我们先了解下美团搜索，左图是美团 APP 首

获取用户的查询 Query，在理解查询 Query 后，对接到所服务的各种各样的业务

美团搜索是典型的 O2O 搜索，右图显示了对比传统的网页搜索以及电商搜索的一

另外一个重要的特点是基于位置的相关性比较高，因为 O2O 主要是基于本地生活

蜂窝是类似外卖这种业务，它的配送范围是很有限的，大概可能 3~5 公里的范围；

下面介 绍下查询 理解系统 。QU ( Query Understanding )，主要 利用基础 NLP

能力，对我们的用户输入的 Query 进行分析，产生一系列的基础信号，然后这些

上图是查询理解 DQU 项目的架构。

经验，平台就成了很有价值的工作。目前 DQU 的项目已经支持了公司内大部分

整个框架分三个部分，最底层是基础信号层，主要是 NLP 相关基础信号模块，可

首先是实体识别，对比于通用网页搜索，电商和 O2O 搜索更多的是结构化的召回。

后对应到我们的 Doc 端，通过不同的字段进行召回。

面”。所以我们需要结构化召回来保证更高的精度。其中 NER 是指导召回的关键

接下来讲一下 NER 模型迭代相关的一些工作。初期线上的模型主要是 CRF，在

19 年引入了 BERT 模型。这里面主要是两个方面的改进，一方面是训练过程，引

入了美团 UGC 的一些数据，用这些评论相关的数据进行预训练，补充 O2O 场景

下的一些语义信息。再就是 fine-tune 阶段，我们除了人工标注语料的数据集，

对于大规模的模型训练，语料是非常重要的一个部分，但是对于 NLP 任务，一般

工标注语料，训练一个 Model A，然后针对线上已有的实体库去预测打分，对打

边界和类型，把用户 Query 中识别出的实体成分进行落库，同步到实体库中。

Query 中的实体边界的切分，主要参考该 Query 召回的多个 Doc 结果的命中信

来寻求一个切分概率最大的方式，具体可以参考文章《美团搜索中 NER 技术的探

下面再介绍一下实体链接的一些相关工作，美团搜索场景下的 LBS 属性，决定了

身还可以修正 NER 的结果。

离线的部分，其核心是对所有物理实体 mention 的挖掘，其实就是实体的一个别

主要结合 Query 文本序列的特征、基于地理位置的特征（比如城市和 GeoHash），

还有上下文的一些文本信息进行消歧排序，返回给用户最相关的 Top 实体。

核心算法如上图。离线部分，刚才也提到了主要是 Mention 的挖掘，目前基础数

据，主要是商家库的数据、搜索日志、UGC 评论、知识图谱等。Mention 挖掘目

 挖掘式：主要是通过用户评论和搜索的点击 session 日志，通过用户行为

 生成式：主要是通过 Seq2Seq 的一些模型，自动化的去生产一些泛化实

为什么需要查询改写？主要因为自然语言表达的多样性，首先是 Query 和 Doc

之间表达的差异，用户的 Query 会相对随意，而 Doc 端相对正规，商家和运营

多长尾 Query 的搜索。

比较容易通过搜索日志的 Session 来构造，甚至还可以用 Query-Doc 的点击数

解码如果不加限制，会产生组合爆炸的问题。所以结合了 BeamSearch 以及业务

相关的过滤器，例如利用 NER 和实体链接的信息，对商家实体词限制改写，通过

这样的一些业务特征来保证精度。通过路径裁减，返回概率最高的 Top-K 的结果，

词典和 Pattern 规则，能比较好的解决热门识别，针对长尾部分，主要靠 Bert 模

上展示的每条 POI 结果，后台都有明确的业务归属，所以我们就可以依据这个业

征主要分为两部分，一是统计类的特征，包括一些 CTR、CVR 及相关的用户行为

的特征。二是 Embedding 类特征，来进行语义的表达。

查询改写、意图识别。查询理解是搜索引擎与 NLP 结合的产物，用来解决搜索相

知乎的搜索算法团队成立于 2017 年底，于 2018 年 8 月上线了深度语义匹配模

型 。在 2019 年 4 月 引入 了 BERT 模 型， 同年 8 月 排序 模型 由 GBDT 升 级为

DNN 模型，随后在 DNN 模型的基础上进行了一系列的迭代升级。

一次搜索流程主要包括 Query 解析、召回、排序几个阶段。用户输入 Query 之

后，首先要进行 Query 解析，生成查询 Query Tree 和语义表示向量。之后进

在这一环节会筛选出前 400 的文档进入到排序阶段。排序阶段又分为精排和重排

1. 由 GBDT 模型升级到 DNN 模型

2019 年 8 月份我们将排序模型由 GBDT 升级到 DNN 模型，这么做主要是考虑

 数据量变大之后，DNN 能够实现更复杂的模型，而 GBDT 的模型容量比

升级到 DNN 模型之后，线上效果有一定的提高。

的，TF-Ranking 使用了 Estimator API，提供了排序任务常见的损失函数和指

标计算实现，比如 Pairwise Loss 和 NDCG 指标，以及通过 Multi-head 支持

 特征输入模块，将 Query 特征、相关性特征、文档质量特征和历史点击特

下面介绍下查询理解系统。QU ( Query Understanding )，主要利用基础 NLP

型。在 2019 年 4 月引入了 BERT 模型，同年 8 月排序模型由 GBDT 升级为

hard sharing 结构不同， MMOE 引入了 Expert，将共享参数层替换为多个

shallow tower 的部分加一些 dropout 防止模型对 Position Bias 的过度依

所以存在线上线下不一致的问题，而这种不一致对于 SE Block 的计算影响很

召回字面不匹配但语义层面相近的商品，如 query='2-3 周岁宝宝玩具'是无法召