天貓推薦算法團隊的那些事兒
天貓技術部算法組是一個相對比較新的團隊，剛剛成立一年，目前有 10 個算法工程師和 5 個開發工程師。這個團隊所負責的內容是天貓上的數十個推薦產品，這些推薦產品幫助消費者找到他們喜歡的東西，將用戶跟商品匹配的路徑縮短。當然對天貓平臺來說，推薦算法的價值在于提高轉化率。從去年的雙十一開始，天貓技術部推薦算法組第一次將推薦產品引入到了雙十一大促活動當中。
2014 年，阿里巴巴集團舉辦了阿里巴巴大數據競賽，大賽的規則、題目、比賽數據、評價標準與評審，都是由算法組負責。最近，InfoQ 中文站采訪了這個團隊的負責人張奇（得福），了解天貓推薦算法組的團隊情況與工作內容。
嘉賓簡介
張奇，花名得福，2010 年畢業于中國科學技術大學計算機系，信息檢索方向博士。2010 年 7 月加入阿里云計算， 搜索廣告組，從事搜索廣告算法研究，參與 Yahoo 中國搜索中搜索廣告的排序算法設計，負責了國內最大規模之一的，每天近 40 億網頁瀏覽記錄的挖掘、用戶行為分析和 User Profile 建模。2012 年 3 月加入天貓產品技術部，推薦算法組，負責天貓推薦算法的改進和數十個推薦業務的優化，包括 PC 推薦業務、無線推薦業務，建立起一套基于機器學習的推薦算法流程。
InfoQ：簡單介紹一下天貓技術部推薦算法組的職責和團隊分工？
得福：推薦算法和搜索、廣告系統類似，很多模塊之間都有上下游關系，如分析用戶偏好興趣，采集用戶點擊、購買行為，計算用戶現在想買什么，比如想買連衣裙還是t-shirt，連衣裙是日韓風格還是歐美風格。還有的組做排序，比如有一堆的商品，連衣裙，天貓有幾十萬款連衣裙，給用戶看什么？這就需要先做品牌、價位的篩選，再有個性化排序，給每個商品計算分數，通過預測點擊率、購買率，來給候選商品做重排序，這樣選出 10 個、20 個商品給用戶看。另外還有一些固定的物理屬性，如用戶的性別、收入水平等。每個模塊都有上下游關系，不同的人做不同的系統。每個推薦流程都有用戶行為分析、商品檢索、個性化排序、返回前臺的過程。
產品上來說有不同分工，我們這邊也是 PM 制度：比如一共有 40~50 個推薦產品，如果有新的產品要開發，就需要 PM 來協調上下游的模塊的同事一起去完成。PM 跟運營或 PD 溝通需求是什么，需要我們怎樣支持，需求怎樣拆解成現有的推薦算法能夠支持的模塊，然后安排各個模塊的同學去開發，還要監控上線之后產品的效果，效果好或不好，有數據報表，不好有改進意見。每個產品都要有同學去負責。
整個推薦分商品推薦、品牌推薦、活動這三種，如果一個同事對某種類型比較熟悉了，跟對應的業務方也非常熟悉了，可能他就專門把這個類型的產品負責好。商品推薦比較廣泛，推薦比較多，就要分給不同的同學。總體來說，這一塊在系統上是橫向的劃分，業務上是縱向的劃分。
</blockquote>InfoQ：你以前做的是阿里云搜索。搜索和推薦產品上從算法和產品的角度來看，差別大么？
得福：算法和產品都不太一樣。算法方面，搜索是處理帶有明確意圖的 query，很多工作都基于對 query 的理解上面，包括 query 怎么分詞，如何抽取有用的信息，包括品牌、商品型號、類目等，就是通過 query 的關鍵詞抽取來反映用戶意圖，然后做查詢、排序。推薦的話，用戶不會輸入 query，他們用自己的行為表達自己的興趣。對我們來說這更困難，你要從非常多的行為里把用戶的興趣抽象出來，我們需要做很多用戶意圖理解的模塊。這是兩者在算法上最大的區別。
產品方面，搜索是一個通用系統，固定的產品形式就是有一個框。推薦的產品可以有很多變種，不同行業也不一樣，比如服裝可能是基于風格、搭配來推薦，書籍、音樂則是另外一種推薦方式，比如書籍要考慮話題、類別、知識水平，所以比搜索來說，產品形式會更加復雜。
InfoQ：驗證新算法會有 AB 測試吧？怎么做的？
得福：我們的測試有兩種，一種離線測試（線下測試），一種線上測試。一開始我們都做線上 AB test，你拿5% 或 10% 的流量供測試，95% 或 90% 的流量作為基準，然后你可以做參數變動或算法調整。這是以前。后來我們考慮到，因為同時會有很多算法想要做測試，一方面流量有限，而且對天貓來說流量是非常值錢的，每個用戶可能只有 20 分鐘或者 30 分鐘，所以一個算法如果未經驗證就到線上做 AB，其實是很浪費流量的，對用戶的體驗也不好，5% 或 10% 的用戶可能會使用一個非常差的版本。
所以漸漸就開發了一套離線評測方法，不需要線上流量就能測試：它用以前的日志去模擬現在的行為，相當于把日志作為模型的輸入，看不同版本的算法在日志上跑的結果怎么樣，來判斷這個東西放到線上后大概的效果。這種系統不會 100% 準確，離線結果A比B好 10% 并不表示在線上也是 10%，但一般如果離線顯示A比B好，那到線上A一般也會比B好，好多少不一定。我們用離線方法就可以淘汰很多不太靠譜的算法——A如果比B明顯要差，我們就可以去掉。只有A比B好，我們才拿到線上測，保證流量能夠被充分利用。另一個好處是，離線測試十分快速，因為處理日志跑起來是很快的，可能十幾分鐘就跑完了很大的用戶量，而線上一方面流量少——不可能切換太多過來，同時你需要看很多天，效果才能穩定下來，可能需要一到兩周才能看出效果。
所以這兩個方法現在我們同時在用，互相補充。
InfoQ：天貓算法跟產品相關性比較大，會有很多跟產品的溝通。而你們也在產品開發更下一個層面。跟 PM、PD、運營的溝通模式是怎樣的？
得福：PD 是我們的需求方。PD 沖在最前面，跟業務靠的比較近，甚至會跟業務綁在一起。PD 去了解業務的需求，然后提前跟我們交流需求是否合理，如果合理且我們能接受開發量，就回去寫 PRD、MRD 這種文檔。這可能會涉及很多個開發團隊，就要把開發團隊的工作量、時間都安排好，最終確定一個上線時間。
一般 PD 會先寫 MRD，證明該產品需求是合理的。再寫 PRD，對產品進行詳細的功能描述，分哪些模塊，誰來開發，都要涉及。最后會有 PRD 評測，所有相關方都會到，如果有意見會讓 PD 去改。如果大家覺得 OK，PD 需要指定 PM 和最終上線時間，如每個團隊在哪些時間點要提供哪些接口出來，測試時間等等。
InfoQ：你們在去年完成了多少項目？
得福：我們不是按照項目的個數來算工作量。我們總體的評價是，通過推薦幫天貓帶來多少成交，這是我們最重要的指標。這些指標的實現過程有很多小項目累加，包括新項目的開發和老項目的優化，目的都是提高轉化率，不會拆的那么細。
其他具體的方向也有一些，比如無線的產品創新做的如何，或者大賽的支持等等。
InfoQ：你在去年最值得分享的成就是什么？
得福：雙十一。去年是我們第一次在雙十一嘗試這種千人千面的推薦方式，而不是純賣場的方式，我們是第一次做這種嘗試，也突破了很多阻力。當時開發非常辛苦，也不是很高科技，很多跟運營一起的工作，數據都是 excel 來傳遞，自動化系統都沒有準備好，因為系統沒有打通，所以很多人肉的工作，非常痛苦。那段時間加班很多，容易出錯，很多時間用來做協調的工作，不過最后效果還是很好的，轉化率比原來那種賣場方式能提高 10%~20% 左右，給業務帶來比較多的價值。
InfoQ：轉化率是對整個團隊的考評。對于每個人的考評，你們是怎么做的？
得福：我們對工程師個人的考評主要分三個部分：1、業務推動，比如承接了哪些新產品開發，在過程中起了什么作用，是 PM、模塊開發還是數據報表開發等。如果作為 PM，對推動業務做了什么，比如老業務上去可能效果并不好，你是否通過一些主動的行為——如改變產品形式——來把它的效果提升。這是很大一塊。2、技術工作，如你在這段時間有沒有算法方面的創新？數據結果有沒有做產品化、工具化，把之前做的工作總結、凝練、抽象出來，讓別的同學也可以去用？3、團隊貢獻，如你是否做了一些對其他同學支持、分享的工作。這個跟前面兩個也有關系，相當于是從前兩個部分中抽取出跟團隊支持相關的內容來進行評估。
InfoQ：任務的分配是指派的，還是大家可以自己選擇感興趣的方向？
得福：一開始肯定是指派的任務。到你熟悉整個業務了，或者對某個方向掌握非常好了，就會放手讓這個同學去做某一塊的業務，不需要 team leader 去管。一般可能需要半年時間。
InfoQ：你們的團隊招聘主要是什么渠道？
得福：我們的社招不多，應屆生和轉崗比較多。對應屆生，如果是研究生，我們要求他要么是工程能力很好，項目的深度、廣度掌握的比較好，跟我們的方向比較一致，要么是研究做的比較好，論文質量高。社招的話，因為他有經驗了，我們主要要求他的經驗跟我們的方向比較一致，同時他在之前公司做的結果比較好，做成功過一些項目，對項目細節和全局都能掌握的比較好，算法能力也比較好。我們對社招的要求比較高，名額也緊張，通過率比較低。
InfoQ：對這次的天貓天池算法大賽有什么期待？
得福：其實我們以前沒想過這個比賽會做的這么大，原來我們只是覺得好玩就行了，在小圈子里面有興趣的同學來一起玩，加強算法交流，也沒有想限制在學生的范圍，而是希望其他公司的同學也可以來一起玩，通過這個比賽加強交流，也認識認識其他公司的團隊。
后來這個比賽做大了，做到集團層面了，整個集團層面可能希望有一些校招的效果，對我們來說也是更好的事情。如果有很好的學生愿意過來，我們當然非常高興。不過我們更希望大家更純粹的在這個平臺上進行比賽。
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！