ホームページ >テクノロジー周辺機器 >AI >Baidu 仕分け技術の探求と応用
まず、Baidu の包括的な情報フロー推奨のビジネス背景、データ背景、および基本的なアルゴリズム戦略を紹介します。
Baidu の包括的な情報フローには、Baidu APP の検索ボックスが含まれています。リストページとイマージョンページの形式で、さまざまな製品タイプをカバーします。上の図からわかるように、推奨されるコンテンツ形式には、Douyin に似た没入型レコメンデーションのほか、Xiaohongshu Notes のレイアウトに似た 1 列および 2 列のレコメンデーションが含まれます。ユーザーがコンテンツと対話する方法も多数あります。ランディング ページでコンテンツにコメントしたり、「いいね!」をしたり、収集したりできます。また、作成者ページに入って関連情報を表示し、対話することもできます。また、ユーザーは否定的なフィードバックなどを提供することもできます。包括的な情報フロー全体の設計は非常に豊富かつ多様で、ユーザーのさまざまなニーズや対話方法に対応できます。
モデリングの観点から見ると、私たちは主に 3 つの課題に直面しています:
## ######################### 大規模 ############。 1 日あたりの表示レベルは数百億を超えるため、モデルには 1 日あたり数百億のスループットが必要です。 1 日あたりの DAU は 1 億を超えており、モデル全体を高スループットと高スケーラビリティで設計する必要があることもわかります。ソートモデルはオンライン上で毎秒数億回の計算が行われるため、モデル設計時には効果だけでなくパフォーマンスも考慮する必要があり、パフォーマンスと効果のバランスをとる必要があります。ユーザーインタラクションの形式とシナリオが多様化しているため、複数の種類のタスクを予測するモデルも必要です。 ##################高需要。システム全体の応答時間要件は非常に高く、エンドツーエンドの計算はミリ秒単位で実行されます。所定の時間を超過すると、エラーが返されます。これは、複雑な構造をオンラインにすることが難しいという別の問題も引き起こします。
次に、機能、アルゴリズム、アーキテクチャの3つの観点からさらに詳しく紹介します。
特性は、ユーザーとシステム間の対話型の意思決定プロセスを説明します。
次の図は、ユーザー、リソース、シナリオ、状態の時空間関係相互作用マトリックス図を示しています。
まず、すべてのシグナルをユーザー、リソース、シナリオ、状態の 4 つの次元に分割します。本質的にユーザーとリソースをモデル化する必要があるためです。 。各次元で様々な似顔絵データを制作可能です。
ユーザーの視点から見た、年齢、性別、関心のあるポイントの最も基本的なポートレート。これに基づいて、類似したユーザーや、さまざまなリソースタイプに対するユーザーの過去の好みの行動など、いくつかのきめ細かい機能も追加されます。セッションの特徴は主に長期および短期の行動シーケンスです。業界には多数のシーケンス モデルがあるため、ここでは詳しく説明しません。ただし、どのような種類のシーケンス モデルを作成する場合でも、機能レベルでの離散セッション機能は不可欠です。 Baidu の検索広告では、このようなきめ細かいシーケンス機能が 10 年以上前に導入されており、異なる時間枠での異なるリソースタイプに対するユーザーのクリック行動や消費行動などを注意深く描写する複数のシーケンス機能が導入されています。
リソース ディメンションには、メモリが大半を占めるリソース自体の状況を記録するための ID タイプの機能もあります。基本的な一般化機能を実現するためのプレーンテキストのポートレート機能もあります。粗粒度の特徴に加えて、ポートレート特徴の埋め込みなど、より詳細なリソース特徴もあり、これはマルチモダリティなどの事前トレーニング済みモデルに基づいて生成され、個別の埋め込みにおけるリソース間の関係のより詳細なモデリングが行われます。空間。さまざまな状況下でのリソースの事後的なパフォーマンスを説明する統計的なポートレート機能もあります。類似した特徴だけでなく、ユーザーはリソースを逆に特徴付けて精度を向上させることができます。
シーンのサイズに関しては、シングルカラム、イマーシブ、ダブルカラムなど、さまざまなシーン特性があります。
ユーザーは、状態によってフィード情報を異なる方法で消費します。例えば、更新ステータスが何なのか、どのようなネットワークから来ているのか、ランディングページのインタラクションフォームがどのようなものであるかなどは、ユーザーの今後の意思決定に影響を与えるため、ステータスの側面からも特徴を記述します。
ユーザー、リソース、ステータス、シナリオの 4 つの側面を通じて、ユーザーとシステムの相互作用の意思決定プロセスを包括的に描写します。多くの場合、複数の次元間の組み合わせも行われます。
次に、離散特徴設計の原則を紹介します。
高品質の特徴には、通常、高い識別性、高いカバレッジ、強力な堅牢性という 3 つの特性があります。
#上記の 3 つの基準に加えて、単一の特徴に対して AUC を判断することもできます。たとえば、特定の機能のみを使用してモデルをトレーニングし、その機能とターゲットの関係を確認します。特定の機能を削除し、その機能がなくなった後の AUC の変化を確認することもできます。
上記の設計原則に基づいて、クロスオーバー、バイアス、シーケンスの 3 種類の重要な機能に焦点を当てます。
整個推薦漏斗是分層設計的,每一層都做了過濾與截斷。如何在濾波截斷的分層設計中達到效率最高呢?前面也提到會做模型的聯合訓練。另外,特徵設計的維度上也可以做相關的設計。這裡也存在一些問題:
接下來介紹核心演算法的設計。
首先來看推薦排序模型。一般認為,精排是推薦系統中精度最高的模型。業界有一種觀點認為粗排附屬於精排,對著精排學就可以了,但具體實踐中發現粗排並不能直接對著精排來學,可能會帶來很多問題。
#從上圖可以看出,粗排與精排的定位不同。一般來說,粗排的訓練樣本與精排一樣,也是展現樣本。每次召回候選供粗排打分的結果有數萬條之多,這裡面99% 以上的資源是沒有被展現的,而模型僅使用最終展現的十幾條資源來做訓練,這就打破了獨立同分佈的假設,在離線模型分佈差異極大。這種情況在召回是最為嚴重的,因為召回的候選集都是數百萬、數千萬甚至數億,最終返回的結果大多數也都是沒有被展現的,粗排一樣相對也比較嚴重,因為候選集通常也在數萬級。而精排就相對好很多,通過了召回與粗排兩層漏斗後,資源的基礎品質是有保證的,它主要做優中選優的工作。因此,精排在離線分佈不一致問題不是那麼嚴重,不需要過多地考慮樣本選擇偏差(SSB)的問題,同時由於候選集合小,可以做重計算,精排重點在於特徵交叉,序列建模等。
但是粗排這一層,並不能直接對著精排學,也不能直接做類似精排的重計算,因為其計算量是精排的數十倍,如果直接用精排的設計思路,線上的機器是完全不可承受的,所以粗排需要高度的技巧平衡性能與效果,它是一個輕量級模組。粗排迭代的重點與精排不同,主要解決樣本選擇偏差,回想隊列最佳化等問題。由於粗排與召回關係緊密,更關注的是返回精排的數千資源的平均質量,而不是精確的排序關係。精排則是與重排關係更緊密,更關注的是單點的 AUC 精確度。
因此在粗排的設計上,更多的是做樣本的選擇與生成,和泛化特徵與網路的設計。而精排的設計可以做複雜的多階交叉特徵、超長序列建模等等。
前面介紹的是宏觀層面的,下面來看微觀層次。
具體到模型的訓練過程,目前業界主流的是使用超大規模的離散 DNN,泛化問題會是比較嚴重的。因為超大規模離散 DNN,透過 embedding 層,主要做的是記憶的功能。參見上圖,整個 embedding 空間是非常龐大的矩陣,通常都是千億或萬億行,1000 列。所以模型訓練都是全分散式,數十甚至上百台 GPU 做分散式訓練。
理論上,對於這麼大的矩陣,並不會直接做暴力計算,而是採用類似矩陣分解的操作。當然這個矩陣分解和標準的SVD 矩陣分解並不一樣,這裡的矩陣分解是先學到低維的表徵,透過slot 之間的parameter 的share 來降低計算跟存儲量,也就是分解成兩個矩陣的learning 的流程。首先是特徵、表徵矩陣,會學習特徵跟低維嵌入的關係,這個嵌入很低,通常會選擇十維左右的嵌入。另外一個是嵌入和神經元矩陣,每個槽位之間的權重是共享的。透過這種方式既降低了儲存量,又能夠提升效果。
低維度的嵌入學習是離線DNN 優化泛化能力的關鍵,它等價於做稀疏矩陣分解,因此,整個模型泛化能力提升的關鍵就在於如何使得參數規模與樣本數能夠更好地匹配。
從多個面向來進行最佳化:
業界通常是採用兩階段訓練抗過擬合的方式。整個模型由兩層組成,一個是很大的離散矩陣層,另一個是很小的稠密參數層。離散矩陣層是非常容易過度擬合的,所以業界實踐通常都是採用 One Pass Training,即 online learning,所有的數據都過一遍,並不會像學術界一樣的做 batch training。
另外,業界通常會利用時序 Validation Set 來解決稀疏層的 overfitting 問題。把整個訓練資料集依時間維度切割成很多 Delta,T0,T1,T2,T3 不同的 Delta。每次訓練是用前幾小時訓練好的離散參數層固定住,再用下一個 Delta 的資料 finetune dense 網路。也就是透過固定稀疏層、重訓其它參數的方式來緩和模型的過擬和問題。
這個做法也會帶來另一個問題,因為訓練是切分開的,每次都需要固定T0 時刻的離散參數,再用t 1 時刻重訓join階段,這樣會拖累整個訓練速度,帶來擴展性方面的挑戰。所以近年來都是採用單階段訓練,即將離散表徵層與稠密網路層在一個 Delta 中同時更新。而單階段訓練也存在一個問題,因為整個模型除了 embedding 特徵之外,還有很多連續值特徵,這些連續值特徵會統計每個離散特徵的展現點擊情況,因此,可能帶來資料穿越的風險。所以在具體實踐時,第一步會先除掉統計量的特徵,第二步使得稠密網路與離散表徵一起訓練,使用單一階段的方式訓練。另外整個嵌入的長度,都是自動可伸縮的方式。透過這一系列方法,可以使得模型訓練提速 30% 左右。實踐表明,該方法過擬合程度很輕微,訓練跟測試的 AUC 的差距也都是 1/ 1000 或更低的程度。
##接下來介紹架構設計上的思考和經驗。
系統設計的核心原則是分治法。召回需要有多個通道,核心的目標是要提升召回率,以及召回資源的豐富程度。同時召回也要考慮探索跟利用的問題,是推薦效果的基礎保證。粗排做第一層的過濾,主要做輕量級點預估,承上啟下。精排通常是做重計算,也是做點預估,跟重排的關係非常緊密,通常會使用非常複雜的結構,也是業界研究的重點。重排是最後一層,重排是具體面對使用者的,決定了最終的展現序列,基於精排的結果考慮上下文然後來做複雜的序列預估,即 list wise 的排序。重排序需要考慮很多業務的約束,裡面有很多規則,包括打散、LCN、退場等等,是規則與模型雙重驅動的模組。
推薦系統各層的目標基本上一致,但是各層側重不太一樣。召回和粗排著重的是泛化以及回想率,精排著重的是單點 AUC 的精確度,重排著重的是整體序列最優。從數據來看,越靠近召回粗排,越泛化,越靠近精排重排,越要求精確度。越靠近召回來源,效能受限越嚴重,因為候選資源越多計算量越大。粗排只需要對齊精排是個誤區,粗排需要考慮與精排的一致性,但並不能只對齊精排。如果粗排什麼都不做,只是做對齊精排,會帶來非常嚴重的馬太效應。因為精排不是 ground truth,使用者的行為才是,需要學習好使用者行為,而不是學習精排,這是很重要的一點提示。
精排跟重排之間的關係是非常緊密的,早年重排是直接用精排的評分來做訓練的,一方面耦合很嚴重,另一方面直接使用精排打分來做訓練,很容易產生線上的波動。
百度鳳巢 CTR 3.0 精排跟重排聯合訓練項目,就非常巧妙地利用模型同時訓練避免打分耦合的問題。此專案將精排子網路的隱層及內部評分,都作為重排子網路的特徵,然後,將精排與重排子網路拆開,分別部署於各自模組。一方面可以很好地重複使用中間結果,不會出現評分耦合帶來的波動問題,同時對於重排的精度又會有百分位的提升。這也是當年百度最高獎的子項目之一。
另外,注意該專案並非ESSM,ESSM 是CTCVR 建模,是多目標建模,而CTR3.0 聯合訓練主要解決打分耦合和重排模型精度的問題。
此外,對召回和粗排做解耦合,因為新佇列加入進來,對於新佇列可能會不太公平。因此,提出了隨機遮罩的方式,即隨機 mask 掉一部分特徵,使得耦合度不會那麼強。
#最後再來看一下部署在線上的過程。模型參數規模都是千億到兆量級,目標也非常多,直接進行線上部署開銷是非常大的,不能只考慮效果,不考慮效能。有一種比較好的方式就是彈性計算,類似 Sparse MOE 的想法。
粗排連接了非常多的佇列,有數十個甚至數百個佇列。這些隊列對線上的價值(LTV)是不一樣的,由流量價值層來計算不同召回隊列對線上點擊時長的價值。其核心思想是召回隊列整體的貢獻度越大,越可以享受更複雜的計算。從而使得有限的算力能夠服務更高價值的流量。所以我們也沒有採用傳統的蒸餾的方式,而是採用類似 Sparse MOE 的想法來做彈性計算,即策略跟架構 co-design 的設計,使得不同的召回隊列能夠使用最適合的資源網絡進行計算。
眾所周知,現在已經進入LLM 大模型時代。百度對下一代基於 LLM 大語言模型的推薦系統的探索將會從三個面向展開。
第一方面是希望模型從基礎的預測升級到能夠做決策。例如經典的冷啟資源高效率探索,沉浸式序列推薦回饋,以及從搜尋到推薦的決策鍊等等重要的問題,都可以藉助大模型來進行決策。
第二方面是從判別到生成,現在整個模型都是判別式的,未來會探索生成式推薦的方式,例如自動生成推薦理由,對長尾資料基於prompt 來做資料自動增強,以及生成式的檢索模型。
第三方面是從黑盒到白盒,傳統做推薦系統,大家常說神經網路是煉金術,是黑盒的,是否有可能向白盒化方向探索,也是未來的重要工作之一。例如基於因果,探究使用者行為狀態遷移背後的原因,推薦公平性方面做更好的無偏估計,以及 Multi Task Machine Learning 的場景上能夠做更好的場景自適應。
以上がBaidu 仕分け技術の探求と応用の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。