Day 02：用資料說話——4,343 筆職缺的任務訊號解剖

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

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

今天要解決的問題

你可能看過這種標題：「2026 最缺的 10 個 AI 職缺」「AI 人才缺口達 XX 萬人」。點進文章，對於樣本數、擷取日期、判定標準模糊，姑且不論對錯，但事實你無法判斷它對不對。

所以今天我試圖交代資料怎麼來的、交代怎麼分級的、以及最重要的——在這樣的搜尋整理基礎之上，哪些解論不適合說。

📊 職缺訊號

今天這篇本身就是「職缺訊號」的方法論。所有後續 28 篇引用的百分比，都來自這一份資料；看完這篇，您可以自行判斷該給這些數字多少信任。

---

一、現象：從 7,149 列到 842 筆

資料擷取日為 2026 年 7 月 25 日（Asia/Taipei），來源是公開搜尋頁與同源搜尋 API，使用 12 組固定關鍵字：

查詢詞	當日實抓列數	備註
生成式 AI	3,010	受平臺 100 頁上限限制
RAG	898	完整或近完整擷取
模型部署	837	完整或近完整擷取
大型語言模型	695	完整或近完整擷取
模型監控	595	完整或近完整擷取
LangChain	310	完整或近完整擷取
Agentic	314	完整或近完整擷取
MLOps	275	完整或近完整擷取
LlamaIndex	118	完整或近完整擷取
MLflow	45	完整或近完整擷取
Kubeflow	33	完整或近完整擷取
LLMOps	19	完整或近完整擷取

注意最後一列：LLMOps 全台只有 19 筆。這不代表 LLMOps 不重要，而是這個詞還沒成為招募文字的通用語——實際在做 LLMOps 的職缺，多半掛在「MLOps 工程師」或「AI 工程師」的標題底下。這是解讀職缺資料時最容易踩的坑：你搜到的是詞，還不是工作職務主要描述。

接著是四道關卡：

圖 2-1：職缺資料的分級漏斗（實際統計，2026-07-25 擷取）。左圖是四道關卡的收斂過程，右圖是去重後 4,343 筆的相關度組成。

1. 去重：同一筆職缺可能被多組查詢命中，依職缺編號（jobNo）去重，7,149 列 → 4,343 筆。
2. 相關度分級：依技術職稱、技術關鍵詞與工作任務訊號，分為高相關、中相關、待複核、低相關／排除。
3. 正式分析母體：高／中相關共 842 筆（19.4%），這才是後續所有任務訊號的計算基礎。
4. 嚴格分析池：在高／中相關中，職類技術詞分數達門檻者，MLOps 側 195 筆、生成式 AI 側 700 筆，用於計算任務訊號比例。

📌 為什麼要留下 2,504 筆低相關職缺？

因為不刪除才能反向抽查。如果把判定為不相關的資料直接丟掉，就永遠不會發現分級規則的偽陰性（把該算的算掉了）。這也是資料工作的紀律之一，Day 09 談資料驗證時會再遇到同一個原則。

二、原理：任務訊號怎麼算、代表什麼

「任務訊號」的定義很樸素：在職缺標題與工作摘要中，可觀察到的特定工作任務文字。一筆職缺可以同時命中多項任務，所以比例不會加總為 100%。

圖 2-2：兩項職務的工作任務訊號（實際統計，2026-07-25 擷取；左 n=195，右 n=700）。這張圖決定了本系列 30 天的篇幅配比。

這張圖是整個系列的「課綱來源」。您可以直接把它當成投資報酬率表來看：

• MLOps 側：平臺與基礎設施 58.5% 遠高於其他，所以 Day 12（K8s／GPU）與 Day 15（平臺與成本）各給一整天。
• 生成式 AI 側：RAG 48.1% 與 Agent 47.6% 幾乎並列，所以 RAG 給三天（Day 18–20）、Agent 給兩天（Day 21–22）。
• 兩側都有的「部署與 LLMOps」（38.7%）與「治理安全」（13.8%／34.3%），構成 Day 24–27 的交會段。

再看市場分布，這對「要不要搬到台北」是實際的決策資訊：

圖 2-3：高／中相關職缺的產業與地區分布（實際統計，n=842，2026-07-25 擷取）。

電腦軟體服務業以 189 筆（22.4%）居首，但把電腦及週邊設備製造、半導體、IC 設計、消費性電子加總起來也有相當份量——這是台灣特色：AI 工程職缺不只在網路公司，硬體與半導體業同樣在徵。地區上台北市內湖區以 102 筆（12.1%）最集中，但新竹市有 50 筆（5.9%）、台中西屯 25 筆——這通常對應製造業與半導體的內部 AI 平臺團隊。

三、動手：自己跑一次迷你版

不要只相信我的數字。你可以用同樣的方法，針對你自己關心的關鍵字跑一次迷你分析。下面是分析骨架（擷取的部分請自行以合法方式取得，並遵守目標網站的服務條款與 robots.txt）：

import pandas as pd

# jobs：至少包含 jobNo（職缺編號）、title（職稱）、description（工作摘要）三欄
jobs = pd.read_csv("jobs_raw.csv")

# 步驟 1：去重——分析單位是「職缺」，不是「搜尋結果列」
jobs = jobs.drop_duplicates(subset=["jobNo"])
print(f"去重後：{len(jobs)} 筆")

# 步驟 2：定義任務訊號的關鍵詞（可依你的職務調整）
SIGNALS = {
    "RAG 與企業知識庫":     ["RAG", "檢索增強", "向量資料庫", "知識庫", "embedding"],
    "Agent 與工具串接":     ["Agent", "代理", "工作流", "function call", "MCP"],
    "模型部署與推論服務":   ["部署", "推論", "serving", "API 服務", "Triton", "vLLM"],
    "監控與可靠性":         ["監控", "漂移", "drift", "SLO", "可觀測"],
}

text = (jobs["title"].fillna("") + " " + jobs["description"].fillna("")).str.lower()
for name, kws in SIGNALS.items():
    hit = text.apply(lambda t: any(k.lower() in t for k in kws))
    jobs[name] = hit
    print(f"{name}: {hit.sum()} 筆（{hit.mean():.1%}）")

# 步驟 3：交叉看——哪些任務常常一起出現？（這才是「職務長什麼樣」的線索）
print(jobs[list(SIGNALS)].astype(int).corr().round(2))

第 3 步是重點。 單看每項任務的比例只能知道「市場要什麼」，看任務之間的共現關係，才能知道「這些任務是不是同一個人在做」——這正是判斷「該不該是同一個職務」的證據。

四、取捨：這份資料不能說的五件事

這是今天最重要的一段。以下五句話，用這份資料說出來都是錯的：

❌ 不能說	為什麼
「全台有 842 個 AI 職缺」	這是單一平臺、單日橫斷面、12 組關鍵字的搜尋結果，不是全國普查
「生成式 AI 職缺有 26,019 個」	那是搜尋頁回報的查詢結果指標，會隨排序、同義詞、刊登狀態變動；且該查詢受 100 頁上限，實抓率僅約 11.6%
「AI 人才缺口 XX 人」	職缺數 ≠ 缺口。一個職缺可能徵多人，也可能長期掛著不招
「這個月需求成長了 15 筆」	兩次擷取的差異可能來自新刊、下架、重新刊登或搜尋排序變動，不是需求成長率
「58.5% 的 MLOps 工程師在做平臺」	正確說法是「58.5% 的相關職缺文字提到平臺相關任務」。招募文字反映的是期待，不是實際工時分配

還有兩個技術性限制要一併聲明：工作摘要可能被截斷，所以所有任務訊號比例都應視為「可觀察下限」；以及相關度與任務標記是規則預編碼，尚未經人工逐筆複核與企業訪談驗證。

⚠️ 那這份資料還有什麼用？

它非常適合回答一個問題：「在公開招募文字中，哪些工作任務被反覆提及？」 這對「我該學什麼」已經足夠了。它不適合回答「市場總量有多大」——但老實說，後者對個人職涯決策的幫助，遠不如前者。

---

今日小結

• 資料為 2026-07-25 單日橫斷面：12 組查詢、7,149 列、去重 4,343 筆、高／中相關 842 筆、嚴格分析池 MLOps 195／生成式 AI 700。
• 任務訊號＝招募文字中可觀察的工作任務，一筆職缺可命中多項，比例不加總為 100%，且應視為可觀察下限。
• 搜到的是詞不是工作：LLMOps 只有 19 筆，不代表沒需求，而是這個詞還沒進入招募用語。
• 這份資料能回答「該學什麼」，不能回答「缺口多大、成長多快」——後續 28 篇引用時請一併記得這個邊界。

本文限制

• 關鍵字選取偏差（Keyword Selection Bias）： 初始僅設定 12 組固定關鍵字，即便我判斷具有相當程度的代表性，但也可能遺漏未涵蓋的新興關鍵字，導致整體母體從採集端即有選擇性偏差。
• 忽略隱性招募管道與頭部企業： 高階或頂尖 AI 職缺常透過 Internal Referral（內推）、Headhunter（獵頭）或 LinkedIn 直接聯繫，不會完全反應在公開人力銀行的搜尋頁面與 API 抓取資料中，還請見諒。

明天預告

知道市場要什麼之後，下一個問題是：這些事，難道不是資料科學家／DevOps／後端本來就在做的嗎？ 明天我們畫責任界面，把兩個新職務與五個既有角色的分工講清楚——包括小團隊裡「一個人扛全部」時該怎麼排優先順序。

---

← Day 01 ｜ Day 03 →

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