我們曾經在公眾號上發過一篇文章《年薪百萬的機器學習專家，為什麼不產生價值？》，文中的機器學習專家花了大量的時間搭建平臺，做資料的清洗、處理與機器學習建模，卻沒有帶來公司所期望的價值。問題出在哪裡了呢？

基於第四正規化在機器學習工業應用方面的大量成功案例和經驗，我們今天就來分析一下，想用機器學習提升業務價值，在搭建平臺、處理資料、訓練演算法之前，真正要做的第一步應該是什麼？

我們今天不談技術，不談演算法，不談平臺，但是今天聊的東西卻是機器學習產生價值過程中，最關鍵的步驟之一。

這次分享我們會從幾個方面分析這個問題：

1. 機器學習是不是萬能良藥？我們首先需要想清楚, 機器學習作為特別牛的技術, 它能解決什麼樣的問題。
2. 一個業務問題，可能有各種千奇百怪的坑，假設我們初步判定可以通過機器學習來解決他，那麼應該通過怎樣的轉化，避開這些坑，把業務問題變成機器學習的問題。
3. 如果有一個好的可以轉化成機器學習的問題，我怎麼去設計機器學習的開發節奏，估算它的投入產出比，如何分階段去推動問題的建模和應用。

這就是我今天要介紹的，機器學習的 MVP。

機器學習的最小可用產品

現在的網際網路技術，接受的一個概念是最小可用產品，MVP，就是開發團隊、設計團隊用最小的成本代價，最大程度去驗證產品的可行性。這個產品的可行性，是指這個需求是否真實存在，一個產品滿足需求的方式是不是對的。

機器學習也是一樣的，我們做機器學習的投入是長期的、持續的，帶來的收入和回報也是巨大的，在開始之前，我們一定會希望以比較低的成本知道：現在引入機器學習是否可以影響我們所面對的業務，產生價值的潛力有多大。

那麼把一個業務真正用機器學習做之前，我麼可以用兩步，做一個機器學習的 MVP：

第一步：我們要選擇正確的業務問題，並不是所有的問題都可以套在機器學習的框架裡，有些適合機器學習解決，有些不適合機器學習解決。在任何的技術專案管理中，用差的方法解決好的問題，一定優於用好的方法解決錯誤的問題。

第二步：當我們找到一個機器學習可以解決的問題後，我如何通過最小的時間和人力代價，去證明機器學習可以解決它，帶來滿意的投入產出比。

選擇正確的問題：從分類器開始

首先我們看看機器學習擅長解決什麼問題。我舉一個例子，就是周志華老師的西瓜書講的例子，它很經典，也很簡單，還很深刻，這個問題是說我要判斷一個西瓜是好的還是不好的。

這個問題的業務場景是什麼呢，一個西瓜，我怎麼在不交易、不開啟的情況下，就知道它是好的還是不好的。如果我知道，我就可以用同樣的價錢買到更好的西瓜；而如果我是瓜商，有了一套標準之後，我就可以更好的管理我的貨品。

回到這個問題，一個西瓜是好的還是不好的，這是典型的機器學習二分類問題。首先我們要找到，判斷這個西瓜好不好有哪些可以用到的資料。我們不能把買賣西瓜之後的資料放進去分析，比如買了西瓜之後，我開啟就知道好不好了，那麼這個就沒有價值。

所以我必須在不破壞西瓜的前提下，這時候能用到的資料是西瓜的產地、西瓜的紋路、重量、比重、敲擊西瓜的聲音是渾濁還是清脆、西瓜皮的質感等等，這些不開啟西瓜的情況就知道的資料。

剛剛我們的目標已經講得很清楚了，好的還是不好的，好的是 1，不好的是 0，甚至我還可以定義一個評分，0 到 1 之間的一個數，但總體而言我可以設定一個機器學習的目標，我們稱之為 Label。

選擇正確的問題：真實世界模型

這看起來是一個很簡單的場景，好像一旦我們具備了這樣的資料，就可以嘗試建立機器學習模型了。然而在現實中，當我們想用機器學習來解決實際問題時，也會這麼簡單麼？真實世界中往往是有很多陷阱的。這些陷阱可能有什麼呢？

第一，西瓜好不好，是怎麼定義的？是大？還是甜？皮厚不厚？瓤脆不脆？如果建立這個模型是為了西瓜的售賣，這些因素可能都會評價的因素之一，模型學習的樣本也都需要基於這個標準來建立。如果我們僅僅是基於西瓜大不大來定義樣本，而實際的應用場景是綜合判斷西瓜好不好，那麼可能會得不到想要的好的結果。

第二，西瓜好不好，是以什麼為標準的？是用科學方法和儀器測量的？還是專家評測？如果是後者，評測者是同一個人麼？如果是不同的人，大家對好西瓜的判斷標準一樣麼？ 現實情況中，很可能是不一樣的，那就要想辦法消除 Label 的偏差。

第三，網際網路的場景下，往往是需要滿足所有人個性化的需求的 ，有些人喜歡甜的西瓜，有些人喜歡脆的西瓜，那將問題定義為分辨好的西瓜是否還合適？因為每個人對好西瓜的定義不一樣，這個問題可能就轉化為了推薦一個西瓜給一個使用者，他（她）會不會喜歡。

第四，真實的應用環境是怎樣的？假設我們需要一個線上實時的西瓜分類器，拿到西瓜那一刻馬上判斷它好不好，那是不是有些當時不能馬上拿到的特徵就不能用了？如果好瓜的判斷標準在不斷髮生變化，或者瓜本身的特性在不斷變化，模型還需要能夠跟得上這個變化，基於新的資料和反饋做自我更新迭代，這就是我們搭建模型更新的方法。

可見，即便是簡單的問題，我們都需要思考一下業務的方方面面，理清哪些因素，邊際，個性化要素和基礎設施是要考慮進去的。

選擇正確的問題：業務問題的本來面貌

我們從西瓜還原到業務，任何一個業務能不能做機器學習，我們要看三個要素。

第一，這個業務的目標值是什麼，它不一定是唯一的，但一定有主次。這個目標是否可以量化、收集反饋、客觀觀測的。什麼叫客觀觀測，我說甜和你說甜，這個事情就可能不客觀，那有沒有一個客觀的東西可以反饋。

第二，樣本應該如何構造, 樣本不應該違反因果關係,y=f(x),x 一定是我們業務 場景中所能知道的資訊。在西瓜的問題, 就是開啟西瓜之前我們能知道的資訊, 才可以作為 x。同時，樣本應該符合業務場景的真實情況，假設我們的業務是摸黑挑西瓜, 我們看不見西瓜長什麼樣, 我們只能敲, 那西瓜的顏色就不能作為特徵。

第三，樣本的每一行代表什麼意思，每一行應該代表西瓜的每次測量，然後才是選擇哪些資料作為 x，這些我們已經講得很清楚。

當西瓜的問題說完後，我們來看看真實的業務問題是怎樣的。

1、點選率預估

比如說我們看到的推薦系統問題——點選率預估。

一個推薦系統的目標是什麼？它的終極目標一定是使用者體驗，但這個目標很虛幻，我們要把它量化，變成一系列可以測量的資料，比如說點選、觀看時長、購買、好評等，這些就是 y。

然後我們看有哪些 x，這些 x 代表的是我做出推薦排序的一瞬間，當客戶請求時，在那個瞬間我知道的事情。我能知道客戶的屬性、特徵，我能知道內容特徵、上下文特徵，但不知道最終這個內容是否有被展現和點選。我可以知道內容在這一瞬間之前被點選了多少次，但一定不是這個瞬間之後被點選了多少次，因為這樣就穿越了。

有了 y 和 x，就可以構造樣本了。我的樣本比如說，我給使用者展現了 10 條推薦的內容，這個的反饋可能是點選和觀看，那麼每一次的樣本展現就是一個樣本。

這裡我們可以思考一個有趣的問題，當我們思考不同的特徵對問題的影響時，比如說我們把展現作為一個樣本，一個避免不了的問題是，我怎麼知道這個內容是否被使用者看到。

一種做法是我不去想這件事情，那麼模型可能就是有偏的，比如說你認為這個樣本沒有被點選，但也有可能是沒有被看到，但最理想的是把推薦到使用者手機螢幕上的作為一條樣本。

退一步，還有一個辦法，就是把展現的位置補充回來，作為一個特徵。然後請求的時候雖然沒有這個特徵，但是這個特徵吸收了位置對於展現和反饋的偏差。

2、簡歷匹配

再舉一個場景的例子 —— 簡歷匹配。簡歷匹配是什麼意思？它其實想預測的是，我給企業推薦了一個簡歷，這個人有沒有被企業聘用，這看起來是個簡單的機器學習問題。但是回到業務場景思考，這個問題有沒有這麼簡單？對於內容推薦來說，使用者有沒有點選這個內容，點選後看多久，都是使用者單方面的選擇。

但是簡歷有兩個選擇，第一個選擇是企業通過面試、簡歷的選擇，判斷這個人是否適合企業。第二個選擇是應聘者，他會不會去企業面試，而即便拿到了企業的 offer，會不會被打動加入企業。

所以這就變成了多點、雙向的問題，在這樣的情況下，就需要對問題進行拆解。我們可以不直接做個人被企業招聘的事情，而是分開來做，比如說企業會不會邀請這個人去面試，以及這個人會不會接受企業的面試邀請，這樣就能把問題做的更好。

總結一下我們剛剛所介紹的 MVP 第一步：做機器學習，首先不是著急去建機器學習的模型，而是認真思考這件事情的業務場景到底是怎麼樣的。

解決正確的問題：小結

總結下來一個機器學習能解決的業務問題，有這麼幾個點：

第一它是否能轉化成分類 / 迴歸的問題

第二目標是否是容易獲取、客觀無偏差的資料。

第三是問題的預測目標，因果關係是什麼，因果關係越簡單越好，如果是多因多果，或者說描述“因”的相關資訊不方便獲取，那是否可以拆分成多個模型。特徵往往是因的資料，或者是一些不是直接原因的資料，只要它不破壞這個因果關係。

第四是我們剛剛沒具體去描述的, 就是這個問題是不是一個真的業務需求。

一個真的業務需求是指，在我們用機器學習做出預測後，業務能否可以根據這個預測結果而受到影響？這個影響點是否足夠清晰、有效？因為業務人員會用對業務影響的結果來評估我們專案的效果，如果我們預測的結果並沒有有效影響業務，即使這個模型再好，也不會發揮作用。

比如說推薦系統，我預測了新的點選率後，可以按照點選率倒排來影響業務結果。但如果是遊戲呢？如果我們預測這個人明天有 30% 的機率付費，我該如何影響到他，我能不能影響他？

所以你一定要思考，你的預測結果會怎麼在業務中使用，這個使用會不會對業務產生提升。如果你發現提升本身是很難的，那這本身就是個偽需求。然後你還需要思考，現在沒有用機器學習的業務，它是用了什麼方法和資料，現在的方法和資料有什麼缺陷，哪些是機器學習可以幫到的。

當以上的問題都有清晰的回答後，這時候你就可以提出一個好的問題了。這時候你就成功 80% 了，而剩下的問題都相對簡單了。

機器學習的投入

這是我們 MVP 的第二步：在可控的人力、金錢投入下，構建一個有效的機器學習模型。

那什麼是可控呢？1-3 人月的投入，更多就會風險太高。我們會期望獲得什麼提升？Case by case，不同的業務不一樣，有些業務比如說廣告，1% 的收入就是好幾百萬，而有些問題可能要提升好幾倍才有商業價值。

在機器學習成本分配中，最大比例在機器學習本身，調參、特徵工程、模型評估、模型上線這些工程的事情佔了大量的時間，而問題的定義、資料的採集佔的時間非常小，我們認為這是有問題的。我們認為一個機器學習的專案，無論通過合作還是使用第三方平臺的方式，應該把大錢花在採集好的資料，定義好的問題上去，甚至這要超過一半的時間。而另一半的時間，才是真正做機器學習模型的時間。

降低資料的成本

那我們怎麼降低資料的成本呢？我給大家一些思考。

第一，除非必要，只使用採集好的資料。因為資料採集是一個有成本的事情，當一個公司的體系越複雜，它採集資料的成本就越高，所以除非這個資料採集起來很輕鬆，或者已經有了，你才會去考慮。

第二，如果你要開發新的資料，首先要考慮的是成本。開發新的資料來源是有風險的。機器學習最怕的是說不清楚這是演算法的問題，還是資料問題，還是問題定義的問題，所以讓 MVP 環節中能出問題的環節越少越好。

前面我們介紹了問題定義的問題如何避免，而演算法一般是不太容易出問題的，除非用錯，而資料其實是很容易出問題的，所以我們儘量用簡單、可靠、成熟的資料。

第三，我們講到在建模的過程中，儘量使用成熟的工具。真正在資料處理，特徵計算，和演算法訓練的這些過程中，大量的工作是可標準化，甚至可以用演算法自動優化的，大量的坑其實也是可總結，或者說可以在產品引導中避免的。我們一直在研發的第四正規化先知建模平臺，就是在努力將建模過程中的 know-how 封裝到產品中，讓使用者操作更簡單，而且少踩坑，更有效的獲得好模型。

總結一下，這一步總的思想是，能不製造新的風險點，就不製造風險點，能降低不確定性就降低不確定性。

如何 Review 機器學習的模型？

好了，做好了前面介紹的兩步，我們已經有了機器學習的 MVP，機器學習對業務的影響已經初見結論，如果業務有明顯提升，那麼祝賀你，找到了新的價值增長點，優化後一定還會有更大的提升潛力；而如果效果不明顯，我們這裡再給大家一些關於如何 review，如何檢查 MVP 的建議：

首先要 Review 問題的方向是不是對的，模型的效果是否符合預期，模型的優化目標是否有明顯的變化，比如優化的目標是西瓜好不好，優化之後是不是買到的西瓜好的變多了。如果不是，那就是這個問題沒有解決。那還會有什麼原因？是不是指定了錯誤的目標，用在了錯誤的環境，或者資料有問題。其實說白了，要麼是目標有錯，要麼是模型用錯，要麼是資料有問題，基於這 3 點來檢查。

在現實業務中，解決了一個問題，有時也會帶來新的問題。比如說新聞推薦的系統，現在點選的人多了，那麼是不是由於推薦，新聞變得更加娛樂化了，是不是新聞的點選變得更集中化了，這可能並不是業務上非常希望的，需要繼續想辦法來優化。

第二步是 Review 資料，這些資料裡面哪些起了關鍵作用，哪些資料是經驗上認為會有作用的，但實際上沒有的。那麼重新檢查這些資料，看是不是資料質量的問題，使得沒有發揮應該發揮的作用。還可以看下一步我們可以引入哪些新的資料，資料最好一批一批引入，我加入一批，一次性開發結束。

第三步，當我 Review 上面的事情後，我要制定下一步的方案，往往是我會有新的、更多的資料。我也可能會調整目標，有可能是目標錯了要改，也可能是增加目標，原來一個目標不夠了，我要加入好幾個新的指標，使模型變得更平衡。還有就是在工程上，看效能能不能優化等。

這就是我們這次分享的內容，我們怎麼去推動一個機器學習的專案，問題如何定義，風險如何管理等等。

答疑環

Q1：請問第二目標是否是容易獲取、客觀無偏差的資料？

差的比例有多大，能否定位出來？比如說我們之前做過一個新聞推薦系統專案，每到半夜點選率暴漲，最後我們知道是半夜有競爭對手的爬蟲來點選新聞。我們知道以後就可以對這部分資料進行處理。
第三，在大資料環境下，當資料量大到一定程度的時候，偏差可能會因為大量的樣本以及超高的維度而不再重要。比如說做廣告的人可能知道，點選率是會被位置所影響的，這個資料是有偏差的，那把位置本身也作為一個特徵，並且利用一些特徵工程的手法，可以把這個偏差吸收掉，得到一個無偏的模型。所以有偏差不要緊，想明白原因是什麼，大多數情況總有方法解決他。

Q2: 針對資料不平衡問題，在應用中比較好的解決方法是什麼呢？

田楓：對於機器學習問題，樣本的資料分佈跟現實的資料分佈保持一致是最好的，如果極度不平衡，例如說正樣本極少，影響了建模，那麼也是有一些策略可以用的：1. 比如說過取樣，就是把 label 中佔比少的樣本通過隨機的方式多采樣一些到訓練樣本中。2. 欠取樣，就是把 label 中佔比多的樣本通過隨機的方式取樣一部分，這樣可以平衡樣本，同時還能加快訓練速度，在一些較大的資料集上可以使用這種方法進行初步的探索。3. 通過欠取樣多份訓練樣本，分別訓練模型再做整合學習的方式，能夠充分利用全部資料資訊，同時避免了過於傾斜的樣本對於模型訓練的影響，是一種比較好的方法。

Q3: 先知支援深度學習和 GPU 運算嗎？

田楓：針對金融等領域的結構化大資料，一個“寬”的模型（特徵維度特別高）更有利於在比較低的門檻和代價下獲取好的效果。因此先知目前主要的演算法是高維機器學習演算法，包括超高維 LR。和大規模 GBDT，以及衍生的低門檻免於複雜特徵工程的演算法 HE-Treenet 和 LFC 和大規模 GBDT，以及衍生的低門檻免於複雜特徵工程的演算法 HE-Treenet 和 LFC。對於深度學習這種“深”的模型，一方面，提供支援可自定義層數和節點數目的 DNN 網路的分散式訓練演算法。另外一方面，在先知產品路線上，還有“寬”和“深”結合的低門檻高維深度學習演算法，也將逐步向公眾開放。在對 GPU 的支援上，先知平臺底層的 GDBT 機器學習框架對計算做了很好的抽象，因此可以通過對接 GPU 計算庫的方式獲得 GPU 的加速能力。

Q4: 老師在開始提到了核心也是最重要的首先要考慮的，到底有沒有必要上機器學習平臺？後續才是考慮技術細節的事情。我看到第四正規化提供了先知平臺還能免費使用，這個很棒！那麼後續我們所在企業關於實際業務需求是否需要上機器學習平臺，我們可以從哪得到專業的指導？第四正規化提供這種諮詢嗎？

田楓：我們有個先知機器學習培訓平臺,在這裡會有我們最新的知識庫沉澱，大家可以在這裡學習。另外第四正規化是提供企業機器學習諮詢的。

Q5: 您好，您說“開發新的資料，首先考慮成本問題”，那除了成本，還有哪些考慮呢？

田楓：時間和風險，歸根結底，專案管理就是消除專案中的不確定性。網際網路思維講求的是快，如果速度太慢，會失去市場的機會。所以我們一再強調的是，在可控的範圍內，儘快做出一個有效果的機器學習模型。同時，因為我們談的是開發機器學習的 MVP 模型，一般會出問題的其實是 y 的選擇，資料即便不夠多，其實也能夠驗證。如果開發新資料，會把大量時間都花在了新資料開發上，這對於 MVP 是不合理的。另外開發新資料是有風險的，如果最後模型沒有效果，那到底是資料的問題，還是模型的問題？例如說很多資料看起來開發好了，但是有些地方有很多異常值，這可能會導致最終結果出現問題，但很難找到原因。所以有效控制變數，對於 MVP 也是很重要的事情。

Q6：田老師，講了一個西瓜好壞分類管理的例子。公司電商專案中，對供應商好壞有也有個傳統方法。就是經驗設定幾項指標評分，判斷供應商好壞直接按分來分類管理。請問這問題用機器學習與傳統方法根本區別是什麼，價值是什麼。謝謝。

田楓：由指標生成評分的公式也是一種模型，但是是一種維度比較低的模型。因此如果資料較大的情況下，這種維度低的模型無法充分利用到所有的資訊。我們所說的機器學習可以通過利用演算法和計算能力，使用大的資料生成一個高維模型，從而能夠在指定的業務目標上更準確的判斷“好壞”這種分類，大資料 + 高維模型帶來的準確率提升就是最終可以獲得的價值。

Q7：請問，機器學習專案如何排期？團隊之間需要如何協作？比如說一個推薦模組的優化，不同成員怎麼分工

田楓：首先這件事情取決於您的團隊組成，以及機器學習建設到什麼程度，是否已經有機器學習平臺基礎（包括高維機器學習模型訓練和線上實時預估系統）。因為建設平臺和線上系統本身是一件成本很高代價比較大的工作。這裡以使用我們先知平臺建設推薦系統的客戶來說，主要工作包括：1- 對原有的推薦系統進行開發改造；2- 積累一段時間的歷史樣本，一般至少積累一個週期的資料如一週；3- 基於積累的資料進行模型訓練與優化；4 模型線上試驗。