🔍 大模型（VLM）輔助判斷結果
方法、能力範圍與 iSeek 降誤報落地

技術交接文件 · 2026-06-15 · 來源：VLM-as-verifier 兩輪研究 + ppe-demo 階段 1/2 實作

1. 核心方法：VLM-as-verifier（偵測後二次確認）

主模型（CNN / YOLO cascade）先偵測 → 對需要複核的偵測結果，把該 person 區域餵給 VLM 問一個是非題 → VLM 的判斷與主模型對照，作為「二次確認 / FP 過濾」。不是取代主模型，是接在後面當守門員。

已驗證的最佳配方

環節	結論	備註
VLM 模型	Qwen2.5-VL-7B	gx10/4t 已部署可跑。研究首選原為 InternVL3-8B，但大樣本證明兩者差異 ~2pp、CI 重疊不顯著，且 InternVL3 在 prod transformers 5.9 跑不動 → 實務用 Qwen
視覺標記	crop 放大 / context-margin crop	完勝「整張+黃框」。per-person 小目標要給 VLM 更多頭部像素；整張+框只適合 scene-level（雜物偵測）
Prompt	英文 yes/no 短問句	例：`Is the person inside the box wearing a hard hat? Answer yes/no/uncertain + one reason`。CoT / JSON / 中文都沒更好還更慢
速度	gx10 Qwen ~15s/張（warm）/ ~105s（cold 首次載入）	研究報的 0.7s 是 InternVL3 在別張卡；DGX Spark GB10 的 VLM 推論本來就慢

2. 能做到的範圍（實證數據，全 95% CI）

✅ hard_hat 模糊偵測：VLM 大勝主模型 — 在主模型信心 0.3~0.7 的模糊區（n=302）：VLM 77.5% [72–82] vs model 57.3%，CI 不重疊，穩定可信。

用途	數字	意義
當 FP 過濾器：抓回主模型假陽性	64.7%	主模型誤判「違規」的，VLM 抓出約 2/3
救回主模型假陰性	~70%	主模型漏判的也能補一部分
與人工判讀一致率	90.6%	去掉 cvat 標註噪音後

哪些屬性值得用 VLM、哪些不值得

屬性	VLM vs 專用 CNN	結論
hard_hat 安全帽（模糊區）	77.5 vs 57.3	值得VLM 強，語意判讀補 CNN 不足
反光衣 safety_vest	95.4 vs 96.9	不需CNN 已強、打平
護目鏡 safety_glasses	69.2 vs 89.2	別用小目標 VLM 弱
口罩 face_mask	75.4 vs 96.2	別用CNN 大勝

→ VLM verifier 不是萬用。價值集中在「語意可混淆 + 目標夠大」的屬性。CNN 已做得好的（小目標、清晰特徵）VLM 補不了，加上去純浪費算力。iSeek 降誤報第一個、也可能是唯一一個值得接 VLM 的 = hard_hat。

3. ⚠️ 限制與紅線（規劃時務必納入）

⭐ 端到端真相（最重要，第一輪沒測、第二輪才量化）
場域 slice（n=742，主模型判正 287 個）：主模型的假陽性幾乎都是高信心（只 6/287 落在模糊區）。所以：

「只驗模糊區」幾乎無效：FP 14→13、recall 不變 — 因為 FP 不在模糊區
「驗全部正樣本」：FP 14→4（−71%）、precision 95.1→98.4%，但 recall 92.9→84.0%（−9pp，誤殺真實正樣本）

→ VLM verifier 端到端是 precision↔recall 取捨。要降 FP 就得驗高信心預測 → 必然犧牲 recall。是否上線，取決於 iSeek 場域「誤報騷擾成本」vs「漏報真違規成本」的權衡。

🔴 紅線（架構硬約束）

VLM 不能進 live 每幀推論：15s/張會卡死即時串流。只能異步、只對「候選事件」跑
不能無條件自動否決告警：recall −9pp，安全違規漏報成本高。否決模式必須保守（VLM 明確說「有戴」才壓告警，uncertain 仍報）
只對 hard_hat 開：其他屬性 CNN 已強
「0% 誤殺」是假象：第一輪小樣本說 0%，大樣本實為 ~4.2% [2–9]。VLM 自己也會錯

4. iSeek 降誤報落地架構

FP 發生在哪：iSeek 告警 state machine

誤報就發生在 app.py 的 iSeek alert state machine（約 line 2466–2509）：對 hard_hat < thr 持續 sustained 秒 → fire alert + send_webhook("iseek_alert") 通報 ISMS。主模型在 sustained 期間一直把「有戴」誤判成 <thr，就誤報。

主模型 live 偵測 hard_hat < thr（持續 sustained 秒） │ ▼ ← VLM 插在這裡（fire 前的閘，異步、只在「即將通報」那刻跑一次） [背景 VLM queue] context-margin crop → Qwen2.5-VL 「有沒有戴安全帽?」 │ ▼ verdict=有戴 → 壓掉告警（降 FP） | verdict=沒戴/uncertain → 照常通報（保 recall）

關鍵：只在 sustained 達標、即將通報的那一刻觸發一次 VLM（不是每幀），成本可控；~15s 延遲對「持續數秒才報」的告警完全可接受。

三階段落地（風險遞增）

階段 1 已實作上線單張 VLM 輔助按鈕

live / 影片 /result viewer 每個 person 旁「🔍 問 VLM（安全帽）」鈕 → 後端 context-margin crop → Qwen → 回 verdict + 理由。純人工輔助、不自動改判定。

⚠️ 已知 bug 修復中：/result viewer 的鈕 onclick handler vlmVerifyHardHat 漏定義在前端 template（後端 API 100% 正常，已 browser 實測 verdict=no/19s/200）。

階段 2 已實作上線告警確認閘 —— 影子模式

iSeek rule 加 vlm_verify flag（UI checkbox，只 hard_hat）。alert fire 前把違規 person crop 丟背景 bounded queue(500) + worker thread（不阻塞 inference_loop）→ VLM 判讀 → 寫 data/vlm_shadow.jsonl。

🔴 影子模式 = 零告警行為改變：alert 照常 fire、webhook 照常送，VLM verdict 只寫 log。這正是研究說的「端到端需線上 A/B」——讓它在真實場域跑幾週，累積「VLM vs 主模型 agree-rate」數據。已 gx10 完整 e2e 實證（alert→enqueue→Qwen verify→寫 jsonl，record 正確）。

看數據 API：GET /api/vlm-shadow（n / by_verdict / queue_pending / 估算「開否決會降多少 FP、誤殺多少」）。

階段 3 待規劃（接手 session 的主戰場）否決模式 + 標註回流

前提：階段 2 影子數據證實「VLM 否決能降 FP 且 recall 代價在場域可接受」才開
否決邏輯（保守）：VLM 明確 verdict=有戴 → 壓掉告警；uncertain / 沒戴 → 照常通報（偏 recall）
標註回流：VLM 跟主模型高度不一致的樣本 → 回送 cvat 標註 audit，順便補標降低主模型 FP 根因（治本）
場域驗證：對代表場域影片做端到端 FP/漏報 before-after 量化（規則 17 精神）

5. ppe-demo 現有基礎設施（接手可直接用）

資產	位置 / 介面	狀態
單張驗證 API	`POST /api/verify_attr` {source: live\|job\|cvat, file_id, frame_number, bbox, attr:"hard_hat"} → {verdict, reason, latency_s}	✅ 兩台上線
影子統計 API	`GET /api/vlm-shadow`	✅ 兩台上線
iSeek rule VLM flag	rule dict 加 `vlm_verify` + UI checkbox（只 hard_hat）	✅
背景 verify queue + worker	bounded(500)，alert fire 非阻塞 enqueue	✅
影子 log	`data/vlm_shadow.jsonl`（ts, attr, model_prob, vlm_verdict, reason, agree）	✅
VLM backend	`ClutterVLMHandler._vlm_load` + Qwen2.5-VL 單槽 cache（按需載入，與雜物偵測共用）	✅
前端 verify 鈕	RESULT_HTML / live sidebar 「問 VLM」鈕	⚠️ JS handler 修復中

Source repo：5090 ~/rai-model-viewer（commit e85d7a5 階段1 / c469a34 階段2）。部署：scp app.py → gx10 docker cp + restart → gx10-4t 同步。VLM 推論在 gx10/4t production 機按需載入。

6. 給接手 session 的建議起手式

先在 iSeek 對 hard_hat 規則開影子模式（vlm_verify checkbox），讓真實場域告警跑 1~2 週，累積 vlm_shadow.jsonl
讀 /api/vlm-shadow：看 agree-rate、看「VLM 否決會降多少 FP / 誤殺多少」的場域實數（不是研究的 dataset 數字）
跟 operator 確認誤報 vs 漏報成本權衡，再決定是否開階段 3 否決模式、用什麼 verdict 門檻
VLM 不一致樣本回送 cvat audit 補標 —— 這是治本（降低主模型 FP 根因），跟 VLM 守門可並行
範圍守住 hard_hat，不要擴散到 CNN 已強的屬性

完整研究報告（圖文 + 變因矩陣 + 案例圖）：
· 可行性研究：vlm_verifier_research_v20260614_report
· 完整規模測試（大樣本，以此為準）：vlm_verifier_research_v20260614_full_report

⚠️ 引用數字一律以「完整規模測試（round 2 大樣本）」為準；第一輪小樣本的樂觀結論（可混淆頭飾是價值帶 / 0% 誤殺 / InternVL3>Qwen）已被大樣本推翻。

🔍 大模型（VLM）輔助判斷結果方法、能力範圍與 iSeek 降誤報落地