第一次用CrossEntropyLoss()做圖像分割是在一個街道場景的語義分割實驗里。網(wǎng)絡(luò)結(jié)構(gòu)用的還是當時很常見的編碼-解碼結(jié)構(gòu)第一版代碼跑起來之后loss從0.6慢慢降到0.3我當時還挺高興結(jié)果驗證集的mIoU一出來直接傻眼——背景類占了接近90%準確率很高但車輛、行人、建筑這些真正關(guān)心的類幾乎全部沒學到。后來花了好幾個晚上排查發(fā)現(xiàn)問題基本都出在我對CrossEntropyLoss()這條函數(shù)本身的理解上輸入格式、標簽編碼、類別分布、ignore_index每一個都能讓訓練“看似正常、實則報廢”。這篇就把我用CrossEntropyLoss()做圖像分割踩過的坑按類別整理一遍每個坑后面附上可照做的檢查方式和修復思路希望能幫你少熬幾個夜。1. 為什么圖像分割任務繞不開CrossEntropyLoss1.1 CrossEntropyLoss到底在算什么首先回到一個最基本的認知圖像分割的本質(zhì)是逐像素分類。模型對每個像素輸出C個類別的分數(shù)CrossEntropyLoss()的作用就是衡量“模型預測的分數(shù)分布”和“真實類別”之間的差異。PyTorch里的nn.CrossEntropyLoss()并不是一個復雜的黑盒它內(nèi)部等價于F.log_softmax(input, dim1)加F.nll_loss()也就是說它會先把logits在類別維度上做log softmax再取正確類別對應的負對數(shù)概率作為loss。把公式拆開就是對某個像素如果真實類別是c模型對該類的得分是z_c那損失就是-log(exp(z_c) / sum_j exp(z_j))。得分越高loss越小得分越低loss越大而且梯度會因為log函數(shù)的性質(zhì)變得更加明顯。這也是它在分類類任務里比MSE好用的原因MSE對輸出概率的錯誤懲罰是二次的到了飽和區(qū)梯度幾乎消失交叉熵在錯誤嚴重時梯度很大優(yōu)化起來效率高得多。有一個點容易被忽略F.log_softmax里的dim1意味著它默認輸入的第一維是batch第二維是通道也就是類別維度。這個約定直接影響后面所有輸入格式問題只要把通道維度放錯位置整個loss計算就會在錯誤的方向上“絲滑”地跑下去。1.2 分割場景下它比BCE、MSE更合適的原因很多做分割的新手會因為“分割也是輸出mask”就想到二分類于是直接拿BCE或者MSE去套這種做法在二前景二背景的簡單任務里能跑通但一旦類別變多就立刻出問題。BCE是逐類別獨立計算損失的它不關(guān)心類別之間是不是互斥的相當于把每個類都當成一個獨立的二元分類問題而語義分割的類別通常是互斥的一個像素只能是某一個類用CE這種帶softmax歸一化的損失才能天然保證所有類別的概率加起來等于1模型輸出的是真正的概率分布。MSE的問題更明顯。如果把分割當成回歸任務模型輸出的向量被強行拉向one-hot一樣的分布數(shù)值在飽和區(qū)梯度極小訓練速度慢而且對類別判別邊界非常不敏感。簡單說就是MSE問“你預測的數(shù)字和真實數(shù)字差多少”CE問“你給正確類別的信心夠不夠高”后者更貼合分類任務的本質(zhì)。所以主流分割項目的第一步基本都是criterion nn.CrossEntropyLoss()。但要注意默認情況下它給每個像素的權(quán)重是相同的也就是沒考慮類別分布差異。這在類別極不平衡的數(shù)據(jù)集上是致命問題后面第4章會展開講。1.3 使用它的前提約束logits與target的三條約定使用CrossEntropyLoss()前必須明確三條硬性約定第一輸入必須是未經(jīng)過softmax的原始logits不是概率第二logits的shape一般是(N, C, H, W)N是batchC是類別數(shù)H和W是空間尺寸第三target必須是整數(shù)索引形式的標簽shape是(N, H, W)取值必須在[0, C-1]范圍內(nèi)或者用ignore_index指定一個特殊值來忽略某些區(qū)域。這三條約定錯一條訓練就會出現(xiàn)各種奇怪現(xiàn)象。最常見的錯誤就是有人先寫了prob torch.softmax(logits, dim1)再把prob當作輸入扔給CrossEntropyLoss()結(jié)果loss沒有爆掉但模型越訓越差。還有人是把標簽做成了one-hot形式然后發(fā)現(xiàn)shape對不上直接報錯。后面所有踩坑內(nèi)容本質(zhì)上都圍繞這三條約定展開。2. 最容易踩的維度與形狀坑2.1 target的shape永遠比logits少一維這是我身邊同事問過最多的問題。模型輸出logits是(B, C, H, W)而mask標簽往往是(B, H, W)有些人會習慣性把mask也做成(B, H, W, 1)或者(B, 1, H, W)然后直接丟進loss接著就會看到類似Expected target size [B, H, W], got [B, 1, H, W]的報錯。為什么PyTorch要這么設(shè)計因為C通道是類別維度對每個像素來說真實類別就一個整數(shù)索引不需要展開成one-hot。如果你習慣把mask做成(B,1,H,W)在放進loss之前需要做一次squeeze(1)。如果你從圖像處理庫讀出來的是(H,W,1)類似的多余通道也要先去掉目的就是讓target保持(B,H,W)。我的建議是在dataloader的返回值里就把格式固化。圖像返回(3,H,W)的float tensor標簽返回(H,W)的long tensordataloader自動堆疊后就是(B,3,H,W)和(B,H,W)直接在loss里對齊。不要在訓練循環(huán)里臨時做各種view、squeeze、reshape少一步排錯步驟就會少一個潛在坑。2.2 通道維度在第二維別對最后一維做softmaxPyTorch的圖像張量默認是NCHW格式也就是說類別通道維度在第二維也就是dim1。但這個約定太容易被忽略尤其是從TensorFlow遷移過來的同學TF習慣把通道放在最后一維PyTorch里錯誤地寫torch.softmax(logits, dim-1)非常常見。表面上看dim-1也能運行不會報錯但它在W方向上做歸一化而不是在類別方向上。舉個例子如果logits的shape是(2, 19, 256, 256)dim-1會在最后一個維度的256個空間位置做softmax結(jié)果是每個通道內(nèi)部的空間值被歸一化了類別之間完全沒有競爭關(guān)系。這種情況下loss還能正常計算因為CrossEntropyLoss()內(nèi)部還會在dim1再做一次log_softmax但輸入已經(jīng)變成了一堆被空間歸一化過的數(shù)字模型基本學不出有效的類別邊界。診斷這類問題有一個很笨但有效的辦法在loss計算前打印一行l(wèi)ogits.shape然后自己默念一遍“第二維是類別數(shù)”再檢查softmax的dim是1。如果嫌麻煩就把softmax這類操作封裝成一個函數(shù)統(tǒng)一傳dim1避免到處手寫。2.3 提前對logits做softmax再送進loss等于白做這個坑我踩過而且是在一輪已經(jīng)很深的訓練之后才發(fā)現(xiàn)的。當時我為了在訓練日志里輸出“置信度”順手在loss之前寫了一句out torch.softmax(out, dim1)然后才把out傳給CrossEntropyLoss()。結(jié)果模型訓練一直很慢loss數(shù)值偏小驗證集幾乎不動。原因是CrossEntropyLoss()內(nèi)部已經(jīng)有l(wèi)og_softmax這一步。如果你先把softmax結(jié)果傳進去它等于在[0,1]范圍內(nèi)的概率值上再取一次log得到的分布已經(jīng)不再是模型原始分數(shù)的對數(shù)概率。尤其在概率接近0或1時數(shù)值會發(fā)生奇怪的偏移梯度方向雖然不至于完全反向但優(yōu)化過程被嚴重扭曲。正確做法是模型最后一層輸出logits直接丟給CrossEntropyLoss()需要看概率時單獨在inference階段做softmax。如果你非要在訓練過程中監(jiān)視概率就用with torch.no_grad()的代碼塊只算softmax做日志別讓它進入損失計算圖。2.4 上采樣、padding、裁剪引起的尺寸錯位分割模型里編碼-解碼結(jié)構(gòu)非常常見很多模型在解碼器末尾直接輸出了下采樣后的特征圖而不是原圖大小。此時如果直接把logits和原始分辨率mask去算CrossEntropyLoss()會報shape不匹配的錯誤。但比這個更隱蔽的情況是你用某種方式強行把它們對齊了但空間位置是錯的。比如DeepLab系模型最后特征圖是輸入尺寸的1/8或1/16如果沒做上采樣shape對不上會立刻報錯如果你寫了logits F.interpolate(logits, size(H, W), modebilinear, align_cornersTrue)尺寸對了但因為mask和原圖經(jīng)過的裁剪、padding不一樣實際像素錯位loss還在繼續(xù)算只是結(jié)果全程沒有意義。我的排查順序是先看原始圖像進模型前的尺寸變換再看mask有沒有做過相同的resize和crop。特別是在使用隨機裁剪時必須保證image和mask使用同一個crop參數(shù)。如果你在dataloader里用了圖像增強庫一定檢查是不是對mask也同步做了增強而且mask的插值方式要選最近鄰。3. mask標簽處理中隱藏的坑3.1 RGB的標注圖不能直接當target現(xiàn)在很多公開分割數(shù)據(jù)集給的標簽是RGB偽彩色圖而不是每個像素一個索引的PNG。比如VOC格式的mask是一張彩圖背景是黑色行人是紅色汽車是藍色。如果直接把RGB圖讀進來變成(H,W,3)或(3,H,W)再扔給CrossEntropyLoss()第一個崩潰點就是target維度不對第二個崩潰點是數(shù)值范圍不對——CrossEntropyLoss希望target是單通道整數(shù)索引不是一個三元組。正確做法是建一個顏色映射表把每個RGB值映射到類別索引。速度上別用純Python逐像素循環(huán)數(shù)據(jù)量一大就慢得致命?？梢杂肗umPy一行搞定每一類先做一個全零的索引矩陣然后對每個類別用np.all(mask_rgb color, axis-1)得到一個布爾矩陣再把對應位置填成類別id。最后轉(zhuǎn)成torch.from_numpy(index).long()。這個轉(zhuǎn)換過程最好放在預處理階段提前批量生成索引版mask保存下來而不是每次訓練都在dataloader里現(xiàn)場轉(zhuǎn)換。否則訓練時每讀一個樣本都做一次全圖顏色匹配CPU負載高到無法接受。3.2 標簽值必須連續(xù)且從0開始這個坑極其隱蔽。很多數(shù)據(jù)集的原始標簽里忽略區(qū)域用255背景用0但某些類別的ID可能是1、2、3之后直接跳到7、8、9中間沒有4、5、6。人的直覺是“既然是類別ID那就直接用”但CrossEntropyLoss()內(nèi)部做索引查表時是按target里的具體數(shù)值去取logits對應通道的。比如logits有10個通道代表類別0到9target里如果出現(xiàn)值12它會直接訪問越界報錯如果target里的值不連續(xù)但都沒有越界比如某些類從0到9中間缺了幾個那模型的一個輸出通道可能永遠不被用到另一個類別卻對上了錯誤通道最終預測結(jié)果混亂。所以在訓練前要做一件看起來多余但救命的事對訓練集和驗證集分別執(zhí)行np.unique(mask)看看mask到底有哪些值。如果發(fā)現(xiàn)不連續(xù)或者存在超出類別數(shù)范圍的值就建立一個重映射字典把所有有效值映射成0,1,2,...,C-1忽略值映射成255。這樣CrossEntropyLoss的通道和標簽才能一一對應。3.3 ignore_index是雙刃劍別指望它自動處理所有無效區(qū)域ignore_index的設(shè)計初衷是忽略某些位置的像素比如VOC的邊界白線、標注不全的區(qū)域等。常見做法是nn.CrossEntropyLoss(ignore_index255)然后在target里把無效區(qū)域的值設(shè)為255。這個機制很好用但它有幾個副作用需要留意。第一個副作用是當reductionmean時分母只統(tǒng)計有效像素數(shù)不是所有像素。如果一個batch里有效像素特別少loss值會表現(xiàn)出不正常的劇烈波動。更極端的情況是整個batch里的像素全是255loss直接變成nan。這個問題在小batch訓練、mask標注大量缺失時尤其明顯。第二個副作用是如果你同時設(shè)置了類別權(quán)重weight和ignore_indexweight的長度必須等于真實類別數(shù)C不要把忽略區(qū)域當成一個類別放進weight里。否則要么報維度不匹配要么權(quán)重語義錯亂。我習慣在計算weight時只統(tǒng)計非忽略區(qū)域的像素確保每個類別都有合理的頻率估計。3.4 數(shù)據(jù)增強后mask錯位和插值問題做分割的人都用過隨機翻轉(zhuǎn)、隨機旋轉(zhuǎn)、隨機縮放這些增強。很多人會把圖像增強做好但mask增強忘掉或者雖然做了用了雙線性插值。雙線性插值會產(chǎn)生介于兩個整數(shù)之間的浮點值比如0.2、0.8這樣的target直接傳給CrossEntropyLoss()會報dtype錯誤或者被某些操作截斷成0和1導致類別完全錯亂。mask的resize必須用最近鄰插值這在PyTorch的F.interpolate里就是modenearest在圖像增強庫里有類似參數(shù)。翻轉(zhuǎn)和旋轉(zhuǎn)這種不改變像素值的幾何變換要特別確認邊界填充值不要生成垃圾類別。隨機旋轉(zhuǎn)時如果邊界填充用了0那么補齊區(qū)域會被當成背景類這往往不是你想要的結(jié)果需要顯式用一個填充值然后在target里把它映射成ignore_index。另外一個容易被忽略的點如果對圖像做了歸一化mask不要做同樣的歸一化。圖像需要減去均值除以標準差mask只需要做類型轉(zhuǎn)換否則會引入浮點誤差。很多新手在同一個transform里對圖像和mask套了同一個標準化函數(shù)最后target直接變成了負數(shù)或者0.幾的小數(shù)loss瞬間變成nan。4. 訓練時loss表現(xiàn)異常的排查4.1 loss突然變成nan先從數(shù)據(jù)和target查起loss變成nan是分割訓練里最常見的異常之一。很多人第一反應是調(diào)整學習率、換優(yōu)化器但我經(jīng)手的案例里大部分nan其實來自target和輸入格式的問題而不是優(yōu)化器的問題。排查順序應該是先打印target.min()和target.max()確認沒有超出類別數(shù)范圍再打印logits.min()和logits.max()確認沒有inf或者nan最后看loss.item()是不是一開始就是nan如果是那大概率是數(shù)據(jù)問題。比如target里有值200而你的模型輸出通道只有19個CrossEntropyLoss在取log_softmax對應通道時會越界輕則報錯重則在某些版本里直接產(chǎn)生nan。還有如果標簽是浮點型必須轉(zhuǎn)成long()。我建議在dataloader里就把mask mask.long()固定好不要等到訓練循環(huán)里再改更不要依賴自動類型推斷。排查時在loss.backward()前面加一行斷言也很有用assert loss.item() loss.item()這能快速發(fā)現(xiàn)nan。加assert不能解決根本問題但它能把問題卡在最早出現(xiàn)的時刻避免訓了半天才發(fā)現(xiàn)loss早就壞了。4.2 loss不下降多半是大類別把模型帶偏了這個問題表面上跟CrossEntropyLoss關(guān)系不大但它確實是使用默認參數(shù)最容易踩的大坑。默認的weightNone意味著每個像素對loss的貢獻相同。當背景像素占95%、前景只占5%時模型只需要把所有像素都判成背景l(fā)oss就能降到很低mIoU卻慘不忍睹。我比較推薦的做法是先跑一個epoch統(tǒng)計各類別像素占比然后計算中位數(shù)頻率平衡權(quán)重。公式思路很簡單weight_i median_freq / freq_i其中freq_i是第i類像素在所有有效像素中的比例median_freq是這些比例的中位數(shù)。這樣做的效果是讓出現(xiàn)少的類別獲得更大權(quán)重同時不至于讓極稀有類權(quán)重過大導致訓練震蕩。設(shè)置weight時還有一個細節(jié)weight的每個值對應logits的通道索引不是類別標簽本身。如果你重映射過mask那么mask的值和weight的順序都要按照重映射后的索引來。否則即使維度匹配權(quán)重也會“配錯對象”。4.3 整個batch全是ignore區(qū)域時的空張量問題這個坑我調(diào)試了很久。當時用的數(shù)據(jù)集標注很稀疏一個batch里大部分像素都是未標注區(qū)域全是255。CrossEntropyLoss的ignore_index255把所有像素都過濾掉之后reductionmean要對0個元素求平均結(jié)果就是nan。這個問題在batch size比較小、類別又多又稀疏時很容易發(fā)生。修復思路有幾個方向。最直接的是增大batch size或者過濾掉那些有效標注太少的數(shù)據(jù)樣本。另一個通用做法是在訓練循環(huán)里檢測一下有效像素數(shù)量如果為0就跳過這個batch。但更治本的是檢查數(shù)據(jù)pipeline確認255這個值到底是“忽略區(qū)域”還是“背景類0”被強行轉(zhuǎn)成了255。我見過有人把mask填充值設(shè)成255但忘記標注它是ignore導致所有有效像素都被丟掉了。還有一個小技巧如果你發(fā)現(xiàn)訓練集里某些類別的像素總數(shù)少得可憐與其硬扛CrossEntropyLoss不如先做數(shù)據(jù)清洗把標注明顯錯誤的樣本剔除。損失函數(shù)能緩解類別不平衡但補不了標注質(zhì)量的問題。4.4 損失看起來太小或為0的幾種情況loss異?！昂谩辈灰欢ù碛柧氄?。最常見的一種情況是忘記喂logits直接拿softmax后的概率值傳給CrossEntropyLoss此時loss數(shù)值會比正常情況小很多因為它是在概率值上再取log而概率值的范圍天然被壓縮在0到1之間log后的負數(shù)絕對值非常小。這時候模型不一定完全學廢但跑很久也很難收斂到理想狀態(tài)。還有一種情況是target退化成了常數(shù)比如所有mask都是背景類0。此時模型只需要輸出一個常數(shù)分布就能把loss壓得很低。驗證集mIoU可能不為0但仔細看每類IoU只有一個類有數(shù)值。要排查這個問題可以在訓練開始前可視化幾個樣本的mask看一眼是不是存在不同類別的像素。如果驗證時loss很低但mIoU不高還有一個隱藏原因是模型處于model.train()而不是model.eval()模式BatchNorm的統(tǒng)計量在驗證時還在不斷變化導致輸出不穩(wěn)定。這種問題在分割任務里很常見尤其在用驗證集計算loss時必須用with torch.no_grad()加上model.eval()。5. 一次完整最小可復現(xiàn)的分割訓練實操5.1 最小數(shù)據(jù)讀取與標簽格式轉(zhuǎn)換下面給一個可以直接改來跑的流程重點不是模型多強而是讓CrossEntropyLoss的輸入輸出嚴格合規(guī)。圖像讀取后統(tǒng)一轉(zhuǎn)成float32的(3,H,W)張量mask讀取后先做顏色映射或直接讀索引圖然后轉(zhuǎn)成int64的(H,W)張量。def load_sample(image_path, mask_path): image read_image(image_path).astype(np.float32) # H,W,3 mask_raw read_mask(mask_path) # 可能是RGB或索引圖 # 如果mask是RGB圖這里要完成顏色到索引的映射 h, w mask_raw.shape[:2] mask np.zeros((h, w), dtypenp.int64) for cls, color in color_mapping.items(): mask[np.all(mask_raw color, axis-1)] cls # 統(tǒng)一格式圖像CHW標簽HW image torch.from_numpy(image.transpose(2, 0, 1)).float() mask torch.from_numpy(mask).long() return image, mask這里color_mapping要自己根據(jù)數(shù)據(jù)集定義比如{0: (0,0,0), 1: (128,0,0)}。映射完成后做一次np.unique(mask)確認最大值小于類別數(shù)或者把不需要的區(qū)域改成255。這個步驟雖然看起來啰嗦但能攔住后面至少一半的問題。5.2 一個最小分割模型與loss初始化模型不需要太復雜核心是最后輸出logits。class SegmentNet(nn.Module): def __init__(self, in_channels3, num_classes19): super().__init__() self.backbone nn.Sequential( nn.Conv2d(in_channels, 32, 3, padding1), nn.ReLU(inplaceTrue), nn.Conv2d(32, 64, 3, padding1), nn.ReLU(inplaceTrue), ) self.head nn.Conv2d(64, num_classes, 1) def forward(self, x): return self.head(self.backbone(x))損失函數(shù)我一般先這樣初始化criterion nn.CrossEntropyLoss(ignore_index255)如果已經(jīng)統(tǒng)計好了類別頻率就加上weight參數(shù)比如weightclass_weight_tensor。注意這個tensor要放到和模型一樣的device上并且數(shù)據(jù)類型是torch.float32。不要一開始就上focal loss、dice loss之類的復雜變體先用默認CE跑通基線后續(xù)再根據(jù)問題換。5.3 訓練循環(huán)中損失計算的常見寫法對照訓練循環(huán)的核心就幾行但錯誤寫法非常多。正確寫法是for images, targets in dataloader: images images.to(device) targets targets.to(device) # (B,H,W), long logits model(images) # (B,C,H,W) loss criterion(logits, targets) optimizer.zero_grad() loss.backward() optimizer.step()常見錯誤寫法我列幾個如果你在代碼里看到類似寫法直接改loss criterion(torch.softmax(logits, dim1), targets)——錯誤重復softmax。loss criterion(logits, targets.unsqueeze(1))——錯誤target多了通道維度。loss criterion(logits, targets.float())——錯誤target必須是long。loss criterion(logits.view(-1, C), targets.view(-1))——這種做法本身沒問題但前提是原始空間對應關(guān)系沒亂。很多人是在HWC和CHW之間換得暈頭轉(zhuǎn)向結(jié)果像素順序全亂了。與其手動view不如直接保持(B,C,H,W)和(B,H,W)傳給loss。5.4 驗證與保存指標時要注意的細節(jié)驗證階段很多人會直接pred logits.argmax(dim1)然后和target比較。這里最隱蔽的問題是argmax(dim1)是類別維度是對的但如果你因為之前習慣了TF的NHWC寫成argmax(dim-1)那你的pred會在W方向上取最大得到的結(jié)果完全不是類別索引。計算mIoU時也要過濾掉ignore_index對應的像素。最簡單的方法是只計算有效像素的混淆矩陣然后逐類計算IoU?；煜仃嚨木S度是C x C但一定要先確認target的值都在0到C-1之間否則索引直接越界。另外保存可視化結(jié)果時索引mask直接保存成灰度圖會很難看最好映射回原始RGB顏色再保存。但保存和可視化用的顏色映射不能影響訓練數(shù)據(jù)它只是后處理別把它混進dataloader里。6. 問題排查速查表與實際心得6.1 常見報錯與修復對照表這里整理一份我現(xiàn)在幾乎每次排查都會對照的速查表能覆蓋大多數(shù)分割任務中的CrossEntropyLoss問題?，F(xiàn)象常見原因修復方式報錯Expected target sizetarget多了一維或傳了one-hot統(tǒng)一為(B,H,W)的long型標簽loss是nantarget含越界值、ignore_index未設(shè)置、lr過高打印target min/max設(shè)置ignore_index降低lrloss數(shù)值異常小對softmax結(jié)果再算CrossEntropyLoss改為直接傳logits訓練acc高但mIoU低類別不平衡加類別權(quán)重或換focal/dice losslabel和模型通道錯位使用了不連續(xù)的類別ID重映射標簽為0到C-1mask增強后錯位mask用了雙線性插值或未同步變換用最近鄰插值圖像和mask走同一變換驗證時loss波動大忘記model.eval()BatchNorm失效驗證階段固定model.eval()這張表每次排查都能用上但真正解決問題的往往不是最后一條而是前幾條數(shù)據(jù)鏈路的問題。所以我的習慣是先檢查數(shù)據(jù)再去動損失函數(shù)。6.2 幾個我一直在用的診斷習慣我現(xiàn)在的固定流程是在第一次訓練前單獨寫一個“冒煙測試”腳本把第一個batch的數(shù)據(jù)取出來手動前向一次打印以下信息logits.shape、target.shape、target.dtype、target.min()、target.max()、logits.min()、logits.max()。這一堆信息看一眼能攔住絕大多數(shù)低級錯誤。如果訓練過程中l(wèi)oss出現(xiàn)異常我還會把當前batch的image和target可視化拼圖保存下來。直接看圖片比看數(shù)字快得多尤其是mask是否錯位、是否有莫名奇妙的填充值、以及255和0到底哪個是背景一張圖就能講清楚。還有一個小習慣是給訓練腳本設(shè)置固定隨機種子并且使用確定性的dataloader。這樣排查問題時能穩(wěn)定復現(xiàn)不會因為數(shù)據(jù)順序變化導致現(xiàn)象時有時無。分割任務本來訓練周期就長能復現(xiàn)的問題最好在早期就控制住。6.3 回到最初的那個項目最后是怎么修好的回到我開頭說的那個街道場景項目最后其實只改了三處把RGB mask轉(zhuǎn)成了連續(xù)索引給CrossEntropyLoss設(shè)置了ignore_index255再按各類別像素頻率計算了權(quán)重。沒換模型結(jié)構(gòu)沒換優(yōu)化器mIoU直接從不到20漲到接近50。那次之后我養(yǎng)成了一個習慣每次想把損失函數(shù)換成更復雜的東西之前先問自己幾個問題——target是不是long型通道維度是不是在第2維數(shù)據(jù)增強是不是同步了mask里的值是不是在0到C-1之間如果這些答案有任何一個是“沒確認”那就先別換loss因為CrossEntropyLoss本身很簡單復雜的永遠是它前后那堆數(shù)據(jù)。最后再分享一個小技巧如果你調(diào)來調(diào)去還是覺得loss表現(xiàn)詭異先臨時把數(shù)據(jù)集縮小到一個batch擬合一個或幾個樣本看loss能不能降到接近0。如果連單樣本都擬合不了那問題一定在數(shù)據(jù)鏈路或模型前向而不是損失函數(shù)。這個辦法我在很多項目里都用過比反復調(diào)整優(yōu)化器參數(shù)有效得多。