推06，從推薦策略演算法到推薦系統，到數據架構，再到產品設計 | 系列收官篇

作者 | HCY崇遠

推薦系統第5篇是12月21號寫的，距離到現在都20幾天了，中間零散更新了其他的幾篇文章，再拖延下去，懶惰得都不一定有信心把這個系列收尾了，所以，今天，我們把這個系列好好的收官，讓那些一直追著這個系列的朋友不留下遺憾。

接推薦系統系列的上一篇《附Spark案例 | 推05，論推薦系統之經典，還得數協同》，開篇2篇我們從概念，從應用場景出發，大概的把推薦系統基礎知識給大伙兒普及了一遍，接下來的三篇，分別由淺到深，從理論到代碼案例講解幾種不同推薦系統的策略或者推薦演算法，看著整個系列從理論到案例，該有的都有了，其實不然，之前就有說過，推薦策略或者演算法與推薦系統是有本質的不同的，而這一篇就是要把前面的東西進行收攏，從整體上進行收官。

雖然不再從策略維度再進一步深入，即這裡不會再從理論到代碼案例再深入講策略，但是實際上推薦的策略是遠不止如此的，並且從應用以及系統的角度來說，並沒有說固定的策略可言。

01 推薦策略以及演算法的百花齊放

承上，我們講了最基礎的基於內容屬性本身的相似關係進行針對物品的推薦，再到基於用戶的興趣屬性進行推薦，再過渡到基於協同關係進行推薦，其實這些都算是推薦的策略，說的更技術點就是推薦的演算法。

而推薦策略的想像力其實無限的，並不局限於某種固定的策略，只要從業務的角度走的通，其實都是可以的，當然具體的選擇以及搭配問題，後面我會講到。

我們來看已經歸屬於大騰訊的「起點中文網」的推薦。

PS：截圖是我隨意點擊的一本小說《飛劍問道》，不重要，可以不care。

從他的推薦理由「喜歡這本書的人還喜歡」來看，顯然是通過用戶之間的閱讀關聯性來做的這次推薦，說的更通俗易懂點就是購物籃分析：買這個商品的人還經常一起買其他商品。

是不是邏輯關係很像？當然實際上到底是不是這種推薦策略，就需要起點的演算法工程師出來講話了，我個人只是從業務層往下進行追溯從而得出的結論。你看，我說的對不對，策略一層是沒有定式，購物籃分析的邏輯依然是可以用在看文學站的推薦邏輯上，沒毛病。

我們再來看一個策略，依然是騰訊的，騰訊社交廣告一直對外宣稱的技術「Lookalike」，翻譯成技術語言就是「人群擴散演算法」。簡單的邏輯是，先找種子用戶，然後基於用戶畫像和關係鏈（這是騰訊強項）挖掘相似用戶，然後再將受眾進行擴大。

具體示意圖如下：

你覺得這是推薦？看著更像是廣告投放，但廣告的投放誰說不是一次信息主體的推薦呢？本質上應該是沒有這麼大的差距的，只是一個從業務的角度去描述，一個是更偏技術的角度的說法。

隨著阿法狗諸如此類的人工智慧應用的推廣（造勢），以及近幾年計算能力的大幅提升，使得依賴於大計算能力的神經網路的相關演算法得以大放光彩，基於神經網路的一些推薦演算法或者策略也是一個大的研究方向。

綜上，不必舉過多的推薦策略或者演算法例子了，核心想說的就是，其實策略層本身就是百花齊放的狀態，甚至你隨意光顧一些平台網站，都能遇到不同的策略和演算法，甚至是搭配組合，沒有限定的策略和演算法層，只有不同不適應的應用場景，以及從策略到推薦系統層，其實還是有很多東西的。

02 從推薦策略演算法到推薦系統

接上面的話題，從策略演算法層到系統層，差的有哪些東西：

1.首先是策略並不等於系統，這是明確的，推薦的整體邏輯也未必是一種邏輯在裡頭，也可能是多種的策略組合。

2.其次，如何選擇策略，如何組合策略，如何去評判，如何追蹤效果，這點尤其重要。

3.對於整個系統級的支撐，在工程化，以及數據架構上如何去實現，才能支持上層的演算法邏輯層。

4.產品層的策略對整個推薦系統的影響有多大。

如上四個問題都是從推薦系統的角度出發進行分析的，從這裡我們知道，光知道策略或者推薦演算法，是不是離推薦系統的構建還差那麼好幾個量級，02這個小節，我們先從1/2兩個小點進行分析。

策略！=系統，這點是明確的，並且選擇哪些策略去做推薦，本身就有嚴格的選擇機制以及評判機制在裡頭的。

這張圖片很有意思，是別人在脈脈上調侃各大大廠的推薦系統的話，挺有意思，另一方面也是可以側面驗證各大長的一些側重點（不過有點為鵝廠說好話的嫌疑），不管，我們隨拿一些實例來看看。

首先是豆瓣（當前主頁是魔戒1的主頁）：

從直觀的的角度講，同類推薦的因素一定的在，比如《指環王》其他，比如哈利波特，加勒比海盜，但諸如大魚、角鬥士、勇敢的心、與狼共舞這些的邏輯就不得而知了。

從用戶的角度上看，個人使用豆瓣電影也不算少，但幾乎沒有賬號（但如果說沒有賬號就體系就推不準，那這個公司可以死球去了，有很多可以做類似唯一用戶的判別的方式，諸如瀏覽器、電腦硬體地址、cookie等等），但從我的個人感知來看，推薦的效果一般般。

再換一個，這是某寶的（當前是一個iphoneX的購買主頁）：

誠如調侃所言，我吃完兩饅頭，再問我要不要兩饅頭，我搜索iphoneX，他問我要不要iphone從6到6s到8s，挨個問，也夠累的，反正我是不喜歡這種格調。

再回到大騰訊，這是之前文章就涉及到的，騰訊視頻的推薦：

當前頁面為《海上牧雲記》的播放頁面，個人是騰訊視頻的中長期會員，再看看他給我推薦的是什麼？大部分都是類似的奇幻古裝劇，而老實講，我對這種劇著實不喜歡，拍的tmd的假，而我只是好奇點擊進去的，So...

再說到騰訊的朋友圈廣告的投放推薦，前段時間一直給我這種孩子都快打醬油的人推婚紗攝影，這是幾個意思？

再多的例子這裡就不舉了，很多看其推薦的列表大致能猜測一些其推薦的策略重點，其實或多或少還真是與調侃的有一些相似之處，那從表面看起來大部分的推薦系統都不像那麼高大上，問題出在哪，是他們的策略就是這麼Low？是他們的演算法工程師太菜？

其實核心問題在於推薦系統的評價機制，在實際的場景中，一切以效果評價為導向，將策略，甚至是組合推薦的策略往評價得分高的方向進行調整，對於整個系統來說才是有意義的，並不是說演算法高深就一定好。

那麼，具體什麼是合理的評價方式呢，大部分來說都是為了讓用戶的挺溜時間加長，最直接的表現就是點擊轉化，但並不是完全絕對的。以百度的調侃為例，你要的是饅頭，人家給你推薦的是饅頭製造機。

這跟其商業模式是有一定的關聯的，百度之前的核心就是關鍵詞競價廣告，那麼，他必然要衡量幾個方面的東西，第一是關鍵詞與搜索詞的相關性，離太遠太扯淡的不行；第二相關廣告的競價。

於是，他就需要衡量准與商業價值之間的關係了，所以，並不是一味地追求準確，而是追求在其中最佳的平衡點，能給百度帶來最佳的廣告收益轉化。

再說其他的之前我所體驗的推薦系統，他們就一定不準嗎？或許以我個人的角度講，他們推薦的並不是很符合我的口味，但是如果他們是從整體轉化進行評判呢？這種機制是他們所有目前方案中的最佳轉化方案，那為什麼不能用？少數的個體badcase並不會影響整體的策略，也不用管low還是不low，抓住核心問題。

當然，不可否認的是，如果能滿足所有的人的意願認為它很准，又能讓整體系統的轉化做到最大化，那當然最好了。

所以，從推薦策略演算法到推薦系統，最核心的一個東西就是評估機制，構建起完善並且合理的評估機制，有利於整體推薦系統的優化和改進。說到評價，那不得不說的就是AB測試了，一個好的推薦系統，一定是會帶AB測試的，能夠很好的進行策略對比，進行流量分配，效果展示等等。

03 推薦系統架構

前幾天記得分享過朋友的一篇文章，核心就是講推薦系統架構的。對於整個推薦系統來說，系統的架構設計會嚴重影響到整個系統的效果與上層應用的體驗。

在推04中，記得大致提到過基於用戶畫像推薦的短期興趣與長期興趣，其實長期興趣的挖掘還好，基本基於離線的計算結果依然還是可行的，但是對於很多推薦機制來說，就是短期興趣，更切確的說是你當前行為的興趣表現。

這意味著，我需要實時的對你的瀏覽行為進行興趣分析，然後實時的反饋給你推薦列表，這種機制看似簡單腦殘，但往往很有效，因為他足夠實時，而在段時間內，人的注意力一般只會放在很垂直的某個點上，所以往往就很有效。

但是，看似簡單的機制，對於這種需要支持實時分析，實時反饋的機制來說，架構的設計就是一個挑戰。此外，在整體的系統構建過程中，你需要考慮演算法邏輯層可迭代性的問題，即通過反饋數據能夠不斷的自動調整你的演算法策略，從而讓效果更佳，這些都是需要數據架構進行支撐的。

此外，就是上面說的AB測試，效果反饋機制，都是需要集成至整個推薦系統中，再有承接上層應用，你需要考慮好計算的效率與結果輸出的效率問題，所以緩存的設計與緩存更新的機制又是個問題。

從整個架構層來說，其實是相對繁雜的，與我們之前所說的策略演算法層，這是另外一個維度上的東西，需要我們從整體系統級別去考量。

04 從系統到產品策略層

說完推薦策略，再到推薦系統，再到系統架構，這些看似都是與數據、與演算法嚴密相關的東西，單純的以產品思維角度出發，你覺得在設計或者做一個推薦系統時，有什麼需要考慮的嗎？

其實只要用點心，就算不太care演算法策略，也是大有可為的，以上面貼過的一張圖為例。

我們來看他的左上角標題「喜歡這本書的人還喜歡」，其實這就是一種推薦解釋，同理，我們可看亞馬遜的推薦解釋「買過這個商品的人還購買了」。

這就是所謂的推薦結果的可解釋性，人往往信任一些可以解釋、容易理解的東西，這也就是為何很多推薦系統都願意去給出這種類似的推薦解釋，因為這種行為可以提升可信度，而可信度可以增加用戶的點擊轉化，所以，可信度也是推薦系統設計中的一個重要參考因素。

從上面這麼多推薦案例中，我們不難發現一個共同特徵，那就是右上角的「換一批」按鈕，我們來思考一下這個按鈕存在的意義。

任何一次用戶點擊這個換一批按鈕，這就意味著我們收集到了用戶的反饋行為，至於說這個反饋行為到底是正向的還是負向的，就得看具體分析了。比如一個用戶一個推薦項都沒有點，不斷的切換推薦列表，直至放棄，這顯然你的推薦列表不如人意，但該用戶又是一個迫切需要推薦場景的用戶。如果某個用戶，在不斷點擊推薦項的同時，又在不斷的切換列表，這意味著這個用戶很樂意使用推薦的場景，並且推薦的列表還是可以的。怕就怕那種不點擊，也不切換的用戶，我們無法獲取到更多的主動反饋了。

說到主動反饋，另外一個純產品層的設計思路就是推薦項的主動反饋了，這點也是亞馬遜首創，每個推薦項用戶都可以打分，或者直接評判說喜歡與不喜歡。通過這種方式，不斷的收集用戶的喜好，然後融入策略演算法層，才能讓你的推薦系統更加的合理，體驗更好。

所以，單純的從產品層，也是有很多東西可以去研究的，對於整體推薦系統而言，他就是一個應用，無非是更偏向於數據、演算法等維度的一個產品而已，我們可以從演算法層去著手，也可以試圖從產品層去優化。

05 綜上

到這裡，整個推薦系列基本就結束了，從整個系列的邏輯我們知道，如果你要架設一個推薦系統，那麼首先對於推薦系統的一些基本概念需要熟悉，然後了解不同的推薦策略，然後結合場景分析最佳的一些推薦策略演算法，然後基於架構的考慮（不同層級的分離），搭建整個推薦系統，然後從產品的思維角度去優化，最終產出符合你業務特徵的推薦系統。看著容易，其實操作起來還是有一定困難的。

推薦系統在一般業務規模小的時候，其實鳥用不大的，只有在業務有了一定規模之後，那麼就到了錙銖必較的階段了，使用推薦哪怕增加了5個點的增長轉化，也是極好的，更何況可能遠遠不止呢。

目前很多主流推薦系統都是基於用戶的畫像、興趣愛好推薦的（這是一種相對靠譜，又容易在大規模用戶場景中使用的策略），你越是被他推薦的東西牽著走，你後續就會越陷入其中，最終導致了你所獲取的信息一直都是圈定在某個範圍內的，這就是所謂的「信息繭房」。

其實要形成信息繭房一方面是由於推薦機制導致的，另一方面跟場景也是有很大關係的，比如如果用戶被你所推薦的東西所推動，那麼就容易陷入這種狀態，如果用戶獲取信息的渠道有多種（比如導航、搜索等等），那麼就不那麼容易。

典型如今日頭條，如果在前期你不小心點擊了一些比較low的內容，然後它就越給你推類似的文章，結果你越看，它就越推，於是你所看到的東西都是一大坨類似離譜八卦了。從直觀的角度看，今日頭條重度依賴於用戶的閱讀行為，而頭條又是一個重推薦場景的產品，所以會相對容易陷入「信息繭房」的這種情況。

單純從轉化的角度看來，短期內可能對於系統側來說是正向的，因為他才不會關注到底是不是「信息繭房」，他只關注轉化有沒有提升，但長期來說，對於用戶就是一種損害。所以，我們在考慮設計推薦策略演算法的時候，多多少少都會考慮推薦的新穎性。

但新穎性這東西就是一個雙刃劍，新的東西意味著不確定，不確定意味著可能低的轉化，所以好的推薦系統一定是在確保你興趣的同時，又會考慮新穎，並且這是一種順其自然的推薦信息主體的過渡，構建起你偏好信息與新信息之間的關聯性，讓你同樣有慾望去點擊那些新的東西，不過這就很難是了。

到這裡，整個推薦系列算是真正的收官了，整篇文章也算是一氣呵成了，真乃：文思如尿崩，誰與我爭鋒！

打完收工，整個系列文章：

《推01，你們是不是都覺得自己少了個推薦系統？》

《推02，就算非技術人員也有必要了解的推薦系統常識》

《推03，最最最簡單的推薦系統是什麼樣的 | 附Spark實踐案例》

《推04，融合了用戶興趣的推薦系統才會更具個性 | 附Spark實踐案例 》

《推05，論推薦系統之經典，還得數協同 | 附Spark實踐案例》

《推06，從推薦策略演算法到推薦系統，到數據架構，再到產品設計》（本文）

最後，對於整個系列，有想深入交流諮詢的，有想要案例實踐數據代碼的，請私信我，不過諮詢之前請給我發個99大洋的紅包，我不會客氣的，因為我覺得這整個系列的系統性知識遠不止這個價，你賺大了，如果只是順路路過的，就無所謂啦。

關於我：

大數據行業半個老鳥，我家梓塵兄的超級小弟，會敲代碼、會寫文章，還會泡奶粉哄小屁孩。

想和我交流的，可以加我個人微信mute88，可以拉你入交流群，但請註明身份and來意~

--2018年01月10號23點40分

推薦閱讀：