▌ 引言

對(duì)嵌入式和 IoT 工程師來(lái)說(shuō)，攝像頭接入 AI 的路徑已經(jīng)相當(dāng)成熟：IPC 輸出 RTSP 流，邊緣盒子跑推理，檢測(cè)結(jié)果上傳云端或觸發(fā)本地動(dòng)作。YOLOv8 輕量化版本在 RK3588、昇騰 310 等芯片上的部署，已經(jīng)有大量工程實(shí)踐可以參考。
但在部署層之上，有一個(gè)問(wèn)題逐漸變得突出：推理結(jié)果的"顆粒度"與實(shí)際應(yīng)用需求之間存在錯(cuò)配。
模型識(shí)別出"一個(gè)人在用手機(jī)"——這是感知結(jié)果。但業(yè)務(wù)系統(tǒng)需要的是"這名員工在崗位上持續(xù)使用手機(jī)超過(guò) X 分鐘"——這是判斷結(jié)論。本文從硬件感知到系統(tǒng)邏輯，梳理這一層的設(shè)計(jì)思路。

▌ 一、感知層現(xiàn)狀：端側(cè)推理已相當(dāng)成熟

硬件側(cè)：
? 邊緣 AI 芯片：瑞芯微 RK3588、海思 Hi3516/Hi3519、地平線 J5/J6、昇騰 310B 等
? 典型算力：1 ~ 10 TOPS INT8，滿足 1080P 視頻實(shí)時(shí)檢測(cè)需求
? 接入方式：RTSP/RTMP 拉流，GigE 有線或 WiFi 無(wú)線，POE 供電

軟件側(cè)：
? 推理框架：RKNN、MNN、OpenVINO、TensorRT（按芯片選擇）
? 檢測(cè)模型：YOLOv8/v9 輕量化版本，端側(cè)部署幀率一般在 15 ~ 30 FPS
? 跟蹤算法：ByteTrack、OC-SORT，用于目標(biāo) ID 持久化

這一層能穩(wěn)定輸出：目標(biāo)框、類別標(biāo)簽、置信度、目標(biāo) ID（跟蹤情況下）。但這些輸出是逐幀結(jié)構(gòu)化數(shù)據(jù)，缺乏時(shí)序上下文。

▌ 二、中間層缺失：從特征流到事件結(jié)論的鴻溝

設(shè)想一個(gè)具體場(chǎng)景：需要判斷后廚員工是否在處理食材前完整執(zhí)行了洗手流程。
流程定義為：
1. 員工接觸原材料（攝像頭 A 覆蓋區(qū)域）
2. 員工移動(dòng)至洗手臺(tái)（攝像頭 B 覆蓋區(qū)域）
3. 洗手動(dòng)作持續(xù)時(shí)間 ≥ 20 秒
4. 員工返回操作臺(tái)（攝像頭 A）

如果只依賴端側(cè)推理輸出，系統(tǒng)接收到的是：

如果只依賴端側(cè)推理輸出，系統(tǒng)接收到的是：
t=00:01:23 cam_A person_07 action: touching_ingredients conf=0.91
t=00:01:47 cam_B person_? action: handwashing conf=0.83
t=00:02:09 cam_A person_07 action: food_prep conf=0.88

要從這三條離散記錄中判斷"洗手流程合規(guī)"，系統(tǒng)需要解決：
? cam_B 中的 person_? 是否與 cam_A 的 person_07 是同一個(gè)人？（跨攝像頭 ReID）
? 洗手動(dòng)作是否持續(xù)了足夠時(shí)長(zhǎng)？（時(shí)序狀態(tài)持久化）
? 整個(gè)流程的時(shí)間間隔是否在合理范圍內(nèi)？（序列時(shí)間約束）
這些處理，全部發(fā)生在感知層之上、應(yīng)用層之下的中間層，而這一層目前在很多系統(tǒng)設(shè)計(jì)中處于空白狀態(tài)。

▌ 三、中間層的關(guān)鍵技術(shù)模塊

1. 目標(biāo) ReID（跨攝像頭重識(shí)別）

原理上是基于外觀特征向量（ResNet/ViT 提?。┑南嗨贫绕ヅ?，但實(shí)際工程中需要應(yīng)對(duì)：
? 光線差異（不同區(qū)域攝像頭的曝光條件不同）
? 服裝相似（同一品牌制服的員工高度相似）
? 遮擋與角度變化
工程上通常結(jié)合空間拓?fù)浼s束來(lái)降低誤匹配率：只有攝像頭網(wǎng)絡(luò)中空間相鄰的點(diǎn)位，才對(duì)目標(biāo) ReID 進(jìn)行匹配嘗試。

2.行為狀態(tài)機(jī)

用于對(duì)單一目標(biāo)的跨幀行為狀態(tài)進(jìn)行管理，典型設(shè)計(jì)如下：
IDLE ──[首次檢測(cè)到目標(biāo)行為]──> TRIGGERED
TRIGGERED ──[持續(xù)N幀確認(rèn)]──> CONFIRMED
TRIGGERED ──[行為消失]──> IDLE
CONFIRMED ──[超過(guò)時(shí)長(zhǎng)閾值]──> EVENT_GENERATED
CONFIRMED ──[行為消失]──> IDLE（不生成事件）

3.序列流程驗(yàn)證器

本質(zhì)上是一個(gè)帶時(shí)間約束的有限狀態(tài)自動(dòng)機(jī)（FSA）：
? 定義動(dòng)作節(jié)點(diǎn)序列：[A, B, C]
? 為相鄰節(jié)點(diǎn)間定義時(shí)間窗口約束：A→B ≤ 30s，B→C ≤ 120s
? 狀態(tài)在收到對(duì)應(yīng)事件信號(hào)時(shí)遷移，超時(shí)則回到初始狀態(tài)或標(biāo)記為流程中斷
3.4 規(guī)則配置層
業(yè)務(wù)規(guī)則以結(jié)構(gòu)化配置描述，而非硬編碼，規(guī)則變更只需修改配置文件，無(wú)需重新訓(xùn)練或部署模型。

▌ 四、端側(cè) vs 邊緣服務(wù)器的分工建議

▌ 五、開(kāi)發(fā)者注意事項(xiàng)

時(shí)鐘同步： 多攝像頭跨幀分析的基礎(chǔ)是時(shí)間戳可信。邊緣設(shè)備需要接入 NTP 同步，時(shí)鐘偏差控制在 100ms 以內(nèi)，否則跨攝像頭的時(shí)序邏輯會(huì)出現(xiàn)系統(tǒng)性誤差。
幀采樣策略： 不需要對(duì)每幀都運(yùn)行全量推理。對(duì)于持續(xù)性行為判斷，1 ~ 5 FPS 的關(guān)鍵幀采樣通常足夠，結(jié)合運(yùn)動(dòng)檢測(cè)進(jìn)行自適應(yīng)采樣可進(jìn)一步降低計(jì)算開(kāi)銷。
特征流格式標(biāo)準(zhǔn)化： 中間層輸入的特征流格式要盡早標(biāo)準(zhǔn)化（推薦 Protobuf 或 JSON Schema），這是規(guī)則引擎與感知層解耦的基礎(chǔ)。
狀態(tài)持久化： 邊緣服務(wù)器需要對(duì)目標(biāo)狀態(tài)進(jìn)行持久化（SQLite 或 Redis），避免因重啟丟失跨時(shí)段的行為狀態(tài)記錄。

▌ 小結(jié)

視頻 AI 系統(tǒng)從"端側(cè)推理"到"事件判定"，需要在感知層之上構(gòu)建一個(gè)完整的中間分析層，核心模塊包括：跨攝像頭 ReID、行為狀態(tài)機(jī)、序列流程驗(yàn)證器和規(guī)則配置引擎。
這一層的工程挑戰(zhàn)主要集中在跨攝像頭目標(biāo)關(guān)聯(lián)的準(zhǔn)確性、實(shí)時(shí)系統(tǒng)的延遲控制和規(guī)則描述的表達(dá)能力上。

感興趣的朋友歡迎在評(píng)論區(qū)討論相關(guān)的工程實(shí)踐經(jīng)驗(yàn)。

審核編輯 黃宇