京東廣告研發——效率爲王：廣告統一檢索平臺實踐

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、總結展望

廣告檢索系統通過執行上述三個主線，實現了單位算力的業務收益最大化，有效地支持了京東廣告的業務發展。未來系統技術部的同學還會沿着這三條主線圍繞算力、檢索效率、迭代效率持續提升廣告檢索的架構。我們也歡迎對此感興趣的小夥伴加入我們，共同成長，一齊助力京東廣告業務的發展。