從解決問題的角度談機器學習專案
最近與大學社團學弟妹討論，發覺現在多數剛進入數據領域的數據人才習慣使用Kaggle（註:一個以舉辦數據科學比賽為主的競賽平台，上面有許多案例分享與分析討論）的專案作為入門訓練數據分析能力、學習機器學習的建模流程。
個人在剛開始學習時也受益 Kaggle 的 Kernel 良多，然而以 Kaggle 作為學習起點蠻容易陷入「瘋狂打比賽」、「過度專注在優化一個模型」上，卻忽略了數據科學專案主要在解決問題的本質，就連我也發覺自己早期的文章很多都跟比賽與建立模型有關，容易忽略怎麼定義一個數據科學問題，這種學習與使用的落差容易造成剛開始參與業界專案的數據科學人才不適應。
而不只是學習數據科學的人才，許多合作專案中也有關係利益人存在「模型是專案唯一重點」的迷思，因此這篇文要來說明解決問題的重要性，並舉一個實際人員離職預測案例來分享個人對於數據科學，尤其是運用機器學習在解決問題上的經驗與體悟。
本文重點有三：
1. 機器學習專案需要參與進模型使用者, 共同設計與討論解決方案
2. 可以自模型開始, 但不一定從模型預測結果結束
3. 維持解決問題的彈性, 讓解決問題的流程可以被不同工具、情境迭代
寫在前頭：數據科學與機器學習的核心仍在於解決具體問題
之所以說機器學習專案，是因為過往在管顧參與專案、個人諮詢的經驗中發現很多客戶總是會詢問「這個專案可不可以用機器學習？」、「我們想做一個預測模型」，似乎「機器學習」這個解決問題的「手段」，是多數專案的隱形限制，以及對於既有問題的框架。而會保有這種期待或者手段前提，深入挖掘才理解到多數人覺得預測類型的專案比較先進、有一些數據「看似可以預測」，因此想要導入這種技術。因此首先就要來談「機器學習作為解決問題手段的合適度」。
在許多報告中，人們傾向於把機器學習跟數據分析依照方法類別劃分開來，你可能會找到一張比較表，「數據分析適合診斷與描述 、機器學習適合預測分析、管理科學/運籌學適合處方性分析」，而因為越往右邊走（描述到預決策）看似越先進高端，因此在合作初期，非數據背景的相關利益關係人習慣性會把機器學習與預測劃上等號，因此這裡會有兩個問題需要思考：
機器學習是否只能以預測為目的來使用呢？什麼情況下用機器學習更適合？
事實上機器學習不只可以用來回答預測問題，也可以更好幫助我們展開前一步的分析、又或者下一步的最優化輸入，且雙雙都會影響到後續解決方案的設計，來更好達到原本「解決問題」的目標，本文將會舉一個實際例子來分享這個過程。
數據科學的專案迭代有多種形式
讓我們以數據科學專案的範疇來描述以數據科學解決問題的過程
個人的體會是機器學習通常是一個開始，或者一種思考方式，但通常不會是一個模型訓練下去就能漂亮解決實際的問題 ; 許多人都知道數據科學專案是一種「循環迭代的過程」，然而實際跟不同從業者、專案團隊交流後，我發現對於專案迭代的理解還是有一些細微差異的。
工程上的迭代例子
一部分人對於機器學習「專案迭代」的理解在於固定週期重新收集數據、重新訓練模型，但我認為這依然偏向MLOps的、數據科學的技術範疇，倘若本來的 model pipeline 設計得不適合（包含監督學習中Y的定義、採集X的時間範圍、X與Y的時間差），我認為這種本質上共享同一種處理邏輯（Pipeline）的專案其實更像是一種必要的維護工作，然而在解決問題的手段上並沒有太大的不同。
預測任務的迭代例子
另外一種「專案迭代」的理解則是類似Kaggle比賽的模型優化，來回分析數據、思考特徵，進而優化模型的評估指標 。這篇文章也不是討論這種分析式的迭代，畢竟Kaggle上的問題大部分其實已經被定義好了（不包含 Analytics 類型的比賽與數據公開賽），甚至連 Label 都有不同賽事舉辦方的說明與協助標註，自變數與可用數據集的時間也被分割好，因此可以專注在優化比賽挑選的評估指標上，以至於這類型的專案前提在於「問題定義得夠好」，確實可以很好訓練個人在數據科學上的技術能力，但是對於解決實際問題訓練得比較少一些，比賽的機制也不比較不需要參與到這部分。
對問題的迭代在個人經驗也不可忽視
若粗淺歸納並給予分類，上面第一種更像是工程的迭代，第二種類似於算法的迭代，而數據科學離不開工程、算法、領域知識，我發現在與商業端討論、實際落地，特別是客戶第一次使用機器學習的專案中，第三種 ：領域知識的迭代會更容易引起討論與合作，並有效解決問題，而所謂的領域知識，無非是從數據分析與對話中建立認知，並設計貼近業務的解決方案。
今天所要討論的便是機器學習在解決問題中的迭代，也就是從現狀與目標的落差不斷去收斂，持續逼近的過程。接下來將會以一個過去諮詢經驗中的實際案例來分享在解決問題上，機器學習更多是來回迭代，討論與思考而成，以及具體的過程，案例背景會稍做修改，所以也有可能出現舉例與真實產業knowhow理解的差異，但思路是類似的。
案例：餐飲集團如何降低人事離職率？
背景是一間連鎖餐飲集團想要解決人事不充足問題，為節省篇幅，將簡單分割成問題定義（info in）、數據分析(info process)、解決方案設計(info out) 三大部分。
info in 問題定義：
在前期的問題定義中，首先要確定問題值得被解決，適合我們來解決，以這個案例來說，隨著各個行業招募成本增加、尤其是餐飲越來越難找人、以及員工離職後重新培育、上手的時間、金錢成本都巨大，餐飲業又依賴於員工來維持餐廳營運，因此想要事先知道誰有可能離職，進而防範於未然。
看起來問題的影響力確定了，也能找到衡量財務回報的方式，已經確定這個問題值得被解決，我們就接著看「如何解決？」
原始問題：「可以幫我預測誰會離職嗎？」
這很容易被定義為一個典型的「能夠用機器學習XX嗎？」的問題，我們可以拆解一下，首先關鍵詞在於「預測」，在這個問題背景中，要辨認預測是否有意義，第一個子問題是行動方案，也就是如果我真的開了上帝視角知道誰會離職，我們可以做什麼？
所有的預測本質上都是行動方案的輸入之一
因此開啟第一個溝通，從行動方案去理解可以做、可以改變的事情，這樣有幾個好處
- 確保數據科學專案可以落地
- 將行動方案融入設計數據科學 Pipeline 中
- 確保相關利益人參與進來
1.有行動通常就容易讓專案落地，包含被人實際使用、作為下一個專案的輸入（如最優化、管理科學），這對於產生實際影響至關重要。
2. 很有趣，在於如果真的走到設計預測專案，在監督學習來說自變數、應變數Ｘ、Y會有個間隔時間差，而實際專案中我們也要設計這個時間跨度。舉例來說，業務相關人員在得知模型結果後，可能需要2~3週的時間去產生行動（好比預測離職中去安撫可能會離職的人、預測個人樣品偏好後去設計溝通內容與發放樣品方式），那麼X、Y時間差就不能低於2~3週 ，否則看到模型結果後也來不及產生改變。我在 L‘Oreal 萊雅實習：數據分析與數位行銷的美麗交織中也有分享實際的例子。
3.實際去思考行動方案時會發現這個專案牽涉到的人可能更多，比方說需要一些人的協助才能參與行動，那麼他們願意相信、嘗試模型的結果去行動嗎？或者他們有一些「共通目標」，比方說有另外一個專案正在想怎麼更有效率招募人才，那麼財務的預算要怎麼分配呢？是花更多錢在培育留人上，還是更多花在招募人才上？因為兩者在邏輯上都能解決潛在人才不夠的問題。那麼是否也有「相異目標」，比如行銷想要專注在顧客行銷上，但是粉專的發文資源能不能也用來發佈職涯、招募消息，以及是否適合？
重新定義看似直覺的機器學習問題也是一種迭代
在這一個層次，行動就要討論不同的方案，這就是第一種迭代，甚至我們還會想要把不同行動融入數據科學專案中，因此這裡問題有可能重新定義為：
「給予獎金與給予安撫，哪一種方式可以更好降低離職率？」
從這個定義就能知道在演算法上，原始的機器學習模型可能是不夠回答這個問題的，我們可能還要設計因果推論的方法 ; 在工程上，數據科學家需要預留一個數據讀入的變數欄位，這個欄位可以靈活變換行動，好比「獎金、安撫」，未來可能擴增為「獎金、安撫、升遷激勵」，而數據就不只是接數據庫，可能還需要要設計出一個簡單的介面可以讓人資上傳「行動方案表」，如果這個行動還有很多屬性（比如給獎金的範圍很廣、設定有額外條件），那麼我們甚至也要考慮找數據工程師一起設計一張表，藉此來存儲這些屬性與數據來方便之後的分析與建模應用。
因此從上面這個簡單的例子，可以看到在解決問題上範疇不僅限於手上的jupyter notebook，我們可能還需要Slack(溝通)、Notion (紀錄學習建資料庫的筆記XD)、Excel (初期行動方案不會太複雜當數據庫用)。
我覺得工具的多樣性也是重點，在解決問題的過程中大家可能會發現：怎麼問題這麼多、要掌握的資訊看似很多很複雜、要實作這麼多內容也很花時間，導致專案時間拖得很長。
但不要忘了我們「正在迭代」，初期都可以用一些工具簡化問題，比如説在思考上我已經想到未來可能的擴充性，需要額外建立與維護一個資料表，但在實作上現階段我為了簡化問題的複雜度，可以單純用Excel作為輸入，甚至開一個Google Sheet 讓人資方便更新數據，這樣一來就不會被專案實作搞得暈頭轉向，但又能讓思考與實際進度同時往前，我覺得這部分也是要團隊自己取捨的，我自己會傾向只要想得夠全面與深入，即使解決方案還不夠漂亮，但有用即可，畢竟我們也已經想到未來可以再怎麼優化。
總之，在思考、設計時應該是更全面，更跳脫數據科學技術本身 ; 而在執行上也應該發揮我們的專業能力，設計一個簡單但有用的解決方案，讓不同節點隨時可依據專案對完成性的需求往上優化，這是解決問題的迭代之一
info process ：數據分析與建模
假設我們已經確立了行動方案，下一個問題就是「需不需要機器學習？」離職預測不見得需要模型，一些簡單的規則可能就可以很好去理解與「偵測（detect）」離職的傾向。通常我會選擇一個樹模型開局，這麼做不見得是為了要一發train到底，而是從特徵重要性去收斂我接下來要分析的範疇，比如我從模型知道重要的離職特徵在於年紀、加入時間、最近請假次數，那就有助於我去搜索相關文獻與思考特徵工程。
模型不一定要很準，但是在這個階段可以回答我幾個重要的問題就足夠：
相關利益人（此人資）對問題的假設是否成立？比方說最近請假次數多（可能去面試）容易離職
在這麼多合併過的數據表欄位中，哪些維度與指標我需要更在意？（特徵重要性可以初步回答）
驗證相關利益人的假說不只可以善用專家們的領域知識，也可以讓合作方有參與感，進而更有效率協助數據科學專案的進度推動。而辨認出重要因子，有助於聚焦在重要的因子與特徵上，讓分析更有效率、不會陷入大企業數據太多、繁雜的分析泥淖。
特徵的性質也很重要，因為這會影響到我們前面的行動方案。比方說，年紀我們可能無法改變，但這個資料確實可以「detect」，甚至也很好預測對吧？因為說白了下一年的年紀就會是今年的年紀+1，銀行就深諳此道，18歲推送學貸、6年後24歲車貸、保險、信用卡，這裡即使不需要模型也可以預測幾年後消費者的需求。
而回到案例上，從數據分析上是年齡這個變數，在真實的世界則是反應了剛成家、有養育責任的人可能對薪資要求會更有壓力，那麼就可以考慮在誘因上給予獎金類型、升遷與薪資成長的調整。而請假次數可以改變，既然它是個領先指標，那我們可以以此來間接衡量你的行動方案是否有效（在人資關心後，請假次數是否減少，而不用等到人真的離職才去比較）
接著就可以針對重要的特徵去分析，比如看請假次數在一定時間範圍內超過多少次時後來離職率會大幅上升，那就是一個很好的離職信號，而關聯到解決方案，可以設計一個簡單的儀表板追蹤這個領先指標，並以分析出來的結果作為告警閥值（請假超過幾次可以格外關注），這個簡單的數據產品不需要模型輸入輸出，用人資熟悉的 Power BI 就能呈現，也能回答「什麼情況下我該介入關心」的直接子問題。
倘若我真的想要很準確知道誰會離職，那麼一定要從模型的角度來優化嗎？其實不一定，我們也可以從數據下手，好比分析的時候發現年齡、加入時間其實會透露出人生與職涯階段（剛出社會、剛成家、達到理論升遷年紀），人生與職涯階段的需求才是影響是否換工作的重要因子
若外部分析、內部訪談後我們認為公司氛圍良好、升遷度明確無內在推力，那麼便是本身需求受到外在拉力影響因此興起離職念頭，也就是說「背後的需求」才是最根本影響到我們這邊關心的變數（離職），那麼這些數據真的只來自於一開始客戶提供的出缺勤紀錄、考核表數據嗎？其實不止，為了收集這些數據與預測因子，我們額外發放問卷收集心理變數，發現從心理變數去預測離職與否非常精準，也相當好解釋，因為問卷設計來自於領域知識與數據分析的共同輸入，預測效果也相當好。
一個模型要預測得好，前提是它使用的數據具有預測力，而一開始收集的數據在缺乏理論與實務的梳理時，都並不保證具有這個預測效果，有可能只是組織剛好有收集這些數據，所以想要「試試看」
更重要的是，這個流程本身讓人資也參與（Engage）進來，因此相關利益人會更願意去使用、相信模型的結果。共同建立一個流程、打造解決方案對於推動相關利益人的使用與專案落地在個人的經驗中通常蠻有效的。
問題變成：給定心理狀態，我們能夠提早發覺這個人想要離職嗎？
這個問題的解決方法甚至也可以很彈性，比如衍生的子問題是「收集資料成本高，因為發送內部問卷困難」，那麼結合前面的分析，可以只針對前述提到請假次數飆升的人給予問卷發放，降低對員工干擾程度 ; 或者以行為數據去預測心理狀態（給定收回來的問卷），再用心理狀態去預測離職傾向 ; 在這個例子中數據收集與模型的設計取決於問卷實際發放是否困難、新的預測因子（心理變數）能否確實反應更好的預測能力。
因此這裡可以看到即使從一個看似直覺的機器學習分類問題開始，給定現有人事數據(X)，預測未來是否離職（Y），也可能轉換X（心理問卷）、甚至Y（心理傾向）來繼續這個專案，這也是解決問題的迭代。
info out：解決方案設計
前面提到的在於定義問題、設計處理流程，解決方案可以更靈活，也可以有很多種變化。
比如最後上線的模型不見得要是一個可以調用的「是否離職」API，而是單純一個Power BI 儀錶板，因為從儀表板的關鍵指標我可以知道該對誰產生行動。
也有可能是一個分析報告，說明我們應該更專注在哪些組織制度與人資領域事務（如薪資結構）設計上，因為這可以更根本解決問題
也確實有可能是一個模型，但不是每天排程預測誰明天會離職的腳本，而是一個每季回收員工問卷數據並檢測心理健康的心理探測儀。
因此我們可以看到，其實雖然一個專案起初的想法是一個直覺的分類模型，但是專案的結束不一定只有預測的機率，可能是一個容易使用的儀表板、一個開發出來的協作調查流程、一份探討策略方向與索取資源的分析報告。
在設計解決方案時，也要考慮組織與團隊的資訊架構（infra）是否成熟，其實很多合作與專案的初期在於建立信任、快速看到成效，此外組織、團隊也不一定有很完整的數據架構（尤其有些組織的數據分析人員可能是行銷人員、人資、供應鏈專家們自己），或者資訊系統架構還不成熟等等……但我們也可以依照情況去設計滿足現階段的解決方案。
以上面的例子來說，這個解決方案可能還沒有完整的自動化數據管道、客製化的前端介面，只是一個人資定期發送的 SurveyCake 跟 Jupter Notebook ，以及供大家討論與發現問題的 pdf 報告跟大家熟悉的 Power BI，但或許也很有用並確實可以解決問題，也能夠在未來升級成更自動化、完整的流程或者系統。
總結：機器學習不只可以用來「預測」，而是設計更貼合具體場景的解決方法
事實上能夠滿足現有數據建立機器學習模型來估計、預測解決的條件並不多，很多環境過於複雜、變化太快，這導致收集的數據維度總是太少無法衡量全部的影響因子、或者數據對時間敏感容易「過期」，個人過去在電商、快消品牌端的時候，最關注的核心指標都是營收，然而這個指標受到的影響因子太多，小至內部活動、大至外部競品，總有各種因素會干擾預測。
既然核心指標難以精準預測，我們不如從邏輯與數據中找到領先指標，追蹤好，預先設計好可以產生的行動，並抓住分析後得到的信號來見機行事。在說文解字上，我自己更喜歡把預測理解成是「detect」而不是「predict」，一來是預測並不總完全對，二來是通常也不需要完全對才可以真的把數據科學落地，只要能辨別那些走向預期未來的關鍵信號即可，這樣在解決問題上會更落地，更有彈性，也可以加深對自己領域的理解。
許多產品導向的數據科學家總能夠通過對領域知識的理解與分析的思考來建立出一套成熟的指標體系，藉此找到數據間的領先、結果關係，並很好追蹤與衡量產品的方向，這裡面用到的的方法可能不難、甚至可能不會用到機器學習模型，但也創造了很好的價值，對我來說便也是一個很好的「預測」。
其實解決問題的切入點還有很多細節，數據科學是個很有趣、充滿變化的領域，之後也會分享更多實際專案的學習與收穫，敬請期待！
歡迎想學習Python資料科學、商業分析、金融知識的人一起交流！本部落格的內容全部都是基於「分享」的實作、理論兼顧文章，希望能夠幫助到所有對資料科學領域有興趣的人們，長期關注可按左手邊的Follow!若喜歡我在 Medium 的內容，可以拍個手（Claps）這邊想做個實驗，好讓我知道你/妳喜不喜歡這篇文章：
拍 10 下：簽個到，表示支持（謝謝鼓勵！）
拍 20 下：想要我多寫「商管相關」
拍 30 下：想要我多寫「資科相關」
拍 50 下：我有你這讀者寫這篇也心滿意足了！敬請期待下一篇！或是您也可以逛逛我的其他資料科學文章，到我的主頁置頂文章獲得良好的目錄體驗。
Python資料科學系列：
- 【Python實作】生活中的資料科學，用模型挑出高C/P智慧型手機
- 【Python實作】Back to E’shanzen資料科學的商業分析
- 利用集群分析掌握消費者輪廓
- 利用Airbnb來更了解居住城市，以臺北為例 Python實作
- 學生社團的數據分析，Python線上課程分析實作
如果想跟著我實作資料科學，開始寫程式必知必會基礎系列：
