一、推薦系統中的排序公式

首先，我們來探討排序公式在推薦系統中的重要地位。對于眼界廣闊的算法工程師來說，他們在各種大公司中的工作可能看起來像是在進行數據分析，或者進行開發，或者策略制定，但實際上他們所做的一切都是為了一件事——服務于最終的排序。這是因為，推薦系統的最終輸出就是排序結果。

無論是從事特征工程、模型訓練，還是推薦策略的人，又或是那些努力將業務理念融入推薦結果的人，他們所有的努力，都是為了將個性化的差異體現在最終的排序結果中。為了實現這個目標，必須依靠排序公式。排序公式是實現我們所有目標，并最終展現出推薦結果的關鍵。

由于排序公式在推薦系統中占據著核心地位，大公司對其的研究和迭代都非常深入且廣泛。排序公式主要包括兩種融合方式：序融合和值融合。

首先，序融合主要關注各個模型或其提供的特征以及給出的排序信號。這種方法只關注排名，而不關心其具體的數值。這樣做的優點是，由于我們直接在排名（rank）維度上進行排序和融合，這個過程已經擺脫了各個子模塊之間尺度的巨大差異影響。這種技術更適合處理那些最后只需要排名，而無法最后確定精確評分的推薦算法，如混排的場景。然而，這種方法的缺點是會丟失很多信息。

很多大公司也在做各種嘗試，有的公司以前可能主要迭代值融合的算法，但后來覺得不能減小方差或差異性，因此改為迭代序融合，嘗試了一段時間后又回到了迭代值融合。這兩種方法并沒有絕對的好與壞，需要結合業務需求選擇最佳的結合方式，或將二者組合使用。

接下來介紹序融合。序融合中最簡單最常見的是 rank product 方法，該方法引自遺傳算法，用于研究哪個基因最重要，之后很多融合算法都受到了生物信息學的啟發。在實際應用中，序融合的研究和使用數量更多。

值融合是直接對各個推薦子模塊的輸出值進行操作。這種方法的優點是易于理解和調整。調整時，可以清晰看到所調整的子模塊或公式部分如何影響結果范圍，如何產生作用，如何擠壓其它信號，以及如何改變整個融合分的均值。這些都可以通過離線或在線的方式預估。因此，值融合不僅易于實現，而且對于進行迭代的研究者而言，它降低了迭代的壓力，使得整個迭代過程變得更容易。但是，其缺點在于如果某些排序因子預估值分布是在 0.1，那么會導致融合效果不理想。

有些目標如觀看時長或打賞金額等，具有明確的物理含義，而它們本身的尺度(scale)差距非常大。在這種情況下，直接融合無法獲得良好的效果。因此，我們需要采用某種標準化方法或映射來解決這個問題。在數據來源相對統一，例如同一模型得到的不同預估值，或者尺度接近的情況下，值融合的方式會比較好，操作起來也更加簡單。

為了更好地理解推薦系統中的排序公式融合方式，我們應明確融合公式需要解決的問題以及應如何定義優秀的融合公式。在本文中，優良的融合公式應至少滿足以下基本要求：

• 一是具有區分度，因為融合公式融合了各種先驗信息、預估信號以及業務需求得到的綜合評分，若評分沒有區分度，那么排序機制將失效。
• 其次，我們需要最大限度地保留各排序因子的信息量，因為如果融合公式因設計問題而無法保留原始排序因子的信息，就等同于拋失了這個排序因子的信息。
• 最后一點，若排序公式過于復雜，如包含過多的超參數，這將增加人工調參的難度，使我們可能沉溺于局部最優而無法看清整體趨勢，為此，我們將在后續提供一些方法，以減少參數冗余，并更好地理解數據分布，從而更有效地進行參數調整。

在實際工作中，優化并非僅限于單一指標，實際上，優化過程中涉及到的因素或指標間既有可能同向優化，又有可能不相關或相互制約。因此，認識和處理好這些關系，對于推薦系統的優化具有重要意義。

二、業務夾角與多目標權衡

在實際工作中，調整模型參數的過程經常“牽一發而動全身”，某個業務的微調可能會對其他相關業務產生影響，這也使得參數優化過程中壓力倍增，要實現“帕累托優化”（在保障所有業務不受影響的同時，仍能取得收益）實際上是一項艱巨的任務，除非我們關注的指標集合相對較少。然而，在現實環境下，各業務方都有自己的需求，我們需要盡可能地滿足這些需求。因此，問題轉變為我們需要犧牲多少及何種業務來換取我們需要的指標，以及針對這些指標進行多少折算。總的來說，對于融合公式的迭代來說，這個權衡是必須要面對的問題。

在進行權衡時，我們需要基于兩種判斷：價值判斷和事實判斷。價值判斷來自于高層決策，例如公司策略決定大力發展短視頻或直播等，這種決策反映了公司的價值取向，并非我們可以主觀改變的。事實判斷則是一種客觀存在，例如即使我們決定將短視頻業務去置換直播業務的某種收益，但這兩項業務之間的置換難度是客觀存在的。為此，我們需要在多目標優化中盡可能感知到這種置換的難易度。這可以通過某種工具或調參方式來實現，使我們能夠發現業務間置換的實際難度。在制定多目標權衡設計框架時，我們需要同時考慮公司戰略的價值判斷和事實判斷，這是優化權衡的基本出發點。

以上介紹了調整推薦系統排序公式融合過程中面臨的挑戰和需要做出的決策。

三、排序公式離線尋參原理

下面要探討的問題是如何迭代排序公式，進而提升技術效能。對此，我們需要首先考慮為什么要進行離線迭代及其必要性。許多公司投入大量人力資源在調整排序公式上，算法工程師們可能需要投入大量精力在這樣的任務上。這是一項費時、費心、費力的工作，卻又非常必要。一旦參數調整成功，其效果將十分顯著。

那么，為什么我們會選擇離線調整參數呢？事實上，也有公司會選擇將強化學習接入到線上系統中，以實時學習和調整參數。然而，我們并沒有看到這種方法成為主流，原因主要有以下三點：

• 首先，我們很難確保線上調參的質量。由于線上調參實際上是在實時運行的系統中試錯，不能使用大規模流量進行廣范圍的搜索，因此無法有效覆蓋整個樣本空間。而且，由于這是一個實時交互的過程，結果具有很大的不確定性，且幾乎沒有試錯的空間。因此，使用強化學習在實時交互的環境中進行訓練是非常困難和緩慢的。
• 其次，線上調參的效率無法保證。在線上調參的過程中，我們無法保證系統能快速收斂。而且，由于系統狀態在不斷變化，無法預知系統的最終狀態。考慮到排序公式并無必要實時更新，如果將其視為實時模型，便意味著需要在現有的排序結果中嵌入自己的業務理念。由于排序公式的更新一般并不需要達到分鐘級，我們完全有條件進行離線調參。
• 最后，線上過程很難處理多目標優化問題。如前文所述，多目標優化需要同時考慮價值判斷和事實判斷，即需要同時考慮上層的業務需求和當前系統的實際狀態。在線上環境下難以實現這種優化，因為我們無法進行反復或交叉驗證。例如，我們無法獲取 A 置換 B、B 置換 C 等等所需的置換難度。而在離線環境下，由于其封閉性，我們可以測定各種置換的邊際效益和置換效果。

基于以上三個方面的考慮，我們提出了離線調整排序公式的優化路徑。

接下來介紹離線調參框架的基本原理。首先我們需要考慮要構造什么樣的融合公式，有些工程師可能傾向于加法公式，有些可能傾向于乘法公式，甚至可能有精心設計的、具有特定物理含義的公式，這種公式在廣告行業比較常見，還有一些復合公式，即基于某個公式輸出進行再次配置的公式，這種可以看作是一種樹狀結構的公式，可以寫成 JSON 格式，這也是一種融合公式。

我們首先需要考慮要迭代的公式是什么形式，一旦確定了這個，我們就可以知道有多少超參數需要進行迭代。實際上，迭代公式就是迭代超參數，我們希望知道在新的公式形式下，這些超參數被調整到什么樣子，線上的某些指標將如何變化，這是我們要解答的問題。確定了融合公式的形式后，就可以開始收集離線樣本了。

在收集離線樣本時，需要考慮關注哪些指標，比如點擊率、觀看時長、分享數、打賞數等。這是在每次迭代時都要明確定義的。對于這些目標，我們會定義自己的計算方式。例如，對于離散變量點擊或未點擊，可以使用 AUC 來衡量。對于連續變量，例如觀看時長，可以進行分桶或使用其他評估方法來進行度量。因此，第二步就是確定希望優化的目標，并決定怎么計算。

確定了離線目標后，就要考慮如何將這些目標進行融合，這就涉及到我們剛剛討論的多目標融合，即價值判斷和事實判斷。你可能認為點擊的 AUC 和分享的 AUC 同樣重要，那么在我們優化的目標中，這兩個指標的權重就可以設為 1:1。這就是價值判斷部分。事實判斷部分就是，當我們完成了離線尋參，我們一定會發現有些指標降不下去，有些很容易改進。根據這個認知更新，我們需要調整我們的優化目標設計。這就是事實判斷部分。

根據我們定義的結果合并方法及子目標的方法，可以使用算法工具，比如 Optuna 進行尋優。這就是我們進行 sorted top-K prediction 問題中的求解方法。

綜上所述，離線調參框架至少需要四個功能：確定融合公式、評估子目標、融合子目標，還需要有一個優化器來求解。這就是我們從技術角度拆解的離線調參框架。

四、融合排序量化尋參實戰

接下來介紹一款業界廣泛使用的開源框架——ParaDance（項目鏈接：https://github.com/yinsn/ParaDance），該框架由我個人開發。這是一款開箱即用的、全自動的排序公式迭代框架。該框架在 Linux 和 Mac 上都可以通過 pip 工具進行安裝。

ParaDance 是一個開源項目，主要在業余時間進行開發和維護。因此，如果你對此感興趣，也可以貢獻你的代碼。該框架的特點在于其開箱即用的特性，它非常適合一線算法工程師進行排序公式的調整。其次，它支持離線計算，并且已實現并行處理，可以很快地運行。

由于得到了許多同行的幫助和建議，ParaDance 已經具備了豐富的評估手段，不僅支持如 AUC 這樣的評估方式，也支持其他各種子目標的計算方式。此外，它還支持豐富的公式形式，不僅僅是加法和乘法公式，你甚至可以將自己想要的公式以 JSON 的形式傳入，ParaDance 可以很好地支持這些操作。

此外，ParaDance 提供全程監控功能，可以監控每個子目標和綜合目標在迭代過程中的變化情況，讓你一目了然地知道哪些指標有明顯的改進，哪些指標難以迭代等信息。安裝了該庫后，我們就可以著手準備離線數據了。

例如，這里我們模擬了一些數據，包括四種類型的 XTR（XTR 0 到 XTR 3），并關注了“點擊”和“分享”兩種子目標。我們更關注“點擊”這個目標，認為它比“分享”更重要，這是由實際經驗和業務需求所決定的。如果我們決定按照這種方式進行調參，那么就需要收集相應的離線數據。這種基礎設施在各公司應該都已經存在。只需對離線數據進行采集和均勻采樣，這是非常容易實現的。根據經驗，大約需要幾百萬條數據，才能獲取到一個相對穩定的調參狀態。

然后，我們要進行的第一步是確定融合公式的形式。實際上，很多公司在加法公式和乘法公式之間反復調試。為了方便大家使用，這里還支持了一種稱為"freestyle"的類型，可以在其中任意編寫各種形式的公式，甚至支持函數類型推導，還可以在其中加入條件語句等。甚至，還支持一種非常復雜的形式，即直接傳入一個 JSON 來定義你的融合公式。對于那些有幾千行的復雜公式都能夠支持。無論你想調整公式中的一部分，還是整體，我們的框架都能夠支持。確定了融合公式的形式后，我們就可以開始構造我們的融合公式了。

代碼實現上，首先選擇了四個排序因子作為考慮對象，并使用融合公式進行組合。在這個例子中，采用了"freestyle"形式的融合公式，該公式具有一定的邏輯意義和物理解釋。例如，“weight”乘以緊隨其后的兩個排序因子（即，"columns 1"和"columns 2"），它們恰是對應的排序因子。這個公式是根據實際情況、專業知識和經驗判斷定義的，代表著預期公式應該是什么樣的形式。

在框架中，根據確定的公式形式，會評估并挑選出最佳的公式組合。例如，在這個場景中，公式形式為“freestyle”，目前有四個超參數需要調整，即 weights[0] 到 weights[3]，共計四個超參數。迭代完成后，框架會給出最佳的參數組合，從而使公式達到預期的效果。

此后，將離線數據傳遞給模型，指定所需的排序因子，并指定融合公式的類型和形式，這些都是事先定義好的。這是在確定融合公式形式后的必要步驟，且其代碼實現極其直接。

此外，還需要確定子目標的評估方式以及融合方式。前述中提到的"點擊"和"分享" 是分別作為子目標進行考慮的，對于如何評估這些子目標需要提前確定。例如，對于"點擊"這一指標，可以采用 AUC（Area under the ROC Curve，ROC 曲線下的面積）進行評估。值得注意的是評估方式可以多種多樣，AUC 只是其中一種相對易于接受和理解的評估方式。然后就是確定子目標之間的融合方式，即如何設定綜合目標的計算公式。

一個業務決策的例子是，我們可能認為"點擊"指標的 AUC 更重要，因此我們給它賦予更大的權重。在這種情況下，我們可能會將其權重設為 2，這個決定完全來自于我們的業務洞察，如老板覺得"點擊"指標是其他指標重要性的兩倍。這將作為我們的初始設定。然后我們創建一個多目標優化器對象，其中包含剛剛創建的融合公式和我們希望優化的目標方向。如這里我們設置了"maximum"，表示我們希望 AUC 盡可能大。然后，我們將融合目標輸入，設定所需的超參數數量，這些都可以有默認值。如果有具體需求，我們可以為每個超參數設置精確的范圍，如大于 0、小于 1；大于 -1、小于10；大于 1、小于 100；大于 -1、小于 50 等，都可以自由設定。

另外，"study name"選項會生成一個包含所有結果的文件夾。這有助于我們準確了解每次實驗的內容，尤其是當我們在一天中進行多次嘗試的時候，很容易混淆每次實驗的目標和結果。因此，我們提供了一個便利的命名功能，可為你的實驗記錄添加具體描述。

在定義了融合公式和目標后，剩下的代碼實現就僅有一行，即"run"。"run"后的參數設定了循環的次數，這里設置了 300 次。實際的輪次可能根據具體的問題和難度有所不同，但是通常幾百次的迭代就已足夠使得結果收斂。這是因為排序公式也有自身的容量限制，不能無限地優化一個指標。

代碼運行結束后會輸出一個文件夾，第一個輸出的文件是我們這個實驗的配置信息。第二個文件 paradance_best_trials.csv 中記錄了它優化的過程，包括兩個子目標的優化過程，以及每一個超參對于每一個非列解等于多少，一般情況下是取最后一行，即最好的一組參數進行使用。文件 paradance_storage.db 和 paradance.log 分別是 check_point 和完整的迭代記錄。

*可通過以下鏈接獲取示例數據和代碼：

https://pan.baidu.com/s/1AI9MkYhiJwd182gmtHL7fQ?pwd=1234

五、Q&A

Q1：離線評估如何構建樣本數據？有些候選集在線上的排序方式可能壓根沒有下發，沒有這部分候選集的后驗數據如何保障離線評估是否準確的呢？

A1：你提出的問題非常重要。我們目前的方式的確必須需要有落盤的數據。如果沒有落盤的數據，這部分數據就被視為缺失，在離線環境下確實無法解決。離線評估是分階段的，因為我們的排序也是從召回一直到最后重排，中間經歷了多個階段。實際上，離線數據采集的越靠近真正曝光的環節，這段數據空間對我們的公式的要求越接近，線上線下一致性效果越好。但如果數據完全偏離，沒有落盤，確實無法進行離線評估。

Q2：readme 文件上缺少使用的文檔和示例，這是因為何原因？

A2：readme 文件已經非常久沒更新了，我們有自己的內部文檔和示例庫，這些無法對外公布。如果你在使用過程中遇到具體問題，可以直接找到我，我們有相關的用戶群，提供一些共享數據和示例，但我目前沒有太多精力去更新 readme 文檔。

Q3：如何處理多樣性的流行度高的商品問題，也就是說可能有些商品在多個目標上的得分都很高？

A3：我們可以直接設計一個多樣性的評估算子，在收盤的時候進行約束。實際上任何想法都可以轉化為算子，然后在迭代過程中進行約束。多樣性也不例外，你可以用熵或者基尼系數作為它的約束算子。

Q4：不同的用戶可能有不同的個性化需求，但離線尋參對所有用戶都是一樣的，你們有對這點進行比較嗎？

A4：我們的總體情況并不是對所有用戶一樣。我們的算子支持 group by 方法，這樣就可以以用戶為單位進行聚類，實現千人千面。