作者：datarevenue

編譯：ronghuaiyang

導讀

如何處理沒有見過的數據，優化響應時間，並頻繁更新模型。

如何處理不可見的數據，優化響應時間，並頻繁更新模型。

介紹

有很多關於訓練和評估推薦系統的文章，但很少有文章解釋該如何克服建立全面系統的挑戰。

大多數庫都不支持開箱即用的可擴展生產系統。這些挑戰通常是：

• 動態預測 — 當你的用戶/物品維度非常大的時候，它可能是非常低效的 — 或者說不可能預先計算好所有的推薦。
• 優化響應時間 — 當你動態創建預測時，檢索它們所需的時間非常重要。
• 頻繁更新模型 — 當系統需要合併可用的新數據時，頻繁更新模型是至關重要的。
• 基於沒見過數據進行預測 — 這意味著要處理沒見過的用戶或物品，並不斷地更改特徵。

這篇文章將告訴你如何在一個完整的生產環境中修改模型來擴展它的功能。

混合推薦模型能更好地應對現實世界的挑戰

我們使用了LightFM模型，這是一個非常流行的python推薦庫，它實現了一個混合模型。它最適合中小規模的推薦項目 — 不需要分布式的訓練。

簡要介紹不同的推薦方法

有兩種基本的推薦方法：

協同過濾 模型只使用協同過濾的信息 — 用戶和物品之間隱式或者顯式的交互（比如看過的電影，評分，是不是喜歡）。沒有使用任何實際物品的信息（如電影類別，流派等）。

協同過濾模型在小數據集上可以得到很高的準確率，但是不能處理未知的用戶或者物品（冷啟動問題）。

協同模型可以在數據少的情況下達到**的高精度，但無法處理未知的用戶或項目(**冷啟動問題)。

基於內容的 模型完全基於關於物品或用戶的可用數據，完全忽略了用戶與物品之間的交互。所以他們處理推薦的方式與協同過濾模型非常不同。

基於內容的模型通常：

• 需要更多的訓練數據(你需要為幾乎每一個單獨的用戶/物品組合提供用戶/物品樣本)，並且
• 比協同過濾模型更難調優。

但是，與協同過濾模型相比，它們可以對未知的物品進行預測，並且通常具有更好的覆蓋率。

混合推薦 — 像LightFM一樣，將兩種方法結合起來，克服了每種方法的各自的缺點。

可以處理新物品或新用戶：

當你將一個協同過濾模型部署到生產環境中時，你經常會遇到需要預測沒有見過的用戶或物品的問題 — 比如當一個新用戶註冊或訪問你的網站，或者你的內容團隊發布一篇新文章時。

通常，你必須至少等到下一個訓練周期，或者等到用戶與某個物品交互時，才能為這些用戶提供建議。

但是，即使在這種情況下，混合模型也可以進行預測：它將簡單地使用部分可用的特徵來計算推薦。

混合模型還可以處理特徵缺失：

有時，一些用戶和物品會缺少一些特徵(僅僅是因為你還沒有能夠收集它們)，如果你依賴於基於內容的模型，這就是一個問題。

混合推薦器適用於為用戶(那些從訓練中了解到的用戶)包括新用戶返回物品，只要你有關於他們的特徵。這對於物品尤其有用，對於新用戶也是如此(當用戶第一次訪問你的站點時，你可以詢問他們對什麼感興趣)。

系統組件

在這個系統中假設物品的數量比用戶要少得多，因為它總是檢索所有物品的預測。但它可以作為更複雜推薦的基礎。

系統的核心是一個flask app，它接收一個用戶ID，然後返回和該用戶相關的物品。它將(重新)加載LightFM模型，並查詢一個針對物品和/或用戶特徵的redis實例。

我們將假設用戶和物品的特徵是存儲和序列化在一個redis資料庫中，並可以隨時由flask的應用程式來檢索。

所有應用程式都將通過docker容器部署為微服務。

LightFM如何進行預測

但是這個東西怎麼工作呢？

這篇LightFM論文：(https://arxiv.org/pdf/1507.08439.pdf)對於學術讀者來說信息量很大，但是對於不太熟悉這個領域的人來說可能有點簡略。我將在下面更簡單地概述LightFM模型的預測的過程。

公式說明：

• 小寫字母表示向量，大寫字母表示矩陣。
• 下標u為單個用戶，U為所有用戶的集合。
• 物品以相同的方式引用。

這裡的命名大部分與LightFM論文一致。

模型的組成

LightFM結合了協同過濾和基於內容的方法。你可能會說它為兩種方法中的每一種建模一個組件。這兩個都是必要的，可以從推薦系統中得到我們想要的屬性。

協同過濾部分

協作過濾部分允許你在沒有任何特徵或特徵不能提供信息的情況下使用協同過濾算法。最先進的協同過濾算法是通過矩陣分解實現的。他們估計了兩個潛在的(未觀察到的)矩陣表示，當它們彼此相乘時，將重現訓練期間模型看到的每個物品和用戶的交互矩陣。當然，誤差項可以允許一些噪聲和避免過擬合。

打個簡單的比方：試著因式分解12。我們可以用2和6，3和4，1和12等等。矩陣也是類似的。

我們稱這些矩陣為潛在表示，因為它們是我們交互數據的壓縮形式。

基於內容的部分

基於內容的部分允許你在沒有交互數據的時候獲得預測。

LightFM通過將用戶和物品特徵與潛在表示關聯起來，從而合併了這些特徵。假設特徵和潛在表示是線性相關的。所以在向量形式中：

為用戶的潛在表示，為單個用戶特徵的行向量，為估計的物品的嵌入，為用戶emedding的偏差。(為了簡單起見，我們將從現在開始忽略它們。)

看起來很像線性回歸，對吧？除了是一個矩陣，其他都是向量。實際上，這實際上執行了多個回歸：每個模型組件一個。同樣，對於物品也是類似的。

在訓練中，利用梯度下降算法估計用戶嵌入和物品嵌入。嵌入矩陣中的每一行都是一個特徵。嵌入矩陣的列稱為分量。列的數量被設置為一個模型超參數，我們從現在開始將其稱為d。

上面的圖概括了為所有用戶和所有物品進行預測的這個過程。因此，在步驟I中，我們將尺寸為的用戶特徵矩陣與尺寸為的嵌入矩陣相乘。同樣的方法也適用於物品特徵與物品嵌入的第二次乘法。由步驟I得到兩個尺寸為和和的矩陣。因此，每個用戶/物品都表示為大小為d的潛向量。

現在你可以很容易地獲得一個單一用戶的所有表示與以下條件：

是用戶潛在表示的行向量，是所有物品的潛在表示的矩陣。

使用指示矩陣對協同過濾模型進行退化

LightFM可以只生成具有協同過濾信息的模型。它使用了一個非常有效的技巧：如果根本不使用用戶或物品特徵，模型將接受一個大小分別為或的單位矩陣。這是非常有效的，因為它隨後學習d向量 — 每個用戶一個。這樣，模型就可以最終退化成最佳的純協同過濾方法。你可以將這些組件看作是用戶的模型記憶，以及在訓練中已經看到的物品。

你還可以強迫模型退回到協同過濾模式 — 即使你有特徵：你可以通過向其添加一個單位矩陣來修改特徵矩陣。有時你需要這個來讓你的模型收斂。然而，這通常意味著你的特徵太過嘈雜或者沒有攜帶足夠的信息，以至於模型本身無法收斂。

最後，使用這種技巧增加了將模型投入生產所需的工作：在訓練期間，用戶的索引用於檢索相應特徵/單位矩陣的正確行 — 而這些信息在生產環境中可能不再可用，另外，LightFM模型將這個責任推卸給了用戶。

有趣的事實

在歐幾里得空間中，僅使用指示特徵就可以獲得的相似物品/用戶的潛在表示(就協同過濾信息而言)是接近的。該模型基於協同過濾信息對它們進行估計。因此，你可以使用它們來查找物品或用戶之間的相似性。

動態地重新創建指示器和特徵

現在讓我們實現一個模型，該模型可以回到協同過濾模式，跟蹤IDs，從而能夠重構正確的特徵和指示器。

我們將聚焦在實現一個完整的方法。這是相當複雜的，因為同時，它應該能夠在大多數情況下給出預測。我們將繼承LightFM類並添加一個特殊的predict_online方法，該方法將在生產期間使用。

這樣，我們仍然可以使用LightFM的cythonised預測函數，避免分別處理用戶和物品ID的映射。

它應可以滿足下列要求：

1. 如果在訓練過程中看到過用戶/物品，則重構其指示特徵
2. 不管某個用戶的數據是什麼，都要進行在線預測
3. 儘可能快地做出預測

ID映射

為了達到第一個要求，你必須在訓練中使用同樣的類。你還需要調整你的子類，使它在訓練期間只接受稀疏矩陣，SparseFrame對象，因此創建並保存ID映射。

重構特徵

為了實現第二個需求，你需要在每次請求傳入時檢查可用數據。有16種情況你必須處理：

在IV、VIII和XII的情況下，我們簡單地返回我們的基線預測。對於XIII至XVI的情況，我們無法作出任何預測，因為我們對這些物品了解不夠。

總結一下：我們基本上想要創建一個行向量，其中包含用戶特徵，如果它們是可用的。否則在相應的下標上都是0。如果用戶在訓練的時候見過，它還在正確的索引上包含了用戶的指示特徵。

物品特徵與用戶特徵類似，只是我們希望它們能夠很容易地放到內存中，以便進行緩存。你可以考慮根據你的使用情況使用不同的緩存策略(如TTLCache)，或者根本不使用緩存。

我們還希望支持不添加指示器，或者只將它們添加到用戶或物品特徵中，這可能會使實現更加複雜。儘管如此，我們還是儘量保持簡單。

下面是上述方法的示例實現。這個實現應該能夠正確處理到VIII的所有情況。但是可能不是所有的項目用例都實現了，因為我們的應用程式不需要它。因此，預測沒有項目特徵的已知項目是不可能的，但它應該很容易添加。

本文的第二部分使用這個類，將它連接到一個redis資料庫，並使用flask動態地提供它的預測。我們還將向你展示如何使用從flask應用程式內部啟動的後台線程在不停機的情況下更新模型。

代碼連結：https://gist.github.com/kayibal/16340660d1d85b9ea1872a5d9be0f383

英文原文：https://www.datarevenue.com/en-blog/building-a-production-ready-recommendation-system