京东广告研发——效率为王:广告统一检索平台实践
1、系统概述
实践证明,将互联网流量变现的在线广告是互联网最成功的商业模式,而电商场景是在线广告的核心场景。京东服务中国数亿的用户和大量的商家,商品池海量。平台在兼顾用户体验、平台、广告主收益的前提推送商品具有挑战性。京东广告检索平台需要在保证服务高效可靠的前提下,为广告与用户需求进行有效匹配,提供个性化、精准的广告推荐和检索服务,为广告主和用户创造更好的交互与价值。
1.1、检索平台功能概述
检索平台将广告主投放诉求转换为播放系统的语言;同时,作为广告系统的最上游,完成人货场的初步匹配。从上亿级的检索空间,返回数百个物料发送至下游,需要考虑用户体感、广告主的投放诉求、召回结果的相关性、平台收入等,承载了大部分的广告业务逻辑。其效果决定了整个广告效果的天花板。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-03-16-15-07miDLuQquETt16SJ.png)
Fig 1: 京东广告检索系统架构
1.2、问题定义
检索平台核心能力
本文档重点关注检索系统核心功能之“为用户检索出相关的广告”,即召回。其他核心功能另起文档,不再赘述。为了不失一般性,相关性函数可以抽象成一个打分函数
基于规则的前深度学习时期的相关性打分是对业务规则的抽象,具备解释性强的优势。但是不同规则的分数通常不具可比性。例如基于标签的规则匹配定向是一种只返回布尔结果的特殊打分方式,其打分函数可以表示为:
检索平台核心技术难点
检索系统人货场的匹配由多个OP(算子)协同完成
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-03-16-15-58e58ag0AdrHjxmLyW.png)
Fig 2:检索系统内部OP处理的数据量呈现漏斗状,用于平衡海量数据和有限算力之间的矛盾
以过滤OP为例,即从通过召回环节的广告集合中挑选满足业务规则约束的广告,如果将过滤抽象成一个输出为布尔值的打分函数,其表述如下:业务评分
检索平台核心技术难点:在有限的算力和海量数据处理中找到平衡。为了缓解检索阶段海量数据和有限算力之间的矛盾,检索系统进行了以下方面的探索:
文章以下篇幅围绕上述三方面展开,阐述检索系统核心能力建设的过程
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-03-16-15-08jcHgqek16PV6YCMx.png)
Fig 3:检索平台核心能力。蓝色方块为本文涉及到的环节
2、主线一:Beyond Serverless,数据驱动的自适应算力优化框架
检索系统业务逻辑复杂,计算密集,模块众多。各模块的各自算力优化并不等于系统整体算力优化。为优化检索系统的算力分配,检索系统完成了从单个模块的图化,到联动上下游的分布式执行图的升级。
2.1、全图化到数据驱动的图化,逼近算力优化天花板
分布式执行图是一种基于RPC调用的数据驱动、跨服务图框架,它突破了物理服务之间的上下游依赖,从数据依赖出发,站在整体链路上实现全局算力最优解,将京东广告检索系统的算力自动分配能力推至行业领先水平。
难点:「为什么要立足整体管理子图」1)解决服务间(子图间)的割裂。架构进入Serverless时代后,各个图相互割裂,服务内部的迭代优化很难考虑整体架构的收益;2)代码驱动的执行流程在实际执行时有大量不必要的等待/依赖。
创新:「数据,数据,还是数据」自上而下来看,广告系统的大图为函数
「一套架构,多重视角」完整的分布式执行图能实现自动调度,依据业务编排自动进行串/并行的执行;支持数据驱动的DAG表达,充分释放算力,持续保持系统处于算力分配的最佳状态。当前分布式执行图已经落地京东搜索广告,通过充分发掘检索系统及其上下游的数据依赖关系,经过自动编排后的系统对比流程驱动的架构,检索环节节省耗时超过16%,极大释放了检索链路的算力。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-03-16-15-09Dkq9faxSJPxEqTV.png)
Fig 4: 分布式执行图实现一套架构,多重视角
2.2、弹性系统,智能算力分配助业务平稳增长
京东广告检索平台日常管理超数十万核CPU,站内站外日常处理大量请求。大促期流量还会翻倍,如何保证平台的稳定对京东广告检索系统带来巨大的挑战。
难点:
应对思路:将算力分配沉淀成基础能力,为广告系统在不同时期,不同场景赋能。
数学建模:经过数年的迭代,京东广告弹性系统的目标从维持系统稳定度过流量高峰期转至通过算力分配以提升收益。弹性系统的建模目标也随之发生改变。
阶段一、维持系统稳定的PID弹性系统:
阶段二、合理利用系统日常闲置算力,为系统带来收益:
京东APP的流量分布呈现早晚两高峰结构,非高峰时期闲置大量冗余算力。阶段二的目标为满足系统约束下的流量价值最大化。调控手段为扩大/缩小召回系统各个环节的队列长度。新的系统反馈定义如下:
系统目标为在一定时间粒度下最大化单位算力的期望收益。该建模有如下挑战:
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-03-16-16-25BkPedk0NRtzEvip.png)
Fig 5: 京东广告弹性系统迭代road map
3、主线二:与时间赛跑,高效检索引擎打开广告效果天花板
在有限的时间内最大化算力的价值是检索团队追逐的目标。在硬件资源有限的背景下,一百ms耗时内遍历亿级商品池并用模型打分难以实现。京东检索团队参考了大量业界优秀的公开设计文档,结合京东广告的实际情况,规划了高效算法检索引擎的迭代路线。整体规划可以分为4个阶段:
第一阶段:算法检索引擎矩阵初具雏形
初期复用互联网通用的双塔范式,快速赋能广告业务。后续迭代过程中不断沉淀诸如PQ索引压缩,基于业务的层次化检索,全库检索等技术,与行业先进检索系统接轨并有效支撑了京东广告业务的发展。
第二阶段:效率为王,极致提升数据时效性
检索系统感知物料的时效性,对引擎的检索效果具有显著影响。提升算法检索引擎感知物料的速度,将对亿级物料的感知延迟压缩至分钟级,达到业内领先水准。
第三阶段:链路目标对齐,任意目标建模的召回
广告检索系统的目标是为用户挑选出相关广告,通常以单一目标如CTR指标来建模。而广告系统通常以广告的eCPM评估广告,即bid x CTR。检索目标与系统目标的不一致会为广告系统的效果带来损失。广告检索团队从业务出发,推出支持最大化任意目标的ANN检索范式。
第四阶段:标量向量混检,检索目标再对齐
在检索+过滤的旧架构模式下,检索出来的部分广告单元因为不满足业务规则约束而被过滤,浪费了算力。基于模型结构向更深度演化的背景下,这种架构带来的算力浪费被放大。检索团队从节省算力角度出发,建设标量向量混合检索能力,用过滤前置的思想完成检索与后链路过滤的目标对齐,提升单位算力的收益。
3.1、双塔到深度,从行业追赶到第一梯队
京东检索广告从无到有打造出算法检索引擎产品矩阵,完成了从简单的树索引到结合业务的层级化索引,再到深度索引的演变,支撑了平台对亿级广告的高效检索。
「ANN是什么?」为了在规定的耗时约束内完成对亿级候选集的检索,系统通常会使用近似近邻检索(ANN)来避免穷举候选集里所有的广告。常用的树状索引按照向量间的欧式距离将距离近的向量放在索引上相邻的位置。此索引上叶子结点为广告对应的节点,中间节点为聚类产生的没有物理含义的节点。结合宽度为K的Beam Search,则每层索引上需要打分的节点个数小于等于
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-03-16-16-14hOk10JE9GVNdyLYh.png)
Fig 6: 以一个2叉为例演示了k=1的beam search过程:给节点P2,1和P2,2打分后选取分数更高的P2,1。依次类推最后召回SKU1
「创新,基于业务的层次索引」京东广告的特定场景下,用户表现出明显的意图能够有效帮助检索系统缩小候选集。利用这一业务知识,京东广告推出基于业务理解的多级向量索引。以搜索为例,用户Query包含用户明确的意图。如果将广告按用户意图离线分区,在线检索时仅检索指定分区。不仅能有效减少检索计算量,还能减少因为模型泛化引入的Bad Case。分区内使用树状索引可以进一步减少检索的耗时和计算开销。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-03-16-16-04S6KBjA16mpbfyzk51.png)
Fig 7:结合业务的层级召回首先根据业务将索引分区。召回阶段只需要检索指定分区下的索引
「全库索引」京东检索系统管理分支众多,覆盖广告达上亿,每个广告均用多维浮点向量表示,占据检索系统可观的内存。在检索引擎迭代中,树状索引逐渐被扁平的Product Quantization(PQ)索引取代。PQ将高维度浮点数向量转化为低维度整型向量,实测内存压缩率高达85%以上,大幅提升了检索系统表达容量。得益于PQ节省的算力,扁平索引使用暴力计算代替树状索引Beam Search的检索方式,实现全库检索。
「深度索引」双塔模型因其产生的向量满足近邻检索性质的特点在召回阶段受到广泛的应用。但模型表征能力,即打分能力也受到如下影响:
结合以上不足,京东广告检索推出基于EM的深度索引。新索引突破了传统索引对双塔模型的结构限制。算法不仅可以纵向迭代:表征函数更复杂;还可以横向迭代:matching函数更复杂,且用户和广告可以任意阶段融合。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-03-16-16-01LSPLtfBFWdCOrPV.png)
Fig 8:深度索引支持召回算法新的迭代模式
值得注意的是,因为召回模型不再遵守双塔模型的范式,即模型不再假设将用户与广告映射到同一个向量空间内,模型产生的向量不再具备近似近邻检索的性质。
广告检索的本质是在索引上找到通向高价值广告的路径。双塔模型的树索引,作为一种特殊的深度索引,从根节点到叶子节点的路径由向量叉乘确定,无需模型参与。而深度索引的路径根据模型打分确认,目标为最大化路径指向广告的价值。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-03-16-16-28j7XDLZDuoOa0JUa.png)