文章作者：薛海霞 網易傳媒
編輯整理：鄭智獻
內容來源：DataFun AI Talk
出品社區：DataFun
注：歡迎轉載，轉載請註明出處
大家好，今天分享的主題是：網易新聞客戶端信息流的個性化推薦中，深度學習排序系統及模型，這也是我們團隊在研發實踐中的一些經驗總結。
首先看一下在信息流場景中，個性化推薦的產品形態。左邊是網易新聞的頭條頻道，右邊是短視頻頻道，在經過召回、排序、重排之後信息流的最終呈現。作為流量較大的兩個頻道，我們在對它構建排序系統和排序模型的時候，通常會根據文章、視頻、圖像相關的內容特徵，用戶畫像，場景，關注關係等對內容候選集進行排序。接下來，問題來了，如何衡量排序的效果呢？線上優化指標通常包括：CTR、閱讀時長、留存、刷新次數等，其中最容易建模的就是點擊率了，如果要用一個範式進行表示，就是圖中這個概率公式。
文章作者：薛海霞 網易傳媒
編輯整理：鄭智獻
內容來源：DataFun AI Talk
出品社區：DataFun
注：歡迎轉載，轉載請註明出處
大家好，今天分享的主題是：網易新聞客戶端信息流的個性化推薦中，深度學習排序系統及模型，這也是我們團隊在研發實踐中的一些經驗總結。
首先看一下在信息流場景中，個性化推薦的產品形態。左邊是網易新聞的頭條頻道，右邊是短視頻頻道，在經過召回、排序、重排之後信息流的最終呈現。作為流量較大的兩個頻道，我們在對它構建排序系統和排序模型的時候，通常會根據文章、視頻、圖像相關的內容特徵，用戶畫像，場景，關注關係等對內容候選集進行排序。接下來，問題來了，如何衡量排序的效果呢？線上優化指標通常包括：CTR、閱讀時長、留存、刷新次數等，其中最容易建模的就是點擊率了，如果要用一個範式進行表示，就是圖中這個概率公式。
接下來考慮一個問題，當面臨一個具體的推薦業務場景時，如何高效地構建排序系統和排序模型？
一般來說，排序系統由三部分構成：pipeline、排序模型、模型計算服務。
線下階段，pipeline 將客戶端傳過來的實時反饋日誌，按照不同 session 進行聚合，曝光和點擊數據進行 label match，然後經過特徵填充生成原始樣本，接著特徵預處理後，生成用於模型訓練所需的訓練樣本。線上階段的 pipeline 跟線下基本相同，不同之處在於各自依賴的上游數據源，一個來自客戶端的實時反饋，一個來自召回請求及預測候選集。
下圖為排序系統的基本流程。然而，在具體實踐中，處於對各模塊的計算平臺、流程一致性、組件通用性以及模型訓練性能等各方面的考慮，我們需要對這個 basic 的排序系統做對應的改造。而我們的改造主要集中在兩塊：特徵預處理 & 模型。
文章作者：薛海霞 網易傳媒
編輯整理：鄭智獻
內容來源：DataFun AI Talk
出品社區：DataFun
注：歡迎轉載，轉載請註明出處
大家好，今天分享的主題是：網易新聞客戶端信息流的個性化推薦中，深度學習排序系統及模型，這也是我們團隊在研發實踐中的一些經驗總結。
首先看一下在信息流場景中，個性化推薦的產品形態。左邊是網易新聞的頭條頻道，右邊是短視頻頻道，在經過召回、排序、重排之後信息流的最終呈現。作為流量較大的兩個頻道，我們在對它構建排序系統和排序模型的時候，通常會根據文章、視頻、圖像相關的內容特徵，用戶畫像，場景，關注關係等對內容候選集進行排序。接下來，問題來了，如何衡量排序的效果呢？線上優化指標通常包括：CTR、閱讀時長、留存、刷新次數等，其中最容易建模的就是點擊率了，如果要用一個範式進行表示，就是圖中這個概率公式。
接下來考慮一個問題，當面臨一個具體的推薦業務場景時，如何高效地構建排序系統和排序模型？
一般來說，排序系統由三部分構成：pipeline、排序模型、模型計算服務。
線下階段，pipeline 將客戶端傳過來的實時反饋日誌，按照不同 session 進行聚合，曝光和點擊數據進行 label match，然後經過特徵填充生成原始樣本，接著特徵預處理後，生成用於模型訓練所需的訓練樣本。線上階段的 pipeline 跟線下基本相同，不同之處在於各自依賴的上游數據源，一個來自客戶端的實時反饋，一個來自召回請求及預測候選集。
下圖為排序系統的基本流程。然而，在具體實踐中，處於對各模塊的計算平臺、流程一致性、組件通用性以及模型訓練性能等各方面的考慮，我們需要對這個 basic 的排序系統做對應的改造。而我們的改造主要集中在兩塊：特徵預處理 & 模型。
為什麼要對基礎流程進行改造以及具體如何改造？這裡需要了解一下整個排序系統研發過程中我們所面臨的核心問題和挑戰。
首先關於 pipeline，我們知道，排序模型在訓練和預測之間的差異會對模型的準確性產生很大的影響。而差異的產生來源於：特徵、特徵處理。只有保證 pipeline 線上線下的一致性，才能保證線上模型能夠得出正確的預測結果。特徵方面，我們將進行在線預測時的特徵保存下來，然後填充到線下的訓練樣本中，這樣就保證了訓練和預測階段的特徵是一致的；特徵處理方面，實踐中一般採用 tf.data 和 feature_column 進行讀取樣本數據和特徵處理，這種做法雖然避免了線上線下一致性的問題，但是這種基於原生 TensorFlow 的實現也帶來了線上計算和線下訓練的性能問題。如何在特徵處理模塊即保證線上線下的一致性又能同時保障系統整體的性能，這是我們所面臨的一個挑戰。
然後對於深度學習排序模型，我們需要支持網易新聞不斷增多的業務需求，這就要求排序模型框架有足夠的通用性和可擴展性，以支持模型的快速迭代和遷移。同時要求模型有足夠好的靈活性，以支持業務定製化。
文章作者：薛海霞 網易傳媒
編輯整理：鄭智獻
內容來源：DataFun AI Talk
出品社區：DataFun
注：歡迎轉載，轉載請註明出處
大家好，今天分享的主題是：網易新聞客戶端信息流的個性化推薦中，深度學習排序系統及模型，這也是我們團隊在研發實踐中的一些經驗總結。
首先看一下在信息流場景中，個性化推薦的產品形態。左邊是網易新聞的頭條頻道，右邊是短視頻頻道，在經過召回、排序、重排之後信息流的最終呈現。作為流量較大的兩個頻道，我們在對它構建排序系統和排序模型的時候，通常會根據文章、視頻、圖像相關的內容特徵，用戶畫像，場景，關注關係等對內容候選集進行排序。接下來，問題來了，如何衡量排序的效果呢？線上優化指標通常包括：CTR、閱讀時長、留存、刷新次數等，其中最容易建模的就是點擊率了，如果要用一個範式進行表示，就是圖中這個概率公式。
接下來考慮一個問題，當面臨一個具體的推薦業務場景時，如何高效地構建排序系統和排序模型？
一般來說，排序系統由三部分構成：pipeline、排序模型、模型計算服務。
線下階段，pipeline 將客戶端傳過來的實時反饋日誌，按照不同 session 進行聚合，曝光和點擊數據進行 label match，然後經過特徵填充生成原始樣本，接著特徵預處理後，生成用於模型訓練所需的訓練樣本。線上階段的 pipeline 跟線下基本相同，不同之處在於各自依賴的上游數據源，一個來自客戶端的實時反饋，一個來自召回請求及預測候選集。
下圖為排序系統的基本流程。然而，在具體實踐中，處於對各模塊的計算平臺、流程一致性、組件通用性以及模型訓練性能等各方面的考慮，我們需要對這個 basic 的排序系統做對應的改造。而我們的改造主要集中在兩塊：特徵預處理 & 模型。
為什麼要對基礎流程進行改造以及具體如何改造？這裡需要了解一下整個排序系統研發過程中我們所面臨的核心問題和挑戰。
首先關於 pipeline，我們知道，排序模型在訓練和預測之間的差異會對模型的準確性產生很大的影響。而差異的產生來源於：特徵、特徵處理。只有保證 pipeline 線上線下的一致性，才能保證線上模型能夠得出正確的預測結果。特徵方面，我們將進行在線預測時的特徵保存下來，然後填充到線下的訓練樣本中，這樣就保證了訓練和預測階段的特徵是一致的；特徵處理方面，實踐中一般採用 tf.data 和 feature_column 進行讀取樣本數據和特徵處理，這種做法雖然避免了線上線下一致性的問題，但是這種基於原生 TensorFlow 的實現也帶來了線上計算和線下訓練的性能問題。如何在特徵處理模塊即保證線上線下的一致性又能同時保障系統整體的性能，這是我們所面臨的一個挑戰。
然後對於深度學習排序模型，我們需要支持網易新聞不斷增多的業務需求，這就要求排序模型框架有足夠的通用性和可擴展性，以支持模型的快速迭代和遷移。同時要求模型有足夠好的靈活性，以支持業務定製化。
針對 pipeline 中的特徵處理模塊以及排序模型框架，我們做了如下優化：
首先特徵處理庫，將模型訓練階段跑在 CPU 上的特徵處理任務轉移到 pipeline 階段的大規模計算集群上 ( Haddop Streaming )，以免影響模型訓練階段對 GPU 計算的影響，同時也避免了訓練階段的重複計算。基於這樣的思想，我們將特徵處理庫從模型中獨立出來，線下階段在 pipeline 中而非模型中調用此庫，線上階段在模型中調用此庫，但是這樣會帶來線上線下不一致的問題。我們的解決方案是將特徵處理庫獨立出來之後，線上和線下調用對應的我們自定義 OP ( 樣本讀取和數據處理模塊 ) 即可。
關於自定義 OP，我們主要對樣本讀取和數據處理模塊進行了對應的改造。原生 TensorFlow 通常使用 tf.data 進行數據讀取，通過 feature_column 進行數據預處理，但是在大規模數據場景中，存在性能瓶頸，因此我們重新實現了數據讀取和預處理模塊，並優化了性能；另外，為了支持多值帶權的特徵，我們使用了自定義的樣本格式，而原生接口對樣本格式的解析也並不友好，所以自定義瞭解析模塊；或者想要手動融合一些操作或 TensorFlow 原生不支持的一些操作，也需要我們通過自定義 OP 來實現。
文章作者：薛海霞 網易傳媒
編輯整理：鄭智獻
內容來源：DataFun AI Talk
出品社區：DataFun
注：歡迎轉載，轉載請註明出處
大家好，今天分享的主題是：網易新聞客戶端信息流的個性化推薦中，深度學習排序系統及模型，這也是我們團隊在研發實踐中的一些經驗總結。
首先看一下在信息流場景中，個性化推薦的產品形態。左邊是網易新聞的頭條頻道，右邊是短視頻頻道，在經過召回、排序、重排之後信息流的最終呈現。作為流量較大的兩個頻道，我們在對它構建排序系統和排序模型的時候，通常會根據文章、視頻、圖像相關的內容特徵，用戶畫像，場景，關注關係等對內容候選集進行排序。接下來，問題來了，如何衡量排序的效果呢？線上優化指標通常包括：CTR、閱讀時長、留存、刷新次數等，其中最容易建模的就是點擊率了，如果要用一個範式進行表示，就是圖中這個概率公式。
接下來考慮一個問題，當面臨一個具體的推薦業務場景時，如何高效地構建排序系統和排序模型？
一般來說，排序系統由三部分構成：pipeline、排序模型、模型計算服務。
線下階段，pipeline 將客戶端傳過來的實時反饋日誌，按照不同 session 進行聚合，曝光和點擊數據進行 label match，然後經過特徵填充生成原始樣本，接著特徵預處理後，生成用於模型訓練所需的訓練樣本。線上階段的 pipeline 跟線下基本相同，不同之處在於各自依賴的上游數據源，一個來自客戶端的實時反饋，一個來自召回請求及預測候選集。
下圖為排序系統的基本流程。然而，在具體實踐中，處於對各模塊的計算平臺、流程一致性、組件通用性以及模型訓練性能等各方面的考慮，我們需要對這個 basic 的排序系統做對應的改造。而我們的改造主要集中在兩塊：特徵預處理 & 模型。
為什麼要對基礎流程進行改造以及具體如何改造？這裡需要了解一下整個排序系統研發過程中我們所面臨的核心問題和挑戰。
首先關於 pipeline，我們知道，排序模型在訓練和預測之間的差異會對模型的準確性產生很大的影響。而差異的產生來源於：特徵、特徵處理。只有保證 pipeline 線上線下的一致性，才能保證線上模型能夠得出正確的預測結果。特徵方面，我們將進行在線預測時的特徵保存下來，然後填充到線下的訓練樣本中，這樣就保證了訓練和預測階段的特徵是一致的；特徵處理方面，實踐中一般採用 tf.data 和 feature_column 進行讀取樣本數據和特徵處理，這種做法雖然避免了線上線下一致性的問題，但是這種基於原生 TensorFlow 的實現也帶來了線上計算和線下訓練的性能問題。如何在特徵處理模塊即保證線上線下的一致性又能同時保障系統整體的性能，這是我們所面臨的一個挑戰。
然後對於深度學習排序模型，我們需要支持網易新聞不斷增多的業務需求，這就要求排序模型框架有足夠的通用性和可擴展性，以支持模型的快速迭代和遷移。同時要求模型有足夠好的靈活性，以支持業務定製化。
針對 pipeline 中的特徵處理模塊以及排序模型框架，我們做了如下優化：
首先特徵處理庫，將模型訓練階段跑在 CPU 上的特徵處理任務轉移到 pipeline 階段的大規模計算集群上 ( Haddop Streaming )，以免影響模型訓練階段對 GPU 計算的影響，同時也避免了訓練階段的重複計算。基於這樣的思想，我們將特徵處理庫從模型中獨立出來，線下階段在 pipeline 中而非模型中調用此庫，線上階段在模型中調用此庫，但是這樣會帶來線上線下不一致的問題。我們的解決方案是將特徵處理庫獨立出來之後，線上和線下調用對應的我們自定義 OP ( 樣本讀取和數據處理模塊 ) 即可。
關於自定義 OP，我們主要對樣本讀取和數據處理模塊進行了對應的改造。原生 TensorFlow 通常使用 tf.data 進行數據讀取，通過 feature_column 進行數據預處理，但是在大規模數據場景中，存在性能瓶頸，因此我們重新實現了數據讀取和預處理模塊，並優化了性能；另外，為了支持多值帶權的特徵，我們使用了自定義的樣本格式，而原生接口對樣本格式的解析也並不友好，所以自定義瞭解析模塊；或者想要手動融合一些操作或 TensorFlow 原生不支持的一些操作，也需要我們通過自定義 OP 來實現。
完成 pipeline 的底層改造之後，如何快速使用特徵處理框架呢？很簡單，在配置文件中將特徵處理流程描述出來即可。
在配置文件中，對於每個特徵，描述它對應的特徵處理流程。如下圖，圓形代表原始特徵值和經過各個算子處理後的特徵中間值，方形表示特徵處理庫內的算子，所以特徵處理流程可以視為各個 DAG 圖。右邊的兩個例子是用 DAG 圖來描述特徵處理流程的相關配置。
1）特徵 age，先經過校正算子（將上游傳入為0的 age 特徵字段校正為 Null）得到中間值 age_corrected，再經過算子 CDF 或者 Bucket 處理得到可以作為模型輸入的特徵值 age_cdf 和 age_bucket。
2）特徵 Doc_POI 和 User_POI，經過算子 StrToVec 處理之後再經過相似度算子，得到二者的相似度。
以上經過一系列算子處理後的特徵將作為排序模型的輸入。若在訓練樣本中增加特徵，只需要在特徵處理框架中實現對應的算子，並在配置文件來描述新增特徵的處理流程。
我們使用 DAG 圖來描述特徵處理過程的思想，源自於 TensorFlow，先實現底層算子 API，然後將對特徵的處理流程構建 Graph，再通過上層 API 接口 session.run 啟動運行 Graph。而解析配置文件的過程就相當於解析 DAG 圖。
文章作者：薛海霞 網易傳媒
編輯整理：鄭智獻
內容來源：DataFun AI Talk
出品社區：DataFun
注：歡迎轉載，轉載請註明出處
大家好，今天分享的主題是：網易新聞客戶端信息流的個性化推薦中，深度學習排序系統及模型，這也是我們團隊在研發實踐中的一些經驗總結。
首先看一下在信息流場景中，個性化推薦的產品形態。左邊是網易新聞的頭條頻道，右邊是短視頻頻道，在經過召回、排序、重排之後信息流的最終呈現。作為流量較大的兩個頻道，我們在對它構建排序系統和排序模型的時候，通常會根據文章、視頻、圖像相關的內容特徵，用戶畫像，場景，關注關係等對內容候選集進行排序。接下來，問題來了，如何衡量排序的效果呢？線上優化指標通常包括：CTR、閱讀時長、留存、刷新次數等，其中最容易建模的就是點擊率了，如果要用一個範式進行表示，就是圖中這個概率公式。
接下來考慮一個問題，當面臨一個具體的推薦業務場景時，如何高效地構建排序系統和排序模型？
一般來說，排序系統由三部分構成：pipeline、排序模型、模型計算服務。
線下階段，pipeline 將客戶端傳過來的實時反饋日誌，按照不同 session 進行聚合，曝光和點擊數據進行 label match，然後經過特徵填充生成原始樣本，接著特徵預處理後，生成用於模型訓練所需的訓練樣本。線上階段的 pipeline 跟線下基本相同，不同之處在於各自依賴的上游數據源，一個來自客戶端的實時反饋，一個來自召回請求及預測候選集。
下圖為排序系統的基本流程。然而，在具體實踐中，處於對各模塊的計算平臺、流程一致性、組件通用性以及模型訓練性能等各方面的考慮，我們需要對這個 basic 的排序系統做對應的改造。而我們的改造主要集中在兩塊：特徵預處理 & 模型。
為什麼要對基礎流程進行改造以及具體如何改造？這裡需要了解一下整個排序系統研發過程中我們所面臨的核心問題和挑戰。
首先關於 pipeline，我們知道，排序模型在訓練和預測之間的差異會對模型的準確性產生很大的影響。而差異的產生來源於：特徵、特徵處理。只有保證 pipeline 線上線下的一致性，才能保證線上模型能夠得出正確的預測結果。特徵方面，我們將進行在線預測時的特徵保存下來，然後填充到線下的訓練樣本中，這樣就保證了訓練和預測階段的特徵是一致的；特徵處理方面，實踐中一般採用 tf.data 和 feature_column 進行讀取樣本數據和特徵處理，這種做法雖然避免了線上線下一致性的問題，但是這種基於原生 TensorFlow 的實現也帶來了線上計算和線下訓練的性能問題。如何在特徵處理模塊即保證線上線下的一致性又能同時保障系統整體的性能，這是我們所面臨的一個挑戰。
然後對於深度學習排序模型，我們需要支持網易新聞不斷增多的業務需求，這就要求排序模型框架有足夠的通用性和可擴展性，以支持模型的快速迭代和遷移。同時要求模型有足夠好的靈活性，以支持業務定製化。
針對 pipeline 中的特徵處理模塊以及排序模型框架，我們做了如下優化：
首先特徵處理庫，將模型訓練階段跑在 CPU 上的特徵處理任務轉移到 pipeline 階段的大規模計算集群上 ( Haddop Streaming )，以免影響模型訓練階段對 GPU 計算的影響，同時也避免了訓練階段的重複計算。基於這樣的思想，我們將特徵處理庫從模型中獨立出來，線下階段在 pipeline 中而非模型中調用此庫，線上階段在模型中調用此庫，但是這樣會帶來線上線下不一致的問題。我們的解決方案是將特徵處理庫獨立出來之後，線上和線下調用對應的我們自定義 OP ( 樣本讀取和數據處理模塊 ) 即可。
關於自定義 OP，我們主要對樣本讀取和數據處理模塊進行了對應的改造。原生 TensorFlow 通常使用 tf.data 進行數據讀取，通過 feature_column 進行數據預處理，但是在大規模數據場景中，存在性能瓶頸，因此我們重新實現了數據讀取和預處理模塊，並優化了性能；另外，為了支持多值帶權的特徵，我們使用了自定義的樣本格式，而原生接口對樣本格式的解析也並不友好，所以自定義瞭解析模塊；或者想要手動融合一些操作或 TensorFlow 原生不支持的一些操作，也需要我們通過自定義 OP 來實現。
完成 pipeline 的底層改造之後，如何快速使用特徵處理框架呢？很簡單，在配置文件中將特徵處理流程描述出來即可。
在配置文件中，對於每個特徵，描述它對應的特徵處理流程。如下圖，圓形代表原始特徵值和經過各個算子處理後的特徵中間值，方形表示特徵處理庫內的算子，所以特徵處理流程可以視為各個 DAG 圖。右邊的兩個例子是用 DAG 圖來描述特徵處理流程的相關配置。
1）特徵 age，先經過校正算子（將上游傳入為0的 age 特徵字段校正為 Null）得到中間值 age_corrected，再經過算子 CDF 或者 Bucket 處理得到可以作為模型輸入的特徵值 age_cdf 和 age_bucket。
2）特徵 Doc_POI 和 User_POI，經過算子 StrToVec 處理之後再經過相似度算子，得到二者的相似度。
以上經過一系列算子處理後的特徵將作為排序模型的輸入。若在訓練樣本中增加特徵，只需要在特徵處理框架中實現對應的算子，並在配置文件來描述新增特徵的處理流程。
我們使用 DAG 圖來描述特徵處理過程的思想，源自於 TensorFlow，先實現底層算子 API，然後將對特徵的處理流程構建 Graph，再通過上層 API 接口 session.run 啟動運行 Graph。而解析配置文件的過程就相當於解析 DAG 圖。
至此，完成 pipeline 的優化。回看一下，排序系統經過改造之後的模樣。排序系統變成由一個特徵處理框架進行特徵處理，而這個框架既可以跑在線下階段的 hadoop streaming 上，也可以跑在線上 TensorFlow 深度學習框架之上。
文章作者：薛海霞 網易傳媒
編輯整理：鄭智獻
內容來源：DataFun AI Talk
出品社區：DataFun
注：歡迎轉載，轉載請註明出處
大家好，今天分享的主題是：網易新聞客戶端信息流的個性化推薦中，深度學習排序系統及模型，這也是我們團隊在研發實踐中的一些經驗總結。
首先看一下在信息流場景中，個性化推薦的產品形態。左邊是網易新聞的頭條頻道，右邊是短視頻頻道，在經過召回、排序、重排之後信息流的最終呈現。作為流量較大的兩個頻道，我們在對它構建排序系統和排序模型的時候，通常會根據文章、視頻、圖像相關的內容特徵，用戶畫像，場景，關注關係等對內容候選集進行排序。接下來，問題來了，如何衡量排序的效果呢？線上優化指標通常包括：CTR、閱讀時長、留存、刷新次數等，其中最容易建模的就是點擊率了，如果要用一個範式進行表示，就是圖中這個概率公式。
接下來考慮一個問題，當面臨一個具體的推薦業務場景時，如何高效地構建排序系統和排序模型？
一般來說，排序系統由三部分構成：pipeline、排序模型、模型計算服務。
線下階段，pipeline 將客戶端傳過來的實時反饋日誌，按照不同 session 進行聚合，曝光和點擊數據進行 label match，然後經過特徵填充生成原始樣本，接著特徵預處理後，生成用於模型訓練所需的訓練樣本。線上階段的 pipeline 跟線下基本相同，不同之處在於各自依賴的上游數據源，一個來自客戶端的實時反饋，一個來自召回請求及預測候選集。
下圖為排序系統的基本流程。然而，在具體實踐中，處於對各模塊的計算平臺、流程一致性、組件通用性以及模型訓練性能等各方面的考慮，我們需要對這個 basic 的排序系統做對應的改造。而我們的改造主要集中在兩塊：特徵預處理 & 模型。
為什麼要對基礎流程進行改造以及具體如何改造？這裡需要了解一下整個排序系統研發過程中我們所面臨的核心問題和挑戰。
首先關於 pipeline，我們知道，排序模型在訓練和預測之間的差異會對模型的準確性產生很大的影響。而差異的產生來源於：特徵、特徵處理。只有保證 pipeline 線上線下的一致性，才能保證線上模型能夠得出正確的預測結果。特徵方面，我們將進行在線預測時的特徵保存下來，然後填充到線下的訓練樣本中，這樣就保證了訓練和預測階段的特徵是一致的；特徵處理方面，實踐中一般採用 tf.data 和 feature_column 進行讀取樣本數據和特徵處理，這種做法雖然避免了線上線下一致性的問題，但是這種基於原生 TensorFlow 的實現也帶來了線上計算和線下訓練的性能問題。如何在特徵處理模塊即保證線上線下的一致性又能同時保障系統整體的性能，這是我們所面臨的一個挑戰。
然後對於深度學習排序模型，我們需要支持網易新聞不斷增多的業務需求，這就要求排序模型框架有足夠的通用性和可擴展性，以支持模型的快速迭代和遷移。同時要求模型有足夠好的靈活性，以支持業務定製化。
針對 pipeline 中的特徵處理模塊以及排序模型框架，我們做了如下優化：
首先特徵處理庫，將模型訓練階段跑在 CPU 上的特徵處理任務轉移到 pipeline 階段的大規模計算集群上 ( Haddop Streaming )，以免影響模型訓練階段對 GPU 計算的影響，同時也避免了訓練階段的重複計算。基於這樣的思想，我們將特徵處理庫從模型中獨立出來，線下階段在 pipeline 中而非模型中調用此庫，線上階段在模型中調用此庫，但是這樣會帶來線上線下不一致的問題。我們的解決方案是將特徵處理庫獨立出來之後，線上和線下調用對應的我們自定義 OP ( 樣本讀取和數據處理模塊 ) 即可。
關於自定義 OP，我們主要對樣本讀取和數據處理模塊進行了對應的改造。原生 TensorFlow 通常使用 tf.data 進行數據讀取，通過 feature_column 進行數據預處理，但是在大規模數據場景中，存在性能瓶頸，因此我們重新實現了數據讀取和預處理模塊，並優化了性能；另外，為了支持多值帶權的特徵，我們使用了自定義的樣本格式，而原生接口對樣本格式的解析也並不友好，所以自定義瞭解析模塊；或者想要手動融合一些操作或 TensorFlow 原生不支持的一些操作，也需要我們通過自定義 OP 來實現。
完成 pipeline 的底層改造之後，如何快速使用特徵處理框架呢？很簡單，在配置文件中將特徵處理流程描述出來即可。
在配置文件中，對於每個特徵，描述它對應的特徵處理流程。如下圖，圓形代表原始特徵值和經過各個算子處理後的特徵中間值，方形表示特徵處理庫內的算子，所以特徵處理流程可以視為各個 DAG 圖。右邊的兩個例子是用 DAG 圖來描述特徵處理流程的相關配置。
1）特徵 age，先經過校正算子（將上游傳入為0的 age 特徵字段校正為 Null）得到中間值 age_corrected，再經過算子 CDF 或者 Bucket 處理得到可以作為模型輸入的特徵值 age_cdf 和 age_bucket。
2）特徵 Doc_POI 和 User_POI，經過算子 StrToVec 處理之後再經過相似度算子，得到二者的相似度。
以上經過一系列算子處理後的特徵將作為排序模型的輸入。若在訓練樣本中增加特徵，只需要在特徵處理框架中實現對應的算子，並在配置文件來描述新增特徵的處理流程。
我們使用 DAG 圖來描述特徵處理過程的思想，源自於 TensorFlow，先實現底層算子 API，然後將對特徵的處理流程構建 Graph，再通過上層 API 接口 session.run 啟動運行 Graph。而解析配置文件的過程就相當於解析 DAG 圖。
至此，完成 pipeline 的優化。回看一下，排序系統經過改造之後的模樣。排序系統變成由一個特徵處理框架進行特徵處理，而這個框架既可以跑在線下階段的 hadoop streaming 上，也可以跑在線上 TensorFlow 深度學習框架之上。
深度學習排序模型方面，同樣面臨一系列的問題。如何構建通用 & 可擴展的推薦算法庫框架，來支持新的業務場景，保證模型的快速迭代？如何保證框架的靈活性，根據變化的業務需求對模型做定製化？如何通過高度可配置的方式來構建模型？
文章作者：薛海霞 網易傳媒
編輯整理：鄭智獻
內容來源：DataFun AI Talk
出品社區：DataFun
注：歡迎轉載，轉載請註明出處
大家好，今天分享的主題是：網易新聞客戶端信息流的個性化推薦中，深度學習排序系統及模型，這也是我們團隊在研發實踐中的一些經驗總結。
首先看一下在信息流場景中，個性化推薦的產品形態。左邊是網易新聞的頭條頻道，右邊是短視頻頻道，在經過召回、排序、重排之後信息流的最終呈現。作為流量較大的兩個頻道，我們在對它構建排序系統和排序模型的時候，通常會根據文章、視頻、圖像相關的內容特徵，用戶畫像，場景，關注關係等對內容候選集進行排序。接下來，問題來了，如何衡量排序的效果呢？線上優化指標通常包括：CTR、閱讀時長、留存、刷新次數等，其中最容易建模的就是點擊率了，如果要用一個範式進行表示，就是圖中這個概率公式。
接下來考慮一個問題，當面臨一個具體的推薦業務場景時，如何高效地構建排序系統和排序模型？
一般來說，排序系統由三部分構成：pipeline、排序模型、模型計算服務。
線下階段，pipeline 將客戶端傳過來的實時反饋日誌，按照不同 session 進行聚合，曝光和點擊數據進行 label match，然後經過特徵填充生成原始樣本，接著特徵預處理後，生成用於模型訓練所需的訓練樣本。線上階段的 pipeline 跟線下基本相同，不同之處在於各自依賴的上游數據源，一個來自客戶端的實時反饋，一個來自召回請求及預測候選集。
下圖為排序系統的基本流程。然而，在具體實踐中，處於對各模塊的計算平臺、流程一致性、組件通用性以及模型訓練性能等各方面的考慮，我們需要對這個 basic 的排序系統做對應的改造。而我們的改造主要集中在兩塊：特徵預處理 & 模型。
為什麼要對基礎流程進行改造以及具體如何改造？這裡需要了解一下整個排序系統研發過程中我們所面臨的核心問題和挑戰。
首先關於 pipeline，我們知道，排序模型在訓練和預測之間的差異會對模型的準確性產生很大的影響。而差異的產生來源於：特徵、特徵處理。只有保證 pipeline 線上線下的一致性，才能保證線上模型能夠得出正確的預測結果。特徵方面，我們將進行在線預測時的特徵保存下來，然後填充到線下的訓練樣本中，這樣就保證了訓練和預測階段的特徵是一致的；特徵處理方面，實踐中一般採用 tf.data 和 feature_column 進行讀取樣本數據和特徵處理，這種做法雖然避免了線上線下一致性的問題，但是這種基於原生 TensorFlow 的實現也帶來了線上計算和線下訓練的性能問題。如何在特徵處理模塊即保證線上線下的一致性又能同時保障系統整體的性能，這是我們所面臨的一個挑戰。
然後對於深度學習排序模型，我們需要支持網易新聞不斷增多的業務需求，這就要求排序模型框架有足夠的通用性和可擴展性，以支持模型的快速迭代和遷移。同時要求模型有足夠好的靈活性，以支持業務定製化。
針對 pipeline 中的特徵處理模塊以及排序模型框架，我們做了如下優化：
首先特徵處理庫，將模型訓練階段跑在 CPU 上的特徵處理任務轉移到 pipeline 階段的大規模計算集群上 ( Haddop Streaming )，以免影響模型訓練階段對 GPU 計算的影響，同時也避免了訓練階段的重複計算。基於這樣的思想，我們將特徵處理庫從模型中獨立出來，線下階段在 pipeline 中而非模型中調用此庫，線上階段在模型中調用此庫，但是這樣會帶來線上線下不一致的問題。我們的解決方案是將特徵處理庫獨立出來之後，線上和線下調用對應的我們自定義 OP ( 樣本讀取和數據處理模塊 ) 即可。
關於自定義 OP，我們主要對樣本讀取和數據處理模塊進行了對應的改造。原生 TensorFlow 通常使用 tf.data 進行數據讀取，通過 feature_column 進行數據預處理，但是在大規模數據場景中，存在性能瓶頸，因此我們重新實現了數據讀取和預處理模塊，並優化了性能；另外，為了支持多值帶權的特徵，我們使用了自定義的樣本格式，而原生接口對樣本格式的解析也並不友好，所以自定義瞭解析模塊；或者想要手動融合一些操作或 TensorFlow 原生不支持的一些操作，也需要我們通過自定義 OP 來實現。
完成 pipeline 的底層改造之後，如何快速使用特徵處理框架呢？很簡單，在配置文件中將特徵處理流程描述出來即可。
在配置文件中，對於每個特徵，描述它對應的特徵處理流程。如下圖，圓形代表原始特徵值和經過各個算子處理後的特徵中間值，方形表示特徵處理庫內的算子，所以特徵處理流程可以視為各個 DAG 圖。右邊的兩個例子是用 DAG 圖來描述特徵處理流程的相關配置。
1）特徵 age，先經過校正算子（將上游傳入為0的 age 特徵字段校正為 Null）得到中間值 age_corrected，再經過算子 CDF 或者 Bucket 處理得到可以作為模型輸入的特徵值 age_cdf 和 age_bucket。
2）特徵 Doc_POI 和 User_POI，經過算子 StrToVec 處理之後再經過相似度算子，得到二者的相似度。
以上經過一系列算子處理後的特徵將作為排序模型的輸入。若在訓練樣本中增加特徵，只需要在特徵處理框架中實現對應的算子，並在配置文件來描述新增特徵的處理流程。
我們使用 DAG 圖來描述特徵處理過程的思想，源自於 TensorFlow，先實現底層算子 API，然後將對特徵的處理流程構建 Graph，再通過上層 API 接口 session.run 啟動運行 Graph。而解析配置文件的過程就相當於解析 DAG 圖。
至此，完成 pipeline 的優化。回看一下，排序系統經過改造之後的模樣。排序系統變成由一個特徵處理框架進行特徵處理，而這個框架既可以跑在線下階段的 hadoop streaming 上，也可以跑在線上 TensorFlow 深度學習框架之上。
深度學習排序模型方面，同樣面臨一系列的問題。如何構建通用 & 可擴展的推薦算法庫框架，來支持新的業務場景，保證模型的快速迭代？如何保證框架的靈活性，根據變化的業務需求對模型做定製化？如何通過高度可配置的方式來構建模型？
先看幾個經典的深度學習排序模型的網絡結構，左邊是 DNN，右邊為它的幾種變體：FNN、PNN、Wide&Deep。雖然4種模型結構各異，但抽象一下會發現共通之處，基本單元包括：linear、cross、deep 模塊，從層次結構來看包括: 特徵表徵層、特徵交叉層、全連接層，其中特徵交叉既可以通過人工方式 ( Wide 部分 ) 也可以通過內積或矩陣乘法的方式來進行。經過以上分析，其實提供了一種思路：我們可以將深度學習模型的各個基本單元進行模塊化來構建模型。
文章作者：薛海霞 網易傳媒
編輯整理：鄭智獻
內容來源：DataFun AI Talk
出品社區：DataFun
注：歡迎轉載，轉載請註明出處
大家好，今天分享的主題是：網易新聞客戶端信息流的個性化推薦中，深度學習排序系統及模型，這也是我們團隊在研發實踐中的一些經驗總結。
首先看一下在信息流場景中，個性化推薦的產品形態。左邊是網易新聞的頭條頻道，右邊是短視頻頻道，在經過召回、排序、重排之後信息流的最終呈現。作為流量較大的兩個頻道，我們在對它構建排序系統和排序模型的時候，通常會根據文章、視頻、圖像相關的內容特徵，用戶畫像，場景，關注關係等對內容候選集進行排序。接下來，問題來了，如何衡量排序的效果呢？線上優化指標通常包括：CTR、閱讀時長、留存、刷新次數等，其中最容易建模的就是點擊率了，如果要用一個範式進行表示，就是圖中這個概率公式。
接下來考慮一個問題，當面臨一個具體的推薦業務場景時，如何高效地構建排序系統和排序模型？
一般來說，排序系統由三部分構成：pipeline、排序模型、模型計算服務。
線下階段，pipeline 將客戶端傳過來的實時反饋日誌，按照不同 session 進行聚合，曝光和點擊數據進行 label match，然後經過特徵填充生成原始樣本，接著特徵預處理後，生成用於模型訓練所需的訓練樣本。線上階段的 pipeline 跟線下基本相同，不同之處在於各自依賴的上游數據源，一個來自客戶端的實時反饋，一個來自召回請求及預測候選集。
下圖為排序系統的基本流程。然而，在具體實踐中，處於對各模塊的計算平臺、流程一致性、組件通用性以及模型訓練性能等各方面的考慮，我們需要對這個 basic 的排序系統做對應的改造。而我們的改造主要集中在兩塊：特徵預處理 & 模型。
為什麼要對基礎流程進行改造以及具體如何改造？這裡需要了解一下整個排序系統研發過程中我們所面臨的核心問題和挑戰。
首先關於 pipeline，我們知道，排序模型在訓練和預測之間的差異會對模型的準確性產生很大的影響。而差異的產生來源於：特徵、特徵處理。只有保證 pipeline 線上線下的一致性，才能保證線上模型能夠得出正確的預測結果。特徵方面，我們將進行在線預測時的特徵保存下來，然後填充到線下的訓練樣本中，這樣就保證了訓練和預測階段的特徵是一致的；特徵處理方面，實踐中一般採用 tf.data 和 feature_column 進行讀取樣本數據和特徵處理，這種做法雖然避免了線上線下一致性的問題，但是這種基於原生 TensorFlow 的實現也帶來了線上計算和線下訓練的性能問題。如何在特徵處理模塊即保證線上線下的一致性又能同時保障系統整體的性能，這是我們所面臨的一個挑戰。
然後對於深度學習排序模型，我們需要支持網易新聞不斷增多的業務需求，這就要求排序模型框架有足夠的通用性和可擴展性，以支持模型的快速迭代和遷移。同時要求模型有足夠好的靈活性，以支持業務定製化。
針對 pipeline 中的特徵處理模塊以及排序模型框架，我們做了如下優化：
首先特徵處理庫，將模型訓練階段跑在 CPU 上的特徵處理任務轉移到 pipeline 階段的大規模計算集群上 ( Haddop Streaming )，以免影響模型訓練階段對 GPU 計算的影響，同時也避免了訓練階段的重複計算。基於這樣的思想，我們將特徵處理庫從模型中獨立出來，線下階段在 pipeline 中而非模型中調用此庫，線上階段在模型中調用此庫，但是這樣會帶來線上線下不一致的問題。我們的解決方案是將特徵處理庫獨立出來之後，線上和線下調用對應的我們自定義 OP ( 樣本讀取和數據處理模塊 ) 即可。
關於自定義 OP，我們主要對樣本讀取和數據處理模塊進行了對應的改造。原生 TensorFlow 通常使用 tf.data 進行數據讀取，通過 feature_column 進行數據預處理，但是在大規模數據場景中，存在性能瓶頸，因此我們重新實現了數據讀取和預處理模塊，並優化了性能；另外，為了支持多值帶權的特徵，我們使用了自定義的樣本格式，而原生接口對樣本格式的解析也並不友好，所以自定義瞭解析模塊；或者想要手動融合一些操作或 TensorFlow 原生不支持的一些操作，也需要我們通過自定義 OP 來實現。
完成 pipeline 的底層改造之後，如何快速使用特徵處理框架呢？很簡單，在配置文件中將特徵處理流程描述出來即可。
在配置文件中，對於每個特徵，描述它對應的特徵處理流程。如下圖，圓形代表原始特徵值和經過各個算子處理後的特徵中間值，方形表示特徵處理庫內的算子，所以特徵處理流程可以視為各個 DAG 圖。右邊的兩個例子是用 DAG 圖來描述特徵處理流程的相關配置。
1）特徵 age，先經過校正算子（將上游傳入為0的 age 特徵字段校正為 Null）得到中間值 age_corrected，再經過算子 CDF 或者 Bucket 處理得到可以作為模型輸入的特徵值 age_cdf 和 age_bucket。
2）特徵 Doc_POI 和 User_POI，經過算子 StrToVec 處理之後再經過相似度算子，得到二者的相似度。
以上經過一系列算子處理後的特徵將作為排序模型的輸入。若在訓練樣本中增加特徵，只需要在特徵處理框架中實現對應的算子，並在配置文件來描述新增特徵的處理流程。
我們使用 DAG 圖來描述特徵處理過程的思想，源自於 TensorFlow，先實現底層算子 API，然後將對特徵的處理流程構建 Graph，再通過上層 API 接口 session.run 啟動運行 Graph。而解析配置文件的過程就相當於解析 DAG 圖。
至此，完成 pipeline 的優化。回看一下，排序系統經過改造之後的模樣。排序系統變成由一個特徵處理框架進行特徵處理，而這個框架既可以跑在線下階段的 hadoop streaming 上，也可以跑在線上 TensorFlow 深度學習框架之上。
深度學習排序模型方面，同樣面臨一系列的問題。如何構建通用 & 可擴展的推薦算法庫框架，來支持新的業務場景，保證模型的快速迭代？如何保證框架的靈活性，根據變化的業務需求對模型做定製化？如何通過高度可配置的方式來構建模型？
先看幾個經典的深度學習排序模型的網絡結構，左邊是 DNN，右邊為它的幾種變體：FNN、PNN、Wide&Deep。雖然4種模型結構各異，但抽象一下會發現共通之處，基本單元包括：linear、cross、deep 模塊，從層次結構來看包括: 特徵表徵層、特徵交叉層、全連接層，其中特徵交叉既可以通過人工方式 ( Wide 部分 ) 也可以通過內積或矩陣乘法的方式來進行。經過以上分析，其實提供了一種思路：我們可以將深度學習模型的各個基本單元進行模塊化來構建模型。
沿著以上的抽象和分析，接下來用兩個網絡結構相對複雜的深度學習排序模型來進行驗證。
下圖左邊為 DCN ( Deep & Cross NetWork ) 模型，右邊為 DIEN ( Deep Interest Evolution Network )，可以觀察到，層次結構同上：特徵表徵層、特徵交叉層、全連接層，與上面不同的是：特徵交叉不再受限於人工交叉或各種方式的2階交叉，而是讓 NN 網絡去進行更高階的特徵交叉表達。網絡的基本單元仍然包括：linear、cross、deep。
文章作者：薛海霞 網易傳媒
編輯整理：鄭智獻
內容來源：DataFun AI Talk
出品社區：DataFun
注：歡迎轉載，轉載請註明出處
大家好，今天分享的主題是：網易新聞客戶端信息流的個性化推薦中，深度學習排序系統及模型，這也是我們團隊在研發實踐中的一些經驗總結。
首先看一下在信息流場景中，個性化推薦的產品形態。左邊是網易新聞的頭條頻道，右邊是短視頻頻道，在經過召回、排序、重排之後信息流的最終呈現。作為流量較大的兩個頻道，我們在對它構建排序系統和排序模型的時候，通常會根據文章、視頻、圖像相關的內容特徵，用戶畫像，場景，關注關係等對內容候選集進行排序。接下來，問題來了，如何衡量排序的效果呢？線上優化指標通常包括：CTR、閱讀時長、留存、刷新次數等，其中最容易建模的就是點擊率了，如果要用一個範式進行表示，就是圖中這個概率公式。
接下來考慮一個問題，當面臨一個具體的推薦業務場景時，如何高效地構建排序系統和排序模型？
一般來說，排序系統由三部分構成：pipeline、排序模型、模型計算服務。
線下階段，pipeline 將客戶端傳過來的實時反饋日誌，按照不同 session 進行聚合，曝光和點擊數據進行 label match，然後經過特徵填充生成原始樣本，接著特徵預處理後，生成用於模型訓練所需的訓練樣本。線上階段的 pipeline 跟線下基本相同，不同之處在於各自依賴的上游數據源，一個來自客戶端的實時反饋，一個來自召回請求及預測候選集。
下圖為排序系統的基本流程。然而，在具體實踐中，處於對各模塊的計算平臺、流程一致性、組件通用性以及模型訓練性能等各方面的考慮，我們需要對這個 basic 的排序系統做對應的改造。而我們的改造主要集中在兩塊：特徵預處理 & 模型。
為什麼要對基礎流程進行改造以及具體如何改造？這裡需要了解一下整個排序系統研發過程中我們所面臨的核心問題和挑戰。
首先關於 pipeline，我們知道，排序模型在訓練和預測之間的差異會對模型的準確性產生很大的影響。而差異的產生來源於：特徵、特徵處理。只有保證 pipeline 線上線下的一致性，才能保證線上模型能夠得出正確的預測結果。特徵方面，我們將進行在線預測時的特徵保存下來，然後填充到線下的訓練樣本中，這樣就保證了訓練和預測階段的特徵是一致的；特徵處理方面，實踐中一般採用 tf.data 和 feature_column 進行讀取樣本數據和特徵處理，這種做法雖然避免了線上線下一致性的問題，但是這種基於原生 TensorFlow 的實現也帶來了線上計算和線下訓練的性能問題。如何在特徵處理模塊即保證線上線下的一致性又能同時保障系統整體的性能，這是我們所面臨的一個挑戰。
然後對於深度學習排序模型，我們需要支持網易新聞不斷增多的業務需求，這就要求排序模型框架有足夠的通用性和可擴展性，以支持模型的快速迭代和遷移。同時要求模型有足夠好的靈活性，以支持業務定製化。
針對 pipeline 中的特徵處理模塊以及排序模型框架，我們做了如下優化：
首先特徵處理庫，將模型訓練階段跑在 CPU 上的特徵處理任務轉移到 pipeline 階段的大規模計算集群上 ( Haddop Streaming )，以免影響模型訓練階段對 GPU 計算的影響，同時也避免了訓練階段的重複計算。基於這樣的思想，我們將特徵處理庫從模型中獨立出來，線下階段在 pipeline 中而非模型中調用此庫，線上階段在模型中調用此庫，但是這樣會帶來線上線下不一致的問題。我們的解決方案是將特徵處理庫獨立出來之後，線上和線下調用對應的我們自定義 OP ( 樣本讀取和數據處理模塊 ) 即可。
關於自定義 OP，我們主要對樣本讀取和數據處理模塊進行了對應的改造。原生 TensorFlow 通常使用 tf.data 進行數據讀取，通過 feature_column 進行數據預處理，但是在大規模數據場景中，存在性能瓶頸，因此我們重新實現了數據讀取和預處理模塊，並優化了性能；另外，為了支持多值帶權的特徵，我們使用了自定義的樣本格式，而原生接口對樣本格式的解析也並不友好，所以自定義瞭解析模塊；或者想要手動融合一些操作或 TensorFlow 原生不支持的一些操作，也需要我們通過自定義 OP 來實現。
完成 pipeline 的底層改造之後，如何快速使用特徵處理框架呢？很簡單，在配置文件中將特徵處理流程描述出來即可。
在配置文件中，對於每個特徵，描述它對應的特徵處理流程。如下圖，圓形代表原始特徵值和經過各個算子處理後的特徵中間值，方形表示特徵處理庫內的算子，所以特徵處理流程可以視為各個 DAG 圖。右邊的兩個例子是用 DAG 圖來描述特徵處理流程的相關配置。
1）特徵 age，先經過校正算子（將上游傳入為0的 age 特徵字段校正為 Null）得到中間值 age_corrected，再經過算子 CDF 或者 Bucket 處理得到可以作為模型輸入的特徵值 age_cdf 和 age_bucket。
2）特徵 Doc_POI 和 User_POI，經過算子 StrToVec 處理之後再經過相似度算子，得到二者的相似度。
以上經過一系列算子處理後的特徵將作為排序模型的輸入。若在訓練樣本中增加特徵，只需要在特徵處理框架中實現對應的算子，並在配置文件來描述新增特徵的處理流程。
我們使用 DAG 圖來描述特徵處理過程的思想，源自於 TensorFlow，先實現底層算子 API，然後將對特徵的處理流程構建 Graph，再通過上層 API 接口 session.run 啟動運行 Graph。而解析配置文件的過程就相當於解析 DAG 圖。
至此，完成 pipeline 的優化。回看一下，排序系統經過改造之後的模樣。排序系統變成由一個特徵處理框架進行特徵處理，而這個框架既可以跑在線下階段的 hadoop streaming 上，也可以跑在線上 TensorFlow 深度學習框架之上。
深度學習排序模型方面，同樣面臨一系列的問題。如何構建通用 & 可擴展的推薦算法庫框架，來支持新的業務場景，保證模型的快速迭代？如何保證框架的靈活性，根據變化的業務需求對模型做定製化？如何通過高度可配置的方式來構建模型？
先看幾個經典的深度學習排序模型的網絡結構，左邊是 DNN，右邊為它的幾種變體：FNN、PNN、Wide&Deep。雖然4種模型結構各異，但抽象一下會發現共通之處，基本單元包括：linear、cross、deep 模塊，從層次結構來看包括: 特徵表徵層、特徵交叉層、全連接層，其中特徵交叉既可以通過人工方式 ( Wide 部分 ) 也可以通過內積或矩陣乘法的方式來進行。經過以上分析，其實提供了一種思路：我們可以將深度學習模型的各個基本單元進行模塊化來構建模型。
沿著以上的抽象和分析，接下來用兩個網絡結構相對複雜的深度學習排序模型來進行驗證。
下圖左邊為 DCN ( Deep & Cross NetWork ) 模型，右邊為 DIEN ( Deep Interest Evolution Network )，可以觀察到，層次結構同上：特徵表徵層、特徵交叉層、全連接層，與上面不同的是：特徵交叉不再受限於人工交叉或各種方式的2階交叉，而是讓 NN 網絡去進行更高階的特徵交叉表達。網絡的基本單元仍然包括：linear、cross、deep。
根據前面對幾種深度學習排序模型的網絡結構的分析，總結起來如下表所示：
輸入層到 Embedding 層，該過程把大規模的稀疏特徵通過 embedding 操作或其它表徵方式映射為低維稠密的 embedding 向量；對於生成的 embedding 向量，我們可以對它進行包括特徵交叉在內的其它各種操作，比如：concat、sum or average pooling 等操作，大部分排序模型改造主要集中在這一層；最後將經過各種處理之後的 embedding 向量輸入至全連接框架中。
文章作者：薛海霞 網易傳媒
編輯整理：鄭智獻
內容來源：DataFun AI Talk
出品社區：DataFun
注：歡迎轉載，轉載請註明出處
大家好，今天分享的主題是：網易新聞客戶端信息流的個性化推薦中，深度學習排序系統及模型，這也是我們團隊在研發實踐中的一些經驗總結。
首先看一下在信息流場景中，個性化推薦的產品形態。左邊是網易新聞的頭條頻道，右邊是短視頻頻道，在經過召回、排序、重排之後信息流的最終呈現。作為流量較大的兩個頻道，我們在對它構建排序系統和排序模型的時候，通常會根據文章、視頻、圖像相關的內容特徵，用戶畫像，場景，關注關係等對內容候選集進行排序。接下來，問題來了，如何衡量排序的效果呢？線上優化指標通常包括：CTR、閱讀時長、留存、刷新次數等，其中最容易建模的就是點擊率了，如果要用一個範式進行表示，就是圖中這個概率公式。
接下來考慮一個問題，當面臨一個具體的推薦業務場景時，如何高效地構建排序系統和排序模型？
一般來說，排序系統由三部分構成：pipeline、排序模型、模型計算服務。
線下階段，pipeline 將客戶端傳過來的實時反饋日誌，按照不同 session 進行聚合，曝光和點擊數據進行 label match，然後經過特徵填充生成原始樣本，接著特徵預處理後，生成用於模型訓練所需的訓練樣本。線上階段的 pipeline 跟線下基本相同，不同之處在於各自依賴的上游數據源，一個來自客戶端的實時反饋，一個來自召回請求及預測候選集。
下圖為排序系統的基本流程。然而，在具體實踐中，處於對各模塊的計算平臺、流程一致性、組件通用性以及模型訓練性能等各方面的考慮，我們需要對這個 basic 的排序系統做對應的改造。而我們的改造主要集中在兩塊：特徵預處理 & 模型。
為什麼要對基礎流程進行改造以及具體如何改造？這裡需要了解一下整個排序系統研發過程中我們所面臨的核心問題和挑戰。
首先關於 pipeline，我們知道，排序模型在訓練和預測之間的差異會對模型的準確性產生很大的影響。而差異的產生來源於：特徵、特徵處理。只有保證 pipeline 線上線下的一致性，才能保證線上模型能夠得出正確的預測結果。特徵方面，我們將進行在線預測時的特徵保存下來，然後填充到線下的訓練樣本中，這樣就保證了訓練和預測階段的特徵是一致的；特徵處理方面，實踐中一般採用 tf.data 和 feature_column 進行讀取樣本數據和特徵處理，這種做法雖然避免了線上線下一致性的問題，但是這種基於原生 TensorFlow 的實現也帶來了線上計算和線下訓練的性能問題。如何在特徵處理模塊即保證線上線下的一致性又能同時保障系統整體的性能，這是我們所面臨的一個挑戰。
然後對於深度學習排序模型，我們需要支持網易新聞不斷增多的業務需求，這就要求排序模型框架有足夠的通用性和可擴展性，以支持模型的快速迭代和遷移。同時要求模型有足夠好的靈活性，以支持業務定製化。
針對 pipeline 中的特徵處理模塊以及排序模型框架，我們做了如下優化：
首先特徵處理庫，將模型訓練階段跑在 CPU 上的特徵處理任務轉移到 pipeline 階段的大規模計算集群上 ( Haddop Streaming )，以免影響模型訓練階段對 GPU 計算的影響，同時也避免了訓練階段的重複計算。基於這樣的思想，我們將特徵處理庫從模型中獨立出來，線下階段在 pipeline 中而非模型中調用此庫，線上階段在模型中調用此庫，但是這樣會帶來線上線下不一致的問題。我們的解決方案是將特徵處理庫獨立出來之後，線上和線下調用對應的我們自定義 OP ( 樣本讀取和數據處理模塊 ) 即可。
關於自定義 OP，我們主要對樣本讀取和數據處理模塊進行了對應的改造。原生 TensorFlow 通常使用 tf.data 進行數據讀取，通過 feature_column 進行數據預處理，但是在大規模數據場景中，存在性能瓶頸，因此我們重新實現了數據讀取和預處理模塊，並優化了性能；另外，為了支持多值帶權的特徵，我們使用了自定義的樣本格式，而原生接口對樣本格式的解析也並不友好，所以自定義瞭解析模塊；或者想要手動融合一些操作或 TensorFlow 原生不支持的一些操作，也需要我們通過自定義 OP 來實現。
完成 pipeline 的底層改造之後，如何快速使用特徵處理框架呢？很簡單，在配置文件中將特徵處理流程描述出來即可。
在配置文件中，對於每個特徵，描述它對應的特徵處理流程。如下圖，圓形代表原始特徵值和經過各個算子處理後的特徵中間值，方形表示特徵處理庫內的算子，所以特徵處理流程可以視為各個 DAG 圖。右邊的兩個例子是用 DAG 圖來描述特徵處理流程的相關配置。
1）特徵 age，先經過校正算子（將上游傳入為0的 age 特徵字段校正為 Null）得到中間值 age_corrected，再經過算子 CDF 或者 Bucket 處理得到可以作為模型輸入的特徵值 age_cdf 和 age_bucket。
2）特徵 Doc_POI 和 User_POI，經過算子 StrToVec 處理之後再經過相似度算子，得到二者的相似度。
以上經過一系列算子處理後的特徵將作為排序模型的輸入。若在訓練樣本中增加特徵，只需要在特徵處理框架中實現對應的算子，並在配置文件來描述新增特徵的處理流程。
我們使用 DAG 圖來描述特徵處理過程的思想，源自於 TensorFlow，先實現底層算子 API，然後將對特徵的處理流程構建 Graph，再通過上層 API 接口 session.run 啟動運行 Graph。而解析配置文件的過程就相當於解析 DAG 圖。
至此，完成 pipeline 的優化。回看一下，排序系統經過改造之後的模樣。排序系統變成由一個特徵處理框架進行特徵處理，而這個框架既可以跑在線下階段的 hadoop streaming 上，也可以跑在線上 TensorFlow 深度學習框架之上。
深度學習排序模型方面，同樣面臨一系列的問題。如何構建通用 & 可擴展的推薦算法庫框架，來支持新的業務場景，保證模型的快速迭代？如何保證框架的靈活性，根據變化的業務需求對模型做定製化？如何通過高度可配置的方式來構建模型？
先看幾個經典的深度學習排序模型的網絡結構，左邊是 DNN，右邊為它的幾種變體：FNN、PNN、Wide&Deep。雖然4種模型結構各異，但抽象一下會發現共通之處，基本單元包括：linear、cross、deep 模塊，從層次結構來看包括: 特徵表徵層、特徵交叉層、全連接層，其中特徵交叉既可以通過人工方式 ( Wide 部分 ) 也可以通過內積或矩陣乘法的方式來進行。經過以上分析，其實提供了一種思路：我們可以將深度學習模型的各個基本單元進行模塊化來構建模型。
沿著以上的抽象和分析，接下來用兩個網絡結構相對複雜的深度學習排序模型來進行驗證。
下圖左邊為 DCN ( Deep & Cross NetWork ) 模型，右邊為 DIEN ( Deep Interest Evolution Network )，可以觀察到，層次結構同上：特徵表徵層、特徵交叉層、全連接層，與上面不同的是：特徵交叉不再受限於人工交叉或各種方式的2階交叉，而是讓 NN 網絡去進行更高階的特徵交叉表達。網絡的基本單元仍然包括：linear、cross、deep。
根據前面對幾種深度學習排序模型的網絡結構的分析，總結起來如下表所示：
輸入層到 Embedding 層，該過程把大規模的稀疏特徵通過 embedding 操作或其它表徵方式映射為低維稠密的 embedding 向量；對於生成的 embedding 向量，我們可以對它進行包括特徵交叉在內的其它各種操作，比如：concat、sum or average pooling 等操作，大部分排序模型改造主要集中在這一層；最後將經過各種處理之後的 embedding 向量輸入至全連接框架中。
有了深度學習排序模型的通用範式，我們便針對網易新聞推薦業務設計了通用模型框架。
文章作者：薛海霞 網易傳媒
編輯整理：鄭智獻
內容來源：DataFun AI Talk
出品社區：DataFun
注：歡迎轉載，轉載請註明出處
大家好，今天分享的主題是：網易新聞客戶端信息流的個性化推薦中，深度學習排序系統及模型，這也是我們團隊在研發實踐中的一些經驗總結。
首先看一下在信息流場景中，個性化推薦的產品形態。左邊是網易新聞的頭條頻道，右邊是短視頻頻道，在經過召回、排序、重排之後信息流的最終呈現。作為流量較大的兩個頻道，我們在對它構建排序系統和排序模型的時候，通常會根據文章、視頻、圖像相關的內容特徵，用戶畫像，場景，關注關係等對內容候選集進行排序。接下來，問題來了，如何衡量排序的效果呢？線上優化指標通常包括：CTR、閱讀時長、留存、刷新次數等，其中最容易建模的就是點擊率了，如果要用一個範式進行表示，就是圖中這個概率公式。
接下來考慮一個問題，當面臨一個具體的推薦業務場景時，如何高效地構建排序系統和排序模型？
一般來說，排序系統由三部分構成：pipeline、排序模型、模型計算服務。
線下階段，pipeline 將客戶端傳過來的實時反饋日誌，按照不同 session 進行聚合，曝光和點擊數據進行 label match，然後經過特徵填充生成原始樣本，接著特徵預處理後，生成用於模型訓練所需的訓練樣本。線上階段的 pipeline 跟線下基本相同，不同之處在於各自依賴的上游數據源，一個來自客戶端的實時反饋，一個來自召回請求及預測候選集。
下圖為排序系統的基本流程。然而，在具體實踐中，處於對各模塊的計算平臺、流程一致性、組件通用性以及模型訓練性能等各方面的考慮，我們需要對這個 basic 的排序系統做對應的改造。而我們的改造主要集中在兩塊：特徵預處理 & 模型。
為什麼要對基礎流程進行改造以及具體如何改造？這裡需要了解一下整個排序系統研發過程中我們所面臨的核心問題和挑戰。
首先關於 pipeline，我們知道，排序模型在訓練和預測之間的差異會對模型的準確性產生很大的影響。而差異的產生來源於：特徵、特徵處理。只有保證 pipeline 線上線下的一致性，才能保證線上模型能夠得出正確的預測結果。特徵方面，我們將進行在線預測時的特徵保存下來，然後填充到線下的訓練樣本中，這樣就保證了訓練和預測階段的特徵是一致的；特徵處理方面，實踐中一般採用 tf.data 和 feature_column 進行讀取樣本數據和特徵處理，這種做法雖然避免了線上線下一致性的問題，但是這種基於原生 TensorFlow 的實現也帶來了線上計算和線下訓練的性能問題。如何在特徵處理模塊即保證線上線下的一致性又能同時保障系統整體的性能，這是我們所面臨的一個挑戰。
然後對於深度學習排序模型，我們需要支持網易新聞不斷增多的業務需求，這就要求排序模型框架有足夠的通用性和可擴展性，以支持模型的快速迭代和遷移。同時要求模型有足夠好的靈活性，以支持業務定製化。
針對 pipeline 中的特徵處理模塊以及排序模型框架，我們做了如下優化：
首先特徵處理庫，將模型訓練階段跑在 CPU 上的特徵處理任務轉移到 pipeline 階段的大規模計算集群上 ( Haddop Streaming )，以免影響模型訓練階段對 GPU 計算的影響，同時也避免了訓練階段的重複計算。基於這樣的思想，我們將特徵處理庫從模型中獨立出來，線下階段在 pipeline 中而非模型中調用此庫，線上階段在模型中調用此庫，但是這樣會帶來線上線下不一致的問題。我們的解決方案是將特徵處理庫獨立出來之後，線上和線下調用對應的我們自定義 OP ( 樣本讀取和數據處理模塊 ) 即可。
關於自定義 OP，我們主要對樣本讀取和數據處理模塊進行了對應的改造。原生 TensorFlow 通常使用 tf.data 進行數據讀取，通過 feature_column 進行數據預處理，但是在大規模數據場景中，存在性能瓶頸，因此我們重新實現了數據讀取和預處理模塊，並優化了性能；另外，為了支持多值帶權的特徵，我們使用了自定義的樣本格式，而原生接口對樣本格式的解析也並不友好，所以自定義瞭解析模塊；或者想要手動融合一些操作或 TensorFlow 原生不支持的一些操作，也需要我們通過自定義 OP 來實現。
完成 pipeline 的底層改造之後，如何快速使用特徵處理框架呢？很簡單，在配置文件中將特徵處理流程描述出來即可。
在配置文件中，對於每個特徵，描述它對應的特徵處理流程。如下圖，圓形代表原始特徵值和經過各個算子處理後的特徵中間值，方形表示特徵處理庫內的算子，所以特徵處理流程可以視為各個 DAG 圖。右邊的兩個例子是用 DAG 圖來描述特徵處理流程的相關配置。
1）特徵 age，先經過校正算子（將上游傳入為0的 age 特徵字段校正為 Null）得到中間值 age_corrected，再經過算子 CDF 或者 Bucket 處理得到可以作為模型輸入的特徵值 age_cdf 和 age_bucket。
2）特徵 Doc_POI 和 User_POI，經過算子 StrToVec 處理之後再經過相似度算子，得到二者的相似度。
以上經過一系列算子處理後的特徵將作為排序模型的輸入。若在訓練樣本中增加特徵，只需要在特徵處理框架中實現對應的算子，並在配置文件來描述新增特徵的處理流程。
我們使用 DAG 圖來描述特徵處理過程的思想，源自於 TensorFlow，先實現底層算子 API，然後將對特徵的處理流程構建 Graph，再通過上層 API 接口 session.run 啟動運行 Graph。而解析配置文件的過程就相當於解析 DAG 圖。
至此，完成 pipeline 的優化。回看一下，排序系統經過改造之後的模樣。排序系統變成由一個特徵處理框架進行特徵處理，而這個框架既可以跑在線下階段的 hadoop streaming 上，也可以跑在線上 TensorFlow 深度學習框架之上。
深度學習排序模型方面，同樣面臨一系列的問題。如何構建通用 & 可擴展的推薦算法庫框架，來支持新的業務場景，保證模型的快速迭代？如何保證框架的靈活性，根據變化的業務需求對模型做定製化？如何通過高度可配置的方式來構建模型？
先看幾個經典的深度學習排序模型的網絡結構，左邊是 DNN，右邊為它的幾種變體：FNN、PNN、Wide&Deep。雖然4種模型結構各異，但抽象一下會發現共通之處，基本單元包括：linear、cross、deep 模塊，從層次結構來看包括: 特徵表徵層、特徵交叉層、全連接層，其中特徵交叉既可以通過人工方式 ( Wide 部分 ) 也可以通過內積或矩陣乘法的方式來進行。經過以上分析，其實提供了一種思路：我們可以將深度學習模型的各個基本單元進行模塊化來構建模型。
沿著以上的抽象和分析，接下來用兩個網絡結構相對複雜的深度學習排序模型來進行驗證。
下圖左邊為 DCN ( Deep & Cross NetWork ) 模型，右邊為 DIEN ( Deep Interest Evolution Network )，可以觀察到，層次結構同上：特徵表徵層、特徵交叉層、全連接層，與上面不同的是：特徵交叉不再受限於人工交叉或各種方式的2階交叉，而是讓 NN 網絡去進行更高階的特徵交叉表達。網絡的基本單元仍然包括：linear、cross、deep。
根據前面對幾種深度學習排序模型的網絡結構的分析，總結起來如下表所示：
輸入層到 Embedding 層，該過程把大規模的稀疏特徵通過 embedding 操作或其它表徵方式映射為低維稠密的 embedding 向量；對於生成的 embedding 向量，我們可以對它進行包括特徵交叉在內的其它各種操作，比如：concat、sum or average pooling 等操作，大部分排序模型改造主要集中在這一層；最後將經過各種處理之後的 embedding 向量輸入至全連接框架中。
有了深度學習排序模型的通用範式，我們便針對網易新聞推薦業務設計了通用模型框架。
用層次結構圖來表示的話，即下圖：
文章作者：薛海霞 網易傳媒
編輯整理：鄭智獻
內容來源：DataFun AI Talk
出品社區：DataFun
注：歡迎轉載，轉載請註明出處
大家好，今天分享的主題是：網易新聞客戶端信息流的個性化推薦中，深度學習排序系統及模型，這也是我們團隊在研發實踐中的一些經驗總結。
首先看一下在信息流場景中，個性化推薦的產品形態。左邊是網易新聞的頭條頻道，右邊是短視頻頻道，在經過召回、排序、重排之後信息流的最終呈現。作為流量較大的兩個頻道，我們在對它構建排序系統和排序模型的時候，通常會根據文章、視頻、圖像相關的內容特徵，用戶畫像，場景，關注關係等對內容候選集進行排序。接下來，問題來了，如何衡量排序的效果呢？線上優化指標通常包括：CTR、閱讀時長、留存、刷新次數等，其中最容易建模的就是點擊率了，如果要用一個範式進行表示，就是圖中這個概率公式。
接下來考慮一個問題，當面臨一個具體的推薦業務場景時，如何高效地構建排序系統和排序模型？
一般來說，排序系統由三部分構成：pipeline、排序模型、模型計算服務。
線下階段，pipeline 將客戶端傳過來的實時反饋日誌，按照不同 session 進行聚合，曝光和點擊數據進行 label match，然後經過特徵填充生成原始樣本，接著特徵預處理後，生成用於模型訓練所需的訓練樣本。線上階段的 pipeline 跟線下基本相同，不同之處在於各自依賴的上游數據源，一個來自客戶端的實時反饋，一個來自召回請求及預測候選集。
下圖為排序系統的基本流程。然而，在具體實踐中，處於對各模塊的計算平臺、流程一致性、組件通用性以及模型訓練性能等各方面的考慮，我們需要對這個 basic 的排序系統做對應的改造。而我們的改造主要集中在兩塊：特徵預處理 & 模型。
為什麼要對基礎流程進行改造以及具體如何改造？這裡需要了解一下整個排序系統研發過程中我們所面臨的核心問題和挑戰。
首先關於 pipeline，我們知道，排序模型在訓練和預測之間的差異會對模型的準確性產生很大的影響。而差異的產生來源於：特徵、特徵處理。只有保證 pipeline 線上線下的一致性，才能保證線上模型能夠得出正確的預測結果。特徵方面，我們將進行在線預測時的特徵保存下來，然後填充到線下的訓練樣本中，這樣就保證了訓練和預測階段的特徵是一致的；特徵處理方面，實踐中一般採用 tf.data 和 feature_column 進行讀取樣本數據和特徵處理，這種做法雖然避免了線上線下一致性的問題，但是這種基於原生 TensorFlow 的實現也帶來了線上計算和線下訓練的性能問題。如何在特徵處理模塊即保證線上線下的一致性又能同時保障系統整體的性能，這是我們所面臨的一個挑戰。
然後對於深度學習排序模型，我們需要支持網易新聞不斷增多的業務需求，這就要求排序模型框架有足夠的通用性和可擴展性，以支持模型的快速迭代和遷移。同時要求模型有足夠好的靈活性，以支持業務定製化。
針對 pipeline 中的特徵處理模塊以及排序模型框架，我們做了如下優化：
首先特徵處理庫，將模型訓練階段跑在 CPU 上的特徵處理任務轉移到 pipeline 階段的大規模計算集群上 ( Haddop Streaming )，以免影響模型訓練階段對 GPU 計算的影響，同時也避免了訓練階段的重複計算。基於這樣的思想，我們將特徵處理庫從模型中獨立出來，線下階段在 pipeline 中而非模型中調用此庫，線上階段在模型中調用此庫，但是這樣會帶來線上線下不一致的問題。我們的解決方案是將特徵處理庫獨立出來之後，線上和線下調用對應的我們自定義 OP ( 樣本讀取和數據處理模塊 ) 即可。
關於自定義 OP，我們主要對樣本讀取和數據處理模塊進行了對應的改造。原生 TensorFlow 通常使用 tf.data 進行數據讀取，通過 feature_column 進行數據預處理，但是在大規模數據場景中，存在性能瓶頸，因此我們重新實現了數據讀取和預處理模塊，並優化了性能；另外，為了支持多值帶權的特徵，我們使用了自定義的樣本格式，而原生接口對樣本格式的解析也並不友好，所以自定義瞭解析模塊；或者想要手動融合一些操作或 TensorFlow 原生不支持的一些操作，也需要我們通過自定義 OP 來實現。
完成 pipeline 的底層改造之後，如何快速使用特徵處理框架呢？很簡單，在配置文件中將特徵處理流程描述出來即可。
在配置文件中，對於每個特徵，描述它對應的特徵處理流程。如下圖，圓形代表原始特徵值和經過各個算子處理後的特徵中間值，方形表示特徵處理庫內的算子，所以特徵處理流程可以視為各個 DAG 圖。右邊的兩個例子是用 DAG 圖來描述特徵處理流程的相關配置。
1）特徵 age，先經過校正算子（將上游傳入為0的 age 特徵字段校正為 Null）得到中間值 age_corrected，再經過算子 CDF 或者 Bucket 處理得到可以作為模型輸入的特徵值 age_cdf 和 age_bucket。
2）特徵 Doc_POI 和 User_POI，經過算子 StrToVec 處理之後再經過相似度算子，得到二者的相似度。
以上經過一系列算子處理後的特徵將作為排序模型的輸入。若在訓練樣本中增加特徵，只需要在特徵處理框架中實現對應的算子，並在配置文件來描述新增特徵的處理流程。
我們使用 DAG 圖來描述特徵處理過程的思想，源自於 TensorFlow，先實現底層算子 API，然後將對特徵的處理流程構建 Graph，再通過上層 API 接口 session.run 啟動運行 Graph。而解析配置文件的過程就相當於解析 DAG 圖。
至此，完成 pipeline 的優化。回看一下，排序系統經過改造之後的模樣。排序系統變成由一個特徵處理框架進行特徵處理，而這個框架既可以跑在線下階段的 hadoop streaming 上，也可以跑在線上 TensorFlow 深度學習框架之上。
深度學習排序模型方面，同樣面臨一系列的問題。如何構建通用 & 可擴展的推薦算法庫框架，來支持新的業務場景，保證模型的快速迭代？如何保證框架的靈活性，根據變化的業務需求對模型做定製化？如何通過高度可配置的方式來構建模型？
先看幾個經典的深度學習排序模型的網絡結構，左邊是 DNN，右邊為它的幾種變體：FNN、PNN、Wide&Deep。雖然4種模型結構各異，但抽象一下會發現共通之處，基本單元包括：linear、cross、deep 模塊，從層次結構來看包括: 特徵表徵層、特徵交叉層、全連接層，其中特徵交叉既可以通過人工方式 ( Wide 部分 ) 也可以通過內積或矩陣乘法的方式來進行。經過以上分析，其實提供了一種思路：我們可以將深度學習模型的各個基本單元進行模塊化來構建模型。
沿著以上的抽象和分析，接下來用兩個網絡結構相對複雜的深度學習排序模型來進行驗證。
下圖左邊為 DCN ( Deep & Cross NetWork ) 模型，右邊為 DIEN ( Deep Interest Evolution Network )，可以觀察到，層次結構同上：特徵表徵層、特徵交叉層、全連接層，與上面不同的是：特徵交叉不再受限於人工交叉或各種方式的2階交叉，而是讓 NN 網絡去進行更高階的特徵交叉表達。網絡的基本單元仍然包括：linear、cross、deep。
根據前面對幾種深度學習排序模型的網絡結構的分析，總結起來如下表所示：
輸入層到 Embedding 層，該過程把大規模的稀疏特徵通過 embedding 操作或其它表徵方式映射為低維稠密的 embedding 向量；對於生成的 embedding 向量，我們可以對它進行包括特徵交叉在內的其它各種操作，比如：concat、sum or average pooling 等操作，大部分排序模型改造主要集中在這一層；最後將經過各種處理之後的 embedding 向量輸入至全連接框架中。
有了深度學習排序模型的通用範式，我們便針對網易新聞推薦業務設計了通用模型框架。
用層次結構圖來表示的話，即下圖：
與特徵處理框架的思路相同，這裡對模型框架也採用子模塊可配置化的方式。比如輸入特徵為用戶點擊歷史 clk_history 和目標 docid，首先兩個特徵經過 Embedding 後得到對應的向量表示，再經過 Attention 得到權重分配，隨後 Pooling 操作將變長向量轉化為定長，最後輸入全連接網絡。底層實現各個模型子模塊，具體的業務場景對應的模型只需在其配置文件中將模型結構描述出來即可。
文章作者：薛海霞 網易傳媒
編輯整理：鄭智獻
內容來源：DataFun AI Talk
出品社區：DataFun
注：歡迎轉載，轉載請註明出處
大家好，今天分享的主題是：網易新聞客戶端信息流的個性化推薦中，深度學習排序系統及模型，這也是我們團隊在研發實踐中的一些經驗總結。
首先看一下在信息流場景中，個性化推薦的產品形態。左邊是網易新聞的頭條頻道，右邊是短視頻頻道，在經過召回、排序、重排之後信息流的最終呈現。作為流量較大的兩個頻道，我們在對它構建排序系統和排序模型的時候，通常會根據文章、視頻、圖像相關的內容特徵，用戶畫像，場景，關注關係等對內容候選集進行排序。接下來，問題來了，如何衡量排序的效果呢？線上優化指標通常包括：CTR、閱讀時長、留存、刷新次數等，其中最容易建模的就是點擊率了，如果要用一個範式進行表示，就是圖中這個概率公式。
接下來考慮一個問題，當面臨一個具體的推薦業務場景時，如何高效地構建排序系統和排序模型？
一般來說，排序系統由三部分構成：pipeline、排序模型、模型計算服務。
線下階段，pipeline 將客戶端傳過來的實時反饋日誌，按照不同 session 進行聚合，曝光和點擊數據進行 label match，然後經過特徵填充生成原始樣本，接著特徵預處理後，生成用於模型訓練所需的訓練樣本。線上階段的 pipeline 跟線下基本相同，不同之處在於各自依賴的上游數據源，一個來自客戶端的實時反饋，一個來自召回請求及預測候選集。
下圖為排序系統的基本流程。然而，在具體實踐中，處於對各模塊的計算平臺、流程一致性、組件通用性以及模型訓練性能等各方面的考慮，我們需要對這個 basic 的排序系統做對應的改造。而我們的改造主要集中在兩塊：特徵預處理 & 模型。
為什麼要對基礎流程進行改造以及具體如何改造？這裡需要了解一下整個排序系統研發過程中我們所面臨的核心問題和挑戰。
首先關於 pipeline，我們知道，排序模型在訓練和預測之間的差異會對模型的準確性產生很大的影響。而差異的產生來源於：特徵、特徵處理。只有保證 pipeline 線上線下的一致性，才能保證線上模型能夠得出正確的預測結果。特徵方面，我們將進行在線預測時的特徵保存下來，然後填充到線下的訓練樣本中，這樣就保證了訓練和預測階段的特徵是一致的；特徵處理方面，實踐中一般採用 tf.data 和 feature_column 進行讀取樣本數據和特徵處理，這種做法雖然避免了線上線下一致性的問題，但是這種基於原生 TensorFlow 的實現也帶來了線上計算和線下訓練的性能問題。如何在特徵處理模塊即保證線上線下的一致性又能同時保障系統整體的性能，這是我們所面臨的一個挑戰。
然後對於深度學習排序模型，我們需要支持網易新聞不斷增多的業務需求，這就要求排序模型框架有足夠的通用性和可擴展性，以支持模型的快速迭代和遷移。同時要求模型有足夠好的靈活性，以支持業務定製化。
針對 pipeline 中的特徵處理模塊以及排序模型框架，我們做了如下優化：
首先特徵處理庫，將模型訓練階段跑在 CPU 上的特徵處理任務轉移到 pipeline 階段的大規模計算集群上 ( Haddop Streaming )，以免影響模型訓練階段對 GPU 計算的影響，同時也避免了訓練階段的重複計算。基於這樣的思想，我們將特徵處理庫從模型中獨立出來，線下階段在 pipeline 中而非模型中調用此庫，線上階段在模型中調用此庫，但是這樣會帶來線上線下不一致的問題。我們的解決方案是將特徵處理庫獨立出來之後，線上和線下調用對應的我們自定義 OP ( 樣本讀取和數據處理模塊 ) 即可。
關於自定義 OP，我們主要對樣本讀取和數據處理模塊進行了對應的改造。原生 TensorFlow 通常使用 tf.data 進行數據讀取，通過 feature_column 進行數據預處理，但是在大規模數據場景中，存在性能瓶頸，因此我們重新實現了數據讀取和預處理模塊，並優化了性能；另外，為了支持多值帶權的特徵，我們使用了自定義的樣本格式，而原生接口對樣本格式的解析也並不友好，所以自定義瞭解析模塊；或者想要手動融合一些操作或 TensorFlow 原生不支持的一些操作，也需要我們通過自定義 OP 來實現。
完成 pipeline 的底層改造之後，如何快速使用特徵處理框架呢？很簡單，在配置文件中將特徵處理流程描述出來即可。
在配置文件中，對於每個特徵，描述它對應的特徵處理流程。如下圖，圓形代表原始特徵值和經過各個算子處理後的特徵中間值，方形表示特徵處理庫內的算子，所以特徵處理流程可以視為各個 DAG 圖。右邊的兩個例子是用 DAG 圖來描述特徵處理流程的相關配置。
1）特徵 age，先經過校正算子（將上游傳入為0的 age 特徵字段校正為 Null）得到中間值 age_corrected，再經過算子 CDF 或者 Bucket 處理得到可以作為模型輸入的特徵值 age_cdf 和 age_bucket。
2）特徵 Doc_POI 和 User_POI，經過算子 StrToVec 處理之後再經過相似度算子，得到二者的相似度。
以上經過一系列算子處理後的特徵將作為排序模型的輸入。若在訓練樣本中增加特徵，只需要在特徵處理框架中實現對應的算子，並在配置文件來描述新增特徵的處理流程。
我們使用 DAG 圖來描述特徵處理過程的思想，源自於 TensorFlow，先實現底層算子 API，然後將對特徵的處理流程構建 Graph，再通過上層 API 接口 session.run 啟動運行 Graph。而解析配置文件的過程就相當於解析 DAG 圖。
至此，完成 pipeline 的優化。回看一下，排序系統經過改造之後的模樣。排序系統變成由一個特徵處理框架進行特徵處理，而這個框架既可以跑在線下階段的 hadoop streaming 上，也可以跑在線上 TensorFlow 深度學習框架之上。
深度學習排序模型方面，同樣面臨一系列的問題。如何構建通用 & 可擴展的推薦算法庫框架，來支持新的業務場景，保證模型的快速迭代？如何保證框架的靈活性，根據變化的業務需求對模型做定製化？如何通過高度可配置的方式來構建模型？
先看幾個經典的深度學習排序模型的網絡結構，左邊是 DNN，右邊為它的幾種變體：FNN、PNN、Wide&Deep。雖然4種模型結構各異，但抽象一下會發現共通之處，基本單元包括：linear、cross、deep 模塊，從層次結構來看包括: 特徵表徵層、特徵交叉層、全連接層，其中特徵交叉既可以通過人工方式 ( Wide 部分 ) 也可以通過內積或矩陣乘法的方式來進行。經過以上分析，其實提供了一種思路：我們可以將深度學習模型的各個基本單元進行模塊化來構建模型。
沿著以上的抽象和分析，接下來用兩個網絡結構相對複雜的深度學習排序模型來進行驗證。
下圖左邊為 DCN ( Deep & Cross NetWork ) 模型，右邊為 DIEN ( Deep Interest Evolution Network )，可以觀察到，層次結構同上：特徵表徵層、特徵交叉層、全連接層，與上面不同的是：特徵交叉不再受限於人工交叉或各種方式的2階交叉，而是讓 NN 網絡去進行更高階的特徵交叉表達。網絡的基本單元仍然包括：linear、cross、deep。
根據前面對幾種深度學習排序模型的網絡結構的分析，總結起來如下表所示：
輸入層到 Embedding 層，該過程把大規模的稀疏特徵通過 embedding 操作或其它表徵方式映射為低維稠密的 embedding 向量；對於生成的 embedding 向量，我們可以對它進行包括特徵交叉在內的其它各種操作，比如：concat、sum or average pooling 等操作，大部分排序模型改造主要集中在這一層；最後將經過各種處理之後的 embedding 向量輸入至全連接框架中。
有了深度學習排序模型的通用範式，我們便針對網易新聞推薦業務設計了通用模型框架。
用層次結構圖來表示的話，即下圖：
與特徵處理框架的思路相同，這裡對模型框架也採用子模塊可配置化的方式。比如輸入特徵為用戶點擊歷史 clk_history 和目標 docid，首先兩個特徵經過 Embedding 後得到對應的向量表示，再經過 Attention 得到權重分配，隨後 Pooling 操作將變長向量轉化為定長，最後輸入全連接網絡。底層實現各個模型子模塊，具體的業務場景對應的模型只需在其配置文件中將模型結構描述出來即可。
經過對 pipeline 及模型框架的優化，我們的排序系統最終能夠很好的解決了 pipeline 線上線下一致性、系統整體的性能問題、深度學習模型框架的通用性&可擴展、靈活性等問題。
文章作者：薛海霞 網易傳媒
編輯整理：鄭智獻
內容來源：DataFun AI Talk
出品社區：DataFun
注：歡迎轉載，轉載請註明出處
大家好，今天分享的主題是：網易新聞客戶端信息流的個性化推薦中，深度學習排序系統及模型，這也是我們團隊在研發實踐中的一些經驗總結。
首先看一下在信息流場景中，個性化推薦的產品形態。左邊是網易新聞的頭條頻道，右邊是短視頻頻道，在經過召回、排序、重排之後信息流的最終呈現。作為流量較大的兩個頻道，我們在對它構建排序系統和排序模型的時候，通常會根據文章、視頻、圖像相關的內容特徵，用戶畫像，場景，關注關係等對內容候選集進行排序。接下來，問題來了，如何衡量排序的效果呢？線上優化指標通常包括：CTR、閱讀時長、留存、刷新次數等，其中最容易建模的就是點擊率了，如果要用一個範式進行表示，就是圖中這個概率公式。
接下來考慮一個問題，當面臨一個具體的推薦業務場景時，如何高效地構建排序系統和排序模型？
一般來說，排序系統由三部分構成：pipeline、排序模型、模型計算服務。
線下階段，pipeline 將客戶端傳過來的實時反饋日誌，按照不同 session 進行聚合，曝光和點擊數據進行 label match，然後經過特徵填充生成原始樣本，接著特徵預處理後，生成用於模型訓練所需的訓練樣本。線上階段的 pipeline 跟線下基本相同，不同之處在於各自依賴的上游數據源，一個來自客戶端的實時反饋，一個來自召回請求及預測候選集。
下圖為排序系統的基本流程。然而，在具體實踐中，處於對各模塊的計算平臺、流程一致性、組件通用性以及模型訓練性能等各方面的考慮，我們需要對這個 basic 的排序系統做對應的改造。而我們的改造主要集中在兩塊：特徵預處理 & 模型。
為什麼要對基礎流程進行改造以及具體如何改造？這裡需要了解一下整個排序系統研發過程中我們所面臨的核心問題和挑戰。
首先關於 pipeline，我們知道，排序模型在訓練和預測之間的差異會對模型的準確性產生很大的影響。而差異的產生來源於：特徵、特徵處理。只有保證 pipeline 線上線下的一致性，才能保證線上模型能夠得出正確的預測結果。特徵方面，我們將進行在線預測時的特徵保存下來，然後填充到線下的訓練樣本中，這樣就保證了訓練和預測階段的特徵是一致的；特徵處理方面，實踐中一般採用 tf.data 和 feature_column 進行讀取樣本數據和特徵處理，這種做法雖然避免了線上線下一致性的問題，但是這種基於原生 TensorFlow 的實現也帶來了線上計算和線下訓練的性能問題。如何在特徵處理模塊即保證線上線下的一致性又能同時保障系統整體的性能，這是我們所面臨的一個挑戰。
然後對於深度學習排序模型，我們需要支持網易新聞不斷增多的業務需求，這就要求排序模型框架有足夠的通用性和可擴展性，以支持模型的快速迭代和遷移。同時要求模型有足夠好的靈活性，以支持業務定製化。
針對 pipeline 中的特徵處理模塊以及排序模型框架，我們做了如下優化：
首先特徵處理庫，將模型訓練階段跑在 CPU 上的特徵處理任務轉移到 pipeline 階段的大規模計算集群上 ( Haddop Streaming )，以免影響模型訓練階段對 GPU 計算的影響，同時也避免了訓練階段的重複計算。基於這樣的思想，我們將特徵處理庫從模型中獨立出來，線下階段在 pipeline 中而非模型中調用此庫，線上階段在模型中調用此庫，但是這樣會帶來線上線下不一致的問題。我們的解決方案是將特徵處理庫獨立出來之後，線上和線下調用對應的我們自定義 OP ( 樣本讀取和數據處理模塊 ) 即可。
關於自定義 OP，我們主要對樣本讀取和數據處理模塊進行了對應的改造。原生 TensorFlow 通常使用 tf.data 進行數據讀取，通過 feature_column 進行數據預處理，但是在大規模數據場景中，存在性能瓶頸，因此我們重新實現了數據讀取和預處理模塊，並優化了性能；另外，為了支持多值帶權的特徵，我們使用了自定義的樣本格式，而原生接口對樣本格式的解析也並不友好，所以自定義瞭解析模塊；或者想要手動融合一些操作或 TensorFlow 原生不支持的一些操作，也需要我們通過自定義 OP 來實現。
完成 pipeline 的底層改造之後，如何快速使用特徵處理框架呢？很簡單，在配置文件中將特徵處理流程描述出來即可。
在配置文件中，對於每個特徵，描述它對應的特徵處理流程。如下圖，圓形代表原始特徵值和經過各個算子處理後的特徵中間值，方形表示特徵處理庫內的算子，所以特徵處理流程可以視為各個 DAG 圖。右邊的兩個例子是用 DAG 圖來描述特徵處理流程的相關配置。
1）特徵 age，先經過校正算子（將上游傳入為0的 age 特徵字段校正為 Null）得到中間值 age_corrected，再經過算子 CDF 或者 Bucket 處理得到可以作為模型輸入的特徵值 age_cdf 和 age_bucket。
2）特徵 Doc_POI 和 User_POI，經過算子 StrToVec 處理之後再經過相似度算子，得到二者的相似度。
以上經過一系列算子處理後的特徵將作為排序模型的輸入。若在訓練樣本中增加特徵，只需要在特徵處理框架中實現對應的算子，並在配置文件來描述新增特徵的處理流程。
我們使用 DAG 圖來描述特徵處理過程的思想，源自於 TensorFlow，先實現底層算子 API，然後將對特徵的處理流程構建 Graph，再通過上層 API 接口 session.run 啟動運行 Graph。而解析配置文件的過程就相當於解析 DAG 圖。
至此，完成 pipeline 的優化。回看一下，排序系統經過改造之後的模樣。排序系統變成由一個特徵處理框架進行特徵處理，而這個框架既可以跑在線下階段的 hadoop streaming 上，也可以跑在線上 TensorFlow 深度學習框架之上。
深度學習排序模型方面，同樣面臨一系列的問題。如何構建通用 & 可擴展的推薦算法庫框架，來支持新的業務場景，保證模型的快速迭代？如何保證框架的靈活性，根據變化的業務需求對模型做定製化？如何通過高度可配置的方式來構建模型？
先看幾個經典的深度學習排序模型的網絡結構，左邊是 DNN，右邊為它的幾種變體：FNN、PNN、Wide&Deep。雖然4種模型結構各異，但抽象一下會發現共通之處，基本單元包括：linear、cross、deep 模塊，從層次結構來看包括: 特徵表徵層、特徵交叉層、全連接層，其中特徵交叉既可以通過人工方式 ( Wide 部分 ) 也可以通過內積或矩陣乘法的方式來進行。經過以上分析，其實提供了一種思路：我們可以將深度學習模型的各個基本單元進行模塊化來構建模型。
沿著以上的抽象和分析，接下來用兩個網絡結構相對複雜的深度學習排序模型來進行驗證。
下圖左邊為 DCN ( Deep & Cross NetWork ) 模型，右邊為 DIEN ( Deep Interest Evolution Network )，可以觀察到，層次結構同上：特徵表徵層、特徵交叉層、全連接層，與上面不同的是：特徵交叉不再受限於人工交叉或各種方式的2階交叉，而是讓 NN 網絡去進行更高階的特徵交叉表達。網絡的基本單元仍然包括：linear、cross、deep。
根據前面對幾種深度學習排序模型的網絡結構的分析，總結起來如下表所示：
輸入層到 Embedding 層，該過程把大規模的稀疏特徵通過 embedding 操作或其它表徵方式映射為低維稠密的 embedding 向量；對於生成的 embedding 向量，我們可以對它進行包括特徵交叉在內的其它各種操作，比如：concat、sum or average pooling 等操作，大部分排序模型改造主要集中在這一層；最後將經過各種處理之後的 embedding 向量輸入至全連接框架中。
有了深度學習排序模型的通用範式，我們便針對網易新聞推薦業務設計了通用模型框架。
用層次結構圖來表示的話，即下圖：
與特徵處理框架的思路相同，這裡對模型框架也採用子模塊可配置化的方式。比如輸入特徵為用戶點擊歷史 clk_history 和目標 docid，首先兩個特徵經過 Embedding 後得到對應的向量表示，再經過 Attention 得到權重分配，隨後 Pooling 操作將變長向量轉化為定長，最後輸入全連接網絡。底層實現各個模型子模塊，具體的業務場景對應的模型只需在其配置文件中將模型結構描述出來即可。
經過對 pipeline 及模型框架的優化，我們的排序系統最終能夠很好的解決了 pipeline 線上線下一致性、系統整體的性能問題、深度學習模型框架的通用性&可擴展、靈活性等問題。
同時模型效果在各個推薦業務中相對 baseline 也有比較顯著的提升。
文章作者：薛海霞 網易傳媒
編輯整理：鄭智獻
內容來源：DataFun AI Talk
出品社區：DataFun
注：歡迎轉載，轉載請註明出處
大家好，今天分享的主題是：網易新聞客戶端信息流的個性化推薦中，深度學習排序系統及模型，這也是我們團隊在研發實踐中的一些經驗總結。
首先看一下在信息流場景中，個性化推薦的產品形態。左邊是網易新聞的頭條頻道，右邊是短視頻頻道，在經過召回、排序、重排之後信息流的最終呈現。作為流量較大的兩個頻道，我們在對它構建排序系統和排序模型的時候，通常會根據文章、視頻、圖像相關的內容特徵，用戶畫像，場景，關注關係等對內容候選集進行排序。接下來，問題來了，如何衡量排序的效果呢？線上優化指標通常包括：CTR、閱讀時長、留存、刷新次數等，其中最容易建模的就是點擊率了，如果要用一個範式進行表示，就是圖中這個概率公式。
接下來考慮一個問題，當面臨一個具體的推薦業務場景時，如何高效地構建排序系統和排序模型？
一般來說，排序系統由三部分構成：pipeline、排序模型、模型計算服務。
線下階段，pipeline 將客戶端傳過來的實時反饋日誌，按照不同 session 進行聚合，曝光和點擊數據進行 label match，然後經過特徵填充生成原始樣本，接著特徵預處理後，生成用於模型訓練所需的訓練樣本。線上階段的 pipeline 跟線下基本相同，不同之處在於各自依賴的上游數據源，一個來自客戶端的實時反饋，一個來自召回請求及預測候選集。
下圖為排序系統的基本流程。然而，在具體實踐中，處於對各模塊的計算平臺、流程一致性、組件通用性以及模型訓練性能等各方面的考慮，我們需要對這個 basic 的排序系統做對應的改造。而我們的改造主要集中在兩塊：特徵預處理 & 模型。
為什麼要對基礎流程進行改造以及具體如何改造？這裡需要了解一下整個排序系統研發過程中我們所面臨的核心問題和挑戰。
首先關於 pipeline，我們知道，排序模型在訓練和預測之間的差異會對模型的準確性產生很大的影響。而差異的產生來源於：特徵、特徵處理。只有保證 pipeline 線上線下的一致性，才能保證線上模型能夠得出正確的預測結果。特徵方面，我們將進行在線預測時的特徵保存下來，然後填充到線下的訓練樣本中，這樣就保證了訓練和預測階段的特徵是一致的；特徵處理方面，實踐中一般採用 tf.data 和 feature_column 進行讀取樣本數據和特徵處理，這種做法雖然避免了線上線下一致性的問題，但是這種基於原生 TensorFlow 的實現也帶來了線上計算和線下訓練的性能問題。如何在特徵處理模塊即保證線上線下的一致性又能同時保障系統整體的性能，這是我們所面臨的一個挑戰。
然後對於深度學習排序模型，我們需要支持網易新聞不斷增多的業務需求，這就要求排序模型框架有足夠的通用性和可擴展性，以支持模型的快速迭代和遷移。同時要求模型有足夠好的靈活性，以支持業務定製化。
針對 pipeline 中的特徵處理模塊以及排序模型框架，我們做了如下優化：
首先特徵處理庫，將模型訓練階段跑在 CPU 上的特徵處理任務轉移到 pipeline 階段的大規模計算集群上 ( Haddop Streaming )，以免影響模型訓練階段對 GPU 計算的影響，同時也避免了訓練階段的重複計算。基於這樣的思想，我們將特徵處理庫從模型中獨立出來，線下階段在 pipeline 中而非模型中調用此庫，線上階段在模型中調用此庫，但是這樣會帶來線上線下不一致的問題。我們的解決方案是將特徵處理庫獨立出來之後，線上和線下調用對應的我們自定義 OP ( 樣本讀取和數據處理模塊 ) 即可。
關於自定義 OP，我們主要對樣本讀取和數據處理模塊進行了對應的改造。原生 TensorFlow 通常使用 tf.data 進行數據讀取，通過 feature_column 進行數據預處理，但是在大規模數據場景中，存在性能瓶頸，因此我們重新實現了數據讀取和預處理模塊，並優化了性能；另外，為了支持多值帶權的特徵，我們使用了自定義的樣本格式，而原生接口對樣本格式的解析也並不友好，所以自定義瞭解析模塊；或者想要手動融合一些操作或 TensorFlow 原生不支持的一些操作，也需要我們通過自定義 OP 來實現。
完成 pipeline 的底層改造之後，如何快速使用特徵處理框架呢？很簡單，在配置文件中將特徵處理流程描述出來即可。
在配置文件中，對於每個特徵，描述它對應的特徵處理流程。如下圖，圓形代表原始特徵值和經過各個算子處理後的特徵中間值，方形表示特徵處理庫內的算子，所以特徵處理流程可以視為各個 DAG 圖。右邊的兩個例子是用 DAG 圖來描述特徵處理流程的相關配置。
1）特徵 age，先經過校正算子（將上游傳入為0的 age 特徵字段校正為 Null）得到中間值 age_corrected，再經過算子 CDF 或者 Bucket 處理得到可以作為模型輸入的特徵值 age_cdf 和 age_bucket。
2）特徵 Doc_POI 和 User_POI，經過算子 StrToVec 處理之後再經過相似度算子，得到二者的相似度。
以上經過一系列算子處理後的特徵將作為排序模型的輸入。若在訓練樣本中增加特徵，只需要在特徵處理框架中實現對應的算子，並在配置文件來描述新增特徵的處理流程。
我們使用 DAG 圖來描述特徵處理過程的思想，源自於 TensorFlow，先實現底層算子 API，然後將對特徵的處理流程構建 Graph，再通過上層 API 接口 session.run 啟動運行 Graph。而解析配置文件的過程就相當於解析 DAG 圖。
至此，完成 pipeline 的優化。回看一下，排序系統經過改造之後的模樣。排序系統變成由一個特徵處理框架進行特徵處理，而這個框架既可以跑在線下階段的 hadoop streaming 上，也可以跑在線上 TensorFlow 深度學習框架之上。
深度學習排序模型方面，同樣面臨一系列的問題。如何構建通用 & 可擴展的推薦算法庫框架，來支持新的業務場景，保證模型的快速迭代？如何保證框架的靈活性，根據變化的業務需求對模型做定製化？如何通過高度可配置的方式來構建模型？
先看幾個經典的深度學習排序模型的網絡結構，左邊是 DNN，右邊為它的幾種變體：FNN、PNN、Wide&Deep。雖然4種模型結構各異，但抽象一下會發現共通之處，基本單元包括：linear、cross、deep 模塊，從層次結構來看包括: 特徵表徵層、特徵交叉層、全連接層，其中特徵交叉既可以通過人工方式 ( Wide 部分 ) 也可以通過內積或矩陣乘法的方式來進行。經過以上分析，其實提供了一種思路：我們可以將深度學習模型的各個基本單元進行模塊化來構建模型。
沿著以上的抽象和分析，接下來用兩個網絡結構相對複雜的深度學習排序模型來進行驗證。
下圖左邊為 DCN ( Deep & Cross NetWork ) 模型，右邊為 DIEN ( Deep Interest Evolution Network )，可以觀察到，層次結構同上：特徵表徵層、特徵交叉層、全連接層，與上面不同的是：特徵交叉不再受限於人工交叉或各種方式的2階交叉，而是讓 NN 網絡去進行更高階的特徵交叉表達。網絡的基本單元仍然包括：linear、cross、deep。
根據前面對幾種深度學習排序模型的網絡結構的分析，總結起來如下表所示：
輸入層到 Embedding 層，該過程把大規模的稀疏特徵通過 embedding 操作或其它表徵方式映射為低維稠密的 embedding 向量；對於生成的 embedding 向量，我們可以對它進行包括特徵交叉在內的其它各種操作，比如：concat、sum or average pooling 等操作，大部分排序模型改造主要集中在這一層；最後將經過各種處理之後的 embedding 向量輸入至全連接框架中。
有了深度學習排序模型的通用範式，我們便針對網易新聞推薦業務設計了通用模型框架。
用層次結構圖來表示的話，即下圖：
與特徵處理框架的思路相同，這裡對模型框架也採用子模塊可配置化的方式。比如輸入特徵為用戶點擊歷史 clk_history 和目標 docid，首先兩個特徵經過 Embedding 後得到對應的向量表示，再經過 Attention 得到權重分配，隨後 Pooling 操作將變長向量轉化為定長，最後輸入全連接網絡。底層實現各個模型子模塊，具體的業務場景對應的模型只需在其配置文件中將模型結構描述出來即可。
經過對 pipeline 及模型框架的優化，我們的排序系統最終能夠很好的解決了 pipeline 線上線下一致性、系統整體的性能問題、深度學習模型框架的通用性&可擴展、靈活性等問題。
同時模型效果在各個推薦業務中相對 baseline 也有比較顯著的提升。