Data 關於資料科學 … 我想說的是(上)
後設資料
一句話濃縮
資料科學 不是把資料丟進 AI 模型，而是「以數據解決量化問題」的思辨流程：先定義問題、判斷是否能量化，再把軟性使用者經驗轉成頻率、深度、廣度等可度量指標，讓機器學習、資料工程與資料分析三方能共同判斷技術、資料、目標與商業成效。
提取要點
- 資料科學的樸素定義：相關技術十年來快速變動，從大數據、推薦系統到 AI、Python、TensorFlow，但核心期待仍是「以數據來解決量化問題」。
- 大數據不是只有 AI：資料科學的核心不是炫技，而是一套分析問題、找線索、讓運算平台與技術提供有用資訊的思辨流程。
- 資料科學專案不是傳統軟體開發：專案初期通常不像一般軟體能直接寫完整 spec；若只把產品願望丟給 AI 模型，容易忽略問題範圍、資料條件、工程時程與商業成效。
- 三方專業提問：
- 機器學習：問題適合哪種模型？協同過濾、知識圖譜或其他方法？個人化要到個人層還是分群即可？
- 資料工程：即時推薦還是批次？資料在哪裡？歷史資料要多長？模型多久更新？
- 資料分析：成效指標是什麼？用戶涵蓋率、點擊率、轉換率？短期版位目標和長期用戶成長是否一致？
- 問題定義是第一步：資料科學不是讀心術。必須先定義問題，才進入規格撰寫、時程規劃與成效評估；一開始不釐清應用情境，模型再準也可能無法進入日常商業應用。
- 量化問題三步驟：
- 找出可量化指標：例如把「常常聽音樂」轉成頻率，把「一直聽同一首歌」轉成深度，把「聽很廣」轉成廣度。
- 定錨問題範圍，建立座標：用深度 / 廣度等維度描繪使用者行為空間。
- 將實際問題套入量化指標：判斷推薦系統要提升黏著度、廣度、深度，還是另有新客 / 營收目標。
- 量化不是窄化，而是讓願望可被檢查：軟性談話和產品願望必須轉為可度量指標，才有機會選演算法、訓練模型、做統計檢定與評估結果。
提取概念
連結到此來源衍生 / 更新的 wiki 頁：
- 資料科學 — 補入「以數據解決量化問題」的實務定義，以及 ML / DE / DA 三方協作提問
- Goal-Signal-Metric — 補入把軟性使用者經驗轉成量化指標的資料科學案例
- 數據流 — 補入「數據流不是有資料就好，而是把問題轉成可度量狀態」的對位
- 預測行銷 — 補入電商推薦系統作為協同過濾 / 知識圖譜等預測方法的產品化場景
- 程式猿吃香蕉 — 新建；中文軟體開發 / 資料科學寫作 publication
Ingest 筆記
2026-05-06
- 不新建「量化問題」頁：本篇對「量化問題」有清楚三步驟，但目前仍是 資料科學 的核心子命題，而非跨多來源的獨立方法論。先整合進 資料科學 與 Goal-Signal-Metric，待後續系列中篇 / 下篇或其他資料科學來源反覆使用時再評估拆頁。
- 新建 程式猿吃香蕉 的理由：此 publication 先前已在 觀察清單 以 Jayden-Lin / 程式猿吃香蕉形式出現，這次成為直接來源頁的媒體容器；依 vault 對 你的Py教練Mike、AAPD-As-A-Product-Designer 等內容供應者的處理方式，建立 publication entity 作為後續軟體開發 / PM / 資料科學文章的歸宿。
- 不新建 Sobi entity：Sobi 是本篇作者且有資料處理背景，但目前只有單篇來源；先記在來源頁與 程式猿吃香蕉 entity。若後續同作者 2+ 篇或個人觀點來源累積，再升格建頁。
- 觀察清單同步：消化 程式猿吃香蕉 候選；Jayden-Lin 仍保留在 entity 升格候選，因本篇不是 Jayden Lin 個人來源。
原文（可選）
Ingest 時透過 Medium 頁面讀取，本文不保存完整原文；原始 URL 見 frontmatter。