<b>為什麼做推薦?</b>
推薦本質上并不是一個很新的話題。從很早開始，尤其從網際網路出現之後，大家面臨一個問題，我們怎麼樣從海量的資料裡獲得自己需要的内容？這實際上也經曆了很長的過程，最開始的時候并不是推薦，而是分類導航。做分類導航最好的公司就是雅虎，那個時候網際網路的資料還不是特别多，可以通過人工或者一些簡單的分類方法整理出一個目錄出來，大家就可以按這個目錄一層層往下走，比在原來在網上找好很多。但分類導航由于分類的标準不一樣，人和人認知的差異性，後來谷歌的出現促使了雅虎在這個領域的沉寂。
搜尋就是下一代解決從海量資料中擷取資訊的方法。隻要知道想要什麼，就可以通過搜尋拿到八九不離十的結果，但前提是你想要知道你想要什麼。很多時候你不知道想要什麼，比如看淘寶、新聞，沒看新聞之前一定不知道我想了解什麼東西。是以搜尋是一種主動擷取資訊的方式。
搜尋之後會有一些新的東西出來，比如個性化推薦，它是建立在對使用者興趣或者愛好了解的基礎上，有針對性的展示一些内容。時代一直在發展，今天已經進入了移動時代，移動時代最大的好處是我們可以通過手機，随時随地的了解各種各樣的資訊，随時随地的上網，壞處是手機的螢幕實在太小了，不管做分類也好還是搜尋也好，都不是特别的友善。是以在移動的時代，推薦一定是未來下一個爆發點。總的來說，從分類到搜尋到推薦，本質上都是為了解決資訊過載的問題。
<b>搜尋引擎</b>
到了今天這個時代，推薦一定會發揮更大的作用，但這裡有一個問題，比如搜尋、廣告、推薦，這是整個網際網路在大資料領域幾個經典的應用，作為搜尋來講，這個體系的架構已經非常清晰了。比如有一個使用者首先有一個query進來，建構一個解析，有一個索引，之後會有一些資料的準備等等，最後再采集使用者的行為，最後産生這樣的資料閉環。如果自己想搭一個搜尋引擎的話也很簡單，有各種各樣開源的東西可以用。如果不想用開源的話，還有很多搜尋的服務，比如谷歌、百度、bing，在自己的網站内嵌一個他們的服務也很友善，這一塊都已經非常成熟。
廣告也同樣，整個體系架構是在使用者和廣告商之間搭了一個橋，使用者看到媒體，媒體通過ssp、adx和廣告需求結合起來，dmp提供資料方面的支援，相當于使用者畫像的支援。
<b>推薦系統？</b>
但是提到推薦場景，我們看到的完全不一樣，上圖所有的公司都在推薦裡做的相當好，他們自己玩的很轉，系統也很漂亮，但問題是這種能力我們怎麼把它用起來？也就是說對于一般有需求的使用者來講怎麼樣在自己的系統裡搭一個推薦引擎？海量的資料、各種各樣的行為、算法，對一個新手或者對這個行業了解不是特别深的人來講确實有很大的挑戰。原因如下：
<b>需求。</b>對廣大推薦的要求來講，其實大家的需求都是不太一樣的，比如從推薦的内容來看，有可能是商品，有可能是新聞，甚至有可能是人，各種各樣的東西。資料的來源也非常不一緻，有可能爬蟲爬來的，也有可能自己自己買來的。這與搜尋不一樣，搜尋大部分都是文本，但不排除圖檔搜尋這種新的内容，但基本核心的還是在文本搜尋。對推薦來講這些東西還是有不小的差別，比如音樂往往不可能非常類似。如果我們想從一個比較高的層次看這個推薦的話，大家會覺得非常非常亂，不容易看到一根主線，這可能是一個最重要的原因。
<b>系統。</b>如果我們想搭建這樣一個平台的話，必要的系統支援也是必不可少的。如果還是基于原來方式，自己堆幾個伺服器，在上面寫幾個程式說希望這個東西能服務到很多的使用者，基本上也是不太靠譜的。這裡面我們要考慮的東西很多，比如離線計算、線上計算、日志采集，還得考慮自定義中的性能，比如吞吐性、安全性。
<b>動機。</b>最後一個可能也是最重要的，就是動機。達未必兼濟天下，窮難以獨善其身。
對于這幾種情況，我們應該怎麼來解決？
<b>概念抽象</b>
對于需求，我們可能會需要對整個系統或者整個應用的情況做一個抽象，這個抽象至少能幫助我們把整個推薦裡面一些關鍵的資訊拽出來，至少能在一個架構的層面上做一些東西。阿裡雲的口号是無法計算的價值，我們希望建構一個在雲環境裡的計算生态，推薦其實是一個很好的應用入口。不誇張地講，據原來的一些統計數字，國内在推薦這一個領域裡，自建或者通過合作的方式共建的客戶的數目，大約在10萬能量級。就是如果說我們能把這個領域的能力能推廣出來的話，對阿裡雲來講一定是一個很有競争力的點。是以從動機上，對我們來講是非常有動力來做好這件事的。
怎麼解決？可以從兩個角度來講，大資料一般會講到三個字，存、通、用。存其實是一個很簡單的要求，基本上你想做資料，這是一個必備的條件。概念抽象，其實在這個地方起的就是通的作用，把不同的領域或者不同實力下的要求串起來，抽象到一個相同的層面上來看。基本上可以從幾個方面來看，首先我們會有一個使用者物品和行為的基本對象的概念。我們要做推薦首先要有使用者、有物品，要把物品推薦給使用者，物品和使用者之間其實是通過各種各樣的行為發生關系，當然這個行為的種類就有很多了，物品的種類也有很多，使用者的情況也很複雜，具體怎麼複雜先暫時不要管。格式規範，比如使用者有一張表，把所有不一緻的東西隐藏到裡面，用一個很長的kv的串記錄下來。物品的表，行為的表，這裡面的行為的話，其實是可以自由擴充的，并不局限在這些列出來的内容裡。比如一些跟視訊相關的，可能會有播放、暫停、快進。這些行為一定是與具體的業務類型是有關系的，不太可能能枚舉到完全，就算枚舉到完全，沒有足夠的資料訓練後面模型的話，這種枚舉也是沒有意義的。最後是日志埋點的規範，這一點也是相當重要的，它搭起了雲上推薦引擎和用戶端展示的前端之間的橋梁。
資料已經通了，怎麼用？我們不太可能去針對每一個業務去給它寫上很多專門的算法或者專門的設計，我們也需要有一些相關的概念上的考慮。我們的做法是把它給做成了三個基本概念，第一個是業務，可以了解為就是一個資料的集合。剛才說資料有使用者、物品、行為，業務就可以裂解為使用者、物品、行為三張表，不同的使用者或者不同的推薦物品，就會對應到不同的業務上去。比如現在打個比方，現在有一個app，這個app既可以推薦商品，也可以推薦跟商品相關的新聞，可以有兩種做法。一是把物品分成兩塊，一是新聞，二是商品。另外一塊可以考慮把商品和新聞看成是一個抽象的物品，他們之間可能會有一些相似的特征，把這些相似特征列出來或者取一個并集或者做一些其它方面的處理，把它變成一個新的東西，我們所有的推薦就是推這個抽象的物品。完了之後，真正在選擇真實東西的時候，可能會根據這個特征，根據物品的真實情況再來做一個計算來選擇，這個地方其實定義的就是業務。
第二個是場景，首頁推薦的話，大家很容易想到一個使用者進來了，我現在大概隻能看到這個人是誰，其它的資訊我可能都不知道。是以這個時候我的推薦可能隻能猜一猜他可能喜歡什麼東西，所謂的猜你喜歡。第二個是詳情頁，是說我在看具體某一個東西的時候，你給我展示跟這個東西相關或者相似的東西。這個時候其實我們可以用來做推薦的選擇的參數就會多一些，除了這個使用者之外，我們可能還會看一看目前看的這個東西是什麼。第三個是搜尋場景，除了人可能還會有一些搜尋的關鍵詞，我推薦的結果要和這個人和關鍵詞都有一些關系。但它和搜尋不一樣的地方在于，搜尋可能更多的考慮我給出來的結果和我輸入的關鍵詞是不是比對，可能不太會考慮使用者在這個裡面的一些情況。但推薦的話，一方面要考慮關鍵詞的比對度，另外還要考慮使用者本身的個性。還可以擴充一點推薦的結果，未必跟搜尋的關聯詞做很好的比對，比如說我們搜一個汽車，比如你想買車或者想看看跟汽車相關的新聞。比如我今天搜的是寶馬，搜尋出來的估計都是各種各樣的寶馬新款，你給個奔馳也不是不可以，但好像跟你這個結果不是特别好。但如果給到一個五菱弘光這可能扯的比較遠。在推薦的時候，如果這個人可能收入不是很高，平常對汽車也沒有特别大的興趣，他突然搜了一個“寶馬”，這個時候關于使用者的畫像更多一點的話，推薦的結果可能是像有一些八卦的新聞，不如甯願坐在寶馬車上哭也不願意在自行車上笑這樣的東西，這些人搜尋的東西，我們猜測想看寶馬車主花邊新聞之類的東西，這些可能跟搜尋的場景不太一樣的地方。是以綜合下來看，他們共同的特點是什麼，其實就是反映在我在做推薦的時候，我能拿到什麼樣的參數，不同的參數導緻的推薦的要求和推薦的結果都是不一樣的，是以這一塊我們把它叫做場景。
最後就是一個算法流程，它其實是對場景的具體實作。比如我要做首頁推薦猜你喜歡，這可以有很多不同的方法去做，每一個方法可以做成不同的流程。這個概念一層一層往下越來越細，一個業務有不同的場景，一個場景可能有不同的實作方法，這是關于産品抽象化的概念。
<b>平台支援</b>
對于系統，其實剛才已經提到了需要一個很大的平台來支援，我們不能指望說什麼事情都從輪子開始，一點一點往上造，造到最後造出一個航空母艦來。再看一下平台的支援，首先看看離線的計算和存儲，這些都是阿裡雲現在已經在公有雲上正式上線的元件。線上計算和存儲比較多，像流計算、steamcompute等；資料傳輸；監控預警；資料開發方面；彈性擴容的能力，像彈性計算、虛拟專有雲。正是建立在這些強大的平台能力之上，其實我們才可以來做這個推薦的雲服務的功能。
<b>商業模式</b>
動機就是取決于一個商業模式，公司的驅動點到底在哪裡。
<b>阿裡雲推薦引擎架構</b>
上圖推薦架構與一般的推薦系統沒有太大的差別，隻不過架在雲上而已。前端是一個展示頁面，是客戶自己的，通過規範的資料采集，把日志收上來，可以通過實時的方法收，通過api的方式送出，也可以通過離線的方式傳，這邊有一個資料內建，可以做一個資料的傳輸，把它傳遞到我們需要的各種各樣的地方去。
至于這下面的平台，推薦引擎一方面推薦了相關的算法，一方面把算法的能力以api、saas的方法推出來，并且平台是搭在虛拟機上的。
如果我們想用的話，怎麼樣來使用這個推薦引擎，其實一共分成五步。其實做好前面三步的話，這個事情也就ok了。首先是資料上傳，第二是做配置、業務場景。我的資料要告訴這個推薦引擎資料到底在哪裡，我想做什麼樣的推薦，把這些定義好之後要選擇一些算法來完成這個工作，有一些模闆其實我們都已經配置好了，直接選擇就可以了。如果說我們提供的這些東西不滿足要求，那你可以來做一個自定義開發。為什麼推薦的這個産品沒有能得到大規模的普及？這一塊的功能其實作在都支援的不是太好，如果想在别的系統裡嵌入一段自己的代碼會有各種各樣的擔憂，比如安全性。但現在阿裡雲很好解決的這個問題，包括可以支援大家做自定義的開發，我們提供了一些預設東西随便用，如果覺得不好用的話，也可以修改，很多時候有一些業務規則也可以重新設定。
雲計算可能有排程，推薦結果來了這個使用者，怎麼把這個結果拿回來，擷取一個結果，然後我們的使用者産生一些新的行為，日志怎麼能實時的回報回去，另外是有一些新的物品，新增的東西，我們希望能很快的推薦出去，也可以通過這些接口實時的回報回來，背景會做一些計算。
這些東西內建完之後，其實整個系統可以工作了，問題不會太大。後面這兩件事主要是做額外的輔助，一是日志埋點，目的是為了生成效果報表。在算效果的時候，需要能區分出來哪些行為或者哪些轉化是推薦帶來的，哪些轉化是産品本來就有的，是以需要做一個埋點，把推薦帶來的轉化和原來自有的轉化區分開。
<b>使用者基因分析</b>
如果我們能把使用者做選擇的背後原因搞清楚，其實我們很多時候就可以做出準确的預測。其實基因分析做的就是這樣一件事，首先根據使用者的行為做一個因子分析，這個因子分析的目的是為了分析各個行為所代表的權重。不同的領域裡，大家的行為一定是不一樣的，既然大家的行為都不一樣，那你想做一個統一的産品方案是不太可能的。基因分析是把各種各樣的行為做了一個統一的處理，具體來說，把行為分兩類：第一類是目标行為。就是希望我們使用者去做的行為，比如對電商來講，我們希望使用者買東西；對視訊或者音頻網站的話，我們希望使用者把這個視訊看完或者把歌聽完或者下載下傳完，這是我們的目标行為。剩下所有的行為，比如收藏、點選等等行為，其實都是為了我們最終希望他做的那些事情在做的準備，基于上述行為我們可以訓練一個模型，即用基礎行為去預測目标行為的機率。實際上就可以把這些系數當做行為權重的因子。是以，我們現在的産品裡有多少種行為，其實我都不太在乎，隻要能把這兩個東西能分的出來就好。
特征抽取後獲得物品的一些各種各樣的屬性，比如對于歌來講，會有很多的風格、歌名、專輯、歌手等等，這樣會做一個特征抽取。現在說起來推薦的話，可能深度學習是無所不在。但實際上推薦裡用的深度學習的模型一般不會超過三層，其實本質上這些事情都是比較淺層的東西，你搬一些東西進來可能效果好一些，因為加了非線性的東西進來，但其實用比較樸素的方法做也不是不可以，速度反而快一些。
特征抽取完之後，會得到一組特征的向量，總會有一個特征來基于它的内容。這一步其實隻是做了一個轉換，原來這些特征是針對歌曲本身的，此時就把特征變成人的特征，如果把這個特征打在人身上就了解為人對這個東西的偏好。怎麼做呢？每個行為的對象（歌）都有屬性，行為有系數、屬性，乘乘加加就可以了。一般來說這個過程會很長，是以要降維。
<b>實時修正</b>
實時相關是很正常的需求，一般推薦都有這個問題，第一是新物品進來了我們怎麼辦，我們希望能很快的推出去。使用者發生一個新的新聞，我們希望這個行為能對這個使用者本身做一些修正。歌曲來了之後，第一步要做一個特征的計算，計算完了之後，要做一個反向索引，這裡一定要降維。第二是我們現在有一個人，對一個物品産生新的行為想看看怎麼調整使用者的特征。前面說了每一個行為有一個因子，把所有的因子乘乘加加可以得到一個修正的向量，一般來說我們希望它的行為要比作用大一些，我們要把這個α通常放大5～10倍，這樣會對後面的結果産生比較明顯的影響，是以這些東西其實還是比較簡單的。
<b>行業解決方案</b>
上圖是我們現在做的一些行業的解決方案，系統架構包括離線、靜線和線上。對于内容導購這個領域來講，内容領域可以了解為現在電商發展的新的模式，原來大家做廣告推這個推那個，推多了看的不太爽。但如果做一些比較高大上的方式，比如我賣酒，給你講酒的浪漫故事等等。内容營銷就是這個意思，目的是導購，但手段是内容，是以本質上來講是需要根據這些内容來做一些營銷方面的工作，内容分成這幾塊，pbc、ugc、達人。其他的東西也都差不多，把離線做一個比對，線上做一個調整，大概是這樣。媒體咨詢也差不多，媒體這一塊可能會對實時要求比較高一些，因為新聞總會有一些新的東西盡量，是以在新聞會做的比較強一些，其它都差不多。