標記狀況複查 — 陞訊生成資料 + 跌倒補料

2026-08-07 01:40 · session：模型訓練 · 資料源 CVAT2 即時查詢（非快取）

一、總覽

二、安全帽 / 反光背心的資料正確性

你問過純生成的資料要怎麼確保裡面的人裝備狀態是對的。做法是三層，每層都留下可複核的證據：

第 1 層 — 標籤來自 prompt，不是來自判讀

每張圖是「先決定要 hat=yes/vest=no，再叫模型照這個生」， 標籤在圖片存在之前就確定了，不存在「看圖猜裝備」的誤判空間。 四種組合的張數在送生成時就分配好（見下方分布）。

第 2 層 — 目視逐張確認

把 CVAT 裡的實際標註畫回圖上，依宣稱的標籤分組排列。 同一列的標籤相同，混進不符的一眼就看得出來。抽 24 張（每組合 6 張）：

上到下：hat=no/vest=no、hat=no/vest=yes、hat=yes/vest=no、hat=yes/vest=yes。 綠線是 SAM3 自動框的人形輪廓。24 張全部相符，輪廓也貼合。

第 3 層 — 拿真實影像測

純生成資料訓出來的模型，用 CH10 現場錄影的 299 個真實 person crop 測試， 抽驗 24 個全對，包含「頭上包白布 / 毛巾」這類難例都沒被騙。 這是最硬的一層——訓練資料和測試資料完全沒有共同來源。

多樣性有沒有真的買到

v2 花的 $27 買的就是多樣性，所以要驗。把 120 個 hard_hat=yes 的頭部區域取出做色相統計：

黃 45.0% + 橙黃 18.3% = 63.3%，對上 prompt 設的 60%；紅 6.7% 對 5%。 白 11.7% 與藍 9.2% 略低於設定值。「綠色」是頭部裁切帶到螢光背心造成的誤判，不是真有綠色安全帽。 結論：加權有生效，實際產出 6 種帽色。

隨機抽 48 個頭部區域。人臉、年齡、帽色都有變化——v1「反覆同一個人」的問題已解決。

三、跌倒補料：找到一個真實的誤報機制

這批 1,010 張真實影像原本只是要補三支鏡頭的測試樣本，過程中撈到比補資料更有價值的東西。

全部 17 個被 flag 的樣本（數字為模型輸出的跌倒機率）。可以看到都是坐著或走動的人，從正上方拍。

四、屬性標註分布

未列出的屬性一律為 unknown，依規則 12 不參與 loss 與評估。

五、CH01 真實資料目視抽查

藍框 = person，橘框 = 車輛類。標題列出該張圖的 subset 與各類別框數。

六、健檢結果

七、待你決定

• 刪除生成 v1 的 90 個 task（224 張，多樣性不足已被 v2 取代）——留著會誤導日後盤點
• 愛烙達頻道15 怎麼辦——一週零人次，三個選項見第三節
• 俯視角誤報要不要修——已知機制與對症資料（新東陽 ch21 的 267 張）都在手上， 但那批目前全在 Test；要修得另外找其他俯視角鏡頭的資料進 Train，避免同鏡頭跨 split

八、🔴 全域 person 模型 v20260806_640 被污染，不可上版

先分離變因，確認不是影像的問題

失效範圍恰好是 CH01 這一個場景，其餘全部正常。這種「單一場景歸零」指向訓練資料。

根因：1,944 張圖被當成「確定沒有人」餵進訓練

person_v20260806 共 41,296 張圖、802 個 task。其中 95 個 task 在磁碟上是整個零標註， 回 CVAT 逐一核對後發現 25 個 task 在 CVAT 明明有標註—— 它們的 label 檔是空的，而空 label 在 YOLO 是合法的「背景圖」， 等於明確告訴模型這些畫面裡沒有人。

常見的幾種成因都排除了：不是 video-mode（22/25 是 image-mode）、 不是沒到 acceptance（全部 completed）、不是 label 名稱對不上（都是 person）、 rectangle 與 polygon 都有。成因見下一段。

被漏掉的 task（標註早於 export，屬於真 bug）

為什麼指標看不出來

這個錯誤不會以任何形式報錯。圖片數、目錄結構、資料量全都正常， 訓練與驗證指標也正常（val mAP50 0.772）——因為 val 集有相同的缺漏， 偏差一致就互相抵銷了。只有拿一批乾淨的外部測試資料去打，才會看到 0.000。

根因：export 只吃 polygon，rectangle 全部靜默丟棄

把被漏的 task 與正常進入的 task 逐項比對，前面幾個假設都被推翻：

擴大稽核：46 個 YOLO 資料集，13 個受影響

既然成因是共用的 export 邏輯，就把所有資料集都掃一遍。 判準相同：磁碟上整個 task 零標註，但該 task 在 CVAT 有標註。

要做的事

1. 修 person 的 export：改成同時吃 rectangle 與 polygon， 照 forklift v519 的作法。rectangle 直接就是 bbox，polygon 取外接矩形
2. 加 fail-loud：某個 task 在 CVAT 有標註卻產出 0 個 label 時要中止並報錯， 不能靜默寫出空檔案
3. 加時序檢查：export 完成時間必須晚於所有 task 的最後標註時間，否則警告
4. 修完重跑 export → 重訓，約 15–18 小時

災情範圍：只限 person 這一支

既然成因是 export 的 shape 型別過濾，就把所有 export 腳本掃一遍，確認還有沒有別的中招：

結論：這個 bug 只存在於 person 的 export 血脈，其他模型的 export 都正確處理兩種型別。

已修好並驗證（2026-08-07 04:50）

改的是 export_p1_v20260806.py 第 123 行這一句：

# 舊 —— rectangle 全部被丟掉
shapes = [sh for sh in ann.get("shapes", []) if sh["type"] == "polygon"]

# 新
WANTED = ("polygon", "rectangle")
shapes = [sh for sh in ann.get("shapes", []) if sh["type"] in WANTED]
for tr in ann.get("tracks", []):                 # video-mode 的標註常放在 track
    for sh in tr.get("shapes", []):
        if sh.get("type") in WANTED and not sh.get("outside"):
            shapes.append({**sh, "frame": sh.get("frame", tr.get("frame", 0))})

poly_to_bbox() 本來就是取 points 的 min/max， rectangle 的 [x1,y1,x2,y2] 直接就能算出正確的框，不必另外處理。

另外補了兩道防線：

• 抓 annotation 失敗改成 retry 3 次後拋錯中止，不再 except: continue 靜默跳過
• 產出後逐 task 核對，只要有 task「在 CVAT 有標註卻寫出 0 個 label」就報錯中止。 沒有這道檢查，這類錯誤不會以任何形式浮現

驗證結果

修正版腳本：5090-2 ~/factory_ppe/scripts/export_p1_v20260807.py， 資料集：~/datasets/person_v20260807。 重訓尚未啟動——那是 15–18 小時的資源承諾，依規矩訓練決策要 operator 確認。 hyperparams 沿用 v806 不動，只換乾淨資料。

九、CH01 人員模型選型（已定案）

同一個 CH01 test 集（70 張 / 149 個人）對照。專用版訓練與推論都是 1280， 符合場域遠景小目標的要求。

黃 = 人工標註，藍 = CH01 專用版（conf 0.25），紅 = 全域版（conf 0.01，畫面上一個都沒有）。 專用版與人工標註幾乎完全重合。

專用版 vs 現役 production：兩邊都測，確認該怎麼綁

只知道「專用版在 CH01 比較好」還不夠，得知道它能不能當通用模型用。 所以兩個模型各在兩個 test 集上都跑一次：

兩個模型都以 imgsz 1280 推論。split 沿用 CVAT 的 task.subset， 版本間分配穩定，因此現役模型的訓練資料不會出現在全域 test 裡，比較是公平的。

十、陞訊 demo 模型部署清單

下週二 demo 要用的模型。目前 ppe-demo 上一個陞訊模型都還沒註冊， ckpt 已備到 gx10-4t 的 /home/rai/model_viewer/models/（只放檔案，未改 app.py、未重啟服務）。

部署指令（gx10-4t，ckpt 已就位）

# 1. ckpt 已在 /home/rai/model_viewer/models/（本次已完成，不需重做）
# 2. 改 source repo 的 app.py 加 register block —— 規則 15：一定要進 repo 並 push，
#    只 docker cp 進 container 的話下次 redeploy 會被洗掉
cd scripts/model_viewer && git pull --rebase
python3 ../patch_app_add_shenghsun.py --dry   # 先看會加什麼
python3 ../patch_app_add_shenghsun.py         # 套用
git add app.py && git commit -m "feat: 加陞訊 CH01/CH06-10 模型" && git push origin main

# 3. 部署到 4t
scp app.py rai@192.168.53.17:/home/rai/model_viewer/app.py
ssh rai@192.168.53.17 'docker cp /home/rai/model_viewer/app.py model_viewer:/app/app.py \
  && docker restart model_viewer'

# 4. 驗證（規則 14：一定要 curl 確認，Success 不代表生效）
sleep 10 && curl -s https://ppe-demo-4t.intemotech.com/models | grep sx_ch01_person

# 5. gx10 修好後補做同樣步驟，兩台要一致

十一、電子圍籬 CH02–05：模型從未被真實資料驗證過

整個資料集沒有一張真實影像

sx_fence_v20260806 的 215 張全部是生成圖。 所以這個模型測出來的 P 0.934 / R 0.891 / F1 0.912，是生成資料自己跟自己比的結果。 依先前在陞訊同一天做過的對照，生成圖人物輪廓乾淨、對比清晰、姿態標準， 連沒看過它們的現役模型都能拿滿分——這種分數對真實場域完全沒有預測力。

真實素材一直都在，只是沒進標註流程

也就是說，CH02–05 這四支鏡頭從頭到尾沒有任何一張真實影像被標註過。

已處置：預標並上 CVAT，等標記師複核

SAM3 對這 252 張做 person 預標，逐鏡頭分層切 train/val/test （讓每個 split 都有正樣本，避免正樣本全落在 Train 的老問題）：

十二、車輛模型：子母車與棧板誤判的實地確認

「子母車垃圾箱和載貨棧板被誤判成車輛」是這個案子最初就指定要處理的問題。 mAP 0.981 不能代表它解決了——誤判源如果在 test 集裡出現得少，整體指標根本看不出來。 所以直接對 60 張含垃圾箱的 CH01 畫面推論，用眼睛確認。

藍框 = car，橘框 = truck，綠框 = motorcycle（conf 0.25）。

十三、證偽測試：直接推論驗證，不只靠推理

前面的結論建立在「空 label 會讓模型學到該場景沒有人」這個推理上。 推理可能錯，所以做一個能推翻它的測試—— 拿 v806 去推論那 22 個 rectangle task 的圖， 如果它表現正常，整個結論就不成立。

1,446 張圖、1,471 個真值框，IoU 0.5 判定。真值取自修正後的 person_v20260807。

逐 task 拆開，看得更清楚

順帶驗證：我自己的評估有沒有踩同一個坑

如果我拿來評估的 test 集本身缺框，那前面報的 mAP 與 recall 全都不可信。 所以逐 task 比對「磁碟 label 行數」vs「CVAT 扣除刪除幀後的框數」：