簡介基于YOLOv8的手勢識別應(yīng)用包面向深度學(xué)習(xí)、圖像識別方向的開發(fā)者與學(xué)生解決人機(jī)交互、自動駕駛、虛擬現(xiàn)實等場景中手勢動作快速識別的問題。YOLOv8作為YOLO系列最新版本在保證實時檢測速度的同時提升了精度特別適合手勢這類小目標(biāo)的識別任務(wù)代碼與訓(xùn)練好的模型已封裝成可直接運(yùn)行的項目降低了入門門檻。壓縮包共18個文件約11.18MB核心包含app.py主程序、兩個PyTorch模型權(quán)重yolov8n.pt、best.pt、10張JPG手勢樣本圖以及requirements.txt、packages.txt等環(huán)境配置與README說明文檔目錄結(jié)構(gòu)清晰便于本地部署和二次開發(fā)。目前已有52人學(xué)習(xí)下載適合作為YOLOv8入門實踐的參考案例。通過運(yùn)行代碼和觀察模型輸出讀者可以掌握目標(biāo)檢測的基本流程并結(jié)合訓(xùn)練指標(biāo)圖理解模型調(diào)優(yōu)思路為后續(xù)自建手勢數(shù)據(jù)集提供基礎(chǔ)。其中的README.md與依賴清單可幫助快速搭建環(huán)境避免常見配置問題非常適合課程設(shè)計或畢業(yè)設(shè)計的快速落地。1. 打開這個基于 YOLOv8 的手勢識別應(yīng)用我先確認(rèn)的不是 Demo 而是邊界第一次拿到這份基于 YOLOv8 的手勢識別應(yīng)用壓縮包我常被問到要不要先解壓運(yùn)行一遍。運(yùn)行當(dāng)然要做但在此之前我更習(xí)慣把包的邊界摸清楚它是只給推理腳本還是把訓(xùn)練、驗證、實時識別串成了完整的圖像識別鏈路。按目錄結(jié)構(gòu)看這份資源明顯偏向后者?；谏疃葘W(xué)習(xí)目標(biāo)檢測框架 YOLOv8 的實現(xiàn)里面包含手勢數(shù)據(jù)集的 YOLO 格式標(biāo)注、數(shù)據(jù)配置、訓(xùn)練入口和攝像頭實時識別腳本適合有 Python 基礎(chǔ)、想把手勢類別快速落到業(yè)務(wù)原型里驗證的從業(yè)者如果只是想在周末跑通一個 Demo這套工程反而顯得過度設(shè)計。下面我按實際拆包的順序來寫先看文件結(jié)構(gòu)和數(shù)據(jù)再動訓(xùn)練參數(shù)接后處理然后把常見坑和進(jìn)階部署一起收尾。2. 先拆文件結(jié)構(gòu)和數(shù)據(jù)集組織訓(xùn)練腳本、標(biāo)注格式與類目對應(yīng)關(guān)系壓縮包解壓后我一般不做全盤讀取先做目錄盤點。常見做法是項目按 dataset / code / output 三層切割。dataset 單獨放圖像和標(biāo)簽訓(xùn)練腳本放根目錄產(chǎn)出的權(quán)重統(tǒng)一進(jìn) runs這樣后續(xù)發(fā)布時不會把幾千張訓(xùn)練圖全部打進(jìn)部署包。2.1 目錄逐項拆解圖像目錄、標(biāo)注目錄與三個關(guān)鍵文件hand_gesture/ ├── dataset/ │ ├── images/ │ │ ├── train/ # 訓(xùn)練圖片jpg 或 png │ │ └── val/ # 驗證圖片 │ └── labels/ │ ├── train/ # 與圖片同名的 txt 標(biāo)注 │ └── val/ ├── handgesture.yaml # 數(shù)據(jù)配置與類別表 ├── train.py # 訓(xùn)練入口 ├── detect.py # 單圖/攝像頭推理入口 ├── requirements.txt # 依賴清單 └── runs/ # 訓(xùn)練輸出權(quán)重、曲線、驗證結(jié)果從這個樹能看到三個容易忽略的細(xì)節(jié)。第一images 下只分了 train 和 val沒有 test。手勢識別這類目標(biāo)檢測項目里單獨標(biāo)一個 test 集的成本很高通常訓(xùn)練完拿 val 做早停判斷真正上線前再手工抽查一段視頻就夠了。多數(shù)機(jī)器學(xué)習(xí)初學(xué)者看到?jīng)]有 test 目錄會很慌其實不影響資源包的正常使用我一般會在 val 里再留 10% 的圖不參與訓(xùn)練作為冒煙樣本。第二標(biāo)注沒有用 VOC 的 XML而是 YOLO 自帶的 txt。這個格式把每張圖片的所有目標(biāo)寫進(jìn)一個文本文件里每行一個框和圖片文件保持同名前綴。這樣從訓(xùn)練到推理全程不需要寫 XML 解析代碼是壓縮包里已經(jīng)替你省掉的工序。第三runs 目錄在首次訓(xùn)練前是空的訓(xùn)練腳本會自動創(chuàng)建。如果拿到的包是別人訓(xùn)練過的版本里面會同時帶 best.pt 和 last.pt。best.pt 是按驗證集指標(biāo)選出的最優(yōu)權(quán)重日常識別用它last.pt 是最后一輪權(quán)重適合斷點續(xù)訓(xùn)。判斷資源能直接用還是需要重訓(xùn)就看這兩文件帶不帶。2.2 數(shù)據(jù)組織與標(biāo)注格式labels 里的 txt 存什么怎么校驗以某張編號 000001 的圖片為例同目錄下會有一個 000001.txt# dataset/labels/train/000001.txt每行一個目標(biāo)框 0 0.421875 0.5078125 0.40625 0.7734375 1 0.578125 0.6484375 0.21875 0.3828125 2 0.742575 0.7436120 0.16353 0.21311每行五個數(shù)值依次是類別 id、框中心點 x、框中心點 y、框?qū)?、框高。注意這里的 x、y、width、height 都是相對原圖寬高的歸一化坐標(biāo)取值范圍 0 到 1不能直接當(dāng)作像素用。比如第一行類別 0中心點水平位置在 42.1875% 處實際像素 0.421875 × 圖像寬垂直位置在 50.78% 處框?qū)捳紙D像寬約 40.6%框高占圖像高約 77.3%。手指橫跨成像時這么寬的框是正常的。如果標(biāo)注數(shù)據(jù)是從 LabelImg 或 Labelme 導(dǎo)出之后再轉(zhuǎn) YOLO完整轉(zhuǎn)換邏輯里最容易出錯的就是像素坐標(biāo)沒有除回來。我提供一段常用的轉(zhuǎn)換函數(shù)def coco_to_yolo(coco_box, img_w, img_h): # coco_box 為 [x_min, y_min, width, height]單位是像素 x_min, y_min, w, h coco_box x_center (x_min w / 2.0) / img_w y_center (y_min h / 2.0) / img_h box_w w / img_w box_h h / img_h return f{x_center:.6f} {y_center:.6f} {box_w:.6f} {box_h:.6f}這段代碼的邏輯是把 COCO 風(fēng)格的左上角坐標(biāo)和寬高換算成 YOLO 所需的中心坐標(biāo)與歸一化寬高。參數(shù) img_w、img_h 必須傳原圖分辨率很多人習(xí)慣在此處傳的是訓(xùn)練時縮放后的 640 或 416畫框就全部偏移。比率保留 6 位小數(shù)已足夠太多會無意義太少會在極小目標(biāo)上產(chǎn)生像素級偏差。2.3 類別與配置映射六類手勢和 yaml 的一次對齊包內(nèi) handgesture.yaml 是數(shù)據(jù)配置的錨點path: ./dataset train: images/train val: images/val nc: 6 names: 0: thumb 1: index 2: middle 3: ring 4: little 5: oknc 表示類別總數(shù)names 的排列順序就是模型輸出之后各通道對應(yīng)的類別。訓(xùn)練腳本讀的是這份 yaml推理腳本讀的也是模型里存的 names 字段。如果訓(xùn)練時把 index 放在 1 而部署時把 names 寫成別的順位模型輸出明明是對的界面卻會把食指顯示成中指這種問題排查起來非常隱蔽。我拿到包的第一件事就是在訓(xùn)練前后各打印一次 model.names確認(rèn)它和 yaml 完全一致。另外做一次類別分布抽查也很值得防止某類樣本數(shù)量過少。以下腳本按目錄統(tǒng)計每個類的框數(shù)量from glob import glob from collections import Counter cls_counter Counter() for label in glob(dataset/labels/train/*.txt): with open(label) as f: for line in f: cls_counter[int(line.split()[0])] 1 print(cls_counter)邏輯與參數(shù)說明逐行讀取 label取每行的第一個字段類別 id計數(shù)。如果發(fā)現(xiàn)某個類別數(shù)量只有另一個類別的十分之一訓(xùn)練時就要考慮細(xì)化重復(fù)該類或給該類別更多增強(qiáng)否則最后 loss 會被大類淹沒小類別識別率非常低。這也是我判斷資源包數(shù)據(jù)質(zhì)量時會先看統(tǒng)計、再看 yaml 的原因。3. 訓(xùn)練參數(shù)與數(shù)據(jù)增強(qiáng)配置文件、batch 與 imgsz 怎么定數(shù)據(jù)對齊之后才進(jìn)入訓(xùn)練環(huán)節(jié)。這里不看玄學(xué)主要看兩件事yaml 是否正確被訓(xùn)練腳本讀取以及 batch、imgsz 和增強(qiáng)參數(shù)是否落在硬件能承受的范圍。下面按文件解讀和命令行調(diào)用兩步走。3.1 看懂配置文件與訓(xùn)練入口YAML 與 train.py 的對應(yīng)關(guān)系train.py 常見寫法是對 ultralytics 的二次封裝核心代碼很短from ultralytics import YOLO if __name__ __main__: # 加載預(yù)訓(xùn)練權(quán)重n/s/m 分別對應(yīng)體積和精度 model YOLO(yolov8s.pt) model.train( datahandgesture.yaml, # 第 2 章對齊過的數(shù)據(jù)配置 epochs120, # 完整訓(xùn)練輪數(shù) batch16, # 單批圖片數(shù)受顯卡顯存限制 imgsz640, # 訓(xùn)練與推理統(tǒng)一用 640 cacheTrue, # 首次后把圖片緩存進(jìn)內(nèi)存 patience20, # 驗證指標(biāo)連續(xù) 20 輪未提升則早停 device0, # 0 號 GPU seed42, )邏輯說明YOLO(yolov8s.pt)加載的是 COCO 預(yù)訓(xùn)練權(quán)重COCO 里沒有手勢類別加載它只是借用主干網(wǎng)絡(luò)提取圖像特征的能力最后幾層會被重新初始化。data 指向第 2.3 節(jié)的 yaml訓(xùn)練腳本根據(jù)其中的 train 路徑自動組織樣本。epochs120 是在小數(shù)據(jù)集上足夠覆蓋收斂的輪數(shù)如果你的數(shù)據(jù)量只有幾百張60 輪也會看到驗證指標(biāo)停滯。imgsz640 是官方默認(rèn)值指尖這類細(xì)粒度特征對這個值非常敏感我建議不要低于 480。模型選型上yolov8n.pt 體積最小攝像頭場景吞吐最高yolov8s.pt 精度常有明顯提升顯存占用也在 8G 卡的可承受范圍內(nèi)yolov8m.pt 則適合離線批量處理。資源包默認(rèn)用的通常是 s如果你的機(jī)器只有 4G 顯存第一次訓(xùn)練前建議替換成 n。3.2 從數(shù)據(jù)集路徑到訓(xùn)練命令一次完整調(diào)用不帶界面的命令行調(diào)用如下python train.py --data handgesture.yaml --weights yolov8s.pt \ --epochs 120 --batch 16 --imgsz 640 --device 0這段命令里 --data 是必填--weights 決定遷移起點--batch 和 --imgsz 共同決定顯存開銷。我一般把固定配置留在腳本里命令行只做覆蓋方便記錄每次實驗用的是什么組合。訓(xùn)練開始后日志會輸出每個 epoch 的 box loss、cls loss、dfl loss 以及 mAP50、mAP50-95判斷是否收斂主要看驗證集 mAP50而不是盯著訓(xùn)練集 loss。如果你要在 Windows 上跑注意 train.py 入口必須寫成if __name__ __main__:的形式否則訓(xùn)練腳本在啟動子進(jìn)程時會把整個文件重新執(zhí)行一遍輕則重復(fù)加載模型重則直接報 daemon 進(jìn)程相關(guān)錯誤。Linux 服務(wù)器上一般不需要特別處理。訓(xùn)練中途 CtrlC 中斷是很常見的事。再次執(zhí)行時 ultralytics 會從 runs/detect/trainX 中找 last.pt 并繼續(xù)前提是命令行中 weights 參數(shù)指向 last.pt。我不會清空 runs 目錄重來因為中斷位置可能已經(jīng)收斂得不錯斷點續(xù)訓(xùn)省時間。3.3 數(shù)據(jù)增強(qiáng)與關(guān)鍵超參數(shù)batch、imgsz、mosaic 的實際影響yolov8 的內(nèi)置增強(qiáng)默認(rèn)值是為 COCO 這種多樣場景設(shè)計的手勢數(shù)據(jù)集必須單獨收緊model.train( datahandgesture.yaml, epochs100, batch16, imgsz640, degrees5, # 旋轉(zhuǎn) 5 度之內(nèi)超過會破壞手指相對位置 scale0.5, # 縮放系數(shù) 0.5~1.5 translate0.1, # 平移范圍 ±10%超過會讓手部出框 flipud0.0, # 手勢不做垂直翻轉(zhuǎn) hsv_h0.015, # 色調(diào)輕微擾動防止膚色過擬合 hsv_s0.4, # 飽和度擾動 hsv_v0.4, # 明度擾動 mosaic0.8, # 80% 概率進(jìn)行 4 圖拼接 mixup0.2, # 20% 概率與另一張圖混合 )邏輯與參數(shù)說明degrees 為什么取 5因為手勢是柔性目標(biāo)旋轉(zhuǎn)超過 15 度食指和中指的空間關(guān)系會被破壞模型學(xué)到的是角度特征而不是手勢特征。取 5 度足夠覆蓋手掌在自然狀態(tài)下的晃動。flipud 要關(guān)掉垂直翻轉(zhuǎn)會把食指朝下變成食指朝上類別意義不變但訓(xùn)練分布和真實使用場景不匹配如果攝像頭是俯拍的這類增強(qiáng)反而制造偽樣本。mosaic 和 mixup 對數(shù)據(jù)量少的項目比較重要。mosaic 把四張圖拼成一張相當(dāng)于把小目標(biāo)放大了訓(xùn)練但如果你的手部框占比已經(jīng)很大mosaic 反而增加邊框割裂改到 0.5 到 0.8 之間可以快速對比。我習(xí)慣把超參按以下窗口設(shè)置先跑通再談最優(yōu)參數(shù)推薦起始值什么時候調(diào)低batch168G 顯存且 OOM降到 8imgsz640顯存不足時降到 480不推薦 320degrees5出現(xiàn)手指方向誤判時降到 2mosaic0.8小目標(biāo)漏檢但大目標(biāo)正常時降到 0.5mixup0.2背景負(fù)樣本較多時可提高到 0.4表格里的思路是先保證梯度能更新再考慮精度。顯存不夠只用調(diào)整 batch 和 imgsz 兩項其余增強(qiáng)參數(shù)盡量不要在第一輪實驗中動避免多個變量同時變化分不清是誰的影響。4. 實時推理與結(jié)果輸出攝像頭循環(huán)、后處理與本地接口訓(xùn)練結(jié)束真正能跑起來的還是推理端。這里我按從簡單到復(fù)雜的順序?qū)懴茸寯z像頭循環(huán)穩(wěn)定再自定義標(biāo)注繪制最后接成一個 HTTP 接口給上位機(jī)用。4.1 攝像頭讀取與推理循環(huán)控制檢測頻率保住幀率detect.py 的主循環(huán)常見寫法是import cv2 from ultralytics import YOLO model YOLO(best.pt) # 用訓(xùn)練保存的最優(yōu)權(quán)重 cap cv2.VideoCapture(0) # 打開默認(rèn)攝像頭 cap.set(cv2.CAP_PROP_FRAME_WIDTH, 1280) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 720) frame_skip 2 # 每 3 幀推理一次 idx 0 while cap.isOpened(): success, frame cap.read() if not success: break idx 1 if idx % (frame_skip 1) ! 0: continue results model.predict(frame, conf0.45, iou0.5, verboseFalse) annotated results[0].plot() cv2.imshow(hand_gesture, annotated) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()邏輯說明frame_skip2 的含義是跳過兩幀、處理第三幀攝像頭本身 30fps推理 10fps 就能達(dá)到看起來流暢的交互。如果實際測試仍然卡先把 imshow 和 waitKey 放進(jìn)一個開關(guān)比如按空格才顯示畫面平時只做識別服務(wù)。conf0.45 之所以比離線驗證時低是因為攝像頭運(yùn)動模糊會把置信度整體拉低一截離線測 0.6線上我一般保留 0.4 或 0.45。iou0.5 是 NMS 閾值兩個手勢靠得很近時適當(dāng)降這個值能去掉重復(fù)框但降太多會讓重疊的相鄰手指被合并成一個框。如果你想把識別結(jié)果與業(yè)務(wù)系統(tǒng)同步先在上位機(jī)固定推理輸出的 JSON 字段再談幀率。我習(xí)慣把每幀檢測結(jié)果追加到一個環(huán)形緩沖區(qū)里物理按鍵按下時再取最近一幀結(jié)果這樣不會出現(xiàn)手勢已經(jīng)結(jié)束才收到指令的情況。4.2 后處理與可視化自繪框和類別文字的注意點不依賴 plot()自繪框代碼需要自己處理返回值gesture_names {0: thumb, 1: index, 2: middle, 3: ring, 4: little, 5: ok} for result in results: if result.boxes is None: continue for box in result.boxes: x1, y1, x2, y2 map(int, box.xyxy[0].tolist()) cls_id int(box.cls[0]) conf float(box.conf[0]) if conf 0.5: continue cv2.rectangle(frame, (x1, y1), (x2, y2), (0, 255, 0), 2) label f{gesture_names[cls_id]}: {conf:.2f} cv2.putText(frame, label, (x1, y1 - 8), cv2.FONT_HERSHEY_SIMPLEX, 0.8, (0, 255, 0), 2)參數(shù)與邊界box.xyxy 返回的是浮點張量不轉(zhuǎn) int 送給 cv2.rectangle 會拋類型異常box.conf[0] 是 0 到 1 的置信度過濾閾值放這里最省事不需要等到整張圖推理完。如果你業(yè)務(wù)上只關(guān)心 OK 手勢可以在這一層直接按 cls_id 過濾避免下游系統(tǒng)處理無關(guān)類目。值得注意的細(xì)節(jié)是 gesture_names 這組編號必須和訓(xùn)練 yaml 一致而不是和窗口顯示順序一致。模型預(yù)測的是 0 到 5 的整數(shù)編號編號對應(yīng)的中文名只在這里發(fā)生第一次偏移這也是手寫后處理最容易出錯的一層。我在部署前會在若干張測試圖上對比標(biāo)注與顯示結(jié)果能快速定位錯層。4.3 把結(jié)果接出去用 HTTP 接口替代窗口顯示讓識別結(jié)果給其他進(jìn)程用較常見的方式是包一層 Flask 服務(wù)from flask import Flask, request, jsonify import cv2, base64, numpy as np app Flask(__name__) model YOLO(best.pt) app.route(/infer, methods[POST]) def infer(): payload request.get_json() img_bytes base64.b64decode(payload[image]) img cv2.imdecode(np.frombuffer(img_bytes, np.uint8), cv2.IMREAD_COLOR) results model.predict(img, conf0.5, iou0.5, verboseFalse) out [] for r in results: for box in r.boxes: cls_id int(box.cls[0]) out.append({ class: cls_id, name: model.names[cls_id], conf: float(box.conf[0]), bbox: box.xyxy[0].tolist() }) return jsonify(out)邏輯說明這個接口接收 base64 編碼的圖像先解碼成 numpy 數(shù)組再推理最后返回 JSON。好處是上游只要會 requests 就能調(diào)用不依賴攝像頭設(shè)備。參數(shù)上注意服務(wù)端和客戶端要保持同一套 base64 編碼格式否則經(jīng)常出現(xiàn)圖片能 decode 但顏色通道反了的情況那是 BGR 與 RGB 順序問題不是模型問題。并發(fā)量高的時候盡量避免走 base64直接 multipart 上傳二進(jìn)制圖片能省一層轉(zhuǎn)碼開銷CPU 占用會明顯下降。單攝像頭場景下這個接口足夠支撐本地少量并發(fā)的調(diào)用再高就要上消息隊列。5. 避坑與排查訓(xùn)練不收斂、顯存溢出、誤檢和低幀率的解決記錄下面的五個坑是我每次復(fù)現(xiàn)手勢識別項目時幾乎都會踩到的每一條都按現(xiàn)象、原因、解決的順序記錄。不一定全部命中你的環(huán)境但多數(shù)情況下能減少排查時間。5.1 現(xiàn)象訓(xùn)練 loss 正常下降驗證集漏檢卻接近一半訓(xùn)練曲線看起來沒有任何問題loss 一路走低但到 val 上 mAP50 只有 0.3。原因是數(shù)據(jù)集的背景高度相似比如五百張圖里四百八十張都是同一張辦公桌模型把桌角紋理當(dāng)成手勢的一部分。解決方法是先看 val 圖片的錯誤樣本如果錯誤框集中在圖片固定位置基本就坐實了背景泄漏。我一般在訓(xùn)練時把背景增強(qiáng)打開mixup 調(diào)到 0.3 以上并且在手機(jī)拍攝翻轉(zhuǎn)中引入負(fù)樣本很快就能看到 mAP 回升。5.2 現(xiàn)象訓(xùn)練時提示 CUDA out of memory16G 顯存跑 batch16、imgsz640 很穩(wěn)8G 卡上會在第三個 epoch 附近直接爆。原因是 mosaic 會把不同尺寸圖片拼成一個 640×640實際單 batch 峰值顯存和整圖尺寸成正比幾乎等比于 batch。解決順序是先 batch 16 降到 8如果還爆把 imgsz 降到 480同時確認(rèn)沒有開 cacheTrue。cache 在內(nèi)存里存一份數(shù)據(jù)副本顯存緊張時它并不會直接占用顯存但 Windows 下會拉高物理內(nèi)存占用導(dǎo)致數(shù)據(jù)排隊變慢誤以為又爆顯存。遇到這種情況也檢查一下顯卡驅(qū)動是否支持混合精度ultralytics 默認(rèn)開著 amp老顯卡上反而可能不穩(wěn)定。5.3 現(xiàn)象攝像頭實時推理只有五幀每秒單線程 while 循環(huán)從攝像頭讀一幀、推理一幀、imshow 一幀幀率始終上不去。原因是攝像頭讀取本身阻塞加上 waitKey 強(qiáng)制等待推理時間被放大了三倍。解決是把圖像采集單獨丟到一個線程主線程只負(fù)責(zé)拉最新一幀推理import threading import queue frame_q queue.Queue(maxsize2) def capture_loop(cap, q): while True: ok, frame cap.read() if ok and not q.full(): q.put(frame) thread threading.Thread( targetcapture_loop, args(cap, frame_q), daemonTrue) thread.start()邏輯說明用長度 2 的隊列做緩沖讀線程只管往隊尾放新幀推理線程從隊頭取最新的幀。如果取幀跟不上隊列滿了就直接拋棄舊幀保證推理落在最新畫面上。這個改動在普通筆記本上能把 FPS 從 5 提到 12 左右。同時加上 cap.set(cv2.CAP_PROP_BUFFERSIZE, 1)攝像頭驅(qū)動的內(nèi)置緩沖只留一幀避免視頻流延遲越來越大。5.4 現(xiàn)象畫面里沒有手模型卻報出一個高置信度手勢背景中只要有類似膚色或形狀的物體比如雜志封面的手、桌面反光模型就報出類別。原因是訓(xùn)練集幾乎沒有“沒有手”的負(fù)樣本模型把背景局部特征學(xué)習(xí)成了目標(biāo)特征。解決方法是增加只含背景的圖片作為負(fù)樣本每張負(fù)樣本的 txt 寫為空文件并單獨加一個 background 類別再把 conf 閾值從 0.3 提到 0.5。比較典型的處理從原訓(xùn)練集里抽出三分之一的背景區(qū)域直接存成負(fù)樣本圖重訓(xùn)一輪。這是我這幾個項目里最見效的做法。5.5 現(xiàn)象中指和食指互相混淆錯判集中在這兩個類如果混淆矩陣顯示錯誤集中在 index 和 middle 之間多半有兩層原因一是標(biāo)注框偏了框把兩根手指都包進(jìn)去了模型沒法學(xué)到區(qū)分性特征二是 imgsz 太小640 下指尖間距在特征圖上不足一個像素。解決是先人工抽十張混淆樣本檢查標(biāo)注再在增強(qiáng)外把 imgsz 升到 768 訓(xùn)練一輪。如果兩種措施都做完仍然混淆可以嘗試在類別定義上合并為“二指手勢”這一拍降低細(xì)粒度分類要求業(yè)務(wù)上往往更穩(wěn)定。6. 更近一步導(dǎo)出 ONNX 跑邊緣側(cè)把手勢識別結(jié)果接進(jìn)業(yè)務(wù)系統(tǒng)資源包里的 detect.py 依賴 Python 和完整訓(xùn)練框架生產(chǎn)環(huán)境如果想嵌入到邊緣設(shè)備更好的做法是導(dǎo)出 ONNX 權(quán)重用 OpenCV DNN 或 ONNX Runtime 做推理速度和體積都會顯著改善。導(dǎo)出命令一行即可yolo export modelbest.pt formatonnx opset17 simplifyTrue導(dǎo)出后會生成同目錄的 best.onnx我一般接著用 ONNX Runtime 做一個最小驗證腳本import cv2 import numpy as np import onnxruntime as ort session ort.InferenceSession(best.onnx) img cv2.imread(demo.jpg) # 先 letterbox 到 640再按 YOLOv8 的輸出格式解析寫到這里主要想傳達(dá)的信息是拿到資源包之后的路徑應(yīng)該是先小數(shù)據(jù)復(fù)現(xiàn)再大增量重訓(xùn)最后導(dǎo)出成更輕的部署格式。某次我把 best.pt 直接塞進(jìn)邊緣盒子里啟動時間超過八秒換 ONNX 之后降到一點五秒這個差距在產(chǎn)線上非常明顯。導(dǎo)出驗證通過后可以把結(jié)果通過 HTTP 或消息隊列接進(jìn)業(yè)務(wù)系統(tǒng)。我之前在模擬項目X里就是讓識別服務(wù)返回 JSON上位機(jī)拿到手勢類別后觸發(fā)語音播報和屏幕提示延遲控制在百毫秒以內(nèi)。此類接法只需改 detect.py 的返回結(jié)構(gòu)不需要重訓(xùn)模型。每次做手勢識別原型驗證我都強(qiáng)制把“小樣本先跑通”和“ONNX 導(dǎo)出后做一次結(jié)果對比”這兩步放進(jìn)工作流避免模型形態(tài)變了但推理端還拿著舊解析邏輯。這條習(xí)慣幫我少踩了不少坑希望幫到你。本文還有配套的精品資源點擊獲取