快手OneRec 重構推薦系統:從檢索排序到生成統一的躍遷

文章目錄

  • 1. 背景
  • 2. 方法
    • 2.1 OneRec框架
    • 2.2 Preliminary
    • 2.3 生成會話列表
    • 2.4 利用獎勵模型進行迭代偏好對齊
      • 2.4.1 訓練獎勵模型
      • 2.4.2 迭代偏好對齊
  • 3. 總結

昨天面試的時候聊到了OneRec,但是由于上次看這篇文章已經是一個月之前,忘得差不多了,這里就來回顧一下。

1. 背景

在過去十余年中,推薦系統已經成為信息分發的核心技術,大量互聯網平臺廣泛采用了**級聯排序(cascade ranking)**的架構來平衡系統效率與推薦效果。這種方法通常將推薦流程拆解為多個獨立的階段,如召回、粗排、精排、重排,每個階段對候選集進行進一步篩選與優化。這種多階段結構雖然具備良好的工程可控性和響應速度,但由于各階段彼此獨立優化,導致信息難以全局共享,使得每個階段的性能成為下一階段的“天花板”,從而限制了系統整體的推薦能力。

與此同時,隨著生成式模型(Generative Models)在自然語言處理、計算機視覺等領域的突破,研究者開始探索其在推薦系統中的應用——特別是“生成式檢索”這一新興范式的潛力。相比傳統方法依賴向量匹配和打分機制,生成式推薦模型嘗試直接以自回歸方式“生成”用戶感興趣的內容,從而打破了傳統推薦流程中“選擇而非生成”的邏輯。然而,目前大多數生成式模型僅作為候選生成器(retrieval stage)存在,未能形成真正的端到端解決方案,其精度也未能超過多階段精調系統,導致其仍難以在工業界大規模落地。

在這種背景下,OneRec 的提出具有明確而強烈的動機:即構建一個真正統一、端到端、生成式的推薦架構,既能打破多階段推薦的結構限制,又具備大模型在表達能力上的優勢。同時,通過引入會話級生成(session-wise generation)和偏好對齊機制(preference alignment),OneRec 試圖從根本上提升推薦的上下文理解能力和用戶滿意度,探索推薦系統在“生成式時代”中的新形態。

在這里插入圖片描述

圖 1 直觀展示了傳統級聯推薦架構(Cascade Architecture)與 OneRec 所提出的統一生成式架構(Unified Architecture)之間的本質差異。下半部分(b)展示的是目前工業界廣泛采用的多階段推薦流程:首先從海量視頻庫(約 1010 個候選項)中通過粗略召回選出數十萬條視頻,經過預排序階段篩到數千條,最后由精排模型進一步打分排序,最終輸出幾十條推薦視頻。整個過程盡管高效,但各階段之間彼此獨立、信息傳遞受限,限制了最終推薦質量的上限。

上半部分(a)是 OneRec 提出的端到端生成架構,它打破了分階段設計的限制,直接使用一個 encoder-decoder 模型,輸入用戶行為序列后,一次性生成最終推薦視頻列表。這種方法不僅省略了中間復雜的召回與排序流程,還能更充分地建模用戶興趣的上下文依賴,提升推薦結果的連貫性與個性化程度。圖中的紅色箭頭“End-to-End Generation”正體現了這一轉變的核心思想:從傳統的“多階段選擇”邁向了“一體化生成”。

2. 方法

2.1 OneRec框架

在這里插入圖片描述

OneRec 是一個端到端的單階段生成式推薦框架,旨在替代傳統的多階段推薦流水線。其方法部分主要分為三個核心組件:特征工程會話級生成任務建模偏好對齊機制。圖 2 對整體流程進行了結構化展示,展示了從用戶行為建模到生成推薦列表,再到基于用戶偏好進行迭代優化的完整路徑。

如圖 2(a) 所示,OneRec 的模型結構采用 Encoder-Decoder 架構。用戶的歷史行為序列被表示為語義 token(如 <a_6><b_1><c_5>),首先由 Encoder 進行表征學習,提取出序列的上下文興趣表示 H \mathbf{H} H。Decoder 接收這一表示,并以自回歸方式生成一個完整的推薦會話列表。值得注意的是,Decoder 中引入了 稀疏專家網絡 MoE(Mixture-of-Experts),可通過激活少量專家節點提升模型表達力,同時保持高效推理。此外,模型訓練目標是最小化一個會話級的 next-token 預測損失 L NTP \mathcal{L}_{\text{NTP}} LNTP?

在圖 2(b) 中,展示了 OneRec 的第二階段——偏好對齊優化(Iterative Preference Alignment, IPA)。首先,當前訓練輪次下的 OneRec 模型 OneRec t \text{OneRec}_t OneRect? 通過 Beam Search 生成多個推薦會話候選。接著,一個訓練好的獎勵模型(Reward Model 對這些候選進行打分,選出最符合用戶偏好的結果(chosen)和最差的結果(rejected),構建偏好對比對(preference pairs)。然后使用直接偏好優化(Direct Preference Optimization, DPO) 對模型進行優化,目標函數為 L DPO \mathcal{L}_{\text{DPO}} LDPO?,從而進一步提高模型生成內容與用戶真實偏好的契合度。

2.2 Preliminary

在 OneRec 的生成式推薦任務中,模型被設計為從用戶的歷史行為中直接生成一個完整的推薦列表。輸入為用戶與內容的交互序列 H u = v 1 h , v 2 h , … , v n h \mathcal{H}_u = {v_1^h, v_2^h, \dots, v_n^h} Hu?=v1h?,v2h?,,vnh?,其中每個 v i h v_i^h vih? 表示用戶曾經有效互動的視頻,例如觀看、點贊或轉發。模型的目標是基于這些歷史行為序列,生成一個長度為 m m m 的推薦列表 S = v 1 , v 2 , … , v m \mathcal{S} = {v_1, v_2, \dots, v_m} S=v1?,v2?,,vm?,作為當前會話的推薦結果。與傳統逐項預測的方式不同,OneRec 一次性輸出整個推薦序列,強化了內容之間的連貫性和整體結構。

為了讓模型理解每個視頻的語義信息,系統為每個視頻 v i v_i vi? 提供了一個多模態嵌入向量 e i ∈ R d e_i \in \mathbb{R}^d ei?Rd,該向量整合了視頻的標題、封面圖、標簽等內容特征,并通過預訓練方法對齊用戶的真實行為偏好。這些嵌入表示作為輸入,有助于模型從內容層面建模用戶興趣,也為后續的序列生成提供了語義基礎。

過去的生成式推薦方法通常會采用 RQ-VAE(Residual Quantized Variational Autoencoder)將嵌入向量 e i e_i ei? 編碼成語義 token。然而,這種方式存在“沙漏效應”:由于 token 分布嚴重不均,部分 token 被過度使用,而大多數 token 幾乎從不出現。這種不均衡不僅限制了模型表達能力,也容易導致訓練不穩定。為解決這一問題,OneRec 采用了分層殘差量化機制,將每個嵌入向量通過多層 K-Means 編碼,逐步生成一組離散語義 token。量化過程從 e i e_i ei? 本身作為初始殘差開始,第一層選擇最近的中心點 c s i 1 1 c_{s_i^1}^1 csi1?1?

r i 1 = e i , s i 1 = arg ? min ? k ∣ r i 1 ? c k 1 ∣ 2 2 r_i^1 = e_i, \quad s_i^1 = \arg\min_k |r_i^1 - c_k^1|_2^2 ri1?=ei?,si1?=argkmin?ri1??ck1?22?

接著計算殘差 r i 2 r_i^2 ri2? 并進入下一層:

r i 2 = r i 1 ? c s i 1 1 , s i 2 = arg ? min ? k ∣ r i 2 ? c k 2 ∣ 2 2 r_i^2 = r_i^1 - c_{s_i^1}^1, \quad s_i^2 = \arg\min_k |r_i^2 - c_k^2|_2^2 ri2?=ri1??csi1?1?,si2?=argkmin?ri2??ck2?22?

以此類推,直到最后一層 L L L

r i L = r i L ? 1 ? c s i L ? 1 L ? 1 , s i L = arg ? min ? k ∣ r i L ? c k L ∣ 2 2 r_i^L = r_i^{L-1} - c_{s_i^{L-1}}^{L-1}, \quad s_i^L = \arg\min_k |r_i^L - c_k^L|_2^2 riL?=riL?1??csiL?1?L?1?,siL?=argkmin?riL??ckL?22?

最終每個視頻都被編碼為一組語義 token s i 1 , s i 2 , … , s i L {s_i^1, s_i^2, \dots, s_i^L} si1?,si2?,,siL?,作為生成模型的輸出目標。

其中,為了構建出更加平衡且高效的語義空間,OneRec 使用了一種 Balanced K-Means 聚類算法對所有視頻嵌入向量進行劃分。在這個過程中,整個視頻集合 V \mathcal{V} V 被劃分為 K K K 個等量的 cluster,每個 cluster 精確包含 w = ∣ V ∣ / K w = |\mathcal{V}| / K w=V∣/K 個視頻。算法在每輪迭代中,基于歐幾里得距離為每個中心點選擇 w w w 個最接近的未分配視頻,并據此更新中心點。當所有 cluster 達到穩定分配后,算法停止。這種方式能夠確保每個 code 被均勻使用,從而克服傳統 RQ-VAE 的 token 分布偏斜問題,提高生成模型的訓練效率和語義覆蓋能力。

在這里插入圖片描述

整個算法的輸入是:視頻集合 V \mathcal{V} V,和聚類數量 K K K。我們希望將 V \mathcal{V} V 平均劃分成 K K K 個子集,每個子集大小是 w = ∣ V ∣ / K w = |\mathcal{V}| / K w=V∣/K。下面是每一步的工作內容:

  1. 初始化階段
    • 首先計算每個 cluster 該有多少個視頻,即 w w w
    • 然后隨機選擇 K K K 個向量作為初始中心點,構成初始的 codebook: C l = c 1 l , c 2 l , … , c K l C_l = {c_1^l, c_2^l, …, c_K^l} Cl?=c1l?,c2l?,,cKl?
  2. 聚類迭代過程(repeat 循環)
    • 初始化一個未分配的視頻集合 U = V \mathcal{U} = \mathcal{V} U=V,每輪都從這個集合里往外“抽視頻”;
    • 然后對每一個 cluster k k k 做以下步驟:
      • 計算 U \mathcal{U} U 中所有視頻到當前中心點 c k l c_k^l ckl? 的距離;
      • 按距離從近到遠排序;
      • 選擇前 w w w 個最接近的視頻分配給當前 cluster(記作 V k \mathcal{V}_k Vk?);
      • 用這 w w w 個視頻的平均值更新中心點 c k l c_k^l ckl?
      • 最后把這 w w w 個已分配的視頻從 U \mathcal{U} U 中移除。
  3. 終止條件
    • 當所有 cluster 的分配都不再發生變化時(也就是“收斂”了),循環結束;
    • 輸出最終的均衡 codebook C l C_l Cl?,用于后續的殘差量化過程。

與傳統 K-Means 不同的是,Balanced K-Means 會強制讓每個 cluster 拿到相同數量的視頻,這保證了所有 token 都能被均勻使用,不會有某些 token 被濫用、某些 token 被冷落。這種平衡性對于語義編碼來說非常關鍵,因為后續的生成模型訓練依賴這些 token 的質量和覆蓋范圍。

2.3 生成會話列表

在這里插入圖片描述

在 OneRec 的推薦生成中,我們首先需要一種方式將每個視頻轉換為模型可以理解的離散語義表示。為此,論文借鑒了 RQ-VAE(Residual Quantization VAE) 的思想,對視頻的多模態嵌入向量進行分層殘差量化編碼。每個視頻原本是一個連續向量 e i ∈ R d e_i \in \mathbb{R}^d ei?Rd,通過 L L L 層的 K-Means 量化后,變成了 L L L 個離散 token,也就是 s i 1 , s i 2 , … , s i L {s_i^1, s_i^2, …, s_i^L} si1?,si2?,,siL?。每個 token 表示該視頻在某一語義空間中的“位置”,這使得模型能更好地建模視頻的語義結構。最終,我們將用戶的歷史行為序列(多個視頻)拼接成一個 token 序列,作為 Encoder 的輸入,形式如下:

H u = ( s 1 1 , s 1 2 , … , s 1 L ) , ( s 2 1 , s 2 2 , … , s 2 L ) , … , ( s n 1 , s n 2 , … , s n L ) \mathcal{H}_u = {(s_1^1, s_1^2, \dots, s_1^L), (s_2^1, s_2^2, \dots, s_2^L), \dots, (s_n^1, s_n^2, \dots, s_n^L)} Hu?=(s11?,s12?,,s1L?),(s21?,s22?,,s2L?),,(sn1?,sn2?,,snL?)

Encoder 的作用是對用戶的歷史行為進行建模,提取用戶興趣的語義表示。在 OneRec 中,Encoder 采用了 Transformer 架構,輸入就是剛才提到的 H u \mathcal{H}_u Hu?,也就是視頻 token 的序列。每個 token 會通過多層的自注意力(Self-Attention)和前饋網絡(Feed Forward)進行編碼,最終輸出一個用戶興趣表示序列 H H H

H = Encoder ( H u ) H = \text{Encoder}(\mathcal{H}_u) H=Encoder(Hu?)

其中,Attention 是全可見的(Fully Visible),因為我們希望模型可以自由地在歷史行為之間建模上下文關系。這個 H H H 就像是一份語義“興趣檔案”,會在后續 Decoder 生成推薦列表時被引用,作為 cross-attention 的 Key 和 Value。

Decoder 的任務是根據用戶興趣向量 H H H,生成推薦 session(多個視頻 token)的完整序列。Decoder 同樣采用 Transformer 架構,在每一層中包含因果掩碼的 Self-Attention 和對 Encoder 輸出 H H H 的 Cross-Attention。在訓練階段,我們使用真實的推薦 session(例如用戶確實點開的內容),將每個視頻編碼為一組 token s i 1 , … , s i L {s_i^1, …, s_i^L} si1?,,siL?,并在每個視頻前添加起始標記 s [ BOS ] s_{[\text{BOS}]} s[BOS]?,構造 Decoder 的輸入:

S ˉ = s [ BOS ] , s 1 1 , s 1 2 , … , s 1 L , s [ BOS ] , s 2 1 , … , s 2 L , … \bar{\mathcal{S}} = {s_{[\text{BOS}]}, s_1^1, s_1^2, …, s_1^L, s_{[\text{BOS}]}, s_2^1, …, s_2^L, \dots} Sˉ=s[BOS]?,s11?,s12?,,s1L?,s[BOS]?,s21?,,s2L?,

Decoder 的每個 token 都依賴于前面已生成的 token,同時參考 Encoder 提供的用戶興趣向量 H H H,一步步自回歸生成整個推薦序列。

整個 Encoder-Decoder 模型是通過一個標準的語言建模目標進行端到端訓練,目標是最小化生成 token 序列與真實推薦 token 序列之間的差異。具體來說,訓練采用的是自回歸的 下一 token 預測損失,即 Next Token Prediction Loss( L NTP \mathcal{L}_{\text{NTP}} LNTP?):

L NTP = ? ∑ i = 1 m ∑ j = 1 L log ? P ( s i j + 1 ∣ s [ BOS ] , s 1 1 , s 1 2 , … , s 1 L , s [ BOS ] , s i 1 , s i 2 , … , s i j ; Θ ) \mathcal{L}_{\text{NTP}} = - \sum_{i=1}^m \sum_{j=1}^L \log P(s_i^{j+1} \mid s_{[\text{BOS}]}, s_1^1, s_1^2, …, s_1^L,s_{[\text{BOS}]}, s_i^1, s_i^2, \dots, s_i^j; \Theta) LNTP?=?i=1m?j=1L?logP(sij+1?s[BOS]?,s11?,s12?,,s1L?,s[BOS]?,si1?,si2?,,sij?;Θ)

其中, s i j s_i^j sij? 表示第 i i i 個視頻的第 j j j 個 token, Θ \Theta Θ 表示整個模型參數(包含 Encoder 和 Decoder)。訓練的目標是最大化生成下一個 token 的概率,從而保證 Decoder 能夠準確地生成推薦 session 的每一個 token。這種訓練方式完全類比于機器翻譯任務中的 Transformer,只不過在這里,推薦 session 的 token 取代了自然語言中的詞語,成為生成的目標。

2.4 利用獎勵模型進行迭代偏好對齊

在這里插入圖片描述

盡管 OneRec 在前期通過端到端的訓練已經能夠生成符合用戶歷史興趣的推薦列表,但僅僅依賴歷史行為序列進行建模,仍然難以保證生成的內容真正契合用戶偏好。傳統推薦系統通常通過點擊率、停留時長等弱監督信號進行優化,但這些指標本質上并不能直接衡量用戶對整個推薦 session 的滿意度。因此,為了進一步提升推薦質量,OneRec 引入了“偏好對齊”(preference alignment)機制,旨在從用戶行為中學習推薦結果的優劣,從而實現更細致、更個性化的推薦調整。這種優化思想受啟發于自然語言處理(NLP)領域中流行的 RLHF(Reinforcement Learning from Human Feedback),即通過人類打分對生成結果進行強化學習。然而,與 NLP 不同,推薦系統中幾乎不存在由人類標注的“偏好比較數據”。取而代之的,是稀疏、間接的用戶行為數據。因此,OneRec 設計了一種替代方式:先構建一個獎勵模型(Reward Model, RM),讓其學會自動評估一個推薦 session 的“質量”,然后利用這個 RM 來對模型生成的多個候選推薦進行打分,從中選出“好”的(chosen)和“不好”的(rejected),形成偏好對比對。在此基礎上,OneRec 采用了 Direct Preference Optimization(DPO) 進行訓練。這種方法不依賴復雜的強化學習算法,而是通過 pairwise ranking 的方式直接優化生成策略,使得模型在未來生成中更加傾向于高偏好序列。最終,模型可以在真實用戶行為的弱監督反饋中,持續進行自我迭代、自我優化,從而生成更貼合用戶興趣的內容,真正實現從“生成推薦”到“偏好對齊”的閉環。

2.4.1 訓練獎勵模型

在 OneRec 中,為了實現用戶偏好的精準對齊,模型需要一種機制能夠判斷“推薦得好不好”。但推薦系統不同于 NLP 領域,后者可以通過人工標注來得到明確的偏好信號,而推薦系統中用戶并不會直接告訴我們他喜歡哪些推薦。相反,我們只能通過用戶在實際使用系統時留下的行為數據,來間接推斷推薦的好壞。為了解決這一問題,OneRec 引入了一個獎勵模型(Reward Model, RM),用來預測用戶是否會喜歡某個推薦 session,并將這個預測結果作為后續優化的依據。

獎勵模型的目標是,給定一個用戶 u u u 和一個推薦 session S = v 1 , v 2 , … , v m \mathcal{S} = {v_1, v_2, …, v_m} S=v1?,v2?,,vm?,輸出一個分數 r r r 來表示這個 session 對該用戶來說是否具有吸引力。這個分數不需要用戶明確標注,而是通過用戶的行為日志進行間接學習。比如,當用戶完整地觀看了 session 中的大多數視頻、點擊了其中的內容、點贊或收藏了視頻時,這些行為都可以被視為“喜歡”;而如果用戶快速劃過這些推薦,或者根本沒有互動,則說明這條推薦可能不夠好。這些自然發生的行為數據就成為訓練獎勵模型的“真實標簽”。

為了讓模型具備判斷能力,第一步是將用戶 u u u 和推薦 session S \mathcal{S} S 建模為一組結合表示。具體來說,對于 session 中的每個視頻 v i v_i vi?,模型會融合用戶興趣生成一個目標感知向量:

e i = v i ⊙ u e_i = v_i \odot u ei?=vi?u

其中 ⊙ \odot 表示一種交互操作(可以理解為加權注意力、向量點乘等),使得每個視頻的表示都與用戶興趣相關聯。經過融合后的所有視頻表示構成一個向量集合 h = e 1 , e 2 , … , e m h = {e_1, e_2, …, e_m} h=e1?,e2?,,em?,這就形成了該用戶視角下的 session 表示。

考慮到推薦列表中的多個視頻之間是有協同關系的(比如連貫性、風格一致性、多樣性等),模型并不會直接使用這些向量去做判斷,而是通過一個**多頭自注意力模塊(Self-Attention)**來讓視頻之間“交流信息”:

h f = SelfAttention ( h W s Q , h W s K , h W s V ) h_f = \text{SelfAttention}(hW_s^Q, hW_s^K, hW_s^V) hf?=SelfAttention(hWsQ?,hWsK?,hWsV?)

這個操作讓模型能感知整個 session 的結構與互動,最終輸出一個融合后的 session 表示 h f h_f hf?,用于后續的打分預測。

為了全面評估推薦 session 的質量,OneRec 的獎勵模型設計了多個預測任務,分別關注用戶的不同偏好行為。例如:

  • r ^ swt \hat{r}^{\text{swt}} r^swt:用戶是否持續觀看(session watch time);
  • r ^ vtr \hat{r}^{\text{vtr}} r^vtr:用戶是否點擊進入觀看(view through rate);
  • r ^ ltr \hat{r}^{\text{ltr}} r^ltr:用戶是否點贊、收藏等行為(like-through rate);

這些行為通過不同的 MLP 模塊(也稱作 tower)來分別預測:

r ^ swt = Tower swt ( Sum ( h f ) ) , r ^ vtr = Tower vtr ( Sum ( h f ) ) , r ^ ltr = Tower ltr ( Sum ( h f ) ) \hat{r}^{\text{swt}} = \text{Tower}^{\text{swt}}(\text{Sum}(h_f)), \quad \hat{r}^{\text{vtr}} = \text{Tower}^{\text{vtr}}(\text{Sum}(h_f)), \quad \hat{r}^{\text{ltr}} = \text{Tower}^{\text{ltr}}(\text{Sum}(h_f)) r^swt=Towerswt(Sum(hf?)),r^vtr=Towervtr(Sum(hf?)),r^ltr=Towerltr(Sum(hf?))

這里的 Sum ( h f ) \text{Sum}(h_f) Sum(hf?) 表示對 session 中所有 token 表示做加和池化,得到整體 session 的語義表達,然后再送入每個塔進行預測。

訓練過程中,系統會從用戶真實行為日志中抽取是否完成觀看、是否點擊、是否點贊等行為,轉化為二分類標簽(1 表示發生,0 表示未發生)。模型的輸出與這些標簽進行對比,采用二元交叉熵損失函數作為優化目標:

L RM = ? ∑ x ∈ swt , vtr , ltr x t r [ y x t r log ? ( r ^ x t r ) + ( 1 ? y x t r ) log ? ( 1 ? r ^ x t r ) ] \mathcal{L}_{\text{RM}} = - \sum_{x \in {\text{swt}, \text{vtr}, \text{ltr}}}^{xtr}\left[ y^{xtr} \log(\hat{r}^{xtr}) + (1 - y^{xtr}) \log(1 - \hat{r}^{xtr}) \right] LRM?=?xswt,vtr,ltrxtr?[yxtrlog(r^xtr)+(1?yxtr)log(1?r^xtr)]

這個損失函數會對每一個行為目標分別求解,并指導模型學習什么樣的推薦 session 更容易被用戶接受、產生良好互動。最終訓練完成的獎勵模型就具備了自動評分能力,可以在無需人工干預的前提下判斷任意一個推薦 session 的優劣,為后續的 DPO 偏好對齊提供決策依據。

2.4.2 迭代偏好對齊

在完成獎勵模型(Reward Model, RM)的訓練之后,我們就可以利用它對推薦結果的質量進行自動打分,并用作模型微調的依據。OneRec 并沒有一次性完成訓練,而是采用了一個迭代式的偏好對齊方法(Iterative Preference Alignment)。它的核心思路是:讓模型自己生成多個推薦候選,然后用獎勵模型打分,從中選出表現好的和差的推薦結果,作為正負樣本對進行對比學習。這種方式與傳統的強化學習不同,它更簡單、更穩定,同時能在沒有明確人工偏好標簽的前提下實現推薦優化。

具體來說,給定當前時間步的 OneRec 模型 M t \mathcal{M}_t Mt?,我們為每個用戶 u u u 生成 N N N 個不同的推薦 session 候選,使用的是 Beam Search 采樣:

S u n ~ M t ( H u ) for?all? u ∈ U , n ∈ [ N ] \mathcal{S}_u^n \sim \mathcal{M}_t(\mathcal{H}_u) \quad \text{for all } u \in \mathcal{U}, n \in [N] Sun?Mt?(Hu?)for?all?uU,n[N]

其中, H u \mathcal{H}_u Hu? 表示用戶 u u u 的歷史行為, S u n \mathcal{S}_u^n Sun? 是模型生成的第 n n n 個推薦 session 候選。生成這些 session 后,我們使用前面訓練好的獎勵模型 R ( u , S ) R(u, \mathcal{S}) R(u,S) 對每個候選結果進行打分,得到該推薦 session 的偏好得分:

r u n = R ( u , S u n ) r_u^n = R(u, \mathcal{S}_u^n) run?=R(u,Sun?)

隨后,我們從這 N N N 個候選中選出得分最高的一個 S u w \mathcal{S}_u^w Suw? 和得分最低的一個 S u l \mathcal{S}_u^l Sul?,構成一個偏好對比對(Preference Pair)

D t pairs = ( S u w , S u l , H u ) D_t^{\text{pairs}} = \left(\mathcal{S}_u^w, \mathcal{S}_u^l, \mathcal{H}_u\right) Dtpairs?=(Suw?,Sul?,Hu?)

也就是說,在給定用戶歷史 H u \mathcal{H}_u Hu? 的前提下,我們知道用戶更可能喜歡 S u w \mathcal{S}_u^w Suw?,而不太喜歡 S u l \mathcal{S}_u^l Sul?。我們希望訓練一個新的模型 M t + 1 \mathcal{M}_{t+1} Mt+1?,讓它以后在面對相同用戶歷史時,更傾向于生成 S u w S_u^w Suw? 這樣的推薦,而不是 S u l S_u^l Sul?

訓練新模型使用的是 DPO(Direct Preference Optimization)損失函數,它通過比較兩個推薦結果的相對概率,來實現模型偏好上的優化。具體損失如下:

L DPO = L DPO ( S u w , S u l ∣ H u ) = ? log ? σ ( β log ? M t + 1 ( S u w ∣ H u ) M t ( S u w ∣ H u ) ? β log ? M t + 1 ( S u l ∣ H u ) M t ( S u l ∣ H u ) ) \mathcal{L}_{\text{DPO}} = \mathcal{L}_{\text{DPO}}(\mathcal{S}_u^w, \mathcal{S}_u^l \mid \mathcal{H}_u) = -\log \sigma \left( \beta \log \frac{\mathcal{M}_{t+1}(\mathcal{S}_u^w \mid \mathcal{H}_u)}{\mathcal{M}_t(\mathcal{S}_u^w \mid \mathcal{H}_u)} - \beta \log \frac{\mathcal{M}_{t+1}(\mathcal{S}_u^l \mid \mathcal{H}_u)}{\mathcal{M}_t(\mathcal{S}_u^l \mid \mathcal{H}_u)} \right) LDPO?=LDPO?(Suw?,Sul?Hu?)=?logσ(βlogMt?(Suw?Hu?)Mt+1?(Suw?Hu?)??βlogMt?(Sul?Hu?)Mt+1?(Sul?Hu?)?)

這個公式的核心是:如果新的模型 M t + 1 \mathcal{M}_{t+1} Mt+1? 在偏好的推薦上得分更高、在不偏好的推薦上得分更低,那這個偏好方向是正確的,損失就會變小;反之則會增大。 β \beta β 是一個可調的溫度超參數,用于控制對比強度, σ \sigma σ 是 sigmoid 函數。

整個過程是逐步迭代進行的:從 M t \mathcal{M}_t Mt? 開始,我們生成候選、打分、選出正負樣本對、計算損失、更新參數,得到 M t + 1 \mathcal{M}_{t+1} Mt+1?。下一個迭代又以 M t + 1 \mathcal{M}_{t+1} Mt+1? 為基礎繼續進行。這種自我對比、自我優化的策略,使得模型能夠不斷地貼近用戶真實偏好。

為了減輕計算負擔,論文中提到實際只對 1% 的樣本進行 DPO 微調(即 r DPO = 1 r_{\text{DPO}} = 1% rDPO?=1),從而在效率和性能之間取得平衡。

這一迭代優化過程的最終目標,是構建出一個能持續自我進化的推薦系統,使模型不僅能根據歷史行為生成推薦,還能“對比判斷”哪些推薦更好,并據此不斷改進。相比傳統的強化學習,DPO 更簡潔、穩定,特別適用于用戶行為數據稀疏、偏好信號隱性的推薦場景。它使得 OneRec 不僅是一個生成模型,更是一個可以持續優化的偏好智能體。

在這里插入圖片描述

圖 3 展示了 OneRec 系統在真實業務中的在線部署與訓練框架。整個系統由三個主要組成部分構成:DPO Server、分布式訓練系統在線服務系統(Online Serving)。其中,DPO Server 包含了預訓練好的獎勵模型 R ( u , S ) R(u, \mathcal{S}) R(u,S) 和用于生成偏好對比對的 DPO Sample Server,它負責從當前 OneRec 模型中生成多個候選推薦,并利用獎勵模型對這些候選進行打分,從中選出得分最高和最低的推薦 session,形成偏好對比對 ( S u w , S u l ) \left(\mathcal{S}_u^w, \mathcal{S}_u^l\right) (Suw?,Sul?)。這些樣本會被送入 Offline Model Trainer,與主干的推薦模型一起進行訓練,并定期將更新后的參數同步到在線推理服務(Online Infer Model)中,實現推薦效果的持續自我優化。

在這里插入圖片描述

算法 2 給出了整個 Iterative Preference Alignment(IPA)過程的詳細執行流程。在每一輪訓練中,模型會遍歷樣本集合 N sample N_{\text{sample}} Nsample?,對于每一個樣本,根據預設概率 r DPO r_{\text{DPO}} rDPO? 決定是否進行 DPO 微調。如果是,則執行如下步驟:從當前模型 M t \mathcal{M}_t Mt? 中生成 N N N 個推薦候選 S u n \mathcal{S}_u^n Sun?,并使用獎勵模型 R ( u , S u n ) R(u, \mathcal{S}_u^n) R(u,Sun?) 為它們打分,挑選得分最高的作為偏好推薦 S u w \mathcal{S}_u^w Suw?,得分最低的作為反偏好推薦 S u l \mathcal{S}_u^l Sul?。隨后計算該樣本的 DPO 損失 L DPO \mathcal{L}{\text{DPO}} LDPO 與常規的下一 token 預測損失 L NTP \mathcal{L}_{\text{NTP}} LNTP?,并組合得到總損失 L \mathcal{L} L。否則,若不進行 DPO,僅使用 NTP 損失進行更新。最終,根據該損失對模型參數 Θ \Theta Θ 進行梯度更新。

3. 總結

總的來說,OneRec不僅是一種技術創新,也是快手生成式推薦的重要探索,體現了推薦系統未來的發展趨勢:從“排序打分”走向“偏好理解與生成”,從“靜態預測”走向“持續自我優化”。

本文提出OneRec打破傳統多階段檢索排序架構的限制,首次構建一個端到端、單階段、生成式推薦模型框架。在方法上,采用一種平衡k-means(RQ-VAE改變)將視頻內容編碼為離散語義token,基于用戶行為的統一編碼器解碼器結構(解碼器用了MoE技術),通過自回歸生成完整的推薦session。并為進一步提升推薦質量,結合DPO以及獎勵模型,進行迭代的偏好對齊,實現模型與用戶真實偏好的自我對齊。整天方法不僅在離線評估中顯著優于傳統推薦策略,也已成功部署與真實短視頻平臺中。

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/news/901848.shtml
繁體地址,請注明出處:http://hk.pswp.cn/news/901848.shtml
英文地址,請注明出處:http://en.pswp.cn/news/901848.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

軟考高級系統架構設計師-第11章 系統架構設計

【本章學習建議】 根據考試大綱&#xff0c;本章不僅考查系統架構設計師單選題&#xff0c;預計考12分左右&#xff0c;而且案例分析和論文寫作也是必考&#xff0c;對應第二版教材第7章&#xff0c;屬于重點學習的章節。 軟考高級系統架構設計師VIP課程https://edu.csdn.net/…

selenium之文件下載

Selenium 自動化測試&#xff1a;輕松搞定文件下載 在 Web 自動化測試中&#xff0c;經常會遇到需要驗證文件下載功能的場景。例如&#xff0c;測試報告的導出、用戶上傳文件的下載、PDF 文檔的生成與下載等等。Selenium 本身并沒有直接處理文件下載的內置方法&#xff0c;但我…

基于遷移學習實現肺炎X光片診斷分類

大家好&#xff0c;我是帶我去滑雪&#xff01; 肺炎是全球范圍內致死率較高的疾病之一&#xff0c;尤其是在老年人、免疫系統較弱的患者群體中&#xff0c;更容易引發嚴重并發癥。傳統上&#xff0c;肺炎的診斷依賴于醫生的臨床經驗以及影像學檢查&#xff0c;尤其是X光片&…

工業數據治理范式革新:時序數據庫 TDengine虛擬表技術解析

小T導讀&#xff1a;在工業數字化過程中&#xff0c;數據如何從設備采集順利“爬坡”到上層應用&#xff0c;一直是個難題。傳統“單列模型”雖貼合設備協議&#xff0c;卻讓上層分析舉步維艱。TDengine 用一種更聰明的方法打通了這條數據通路&#xff1a;不強求建模、不手動轉…

Redis面試——日志

一、RDB&#xff08;Redis DataBase&#xff09; RDB 全程是 Redis DataBase&#xff0c;它是一種將 Redis 在某一時刻內存中的數據以快照形式保存到磁盤的機制 &#xff0c;相當于給執行save/bgsave命令時刻的內存數據庫數據拍了一張快照我們如果通過save命令來執行快照&…

【Android】常用參數實踐 用戶界面UI 布局文件XML

本文將系統總結 Android XML 布局的通用參數和常用布局類型的專屬規則 一、通用布局參數 這些參數適用于所有 View 和 ViewGroup&#xff0c;是布局設計的基石。 1. 尺寸控制 android:layout_width 與 android:layout_height 定義視圖的寬度和高度&#xff0c;可選值&#xf…

解決 VSCode 中 NVM 配置后無法識別 Node 和 NPM 的問題

在開發中&#xff0c;我們經常需要使用 Node.js 和 NPM 來管理 JavaScript 項目依賴&#xff0c;而 NVM&#xff08;Node Version Manager&#xff09;是開發者在本地環境中管理多個 Node.js 版本的得力工具。不過&#xff0c;有時候在 VSCode 中配置完 NVM 后&#xff0c;可能…

BGP分解實驗·23——BGP選路原則之路由器標識

在選路原則需要用到Router-ID做選路決策時&#xff0c;其對等體Router-ID較小的路由將被優選&#xff1b;其中&#xff0c;當路由被反射時&#xff0c;包含起源器ID屬性時&#xff0c;該屬性將代替router-id做比較。 實驗拓撲如下&#xff1a; 實驗通過調整路由器R1和R2的rout…

Linux: 線程同步

目錄 一 前言 二 線程饑餓 三 線程同步 四 條件變量 1. cond &#xff08; condition&#xff09; 2. pthread_cond_wait() &#xff1a; 3. pthread_cond_signal() 五 條件變量的使用 一 前言 在上篇文章Linux : 多線程互斥-CSDN博客我們講解了線程互斥的概念&#xff…

MyBatisPlus-QueryWrapper的exists方法拼接SQL中的EXISTS子句

在 MyBatis-Plus 中,QueryWrapper 的 exists 方法用于拼接 SQL 中的 EXISTS 子句,通常用于構 建子查詢條件。以下是具體用法和示例: ??1. 基本語法?? // 判斷是否存在符合條件的記錄 queryWrapper.exists(String existsSql); queryWrapper.notExists(String existsSq…

[數據結構]哈希表

目錄 1、哈希表 1.1、概念 1.2、沖突 2、哈希函數設計 3、負載因子調節 4、閉散列 5、開散列/哈希桶&#xff08;重點掌握&#xff09; 6、實現哈希桶 6.1、put方法 6.2、HashMap的擴容機制 6.3、get方法 7、HashMap 8、HashSet 8.1、哈希表性能分析 9、hashcod…

VS-Code創建Vue3項目

1 創建工程文件 創建一個做工程項目的文件夾 如&#xff1a;h5vue 2 cmd 進入文件 h5vue 3 輸入如下命令 npm create vuelatest 也可以輸入 npm create vitelatest 4 輸入項目名稱 項目名稱&#xff1a;自已輸入 回車 可以按鍵盤 a (全選) 回車&#xff1a; Playwright…

linux休眠喚醒流程

1、框架 2、休眠流程 應用層通過echo mem > /sys/power/state寫入休眠狀態&#xff0c;給一張大概流程圖 這個操作對應在kernel/power/main.c的state這個attr的store操作 static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr, …

Mysql--基礎知識點--93--兩階段提交

1 兩階段提交 以update語句的具體執行過程為例&#xff1a; 具體更新一條記錄 UPDATE t_user SET name ‘xiaolin’ WHERE id 1;的流程如下&#xff1a; 1.執行器負責具體執行&#xff0c;會調用存儲引擎的接口&#xff0c;通過主鍵索引樹搜索獲取 id 1 這一行記錄&#…

Windows 環境下 Apache 配置 WebSocket 支持

目錄 前言1. 基本知識2. 實戰前言 ?? 找工作,來萬碼優才:?? #小程序://萬碼優才/r6rqmzDaXpYkJZF 爬蟲神器,無代碼爬取,就來:bright.cn 原先寫過apache的http配置:Apache httpd-vhosts.conf 配置詳解(附Demo) 1. 基本知識 ?? WebSocket 是 HTTP 的升級協議 客戶…

UMAEA論文閱讀

Preliminaries MMKG為一個五元組G{E, R, A, V, T}&#xff0c;其中E、R、A和V分別表示實體集、關系集、屬性集和圖像集。 T?ERE是關系三元組集。 給定兩個MMKG G1 {E1, R1, A1, V1, T1} 和 G2 {E2, R2, A2, V2, T2}&#xff0c; MMEA旨在識別每個實體對&#xff08;e1…

AIGC-十款知識付費類智能體完整指令直接用(DeepSeek,豆包,千問,Kimi,GPT)

Unity3D特效百例案例項目實戰源碼Android-Unity實戰問題匯總游戲腳本-輔助自動化Android控件全解手冊再戰Android系列Scratch編程案例軟考全系列Unity3D學習專欄藍橋系列AIGC(GPT、DeepSeek、豆包、千問、Kimi)??關于作者 專注于Android/Unity和各種游戲開發技巧,以及各種資…

Qt界面卡住變慢的解決方法

本質原因: 當Qt界面出現卡頓或無響應時&#xff0c;通常是因為主線程&#xff08;GUI線程&#xff09;被耗時操作阻塞。 完全忘了。。。 Qt Creater解決方法 1. 定位耗時操作 目標&#xff1a;找到阻塞主線程的代碼段。 方法&#xff1a; 使用QElapsedTimer測量代碼執行時間…

【LangChain4j快速入門】5分鐘用Java玩轉GPT-4o-mini,Spring Boot整合實戰!| 附源碼

【LangChain4j快速入門】5分鐘用Java玩轉GPT-4o-mini&#xff0c;Spring Boot整合實戰&#xff01; 前言&#xff1a;當Java遇上大模型 在AI浪潮席卷全球的今天&#xff0c;Java開發者如何快速擁抱大語言模型&#xff1f;LangChain4j作為專為Java打造的AI開發框架&#xff0c…

Vue 3 reactive 和 ref 區別及 失去響應性問題

在 Vue 3 中&#xff0c;reactive 和 ref 是實現響應式數據的兩個核心 API&#xff0c;它們的設計目標和使用場景有所不同。以下是兩者的詳細對比&#xff1a; 1. 基本定義與核心功能 特性reactiveref作用創建對象類型的響應式代理&#xff08;對象、數組、Map 等&#xff09…