【ML專欄】【2018Q1】（4）眾包vs有監督學習

05-16

TL;DR

在數據極其稀疏的場景適合ML；在數據不那麼稀疏的場景適合以ML結果為初值，長期轉化為眾包人工標註。
數據稀疏與否與特徵工程方式和業務需求有關，隨著全行業對特定領域認知的積累，之前稀疏的場景未來可能會有不那麼稀疏的抽象方式。

討論範圍

明確一些本文中提到的概念所指的範圍：

業務場景：本文主要討論互聯網場景下，除了圖像、語音、大部分的NLP這種本身特徵工程較為困難的領域以外，技術方案更普適（——沒有積累出太多獨特的特徵工程方式）的業務場景，包括而不限於：廣告CTR、推薦、地圖、各種多邊場景下的匹配等
眾包：本文不太區分傳統眾包這種由外部人員或用戶進行標註的方式和公司內專業員工進行標註。但更強調進行標準的人員對當地更熟悉、對數據所屬群體更了解，例如二次元文化圈的人標註二次元相關的內容，而不是隨便找個編輯。
有監督學習：文本主要討論工業界百萬到千萬級數據量下較為常用的方案，如LR、GBDT、GBDT+FTRL、FM類、DL類方法。各種無監督學習、半監督學習、主動學習等不在本文討論之內，但分析方式可以類比，結論也會有所不同。

本文主要希望討論的是ML方法在推廣到各種業務場景下的情況，而不是像、語音、NLP、廣告CTR、推薦這樣較為熱門積累較多的領域。我們假設這些領域中：

業務場景對於badcase的容忍性是：初期上線時能夠接受90%量級的準確性，但如果發現了badcase，需要確實能在一個較短的時間內修復，例如不超過兩周。持續累計badcase修復量可能較大。
業務中的各類元素變化是不能無視的，例如：新用戶/商品的加入、舊商品下線、主流話題變化、監管標準的調整、道路可能出現新建或封閉、交通出現嚴重擁堵或事故等。

如何界定數據極其稀疏

主要依賴在給定了特徵工程方式之後，特徵空間已經確定，對於特徵空間中的每個位置，有多少樣本。也相當於對於特徵空間中的每個位置（從PM角度可以叫場景），等到下一個樣本需要多長時間。

這個定義強烈依賴於樣本特徵性質和特徵工程的方式：如果所有的樣本都沒有任何特徵，總特徵維度是0，那麼無論什麼場景都是不稀疏的，可以訓練得到一個類似於平均點擊率、平均購買率之類的東西。反之，如果給每個樣本一個唯一ID，對這個ID做one-hot並只使用該特徵，那麼在這個樣本空間中，任何樣本的特徵表示都是不同的，就是極端稀疏的。

當然鑒於目前ID one-hot特徵的大量使用，我們這裡的討論要加一個限定，那就是這個特徵提供的信息量較高，是一個該業務場景下的「本質」特徵。

一般特徵的選擇和業務場景有關，特別是重要的場景類的特徵。一個PM可理解的視角就是，在一個特定場景下，下一個會遇到非常接近該場景的訂單或者query要在多久之後出現？

一般業務中，總會有些query是相對較熱門的，也就是相對不稀疏。而一些冷門的query則較為稀疏，甚至極其稀疏——下一個遇到該場景的query可能1年之內都不會出現。

例如，如果我們認為全程的路網暢通情況任何時候都不會完全和另一個時間相同，那麼對於路徑規劃來說，所有query就都是極其稀疏的。

實際業務中，隨著我們對業務理解的加深，一般都可以慢慢的從龐大的原始特徵中構造出較為穩定、維度相對較低，特徵空間中的距離定義更為合理——也就是特徵空間中樣本不那麼稀疏——的特徵工程方式。這個過程往往需要數年甚至更多的時間，這就使得在當下我們看到的不同領域中，數據的稀疏性可能有顯著的差異。

眾包的場景

數據不稀疏時，仔細的收集人工標註就是有價值的。甚至由於標註人員往往對當地或數據所在領域有較為豐富的知識，標註結果的質量可以大幅超越目前依賴已經普及的感測器所能採集的數據所能挖掘的質量上限。

少量相對專業的用戶做了主動或被動的標註工作，其結果可以為後面幾十上百甚至更多的用戶服務，這時標註或收集標註的成本就能被大幅單薄。

眾包無效的場景

當數據稀疏到一定程度時，眾包的價值就變得很低。因為一個標註結果可能在其本身過期之前難以為後續用戶服務。

甚至對某些每個場景一般只有一次服務的領域，標註就只能為ML服務了，沒有更多的價值。這時就只能依靠ML的泛化能力，希望對於未知的場景也能夠自動給出一個平均意義上相對合理的結果。

而且往往在這種場景下，用戶面對的都是新的場景，他自己對什麼是比較好的結果也沒有太多的認知，對於一個相對質量不那麼高的由ML自動產生的結果是能夠接受的。

機器學習與眾包

在一般的業務中，ML和眾包是相輔相成的：

在一個場景未被標註之前，由ML提供一個相對可接受的結果。
當有用戶體驗和標註過之後，該場景轉為使用眾包的數據，此時數據的時效性和準確性都會提升。
隨著用戶標註數據的積累，ML模型對為標註的結果的預測質量會慢慢提高。
無論某個場景用戶標註或未標註過，業務都可以對每個場景進行快速獨立的干預，來滿足監管、數據等方面變化帶來的新變更，或修復造成重要影響的badcase。
ML模型和用戶標註結果可以相互驗證。
ML模型可以從未標註的結果中，挑出應該被優先標註的場景，降低業務綜合的標註成本，此時就類似於主動學習。