推薦系統之內容畫像
中午和一前同事一起用餐，發現還是有很多碰撞點的。交流了很多正在做的事情，
對方也提供了非常多的思想值得自己很好的思考。
先是和他聊了下我們現在做內容標籤的進展，其實就是在做內容畫像。我們一般都是在談使用者畫像，其實內容也是要畫像的。
我之前說，內容和使用者是現在網際網路企業核心的兩個東西，使用者的行為則將內容和使用者連線了起來。
很多人一上來，擼起袖子就開始做使用者畫像，後面會發現，如果沒有對內容做好分析，其實使用者畫像這個東西也會做不好。因為使用者的行為是以內容為承載的，只有把內容畫像做好了，才能進一步提升使用者畫像的品質。而要做內容畫像，其實有兩件事情要做的：
- 從多個維度刻畫內容的，並且形成對應的標籤體系
- 如何將這些標籤打在內容上
** 另外在如何做的這件事情上，他也談及了自己的看法，就是要求以Spark的Mlib為載體，儘量所有人共用一個演算法平臺。 ** 我詫異的說，竟然和我的想法不謀而合。他說這樣做的好處是大家資訊共享會更快，同一個平臺也更好維護。我進一步補充，其實如果每個人都有Google工程師的水準，其實倒也不用限制在一個平臺上，但事實上如果每個人都堅持自己擅長的方式，其實隱形成本非常高。
比如，演算法工程師寫了一個巨牛逼的演算法原型，然後他需要先給工程師講懂這個演算法，工程師看個人水平，先不說能否將演算法實現，實現所花的時間，以及是否真的有時間和精力去幫著實現，實現的是不是有問題就是一個很大的問題了。來回一折騰，兩個人都會比較累。當然，我前面也說了，如果都是Google工程師級別的，事情自然能更快。如果大家都使用spark 平臺，這種交流成本小非常多。研發工程師只要將演算法工程師已經寫好的spark程式碼做些調整優化，估計就可以直接上線看效果了。所以我做的更極端一些，要求演算法工程師用到的演算法都必須是Spark Mlib現有的，或者有能力自己實現的，不能單機去Lib跑跑就行。
** 他還問我說，怎麼才算對演算法有了真正的理解。** 這個問題真的把我問住了，我之前肯定會說，知道什麼場景使用什麼樣的演算法，就足夠了。但是現在真的靜下心來做，發現不是這麼一回事。
我們先談談，怎麼知道什麼場景，使用什麼演算法。首先我們要知道具體場景能對應到一個什麼類別的問題上。是一個聚類的問題？一個分類的問題？還是一個迴歸類問題？定義了類別之後再去找對應的演算法。比如聚類可以使用KMeans,LDA,K近鄰等，分類可以貝葉斯，SVM等。然而你會發現，其實還是太簡單了。
一個場景要解決的一個問題往往不是這麼直觀明顯的，就如同我們上面提到的構建內容畫像的問題，就得到了兩個子問題，每個子問題又需要劃分成好多個步驟，每個步驟可能對應一個或者多個演算法問題。
但是就算這樣，也還是是遠遠不夠。因為我們即使做到了具體知道該使用哪個演算法，但是一用，發現效果完全不是那回事。這個時候我們至少需要了解兩方面：
- 演算法的核心是什麼，有什麼潛在的需求？比如是不是對資料的分佈做了什麼假設麼?
- 特徵和資料集的情況是如何的
而且很多演算法做了很多很粗暴的假設，這種假設會導致演算法存在一些固有的問題，如果你不瞭解其內部的這些假設，你會以為這些是他的一個特性，其實是一個缺點。比如Gini Importance，如果你不去了解的內部思想，你在理解資料時，就會造成誤解，導致錯誤的認為先被選中的特徵是很重要的，而其餘的特徵是不重要的，但實際上這些特徵對響應變數的作用確實非常接近的。
** 做公式推導到底重不重要呢。** 我們常常覺得那些對演算法裡的公式能做推導的人，很牛，能做到這點，自然值得鼓勵和欽佩，但是我覺得演算法和能不能推導公式是兩碼事。我可以把演算法裡的每個公式拎出來，找個數學系的人進行推導，它可能比較輕鬆的搞定。但是我們說他懂得這個算了麼？他連演算法是什麼都不知道，對麼？ 所以從工程轉過來的人，一定不要為此覺得有什麼障礙，其實我們可以忽略公式的本身推導過程。
我有時候覺得，引用演算法工程師最流行的一個話，就是tricky。 中文我不知道怎麼翻譯更合適，很多時候是需要悟性和對事物本質的瞭解，才能瞭解一個演算法的，絕對不是靠幾個公式就能搞定的。
協同演算法是我們應用的比較廣泛的一個演算法。** 但是我覺得協同不應該算是一個演算法，而是一種模式。 ** 我們常見的很多模型，最後都是協同模式。舉個例子來說，是不是個A1使用者推薦文章B1,我們可能是這麼做的：
- 把使用者用向量做表徵，文章也是
- 觀察大量的使用者A2,A3...AN 是不是有點選該B1
- 使用邏輯迴歸/SVM等分類演算法訓練模型
- 把A1,B1丟進模型，得到是否推薦。
但事實上這套演算法，用的就是協同。為啥的？本質上還是相近的使用者做的選擇互相推薦。
作者：祝威廉
連結：https://www.jianshu.com/p/d59c3e037cb7
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。