中午和一前同事一起用餐，發現還是有很多碰撞點的。交流了很多正在做的事情，
對方也提供了非常多的思想值得自己很好的思考。
先是和他聊了下我們現在做內容標籤的進展，其實就是在做內容畫像。我們一般都是在談用戶畫像，其實內容也是要畫像的。
我之前說，內容和用戶是現在互聯網企業核心的兩個東西，用戶的行爲則將內容和用戶連接了起來。
很多人一上來，擼起袖子就開始做用戶畫像，後面會發現，如果沒有對內容做好分析，其實用戶畫像這個東西也會做不好。因爲用戶的行爲是以內容爲承載的，只有把內容畫像做好了，才能進一步提升用戶畫像的品質。而要做內容畫像，其實有兩件事情要做的：
從多個維度刻畫內容的，並且形成對應的標籤體系
如何將這些標籤打在內容上
** 另外在如何做的這件事情上，他也談及了自己的看法，就是要求以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丟進模型，得到是否推薦。
但事實上這套算法，用的就是協同。爲啥的？本質上還是相近的用戶做的選擇互相推薦。
