18 篇文章 含有標籤「2026 iThome 鐵人賽」

今天進入生成式 AI 職缺中出現頻率最高的主題：RAG（48.1%）。

因為它太重要，我用三天處理：今天講索引端（文件怎麼進去）、明天講檢索端（怎麼找出來）、後天講生成與評測（怎麼用、怎麼知道好不好）。

如果你只能讀一天，讀今天——因為多數 RAG 系統的品質上限，在文件進資料庫的那一刻就決定了。

2020 年我初次參加鐵人賽寫的是《用 LINE 串起多媒體系統》（GitHub），那 30 天在做的事，本質上是：接收使用者訊息 → 判斷意圖 → 呼叫對應的服務 → 組裝回應。

六年後的今天，我們做的事情架構上驚人地相似，但有一件根本性的不同：

2020 年，「判斷意圖」是我用 if "天氣" in text 寫死的。 2026 年，這件事由模型決定，而且它還會自己決定要呼叫哪個 API、帶什麼參數。這一行差別，就是今天的主題。

今天進入主軸二：生成式 AI。前八天我們在解決關於 MLOps 的「模型會不會掛」，接下來八天解決「模型會不會智商下線」。

主軸一的讀者會發現，這邊的問題同樣需要工程紀律，只是換了一種形式。

前七天，我們一路處理模型如何可靠地上線、持續部署、監控，以及出問題時怎麼發現。今天換一個主管通常更有感的問題：

這套 AI 系統，到底花多少錢？

模型能活著還不夠，還要活得起。如果工程師只能回答「這樣架構比較漂亮」，很難推動決策；但如果能回答：「這個方案每月多花多少？」、「GPU 利用率提升後，可以少買幾張卡？」、「租雲端和買地端的成本交叉點在哪？」對話就完全不同了。

今天要解決的問題​

先看兩個很常見的情境。

場景一
主管：「我們要不要買 GPU？一直租雲端好貴。」 工程師：「呃……我算一下？」
然後這個問題被擱置了三個月。

場景二 主管：「上季買的四張 A100，用得如何？」
工程師：「都有在用啊。」
主管：「利用率多少？」
工程師：「……」

這兩題沒有放諸四海皆準的答案，但有一套可以量化的決策方式。

今天就處理兩個數字：

1. 成本平衡點：什麼使用量下，租雲端與買地端的成本開始交叉？
2. GPU 利用率與單位成本：買下來的卡，到底有多少時間真的在工作？這些工作又產生多少價值？

📊 職缺訊號

「AI／ML 平臺與基礎設施」是這次 MLOps 職缺中最高頻的任務訊號之一，占 58.5%。

不過 JD 的層次差異很大：初階可能寫「維護 GPU 環境」，資深職缺則會出現「規劃 AI 運算資源」、「容量管理」、「平臺工程」與「成本最佳化」。

分水嶺不只是會不會架環境，而是能不能把技術選擇轉成容量、成本與風險的決策。

Day 04 曾說過「不能省的三件事」：可重現、監控、評測。Day 08 提到「只能投資一項就選監控」。今天就講為什麼。

如果這 30 天你只讀一篇，建議這篇要讀。

昨天服務跑起來了。今天回答：它跑得好不好？

面試時很容易被問到的題目，包含「你的服務延遲多少」、「怎麼提升吞吐」及「P99 為什麼重要」？這三題答得好，入職的機率大大提升。

今天進入 MLOps 職缺中出現頻率最高的領域：AI／ML 平臺與基礎設施（58.5%）。

本日不包含 Kubernetes 的全部——那是一本書的量，而且新入職的你優先事項不包含建立叢集（Day 04 的止損點清單裡有說明）。今天只講跑 ML 工作負載時，與跑一般 Web 服務不一樣的那些地方。

資料有版本（Day 09）、實驗有紀錄（Day 10），今天加上最重要會擋人的門，把它們串成一條自動跑也安心的管線。

這是 Level 0 到 Level 1 的關鍵一步，也是 Day 08 診斷表第 1、6、7 題的內容。

昨天資料有了版本。今天處理另外兩根柱子：這次訓練用了什麼設定、跑出什麼結果、產出的模型在哪裡。

這是 Day 08 診斷表第 3、5 題的內容，也是導入成本最低、痛感解除最快，投資報酬率最高的一天。

昨天的成熟度診斷中，其中「訓練前自動檢查資料」與「重現三個月前的訓練」應是最多團隊答「否」的兩題。今天就處理這兩題。

Day 06 說過可重現需要五根柱子，今天說明資料版本與隨機種子這根支柱，也順便處理一個棘手的問題。

2021 年那套成熟度模型，在 2026 年還適用嗎？ 我的答案是：框架適用，內容要改寫。

本系列為 MLOps × GenAI Engineering 雙主軸，走主軸二的讀者可以略讀，但建議至少看完第二節——那是你未來合作對象的世界觀。

今天也是這個系列與 2021 年《從 AI 落地談 MLOps》 正面對話的一天。

今天只聚焦在 Token 怎麼計價、生成怎麼進行、模型怎麼選這三件事，會直接影響你系統設計與帳單，也可能導致容易做出錯誤架構決策的部分。

本篇不會重講 Transformer 的數學（網路上已有太多好文章）。加上前兩天說明了「工程」與「ML」，今天說明「LLM」進行打底。

ML 專案跟一般軟體專案，到底哪裡不一樣？，在開發環境的建立之後，今天要處理 ML 系統成敗的認知問題。

「在我電腦上明明跑得起來啊。」

這句熟悉的對話日常，在 ML 系統會是場災難，因為 ML 多了兩個變數：資料與模型權重。第一部曲我們將 AI 職缺目前在市場的需求進行說明，第二部曲聚焦在地基，今天要做的，就是降低只能回答出「在我電腦上明明可以」的風險。

站在哪裡往前走​

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

站在哪裡往前走​

昨天我們確認了就業市場的徵才概況。今天要處理一個很多人心裡的疑問：這些事，不是資料科學家、DevOps、後端本來就在做的嗎？為什麼要多兩個職務？

這個問題很好，而且答錯的代價很實際——它決定了您面試時該強調什麼、進團隊後該對齊誰、以及出事時該誰負責。

昨天提到，這一系列文章是從真實需求出發，透過整理新興 AI 職缺，我觀察到目前市場上的 AI 人才需求，已逐漸分化成兩類不同的職務方向。今天，就想進一步和大家分享我從職缺資料中看到的變化與趨勢。

透過實際職缺的觀察，再對照過去 MLOps 發展至今的市場變化，我更希望把這些真實世界中的人才需求，重新扣回到一個最實際的問題：如果我們想成為 AI Engineer，現在究竟該如何準備？

2021 年，我在鐵人賽寫了《從 AI 落地談 MLOps》（GitHub）。那 30 天在回答一個問題：模型訓練好了，然後呢？

五年後，這個問題不但沒有過期，還變得更尖銳了——因為現在連「訓練模型」這件事，仍不是大眾的選項，很多團隊任務不再於訓練模型，而是直接呼叫 API，兩週做出一個看起來很厲害的 Demo，然後卡在同一個地方：上不了線，或者上線了沒人知道它是好是壞。

這 30 天，我想用一個不太一樣的方式重新回答 AI 落地：不從技術出發，而是從職缺出發。