iseek 模型版本驗證機制 - 概念設計

文件目的

針對 iseek 智慧模型辨識系統，提出模型版本部署的驗證機制，避免類似本次事件（換同種類模型導致客戶通報全無或亂報）再次發生。

本文件記錄概念設計，實作細節另行討論。

一、事件背景

1.1 事件描述

因為要換同種類模型（但模型表現方式不一樣），所以服務邏輯也需要配合調整。但尚未經過精細驗證就上版，導致實際客戶受影響。

1.2 問題識別

得知系統沒有針對這種事件的測試標準系統，因此誤判進版可行而上線。這次的根本問題不是單純技術失誤，而是缺乏一套可依循的版本驗證機制。

1.3 應對方向

需要導入對應驗證機制，做法是：

根據提供的標準答案 + 現實環境運作測試，依照版本大小定義產出測試報告，依數據決定版本走向。

二、驗證機制做法（過濾器分階段）

階段 1：搜集誤判標準答案

初版先經過人為觀測該模型並記錄數據線
整理誤判影片集並輸出 RTSP（作為服務對照串流）
提供遵照答案（答案定義 = 理當通報）
搜集範圍：每一顆正式版登錄之鏡頭

階段 2：鏡頭 ID 對應 + 測試啟動

每顆鏡頭會對照正式版本服務的鏡頭 ID
提供測試環境啟用目標鏡頭開始測試
產出測試結果

階段 3：差異捕捉與漏洞修正

過程中會因為邏輯因素造成差異，例如：
10 秒通報冷卻
沒記到 log
邏輯適用性
這些差異反而是價值點 — 可以抓到邏輯與服務漏洞的關鍵點而修正
初期先直接呈現證實可用，再用可觀測性數據導入加快輔助判決

階段 4：客戶設定回饋閉環

鏡頭之設定會回過頭來作為人為標準答案的對照依據
或作為下次自動化數據跑的依據
範例：使用者設定「連續三秒 + 通報帽子」
規則會被對照，跟後續測試 match

階段 5：雙重數據產出與決策

雙重數據（標準答案 + 真實運作）之下產出：
百分比對照
原始數據
集中分析：
誤差只有 5%（自定義）→ 版本成功套用，可進行部署
失敗 → 有資料能參考作為對照

三、版本分級對應測試嚴謹度

依照修改版本的定義決定測試嚴謹度。

小版本

定義：完全同種類模型只是補齊資料組特性：原理上邏輯能沿用 測試方式：使用誤判驗證資料之抽樣做快速測試

中版本（本次出事範圍）

定義：模型不同但有關聯性要取代導入特性：連帶邏輯因應修正需確認 測試方式：跑完整誤判驗證資料 + 真實服務鏡頭即時運作（1～2 天）做分析依據

大版本

定義：模型全新且商用邏輯也有更動特性：模型 / 邏輯都為全新 測試方式： - 用上述方式拉長為週期測試驗證 - 因模型 / 邏輯都為全新，會定義新的評判標準

四、預期解決的問題

未來有數據測量能交付作為版本部署依據 - 業務層面對服務掌握度提升
提升服務穩定性以及模型 + 服務的掌握程度
模板實作後，未來導入可觀測性數據 debug 更快

五、對組織的效益（管理層視角）

本章節用「立刻避免什麼損失、能獲得什麼能力」兩個方向呈現，讓非技術角色也能評估此機制的價值。

5.1 立即規避的損失

重大客訴事件可預防：類似本次「換版本導致客戶通報全無/亂報」的事故，可在部署前被攔截，不再依賴客戶反映才發現。
緊急復原成本降低：避免事後 hotfix、客戶溝通、補償流程造成的工時負擔。
服務信任維持：客戶對辨識系統的可靠度認知，不會因小機率事件而大幅波動。

5.2 模型版本治理能力升級

版本決策數據化：從「人感判斷」變成「數據佐證」，每次部署都有可追溯的決策依據。
明確版本 SLA：小／中／大版本對應不同驗證週期，PM 與客戶端可獲得可預期的時間表。
漏洞持續發掘：標準答案庫成長過程同時是「bug 反向收集器」，邏輯與服務問題會被持續挖出與修正。

5.3 業務面獲得的能力

對外差異化：可宣稱「對版本變動有獨立驗證機制」，成為服務品質的賣點。
客戶信心傳遞：可告知客戶「您的鏡頭目前在新版的驗證通過情況」。
內部審計依據：每次版本部署都有完整數據可審計。

5.4 跨部門協作的副產品

模型管理區 / 服務團隊 / 客戶端設定 共享同一份標準答案庫，作為三方協作介面。
客戶設定本身成為驗證資產：客戶設定越精細 → 標準答案越多 → 驗證越準，形成正向循環。

5.5 一句話價值定位

把「模型版本切換」從有風險的開發行為，變成有數據佐證的治理流程。

六、概念邊界釐清（討論補充）

針對概念設計的 6 個邊界議題，討論結果如下：

6.1 標準答案庫的維護方式

強度依客戶鏡頭覆蓋率加強：誤報越常發生，該鏡頭的標準答案庫會持續增加
維護角色：需要有人整理，模型管理區的部門可以銜接
移動鏡頭問題：移動鏡頭本質上是固定點位在那邊轉，所以循環會包含完整場景，不算特例
延伸議題（先記錄，後續討論）：

設定值這件事情可以彈性化，搞不好可以延伸自定義標準答案，看哪種通報設定對結果更好

6.2 5% 誤差的對照對象

基本對照：標準答案 vs 目前模型運作結果 → 誤差 5% 內
雙重對照：
新模型 vs 標準答案 ≤ 5%
新模型 vs 目前模型（作為交叉檢驗）≤ 5%
彼此都在 5% 內 = 累計容忍 10%，視為都成功

6.3 版本分級的邊界判定

小版本：算模型問題
測試前期的信心分配率就會發現
在測試時測出大誤差就會直接駁回
中 / 大版本：理解自訂定義上的整合，不會有統一標準
只利用概念範圍確認
範例：「安全裝備 → 多樣化的安全裝備」
以觀念上他是本質一樣的東西

6.4 邏輯差異的三種分類（設計差異 / bug / 邏輯差異）

接受要分類
要檢驗的區域就會在這邊 → 用來判斷
同時也降低變數影響

6.5 客戶設定回饋的角色

以目前設定直接算，兩瞪眼
如果有更好的設定，那是另一個議題（延伸討論）
不影響本次驗證機制的判定方式

6.6 初始基線的建立方式

沒有「一次補完」的期待
拿業務目前層面開始慢慢補齊
隨著時間累積，標準答案庫會自然擴增

七、概念結構摘要

事件 → 缺乏驗證機制 → 客戶受影響
                ↓
        建立標準答案庫（人為標註 + RTSP 對照串流）
                ↓
        鏡頭 ID 對應 → 測試環境啟動
                ↓
        差異捕捉 → 漏洞修正 + 客戶設定回饋閉環
                ↓
        雙重數據（標準答案 vs 真實運作）
                ↓
        百分比對照（5% 閾值）→ 部署決策
                ↓
        依版本大小（小/中/大）配對應嚴謹度
                ↓
        產出測試報告 → 決定版本走向

文件版本：v3 - 加入「對組織的效益（管理層視角）」章節狀態：概念已成形，邊界已釐清；待進入實作層級討論

附錄：延伸議題（暫存，後續討論）

議題	緣由
自定義標準答案的設定彈性化	「搞不好可以延伸自定義標準答案看哪種通報設定對結果更好」（5.1）
客戶設定的最佳化建議	「如果有更好設定那也是」— 屬於另一個議題（5.5）