跳至主要内容

Day 04：從職缺任務到學習地圖——您走哪條路？

· 閱讀時間約 6 分鐘
Willis Chen
Willis Chen
Tech Instructor

站在哪裡往前走​

三天下來我們確認了：市場要什麼（Day 02）、誰負責什麼（Day 03）。今天是第一部曲的收尾，也是我覺得最實用的一篇——把職缺梳理成您能照著走的路。

今天要解決的問題​

「我知道要學 MLOps 了，然後呢？」

這是我最常思考的問題，而多數答案都不見得符合實際，因為多半收到的是技術清單：Docker、K8s、MLflow、Airflow、Terraform……看起來很完整，但沒有回答到我期待的三個關鍵問題：

  1. 順序：先學哪個？（學錯順序會卡很久，例如還不會 Docker 就學 K8s）
  2. 深度：學到什麼程度算夠？（每個都要精通的話，我怕我兩年也走不完）
  3. 止損點：什麼可以先不學？（這題最少人回答，但卻關係到時間緊迫的策略取捨）

今天這篇就試著回答這三個問題。

📊 職缺訊號

學習順序應該按任務訊號的頻率 × 您的缺口排序，而不是依照「技術難度」排序。同樣是 MLOps，平臺與基礎設施出現在 58.5% 的職缺、模型版本與實驗管理只有 7.2%——不是後者不重要，而是當你時間有限時，前者能讓你先拿到面試。

一、現象：三條轉職路線，起點不同​

絕大多數要進這兩個職務的人，來自三個地方。您的既有優勢與待補缺口完全不同：

三條主流轉職路線的優勢與缺口

圖 4-1：三條主流轉職路線的既有優勢與待補缺口（依 2026 年職缺任務訊號與常見團隊分工整理的示意性歸納）。綠色是可直接遷移的優勢，紅色是本系列要補的缺口。

路線 A：後端／DevOps → MLOps／LLMOps。 您已經有容器、CI/CD、監控、API 服務的底子——這是最短的路。您缺的不是工程能力，是「ML 特有的那些會故障的地方」：資料會漂移、特徵在訓練與線上會不一致、模型會無聲失效。Day 09、11、14 是你的重點。

路線 B：資料科學家 → MLOps／LLMOps。 您懂模型與資料，缺的是工程紀律與系統思維：容器、K8s、IaC、SLO。這條路的難處不是學不會，是心態轉換——從「這個模型指標更好」轉換成「這個系統半夜壞了誰處理」。Day 12、13、15 是你的重點。

路線 C：前／後端 → 生成式 AI 應用。 您會做系統整合，缺的是LLM 的行為特性：它會胡說、輸出不確定、每次呼叫都在花錢、還可能被使用者的輸入騙走。Day 07、18–20、24–25 是你的重點。

二、原理：學習順序的三個排序原則​

有了缺口清單，接下來是排序。我們梳理成三個原則：

原則一：能不能動手，優先於懂不懂原理。 先讓一個東西在電腦上跑起來，再回頭理解為什麼。這是因為跑過比較容易記住。所以 Day 05 會先提供工程基礎，Day 06、07 才補理論。

原則二：先學「會被別人依賴」的，再學「只有自己用到」的。 容器化的優先序高於實驗追蹤，因為前者是別人接您工作的介面，後者是自己的工作習慣。這也對應了任務訊號的高低。

原則三：先建立回饋迴路，再談優化。 監控與評測要早於效能最佳化。如果連自己有沒有變好都不知道，又該如何談優化。也因此會安排 Day 14 談監控， Day 15 再談成本優化；Day 20 會談評測、Day 23 再談微調。

三、動手：30 天怎麼取用​

30 天連載路線圖

圖 4-2：30 天連載路線圖（依任務訊號配比規劃的示意排程）。Day 08 分流、Day 24 合流。

完整版： 照順序走，Day 28 的綜合專題會把前 27 天串起來。

主軸一速成（時間有限、想轉 MLOps）： Day 01–04 → 05–06 → 08–15 → 24、26、27 → 28–30。可跳過 Day 07、16–23 的細節，但 Day 18 與 Day 21 建議略讀，因為您未來要支援的就是這些系統。

主軸二速成（時間有限、想做生成式 AI 應用）： Day 01–04 → 05、07 → 16–23 → 24–27 → 28–30。可跳過 Day 09–11，但 Day 12–14 建議略讀——不懂部署與監控的應用工程師，做出來的東西上線也不好控制。

週末版（平日沒空）： 每個週末處理一個部曲，六週走完。優先做每篇的「動手」段落，「取捨」段落當睡前讀物。

主管／教學者版： Day 01–04（為什麼要投資這個能力）＋ Day 29（怎麼驗收）＋ Day 30（怎麼規劃團隊路徑）。中間 25 天當作能力清單的細目。

搭配一個可勾選的能力檢核，每完成一項就打勾——這份清單直接對應面試會問的東西：

【共同地基】
□ 能寫一個 multi-stage Dockerfile 把服務打包成 500MB 以下的映像
□ 能說明 .env 與金鑰管理的正確做法，且從不把金鑰寫進程式碼
□ 能講清楚「訓練/驗證/測試」為什麼要切、切錯會怎樣
□ 能估算一次 LLM 呼叫的成本，並說出哪一段最貴

【主軸一 MLOps】
□ 能用 MLflow 追蹤實驗並註冊模型，服務端以 alias 取用
□ 能寫一條含品質門檻的 CI 流程，模型沒過門檻不得上線
□ 能在本地 kind 叢集部署服務並設定 HPA
□ 能對 API 壓測並讀懂 P50/P95/P99，據此訂 SLO
□ 能用 PSI 或 KS 檢定偵測漂移，並說明門檻怎麼定

【主軸二 生成式 AI】
□ 能建一個含混合檢索與來源引用的 RAG 系統
□ 能手刻一個具工具呼叫與迭代上限的 ReAct agent
□ 能建 20 題以上的評測集，並算出 LLM 評審與人工標註的一致性
□ 能說明提示注入的四層防禦，並實作其中至少兩層
□ 能判斷一個需求該用微調、RAG 還是提示工程，並說出理由

四、取捨：什麼可以先不學​

以下這些，在您拿到第一份相關工作之前，可以先不碰，在策略上設定明確的止損點：

先不學為什麼什麼時候再學
自建 Kubernetes 叢集先求會用（部署、除錯），建叢集是平臺團隊的事，還不急進入約有 8 人以上規模團隊、要做內部平臺時
從頭訓練大模型幾乎沒有職缺要求，成本也不是個人負擔得起，這是市場說的不是我說的進入模型研發團隊時（極少數）
全參數微調90% 的客製需求用 RAG 或 LoRA 就能解有明確風格／格式需求且已試過提示工程後（Day 23）
多代理框架（AutoGen、CrewAI 等）多數需求用確定性工作流更穩、更便宜單一代理已經做好，且確實遇到需要協作的場景（Day 22）
分散式訓練（DDP／FSDP）對應職缺比例極低要訓練 10B 以上模型時
各家雲端的專屬服務認證觀念相通，工具可換；先學開源版本理解原理確定要進的公司用哪一朵雲之後

⚠️ 但這三件事不能省

可重現、監控、評測。 這三項在每份職缺裡都不是最顯眼的關鍵字，卻是資深與初階的實質差別。它們的共同點是：做了不會有人稱讚，沒做遲早會出事。

今日小結​

  • 三條轉職路線起點不同：後端／DevOps 缺「ML 特有的坑」、資料科學家缺「工程紀律」、前後端缺「LLM 的行為特性」。
  • 學習排序三原則：能動手優先於懂原理、先學會被依賴的、先建立回饋迴路再優化。
  • 30 天可依主軸速成取用，Day 08 分流、Day 24 合流；交會段（24–27）都要讀別跳過。
  • 明確的止損點：自建叢集、從頭訓練、全參數微調、多代理框架、分散式訓練、雲端專屬認證——優先排序往後，在此之前您還有更重要的事。
  • 不能省的三件事：可重現、監控、評測。

明天預告​

第一部曲結束，明天進入地基。我們從最實際的地方開始：您的開發環境。Python 環境、Git 在 ML 專案的特殊性（大型檔案、資料、金鑰）、第一個 Dockerfile，以及一個太多人踩的坑——把 API 金鑰推上 GitHub。

← Day 03 ｜ Day 05 →

本文同步發布於 iThome 鐵人賽；Blog 版本為站內閱讀與系列導覽的主要版本。