筆者 Sobi 任職知名外商，摸過各式各樣大資料小數據，喜歡聽故事，也喜歡說故事，《程式猿吃香蕉🍌》客座專欄作家
資料科學是什麼？從十多年前就出現，資料科學家躍昇為 21 世紀最性感的職業，隨著時間的演變，已經有了好幾代的不同面貌。
2012年，「大數據」的概念方興未艾，也沒有現在大家耳熟能詳的各種雲端平台服務，當時的我很幸運有機會使用雲端服務的雛形 — 「Yahoo 私有雲系統」，對電商平台的用戶行為進行分析整理，努力了解各種演算法，磨刀霍霍打造電商推薦系統。這可不是固定的邏輯推薦喔！而是可以透過大數據學習而來的推薦。對當時的我而言，「資料科學」是種應用數據分析跟機器學習，讓電腦預測人類行為，做出決策的資料工程架構。有了這樣的架構，我們只要收集夠多使用者的行為，就可以讓電腦像是領域專家一樣進行預測。
這可比我剛開始工作之初，寫著死板板的 Business Intelligence (商業智慧) 聰明許多，能叫人不興奮嗎？
過了十年，來到 2022 年，Google 搜尋 Data science ，搜尋結果出現多達50億筆，AI、python、TensorFlow 滿天飛......早已不是當年認知的關鍵字，如下圖文字雲所示，大家不妨找找哪些是你所聽過的呢？
這十年來，相關技術的確是飛快成長，所以關鍵字也一直在變，但是核心價值未曾改變，對於資料科學的期待也沒有太大變化，也就是說，老闆們這十多年問的問題都差不多，資料科學的定義簡單一句話：
以數據來解決量化問題。
這聽起來似乎太過樸實無華，資料科學畢竟是 21 世紀性感職業之一，怎地不是 AI 華麗登場？導入 AI 就能解決大數據問題？
▍大數據不是只有 AI
曾經我也以為掌握技術就會踏上康莊大道，只要一直用最新最快的平台計算，資料丟進去，貨物賣出去，就可以發大財。但隨著經驗的累積，深深領悟資料科學的核心是一套分析問題，找尋線索的思辨過程，而各種突飛猛進的運算平台跟技術，則是互相配合，提供有用的資訊，完成這個思辨過程不可或缺的重要夥伴們。
是否太難理解？換個方法來感受一下。我們就一起來看看一個典型的資料科學專案討論會議吧！
⊙ 場景：許願池會議
專案經理拿出手機滑了滑：老闆們都覺得這塊版位的推薦很讚耶！一直推薦各種新東西，看起來像是個人化又很多元，這應該不難做出來吧？
如果台下一片讚聲說沒問題，肯定有問題！應該會有三方專業提問：
🙋♀️ 機器學習工程師（舉手）問：
- 有多少時間可以開發模型？經典解法可用入門款：協同過濾 (Collaborative Filtering)，行有餘力可以來個知識圖譜 (Knowledge Graph)
- 資料長什麼樣？結構化資料有多細？
- 個人化推薦是要真的個人化還是分群就好啦？
🙆 資料工程師（急忙跳起來）問：
- 要及時推薦還是一天一次的推薦？
- 資料儲存在哪裡？本地資料庫還是上雲端？
- 歷史資料要抓多久才夠。模型多久更新一次？
- 資料更新頻率是多長？一小時一次？還是一天一次？
💁 資料分析師（慢條斯理推眼鏡）問：
- 成效評估量化指標是什麼？用戶涵蓋率？ 點擊率？轉換率？
- 短期目標一季就好嗎？是否還有長期用戶成長規劃？一年三年？
- 產品中還有其他相關推薦版位？
- 開發前是否需要評估不同版位擔任不同推薦角色？首頁就是衝高流量帶新用戶，不同分類底下的模組就是要增加用戶黏著度，按越多廣告越好！
🤦♀️ 專案經理眼神死，問不出來…..
一連串的專有名詞可能造成腦霧狀態，難道不是 AI 模型就能完成任務了嗎？哪來那麼多問題要先確認？
相信各位看到這裡，應該很難理解，不就是給個 AI 模型，有這麼難嗎？
▍資料科學和傳統軟體開發其實很不一樣
江湖一點訣，說破不值錢！資料科學的三個角度其實是…
❶ 機器學習：分析問題，判斷適合用什麼技術跟模型解決。
❷ 資料工程：解決問題，確認資料儲存格式和空間，以及機器運算能力。套用在適合的工具，用來分析與建立模型。
❸ 資料分析：定義問題，判斷是否能以資料科學解決，用量化指標定義目標，並評估模型帶來的商業影響。
這與軟體開發流程實在很不一樣：
專案經理很難在初期就告知工程團隊問題範圍，規格書 Spec。
因為目前資料科學的專案開發更像是許願：也許ＸＸＸ不錯，讓使用者體驗更好！聽說 AI 模型可以做到。背後沒說的願望是：使用者體驗更好，會帶來更高的流量，營收會變高。
默默期待這三個願望在 AI 模型中一次滿足。但是資料科學不是讀心術，必須明確定義問題，才能進入開發流程：規格撰寫、時程規劃、成效評估。
▍別急著跳進開發流程
1. 資料科學關鍵第一步：問題定義
問題尚未定義清楚之前，千萬別把自己當成工具人！資料科學是從量化數據的角度提供解決問題，必須如同論文的思辨流程 (如下圖)：
機器學習、資料工程、資料分析這三方缺一不可：每個步驟必須同時開發討論，絕對不是資料串接完畢，模型也訓練完之後，資料分析才在最後階段評估成效。
遙想當年，尚未想通這個道理之前，也是一路上坑坑疤疤走來跌跌撞撞，的，要不是模型準確度很高，但是算出結果要十天半個月的，沒辦法放到實際環境要用。要嘛就是模型很準，可是只對少數老客戶有吸引力，卻拉不到新客人。當年的一股熱情，幾次下來幾乎是消磨殆盡了。
回想起來，其實一心想著有資料可把玩可分析，有模型可研究，就一古腦兒跳進開發流程，期待著終於也要體會那最「性感」的工作，然後 … 結果就沒有然後了。經過幾次的慘痛教訓，白了頭髮，才頓悟問題所在。
那麼，問題出在哪裡呢？其實是因為一開始就沒有把問題定義清楚，也沒考慮應用情境，就算模型訓練的過程完美，但是套不進日常的商業應用，就算怎麼完美的理論，也只能含淚退場。
多年之後，我悟道了！資料科學除了上述一再強調的定義問題之外，關鍵的是：數據僅能解決可以量化的問題！
2. 資料科學關鍵第二步：判斷是否為量化問題？
就是量化數據定義問題。
第二步依舊樸實無華，一點都不炫技，接下來，我們再度用會議場景說明定義量化問題三步驟：
⊙ 場景：Brainstorming 腦力激盪
繼許願推薦模組的會議之後，專案經理又請大家聊聊自身經驗和使用產品的感受，以便討論未來產品方向：
派大星：「我是音樂愛好者 啊！常常聽音樂，喜歡的歌會一直一直 聽」
蟹老闆：「聽的音樂很廣 啦，什麼歌都聽，每天搭捷運都會聽...算是重度」
這種經驗分享通常都是非常熱絡，此時，資料科學家的大腦運轉狀況是這樣子的：
這些使用經驗可化約為三個指標：
- 頻率：常常，每天
- 深度：喜歡的歌會一直一直聽
- 廣度：聽的音樂很廣
根據聆聽頻率，從歌曲的深度與廣度分析用戶習慣，最後再根據商業用途再將用戶分群貼標。
白話來說，將個人感受經驗轉換成量化指標：
原本七嘴八舌的軟性談話內容，在資料科學世界裡必須變成硬梆梆的數據才行。
說來這有點硬，但是多練習幾次之後你會漸漸愛上再怎麼天花亂墜天馬行空的許願都可精練成幾句話的爽快，我們一起來練習以下三步驟：
❶ 找出可量化指標
派大星說很愛周杰倫，一天聽 10 次，蟹老闆說他才是鐵粉，每張專輯都聽過 20 次以上，不管他們怎麼吵，把這些鐵粉行為量化成指標就對了！
- e.g., 深度：播放次數/歌曲數目
- e.g., 廣度：歌曲數目/天數
❷ 定錨問題範圍，建立座標
將真實世界的萬事萬物變成義量化指標之後，就可以在資料世界裡打造出你心目中的座標空間啦！舉派大星和蟹老闆的鐵粉之爭為例：
二維空間中，以音樂廣度為Ｙ軸，深度為Ｘ軸，觀察用戶行為都落在哪個角落，深度用戶多一些呢？還是什麼都聽的用戶多一些？又深又廣的用戶存在比例佔多少？當大家忘情地討論自身經驗的時候，資料科學家就必須能明確描繪出座標空間，明確地描述用戶行為，並將收斂問題於幾個重要指標。
❸ 將實際問題套入量化指標中
用量化指標來定義問題，同樣的也必須要定義出能用量化指標評估的成效。我們再回到許願會議裡的音樂推薦系統，該怎麼把量化標套進去，判斷做得好還是不好呢？
- e.g., 如果目標是提升用戶經驗，增加黏著度，是提升廣度還是深度？抑或兩者都要？
- e.g., 如果目標是增加新用戶賺更多錢，那就不是目前的討論可以解決的範圍，必須另外討論
無論如何華麗的許願如果可以透過三步驟以量化指標定義問題並收斂範圍，專案經理的願望就能透過資料科學完成啦！
▍量化！量化！量化！
請務必記得，資料科學是什麼？就是量化！量化！量化！很重要，所以要說三次！各種複雜的問題，唯有定義出量化指標，才能夠找到適合的演算法訓練並優化模型，也才能套用統計檢定來分析評估結果，形成一個互相參照補足的正向循環。
那 ...... 如果問題是不可量化呢？就算了嗎？當然不是！資料科學家當然是要盡其所能在模糊之中抽絲剝繭可量化的部分啊！
下一篇，才是資料科學好玩精彩之處，根本就是從業十年的問題大蒐奇，經典問題怎麼解？不能量化怎麼辦？看似量化的問題其實根本就是陷阱....
資料科學小教室我們下次見！
若是喜歡我分享的內容，可以訂閱我們的粉絲團《程式猿吃香蕉🍌》，在軟體開發的路上，一起分享交流，一起成長。
