工程服務 · B2BYOLO / ONNXAI 輔助標註邊緣 CPU 部署

影像辨識模型客製

用你現場的資料訓練專屬模型 · AI 輔助標註 · 部署到邊緣裝置 · 以 recall 驗收

公開模型在台灣現場常常不準,雲端 API 又不能離線、不能每秒跑。我們把整條線做完:從你的相機收資料、用 AI 幫忙標註、訓練、部署到 CPU 邊緣裝置、用真實資料驗收—— 自家已在車機 CPU 上做到兩階段 200 ms、紅燈判色 recall 92.9%,也有每天在跑的照片人數判讀。

8,340 張
自家裁圖 · 26 類標註
AI 輔助標註
LLM 第一輪、人複核
≈200 ms
車機 CPU 兩階段
recall 92.9%
致命錯誤 0.67%
01

這是什麼、給誰用

你有一個「看得到就能判斷」的工作,現在靠人眼或靠不準的現成工具:儀表要抄、產線要挑、門口要數人、車道要看號誌、工地要看有沒有戴安全帽。我們替你做一個只認你現場的模型,並讓它在你既有的設備上跑起來。

  • 工廠與設備商:儀表讀值、產線瑕疵、料件辨識、機台狀態燈。
  • 零售與活動:來客與活動人次、貨架狀態、照片自動統計進報表。
  • 車隊與車用:號誌、車種、車道標線,與我們的行車資料工程接在一起。
  • 已經有相機、有影像資料,但沒人會把它變成模型的公司
離線、每秒跑、不上雲
模型部署在你的裝置上(CPU 就能跑),影像不用送出去。需要雲端大模型的判讀(例如照片人數)也可以,但那是選項不是前提。
02

五個步驟:資料到部署

01
從現場設備收資料

接你既有的相機、車機、行車紀錄器、手機照片;先確認光線、鏡頭、色溫跟正式環境一樣——我們踩過兩台裝置色溫不同、模型直接看不見的坑。

02
AI 輔助標註

用大型語言模型當第一輪標註員(判色、分類、框),人只複核;現成的公開模型不適合台灣場景時(例:某開源紅燈模型對台灣紅燈 recall 僅 28%),這一步省最多。

03
訓練與資料清理

自家 GPU 訓練;補負例(沒有目標的畫面)避免誤報;切邊的框保留而不是丟棄;用幾何條件(例如地平線以下不可能有號誌)清掉誤標。

04
邊緣裝置部署

匯出 ONNX,在 CPU 上跑:執行緒數、輸入解析度、佔空比都實測;必要時拆成「偵測位置 + 小分類器」兩階段,速度與準度一起拿。

05
以 recall 與致命錯誤驗收

不交 mAP。交的是「該抓到的抓到幾成、絕不能錯的錯了幾次、每張幾毫秒」,並附可重跑的評估腳本。

03

我們自己做過的

數字全是自家資料(一台車、一組相機、一家商店),不是通用承諾;但每一個都有 log 與評估腳本可重跑。

92.9%
紅燈判色 recall,致命錯誤 0.67%

自訓 64×64 顏色分類器(紅/綠/黃/綠箭/關),真紅燈判成綠燈只有 0.67%;綠 91.1%、黃 88.8%。在車機 CPU 上 1 顆燈 7.2 ms、4 顆 21.9 ms。

≈200 ms
兩階段架構在車機 CPU 上 4.8 FPS

偵測器 1344×352 int8 找燈的位置(189 ms)+分類器判色(7–22 ms)。把「找到燈」和「判顏色」拆開後,準度與速度都上來;GPU(tinygrad on Adreno)實測反而比 CPU 慢 4 倍,結案不追。

8,340 張
號誌燈裁圖、26 類標註標準、AI 代理標註

從自家行車紀錄自動裁出 8,340 張號誌燈,訂 26 類標註標準,用 LLM 代理判色做第一輪;訓練集 5,329 張含 1,809 張無燈負例、驗證 579 張。

0.184 → 0.555
偵測器紅燈 recall 三倍,然後發現問題定義錯了

單階段偵測器從 0.184 提到 0.555 之後,我們量出「判色從來不是問題,找到燈才是」——於是改兩階段。這種回頭改問題定義的判斷,比多跑幾個 epoch 值錢。

每天在用
活動照片人數 AI 判讀,進市府商店的每日回報

拍貼機照片自動判讀「這張幾個真人」(排除卡通與貼圖),與代幣數並列對照,人數不符自動標紅;店員可在後台校正、原判讀值保留可追溯。2026-08 上線至今每天產報告。

375 ms
推論延遲從 499 ms 降到 375 ms,四執行緒反而更慢

同一顆 ONNX 模型在車機上實測執行緒 2/3/4 = 499/375/412 ms——因為跟主程式搶核。這種數字不量不會知道。

螢幕 OCR 五源採集(企業桌面 AI)

3Q夥計的員工端以 GPU OCR 服務讀畫面文字,與視窗、鍵盤、剪貼簿、滑鼠合成時間軸,再萃取 SOP。

儀表讀值 PoC(2025):現成 OCR 都不準,結論要自訓

七段顯示器與指針電表:Tesseract、EasyOCR、公開 Roboflow 模型逐一實測不準,結論是要用自己現場的資料訓練——這個 PoC 沒完成,但我們知道哪些路不通。

技術文章:紅綠燈判色為什麼拆成兩階段:車機 CPU 上 200 ms、recall 從 0.55 到 0.93

04

方法:看 recall,不看 mAP

  1. 先定義「絕不能錯的那一種錯」。 紅燈判成綠燈是致命錯誤、綠燈判成紅燈只是保守——兩者要分開算,mAP 把它們混在一起。
  2. 負例要夠。 沒有目標的畫面佔訓練集三分之一,模型才不會看到什麼都想框。
  3. 資料清理用規則,不用感覺。 黃燈標註有 26% 落在地平線以下——那是方向燈,用幾何條件整批清掉。
  4. 該拆就拆。 偵測器負責「在哪」、小分類器負責「是什麼」,分類器只要幾毫秒、準度反而更高。
  5. 部署數字要量。 執行緒、解析度、佔空比、GPU 是否真的比較快——每一項都在目標裝置上實測,不信規格書。
  6. 回頭改問題定義。 指標上不去時先問「我是不是在解錯的問題」,而不是多跑幾個 epoch。
05

適用場景

儀表與機台

類比指針、七段顯示器、狀態燈的自動讀值與異常判斷;接進監控系統或 Modbus 資料一起看。

活動與零售

照片或監視畫面的人次、貨架缺貨、排隊長度,自動進每日報表(我們在市府商店已這樣做)。

車隊與車用

號誌、車種、車道標線、外部雷達目標與視覺目標配對;與行車 log 對齊後做驗收。

安全與合規

安全帽、區域入侵、危險姿態——只做警示與統計,認證設備仍用合規產品。

06

邊界與誠實揭露

  • 準確率沒有通用數字。上面的 92.9% 是一組相機、一個場景;你的場景要用你的資料做 PoC 才能報。
  • 資料量與品質決定一切:太少、光線不一致、鏡頭跟正式環境不同,模型就不會準——我們會在第一步就告訴你夠不夠。
  • 我們自己也有沒做成的:儀表讀值 PoC 停在「現成工具都不準、要自訓」那一步,沒有繼續。這寫在上面。
  • 安全相關場景(人員、車輛)只做輔助與統計,不承諾取代合規設備或人工判斷。
  • 交付含資料集、標註、訓練與評估腳本、ONNX 模型與部署程式,你不會被綁在我們身上。
07

怎麼開始

  1. 盤點(免費):你要辨識什麼、現場有哪些相機與資料、跑在哪台裝置上、什麼錯不能犯。
  2. PoC(2–4 週):用你的資料訓練第一版,交 recall/致命錯誤率/每張毫秒數,以及「資料還缺什麼」。
  3. 交付與迭代:部署到你的裝置,接進既有系統(報表、警示、後台校正),資料越用越多、模型定期重訓。
打電話諮詢 LINE 諮詢