心得分享 | 如何藉助個性化推薦將客戶總體參與度提升50%

面對激烈競爭，幾乎每一個零售商都在努力爲客戶提供量身定製的個性化體驗。但在恰當的時間，經過恰當的渠道，將恰當的產品，以恰當的方式，推薦給恰當的客戶……這真想作好談何容易！

來自美國底特律的初創公司StockX主要圍繞運動鞋和街頭潮牌服飾開展本身的業務，他們致力於經過獨特的買賣雙向報價革新現有電商銷售模式。爲了用更加個性化的體驗吸引客戶，他們通過普遍對比和評估，決定基於Amazon Personalize服務來打造本身的個性化推薦引擎。

藉助本文，StockX公司的Sam Bean與Nic Roberts II將分享本身在構建該個性化推薦引擎過程當中，前期技術選型、架構設計、實施等工做中得到的經驗和考量。

===

2019年，StockX公司正經歷調整增加，咱們的機器學習（ML）工程師小組也開始嘗試使用Amazon Personalize在主頁上添加產品推薦行。最終，這項新功能成了主頁上最受歡迎的部分。在本文中，咱們將分享StockX使用Amazon Personalize的整個過程，探討如何藉此提供出色的定製化用戶體驗。

咱們的市場動態須要提供個性化的用戶體驗。StockX網站的流量激增，在很大程度上源自相關商品市場供應量的降低。沒錯，在運動鞋與街頭潮牌服飾市場上，最受歡迎的必定是那些須要提早預訂的限量版產品。雖然客戶對於產品多樣性的追求一直在增長，但最受關注的永遠是那些稀缺、幾乎買不到的商品。這致使咱們的平臺經歷一波又一波相似於DDoS的合法流量，讓咱們意識到後端的規模伸縮能力已經成爲順利開展業務的基本前提。另外，咱們的團隊還計劃在黑色星期五以前上線產品推薦行功能。這就須要基於強大的推薦引擎 —— 該引擎須要具備良好的擴展能力，並能夠實時變化以適應不斷變化的客戶意圖。

在公司成立的三年當中，咱們逐漸將用戶體驗的個性化視爲核心發展目標。咱們的客戶羣體已經從單純的運動鞋愛好者，穩步發展擁有愈來愈多休閒及新潮設計服飾的客戶。感恩節購物季則爲咱們提供絕佳機會，以更具個性化的體驗吸引這些新客戶，最終提升總體客戶忠誠度。儘管即將到來的2019年假期給咱們的計劃增長了額外的限制，但Amazon Personalize切實幫助咱們爲不斷髮展的用戶羣體打造精心設計且引人入勝的體驗，最終順利應對季節性流量激增帶來的一系列挑戰。

早期階段

咱們的團隊最初打算尋求第三方供應商來填補平臺中的個性化缺失環節。可是，購買現成解決方案不只成本高昂，並且對於咱們獨特的電商業務而言也缺乏靈活性。咱們須要更大的靈活施展空間，但又不太可能單純依靠內部自建方式搞定所有難題。

接下來，咱們開始考慮構建起與Amazon Personalize核心推薦引擎（分層循環神經網絡，簡稱HRNN）相似的自定義神經網絡。雖然咱們的團隊具有自主建模能力，但卻須要考慮一系列使人頭痛的因素：健壯性、可擴展性以及開發週期等等。咱們須要爭分奪秒地構建優質服務，爲咱們的客戶提供引人入勝的體驗並在假期購物季來臨前及時將其上線。爲了明確究竟是自建模型仍是直接選擇現成解決方案，咱們列舉了構建機器學習微服務架構的基本要求。通過整理，咱們的具體要求以下：

1. 數據收集 —— 創建高性能推薦程序的第一步，天然是對網站進行正確跟蹤。除了經過調查、評級以及偏好設置等方式收集明確的客戶喜愛指標以外，咱們還須要考慮從原始點擊流中提取隱式證據，藉此創建起更加精彩的使用體驗。而收集點擊流數據，也成爲建立高性能推薦程序的重要基礎。
2. 數據位置 —— 在收集到正確的數據類型以後，下一步就是爲該數據肯定準確的存儲位置。爲此，咱們須要找到點擊流與產品目錄數據所在的位置，並獲取訪問權限。
3. 數據整理與特徵工程 —— 在找到數據源與存儲位置以後，接下來須要找到其中真正有價值的部分。這是一項高度依賴於經驗的過程，由於在進行實際嘗試以前，咱們每每很難預判算法如何從數據當中提取信號。
4. 模型開發 —— 這一步也是整個開發生命週期當中，數據科學元素最爲密集的部分。大多數團隊會以Notebook中的原型爲起點，逐步嘗試解決業務問題，然後以面向對象的方式進行模型訓練。這一步驟與以前各步驟相互依存，前者中的數據可用性也將直接影響候選模型集的實際組成。
5. 模型測試與評估 —— 在完成模型訓練以後，必須啓用快速合理性檢驗以執行定性分析，藉此補充訓練指標。咱們建議你們建立一款小型的可視化應用程序，用於在模型提出的推薦內容旁邊提示用戶正在與哪些產品進行交互。這能讓咱們更直觀地審視不一樣算法及超參數設置對推薦結果產生的影響，同時結合業務經驗對其進行比較。
6. ETL開發 —— 在肯定數據中的主要特徵以後，咱們還應該創建一套自動化ETL體系，用於提取原始數據、執行特徵工程，並將數據放置在生產訓練程序可以輕鬆訪問的位置。這一步相當重要，由於ETL中的任何細微錯誤均可能拉低輸入數據質量、最終影響輸出結果的置信度。更可怕的是，這類錯誤每每很難在訓練結束後、輸出可視化以前被檢測出來。
7. 後端服務開發 —— 將模型推理機制與後端服務打包在一塊兒，能夠顯著改善監控、穩定性與抽象性水平。對咱們來講，這也是一條重要的「防禦堤」，防止流量的過分涌入。咱們在AWS Lambda中選擇了無服務器解決方案，將getRecommendations API打包在Amazon Personalize當中。
8. 生產部署 ——CI/CD等自動化流程，用於訓練並部署模型的最新版本，保證推薦結果始終符合客戶的實際需求。一旦這一步驟出現問題，可能致使推薦結果過期，最終下降客戶參與度。在完成這一部分以後，咱們的機器學習微服務架構也就構建完成了。

構建本地解決方案，意味着咱們須要從頭開始完成以上八個具體步驟。Amazon Personalize提供自動化特徵工程與模型開發（步驟3和4）功能，幫助咱們快速搞定這兩個最爲耗時的環節。使用Amazon Personalize提供的標準HRNN（一套由Amazon自己使用過的、通過重重考驗實踐模型），咱們的用例只須要一套僅包含五列數據的簡單數據集便可開始訓練。將這兩個步驟交由Amazon Personalize以後，咱們得以專一於實現強大的ETL、後端與生產部署系統。此外，咱們還省下了更多時間用於實現第5步中提到的可視化流程 —— 這是以往須要開發完整技術棧時，咱們根本不敢想象的。固然，直接使用Amazon Personalize也會帶來必定妥協，意味着對於咱們的算法，咱們將沒法用Amazon Forecast內置方法之外的手段進行鍼對性調整。

這天然在咱們的團隊內部引起激烈討論：咱們究竟是該承擔起高昂的成本，以換取對模型的徹底控制；仍是以可調整性爲代價，徹底信任AWS提供的解決方案？最終，咱們決定信任AWS在構建企業級機器學習模型方面的專業水平。咱們的團隊預見到，內部開發的深度學習推理引擎在可擴展性方面必定會帶來巨大風險。若是不拿出時間進行負載測試，咱們將很難計量估算大規模流量涌入時系統的實際彈性，這將把StockX的總體業務置於隨時可能崩潰的危險境地。另外，生產型深度學習微服務架構是個相對較新的議題，與此相關的文獻資料並不豐富，這也致使問題變得更加複雜。

開發

在決定將推薦程序的核心模型開發與生產推理擴展到AWS以後，咱們開始使用Amazon Personalize進行開發，並很快感覺到將其集成至全擴展機器學習管道所帶來的卓越便捷性。下圖所示，爲這套解決方案架構的基本狀況。

咱們將Amazon Personalize插入兩部分代碼庫當中，這兩套代碼庫分別用於建立數據集以及配置Amazon Personalize基礎設施。以此爲基礎，咱們成功實現了由Amazon Personalize驅動的實時推薦引擎的建立、部署與從新訓練流程的全面自動化。

建立數據集

Amazon Personalize爲用戶提供多種選項，可以根據用戶特徵與推薦引擎的特定應用方式進行選擇。部分配置選項容許咱們在模型訓練過程當中考量用戶特徵（例如HRNN元數據），另外一部分配置則只關注平臺上各用戶間的交互（與單一特徵/HRNN無關）。咱們對具體配置的選擇，決定了訓練數據集的實際構建方式，以及最終將向Amazon Personalize提供多少訓練數據集以創建模型解決方案。

咱們首先開發出用於訓練及測試全部三種HRNN變體（純文本、元數據以及冷啓動）的基礎，並對結果作出比較。在添加元數據集時，咱們剛開始並未發現推薦方面的重大改進，並且發現HRNN - 冷啓動在未進行額外特徵工程開發的狀況下並不能生成天然的推薦結果。雖然咱們懷疑在元數據特徵工程方面投入更多精力也許能最終提升性能，但咱們仍決定嘗試其餘更爲簡單、且一樣有望提供高質量推薦的解決方案。

要使用Amazon Personalize HRNN配置，咱們須要爲其提供單一數據集，並在其中包含任意時段以內的用戶交互行爲。這套交互行爲數據集將包含並定義影響核心推薦算法的訓練特徵。對於像StockX這樣的電子商務平臺，這種交互行爲特徵可能表現爲產品頁面瀏覽量、搜索結果點擊流或者與購買行爲相關的操做等指標。

爲了構建起交互行爲數據集，咱們建立了一條自動化Python ETL管道以查詢咱們的點擊流數據源與產品目錄、處理交互數據以提取所需特徵，並最終執行CSV格式化操做以支持Amazon Personalize的數據提取要求。因爲Amazon Personalize原生支持從Amazon Simple Storage Service (Amazon S3)導入數據集，所以建立這樣的自動化管道並不困難，咱們能夠節省大量時間和精力來考慮如何選擇最佳配置以及最佳交互時段。

自動建立Amazon Personalize基礎設施

接下來，咱們開始着手對Amazon Personalize總體基礎設施進行自動化構建。你們固然能夠在AWS管理控制檯上手動建立Amazon Personalize服務，但配合AWS SDK for Java，咱們可以在規模更大的推薦服務管道中實現全自動與可重複能力。在這裏，咱們選擇Scala做爲客戶端以建立Amazon Personalize基礎設施，具體包含如下內容：

• 數據集組
• 數據集
• 導入做業
• 解決方案
• 解決方案版本
• 實時營銷

對於一次性訓練來講，在控制檯上構建基礎設施確實更爲簡單；但要打造出一套真正的全自動可複用管道，SDK絕對是不二之選。

部署策略

更重要的是，咱們的Scala客戶端還能夠承擔對生產部署流程進行仲裁的額外職能，確保對推薦模型的從新訓練不會形成停機情況。隨着用戶與平臺的持續交互，有必要對模型進行從新訓練，從而及時加入新的交互行爲並據此提供新的推薦。在進行平常訓練時，經過新的交互數據從新訓練模型會使得營銷端口處於離線狀態，致使長時間服務中斷。咱們能夠創建兩個獨立的實時營銷端口（以及方案版本）來緩解這個問題，但代價高昂 —— 它意味着即便不提供任何實時流量，咱們都須要爲各端口支付對應的AWS費用。

爲了解決這種部署問題並創建更具成本效益的微服務架構，咱們創建起獨特的部署策略 —— 採用Lambda函數居中調度。該函數負責訪問營銷端口並向前端客戶端提供推薦內容。咱們還將一套特殊的數據集組標籤（下圖最左側的兩個框體）打包成爲Lambda的一個環境變量，用於標識當前處於活動狀態並處理生產負載的營銷端口。

天天夜間，Scala客戶端會啓動新的訓練做業，並首先檢查Lambda環境變量中的實時數據集組信息。客戶端將加載新的交互數據集，重建休眠數據集組，然後在端口上執行心跳檢查以保證端口建立成功。接下來，客戶端會指示Lambda函數更新其營銷相關環境變量並指向新的端口。最後，再也不使用的Amazon Personalize基礎設施將被撤銷。

經過這種方式，咱們的微服務架構可以自動高效對Amazon Personalize模型進行從新訓練，天天更新用戶推薦內容，且不會帶來昂貴的冗餘支出或者任何服務停機問題。另外，使用Lambda函數還容許咱們啓用自定義指標對系統進行跟蹤與故障監控，及時發佈訓練問題或端口活動錯誤告警。這種圍繞Amazon Personalize精心設計的強大的基於微服務的部署策略，使得StockX的推薦引擎即便在在公司成立至今有史以來最爲繁忙的購物季期間也實現了近乎完美的可用性。具體架構以下圖所示。

實時能力

在完成了訓練與部署流程的設計以後，咱們只剩下最後一個問題須要解決：如何在不一樣訓練執行輪次之間，隨用戶興趣的變化更新推薦內容。Amazon Personalize在這方面提供一套簡單的解決方案，即事件交互數據集。咱們使用Amazon Personalize putEvents API將點擊流事件添加到模型當中。點擊流做爲源端將事件實時推送至Lambda函數，函數將事件歸集爲Amazon Personalize所需的特定格式。事件被添加至數據集後的幾秒內，推薦內容便可得到相應體現。下圖所示，爲這一工做流的基本狀況。

測試與部署

咱們的發佈計劃如今已經成爲StockX公司的內部標準 —— 經過設置A/B測試的特徵標記進行「向您推薦」主頁的部署，這使得團隊在初始階段能夠安全地執行金絲雀測試，將該功能僅發佈給1%的用戶。最終，咱們的測試範圍將涵蓋60%的用戶 —— 其中30%的用戶繼續得到原有體驗，30%的用戶則得到個性化首頁體驗，另外40%用戶不受測試影響。在逐步擴大功能涵蓋範圍的過程當中，咱們發現錯誤率或延遲並無隨之增加。爲了保證萬全，咱們進行了爲期兩週的測試。

儘管「向您推薦」顯示在首頁中的第二行位置，但其點擊率卻超過了顯示在最頂端的「最受歡迎」行。按百分比計算，「向您推薦」已經成爲咱們表現最好的購買通道。受其影響，咱們整個主頁的整體客戶參與度提升了50%，這證實個性化、甚至只是單一頁面的個性化，也足以大大提高其餘商品的點擊率。

個性化始終是企業高管團隊的核心戰略目標之一。而咱們的推薦引擎，則是其中最關鍵的成果。與負責產品發現體驗的產品負責人共同制定戰術策略。做爲獨角獸初創企業的咱們深入意識到個性化的重要性，並經過A/B測試實際證實了個性化的強大能力。在得到初步成果以後，困擾咱們的已經再也不是要不要推廣個性化，而是如何保證個性化元素滲透至StockX客戶體驗的每個角落。機器學習團隊一直是StockX內部最具數據驅動能力的工程團隊之一，經過實驗也展示了基於測試KPI如何確保咱們以可衡量的方式改善客戶的實際體驗。

總結

在項目實施期間，機器學習團隊收穫許多關於構建機器學習微服務架構的知識。咱們將這些心得體會總結以下：

• 儘早集成 —— 在項目生命週期中儘早搭建可行的演示很是重要。即便是簡單的推薦算法，也會給各相關方留下深入的印象，並幫助咱們順利爭取到內部資源與更高的項目優先級。
• 可視化 —— 可視化工具對於機器學習模型的測試相當重要。單純將原始產品ID做爲完整性檢查對象還遠遠不夠，咱們須要同時提供推薦產品的圖片與隱性關聯證據，藉此評估推薦程序的實際效果。
• 避免過分複雜 ——Amazon Personalize提供多種機器學習框架選項，各選項在複雜度方面也有着巨大差別。咱們也曾嘗試從複雜的配置起步，並發現很難理解其爲什麼會提出一些奇怪的推薦。而從簡單的HRNN起步，咱們得以快速開發出效果顯著的例子。
• 估算成本 —— 機器學習成本高昂。請保證對於相應預算需求有明確的估計。除了雲基礎設施使用成本以外，開發人員爲此投入的時間也是一種重要的成本構成元素。
• 瞭解擴展性 —— 要構建本身的深度學習推薦程序，請首先確保對推理做業的擴展性充分了解。發現本身辛苦搭建的解決方案不能知足流量峯值期間的業務要求是一件使人沮喪的事。
• 完全消除手動操做 —— 機器學習微服務架構相較於傳統後端服務架構，包含更多組成部分。自動處理管道中的各個環節 —— 只要還有任何一部分ETL或者部署流程須要人工干預，考慮潛在的錯誤。機器學習的工程部分已經至關困難了，避免引入人爲操做故障。

「向您推薦」成爲咱們團隊乃至整個StockX公司的一次巨大勝利。咱們開始迅速將機器學習技術整合至企業中的各個層面。而咱們得到的成功，也使得企業決策者贊成在更多StockX體驗場景當中集成Amazon Personalize，並不斷擴大咱們在機器學習領域投入的精力。能夠確定地講，個性化現在已經成爲StockX內部的頭等大事。

咱們的團隊在此次假期購物季的幾周以前着手項目開發，並在購物季到來時及時將其上線。能夠自豪地說，在Amazon Personalize的幫助下，咱們的微服務架構在整個假期當中都表現出近乎完美的可用性。