想要聊广告中的召回技术，就要明白广告的召回模块到底解决的是什么问题。

01 广告召回模块解决的核心问题是什么？

工业界搜推广的召回模块，解决的问题基本上可以用这样的范式去定义：

在一定的时间与资源限制下，从所有可能的候选集中，选出一个合适大小的候选子集，实现某种指标的最大化。

具体到广告这个场景，如果将召回系统定义为一个函数，则这个问题可以被具象化如下：

其中是衡量广告候选子集价值的函数，是处理召回阶段的时延，是召回模块的输出广告的最大规模。

这个定义看似简单，实际上却引入了非常多的问题。接下来，我将对这些问题一一进行讨论。

01-01 问题1：什么是与当前流量匹配的可投放广告全集？

这个问题可以看成两个子问题：

与搜索、推荐系统不太一样的是，广告系统中额外增加了广告主这一个第三方的参与。因此，与搜索、推荐中的物料不完全一样，广告有两个非常重要的特性：

正是这两个特性引出了上面的两个子问题：

对于子问题1，搜索类广告通常提供竞价词候选，来完成流量与广告的匹配关系，如“苹果 IPhone 手机”等；而展示类广告则通常提供各式各样的人群包，如“北京18-25岁的女性用户”，“对运动类关键词感兴趣的用户”等。

对于子问题2，广告管理系统通常会提供几类工具，帮助广告主控制广告投放的状态，比如，广告计划的暂停与开启、广告投放时段的设置、广告预算的设置等，这些设置基本上需要在很短的时间内生效到系统中。

因此，在广告系统中，召回模块首先要解决如何找到与当前流量匹配的可投放广告全集问题。

01-02 问题2：如何在满足系统约束的情况下，挑出价值最大的子集？

对于一些大规模的广告系统，召回模块的可投放广告全集通常在几十万到上千万不等的规模（如果规模过低，如几百几千等，召回模块基本上不需要做复杂的算法优选），在这样的状态下，如果对于每一个可投放广告都放行到后链路进行计算，显然是不划算的。原因有二：

基于此，召回模块需要在满足系统约束的情况下，从候选全集中挑选出价值最大的子集，同时尽量减少上述两种原因的影响。

由于存在响应时间的限制，在输入的候选规模很大时，给召回模块留下的处理时间并不多，显然，召回模块需要用一些高效而实用的方法，解决召回函数应当如何设计的问题。

从问题的定义来看，其实是一个挑选价值最大集合的组合优化问题。不过，在规模为的候选集上选个，通常是一个的组合计算规模，这个计算规模对于召回模块来说，实在是太大了。

不过，这种问题不是没有解法。当一次流量请求时，返回的广告个数通常远远小于，一种贪心的算法是，直接在召回阶段给出一组TopK的结果，即：

寄希望于这个TopK的结果中大概率包含最优的几个广告结果，则召回的问题变为：

通过这样的简化，召回模块由一个集合优选的问题，缩减为一个TopK的单点计算问题，计算的复杂度被大大降低，同时，单点计算的状态使得大规模的并行计算成为可能。

一般来说，为了解决这个TopK的计算问题，广告的召回模块通常采用了两大类的解法，即基于专家系统的规则类召回以及基于数据驱动的模型类召回：

召回模块的优化，离不开对这两大类召回算法的不断迭代和演进。

两种方式各有优劣，在很多的广告系统中被同时使用，构成多种召回通道，以获得更大的收益。由于召回模块时间短，计算规模大，多通道召回的模式，相当于利用多组TopK计算结果，对最终的结果进行优化提升，达成类似集成学习（Ensemble）的效果。

不过，一般这种多通道召回的模式，由于各个通道内部取TopK的方式不一致，因此，有些召回模块中内置了一个粗排（Pre-Rank）模块，在同一标准下进行TopK的计算。

01-03 问题3：召回的其他优化方向？

仔细观察召回的优化目标：

除了解决TopK的计算问题，其实还有其他的优化模式：

这些优化方式带来了更多的优化问题，比如，为了优化候选集，广告系统通常通过产品的升级、运营的宣导、效果的优化，增大广告主对广告的供给量。再如，更低的时延函数和更大的输出集合，通常依赖算法和工程架构的优化与升级。

02 广告召回模块中的一些通用技术

为了解决广告召回模块的核心问题，广告的召回模块发展了不少的通用技术。

02-01 召回的基础范式：两阶段召回和先召回后归因

在讨论召回的基础范式之前，需要明确召回的输入信息。

对于广告的召回来说，输入来源其实可以被切分成两处，即用户流量端的请求，与广告主端的输入。搜索类广告和展示类广告，虽然形式上有所差异，但是都可以归纳成类似的模式。

先从广告主端的输入谈起。广告主端的各种操作，本质上是为广告系统提供广告候选集。不过这样的候选集通常带有流量端的约束，具体来说：

再看流量端的输入。流量端的输入，可以通过某种方式进行聚合，具体来说：

仔细观察这种关联关系，可以给出问题1的一种天然解法，满足流量与广告的约束关系，该解法被称为两阶段召回法：

这种两阶段召回的方式，在很多广告的系统里成为一种基础范式，发挥了重要的作用。

这种两阶段召回法也隐含了问题2的解法，即将流量与广告的匹配与价值最大的Top广告候选问题，转化为一个两阶段的优选问题。具体来说，为了得到价值最大的Top广告候选集：

这种两阶段的分开优选，能够一定程度上解决召回模块的前两个问题，即有效性和优选，但也存在一定的局限性，即这种两阶段的优选不一定是真正全局最优的。

流量与广告的价值衡量最终要由流量与广告去决定，但在两阶段召回中，这一价值被拆分到流量到竞价词/人群包的优选，以及竞价词/人群包到广告的优选上，明显会带来两个问题：

因此，解决召回的优选问题，更有效的方式是直接去计算流量与广告的价值，再进行优选。不过，这种计算，有可能不满足召回的有效性约束，即优选出来的Top广告，可能会违反流量与广告的匹配关系。

好在这个问题是有解法的。仔细观察召回中的两阶段关系可以发现，不管是搜索类广告，还是推荐类广告，最终得到的是一个三元组：(Query, Bidword, Ad)或(User, Crowd, Ad)，在这个三元组中，有一个中间介质，即竞价词（Bidword）/人群包（Crowd）。两阶段的召回范式，在不违反广告对流量的约束条件的前提下，以这个中介媒介为核心，对流量和广告进行关联与优选。

在直接计算流量与广告的价值的情况下，为了得到这样的三元组，可以使用先召回后归因的范式：

两种召回范式的示意如下图所示：

值得注意的是，这两种基础的召回范式并不互斥，并不是非此即彼的关系。比如，在两阶段召回范式中，一些对流量属性的限制，如时间、年龄、性别、地域、设备等，是通过召回广告后，通过流量侧的属性与广告的选择做过滤实现的，本质上也是一种先召回后归因的模式；在先召回后归因的范式中，召回广告的方式也可以用两段式召回的模式实现。

02-02 基于召回范式的配套系统设计

为了适配召回的基础范式，很多广告的召回模块设计了这样的系统架构，完成不同的功能：

此外，由于很多广告系统的召回模块采用了多路并行的方式，为了衡量不同路召回的效果，获取TopK的候选集给后链路，一些召回模块还内嵌了一个排序计算模块：

值得一提的是，广告的召回模块，有一个与搜索/推荐的召回模块明显不同的地方，即广告的召回模块在处理流量请求的同时，还需要实时响应来自广告主端的各种操作。

具体来说，广告主可以通过在广告管理平台上进行操作，对广告的状态属性进行实时的修改，广告系统需要对这些广告的状态进行实时的感知与响应。为了解决这个问题，召回模块在检索阶段，内嵌了一份广告索引的数据，用来接受广告管理平台的变更状态。

广告索引（Ad Index），顾名思义，是存储广告的一种数据结构，按照检索主键的不同，索引通常被拆分为两个部分：

同时，广告主对于广告的状态属性设置都会存储在这个索引中，通过实时流处理技术进行实时更新。这些状态属性，通常包括：

召回模块的系统设计如下图所示：

02-03 相关的召回算法

明确了召回的范式和配套系统设计，接下来可以谈谈召回中的相关算法。

由于粗排阶段的相关算法与排序模块更为相关，与粗排相关的算法，将放在之后的内容中进行讨论。

先看搜索类广告中的相关召回算法，按之前的范式讨论，搜索类广告要解决的召回问题有以下几种：

与搜索中纯粹面向相关性的Query改写技术不同，广告的Query改写还需要考虑改写到竞价词后的广告收益，因此，也有一些改写算法面向系统收益最优进行建模，比如按照广告覆盖度的规则匹配或者以最大广告收益的建模方法。

搜索词到广告的直接召回技术，即利用搜索词Query直接从广告库中检索广告的技术，常用的技术有：

再看展示类广告中的相关召回算法解决的问题以及相关的算法：

在这些算法中，当广告候选集足够大时，模型类解法总让很多人趋之若鹜，觉得有很大的潜力去挖掘。在召回模块，除了传统的模型结构优化、特征样本选择、模型更新时效性问题之外，模型类解法还需要解决两个重要的问题，即算力分配和建模方式：

关于这些方式的优劣与选择，我将在之后进行更细致的讨论，此处不再展开。

除了这些流量端的召回算法外，广告的召回模块还有一些面向广告主端的算法迭代，比如，在广告主建立广告时，召回端可能需要对广告主投放的广告物料给出一些竞价词/人群包的推荐，以得到更优的广告结果，这类算法的精准度也一定程度上影响广告主的投放体验和意愿，进而影响广告库的大小，因此优化这些面向广告主侧的算法，也有利于提高竞价深度。

当然，上述的讨论只很浅的涉及了广告召回中的皮毛概念，想要真正解决召回中的各种问题，还需要对整个系统进行深入了解，并根据具体情况进行展开分析。