PAI和Hologres的个性化推荐最佳实践
本文內容來自于
由達摩院領航舉辦的3月20日向量檢索專場Meetup講師演講內容
講師介紹
- 天邑
阿里云計算平臺高級算法工程師。主要從事基于PAI平臺的召回和排序算法研發，及基于云產品的推薦系統解決方案研發，賦能客戶個性化推薦解決方案落地。
內容簡要：
一、云上個性化推薦
二、向量召回
三、最佳實踐
01 云上個性化推薦
解決方案簡介
（一） 個性化推薦 - 核心能力
個性化推薦核心價值是要做到千人千面，實現用戶需求和資源的最佳匹配，從而提升流量到業務目標的轉化效果。
個性化推薦流程一般分召回和排序兩個部分，我們要從海量的數據中來精準的篩選出幾個到幾十個Item給用戶推薦過去。
（二）個性化推薦 – 常見方案痛點
常見推薦方案一：運營經驗制定推薦策略
需要有推薦經驗的產品設計或運營人員，通過積累的個人經驗，制定業務推薦策略，并結合數據分析，調整推薦方案，通常在業務規模比較小的企業，冷啟動 階段使用，有明顯的效果弊端：
- 推薦方案及效果，受到人為影響而不可控。
- 方案難以實時結合業務發展快速更新，迭代速度慢。
- 數據計算能力有限，大規模數據分析時候困難。
- 缺少算法人員搭建企業推薦系統，影響企業提升市場競爭
常見推薦方案二：開源框架自建推薦系統
越來越多的企業選擇結合AI技術實現企業推薦系統，但使用開源框架自建推薦系統，也存在諸多問題，影響業務發展：
- 成本高 需要企業采購大量機器用于支持數據計算，不僅一次性投入資金多，且大部分企業都會存在機器資源閑置的浪費問題
- 工程化工作量大 需要適配主流開源框架，存在巨大的工程化工作，以實現不同業務場景最優推薦效果，或實現支持多部門模型需求。
- 運維難承載海量數據、多任務運行，日常運維難度很大。
- 效果不理想。
（三）個性化推薦 – 云上方案
在云上我們可以利用云上的工程基建和算法基建來減緩這部分的成本。在云上提供了兩種的推薦方案，一種是黑盒化的，一種是白盒化的，黑盒化的解決方案低門檻易上手。白盒化的解決方案，整個算法流程是工程師全部自主可控的，它適合于有一定規模的，日處理數據百萬起的團隊，可以支持推薦算法的快速迭代。
（四）云上個性化推薦 – 白盒解決方案
這是整個白盒化的推進解決方案的架構圖，我們從下往上看，最下層是數據處理模塊，MaxCompute和Dataworks的負責離線的特征處理，得到一些離線訓練樣本和用戶的特征數據物料數據，而Flink是支持實時的特征處理，有了特征樣本數據，會流入到PAI-Studio一體化的建模平臺中。
其中PAI-EasyRec負責推薦算法，由GraphLearn和Alink負責一些圖算法和傳統機器設計算法。有了這一些算法，一般會產出兩部分的模型，召回模型和排序模型。召回模型我們可以例行部署到Hologres上，部署成各種基礎索引表，向量召回的話會部署成向量表，這邊圖不太好畫，user部分向量也可以在EAS上進行實時推理。排序模型的話，我們會部署成在線的模型推理服務來進行在線的打分推理。
有了基礎索引表向量表和模型的推理服務，我們再往上層就是整個推薦服務的引擎，我們稱之為PAI-Rec推薦服務引擎，PAI-Rec直接接受用戶的推薦請求，串聯了多路召回、過濾、排序和冷啟動模塊來給出TopN推薦列表。
PAI-Rec之外，我們有PAI-ABTest來做ab實驗，它主要負責科學流量劃分和指標的分析，支持我們云上推薦的效果的快速迭代。
（五）云上個性化推薦 – PAI-EasyRec算法框架
我們重點來看一下其中的幾個模塊，首先是PAI-EasyRec的整個推薦算法框架，可以支持多樣化的數據源，比如說OSS、OdpsTable、HDFS、Kafka等等，有了這樣的特征數據，我們會進入一個離在線一致的特征處理模塊，這里面可以支持IdFeature 、RawFeature 、SeqFeature等等的特征處理。最中間的是ModelZoo，包含很多PAI精心沉淀的排序模型、召回模型和多目標模型，當然也支持算法工程師來基于此自定義自己的算法。整體上看，EasyRec能在PAI上提供萬億樣本、千億特征的超大規模分布式訓練、分布式的評估能力，還支持自動超參搜索和知識蒸餾等調優效果的功能。
（六）云上個性化推薦 – PAI冷啟動方案
除了通用的推薦算法之外，我們還提供了PAI冷啟動方案，我們為什么需要冷啟動？
因為常見的推薦算法對新物品和新用戶是不太友好的，
新物品在很大程度上是常常會被低估的。
冷啟動問題處理不好會影響內容創造者的積極性，進而影響平臺生態的健康發展
我們PAI上的冷啟動方案分為用戶冷啟動和物品冷啟動兩部分。用戶冷啟動主要是基于用戶的基本畫像，基于社交關系，基于用戶興趣的一些熱門推薦，U2U的推薦。物品的冷啟動的算法的則比較豐富了，有基于內容理解的，有基于快速試探強化學習的，基于不同場景間遷移學習的，此外，少樣本學習、知識圖譜的算法，我們也在逐步的研發上線中。
（七）云上個性化推薦 – PAIRec推薦引擎
PAIRec推薦引擎從上往下看，分為接口層、召回層、過濾層、排序層、重排層，這些模塊它端到端的串聯起了整個推薦服務的各個流程，并且其中的一些內置模塊是可以簡單的通過config文件來配置化使用的。
當然為了滿足各種各樣場景定制化的需求，我們也支持在各個層便捷的注冊各種定義的實現來滿足靈活性的要求。
（八）云上個性化推薦 – PAI-A/BTest
PAI-A/BTest是我們保障快速做推薦迭代效果很重要的一環，我們首先來看一下A/B Test是什么，我們會在同一時間維度將用戶劃分成兩組，在保證用戶特征相同的情況下，讓用戶看到不同的兩個ab方案的設計，然后根據最后數據的好壞來決定到底選擇哪個方案，最終把哪個方案來推全，他要走的更進一步，可以滿足各多樣化的A/B Test的需求。
推薦場景為例，我們可以支持這種普通的流量劃分，還可以支持分層的流量劃分，分層流量劃分有什么好處？
推薦場景我們分為召回、排序、重排的這些模塊，這些流量是完全可以正交復用的，我們可以在很小的流量場景之下就可以上很多的實驗上去幫助我們快速的迭代，PAI-A/BTest還支持在實驗室上設置各種各樣的條件，比如區分新用戶和老用戶，來滿足各種各樣多樣化的ab的需求。
02 向量召回
PAI召回算法 & HOLO向量檢
（一）向量召回 – 簡介
召回是在整個推薦系統中很重要的一環，它是在整個推薦系統最前線的部分，決定了整個推薦系統算法效果的上限。
傳統的召回算法，如 CF、Swing等，他們雖然是簡單高效的，但是他們完全基于用戶的歷史行為來進行推薦，沒有結合用戶的畫像信息，物品的屬性信息來產出推薦結果，這導致了整個推薦效果發現性很弱，會導致越推越窄。
而向量召回是將User、Item都嵌入到一個向量空間中去，一定程度上緩解了發現性的問題。一般向量召回分為 U2I和I2I兩種。U2I的向量召回主要代表性的如 DSSM、MIND、YoutubeDNN 等，思想很簡單，將User側和Item側都抽取到向量空間中去，用User的向量在Item的向量集合中查出最臨近的TopK個Item出來。
I2I的如Node2Vec、Metapath2Vec等向量算法，它不同之處是需要Trigger Item，基于用戶的歷史行為來選擇這些Trigger，然后通過Trigger Item的向量，在Item的向量集合中查詢出TopK個臨近的Item。
（二）向量召回 – PAI向量召回
在PAI上我們提供了豐富的召回算法，在PAI-Studio中我們PAI-EasyRec有提供DSSM、YoutubeDNN、MIND等一系列深度的向量召回模型， GraphLearn提供的GraphSage、GAT、SEAL等基于圖的向量召回模型，還有Alink提供Word2Vec、Node2Vec、Metapath2Vec等一系列向量召回模型。在PAI-Studio中，我們想把這些算法快速可視化搭建快速實驗，進行離線效果測試和在線的部署，并且我們還支持AutoML自動化調參，有了這些算法基建，可以幫助我們在云上快速的迭代推進效果。
（三）向量召回 – Hologres向量檢索
Hologres深度集成阿里達摩院自研的向量檢索引擎Proxima，這款向量檢索引擎具有超大規模索引構建和檢索、高緯&高精度、高性能低成本等核心能力，能夠幫助Hologres提供提供低延時、高吞吐的在線查詢服務。并且Hologres是以SQL的查詢接口來暴露給用戶的，十分簡單易用，它能很容易支持水平擴展，因為它是分布式構建向量索引的方式。
（四）向量召回 – Hologres向量檢索
在具體的推薦業務場景中，很重要的一環是向量查詢，Hologres不僅能支持全量item集合上的檢索，面對復雜條件下的檢索， holo也能用sql的形式來支持。例如有很多推薦場景需要查詢最近活躍，當需要查詢某個類目下的，此時寫一個Where語句就能很容易的完成檢索。
全量檢索
select id, pm_approx_euclidean_distance(feature, '{0.1,0.2,0.3}')) as distance where data_time between '1990-11-11 12:00:00' and '1990-11-11 13:00:00’ and tag in ('X', 'Y', ‘Z') from feature_tb order by distance asc limit 10;*
復雜條件下檢索
*
03 最佳實踐
某社交APP首頁推薦
（一）最佳實踐 – 某社交APP首頁推薦
我們以一個社交APP的首頁推薦的場景來體感一下這整套解決方案是怎么運行的。這是一個社交APP首頁推薦的場景，分為列表頁、詳情頁和會話頁，通過點擊列表頁，可以看到用戶的具體詳情，進而發起會話進行聊天。整個首頁推薦的目標是要建立用戶和用戶之間的新聯系，因此我們設計了UV回復轉化率這個指標，就是必須用戶回復，才算一個有效的會話。
（二）最佳實踐 –首頁推薦方案
我們來看一下整個首頁推社交APP首頁推薦問題的難點。
算法需具備發現性，能建立新聯系 ；“有效回復”優化目標非常稀疏，這導致我們優化整個模型的難度也非常高。
下面是整個首頁推薦的方案，我們有常見的多路召回、過濾、排序和用戶的冷啟動和最后會有一個重排。其中的重點是召回里面DSSM的向量召回和GraphSage的向量召回，還有新用戶的冷啟動，這保證了整體的算法具有發現性。然后另一塊是排序這邊做了一個多目標的模型，包括點擊、關注、會話和回復，多個目標的層次遞進的關系，解決了有效回復這個目標非常稀疏的問題。
（三）最佳實踐 – 向量召回算法 PAI-EasyRec | DSSM
重點來看一下其中向量召回，我們以其中的DSSM為例，
它是一個典型的雙塔架構，優勢是能充分利用Side-Info ， 能支持分布式訓練時的負采樣和負樣本MiniBatch內的共享。
（四）最佳實踐 – 向量召回算法 PAI-EasyRec | DSSM – 優化技巧
雙塔架構上模型一個核心的問題點是怎么做負采樣？負采樣決定了整個召回模型效果的好壞，我們來看這個離線hitrate的曲線，可以看到隨著負采量數的增加，基本上是一個穩步上漲的趨勢，最高點是正負樣本比例等于1:1W的時候最佳。所以當然隨著負采樣數的增加，特別是要達到1:1W的采樣，對于存儲的壓力和計算壓力都是非常大的。我們想要離線的去join出這個1:1W的正負樣本來做存儲基本是不太現實的。因此PAI-EasyRec支持在分布式訓練時的實時的負采樣，我們在存儲的時候只存點擊的正樣本，在訓練時分布式采樣出相應的負樣本來做訓練。
下面是我們做分布式負采樣的方案，其實是將用戶的歷史行為和用戶的一些屬性特征，以圖結構形式存在參數服務器上，然后基于我們從參數服務器上進行實時的負采樣，跟正樣本join起來進行訓練。1:1W正負樣本對于我們的計算壓力也是提出了很大的挑戰。在PAI-EasyRec在里面我們做了一個優化， MiniBatch內負樣本是共享的，不用將N*1W個負樣本都計算一次，它只需要整體計算1W次，在做內積的時候以矩陣乘的方式展開，就可以達到簡化共享負樣本計算的效果。
（五）最佳實踐 – HOLO向量檢索
我們再來看一下工程系統在首頁推薦上實踐的HOLO向量檢索，我們首先需要在Hologres中建立向量表，建表的語句也非常簡單，其中重點是要在其中設置proxima的向量引擎和其他向量引擎所需要的檢索參數，有了這樣的向量表，我們就很容易的把MaxCompute上的外表數據來導入到Hologres中，這是一個異性推薦的場景，我們就可以在性別條件下進行向量的檢索。
（六）最佳實踐 – 首頁推薦效果
推薦解決方案使得社交APP首頁推薦的UV回復轉化率提升了39%，UV會話轉化率提升了30%，是一個很成功的案例。
（七）PAI上其他向量算法能力
PAI上其實還提供了很多其他的向量算法能力，包括圖像的、文本的PAI-EasyVision、PAI-EasyTransfer，PAI-EasyTransfer已經在github上開源了，我們在PAI上還有人臉人臉匹配的能力、圖片搜索能力、問答匹配的能力等等，都可以用到其中的向量引擎。歡迎大家來使用。
“ AI 檢索技術博客”
由阿里巴巴達摩院系統 AI 實驗室創立，
關注 “ AI 檢索技術博客” 公眾號，
獲取更多技術干貨文章、
AI 檢索領域 Meetup 動態。
原文鏈接：https://developer.aliyun.com/article/783540?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。總結
以上是生活随笔為你收集整理的PAI和Hologres的个性化推荐最佳实践的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 2021研发效能实践案例征集大赛
- 下一篇： 函数计算帮助石墨文档突破性能瓶颈，有效节