京东广告研发——效率为王：广告统一检索平台实践

1、系统概述

实践证明，将互联网流量变现的在线广告是互联网最成功的商业模式，而电商场景是在线广告的核心场景。京东服务中国数亿的用户和大量的商家，商品池海量。平台在兼顾用户体验、平台、广告主收益的前提推送商品具有挑战性。京东广告检索平台需要在保证服务高效可靠的前提下，为广告与用户需求进行有效匹配，提供个性化、精准的广告推荐和检索服务，为广告主和用户创造更好的交互与价值。

1.1、检索平台功能概述

检索平台将广告主投放诉求转换为播放系统的语言；同时，作为广告系统的最上游，完成人货场的初步匹配。从上亿级的检索空间，返回数百个物料发送至下游，需要考虑用户体感、广告主的投放诉求、召回结果的相关性、平台收入等，承载了大部分的广告业务逻辑。其效果决定了整个广告效果的天花板。

 

 

Fig 1: 京东广告检索系统架构

1.2、问题定义

检索平台核心能力

本文档重点关注检索系统核心功能之“为用户检索出相关的广告”，即召回。其他核心功能另起文档，不再赘述。为了不失一般性，相关性函数可以抽象成一个打分函数

 

，那么召回过程是一个最值搜索问题：对于评分

 

，给定输入

 

，从候选集

 

中寻找固定大小的子集

 

，使得

 

在

 

尽可能排序靠前。以深度学习广泛应用于在线广告为分水岭：

 

•前深度学习时期，召回主要由简单的算法或者规则完成

•后深度学习时期，召回主要是由双塔模型+向量检索完成

基于规则的前深度学习时期的相关性打分是对业务规则的抽象，具备解释性强的优势。但是不同规则的分数通常不具可比性。例如基于标签的规则匹配定向是一种只返回布尔结果的特殊打分方式,其打分函数可以表示为：

 

，此种离散分数很难与其他分支进行对比。后深度学习时期打分由模型完成。多路模型的相关性建模方式类似，价值评估方式统一且分数可比。但受检索系统算力/耗时制约，召回模型通常采用结构简单的双塔模型，限制了模型的表达能力。在硬件发展和算力释放的背景下，打分函数呈现逐渐复杂的趋势。

 

检索平台核心技术难点

检索系统人货场的匹配由多个OP(算子)协同完成

 

 

Fig 2:检索系统内部OP处理的数据量呈现漏斗状，用于平衡海量数据和有限算力之间的矛盾

以过滤OP为例，即从通过召回环节的广告集合中挑选满足业务规则约束的广告，如果将过滤抽象成一个输出为布尔值的打分函数，其表述如下：业务评分

 

，给定输入

 

，寻找固定大小的

 

的子集

 

，使得

 

在

 

尽可能靠前。由于召回和业务评分函数之间的差异，召回的广告可能并不能满足业务要求。指标

 

衡量了两个环节评分函数的差别，也可以粗略衡量召回环节浪费了多少算力用来评估无效的广告。在前深度时期，由于召回环节打分消耗算力有限，其浪费的算力尚不会影响到系统的整体检索效率。在打分模型愈加复杂的后深度学习时期，对候选集内每个候选广告的单点计算量逐渐增加的背景下，召回算力的浪费已经不可忽视。

 

检索平台核心技术难点：在有限的算力和海量数据处理中找到平衡。为了缓解检索阶段海量数据和有限算力之间的矛盾，检索系统进行了以下方面的探索：

1.算力分配：为检索系统计算密集型环节，节省算力与耗时

2.算力优化：提升相关性打分准确性，提升单位算力产生的业务收益

3.迭代效率：配置中心--一站式实验平台，提升迭代效率

文章以下篇幅围绕上述三方面展开，阐述检索系统核心能力建设的过程

 

 

Fig 3:检索平台核心能力。蓝色方块为本文涉及到的环节

2、主线一：Beyond Serverless，数据驱动的自适应算力优化框架

检索系统业务逻辑复杂，计算密集，模块众多。各模块的各自算力优化并不等于系统整体算力优化。为优化检索系统的算力分配，检索系统完成了从单个模块的图化，到联动上下游的分布式执行图的升级。

2.1、全图化到数据驱动的图化，逼近算力优化天花板

分布式执行图是一种基于RPC调用的数据驱动、跨服务图框架，它突破了物理服务之间的上下游依赖，从数据依赖出发，站在整体链路上实现全局算力最优解，将京东广告检索系统的算力自动分配能力推至行业领先水平。

难点：「为什么要立足整体管理子图」1）解决服务间（子图间）的割裂。架构进入Serverless时代后，各个图相互割裂，服务内部的迭代优化很难考虑整体架构的收益；2）代码驱动的执行流程在实际执行时有大量不必要的等待/依赖。

创新：「数据，数据，还是数据」自上而下来看，广告系统的大图为函数

 

，依赖于自己的数据源

 

，为下游产出

 

。自下往上看，每个子图是由多个OP函数组成的，每个OP也是

 

。理清图与图、OP与OP的关键在于理清各层级的数据依赖。从依赖程度来看，分布式执行图将OP之间的数据依赖分为三种：无依赖、局部依赖和全部依赖。无依赖的OP之间执行流充分并行；局部依赖的OP之间引入Batch概念后可支持在Batch间执行流充分并行。

 

「一套架构，多重视角」完整的分布式执行图能实现自动调度，依据业务编排自动进行串/并行的执行；支持数据驱动的DAG表达，充分释放算力，持续保持系统处于算力分配的最佳状态。当前分布式执行图已经落地京东搜索广告，通过充分发掘检索系统及其上下游的数据依赖关系，经过自动编排后的系统对比流程驱动的架构，检索环节节省耗时超过16%，极大释放了检索链路的算力。

 

 

Fig 4: 分布式执行图实现一套架构，多重视角

2.2、弹性系统，智能算力分配助业务平稳增长

京东广告检索平台日常管理超数十万核CPU，站内站外日常处理大量请求。大促期流量还会翻倍，如何保证平台的稳定对京东广告检索系统带来巨大的挑战。

难点：

•平台多样。京东检索平台涉及业务包括搜索广告、推荐广告、首焦广告和站外广告。不同平台在检索流程上存在差异，且访问量也有所不同，每个业务单独建模，人力成本大

•硬件异构。京东广告集群不仅管理着不同的计算硬件（CPU/GPU），且同类硬件也会因为采购批次，品牌型号的不同存在性能差异

应对思路：将算力分配沉淀成基础能力，为广告系统在不同时期，不同场景赋能。

数学建模：经过数年的迭代，京东广告弹性系统的目标从维持系统稳定度过流量高峰期转至通过算力分配以提升收益。弹性系统的建模目标也随之发生改变。

阶段一、维持系统稳定的PID弹性系统：

 

 

，以系统当前CPU和目标CPU之间的差值建模系统误差，用PID控制弹性降级使得服务器CPU利用率达到预设水平。相比于常见的控制QPS以间接调控CPU的建模方式，CPU更加直接。性能不同的机器在同一QPS下的CPU利用率也不同，CPU目标建模考虑了京东检索服务异构硬件的特点，更具适用性。

 

阶段二、合理利用系统日常闲置算力，为系统带来收益：

京东APP的流量分布呈现早晚两高峰结构，非高峰时期闲置大量冗余算力。阶段二的目标为满足系统约束下的流量价值最大化。调控手段为扩大/缩小召回系统各个环节的队列长度。新的系统反馈定义如下：

 

 

 

系统目标为在一定时间粒度下最大化单位算力的期望收益。该建模有如下挑战：

•流量的价值难以定义。使用策略的后验Uplift收益作为价值的Groudtruth来训练价值评估函数。广告检索系统使用点击和消费作为收益指标。

•糟糕的策略会对线上系统带来无可挽回的损失。系统使用离线数据预训练弹性系统。在实际运行中，弹性策略会在系统指定的安全边界内生效。同时，完备的熔断机制也保证了弹性策略失效后会由更稳定的保守策略接管系统。

•目前基于收益优化的弹性系统已经运用在日常情形下。现阶段弹性系统的价值评估函数还比较简单，且该弹性系统还无法应用于大促阶段。下一阶段的目标为精细化价值评估以及将收益最大化的弹性系统应用于大促。

 

 

Fig 5: 京东广告弹性系统迭代road map

3、主线二：与时间赛跑，高效检索引擎打开广告效果天花板

在有限的时间内最大化算力的价值是检索团队追逐的目标。在硬件资源有限的背景下，一百ms耗时内遍历亿级商品池并用模型打分难以实现。京东检索团队参考了大量业界优秀的公开设计文档，结合京东广告的实际情况，规划了高效算法检索引擎的迭代路线。整体规划可以分为4个阶段：

第一阶段：算法检索引擎矩阵初具雏形

初期复用互联网通用的双塔范式，快速赋能广告业务。后续迭代过程中不断沉淀诸如PQ索引压缩，基于业务的层次化检索，全库检索等技术，与行业先进检索系统接轨并有效支撑了京东广告业务的发展。

第二阶段：效率为王，极致提升数据时效性

检索系统感知物料的时效性，对引擎的检索效果具有显著影响。提升算法检索引擎感知物料的速度，将对亿级物料的感知延迟压缩至分钟级，达到业内领先水准。

第三阶段：链路目标对齐，任意目标建模的召回

广告检索系统的目标是为用户挑选出相关广告，通常以单一目标如CTR指标来建模。而广告系统通常以广告的eCPM评估广告，即bid x CTR。检索目标与系统目标的不一致会为广告系统的效果带来损失。广告检索团队从业务出发，推出支持最大化任意目标的ANN检索范式。

第四阶段：标量向量混检，检索目标再对齐

在检索+过滤的旧架构模式下，检索出来的部分广告单元因为不满足业务规则约束而被过滤，浪费了算力。基于模型结构向更深度演化的背景下，这种架构带来的算力浪费被放大。检索团队从节省算力角度出发，建设标量向量混合检索能力，用过滤前置的思想完成检索与后链路过滤的目标对齐，提升单位算力的收益。

3.1、双塔到深度，从行业追赶到第一梯队

京东检索广告从无到有打造出算法检索引擎产品矩阵，完成了从简单的树索引到结合业务的层级化索引，再到深度索引的演变，支撑了平台对亿级广告的高效检索。

「ANN是什么？」为了在规定的耗时约束内完成对亿级候选集的检索，系统通常会使用近似近邻检索（ANN）来避免穷举候选集里所有的广告。常用的树状索引按照向量间的欧式距离将距离近的向量放在索引上相邻的位置。此索引上叶子结点为广告对应的节点，中间节点为聚类产生的没有物理含义的节点。结合宽度为K的Beam Search，则每层索引上需要打分的节点个数小于等于

 

个，缩小了计算量。

 

 

 

Fig 6: 以一个2叉为例演示了k=1的beam search过程：给节点P2,1和P2,2打分后选取分数更高的P2,1。依次类推最后召回SKU1

「创新，基于业务的层次索引」京东广告的特定场景下，用户表现出明显的意图能够有效帮助检索系统缩小候选集。利用这一业务知识，京东广告推出基于业务理解的多级向量索引。以搜索为例，用户Query包含用户明确的意图。如果将广告按用户意图离线分区，在线检索时仅检索指定分区。不仅能有效减少检索计算量，还能减少因为模型泛化引入的Bad Case。分区内使用树状索引可以进一步减少检索的耗时和计算开销。

 

 

Fig 7:结合业务的层级召回首先根据业务将索引分区。召回阶段只需要检索指定分区下的索引

「全库索引」京东检索系统管理分支众多，覆盖广告达上亿，每个广告均用多维浮点向量表示，占据检索系统可观的内存。在检索引擎迭代中，树状索引逐渐被扁平的Product Quantization（PQ）索引取代。PQ将高维度浮点数向量转化为低维度整型向量，实测内存压缩率高达85%以上，大幅提升了检索系统表达容量。得益于PQ节省的算力，扁平索引使用暴力计算代替树状索引Beam Search的检索方式，实现全库检索。

「深度索引」双塔模型因其产生的向量满足近邻检索性质的特点在召回阶段受到广泛的应用。但模型表征能力，即打分能力也受到如下影响：

•双塔独立导致用户侧与Item侧特征融合不充分

•上层Matching函数为向量点积，限制了模型的表达能力

结合以上不足，京东广告检索推出基于EM的深度索引。新索引突破了传统索引对双塔模型的结构限制。算法不仅可以纵向迭代：表征函数更复杂；还可以横向迭代：matching函数更复杂，且用户和广告可以任意阶段融合。

 

 

Fig 8:深度索引支持召回算法新的迭代模式

值得注意的是，因为召回模型不再遵守双塔模型的范式，即模型不再假设将用户与广告映射到同一个向量空间内，模型产生的向量不再具备近似近邻检索的性质。

广告检索的本质是在索引上找到通向高价值广告的路径。双塔模型的树索引，作为一种特殊的深度索引，从根节点到叶子节点的路径由向量叉乘确定，无需模型参与。而深度索引的路径根据模型打分确认，目标为最大化路径指向广告的价值。

 

 

Fig 9:向量索引构建和召回过程抽象

3.2、召回架构升级，极致追求数据时效

「为什么追求时效」京东广告检索作为广告链路的最上游，其数据的时效性极大影响了全链路的营销效果。

难点：京东广告服务大量广告主，覆盖亿级广告，每分钟都有广告因为广告主的操作等因素而发生状态改变的情况。对于分秒必争的流量高峰期，广告主操作的生效时间将直接影响广告主的营销效果。物料变化带来的索引更新本身对算力就有较大的消耗，如果叠加平台日常检索的资源消耗，对于平台能力提出了更高的要求，特别是在京东这种亿级广告量级的情况，更是一个巨大的挑战。

「行业领先，广告分钟级生效」京东广告检索系统支持分钟级别的广告信息更新并体现在算法索引上。索引构建采用全量+增量的思想，全量期间仅为有效广告快速构建索引，全量后广告信息的变更反映在增量上。索引的数据上游-流水系统将数据湖思想集成至索引构建中，减少全量索引构建耗时，缩短索引生效延迟。同时以出色的拓展性，为检索系统高效构建和管理多种形式的索引，如向量索引，KV索引等。

3.3、链路对齐，检索效率再提升

「为什么要链路对齐」自上而下看，目标的链路对齐有两个层次：

•从广告系统来看，检索负责筛选与用户相关的广告，后链路环节如粗排/精排的目标是最大化候选广告的eCPM等目标。广告系统各模块间的目标不齐限制了广告系统的整体收益

•检索系统内部多个OP目标不一致，导致检索结果陷入局部影响整个广告系统的优化迭代

「任意目标召回」一个模型，多种用法。只需对向量进行少量修饰即可完成检索目标的「无痛转化」。

难点：改变检索的目标，需要改变模型的训练方式，成本极大。

创新：以CTR建模的模型为例，双塔模型预估的pCTR计算方式为：

 

，

 

代表用户向量，

 

代表广告向量。只需将在原向量加上一维数据，即可将检索目标从最大化CTR转化为最大化eCPM：

 

用户向量修饰：

 

 

Item向量修饰：

 

,经过数学推导修饰后的向量内积能够逼近eCPM，

 

 

经过修饰后的用户向量与广告向量的点积与eCPM正相关。此时，ANN检索出来的广告即为按照eCPM最大化选出的top-k，完成检索系统与广告整体目标的对齐。

「向量标量混检」建设业务表达能力行业一流的检索引擎

难点：向量检索引擎在检索阶段很难表达业务过滤的诉求。为满足广告主要求，检索系统常采取向量引擎+标量过滤的架构。

创新：京东广告将向量索引结构抽象为：兴趣层与业务层。业务层通常为广告，具备物理意义。兴趣层是路径的中间产物，不具备物理意义。以双塔索引为例，叶子节点表示广告，广告的状态（上/下架）应直接影响该叶子节点能否被检索。中间节点代表广告聚类抽象出的隐式兴趣，不受业务层广告状态的影响。

 

 

Fig 10:索引结构的抽象及检索过程的抽象

为了减少算力浪费在无效节点上，叶子结点上引入标量，在召回阶段避免计算无效的叶子结点，并保证检索队列有效结果数充足。标量向量混合检索不仅提升单位算力的收益，也促进了检索召回OP与其他后链路OP的目标融合，提升检索系统的整体检索效率。

4、主线三：平台力量：平台化基建释放研发生产力

4.1、磨刀不误砍柴工：从京东广告业务迭代面临的挑战说起

「京东广告业务迭代密集」广告检索平台是一个业务复杂，计算、IO密集，为京东APP、京东小程序、京东PC等客户端提供在线广告检索的服务。平台的重要定位也决定了其迭代的密集程度：检索代码库平均每年有600+次合并，检索平均每年全量代码或配置发布次数已超500次，可见一斑。

「研发容量及效率的挑战」支撑检索系统的快速稳定迭代，需要有足够大的研发容量支撑。每个垂直业务线（搜索/推荐/首焦/站外）都包含业务架构及算法策略研发。同时在跨业务线的水平模块（召回/创意/出价）也包含对应的平台业务架构及算法策略研发、以及系统研发、测试等。平台支撑如上近300人的多元研发团队同时开发，为了保证持续业务健康发展，需具备数百至千级的实验吞吐量，提供准确易用的洞察分析工具。

「大促场景的紧急迭代挑战」京东面临一年两次以上的（618、双十一等）大促考验，大促时特有0逻辑需要得到快速落地。紧急迭代对系统代码的健壮性、可读性都带来不小挑战。

4.2、万象适配：平台化支撑多元业务拓展定制

「业务系统分层」把在线系统分为系统架构层、业务框架层及业务算法策略定制层，三层迭代相互独立。这样让业务研发专注于业务逻辑编排及策略本身，而系统研发专注于基础架构的优化。

 

 

Fig 11: 京东广告业务系统分层框架

「业务框架的算子化设计」系统健康运行的基石是健壮的系统框架。将复杂的业务系统按功能拆分为多个算子（简称OP），不仅系统边界清晰，还可将业务策略进行归类和抽象。算子作为OP的原子单位，有明确的输入输出数据和清晰的业务定位。原子化算子遵循：

1、清晰的数据依赖：每个OP具备各自的INPUT和OUTPUT，同时INPUT具有只读属性

2、OP的可洞察性建模：OP中记录运行时DEBUG/TRACE数据，方便调试、监控与分析

3、OP的可配置性建模：配置的控制范围仅限于OP内，可控制一个独立的功能或功能参数

「可插拔的策略定制」每个业务算子提供扩展点供业务策略定制，具有可灵活插拔的特性。这样的设计思想是采取类的组合关系+功能分治的思想，将单一的功能点从OP中抽离出来，通过单独的扩展点类来管理，功能上更内聚。

 

 

Fig 12: 京东智能出价OP的扩展点示例

4.3、超越极限：一站式配置管理及超大容量的极速实验发布平台

「全新视角配置建模」跳出通用的KV建模，京东提出基于全新视角业务配置三要素建模：配置项（Key），配置条件（Condition），配置值（Value）。较KV配置组件，京东的新配置组件更加灵活，定制化能力更强大：以推荐出价OP为例，使用时只需要配置该Key作用于出价OP，配置Condition为推荐业务，配置Value为1。在全新视角配置下，配置Key从属于一个算子OP，配置Condition可做流量业务身份的定制扩展，可以随着业务不断发展迭代。配置方式具有业务语义，便于理解。

「任意配置均可一键实验」上述所有配置更改皆可一键AB分层实验，为在线系统提供超大实验容量。在线广告的配置系统联动分层实验平台，每个算子具备20+个分层实验同时运行的能力。京东广告日常的实验容量在400以上，理论上分层实验可以容纳无限的实验容量，足够满足超300人的产研团队的日常迭代需求。配置修改可叠加一键发起实验，极大简化了研发人员的配置开发测试负担，使得实验切换方式更加灵活可控。

「一站式配置管理及发布」通常业务逻辑迭代需要充分了解当前的配置状态，将全部配置在统一管理界面中呈现，一方面提高了统一配置管理的便捷程度，同时让配置具有更优的可阅读性，让不具备开发能力的同事可以随时了解广告检索系统的业务处理流程，并进行一键实验操作。同时一站式的配置修改，贯穿于自测、联调测试、小流量、全量、holdback研发周期的全程跟踪和托管，免除了在多个平台切换的烦恼。

 

 

Fig 13: 一站式配置管理与发布界面

4.4、洞察专家：可追踪可归因的在线洞察系统

「可调试可追踪」广告在线检索系统的强需求就是可追踪。面向研发，在线洞察系统提供DEBUG模式：

•调试模式可选择：可以选择跟踪特定广告或者是特定环节

•实时性：立即产出DEBUG数据

•全面性：全面记录各个模块各个业务算中间数据，全面透彻

面向运营和广告主提供TRACE模式：

•线上请求可追踪：任意线上请求的结果数据均可全系统链路追踪

•请求可重发：实时请求重发复现现场，加速问题定位

•算法可再洞察：对于TRACE日志落盘数据提供了算法可嵌入再洞察分析的模块，算法可以在系统中自定义常用的业务统计分析归因脚本，提高分析效率。比如搜索广告的低价诊断经常分析某个SKU在同一请求候选队列中的价格分位数，类目多样性

「在线系统归因洞察诊断」除了DEBUG/TRACE模式外，也提供了漏斗洞察模式。系统全链路的漏斗统计分析助力问题分析，验证策略发挥着极其重要的作用。在线洞察提供了自定义流量筛选下的漏斗洞察可视化工具，为广告诸多业务带来不可估量收益。

5、总结展望

广告检索系统通过执行上述三个主线，实现了单位算力的业务收益最大化，有效地支持了京东广告的业务发展。未来系统技术部的同学还会沿着这三条主线围绕算力、检索效率、迭代效率持续提升广告检索的架构。我们也欢迎对此感兴趣的小伙伴加入我们，共同成长，一齐助力京东广告业务的发展。