30 篇文章 含有標籤「AI Engineering」

30 天前，本系列從一份 AI 新興職缺資料出發，說市場已經分成兩個職務。29 天後，我們把這兩個職務的每一項工作任務都拆解、實作、並討論了取捨。

今天做三件事：回顧這條路徑的核心主張、檢討這個系列的限制、給三種讀者各一張路線圖。

28 天的技術內容結束了。今天處理最後一哩：怎麼讓別人相信你會這些。

這篇的內容比較「不技術」，但如果你的目標是轉職或升遷，它可能是投報率最高的一天。

前 27 天，我們一塊一塊地拆解了兩個職務的工作任務。今天要把它們組裝回一個完整的東西。

這也是我對每位讀者的建議：與其收藏 27 篇文章，不如做出一個作品。。

技術面完成了，今天處理制度面——也是這個系列裡最容易被工程師跳過、卻最可能決定專案生死的一天。

昨天談的是「怎麼做得又快又便宜」，今天談的是「怎麼確保這件事做得下去」。

今天是雙主軸真正交會的一天。

• 主軸一的讀者：這是 Day 13（延遲與吞吐）在 LLM 上的延伸，你的直覺全部適用，只是數字大一個量級。
• 主軸二的讀者：這是你的系統能不能規模化的關鍵。做得出 demo 與撐得住一萬人，差別就在今天。

Day 02 提到 LLMOps 全台只有 19 筆職缺——但那是因為這個詞還沒進入招募用語。實際上做這件事的人，需求很大。

昨天讓系統「品質可測」，今天讓它「不會闖禍」。

這一天的內容有個特性：平常沒有人在意，出事一次就記得一輩子。它是 Day 22 那五道護欄的理論基礎，也是 Day 27 治理的技術面。

⚖️ 前提聲明

本文所有攻擊手法的說明，僅以防禦與合法授權測試為目的。文中的紅隊演練請務必在你自己擁有或已取得書面授權的系統上進行。未經授權對他人系統進行測試，於我國《刑法》妨害電腦使用罪章可能構成犯罪。

今天是合流點。前十六天兵分兩路，從今天起的四天，兩條路的人都要看——因為評測、安全、LLMOps、治理，是兩個職務共同的責任。

而評測是其中最關鍵的：它是「做得出 demo」與「做得出產品」的分界線。

主軸二的最後一個技術主題。前七天我們讓模型「知道」（RAG）、「能做」（Agent），今天讓它「像我們要的樣子」。

我把微調放在最後，是刻意的——因為它是最後才該考慮的手段。

昨天手刻了 ReAct 迴圈，也給了兩個護欄（迭代上限、成本上限）。今天處理讓它能真正上線的三件事：工具怎麼接得可維護、多代理什麼時候值得、怎麼確保它不會闖禍。

RAG 讓模型「知道」，Agent 讓模型「能做」。今天進入第二高頻的任務訊號（47.6%）。

但我要先講一個可能讓你意外的建議：你需要的多半不是 Agent。

RAG 三部曲的最後一天。文件進去了（Day 18）、找出來了（Day 19），今天處理怎麼用與怎麼知道好不好。

後半段特別重要——因為 Day 19 提到的所有優化，你都需要一把尺才知道有沒有效。

昨天說明文件的索引，今天處理：怎麼把對的東西找出來。

今天說明的混合檢索、重排序、查詢改寫等3個技術是實務上 CP 值最高的三個優化，而且都不需要換模型。

今天進入生成式 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 落地：不從技術出發，而是從職缺出發。