bs架构多用户访问_实习笔记 D5 | 凤巢广告的检索架构

本篇文章逻辑：从最左边的流程讲起，一共讲四个流程，直到最右边的流程(建议图片发送到电脑，和文章对着看)

物理意义上的广告检索逻辑

首先从物理意义上介绍，一个广告是如何从请求到展现的，当一位用户进行搜索时，便提交了一个query(检索词)

这时会看到页面在刷新，一方面在为你找这个query下的自然结果，另一方面在找设置好的广告位应该出现的广告

当用户点击『百度一下』时，前端便向后端发起了请求接入，希望后端可以传输数据来填补空白

后端在接到用户的query时，不会无脑返回广告，而是去找对应这个query下用户最有可能想看到的广告

这也是互联网时代的广告与传统媒体广告的不同，互联网时代的广告可以做到精细化投放，而传统媒体广告只能让所有人都看见

回归后端，他想找到用户最想看到的广告，第一步就要判断用户到底想搜什么，所以要先做需求分析

根据需求分析后的结论，系统大致可以判断用户搜这个query是基于一种什么样的需求，所以可以根据分析结论去找对应的广告，进行广告触发

找到可以传到前端的广告了，那么下一步就要看广告主是否有钱买我们的广告，因此要获取预算

现在我们手上有一百个广告和对应的广告主，他们都买得起我们的广告，但广告位只有三个，我们下一步需要针对这些广告进行排序计费

然后按照排序的最终结果展现给用户，并根据实际展示情况面向广告主收取费用

以上就是从物理意义，或者说实际意义上广告检索的核心逻辑

这个逻辑是如何落地的？

上文中我们提到了整个广告检索的核心逻辑，那么真正落实到平台上、产品上，其构成其实又要复杂很多

阶段一：请求接入

1. 请求asp：前端会携带着数据发送至asp，其信息维度可以分为三类：

第一类是用户信息，例如query，IP等，其中IP又会携带着广告展现日志和点击日志；

第二类是广告信息，包含广告位置，广告数量等内容；第三类是平台信息，即广告的来源是哪里，因为百度接的广告不一定只将其投放到百度上，也有一些合作平台，例如58同城的用户在检索时也会出现广告，这类广告接的是百度的广告，但流量是自己提供的，所以需要分成，因此就需要知道广告的展现来源是哪

此外asp还有灾备于机房切流量的功能，例如北京的机房瘫痪了，可以通过asp切换到新加坡的机房

2. 请求router：router的作用有三个，第一个是评估流量价值(即用户的价值)，第二个是进行实验选择，第三个是流量分发，我们分开来讲：

第一是评估流量价值，可以继续细分为反作弊和流量商业价值评估，反作弊就是根据用户的相关行为日志判断ta是否是一个假用户，避免出现一位广告主恶意消耗另一位广告主的情况发生；

流量商业价值评估则是根据用户以前的情况，判断其转化意愿如何，进而为后续流量分发做准备的阶段

第二是实验选择，因为app经常需要做一些a/b测，来根据实验组和对照组的表现，判断新上的策略或样式是否能带来正收益，那么在这一阶段就会将命中的用户分流，来展现不同的策略或样式，以验证实验结论

第三是流量分发，baidu旗下不仅有搜素，还有各种垂直频道(图片搜索、贴吧搜索、小说搜索等)，那么就需要判断是哪里的用户，然后将流量分流，对应展现不同类型的广告

3. 请求Mixer：mixer又称调度中心，顾名思义，是起到调度作用的平台，主要是两个作用，第一是获取用户的个性化信息，第二是将用户的query变换为高价值的xquery

首先是获取用户个性化信息(又称upin)，这里又可以分为两类，第一种是短期个性化信息(又称uflow)，主要是通过在线分析用户的query进行判断，例如用户上一次的搜索词等

第二种是长期个性化信息(又称ubay)，主要是通过离线挖掘用户的长期兴趣点进行判断

其次是将用户的query变换为高价值的xquery，我认为主要是效率的考量，这里面有个『归一化』的思想，归一化是数学上的概念，即将所有数字变为0~1的区间，进而进行比较，那么这个理论在query上同样适用，即将多个词对应同一个词，这样我们不需要判断每个用户的query，而是将其翻译为同一个xquery，就可以知道用户的意图，大大提高了效率

至此，请求接入的流程结束，进入需求分析流程

阶段二：需求分析

imcs：这个阶段很简单，主要是将我们转换过来的xquery和广告主所买的拍卖词(bidword)进行匹配，来看命中了那些拍卖词

目前baidu提供的匹配模式有四种：精确匹配、短语匹配、智能-核心词匹配、智能匹配

从左到右，是一个匹配策略从非常严谨到宽泛的过程，你可能会想，为什么有广告主愿意买那些宽泛的词，而不是买精确匹配呢？原因有两点：

1. 精确匹配的价格最高，智能匹配的价格最低

2. 广告主所买的bidword没有那么多用户搜索，再加上竞价机制，导致广告无法展现

阶段三：广告触发

1. imbs：主要包含BS和BSq两个部分，BS又分为倒排和正排，先倒排，意思是拿着bidword在广告池里进行广告检索，去找关键词(winfo id)，然后再正排，意思是是拿着winfo id去获取广告的具体信息

那么问题又来了，为什么要分两个步骤？拿着bidword获取广告具体信息它不香嘛？其实整个广告检索里我们经常可以看到，不断地将整个流程拆分的过程，这不仅可以控制每个环节导致风险降低，还可以有效提高效率，因为上一步已经帮我过滤掉了很多无用信息了，我在下一步就不需要再进行计算了

说回imbs，还有一个BSq主要是用于衡量广告的质量，毕竟光命中还不行，最终决定收入的还是用户的点击率，因此广告质量是非常重要的指标

2. adrest：现在广告都有了，该是考虑展现形式的时候了，adrest由两部分组成，一部分是物料(标题、描述等)，另一部分是样式(图片、视频、子链等)

在进行创意选择的时候，分为创意优选和创意轮选，创意优选就是系统根据广告判断哪个样式最能提升转化率，进而选取最佳匹配结果的

但是这就意味着有些创意可能永远都不会用到，也无法知道这种搭配的数据如何，所以由创意轮选给那些没被用过的创意机会，让其展现

阶段四：预算获取

predictor：预算获取的功能主要有两点，一点是存储/获取广告主的预算，另一点是实时更新广告主的预算

值得一提的是，存储的预算分为三个层级，第一个是账号层级，即广告主的每个账号分别有多少预算，第二个是计划层级，即每类定向广告由多少预算，第三个为分桶消费，例如80%的预算为精确匹配，20%的消费为短语匹配，称为分桶

那么说完了功能，我们来讲讲模块

首先思考一个问题：我们对所有广告主都是点击消费，那么假设一个广告主的预算只有10元，我们此时看到他还有余额，因此会大量曝光广告，但是用户点击是有延迟的，也就是说可能会造成『过消费问题』(广告主无法支付实际点击量带来的消费)

所以predictor分为了虚拟预算和真实预算两个模块，平台根据预估ctr首先在广告主的虚拟预算上扣费，其次才会在真实预算中扣费

阶段五：排序计费

Ranker：排序这边很多东西在之前拍卖方式的文章里有提及，不再详述，但主体可以分为质量分预估、gsp二价计费系统 和 psa分位次样式拍卖

质量分预估公式：sort_score = asq/ubmq*bid，asq可以粗略理解为当前广告质量的评估，ubmq是在ctr预估基础上考虑了上下文对广告点击率的影响计算的值，当广告位是第一位时，ubmq可以粗略理解为下一个广告的质量，bid则是出价

也就是说，如果下一位广告质量非常差，ubmq会很小，而当前广告主的质量非常高，asq会很大，最终导致质量分得分非常高

质量分主要是排序用的，质量分得分高意味着广告主可以花更少的钱拿到这个广告位

gsp二价计费系统不再赘述，psa分位次样式则是根据广告位及其样式，来实时变动广告位出价

如何将这繁杂的流程简化？

可以分为CS、BS、AS三个部分：

CSq模型会预估query和拍卖词的相关性，用来过滤掉差的拍卖词，进行是意图识别，根据用户的query找到bidword，首先过滤掉了一批广告词

BSq模型会预估bidword和广告的相关性，进行广告粗选，会根据bidword找winfo id，再去找对应的idea

ASq模型主要是个性化预估(引入用户层级的预估)，最终选取高质量广告时，需要使用asq对广告质量进行评估、排序

因此CS也对应着imcs，BS对应着imbs，AS对应着predictor，这三个环节是一个漏斗，广告在被层层筛选，直到最后的展现

最后引入一个自己的想法

初学广告展现逻辑时，学的是检索、过滤、召回、粗排、精排、混排几个阶段

但其实没有办法和上文一一对应，所以我认为请求接入是完全被忽视掉了，过滤和召回应该是在BS中进行，也符合广告粗选的定义

粗排、精排、混排则应该是ranker的三个不同阶段，不过以上只是我的猜想，没有找到资料辅助证明

相关阅读：

实习笔记 D-1 | 搜索广告平台架构

实习笔记 D-2 | 广告请求到收费的基本逻辑

实习笔记 D-3 | 搜索广告的拍卖机制

实习笔记 D-4 | 搜索广告常见指标及公式