iseek 模型版本驗證機制 — 補充建議

2026-06-05 · 模型訓練端(5090-2 / ppe-demo)對 原概念設計的補充。
原設計=灰框、為原文件內容摘要;⊕ 補充=綠框、為訓練端用實際模型壓力測試後的補充建議。

原設計機制摘要

系統定位:iSeek 是完整通報系統——使用者後台設定 RTSP、模型、框位置(ROI)、信心值(conf)、通報區間,有狀況即發報。(ppe-demo 僅為測試用、復刻部分功能,非主系統。

事件起因:換用同類型模型未充分測試即上線,導致通報功能失效。

驗證做法:在測試區完整拉起 iSeek,分兩種驗證,兩者皆產出模型差異報告供人員判讀

 ① 測試影片驗證:獨立蒐集 RTSP 錄影檔 + 設定檔(指定模型/conf/事件秒數),按 raw 即時重放進系統檢查發報。
 ② 24h 隨機抽樣驗證:真實環境跑 24 小時隨機抽樣。

版本分級:小版本抽樣快測|中版本完整+1-2天即時|大版本週期驗證+重定義標準。

決策:新舊差異 ≤5%、新模型 vs 標準答案 ≤5% → 通過;累計容忍 10%。漏報另有獨立系統蒐集;推論端 conf/imgsz 由專責工程師調整、設錯會在驗證表現上暴露。

⊕ 補充核心:驗證觀測「症狀」(兩類),成因自動被涵蓋

用已知模型(person / forklift / PPE 22-attr / fire_smoke / safety_rope / door_state)壓力測試後要釐清一個分層:端到端驗證能直接觀測的只有兩類症狀——漏報與誤報;而配置錯(imgsz/conf)、分布外、模型退步等都是「成因」,最終都會顯現為這兩個症狀之一,被同一套測試抓到。所以不需要針對每個成因設獨立白盒檢查(例如 imgsz/conf 設定檔 diff)——本測試已涵蓋;只要兩類症狀的測試場景夠廣,成因自然暴露。

症狀(驗證直接觀測)失效樣態常見成因(會收斂到此症狀)成立前提
① 漏報 FN該報沒報 = 通報失效(本事件起因)模型退步、conf 太高、imgsz 太小漏遠景、分布外(駕駛坐姿)正樣本影像須標注「該報時刻」+ 自動比對有無報
② 誤報 FP不該報狂報 = 客戶最反感髒汙/反光/雲霧誤觸、conf 太低須含純負樣本影像 + 誤報場景納入只增不減回歸集

例:imgsz 該1280誤設640,不會獨立顯現,而是表現為「遠景小目標漏報」→ 被 ① 抓到(v530 翻車路徑)。所以配置錯由驗證機制本身涵蓋,唯一前提是驗證影像要有遠景場景。

⊕ 補充兩條驗證腿的分工 + 一個共同盲區

「測試影片」與「24h 抽樣」不是重複、是互補,各補對方的盲:

① 測試影片② 24h 隨機抽樣
真值來源絕對(設定檔指定該報秒數)無預設、靠人員判讀新舊差異
場景分布人工挑選(要刻意涵蓋罕見/邊界)真實(自然反映現場比例)
強項罕見關鍵事件(火/跌倒)、漏報、邊界場景真實誤報、長時間行為漂移
弱項覆蓋率靠人工保證24h 可能抽不到罕見事件

✅ 共同盲區只發生在「24h 隨機抽樣」,且已被「測試影片」那條腿補住

測試影片有 yaml 標準答案(指定該報秒數)= 絕對真值,判的是「絕對對錯」,不受共同盲區影響——兩版同樣漏報,對照 yaml 一樣抓得到。

24h 隨機抽樣沒有預設答案、只能靠新舊 diff。若某場景新舊同樣漏報/誤報(例如兩版都沒學過駕駛坐姿、都對飯店反光誤報),diff=0、人員判「無差異」→ 通過,但其實兩版都錯、一直都錯。純相對比較抓不到這種共同盲區。

好消息:這個盲區正好被「測試影片(有 yaml 絕對真值)」那條腿補住——前提是該場景有被收進測試影片。兩條腿因此是必要的互補:測試影片給絕對基準擋共同盲區、24h 抽樣給真實分布與漂移。所以唯一要確保的,仍是回到測試影片的場景覆蓋夠廣(敏感場景清單)。

⊕ 補充複合(cascade)模型:黑箱知道「錯了」但不知道「哪級錯」

堆高機通報 = forklift 偵測 → person 偵測 → PPE 屬性判斷 三級串接。端到端黑箱只有「最終發報對不對」一個訊號,但三級任一斷掉,症狀可能都是漏報——黑箱分不出根因

斷點內部現象最終症狀
forklift 沒偵測到整條不觸發漏報
person 沒偵測到沒有人可判 PPE漏報
PPE 判錯(戴帽判沒戴)屬性錯漏報 / 誤報

三種不同根因、同一個症狀 → 確實需要人員調查,但不該純人工翻查。三層解法:

  1. 中間結果落地:cascade 每級輸出(forklift bbox / person bbox / PPE prob)都記 log,發報異常時可回溯是哪級斷掉。(ppe-demo 已做過「forklift_ppe cascade 中間結果可勾選顯示」,這個機制可直接移植到驗證系統。)
  2. 分級回歸測試:除端到端,每級各自保留測試集(forklift mAP / person mAP / PPE attr),不需中間真值就能抓「哪級退步」——比新舊各級 metric 即可。換某一級(如 person 升版)造成端到端變化時,分級測試直接定位是哪級。
  3. 半自動歸因:發報錯誤 → 系統自動帶出該時刻的三級中間結果給人員,定位斷點(不用從頭翻影片)。

分工:端到端驗「整體對不對」(客戶感受),分級 + 中間 log驗「哪級錯」(工程定位)。兩者都要,cascade 才能除錯。

⊕ 補充關鍵前提:兩個「會被發現」其實是有條件的

前提 A — 漏報「另有系統蒐集」要能回灌成正樣本真值

漏報由別的系統蒐集很好,但要閉環的前提是:這些漏報案例要回灌成帶「該報時刻」標注的正樣本回歸集,上版前自動跑、檢查有沒有再漏。否則漏報只是被記錄、沒有變成防止重演的測試。

前提 B — 一切成因的「可發現性」都歸結到場景覆蓋率

配置錯、分布外、退步等成因不會全場景顯現,只在特定場景觸發漏報/誤報(imgsz 該1280用640只在遠景小目標漏、conf 太低只在信心邊緣誤觸)。驗證能不能抓到,取決於驗證影像有沒有那個場景
→ 這不是針對配置錯的特別檢查(那已被測試涵蓋),而是讓兩條症狀防線真的能抓到所有成因的共同前提:每個模型維護「敏感場景清單」,驗證集強制涵蓋。覆蓋率是這套機制唯一需要刻意保證的事。

⊕ 補充機制細節防呆(6 項)

  1. 時間容差窗:iSeek 是 sustained(持續N秒才報)+ cooldown,發報必晚於事件秒數。設定檔要定義「事件秒數 + sustained 區間內發報算正確」,否則時間對不上會誤判失敗。
  2. real-time 即時重放:RTSP 錄影檔要按原始 fps/時間軸即時重放(保留掉幀/stale frame 特性),不是快速灌檔——否則失去真實串流行為(stale frame、timeout 都只有即時串流才會出現)。
  3. 人員判讀 rubric:第五階段人工判讀要有明確標準(什麼算正確發報),不同人才一致;量大時抽樣 + 重點看新舊不一致(diff)的。
  4. 持續事件預期發報次數:事件持續 N 秒,sustained+cooldown 下該報幾次要事先定義,否則「報太多/只報一次」都可能被誤判。
  5. event-level 三指標分開設閾值:「5% / 10%」在端到端機制下要拆成漏報率 / 誤報率 / 時間偏移三個獨立指標各設閾值,別混成一個 5%(三者風險權重不同,漏報與誤報該比時間偏移嚴)。
  6. per-camera / cascade 拆分:全域指標會掩蓋單場域翻車(safety_rope 45% FP 來自單一 task);cascade(forklift_ppe = forklift+person+PPE)要每級各驗 + 端到端驗,每級各過不代表串起來過。

⊕ 補充各模型「敏感場景清單」範例(驗證集應涵蓋)

模型會暴露問題的敏感場景(驗證集必含)
person / forklift 偵測遠景小目標、倉儲深處、背對/側面、低光
fire_smoke鏡頭髒汙、玻璃反光、雲霧、蒸氣、夕陽逆光(純負樣本誤報陷阱)
PPE 22-attr堆高機駕駛坐姿、遠景小人、特殊角度、「沒穿/沒戴」負樣本
safety_rope動態作業中段(要時序前後 frame)、有裝備但未掛勾、門口路人
door_statefall(低頻高風險,需單獨高標準)、半開、逆光

原則:誤報/漏報每發現一個新場景,就永久加進回歸集(只增不減),讓同類問題不再重演。

⊕ 補充一句話收斂

原設計的核心邏輯是對的(端到端黑箱 + 真實 RTSP 即時重放 + 新舊比對 + 人工判讀)。補強都集中在一件事:「覆蓋率怎麼保證」——三條防線(漏報/誤報/配置錯)能不能被驗證抓到,全取決於驗證影像有沒有涵蓋會暴露問題的場景。把「敏感場景清單 + 只增不減的回歸集」做起來,這套機制才真能擋住「換模型導致通報失效」重演。

補充提出:模型訓練端 · 待團隊確認後納入正式設計。