簡介實(shí)例分割是計算機(jī)視覺中區(qū)分同類別不同個體的關(guān)鍵技術(shù)它輸出像素級掩碼在倉儲物流場景中AGV叉車和機(jī)械臂需要精確識別每個托盤的輪廓和叉孔位置才能完成自主裝卸。然而實(shí)際項目中數(shù)據(jù)質(zhì)量往往決定模型上限從拿到數(shù)據(jù)集到訓(xùn)練部署中間每一步都有坑壓縮包損壞、標(biāo)注格式不兼容、類別定義混亂、訓(xùn)練集驗證集重復(fù)等。尤其是COCO格式與YOLO格式的轉(zhuǎn)換以及數(shù)據(jù)劃分策略直接影響模型評估的真實(shí)性。本文以托盤實(shí)例分割數(shù)據(jù)集為例完整記錄從ZIP解壓排錯、COCO轉(zhuǎn)YOLO、數(shù)據(jù)抽檢可視化到y(tǒng)olov8-seg訓(xùn)練調(diào)參的實(shí)操路徑并給出可復(fù)用的腳本和參數(shù)建議。這些經(jīng)驗同樣適用于其他實(shí)例分割數(shù)據(jù)集可以幫助工程人員少走彎路。1. 收到一個“托盤實(shí)例分割數(shù)據(jù)集_20251120_042738.zip”先別急著解壓同事丟過來一個壓縮包文件名是“托盤實(shí)例分割數(shù)據(jù)集_20251120_042738.zip”。做倉儲物流視覺的人看到這個名字就知道這是給托盤也叫卡板、pallet做實(shí)例分割用的訓(xùn)練數(shù)據(jù)。托盤是倉庫里最不起眼又是最關(guān)鍵的東西AGV叉車要識別它才能進(jìn)叉機(jī)械臂要識別它才能抓取無人裝卸要識別它才能定位。實(shí)例分割的意義在于我們不僅要判斷畫面里有托盤還要把每一個托盤單獨(dú)圈出來畫清楚各自的輪廓邊界。而文件名后面那串“20251120_042738”是數(shù)據(jù)集的生成時間戳這個細(xì)節(jié)看著不起眼實(shí)際關(guān)系到后面版本管理的門道我放到最后單獨(dú)聊。拿到這種數(shù)據(jù)壓縮包大多數(shù)人第一反應(yīng)就是雙擊解壓然后拖進(jìn)訓(xùn)練腳本里跑。我早年也是這樣后來被坑過好幾次才明白一份數(shù)據(jù)集到底能不能用、能跑出什么效果從你拿到壓縮包那一刻起就已經(jīng)有50%的答案了。這篇就當(dāng)是給這包數(shù)據(jù)做一次完整的“驗收改造訓(xùn)練部署”記錄適合正在做倉儲物流識別、AGV避障、機(jī)械臂抓取或者剛拿到某個實(shí)例分割數(shù)據(jù)集不知道從哪下手的同學(xué)。我會把解壓排錯、格式判讀、轉(zhuǎn)成YOLO格式、訓(xùn)練調(diào)參、評估落地這條鏈路完整走一遍中間穿插的坑都是實(shí)操里真會遇到的。1.1 實(shí)例分割和普通檢測的差別到底在哪先別急著動手把這個底層問題想清楚后面每個決策都有依據(jù)了。普通目標(biāo)檢測輸出的是矩形框也就是bounding box。矩形框?qū)ν斜P這種外形規(guī)則的剛體目標(biāo)來說乍一看是夠用的——反正托盤大體是長方形的。但實(shí)際項目里你會立刻撞上兩個問題。第一托盤經(jīng)常堆疊、交錯、前后遮擋。兩個托盤并排或者疊放的時候檢測框會連成一片框本身就失效了你根本分不清框里到底有一個托盤還是兩個。第二叉車和AGV真正要下叉的時候需要的是托盤叉孔進(jìn)叉口的精確位置和輪廓框的邊緣差十幾個像素可能就讓叉齒撞上貨物。實(shí)例分割在這里做的事是檢測每個目標(biāo)再給每個目標(biāo)單獨(dú)生成一個像素級輪廓也就是mask。這樣一來堆疊的目標(biāo)能分清叉孔邊界也能拿到像素級的精度。那語義分割不行嗎語義分割也能給每個像素分類但它把所有同類目標(biāo)合并成一個整體區(qū)分不出“托盤A”和“托盤B”。多目標(biāo)交互場景里實(shí)例分割是唯一能兼顧“識別托盤”和“逐個區(qū)分”的方案。至于Mask2Former或者SAM系列數(shù)據(jù)量充足、GPU資源寬裕的項目當(dāng)然可以上但現(xiàn)實(shí)里很多工廠項目只有一塊消費(fèi)級顯卡還要控制推理延遲YOLO系列的分割模型yolov8-seg / yolov11-seg依然是性價比最高的起點(diǎn)。后面所有轉(zhuǎn)換和訓(xùn)練都圍繞YOLO生態(tài)來講。1.2 文件名日期戳背后的版本管理邏輯很多人覺得壓縮包名字就是一串隨機(jī)字符其實(shí)“20251120_042738”就是這套數(shù)據(jù)集的生成時間格式是YYYYMMDD_HHMMSS。別小看這串?dāng)?shù)字它是數(shù)據(jù)集版本管理里最樸素也最有效的標(biāo)記。我見過太多團(tuán)隊的數(shù)據(jù)集叫“最終版v3”“new_dataset_2真最終”過兩周自己都分不清哪個新。我的建議是數(shù)據(jù)集統(tǒng)一用“項目名_內(nèi)容類型_YYYYMMDD_HHMMSS”命名壓縮包里再放一個version.txt或README記錄標(biāo)注規(guī)范、數(shù)據(jù)來源、樣本數(shù)量、變更說明。這樣哪怕數(shù)據(jù)集傳到第三個人手里光看文件名就能判斷新舊不用打開比對。這個時間戳還有另一層價值它標(biāo)記了采集時間窗口。工業(yè)場景里光照、貨物類型、產(chǎn)線布局會隨季節(jié)和現(xiàn)場改造而變化。模型在某個時間段效果變差時你能靠文件名快速定位自己用的是哪個時間窗口的數(shù)據(jù)排查是數(shù)據(jù)沒跟上現(xiàn)場還是模型本身退化。2. 解壓這關(guān)就卡住不少人ZIP文件損壞與密碼問題的完整排查拿到zip文件第一步是解壓。但就這一步我見過大量同學(xué)被卡住。最常見的兩個報錯是file is not a zip file翻譯過來就是“這不是一個有效的ZIP文件”invalid zip archive: could not find EOCDEOCD是ZIP文件尾部的中央目錄結(jié)束標(biāo)記很多人一看報錯就懷疑解壓軟件有問題換了好幾個工具還是不行。問題多半不在軟件在文件本身。2.1 “file is not a zip file”最常見的原因不是你解壓軟件的問題先說結(jié)論這個報錯大概率是文件本身不對而且是“它根本不是zip”的那種不對。三個常見來源第一下載工具把服務(wù)器返回的錯誤頁面存成了文件。比如你訪問一個失效下載鏈接服務(wù)器返回的是HTML錯誤頁瀏覽器或下載工具卻按照原文件名保存文件名是.zip內(nèi)容其實(shí)是一段網(wǎng)頁代碼。第二網(wǎng)盤或聊天軟件傳輸時文件名被截斷或改名擴(kuò)展名變成.zip但內(nèi)容其實(shí)是7z、rar或者其他格式。第三下載沒有完成文件被強(qiáng)制改名。排查方法很簡單Linux下用file命令看真實(shí)格式file 托盤實(shí)例分割數(shù)據(jù)集_20251120_042738.zip如果是正常的zip輸出類似Zip archive data, at least v2.0 to extract如果輸出的是HTML document、ASCII text、7-zip archive data之類那就能對上上面三種情況了。Windows下可以用7-Zip打開文件7-Zip對格式識別比較寬容如果它提示“該文件不是壓縮文件”你就知道問題在哪了。還有一個更隱蔽的情況文件確實(shí)下載完了但網(wǎng)絡(luò)中斷只下了一半文件好幾GB解壓到末尾報“unexpected end of data”。這是截斷型損壞處理方式在下一節(jié)。2.2 “could not find EOCD”是什么意思怎么處理EOCDEnd Of Central Directory是ZIP文件末尾固定結(jié)構(gòu)的一段記錄負(fù)責(zé)登記壓縮包的文件目錄和偏移量。所有解壓工具都是先讀這段“目錄頁”才知道壓縮包里有幾個文件、每個文件從哪里開始。如果EOCD缺失整個壓縮包的信息就丟了。這種報錯的常見原因就一個下載不完整尾部缺失。也有個別情況是生成zip的工具沒有正確封尾但比較少見。處理辦法分三步走。第一步比對文件大小。如果發(fā)布頁或說明文檔里寫了預(yù)期大小比如說是4.7GB你這里只有3.2GB那就別糾結(jié)了直接重新下載。修復(fù)一個沒下完的文件純屬浪費(fèi)時間。第二步大小對得上但依然報EOCD錯誤可以嘗試用7-Zip的修復(fù)功能打開壓縮包后按AltR或右鍵選擇“修復(fù)壓縮文件”Linux下用zip命令重建中央目錄zip -FF 托盤實(shí)例分割數(shù)據(jù)集_20251120_042738.zip --out 托盤修復(fù).zip這個命令會嘗試讀取剩余的數(shù)據(jù)塊并重建目錄。實(shí)測對“尾部少量缺失”有一定概率成功但修復(fù)后的文件里部分條目可能仍然損壞解壓后要逐個驗證。第三步如果修復(fù)失敗老實(shí)換網(wǎng)絡(luò)、換方式重新獲取。從NAS、對象存儲或公司內(nèi)部盤拷貝時建議用帶校驗和的下載方式避免二次中斷。下載完成后先算一下校驗和養(yǎng)成習(xí)慣sha256sum 托盤實(shí)例分割數(shù)據(jù)集_20251120_042738.zip發(fā)布方如果給了SHA256值對得上再解壓對不上果斷重下。這一步能幫你擋掉后續(xù)一大堆莫名其妙的報錯。2.3 密碼保護(hù)和校驗和數(shù)據(jù)集分發(fā)的兩個細(xì)節(jié)解壓時提示需要密碼別急著去找“破解工具”。很多數(shù)據(jù)集發(fā)布方會設(shè)統(tǒng)一解壓密碼通常寫在README、發(fā)布公告或配套郵件里花五分鐘翻一下文檔就能解決。去下載來路不明的破解軟件反而有安全風(fēng)險。如果是內(nèi)部加密包且密碼確實(shí)丟了針對自己有權(quán)解壓的文件可以用fcrackzip或zip2john配合John the Ripper做密碼恢復(fù)。但這類工具本質(zhì)是字典爆破純數(shù)字六位密碼可能都要跑很久實(shí)用性有限最穩(wěn)妥還是找原始發(fā)布者重新獲取。這里必須強(qiáng)調(diào)一條紅線涉及他人數(shù)據(jù)的加密包任何繞過密碼的操作都可能涉及合規(guī)問題邊界心里要有數(shù)。校驗和方面Windows下用PowerShellGet-FileHash -Algorithm SHA256 -Path .\托盤實(shí)例分割數(shù)據(jù)集_20251120_042738.zipLinux下用sha256sum或md5sum都行。養(yǎng)成“先校驗、再解壓”的習(xí)慣之后你會少很多“為什么我解壓出來圖片少了一半”的尷尬。3. 數(shù)據(jù)集內(nèi)部結(jié)構(gòu)標(biāo)注格式、類別與質(zhì)量抽檢解壓成功只是開始。真正決定模型上限的是壓縮包里的標(biāo)注靠不靠譜。這一節(jié)講怎么看懂一份實(shí)例分割數(shù)據(jù)集的內(nèi)部結(jié)構(gòu)。一份規(guī)范的實(shí)例分割數(shù)據(jù)集壓縮包解壓后目錄通常長這樣tray_dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ ├── annotations/ │ └── coco.json └── README.md如果解壓出來只有一堆散圖沒有標(biāo)注文件也沒有說明文檔那這個數(shù)據(jù)集的質(zhì)量就要打個問號了。3.1 COCO JSON與YOLO txt兩種主流分割標(biāo)注怎么識別目前實(shí)例分割數(shù)據(jù)集最常見的標(biāo)注格式有兩種COCO格式和YOLO分割格式。COCO格式所有標(biāo)注集中在一個annotations JSON文件里內(nèi)部按images圖片信息、annotations每個實(shí)例的標(biāo)注、categories類別定義三部分組織。每個annotation的segmentation字段有兩種形態(tài)多邊形坐標(biāo)數(shù)組或RLE壓縮掩碼。多邊形坐標(biāo)是絕對像素坐標(biāo)一維數(shù)組形式[x1, y1, x2, y2, ...]每兩個數(shù)一個點(diǎn)。YOLO分割格式每張圖片對應(yīng)一個同名的txt文件每一行是一個目標(biāo)class_id x1 y1 x2 y2 x3 y3 ...坐標(biāo)是相對圖片寬高的歸一化浮點(diǎn)數(shù)范圍0到1class_id從0開始。兩種格式的差異可以用一張表看清維度COCO JSONYOLO txt組織方式所有標(biāo)注集中在一個JSON每張圖一個txt坐標(biāo)絕對像素坐標(biāo)歸一化相對坐標(biāo)掩碼類型多邊形 RLE多邊形適合格式轉(zhuǎn)換適合作為原始母版適合直接訓(xùn)練人工可讀性一般較好我的建議是任何數(shù)據(jù)集到手先保留一份COCO格式作為“母版”因為它信息完整、生態(tài)工具多CVAT、labelme、coco-annotator都能導(dǎo)入導(dǎo)出YOLO txt只是訓(xùn)練時的臨時格式。后續(xù)換框架時COCO母版能幫你省很多事。3.2 類別定義與命名帶來的標(biāo)簽映射問題托盤數(shù)據(jù)集常見類別包括pallet標(biāo)準(zhǔn)托盤、wooden_pallet木托盤、blue_pallet藍(lán)色塑料托盤、fork_pocket叉孔/進(jìn)叉口等。不同團(tuán)隊對類別的切分邏輯不一樣有的把叉孔單獨(dú)設(shè)為一類有的把叉孔當(dāng)成托盤mask內(nèi)部的空洞不單獨(dú)標(biāo)。這里有個關(guān)鍵決策叉孔要不要單獨(dú)成一類。從AGV叉車實(shí)際決策的角度單獨(dú)一類更友好因為模型能同時輸出托盤外輪廓和叉孔位置直接指導(dǎo)叉齒的進(jìn)入點(diǎn)。但代價是標(biāo)注工作量成倍增加而且叉孔經(jīng)常被貨物遮擋遮擋樣本很難標(biāo)全。另一種做法是只標(biāo)托盤一個類利用mask的凹形輪廓后處理推算叉孔位置。對規(guī)則的木托盤有效對中間鏤空的塑料托盤效果較差。拿到數(shù)據(jù)集后先看README或標(biāo)注說明搞清楚定義規(guī)范。如果明確寫了fork_pocket這個類就老老實(shí)實(shí)按多類別訓(xùn)練別自作主張合并類別因為標(biāo)注者已經(jīng)按叉孔去標(biāo)了你不在訓(xùn)練里用就白白浪費(fèi)了這部分標(biāo)注。3.3 抽檢可視化用一張圖發(fā)現(xiàn)標(biāo)注錯位、漏標(biāo)和過擬合隱患格式和類別確認(rèn)之后不要直接全部丟進(jìn)訓(xùn)練?；ǘ昼娮龀闄z可視化隨機(jī)抽取三十張訓(xùn)練圖把原圖、mask、類別標(biāo)簽疊加畫出來人工過一遍。用Python和OpenCV快速繪制import cv2 import numpy as np def draw_mask_on_image(image_path, mask_np, color(0, 255, 0), alpha0.5): img cv2.imread(image_path) overlay img.copy() overlay[mask_np 0] color cv2.addWeighted(overlay, alpha, img, 1 - alpha, 0, img) return img抽檢時重點(diǎn)看四類問題標(biāo)注錯位mask和托盤邊緣偏差超過幾個像素。常見于標(biāo)注者趕工或標(biāo)注工具的外擴(kuò)參數(shù)設(shè)置不當(dāng)。漏標(biāo)圖中明顯有托盤但沒標(biāo)出來。這類樣本在訓(xùn)練里會被當(dāng)成背景對模型干擾極大。類別混淆木托盤標(biāo)成塑料托盤叉孔標(biāo)成托盤。后面yaml里類別順序一旦定錯前面的標(biāo)注全部白費(fèi)。圖像重復(fù)訓(xùn)練集和驗證集里出現(xiàn)重復(fù)圖片驗證指標(biāo)會虛高。很多人訓(xùn)完mAP看著0.9一上線變成0.6大概率是這個問題。重復(fù)圖檢測用一段小腳本import hashlib from pathlib import Path def file_hash(path): h hashlib.md5() with open(path, rb) as f: for chunk in iter(lambda: f.read(8192), b): h.update(chunk) return h.hexdigest() hashes {} for p in Path(images).rglob(*.jpg): h file_hash(p) hashes.setdefault(h, []).append(p) dup {h: ps for h, ps in hashes.items() if len(ps) 1} print(dup)這一步值得做。尤其是拿到別人整理好的壓縮包你永遠(yuǎn)不知道里面有沒有混入重復(fù)樣本。我之前處理過一個數(shù)據(jù)集訓(xùn)練集和驗證集重復(fù)率接近18%前期所有實(shí)驗指標(biāo)都虛高排查了好久才定位到浪費(fèi)了整整一周的算力。4. 把數(shù)據(jù)集改造成YOLOv8能直接訓(xùn)練的格式如果原數(shù)據(jù)是COCO JSON格式訓(xùn)練前必須做一次格式轉(zhuǎn)換。如果已經(jīng)是YOLO txt格式可以直接跳到4.4。下面默認(rèn)原數(shù)據(jù)是COCO JSON。4.1 訓(xùn)練集/驗證集劃分原則劃分?jǐn)?shù)據(jù)集的原則只有一條驗證集要能代表真實(shí)使用場景。這比追求“隨機(jī)均勻”重要得多。按場景劃分而不是按圖片隨機(jī)劃分。如果同一個攝像機(jī)同一時間段連續(xù)拍攝的四十幀圖片隨機(jī)打散后一部分進(jìn)訓(xùn)練集、一部分進(jìn)驗證集那驗證集就相當(dāng)于訓(xùn)練集的高仿副本評估結(jié)果會嚴(yán)重虛高。正確做法是把連續(xù)時間序列歸為一組整組劃到訓(xùn)練或驗證里。如果數(shù)據(jù)來自多個工廠或產(chǎn)線盡量以整個場地或產(chǎn)線為劃分子單元。比例上常規(guī)做法是train:val 8:2或9:1。數(shù)據(jù)量少于2000張時建議先用KFold交叉驗證評估穩(wěn)定性最終交付時再用全量訓(xùn)一版。4.2 COCO多邊形轉(zhuǎn)YOLO分割格式的歸一化處理轉(zhuǎn)換的核心邏輯把COCO里每個annotation的多邊形坐標(biāo)分別除以圖片寬和高得到0到1之間的歸一化坐標(biāo)。下面是一個可用的轉(zhuǎn)換腳本import json import os def coco_to_yolo_seg(coco_json_path, image_dir, label_dir): with open(coco_json_path, r) as f: coco json.load(f) img_info {img[id]: img for img in coco[images]} cat_id_map {cat[id]: i for i, cat in enumerate(coco[categories])} os.makedirs(label_dir, exist_okTrue) anns_by_img {} for ann in coco[annotations]: anns_by_img.setdefault(ann[image_id], []).append(ann) for img_id, anns in anns_by_img.items(): img img_info[img_id] w, h img[width], img[height] base_name os.path.splitext(img[file_name])[0] lines [] for ann in anns: seg ann[segmentation] if isinstance(seg, dict): # RLE格式需要先解碼為mask再轉(zhuǎn)多邊形見下文 continue for poly in seg: points [(poly[i] / w, poly[i 1] / h) for i in range(0, len(poly), 2)] if len(points) 3: continue cls_id cat_id_map[ann[category_id]] coord_str .join(f{x:.6f} {y:.6f} for x, y in points) lines.append(f{cls_id} {coord_str}) if lines: with open(os.path.join(label_dir, base_name .txt), w) as f: f.write(\n.join(lines))幾個容易出錯的地方要特別注意坐標(biāo)必須保留浮點(diǎn)數(shù)精度不要取整。取整對小目標(biāo)mask是致命的一個點(diǎn)偏兩三個像素小托盤的輪廓就變形了。多邊形的點(diǎn)數(shù)可能很多YOLO對點(diǎn)數(shù)沒有硬性限制但點(diǎn)數(shù)過多也沒有額外收益保留原始精度即可不要做額外的逆時針排序或簡化很多簡化算法會引入偽影。如果COCO里某個目標(biāo)用的是RLE編碼需要先用pycocotools把RLE解碼成二值mask再用cv2.findContours把mask轉(zhuǎn)成多邊形邏輯相對長建議單獨(dú)封裝成一個函數(shù)備用from pycocotools import mask as mask_utils import cv2 def rle_to_polygon(rle): m mask_utils.decode(rle) contours, _ cv2.findContours(m, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) polys [] for c in contours: c c.flatten().tolist() if len(c) 6: polys.append(c) return polys4.3 轉(zhuǎn)換腳本與可視化驗證工具處理壓縮包數(shù)據(jù)集時我習(xí)慣把轉(zhuǎn)換腳本和驗證工具放在一起目錄結(jié)構(gòu)清晰一點(diǎn)tools/ ├── coco_to_yolo_seg.py ├── check_yolo_labels.py └── visualize_labels.py轉(zhuǎn)換之后用check_yolo_labels.py做一次批量驗證重點(diǎn)檢查坐標(biāo)是否在0到1之間、class_id是否越界、多邊形是否退化、圖片和txt是否一一對應(yīng)。from pathlib import Path label_dir Path(labels) all_ok True for txt in label_dir.rglob(*.txt): for idx, line in enumerate(txt.read_text().strip().splitlines()): parts line.split() cls int(parts[0]) coords list(map(float, parts[1:])) if cls 0 or cls 3: print(f{txt}:{idx} bad cls {cls}) all_ok False if any(c 0 or c 1 for c in coords): print(f{txt}:{idx} coord out of range) all_ok False if len(coords) 6: print(f{txt}:{idx} degenerate polygon) all_ok False print(All OK if all_ok else Check failed)再把轉(zhuǎn)換后的txt畫回原圖上人工看幾張確認(rèn)坐標(biāo)沒有翻轉(zhuǎn)。特別提醒COCO和YOLO的坐標(biāo)原點(diǎn)都在圖片左上角但如果你從OpenCV或其他標(biāo)注工具導(dǎo)出的數(shù)據(jù)原點(diǎn)可能在左下角。畫出圖來一眼就能發(fā)現(xiàn)轉(zhuǎn)換腳本里加一個基本檢查就能兜底。4.4 data.yaml與訓(xùn)練命令數(shù)據(jù)準(zhǔn)備好了寫data.yaml。這是訓(xùn)練前最容易寫錯的一步。path: /your/absolute/path/tray_dataset train: images/train val: images/val nc: 1 names: 0: pallet幾個必須注意的點(diǎn)path一定要寫絕對路徑別寫相對路徑。YOLO在切換工作目錄時相對路徑很容易踩坑訓(xùn)練到一半報“image not found”最后發(fā)現(xiàn)是路徑解析問題。nc和names的數(shù)量、順序必須和txt里的class_id嚴(yán)格對應(yīng)。如果你的轉(zhuǎn)換腳本里類別映射不對訓(xùn)練時YOLO會報“erroneous label”或直接忽略錯誤標(biāo)簽。train和val下面填的是圖片文件夾路徑Y(jié)OLO會自動到相鄰的labels目錄找對應(yīng)txt。沒有GPU想先在CPU上驗證數(shù)據(jù)鏈路是否正?？梢杂眯∧Ｐ汀⑸佥啍?shù)跑一遍yolo segment train datatray.yaml modelyolov8n-seg.pt epochs10 imgsz640 batch4 devicecpu這個命令只要能正常進(jìn)入訓(xùn)練循環(huán)并打印loss說明數(shù)據(jù)鏈路已經(jīng)通了。接著再上正式訓(xùn)練GPU命令一般長這樣yolo segment train \ datatray.yaml \ modelyolov8s-seg.pt \ epochs200 \ imgsz640 \ batch16 \ device0 \ workers8 \ projectruns/tray_exp \ nameexp015. 訓(xùn)練托盤實(shí)例分割模型的參數(shù)設(shè)置與調(diào)優(yōu)實(shí)錄這一節(jié)把我實(shí)際調(diào)參過程中的經(jīng)驗寫下來可以直接照抄。5.1 從yolov8n-seg還是s-seg起步很多人一上來就選x-seg或m-seg結(jié)果顯存不夠或者訓(xùn)練時間翻好幾倍。我的建議是分兩步走先用n-seg跑通流程用少量epoch驗證數(shù)據(jù)沒問題、loss能收斂再換s-seg做正式訓(xùn)練。托盤是規(guī)則剛體目標(biāo)學(xué)習(xí)難度不高s-seg在大多數(shù)工業(yè)場景已經(jīng)足夠。本文還有配套的精品資源點(diǎn)擊獲取