【ML專欄】不同應用場景下ML煉丹工的不同生活

TL;DR

• 現有的大數據量監督學習方案更適合用戶不太關心單次結果的場景，如廣告、推薦。
• 場景的特性和產品形態有關，自動診斷要求很苛刻，但輔助診斷系統的要求就要低得多。
• 目前的ML方案對於高準確性+無人值守，這種用戶會就單個case投訴的場景還有些無力。

前言

長期的職位一般都需要提供某種業務價值，單純的試水而不打算落地的研究崗位其實是很少的。

而不同場景下，為了實現各自的業務價值，各位煉丹工所關注的需求和做的事情也是有很大差異的。

場景1：關注平均效果而不太關心單次質量

例如廣告、商品推薦、feed流類內容推薦。

共性是單次請求內容差也不會有太大的問題，用戶本身不太依賴這個，這時候更關注的是平均效果。

這時候相對重要的事就是調模型，尋找和發掘新特徵，更好的線上評估系統，更低的模型線上應用成本（時間、硬體成本）等。

無論是線上還是線下，對請求/樣本的重視程度都要差一些，丟一些數據很多時候無所謂。

場景2：離線或半離線的自動分類

1. 用戶上傳數據或爬取數據的自動審核/分類/標註：主要目的是替代人工分類，降低分類的成本。而且發現錯誤時候可以直接修改數據，快速更正。
2. 輔助診斷、決策系統：主要是為人工決策提供參考信息，一般會由專家對結果進行確認後才會生效，一般能減少人工的偶然錯誤，降低專家的工作強度。出現不合理結果時候可以依賴人工進行修正。

重點也是模型平均效果，不過在效果-成本的權衡中要更傾向於效果。由於沒有線上准實時性的要求，可以上很重的模型，拿python+tensorflow直接上線都不是事。評估相對更容易，因為數據一般都是線下全部可用的。

總得來說是模型黨的天堂，可以快速做模型，快速拿到業務收益。依靠DL的通用性和泛化能力，能解決的問題也更多樣一些。

但業務場景里無法完全排除人工，無論是生效前審核還是發現badcase的事後干預。所以要配一個給運營人員的人工干預系統。

對請求/樣本要更為重視，每個樣本也明顯要貴的多，雖然未必到全事務系統的程度，但上一個相對可靠性的存儲系統（如傳統SQL資料庫）還是有必要的。

場景3：需要移動端部署，模型更新需求不會特別快

例如手機端上的各種圖像、語音、NLP的模型。

這方面我不太了解。但基本上模型設計時就得考慮inference成本，模型壓縮、量化都是很重要的。此外，還得做各種移動端的適配，C++和移動端指令集優化都是很常見的技能。

由於模型是在移動端，部署成本相對於伺服器端成本更新就高得多。雖然說對模型準確率有要求，但應該不會有人成天拿各種長尾badcase讓你幾個工作日內就修復的情況出現。

或者說對準確率有極高要求的場景一般也不會完全在端上落地。（無人車哭死在廁所）

其他場景：

剩下的場景就要相對胃疼一些，或者叫ML模型只是整個問題的一小部分。

1. 無人值守+高準確率+query太稀疏無法完全離線建庫。例如各種地圖App上的導航路線規劃。這種情況下如何修badcase就是個很重要的問題，可能策略/演算法的80%以上人工都在和badcase作鬥爭。
2. 高實時性要求場景。這時候模型的效果-線上代價的平衡就變得非常重要。對於一個長序列場景來說LSTM類的方案可能都難以接受。
3. 模型依賴的特徵快速變化，線上也要實現快速更新。現在的ML方案基本都是一種統計類的方案，只是他們的「直方圖」的分桶方式是在訓練過程中自動學習的，而且現在有一種莫名的端到端大統一模型的趨勢——減少人工特徵構造，直接使用原始特徵。這時候如果模型依賴的特徵出現快速的變化，就會出現來不及訓練新的模型上線的情況。
4. 優化目標尚不明確。這時候往往連怎麼評估工作的產出都要一直扯皮……
5. 沒有大量、廉價、有label的數據。拼標註團隊規模的領域，恩……

等等，歡迎大家補充。

而我的業務方向現在就在同時面對上面1,2,3的問題，為自己心疼1秒……