簡介：常見的個性化推薦系統包括日志收集、資料加工、召回、排序、離線/線上效果評估等諸多環節，對于中小客戶存在技術門檻高、搭建周期長等問題，阿裡巴巴計算平台基于PAI、Hologres、MaxCompute、DataWorks等産品幫助客戶快速搭建個性化推薦解決方案。本文主要分享，從阿裡巴巴計算平台推薦系統的整體解決方案出發，重點介紹基于PAI的向量召回算法和Hologres向量檢索的整體架構，以及該架構在雲上客戶的落地案例和效果分享。
講師介紹：天邑，阿裡雲計算平台進階算法工程師。主要從事基于PAI平台的召回和排序算法研發，及基于雲産品的推薦系統解決方案研發，賦能客戶個性化推薦解決方案落地。
一、雲上個性化推薦解決方案簡介
（一）個性化推薦 - 核心能力
個性化推薦核心價值是要做到千人千面，實作使用者需求和資源的最佳比對，進而提升流量到業務目标的轉化效果。
個性化推薦流程一般分召回和排序兩個部分，我們要從海量的資料中來精準的篩選出幾個到幾十個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還支援在實驗室上設定各種各樣的條件，比如區分新使用者和老使用者，來滿足各種各樣多樣化A/B需求。
二、向量召回PAI召回算法& Hologres向量檢索
（一）向量召回簡介
召回是在整個推薦系統中很重要的一環，它是在整個推薦系統最前線的部分，決定了整個推薦系統算法效果的上限。
傳統的召回算法，如 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集合上的檢索，面對複雜條件下的檢索，
Hologres也能用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;
--複雜條件下檢索
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; 三、最佳實踐
（一）最佳實踐 – 某社交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次，在做内積的時候以矩陣乘的方式展開，就可以達到簡化共享負樣本計算的效果。
（五）最佳實踐 – Hologres向量檢索
我們再來看一下工程系統在首頁推薦上實踐的Hologres向量檢索，我們首先需要在Hologres中建立向量表，建表的語句也非常簡單，其中重點是要在其中設定proxima的向量引擎和其他向量引擎所需要的檢索參數，有了這樣的向量表，我們就很容易的把MaxCompute上的外表資料來導入到Hologres中。這個社交App首頁推薦是一個異性推薦的場景，我們基于Hologres就可以便捷地在性别條件下進行向量的檢索。
（六）最佳實踐 – 首頁推薦效果
推薦解決方案雲上非常成功的案例之一，使得某公司社交APP首頁推薦的UV回複轉化率提升了39%，UV會話轉化率提升了30%。
（七）PAI上其他向量算法能力
PAI上其實還提供了很多其他的向量算法能力，包括圖像的、文本的。PAI上針對圖像和文檔分别提供了PAI-EasyVision和PAI-EasyTransfer算法架構，其中PAI-EasyTransfer已經在github上開源了。基于這些算法架構，我們在PAI上提供人臉比對的能力、圖檔搜尋的能力、問答比對的能力等等，都用到了向量引擎進行向量檢索。歡迎大家來使用。