[[402555]]

導語：機器學習無論是在學術界還是工業界都扮演越來越重的角色，但目前鮮有資料來系統闡述機器學習在學術界和工業界的差異。本文結合作者十余年的工業界經歷，從工業界的視角來嘗試給些思考和總結，歡迎大家批評討論。

工業界需要定義問題在先

在工業界，所做的一切都是服務于業務指標的，常見的業務指標有DAU、時長、點擊、體驗、廣告提升等。但這里業務的問題一般不能直接轉化為學術界的分類、聚類問題，需要工程師結合對業務的理解來做合適的轉換。例如，廣告中要優化變現效率可以對應到CPM，而CPM=BID *CTR*1000 （此處近似，由于計費模式不同，可能略有差異，比如Generalized Second Pricing下使用下一位的出價計費）。 BID一般是廣告主的主觀行為，機器學習算法不適合優化 ，更適合優化CTR，這就是常見的CTR預估。而預估可以用分類、回歸或者排序的思路去做，考慮到用戶對廣告的主觀反饋是點或不點，所以建模成分類而不是回歸。至于為什么很少用排序，則是因為CTR的絕對值也很重要，在競價排序和計費中需要用到。

線上環境一直在變化

在學術界，機器學習是一次性任務，學完這次就不用管下次了。而在工業界，產品一直在線，它學習和作用的環境一直在變，機器學習是個持續不斷優化的過程，這就會帶來幾個非常有意思的問題：怎么保證學習的時效性，持續不斷地學習來適應環境的變化？短期觀測到的效果增益長期真的是有效的嗎？歷史上證明過有效的東西當前還是有效的嗎？ 那些歷史上沒帶來增益的優化現在可能會有效嗎 ？基于當前模型A影響下的行為，我們新學了一個模型B，模型B效果好所以替換了模型A。但模型B作用環境發生了變化（不再受模型A影響），而這種變化是之前沒法模擬到的，怎么辦？

解決問題可以用不止一個算法

在學術界，發論文的套路一般是先剖析一堆算法的缺點，然后基于某個點的發現發明一個新算法，最后用實驗驗證這個算法的效果。而在工業界中，解決問題的套路和這個完全不一樣，你不需要管哪個算法好，也不需要限定一個算法來解決問題。相反，你可以用很多算法來解決同一個問題，無論使用同一個算法的集成還是不同算法的集成，甚至把算法串聯在一起，相互依賴能解決問題都是可以的。學術界的集成學習的相關研究也揭示了對于特定問題集成學習的效果往往是更好的。據我觀察， 牛叉的算法工程師一般都有自己的算法庫 ，當來一個問題時，能同時實驗好幾個不同的算法，迅速組裝出一個基本解出來。

機器學習應用效果如何量化

在學術界，我們經常會用AUC、準確率、召回率、F值等評測算法的效果，這些指標能反應模型在某個維度上的增益，但在工業界，這些指標大多時候是不能直接反應對業務指標的影響。比如CTR模型的AUC漲了，線上CTR、CPM能漲多少是不得而知的？再者，AUC漲了，線上業務的關鍵指標就一定能漲嗎？這個往往是不確定的，整體AUC漲了，不代表頭部排序效果變好了，可能是低于過濾閾值那部分變好了而已，這對線上沒有實際的意義；單個指標漲了，可能對其他指標帶來不可預知的影響，總體可能還是不能上線。另外，線上模型和策略上線往往是并行的，這就會出現 不同算法工程師的工作相互影響 的情況，這個時候要設計好實驗機制來盡可能減弱彼此的影響，比較真實地反映自己小一塊優化帶來的客觀收益。

1）需要更謹慎的樣本工程

在工業界，Y標簽的選取要和業務指標有直接的聯系，樣本直接決定了機器學習優化的目標和方向。比如要優化點擊率，Y標簽自然是點擊或不點擊。但很多情況下，Y還需要經過一些必要的處理才能進行學習。比如要優化播放時長，Y標簽直接定義成觀看時長不一定是合適的，因為有些視頻長有些視頻短。另外，現在用戶基本是在移動手機上來使用產品的，用戶所處的環境可能有很大的不確定性，行為的置信度是不同的。比如，當你很認真的刷手機和很隨意刷手機時候，跳過的那些內容不感興趣的置信度顯然是不一樣的。還有一點，也是容易被忽視的：一個成功的產品涉及到多方的利益， 有不少行為可能不是正常用戶造成的 ，這部分的行為如何區分、建模時怎么對待都是很有意思的問題。

2 ）需要更重的特征工程

在學術界，評測算法一般使用標準的數據集，這些數據集的特征都已制作好，只需要輸入到自己的算法建模即可。而在工業界，特征是算法工程師自己要加工的，且加工的來源也不局限于特定的數據源，會有一個近似開放的數據體系。基于這些數據源，可以持續不斷地進行數據關聯、數據挖掘、特征組合和選擇。算法工程師要利用自己的經驗，來想新特征、特征組合以及新的數據引入。實際上，特征工程占據了機器學習過程中大多數時間，Andrew Ng在最近的一次分享中也提到類似的觀點。另外，不同場景的差異也很大， 在圖像、文本領域這個輸入基本是確定的，看到的就這些原始信息，是一個完備的輸入；而在推薦、營銷等領域，這個輸入是不確定的， 理論上所有影響用戶做決策的因素都對建模效果有影響，這里的特征工程會更復雜。

不同學習任務耦合是難以避免的

在工業界有種特殊的數據耦合現象--一個機器學習任務的輸入是另一個機器學習任務的輸出，這種耦合幾乎是沒法避免的，因為以下一些原因：分工協作的原因，一個算法團隊有很多工程師，大家分頭解決不同的問題要；從單任務可學習的角度，它的學習應該聚焦于本任務自身，而不應摻雜其他目標，否則會加大學習的復雜性；出于架構簡潔的角度，分層、分模塊是很自然的架構設計，層、模塊間的依賴也很自然。但在機器學習里，這種 數據耦合是個風險很高的事情 （不同于軟件工程里的代碼耦合），因為下游沒法保證你的上游不發生問題（可能僅僅是數據分布的變化，而不是什么大的BUG），這個時候怎么降低這種風險就很關鍵。

要優化的目標不是唯一的

在學術界，確定一個問題后優化的目標往往是唯一的，研究者只需優化好這個指標就好了，而在工業界，一個業務往往有好多個關鍵指標，比如DAU、點擊率、時長、完播率、多樣性、冷啟率、頭部大v的穩定率、廣告效率等等。這些指標雖然可以單獨拆解開，但往往之間是相互影響的。這個影響是個很復雜的關系，不是單純的相關或獨立，而是耦合在一起，甚至說不清楚。雖然我們可以用機器學習各個擊破，但還需要在應用學出來的模型時把他們綜合在一起，這就導致了一個嚴重問題----可能某個單點我們學得很好了，但綜合用的時候反而對其他指標有不可預知的危害。那你可能會很自然地提出來一個問題，為何不搞個多目標問題直接用機器學習來學呢？可以當然是可以，一起學模型相互輔助當然是好的，但你可以細想一下，這種 真的解決了多目標耦合甚至沖突的本質問題了嗎？

工業界的機器學習是受約束的

機器學習系統核心要解決的問題是如何建模和上線，但它的輸入和輸出都依托于業務系統，它和現有業務系統的交互是否順暢是直接決定學習效果的關鍵要素。在這個前提下，業務系統原有的一些約束會直接加到機器學習系統上，比如如果業務后臺是C++的，那么你的機器學習這套系統最好也是C++的，這樣就會減少很多不必要的兼容性問題。還有一點，機器學習系統往往是后于業務系統來建設的，需要對業務系統的進行改造，比如必要行為的埋點、數據上報通路、降級處理等等，都是要反復驗證的。最后， 業務系統本身性能永遠是第一位的 ，在這個前提下對模型性能的要求基本也是限定死的。要在這個前提下完成特征處理、模型預測等等操作，要做好性能和應用效果的平衡，選擇最合適當前情況的算法上線，這也是為什么LR在相當長一段時間內都是業界的主流算法的原因。

寫了一兩個小時，發現還有很多新的點可以繼續講講。由于時間關系，今天就先寫到這里吧，姑且作為上篇，敬請期待下篇。