京東推薦系統的數據體系極其復雜，從召回、模型到策略和效果評估，每個環節都需要強大的海量數據處理能力支撐。然而，在實際運行中，整個數據鏈路面臨著諸多挑戰：如實時與離線數據的埋點口徑不一致、數倉模型存在偏差、計算口徑不統一等問題，都會直接影響推薦效果的優化。更棘手的是，由于數據來源多樣、體量龐大，整個推薦系統的數據質量控制和校驗機制往往難以得到有效保障。

京東零售技術專家張穎參與Flink Forward Asia 2024 峰會帶來分享《京東零售基于 Flink 的推薦系統智能數據體系》，介紹了基于Flink構建的推薦系統數據，以及Flink智能體系帶來的智能服務功能。

以下是分享實錄：

01

推薦系統架構

推薦系統通常包含推薦服務，這一服務提供了推薦系統的出口，基于此接口，能夠實現多種推薦場景，如個性化推薦、熱門推薦、新品推薦以及多樣化推薦等。此外，我們關注的推薦系統的關鍵模塊主要劃分三個：召回模塊、模型（粗排、精排、重排等）及策略。在召回及策略模塊中，召回服務的作用是將推薦系統底池數據規模從億或者百億級別降低至千萬級。

以電商場景為例，常見的召回方式包括行為召回、搜索詞熱門召回以及 I2I 召回等上百路召回。模型主要涉及粗排、精排與重排這三個環節。當然，某些特定功能既可以歸類到模型服務，也可劃分至策略模塊。至于策略模塊，其中會涵蓋混排相關內容，比如搜推混排、推薦與廣告混排、搜索與廣告混排等。混排過程中可能還涉及 CVR（轉化率）、CTR（點擊率）等多目標排序，以及流量扶持等策略。

接下來，我們看看推薦系統的智能數據體系構成，該體系的數據底層大致由五部分組成，分別是索引、特征、樣本、可解釋性內容以及指標，后續將詳細闡述每個模塊的具體功能。這些數據主要服務于推薦系統的召回、模型、策略等鏈路，進而支持相關場景，如常見的搜索、推薦、廣告推廣以及用戶增長場景。

02

索引

2.1 什么是索引？

接下來詳細介紹京東搜索推薦系統智能數據體系的構成，第一個模塊為索引，主要為召回服務提供數據支持。常見的索引構建流程是，從底池數據出發，經過索引構建操作，將構建完成的索引提供給召回服務。 索引常見類型可劃分為三類：

(1) 個性化索引：這類索引可能涉及特定用戶或某類用戶的行為足跡或者是基于品類、品牌偏好形成的索引。

(2) 基礎索引：以京東海量商品為例，可將其歸納為基于品類、品牌的索引，同時還包括時間、LBS相關的索引。

(3) 策略索引：此類型索引可能涉及流量扶持相關策略，如冷啟動索引、低曝光商品索引等，此外還包括兜底索引。

接下來介紹一下什么是索引數據，索引數據主要分為正排數據與倒排數據，正排數據，本質上是將商品的各項屬性依次排列，這也是大家通常所指的正排形式；倒排數據，則是依據屬性信息，把相應的商品作列表作為值進行存儲。

2.2 索引架構

下面我們來分析常見的索引架構：索引主要由實時索引、增量索引和全量索引三部分構成，這三部分在保障索引穩定性方面相互補充。例如，若增量索引出現故障，實時索引和全量索引可繼續維持；若實時索引失效，增量索引能夠發揮作用；索引更新頻率并非固定為小時級，也可以是15分鐘級等其他時間粒度。

在索引構建過程中，一般從實時鏈路著手，首先從上游 Kafka 消息隊列獲取相應數據，對數據進行解析與去重處理；之后，可能還需補充屬性信息，如 SKU 對應的商品品牌及標簽屬性，處理后的數據寫入Kafka，供下游索引服務讀取并構建實時鏈路索引；增量索引通常按小時或者分鐘級更新，實時索引數據會實時寫入 OLAP ，在 OLAP 中補齊實時屬性，比如計算商品前一小時或前五分鐘的點擊量等，完成正排計算后，基于正排結果進行倒排計算，進而進行構建索引，并將數據存儲到索引服務中；天級增量索引的流程與小時分鐘級類似，只是涉及的數據范圍可能更廣。全量索引的更新周期一般為天級、周級或月級等。

03

樣本

3.1 樣本開發架構

接下來，我們探討樣本的整體開發架構，其主要分為流式與批式兩種方式。

在流式樣本開發方面，主要操作是將曝光、點擊等用戶行為數據中的關鍵信息與特征數據進行關聯（ Join ），關聯后的數據向后發送，從而形成流式樣本。這些流式樣本會按小時級或分鐘級進行落盤存儲，如此便生成了增量樣本，增量樣本可用于模型的增量訓練。

而批式樣本的生成，是將用戶行為表與特征表進行拼接，拼接后即形成批式樣本。由于批式樣本通常涵蓋較長時間跨度的數據，因此這類樣本又被稱為離線樣本。在訓練模型（例如精排模型）時，僅使用幾天或一周的數據往往是不夠的，通常需要一個月、兩個月甚至幾年的數據。

在進行流式或增量訓練時，會基于這個離線樣本訓練出初始模型（Model），然后再依據增量數據做進一步擬合（Fit）。在實時訓練過程中，則會基于增量模型，繼續對實時樣本進行擬合。

3.2 樣本特定場景

我們來分析在樣本構建過程中所涉及的各類場景，對于離線樣本，通常會面臨樣本冷啟動以及樣本特征回溯的問題；而針對實時樣本，可能遭遇的問題包括延時反饋以及樣本采樣方法的選擇。

3.3 離線樣本架構

這里我們主要介紹下離線樣本拼接，接下來我們看樣本的離線架構，它與前文提及的架構大致相似，主要操作是將用戶行為的離線label表與離線特征表進行批式拼接，進而生成天級樣本表，隨著日復一日的積累，這些天級樣本表會形成月級樣本，以此便可開展全量訓練。然而，在此過程中會出現一些問題。例如，在全新的業務場景下，可能初始并無可用樣本，此時就需要將諸如訂單、點擊等標簽（ Label ）的計算工作全部重新計算；此外，完成這部分操作后，還可能涉及生成特征（Feature ）寬表，這同樣是基于全量數據且以月級為周期的特征處理，在進行這些數據計算和關聯（ Join ）操作時，對算力的要求極高。

關于特征回溯，其操作與上述過程類似，即把 FN + 1 的新表與已有樣本進行關聯（ Join ）。但此過程涉及特征計算，需要完整計算新表近一個月或幾個月的特征數據，并且還需與之前的樣本表進行行對齊。需要補充說明的是，在進行樣本表關聯（ Join ）時，必須借助唯一標識組件 ID，如 Request ID 來實現對齊，如此關聯后的樣本表才能作為特征回溯的樣本表。

3.4 實時樣本架構-分階段窗口

接下來分析實時樣本架構，它基于分階段的窗口機制實現。首先，從 Kafka 接收用戶行為的關鍵數據，經數據解析后，與同樣經過解析（如 PB 解析）的特征數據進行拼接，在曝光與特征拼接環節，盡管這一過程實際速度很快，但為確保拼接的成功率，我們設置了五分鐘的時間窗口，也就是說，只有當特征成功拼接到曝光數據后，數據才會繼續向后傳遞，此時間窗口為五分鐘；隨后是曝光與點擊的拼接環節，該環節時間窗口可設置為十分鐘，即曝光發生后，若十分鐘內未產生點擊行為，相應數據將被視為負樣本。再之后是曝光點擊樣本與加購和下單行為的拼接，此環節時間窗口設定為二十分鐘。需注意的是，五分鐘、十分鐘和二十分鐘這些時間窗口并非固定不變，而是可根據具體業務場景靈活配置。例如，在結算頁場景中，用戶決策時間相對較短；而在搜索或推薦場景下，用戶考慮時間可能較長。

此外，時間窗口還可依據品類和品牌進行針對性配置。以電商場景為例，購買食品時，用戶可能十分鐘內就會下單，整個鏈路的時間窗口或許設置為十分鐘至二十分鐘即可，但購買家電時，用戶考慮時間較長，一天可能都不夠。當然，針對這種情況，雖可通過離線方式進行數據回補，但我們當前聚焦實時處理，期望通過分階段窗口機制，盡可能快速地為模型提供樣本。

再來看延時反饋問題。延時反饋本質上是為模型提供三個標簽，即正標簽、負標簽以及一個修正標簽。當數據到來時，先賦予其負標簽，隨后進入等待流程，通過判斷時間，若發現時間已過特定期限，確定該數據實際應為正標簽，但之前發送時可能誤判為負標簽，此時對這部分數據進行修正，即修正標簽，并將其發送至實時樣本流中。另外，在離線訓練時，我們能夠隨意對樣本數據進行 Shuffle 操作，這樣可有效避免因數據不均衡給模型帶來的問題。然而，實時場景下由于數據是流式傳輸，無法進行 Shuffle。因此，我們采用了一種配置策略，即將離線處理得到的部分數據與實時數據按一定Mix策略進行混合，然后發送至實時樣本中。

3.5 實時樣本架構-OnlineEvaluation

下面我們來看實時樣本的 Online Evaluation 模塊，該模塊主要應用于模型評估場景。實時樣本的情況與上頁 PPT 結尾部分大致相似，但在此過程中會涉及采樣策略。在上頁 PPT 結尾，我們提到將數據全部發送至Kafka，而實際操作中，我們會對數據進行95%和5%的采樣。其中，95%的數據用于模型訓練，5%的數據用于評估（Evaluation）。 在評估環節，又細分為實時評估與離線評估。之所以如此劃分，是因為離線評估雖然不夠實時，但實時評估在一定程度上無法起到全面指導的作用（實時評估有三種標簽）。為綜合兩者優勢，我們將評估工作分為離線和實時兩部分，在進行離線評估時，只有當模型的 AUC 達到預先配置的數值，才會將模型推向線上應用；若未達到該數值，模型將立即重新進行訓練。而在實時評估過程中，我們會持續監控模型數據，一旦模型準確率下降，系統便會馬上發出警報，同時考慮是否需要對模型進行回滾操作。

接下來，我們探討特征相關內容，著重分析整個特征開發過程中的難點。在推薦系統里，特征需求極為繁雜，這是因為特征開發與模型實驗緊密相連、相輔相成，且特征開發的邏輯極為復雜。以京東電商場景為例，存在用戶維度、Item 維度、Session 維度等不同維度的特征，同時還包含統計類、序列類等一系列豐富多樣的特征類型。此外，特征回溯困難，正如前文所提及的，若要回溯前一個月的特征數據，不僅計算量巨大，而且所需耗費的時間周期也很長。

04

特征

4.1 實時特征開發架構（觸發流架構）

下面我們來看實時特征開發的架構，在我們內部，它被稱作觸發流架構。該架構將數據整體劃分為三層：

第一層是行為接入層，此層主要涵蓋各類用戶行為的關鍵數據，例如用戶在京東 APP 上的曝光、點擊、瀏覽等行為數據，這些數據是整個實時特征開發的基礎輸入，記錄了用戶與平臺交互的原始行為信息；

第二層是行為補全層。在這一層，我們會對前期的數據進行整合與補充。以點擊行為為例，我們會將近三天的點擊數據匯總；對于訂單行為，則會整合近三年的數據，從而形成一條完整的行為記錄，基于這些整合后的數據，我們可以計算出諸如點擊商品列表、加購商品列表等用戶行為數據。從商品角度看，我們也能獲取商品的相關行為信息，比如商品被曝光的次數、被哪些用戶曝光等信息可作為衡量商品是否優質的依據，例如，如果商品的曝光點擊率較高，通常可認為它是優質商品；但倘若其曝光點擊率高，然而下單率卻很低，這時就需要深入分析出現這種現象的原因。

第三層是特征挖掘層。這一層基于上面的用戶行為層來計算具體的用戶/商品特征，其中包括統計類特征，比如通過獲取用戶行為list，計算近五分鐘或近十分鐘的點擊量，通過依據時間維度進行數據篩選與計算，確保所得到的數據準確可靠。若某個用戶在近五分鐘內對某類商品的點擊量極高，這表明該用戶對這個品類具有濃厚的興趣，基于此，我們在推薦時，就可以考慮向該用戶著重推薦該品類下的優質商品。

此外，還有用戶的序列特征，我們將其細分為長期序列和短期序列。由于在第二層已經完成了數據的補齊工作，所以在這一層計算長期序列和短期序列特征時就變得相對簡便，直接基于行為補全層的數據進行計算即可；對于商品而言，計算邏輯也是類似的。我們已經獲取了商品相關的列表和計數信息，因此計算商品近五分鐘的曝光數、點擊數等數據也能快速完成。

在處理用戶與商品的交叉特征時，無論是用戶屬性與商品品類的交叉，還是用戶屬性與商品品牌的交叉，相較于直接處理原始數據，在樣本冷啟動階段以及特征調研階段，這種分層架構計算交叉特征的方式都要高效得多。

4.2 特征在離線不一致 && 穿越解決方案

下面我們來探討特征方面常見的問題，主要包括離線不一致問題以及特征穿越問題，同時看看針對這些問題是如何解決的。

首先是在離線不一致問題，為確保在線和離線環境下特征的一致性，我們采用 SDK 的方式，即在線和離線計算均統一使用一套C++ 的 SDK 來開展特征工程，如此一來，在線和離線所生成的特征就能保持一致。

接著是特征穿越問題。針對這一問題，我們采用 Feature Dump 方案。具體做法是，基于埋點數據、用戶數據以及商品數據進行特征開發，將開發好的特征存儲起來，以此提供特征服務。在提供特征服務的過程中，每當用戶請求模型時，系統會通過 Feature Dump 進行特征快照，將用戶當時請求時所涉及的一系列特征完整地記錄下來，并將這部分特征輸入到模型中供其使用，從而有效解決特征穿越問題。 此外，在提供特征服務時，可能會涉及離線樣本的特征計算。如果分別使用 C++ 和 Java 進行計算，可能會因精度問題導致特征不一致。而統一使用 C++ 的 SDK 進行計算，就能夠避免此類問題的發生。這些計算出的特征，一部分用于Predictor，一部分則用于生成 Feature 樣本的特征。

4.3 特征樣本在離線 DIFF

接下來分析特征樣本在離線 DIFF問題，這在我們內部是一個較為棘手的痛點。 DIFF 本質上可歸結為三個方面：其一，實時與離線數據的口徑可能不一致；其二，實時與離線數據的解析方式或許存在差異；其三，實時與離線數據的計算過程也不盡相同。

先看前兩個方面，即如何確保口徑與解析的一致性。對于埋點口徑和解析邏輯的一致性，我們需要將實時和離線數據統一到相同口徑，具體而言，離線數據應完整源自實時數據，并且要保證埋點口徑、過濾條件等方面完全一致，以此解決實時與離線數據的口徑一致性問題。在解析環節，通過提供統一的 SDK 來實現，如此離線和實時就能保證解析算子的邏輯統一。

再談計算環節，實時部分會涉及實時特征與實時樣本，在進行實時特征計算時，我們會將屬性特征與序列特征寫入特征存儲，進而提供特征服務；在樣本場景下，由于涉及樣本拼接，通常是多流拼接的過程，以京東場景為例，常常需要將用戶行為的埋點日志與特征日志進行拼接，多的時候可能涉及七八個流；此外，還需解決超大窗口的問題，比如在業務場景中，將時間窗口設置為一天，以便與離線樣本完整拼接。同時，樣本糾偏和延時反饋等問題也需在計算過程中妥善處理。從工程實現角度，要確保在離線計算的一致性，這里主要涉及口徑與采樣問題。就采樣而言，離線采樣和實時采樣有所不同。例如，離線采樣能夠計算全局正副樣本比例為1:15，但實時采樣難以做到，因為實時數據一旦流過便無法回溯。為此，我們采用相對易實現的方案，即在實時場景下，按照配置比例丟棄副樣本（在京東場景中，副樣本通常較多）；離線場景下，同樣要保證口徑與解析的完全一致。離線場景也會涉及樣本與特征的生成，如通過 Batch Join 生成離線樣本寬表，并提供給下游制定樣本策略，之后供給模型服務。

同時，還需關注質量與校驗方面。在整個數據體系中，特征樣本的分布必須保持一致。若某個特征的空值率升高，可能意味著在某個階段出現了問題。另外，延時也需保持一致，正常情況下，特征的延時應在秒級，樣本的延時為其 Window Size + 配置化的秒級。一旦延時增大，數據的時效性降低，會影響模型效果；針對特征樣本的 Label DIFF ，同樣要實現離線與在線的差異監控，做到天級或秒級的實時監測，確保數據準確無誤。所采用的技術手段包括保證數據源算子與解析算子的一致性，在多流拼接場景中，運用實時 Flink 中的 Union 加Timer 實現，同時還涉及大狀態的優化以及離線 Join 的優化。

05

可解釋

5.1 什么是推薦系統的可解釋？

接下來，我們看看在可解釋性方面的工作。首先介紹一下推薦系統可解釋性的概念，它主要分為三個方面：排序可解釋、模型可解釋以及流量可解釋，這是我們內部劃分的三個研究方向。鑒于今天的分享聚焦于 Flink ，所以我們主要探討與 Flink 相關的排序可解釋和流量可解釋。

排序可解釋，其核心在于闡釋推薦系統的排序結果。具體做法是，詳細記錄物料從召回到過濾，再到排序策略等各個階段的信息，以此作為可解釋數據的基礎。例如，當用戶請求一次推薦系統服務時，需要記錄召回的數據情況，包括從哪幾路召回、具體召回了哪些數據，經過了哪些過濾環節，如曝光過濾；在粗排和精排過程中，輸入粗排的特征有哪些、粗排返回了哪些數據、精排又返回了哪些數據，以及執行了哪些策略，都要詳細記錄。

模型可解釋，主要是對推薦系統的模型結果進行解讀。在這方面，我們重點實現了模型特征的解釋，即從特征層面剖析模型鏈路對某些 SKU 得分高低的影響。

流量可解釋，目前我們還處于建設階段。它主要是從整體流量的宏觀角度，也就是站在整個推薦系統的層面，來解釋商品的差異。例如，分析京東為什么會出現商品分層現象，以及一些長尾商品被歸為長尾的原因，究竟是因為未被召回，還是在排序過程中排序分數較低，從而導致未能獲得曝光機會。

5.2 可解釋系統架構

下面我們來剖析可解釋系統的架構。在可解釋系統架構中，最左側是模型可解釋的應用，這里主要細分為 SKU 特征重要性、用戶特征重要性以及全局特征重要性，在此不做過多贅述。

重點來看右側底層的搭建。我們將用戶的算法日志以及用戶行為數據進行解析與展開處理后，寫入 ClickHouse（CK）中。借助CK 強大的功能，我們能夠進行多維度聚合操作，以及針對精細化場景案例的查詢。例如，分析為何在情人節時系統會向用戶推送喪葬用品類的鮮花。 在排序可解釋方面，主要涉及一些常見場景的分析。比如，當用戶發現某些商品未得到曝光時，通過排查若發現商品未被召回，就需要進一步分析是否應增加一路召回途徑，或者檢查某路召回是否出現故障。對于模型而言，若某個模型一直表現穩定，但突然某項得分持續下降，就需判斷是否是模型本身出現了問題。針對策略方面，要分析策略是否存在問題，或者優勢體現在何處。還有過濾環節，像曝光過濾的設置是否合理等，都能通過可解釋系統進行深入分析。 流量可解釋主要從兩個方向展開。其一，全域的模型打分問題，即分析模型給出的分數是否合理。其二，SKU 流量對比的原因分析，例如，某些 SKU 的流量獲取能力較強，像新發布的蘋果17，其流量通常會高于新上架的普通蘋果產品（這里所舉例子雖較為極端，但旨在說明問題），我們可以從召回、模型、策略、過濾等多個維度全面分析此類問題，在這個架構中，Flink 發揮了重要作用，它實現了數據以天級為單位的 PB 級增長，并能做到實時入倉。而 Click House則為我們提供了多維分析的查詢功能，有效解決了排序可解釋分析過程中面臨的困難。?

5.3 排序可解釋

下面進一步詳細介紹排序可解釋。排序可解釋主要由五個模塊構成，分別是 Trace 鏈路、Debug 鏈路、用戶畫像、商品畫像以及行為畫像。 在這一過程中， Flink 發揮著關鍵作用，主要承擔實時數據 ETL （ Extract，Transform，Load，即數據提取、轉換和加載）功能。對于數據基石部分，我們會在排序服務器上部署 SDK 。該 SDK 能夠將日志采集到消息隊列中，而后續在進行 ETL時，則借助 Flink 來實現。值得一提的是，通過 Flink 的處理，數據能夠做到實時入倉，且這一過程的延遲時間大約在秒級，確保了數據的高效處理與及時存儲。?

5.4 流量可解釋

接下來深入探討流量可解釋。流量可解釋大致分為三層架構。最底層是數據采集層，主要負責采集埋點數據以及用戶行為數據，并借助 Flink 實現實時入倉功能，確保數據能夠及時、高效地存儲，為后續分析提供基礎。

基于底層采集的數據，構建上層的流量可解釋模塊，該模塊主要涵蓋推薦系統整體流量的歸因分析，例如針對召回、排序、策略等環節進行漏斗分析，以此洞察流量在各個關鍵節點的轉化情況。同時，還涉及用戶行為動線的建設，在此，需要明確區分用戶行為動線與序列數據，序列數據通常包含京東平臺上的主要用戶行為，如曝光、點擊、下單等，可能還包括一些更為精細的行為，像點擊評論、點擊大圖等，而用戶行為動線建設側重于描繪用戶在某一特定周期內的行為軌跡，例如用戶從一個頻道跳轉至另一個頻道，以及在此過程中所執行的一系列動作，將這些行為串聯起來形成動線，為上層應用提供深入分析的依據。借助這些數據，可以開展多種業務操作。比如進行跟單操作，通過跟蹤用戶行為來優化業務流程，構建用戶行為序列，為個性化推薦提供更精準的數據支持；實施特征回溯，以完善模型的特征數據；助力樣本冷啟，解決新業務場景下樣本不足的問題。不過，目前流量可解釋模塊尚處于建設階段，后續仍需不斷完善和優化。

06

指標

下面我們來關注指標方面的內容。在推薦系統里， Flink 主要實現了指標的實時化維度。整個指標體系的構建，是先通過 Flink 將埋點數據導入 OLAP 系統，基于這些數據，我們能夠從多個維度展開指標分析，例如，從實驗維度、品牌品類維度等，所計算的指標豐富多樣，涵蓋 UCTR、UCVR、GMV、單量以及流動性等關鍵指標。大家不難發現，有些指標單純依靠 OLAP 進行計算，可能會面臨困難，以典型的 OLAP 系統 Click House 為例，當進行多表 Join 操作時，其性能會明顯下降。所以，為了準確且高效地計算各類指標，除了 OLAP，我們還會借助 Flink 來完成其他指標的計算工作。

推薦系統的數據體系極其復雜，索引、樣本、特征任何階段的不一致都會導致推薦系統出現或大或小的case，本文從數據在離線一致性、系統可解釋性等不同方面解釋了這些問題產生的原因和京東的解決方式，歡迎一起討論交流。