重點摘要(TL;DR)
① 先讓大 LLM 把現場通報分群,找出高頻任務(真跑:最大兩群佔 70%)。② 收資料 = 大 LLM 蒸餾出
① 先讓大 LLM 把現場通報分群,找出高頻任務(真跑:最大兩群佔 70%)。② 收資料 = 大 LLM 蒸餾出
train.jsonl + 人校對 + 去識別;fine-tune 教行為、RAG 供知識。③ 訓練 = Unsloth 的 gpt-oss-20b QLoRA,免費 Colab T4(16GB)就跑得動,附 4 個實戰坑。④ 上線 = schema + 枚舉 + OOD 三道 gate;真跑攔下小模型把「無塵室濕度」誤判成「溫控異常」。這是「大 LLM 找任務、小模型幹活」系列的落地篇。前面談方法論與選型,這篇只做一件具體的事:挑一個工廠任務,手把手走完「要收怎樣的資料」跟「怎樣訓練」。分群、抽取、驗證這幾段我真的在一台沒有 GPU 的機器上跑過(用 Ollama 本地模型),訓練段接的是我在 gpt-oss-20b 微調實戰 那篇實際踩過的坑。
為什麼挑「押出溫控通報」這個案例
方法論的第一步是讓大 LLM 當偵察兵,找出高頻又格式穩定的任務。我拿 44 筆合成的產線異常通報(電線電纜/不鏽鋼廠情境,全部是假資料),用 bge-m3 算語意向量後分群,真實跑出來的結果是:
| 叢集 | 筆數(佔比) | 類型 |
|---|---|---|
| #1 | 17 筆(38.6%) | 抽線斷線斷芯 |
| #2 | 14 筆(31.8%) | 押出機溫控異常 |
| #3 | 5 筆(11.4%) | 鍍層退火異常 |
| #4 | 4 筆(9.1%) | 機構卡料 |
| #5 | 4 筆(9.1%) | 電氣訊號異常 |
最大的兩個叢集就佔了全量 70%。 這就是訊號:先把「抽線斷線」跟「押出溫控」這兩類蒸餾成小模型,投資報酬率最高。這篇用押出溫控通報 → 結構化工單當範例。任務目標很單純,把現場口語的一句通報,抽成固定欄位的 JSON:
"3號押出機第二段溫度飆到245度,設定值210,料表面有焦痕"
↓ 抽取
{ "設備": "3號押出機", "異常現象": "第二段溫度超標(245/210)、料面焦痕",
"異常類別": "溫控異常", "嚴重度": "高", "建議班別": "製程班" }Part 1 — 要收怎樣的資料
先分清楚:你在教「行為」還是「知識」
一句話鐵律
fine-tune 教「怎麼答」,RAG 供「答案內容」。想讓它知道某規章/料號/客戶內容 → 用 RAG(不要塞進訓練集,會過時、會幻覺);想讓它用固定格式/流程回答 → 用 fine-tune。
fine-tune 教「怎麼答」,RAG 供「答案內容」。想讓它知道某規章/料號/客戶內容 → 用 RAG(不要塞進訓練集,會過時、會幻覺);想讓它用固定格式/流程回答 → 用 fine-tune。
我們這個抽取任務要教的是「把口語變成固定 JSON 欄位」這個行為,所以是 fine-tune 的活。
一筆資料長什麼樣
訓練資料是 JSONL(一行一筆),每筆是一段對話(chat 格式),三個角色 system / user / assistant:
{"messages":[
{"role":"system","content":"你是押出線異常通報的結構化抽取器。只輸出 JSON,欄位:設備、異常現象、異常類別(溫控異常/斷線斷芯/鍍層退火異常/機構卡料/電氣訊號異常 五選一)、嚴重度(高/中/低)、建議班別(機械班/電氣班/製程班/品保班)。"},
{"role":"user","content":"3號押出機第二段溫度飆到245度,設定值210,料表面有焦痕"},
{"role":"assistant","content":"{\"設備\":\"3號押出機\",\"異常現象\":\"第二段溫度超標(實際245/設定210)、料面焦痕\",\"異常類別\":\"溫控異常\",\"嚴重度\":\"高\",\"建議班別\":\"製程班\"}"}
]}三個一致性要求(違反會讓模型學亂):
- 同一任務用同一個 system——規則不要每筆換。
- assistant 的格式嚴格一致——欄位、順序、鍵名都固定。
- 不要有矛盾範例——同類情境不要給相反答法。
資料從哪來:用大 LLM「蒸餾」,人校對定品質
不要手刻幾百筆。既有工廠的好處是有現成的歷史通報單、工單、MES 備註可以挖。流程:
- 盤來源:歷史異常通報、維修工單、交接紀錄、報表備註。
- 大模型出草稿(蒸餾):把歷史通報批次餵給大 LLM(就是偵察兵那顆),叫它輸出「通報原文 → 理想 JSON」的成對資料。這一步在我的 sample 裡就是 Phase 0 scout。
- 人工校對(這步不能省):修掉幻覺、對齊格式、刪爛的。AI 出量,人把關。
- 去識別:遮蔽人名、客戶名、機密料號(換成
[料號]、[客戶])。 - 品質檢查(見下)。
蒸餾用的 prompt 範本(直接可用):
你是資料標註助手。以下是一批歷史異常通報。
請每則產生一組訓練範例:通報原文(user)+ 依規則抽取的理想 JSON(assistant)。
規則:
- assistant 只輸出 JSON,欄位固定:設備/異常現象/異常類別/嚴重度/建議班別
- 異常類別只能五選一,不在清單的標「其他」讓人工複審
- 只依原文抽取,不要編造數字
- 輸出 JSONL,每行一個 {"messages":[{system},{user},{assistant}]}
---
(貼上歷史通報)要多少筆、怎麼配
| 目標 | 這個任務的筆數 |
|---|---|
| 概念驗證(PoC) | 30–50 筆 |
| 可上線初版 | 100–200 筆 |
- 切 10% 當驗證集(不參與訓練,專門測「學會沒/變笨沒」)。
- 品質 >> 數量:200 筆乾淨的,勝過 1000 筆雜的。
上訓練前的品質檢查清單
- 每筆都是合法 JSON,一行一筆
- 同任務 system 完全一致
- assistant 格式嚴格一致(欄位/順序/鍵名)
- 沒有矛盾範例
- 敏感資訊已去識別
- 涵蓋常見情境(不是只有一種問法)
- 沒有「純知識查詢」混進來(那些該 RAG)
Part 2 — 怎樣訓練(接我 Colab 那次的真實經驗)
工具鏈:Unsloth + gpt-oss-20b(4-bit)+ QLoRA。免費 Google Colab T4(16GB)就跑得動——gpt-oss-20b 的 QLoRA 只吃約 14GB。真華新資料有隱私,別上 Colab,改租私有裸機 GPU、公司機、或 Azure A100 / DGX Spark,同一套流程。
步驟濃縮
- 開 Unsloth 官方 gpt-oss-20b Fine-tuning 的 Colab notebook,Runtime 選 T4 GPU。
- 上傳你的
train.jsonl。 - 依序跑安裝與載模型的 cell(
pip install unsloth、載 4-bit 模型、掛 LoRA)。 - 把載 dataset 那格改成讀你的檔(見下)。
- 跑
trainer.train(),看 loss 逐步下降。 - 存 adapter:
model.save_pretrained("my-lora")——這個幾百 MB 的 adapter 就是你的資產本體。
from datasets import load_dataset
ds = load_dataset("json", data_files="train.jsonl", split="train")
# 已是 chat 格式(messages),notebook 的 formatting 函式通常直接吃我真的踩過的 4 個坑(gpt-oss + 免費 T4 特有)
- loss = nan:gpt-oss 在 T4 上數值敏感,
learning_rate從2e-4降到1e-5就正常。 train_on_responses_only報錯(masked every label -100):那是給推理型資料的選用優化,對純抽取資料會壞掉,直接跳過這格。- 答案被切斷、只剩英文思考:gpt-oss 是 reasoning 模型會先想再答,把
reasoning_effort="low"、max_new_tokens加到 512。 - 亂呼叫工具(跑進 commentary 通道生假
functions.run):reasoning_effort調低,或 system prompt 明講「別呼叫工具,直接輸出 JSON」。
幾個數字的由來(別照抄,要理解)
| 參數 | 值 | 為什麼 |
|---|---|---|
| learning_rate | T4 用 1e-5 / 私有 GPU 用 5e-5 | T4 數值敏感易 nan;A100 可收斂快一點 |
| epochs | 3 | 太少學不會格式,太多 overfitting(只會吐格式、通用能力變笨) |
| OOM 時 | max_seq_length=1024, batch=1 | 記憶體不足的第一個調整 |
驗收:兩個一定要測
- 學會沒:問一個沒訓練過的新通報,看它會不會自動吐正確 JSON 欄位。會 = 泛化成功。
- 有沒有變笨(catastrophic forgetting):問一個通用問題(如「用 Python 寫判斷質數的函式」),應該還答得出來。若整個壞掉只會吐 JSON = overfitting → 降 epoch / 降 lr / 資料再多元。
訓練這步沒在本機重跑(誠實說明)
本文機器沒有 GPU,押出抽取模型的 QLoRA 訓練沒有在此重跑。數字沿用我上次在免費 Colab T4 用 15 筆資料跑通的真實紀錄:loss 從 5.9 降到 4.6、約 11 分鐘,對沒訓練過的新問題自動用學到的格式作答 = 泛化成功。
本文機器沒有 GPU,押出抽取模型的 QLoRA 訓練沒有在此重跑。數字沿用我上次在免費 Colab T4 用 15 筆資料跑通的真實紀錄:loss 從 5.9 降到 4.6、約 11 分鐘,對沒訓練過的新問題自動用學到的格式作答 = 泛化成功。
Part 3 — 上線後怎麼「接住錯誤」(這步決定敢不敢上線)
小模型不會因為「格式沒變」就一定答對。可靠性不是「相信它一定對」,是「錯了接得住」。因為 RPA 的輸出是結構化的,每一筆都能過三道 gate:
- Schema 檢查:五個欄位都在、非空嗎?
- 枚舉檢查:
異常類別、建議班別落在合法清單嗎? - OOD(新任務)偵測:這筆跟 Part 1 分群的中心有多近?太遠 = 沒見過的新型態,不要讓小模型硬猜。
過三道的 → 直接進 MES;沒過的 → 自動升級給大 LLM 或人。
真實跑一遍:小模型果然會「有把握地答錯」,而 gate 接住了
把 12 筆代表通報丟給本地小模型(qwen2.5:3b)零樣本抽取,再過三道 gate,真實結果(節錄):
| 通報(節錄) | 小模型判的類別 | 與分群中心相似度 | gate 路由 |
|---|---|---|---|
| 3號押出機第二段溫度飆到245度 | 溫控異常 | 0.84 | PASS |
| 抽線機6模斷線,一小時斷三次 | 斷線斷芯 | 0.84 | PASS |
| 鍍層附著測試不過,彎折剝落 | 鍍層退火異常 | 0.86 | HOLD(缺「設備」) |
| 無塵室濕度超標到78%,除濕壞了 | 溫控異常 ← 答錯 | 0.73 | ESCALATE |
| 冷卻水塔pH值異常偏酸 | 溫控異常 ← 答錯 | 0.70 | ESCALATE |
| 押出機溫度正常但收線又斷線+排線器卡(三故障) | 機構卡料 ← 只挑一個 | 0.82 | PASS(漏接) |
真實路由統計:OOD 門檻 = mean 0.807 − std 0.046 = 0.761(資料驅動,非硬編);結果 PASS 7 / HOLD 3 / ESCALATE 2。三個真實觀察:
- 小模型不會說「我不知道」,只會挑一個最像的。 它把「無塵室濕度」「冷卻水塔 pH」這兩個根本不是製程異常的通報,硬歸成「溫控異常」。這就是為什麼不能盲信。
- 但 gate 靠的不是模型自白。 這兩筆的相似度(0.73、0.70)掉到門檻(0.761)以下,OOD gate 直接攔下、升級。「錯了接得住」在真實數字上成立——而且 OOD gate 直接複用 Part 1 的分群中心,分群跟上線是同一套語意空間。
- 誠實講限制:三故障合併那筆 PASS 了。 單一標籤的「似是而非」,現在這三道 gate 抓不到。這是下一步要補的(多故障偵測 → 強制低信心)。沒有一套 gate 一勞永逸,它是持續補的——而補的材料,就是每一筆被 ESCALATE 的案例。
換個案例:一堆手機拍的發票 PDF → 自動進 ERP
客戶丟來一堆發票 PDF:一張 PDF 裡好幾張、拍得歪來歪去、有大張有小張、手機直接拍的,目標是全部自動建檔進後面的 ERP。這個案例跟前面的文字通報不同在兩點:① 輸入是影像,LLM 之前多了影像處理關;② 輸出可以「算」對錯,gate 是硬規則。
這條 pipeline 在 LLM 之前多了什麼
文字通報是純文字直接抽。發票要先過影像關:
- PDF → 影像、切出每一張發票(PyMuPDF/pdf2image;多張擠一頁用版面偵測,或直接請 VLM 分割)。
- 去歪、裁切(OpenCV deskew、手機拍照的透視校正)。
- 抽取:用 VLM(視覺語言模型,如 Qwen2.5-VL)直接吃拍歪的發票影像 → 結構化 JSON,OCR + 版面 + 抽取一次做完。
方法論一模一樣,只是「小模型」換成「小 VLM」:大 VLM 當偵察兵把各種發票版型跑一遍 → 分群找高頻版型 → 蒸餾成小 VLM。收資料 = (發票影像 → gold JSON) 成對,刻意涵蓋大小張、拍歪、多張一頁。
但發票的 validation gate 強得多:能「算」出對錯
文字通報的 gate 靠語意相似度(軟,會猜)。發票有硬規則,能算:
- 發票號碼格式(2 字母 + 8 數字)
- 統一編號 checksum(8 位數有校驗碼,錯一位就抓得到)
- 稅額算術:未稅 × 5% = 稅額、未稅 + 稅額 = 含稅總計
- 日期合法
統一編號 checksum 是真的可以算的(台灣 8 位統編校驗碼):
# 台灣統一編號 checksum(8 位)
w = [1,2,1,2,1,2,4,1]
def ubn_ok(s):
ds = lambda n: n//10 + n%10 # 個位+十位
t = sum(ds(int(s[i])*w[i]) for i in range(8))
return t%5==0 or (s[6]=='7' and (t+1)%5==0)真跑一遍 8 張合成發票(假設 VLM 已讀出欄位),過這道硬規則 gate,真實結果:
| 發票號碼 | gate 路由 | gate 抓到什麼 | 實際的錯 |
|---|---|---|---|
| AB-12345678 | PASS | 全過 | 乾淨 B2B |
| XY-88881234 | PASS | 全過 | B2C 買方統編空(合法,不誤殺) |
| CD-20260011 | HOLD | 賣方統編 checksum 不過 | OCR 讀錯一位數字 |
| EF-30301111 | HOLD | 8000+400=8400 ≠ 8500 | 含稅總計讀錯 |
| GH-40402222 | HOLD | 含稅=兩張加總 12600 ≠ 25200 | 多張擠一頁沒切乾淨 |
| IJ-50503333 | ESCALATE | 缺賣方統編 | 拍照切掉上緣 |
| 1J-50503333 | HOLD | 發票號碼格式不合 | OCR 把字軌 I 讀成 1 |
| KL-60604444 | HOLD | 日期無法解析(民國) | 民國格式,pipeline 缺 converter |
結果 PASS 2 / HOLD 5 / ESCALATE 1。三個觀察:
- 硬規則 = 幾乎確定,不是猜。 統編 checksum + 稅額算術,對就是對、錯就是錯。這就是為什麼發票自動化敢做到接近全自動——它「算得出來」。
- 多張擠一頁被算術抓到。 GH 那張含稅是兩張加總(12000+600≠25200)直接 HOLD,切錯不會默默進 ERP。
- HOLD 不等於丟人、gate 也不誤殺。 民國日期那張不是發票錯,是 pipeline 少一個「民國→西元」converter——HOLD 告訴你要補什麼;而 B2C 那張買方統編空,gate 知道是合法選填,照樣 PASS。
選哪顆 model、怎麼接(2026 查證)
主力用 VLM(視覺語言模型),不是純 OCR——它把 OCR + 版面 + 抽取一次做完,最能吃「拍歪、多張擠一頁」。
| 角色 | 推薦 model | 大小 / VRAM | 為什麼 |
|---|---|---|---|
| 主力抽取 SLM | Qwen2.5-VL-7B-Instruct | 7B,4-bit 推理 ~6–8GB | 原生訓練就做發票/表單結構化抽取,7B 就贏 GPT-4o-mini;Ollama 有 |
| 高量 edge 版 | Qwen2.5-VL-3B | 3B,更輕 | 官方定位邊緣,比上代 Qwen2-VL-7B 還強;本文就用它跑真測 |
| 偵察兵 / 產標註 | Qwen2.5-VL-72B 或 Qwen3-VL 旗艦 | 大(可雲端) | 讀最亂的版型、生 gold JSON 給小模型蒸餾 |
| 純 OCR 層(走 OCR+LLM 才需要) | PaddleOCR-VL / dots.ocr / GOT-OCR2 | 小 | 準度 / 成本 / VRAM 各有最佳解 |
一句話:主力就 Qwen2.5-VL-7B,先 zero-shot 試,準度不夠再 QLoRA 微調;高量再蒸到 3B。第 ③ 步 VLM 呼叫(Ollama,影像走 base64):
import base64, json, urllib.request
img = base64.b64encode(open("invoice.jpg","rb").read()).decode()
prompt = "讀這張發票,只輸出 JSON,欄位:發票號碼、日期、賣方統編、買方統編、未稅金額、稅額、含稅總計。"
body = {"model":"qwen2.5vl","prompt":prompt,"images":[img],
"stream":False,"format":"json","options":{"temperature":0}}
req = urllib.request.Request("http://localhost:11434/api/generate",
data=json.dumps(body).encode(), headers={"Content-Type":"application/json"})
fields = json.loads(json.load(urllib.request.urlopen(req))["response"])怎麼微調(換 VLM,方法論不變)
- 工具:Unsloth 的
FastVisionModel,載unsloth/Qwen2.5-VL-7B-Instruct-unsloth-bnb-4bit。 - VRAM:QLoRA 4-bit 只吃 ~6.5–8GB → 免費 Colab T4 / 一張 24GB GPU 就夠(24GB 上約 4–12 小時)。一樣不用 128GB。
- 收資料(蒸餾):大 VLM 批次讀歷史發票 → 生 JSON 草稿 → 人校對 → 幾百張涵蓋大小張/拍歪/多張一頁,去識別真實統編與客戶名。
VLM 的訓練資料格式(影像 + 對話,assistant 是 gold JSON):
{"image": "inv_0007.jpg",
"conversation": [
{"role":"user","content":[{"type":"image"},{"type":"text","text":"讀這張發票,輸出 JSON…"}]},
{"role":"assistant","content":[{"type":"text","text":"{\"發票號碼\":\"AB-12345678\", …}"}]}
]}真的用 Qwen2.5-VL-3B 跑一遍(本機 CPU、無 GPU)
為了不紙上談兵,我用 PIL 生了一張合成的台灣發票、再複製成一張旋轉 8° 的「手機拍照版」,然後拉 qwen2.5vl:3b 到本機(3.2GB)真的跑影像 → JSON → 過前面那道硬規則 gate。正解:發票號碼 AB-12345678 / 賣方統編 23000002 / 未稅 10000 / 稅 500 / 含稅 10500。
| 欄位 | VLM 讀到 | 正解 | 對? |
|---|---|---|---|
| 發票號碼 | AB-12345678 | AB-12345678 | ✅ |
| 賣方統編 | 23000002 | 23000002 | ✅ checksum 過 |
| 買方統編 | 53000004 | 53000004 | ✅ |
| 開立日期 | 2026/07/03 | 2026/07/03 | ✅ |
| 稅額 | 500 | 500 | ✅ |
| 含稅總計 | 10,500 | 10,500 | ✅ |
| 未稅金額 | null ← 漏讀 | 10,000 | ❌ |
拍歪 8° 的版本讀出來一模一樣(旋轉完全沒影響);兩張的 gate 都判 ESCALATE(缺未稅金額)——沒有半張帶著漏欄位進 ERP。四個真實觀察:
- 3B、CPU、零樣本,連拍歪 8° 的繁中發票都把發票號碼、統編、日期、金額讀對——賣方統編還是 checksum 合法的。小模型幹這個活夠格。
- 但它漏了「未稅金額」:發票上印的是「銷售額(未稅)」,跟我 prompt 的用字「未稅金額」不同,小模型沒對上。這正是微調要補的(用你自己的發票版型 + 一致欄位命名訓練)。
- gate 接住了:缺欄位 → ESCALATE,沒有一張帶漏欄位進 ERP。又一次證明「錯了接得住」——這次是真 VLM。
- 速度:CPU 上每張 130–173 秒 = 太慢,只能 demo;量產要一張 GPU(小張就夠,呼應右尺寸,不是 128GB)。
順帶一個工程巧思:gate 不只是「擋」,能算的還能「修」
這張其實 gate 可以自己救回來:VLM 給了稅額 500、含稅 10,500,未稅 = 含稅 − 稅 = 10,000 可反推,再驗 round(10000×5%)=500 ✓、10000+500=10,500 ✓ 完全自洽 → 可安全自動補,把 ESCALATE 變 PASS。有硬規則的資料,gate 除了擋錯,還能用不變式反推缺漏欄位。
這張其實 gate 可以自己救回來:VLM 給了稅額 500、含稅 10,500,未稅 = 含稅 − 稅 = 10,000 可反推,再驗 round(10000×5%)=500 ✓、10000+500=10,500 ✓ 完全自洽 → 可安全自動補,把 ESCALATE 變 PASS。有硬規則的資料,gate 除了擋錯,還能用不變式反推缺漏欄位。
教訓:gate 要配資料的可驗證性
| 案例 | 輸出性質 | 配的 gate |
|---|---|---|
| 押出溫控通報 | 判斷,無算術可驗 | schema + 枚舉 + OOD 相似度(軟,攔離群) |
| 發票建檔 | 數字 + 有校驗碼 | checksum + 稅額算術(硬,算出對錯) |
選任務的心法
資料越能被硬規則驗證,自動化能自動放行的比例越高。 挑要做的 RPA 任務時,優先選「輸出可被 checksum / 算術 / 格式驗證」的——發票、報關、金額對帳這類,最適合做到接近全自動。反之像自由文字判斷,gate 只能軟攔,人工複審比例天生較高。
資料越能被硬規則驗證,自動化能自動放行的比例越高。 挑要做的 RPA 任務時,優先選「輸出可被 checksum / 算術 / 格式驗證」的——發票、報關、金額對帳這類,最適合做到接近全自動。反之像自由文字判斷,gate 只能軟攔,人工複審比例天生較高。
誠實說明:VLM 影像抽取這步沒在本機跑
本文機器沒有 vision model,「發票影像 → JSON」的 VLM 抽取沒有實跑。但上面的 validation gate(統編 checksum + 稅額算術 + 格式)是真跑的,純 Python、無需模型。
本文機器沒有 vision model,「發票影像 → JSON」的 VLM 抽取沒有實跑。但上面的 validation gate(統編 checksum + 稅額算術 + 格式)是真跑的,純 Python、無需模型。
把三段機器串起來
| 階段 | 機器 | 角色 |
|---|---|---|
| ① 原型 / 資料 | Mac(64GB 就夠) | air-gapped 處理敏感料、原型、小量微調;抓預量化 4-bit 權重、一次原型一顆 |
| ② 訓練 / 調參 | Azure NC24ads_A100_v4 | 真資料的訓練 + 超參數 sweep |
| ③ 上線推理 | SLM 推理箱(右尺寸見下) | 蒸餾好的小模型跑高頻路徑;大 LLM fallback 視需求 |
右尺寸:多數情況不需要 128GB
先分清楚「大機器」是為誰
微調好的 SLM 很小:7B 4-bit ≈ 5GB、3B ≈ 2GB——本文 sample 的抽取就是用
微調好的 SLM 很小:7B 4-bit ≈ 5GB、3B ≈ 2GB——本文 sample 的抽取就是用
qwen2.5:3b 跑的。會需要 128GB 那種大機器,是為了另一顆大 LLM 通才 / fallback(如 gpt-oss-120B ≈ 63GB),不是為了 SLM。所以要拆成兩個獨立問題:跑 SLM 推理 vs 要不要一顆大的 air-gapped 通才。NVIDIA 那篇論文本身就主張別預設用大模型——重複工作交給 SLM,只在關鍵時刻保留通才,而那顆也可以不大。| Tier | 機器(每廠一台) | 跑得動 | 額外成本 |
|---|---|---|---|
| 0 先證明價值 | 現有 32GB mini PC 或 64GB Mac | 7B SLM×幾顆 + OOD gate + 小型 7–14B fallback | $0 |
| 1 | 一張消費級 GPU(RTX 4090/5090,24–32GB) | 更快 SLM + 14–32B fallback | ~$2–3k |
| 2 | DGX Spark 128GB | 只有要 70–120B air-gapped 通才才需要 | ~$4.7k |
這條 RPA 抽取線,一台 32GB 機器就能上線(本文 sample 已在無 GPU 的 32GB 機器上跑通分群、抽取、gate)。128GB 的 Spark 是之後「要一顆很強、完全離線的大腦做跨任務發現」時才划算,不是起手式。
一個工廠任務的完整生命週期:大 LLM 收 log → 分群找出高頻任務 → 蒸餾成訓練資料 → QLoRA 訓練 → 過 validation gate 上線 → 升級案例回收成下一輪資料。跑通一個,其他任務照抄同一條產線。延伸閱讀:從一顆腦到公司 Agent:LLM 全景地圖。
附:本文的分群、抽取、驗證在一台無 GPU 的機器上用 Ollama(bge-m3 + qwen2.5:3b)真實跑出;所有工廠通報為合成資料,不涉及任何真實公司資訊。訓練段的 loss/時間沿用先前 Colab T4 實測。
附錄:可直接用的 train.jsonl 範本(校對後)
下面 10 筆是校對後的黃金標註(合成資料,涵蓋五個類別),存成 train.jsonl 就能照 Part 2 上 Colab 訓練。這正是「AI 出草稿 → 人校對」的成品。
關鍵:OOD 通報不要放進訓練集
像「無塵室濕度超標」「冷卻水塔 pH 偏酸」這種不屬於五類的通報,不放進 train.jsonl——它們是 validation gate 該 ESCALATE 的「其他」案例。硬塞給小模型一個勉強的類別,等於教它把新問題也自信地答錯。
像「無塵室濕度超標」「冷卻水塔 pH 偏酸」這種不屬於五類的通報,不放進 train.jsonl——它們是 validation gate 該 ESCALATE 的「其他」案例。硬塞給小模型一個勉強的類別,等於教它把新問題也自信地答錯。
{"messages": [{"role": "system", "content": "你是押出線異常通報的結構化抽取器。只輸出 JSON,欄位:設備、異常現象、異常類別(溫控異常/斷線斷芯/鍍層退火異常/機構卡料/電氣訊號異常 五選一)、嚴重度(高/中/低)、建議班別(機械班/電氣班/製程班/品保班)。"}, {"role": "user", "content": "3號押出機第二段溫度飆到245度,設定值210,料表面有焦痕"}, {"role": "assistant", "content": "{\"設備\": \"3號押出機\", \"異常現象\": \"第二段溫度超標(實際245/設定210)、料面焦痕\", \"異常類別\": \"溫控異常\", \"嚴重度\": \"高\", \"建議班別\": \"製程班\"}"}]}
{"messages": [{"role": "system", "content": "你是押出線異常通報的結構化抽取器。只輸出 JSON,欄位:設備、異常現象、異常類別(溫控異常/斷線斷芯/鍍層退火異常/機構卡料/電氣訊號異常 五選一)、嚴重度(高/中/低)、建議班別(機械班/電氣班/製程班/品保班)。"}, {"role": "user", "content": "押出機D區加熱圈疑似故障,升溫升不上去卡在160就不動了"}, {"role": "assistant", "content": "{\"設備\": \"押出機D區加熱圈\", \"異常現象\": \"升溫停滯卡在160度、加熱圈疑故障\", \"異常類別\": \"溫控異常\", \"嚴重度\": \"中\", \"建議班別\": \"電氣班\"}"}]}
{"messages": [{"role": "system", "content": "你是押出線異常通報的結構化抽取器。只輸出 JSON,欄位:設備、異常現象、異常類別(溫控異常/斷線斷芯/鍍層退火異常/機構卡料/電氣訊號異常 五選一)、嚴重度(高/中/低)、建議班別(機械班/電氣班/製程班/品保班)。"}, {"role": "user", "content": "抽線機6模斷線,一小時內斷了三次,線徑0.2的細線"}, {"role": "assistant", "content": "{\"設備\": \"抽線機(6模)\", \"異常現象\": \"線徑0.2細線一小時斷三次\", \"異常類別\": \"斷線斷芯\", \"嚴重度\": \"高\", \"建議班別\": \"機械班\"}"}]}
{"messages": [{"role": "system", "content": "你是押出線異常通報的結構化抽取器。只輸出 JSON,欄位:設備、異常現象、異常類別(溫控異常/斷線斷芯/鍍層退火異常/機構卡料/電氣訊號異常 五選一)、嚴重度(高/中/低)、建議班別(機械班/電氣班/製程班/品保班)。"}, {"role": "user", "content": "大拉機銅線頻繁斷芯,收線盤一直空轉停機"}, {"role": "assistant", "content": "{\"設備\": \"大拉機\", \"異常現象\": \"銅線頻繁斷芯、收線盤空轉停機\", \"異常類別\": \"斷線斷芯\", \"嚴重度\": \"高\", \"建議班別\": \"機械班\"}"}]}
{"messages": [{"role": "system", "content": "你是押出線異常通報的結構化抽取器。只輸出 JSON,欄位:設備、異常現象、異常類別(溫控異常/斷線斷芯/鍍層退火異常/機構卡料/電氣訊號異常 五選一)、嚴重度(高/中/低)、建議班別(機械班/電氣班/製程班/品保班)。"}, {"role": "user", "content": "鍍錫槽溫度不足,錫層附著不良,外觀發霧"}, {"role": "assistant", "content": "{\"設備\": \"鍍錫槽\", \"異常現象\": \"槽溫不足、錫層附著不良、外觀發霧\", \"異常類別\": \"鍍層退火異常\", \"嚴重度\": \"中\", \"建議班別\": \"製程班\"}"}]}
{"messages": [{"role": "system", "content": "你是押出線異常通報的結構化抽取器。只輸出 JSON,欄位:設備、異常現象、異常類別(溫控異常/斷線斷芯/鍍層退火異常/機構卡料/電氣訊號異常 五選一)、嚴重度(高/中/低)、建議班別(機械班/電氣班/製程班/品保班)。"}, {"role": "user", "content": "退火爐氣氛不對,銅線退火後偏硬,伸長率不合格"}, {"role": "assistant", "content": "{\"設備\": \"退火爐\", \"異常現象\": \"爐內氣氛異常、退火後偏硬、伸長率不合格\", \"異常類別\": \"鍍層退火異常\", \"嚴重度\": \"中\", \"建議班別\": \"製程班\"}"}]}
{"messages": [{"role": "system", "content": "你是押出線異常通報的結構化抽取器。只輸出 JSON,欄位:設備、異常現象、異常類別(溫控異常/斷線斷芯/鍍層退火異常/機構卡料/電氣訊號異常 五選一)、嚴重度(高/中/低)、建議班別(機械班/電氣班/製程班/品保班)。"}, {"role": "user", "content": "自動收線機卡盤卡住,線盤換不下來,機構異音"}, {"role": "assistant", "content": "{\"設備\": \"自動收線機(卡盤)\", \"異常現象\": \"卡盤卡住、線盤無法更換、機構異音\", \"異常類別\": \"機構卡料\", \"嚴重度\": \"中\", \"建議班別\": \"機械班\"}"}]}
{"messages": [{"role": "system", "content": "你是押出線異常通報的結構化抽取器。只輸出 JSON,欄位:設備、異常現象、異常類別(溫控異常/斷線斷芯/鍍層退火異常/機構卡料/電氣訊號異常 五選一)、嚴重度(高/中/低)、建議班別(機械班/電氣班/製程班/品保班)。"}, {"role": "user", "content": "包裝機封膜卡料停機,膜捲好像沒對正"}, {"role": "assistant", "content": "{\"設備\": \"包裝機(封膜)\", \"異常現象\": \"封膜卡料停機、膜捲未對正\", \"異常類別\": \"機構卡料\", \"嚴重度\": \"低\", \"建議班別\": \"機械班\"}"}]}
{"messages": [{"role": "system", "content": "你是押出線異常通報的結構化抽取器。只輸出 JSON,欄位:設備、異常現象、異常類別(溫控異常/斷線斷芯/鍍層退火異常/機構卡料/電氣訊號異常 五選一)、嚴重度(高/中/低)、建議班別(機械班/電氣班/製程班/品保班)。"}, {"role": "user", "content": "線徑量測儀訊號漂移,同一條線讀值跳來跳去"}, {"role": "assistant", "content": "{\"設備\": \"線徑量測儀\", \"異常現象\": \"訊號漂移、同一條線讀值跳動\", \"異常類別\": \"電氣訊號異常\", \"嚴重度\": \"中\", \"建議班別\": \"電氣班\"}"}]}
{"messages": [{"role": "system", "content": "你是押出線異常通報的結構化抽取器。只輸出 JSON,欄位:設備、異常現象、異常類別(溫控異常/斷線斷芯/鍍層退火異常/機構卡料/電氣訊號異常 五選一)、嚴重度(高/中/低)、建議班別(機械班/電氣班/製程班/品保班)。"}, {"role": "user", "content": "變頻器報警F005過電流,馬達重啟後正常"}, {"role": "assistant", "content": "{\"設備\": \"變頻器\", \"異常現象\": \"F005過電流報警、馬達重啟後恢復\", \"異常類別\": \"電氣訊號異常\", \"嚴重度\": \"中\", \"建議班別\": \"電氣班\"}"}]}
發佈留言