簡介面向深度學習圖像識別初學者、安全方向開發(fā)者及課程設計學習者的字符型驗證碼識別實踐包圍繞數(shù)字與字符驗證碼的卷積神經(jīng)網(wǎng)絡、循環(huán)神經(jīng)網(wǎng)絡建模、訓練與預測流程展開可用于入門項目復現(xiàn)、算法練手和驗證碼識別方案調(diào)研。壓縮包共1210個文件約9.58MB其中978張png、202張jpg及少量bmp、jpeg圖片構成驗證碼樣本17個py腳本覆蓋數(shù)據(jù)處理、模型構建、訓練預測等環(huán)節(jié)另含txt說明、rst文檔、zip壓縮包與模型文件等輔助內(nèi)容。已有1542人學習下載具備一定參考熱度。讀者可從中獲得從樣本歸一化、數(shù)據(jù)增強、one-hot編碼到CNN/RNN模型搭建、交叉熵訓練與結果組合的完整源碼脈絡并借助示例圖片和腳本理解字符序列識別、過擬合監(jiān)控及多字符輸出思路便于改造成自己的驗證碼識別項目。1. 從一批糊掉的字符圖說起這個基于深度學習的字符識別項目到底能干什么前陣子有人拿著一批自己生成的四位字符圖來找我圖上壓著干擾線和噪點人眼掃過去都得愣一下。他要的不是接個現(xiàn)成接口敷衍過去而是基于深度學習的字符型圖片數(shù)字驗證碼識別——從零訓一個模型出來。這份資源就是那條完整鏈路的 Python 實現(xiàn)數(shù)據(jù)生成、圖像預處理、網(wǎng)絡定義、訓練收斂、推理解碼一步不落源碼能直接跑起來。它的適用面比看上去寬。想完整走一遍「圖像輸入到字符串輸出」流程的深度學習新手可以拿它當?shù)谝粋€真正跑通的實戰(zhàn)做 OCR、票據(jù)編號、工牌數(shù)字、集裝箱號這類字符識別落地的開發(fā)者可以把它當成一個能直接改的基線。字符集小、長度固定、單通道灰度圖訓練成本低到一張消費級顯卡幾小時就出結果這才是它適合入門的核心原因。2. 目錄結構與技術選型一個字符識別項目該有的骨架先別急著看模型。字符識別這類項目跑不起來的原因九成不在網(wǎng)絡結構而在目錄沒分好、配置散在各處、訓練和推理各寫一套預處理。這套源碼的目錄劃分是我比較認可的一種改起來不牽一發(fā)動全身。2.1 六個文件撐起整條鏈路captcha_rec/ ├── config.py # 訓練/推理共用配置超參只在這里改 ├── charset.py # 字符集與索引映射訓練推理共用同一份 ├── data/ │ ├── gen_captcha.py # 自建數(shù)據(jù)集生成器 │ ├── dataset.py # Dataset 與預處理流水線 │ ├── train.txt # 每行 路徑\t標簽 │ └── val.txt ├── models/ │ └── cnn.py # CNN 主干 逐位分類頭 ├── train.py # 訓練循環(huán)、驗證、保存權重 ├── predict.py # 單圖/批量推理與解碼 └── utils/ ├── metric.py # 整串準確率、單字符準確率 └── seed.py # 固定隨機種子 └── requirements.txt這個劃分的關鍵在于三個「單一出口」config.py管參數(shù)、charset.py管字符和索引、dataset.py管預處理。很多人在自己寫的時候把預處理寫在訓練腳本里推理時又抄一遍抄錯一個cv2.resize的插值參數(shù)線上準確率立刻掉十幾個點這種血淚經(jīng)驗我在別人的項目里見過不止一次。工程約定上train.txt和val.txt用制表符分隔路徑和標簽不用 CSV因為圖片路徑里偶爾會出現(xiàn)逗號。標簽一律小寫不做大小寫混排——字符集里0和O、1和l這類形近字符如果都保留模型在低分辨率下幾乎必然混淆除非你的業(yè)務真的需要區(qū)分。charset.py是全篇最容易翻車的地方把它單獨拎出來是值得的# charset.py 訓練和推理都必須 import 這一份禁止在別處重寫 CHARSET 0123456789abcdefghijklmnopqrstuvwxyz # 0 號位固定留給 CTC 的 blank逐位分類時從 1 開始用也不會浪費多少參數(shù) CHAR2IDX {c: i 1 for i, c in enumerate(CHARSET)} IDX2CHAR {i 1: c for i, c in enumerate(CHARSET)} BLANK 0 NUM_CLASSES len(CHARSET) 1 # 36 blankNUM_CLASSES加 1 是為了兼容后面第 6 章要講的 CTC 改造逐位分類時多出來的那一類永遠學不會對結果沒有影響。參數(shù)說明CHAR2IDX的索引從 1 開始BLANK0是 CTC 的硬性約定改不了。IDX2CHAR必須和CHAR2IDX嚴格互逆我一般寫個斷言assert len(IDX2CHAR) len(CHAR2IDX)擋住手抖。config.py里我把所有數(shù)字集中了# config.py 所有超參的唯一來源 IMG_H, IMG_W 60, 160 # 統(tǒng)一尺寸寬高比 8:3 比較接近 4 位字符的排版 MAX_LEN 4 # 固定長度變長方案見第 6 章 BATCH_SIZE 64 EPOCHS 40 LR 1e-3 WEIGHT_DECAY 1e-4 DEVICE cuda # 沒有顯卡就寫 cpu訓練慢但能跑 TRAIN_LIST data/train.txt VAL_LIST data/val.txt CKPT ckpt/best.pthIMG_H和IMG_W不是隨便定的。4 位字符橫排寬度至少要是單字符寬度的 4 倍還留出間隙60 高度能保住字符的筆畫細節(jié)又不至于讓全連接層參數(shù)爆炸。把IMG_W提到 320 而模型不變Flatten后的維度翻倍全連接層參數(shù)量直接四倍小數(shù)據(jù)集上過擬合會來得非?？?。2.2 技術選型為什么先做逐位分類而不是一上來就 CRNN 配 CTC字符識別主流兩條路一條是固定長度逐位分類一條是 CRNN CTC 的序列識別。這個項目選的是前者理由很實在固定長度場景下逐位分類的訓練信號更直接。逐位分類把「識別 4 個字符」拆成 4 個獨立的分類任務每個位置一個 softmax損失是 4 個交叉熵的均值。梯度回傳路徑短收斂快20 到 30 個 epoch 就能把整串準確率推到很高的水位。CTC 則是把模型輸出當成一條時間序列靠動態(tài)規(guī)劃把所有可能的對齊方式加起來它對齊能力更強、支持變長但訓練早期收斂慢標簽長度和輸入長度不匹配時還會直接給你inf損失。對比項逐位分類本項目CRNN CTC字符長度必須固定任意長度收斂速度快幾十 epoch 見效慢常要上百 epoch實現(xiàn)復雜度低多一個 view 就行中要處理 input_lengths對字符粘連的魯棒性一般靠位置先驗硬扛較好典型翻車點字符集順序錯亂標簽長度 時間步導致 inf選逐位分類不等于偷懶。字符長度固定的業(yè)務場景——四位驗證碼、六位工單號、固定位數(shù)的批次號——占了實際需求的大頭用 CTC 屬于殺雞用牛刀還多背一份對齊邏輯的維護成本。真到了變長那天主干網(wǎng)絡和數(shù)據(jù)集代碼基本不用動只換分類頭和損失函數(shù)第 6 章會給具體的改法。主干網(wǎng)絡用的是最樸素的四段卷積。這套結構在字符識別上有個隱含優(yōu)勢四段MaxPool把 60×160 壓到 2×10特征圖上橫向還剩 10 個位置剛好夠 4 個字符各自找到自己的感受野又不會因為壓得太狠把相鄰字符糊在一起。換成三段卷積特征圖剩 7×20全連接層參數(shù)量漲到四倍小數(shù)據(jù)集上直接過擬合。2.3 環(huán)境和依賴別在版本上栽跟頭依賴不多但鎖版本這件事別省# requirements.txt torch2.0,3.0 torchvision0.15 opencv-python4.8 numpy1.24 pillow10.0 tqdm4.66opencv-python和opencv-python-headless千萬別同時裝裝重了cv2.imread在無圖形界面的服務器上會報libGL.so.1找不到。這種錯誤看起來像系統(tǒng)環(huán)境問題實際是依賴裝串了浪費半天時間排查。我一般在服務器上只裝 headless 版本。charset.py里的字符集順序一旦定下來就不能隨便動。改了字符集順序而不重訓模型輸出的索引全部錯位表現(xiàn)是「訓練時好好的推理出來全是亂碼」這個坑在第 5 章會單獨展開。種子也要固定utils/seed.py里把random、numpy、torch三家的種子一起設復現(xiàn)實驗才有意義。3. 數(shù)據(jù)管線從字符圖片到能喂進網(wǎng)絡的張量模型再漂亮數(shù)據(jù)管線錯了全白搭。這一章拆的是data/gen_captcha.py和data/dataset.py兩個文件前者負責造數(shù)據(jù)后者負責把圖片變成張量。3.1 自建數(shù)據(jù)集字符圖怎么生成、怎么標注沒有現(xiàn)成數(shù)據(jù)集的時候自己生成是最快的路。真實業(yè)務里的字符圖片通常來自截圖或掃描件但練手階段用 PIL 合成完全夠用關鍵是干擾要加到「人眼勉強能認」的程度太干凈學不到東西太臟模型直接放棄。# data/gen_captcha.py 生成一張四位字符圖并寫入標注文件 import random from PIL import Image, ImageDraw, ImageFont, ImageFilter def gen_one(text, size(160, 60), font_pathfonts/mono.ttf): img Image.new(RGB, size, (255, 255, 255)) draw ImageDraw.Draw(img) font ImageFont.truetype(font_path, 34) cell size[0] // len(text) for i, ch in enumerate(text): # 每個字符獨立抖動坐標模擬真實場景的排版漂移 x i * cell random.randint(-2, 4) y random.randint(0, 8) color tuple(random.randint(0, 90) for _ in range(3)) draw.text((x, y), ch, fontfont, fillcolor) # 干擾線1~3 條顏色比字符略淺避免完全遮住筆畫 for _ in range(random.randint(1, 3)): x1, y1 random.randint(0, size[0]), random.randint(0, size[1]) x2, y2 random.randint(0, size[0]), random.randint(0, size[1]) draw.line((x1, y1, x2, y2), fill(random.randint(120, 200),) * 3, width1) # 椒鹽噪點密度控制在千分之五左右 for _ in range(int(size[0] * size[1] * 0.005)): draw.point((random.randint(0, size[0] - 1), random.randint(0, size[1] - 1)), fill(random.randint(0, 255),) * 3) return img.filter(ImageFilter.GaussianBlur(radius0.6))參數(shù)說明cell是單個字符分到的橫向格子寬度x的抖動范圍[-2, 4]讓字符略微越界模擬真實排版里的擠壓fill取0~90的深色而不是純黑是因為純黑在二值化之后對比過強模型會過度依賴筆畫粗細這個捷徑特征。噪點密度0.005是我試下來比較平衡的值提到0.02之后整串準確率會掉但單字符準確率還在說明模型開始靠猜。生成完記得寫標注文件路徑和標簽用制表符隔開一次寫一行訓練集和驗證集用不同的隨機種子分開生成——這一步是很多人的翻車點同一個種子生成兩批圖驗證集里混進和訓練集幾乎一模一樣的樣本準確率虛高得嚇人。3.2 預處理流水線灰度、去噪、歸一化與尺寸統(tǒng)一預處理的目標只有一個讓訓練和推理走完全相同的代碼路徑。dataset.py里這段是核心# data/dataset.py 預處理 張量化訓練和推理共用 import cv2 import torch from torch.utils.data import Dataset class CaptchaDataset(Dataset): def __init__(self, list_file, char2idx, img_w160, img_h60): self.items [] with open(list_file, encodingutf-8) as f: for line in f: path, label line.rstrip(\n).split(\t) if len(label) ! 4: # 長度對不上直接丟掉別讓它污染訓練 continue self.items.append((path, label)) self.char2idx char2idx self.img_w, self.img_h img_w, img_h def __len__(self): return len(self.items) def __getitem__(self, idx): path, label self.items[idx] img cv2.imread(path, cv2.IMREAD_GRAYSCALE) # 單通道省顯存也省參數(shù) if img is None: raise FileNotFoundError(path) img cv2.resize(img, (self.img_w, self.img_h), interpolationcv2.INTER_AREA) img cv2.medianBlur(img, 3) # 3x3 中值濾波壓椒鹽噪點 img img.astype(float32) / 255.0 # 歸一到 0~1 img (img - 0.5) / 0.5 # 拉到 -1~1 tensor torch.from_numpy(img).unsqueeze(0) # (1, H, W) target torch.tensor([self.char2idx[c] for c in label], dtypetorch.long) return tensor, target邏輯說明先 resize 再濾波是有講究的先濾波再 resize 會讓噪點在插值時被拉伸成條狀反而更難去掉。INTER_AREA用于縮小是最不容易產(chǎn)生摩爾紋的插值方式換成INTER_LINEAR在 160 寬度下問題不大但換成INTER_CUBIC會引入振鈴邊緣出現(xiàn)假的筆畫。參數(shù)說明medianBlur的核大小必須是奇數(shù)且大于 13 是最小有效值5 會開始吃掉細筆畫。歸一化用(x - 0.5) / 0.5拉到[-1, 1]配合 BatchNorm 收斂更快如果網(wǎng)絡里全是 ReLU 而沒有 BN用[0, 1]也能跑差別不大但別兩套混用。DataLoader那邊兩個參數(shù)值得調(diào)from torch.utils.data import DataLoader train_loader DataLoader( CaptchaDataset(data/train.txt, CHAR2IDX), batch_size64, shuffleTrue, num_workers4, pin_memoryTrue, drop_lastTrue, # 最后一批不足 batch_size 時丟掉 )drop_lastTrue在 BatchNorm 上很關鍵。最后一批如果只剩 1 張圖BN 在單個樣本上算方差結果接近 0反向傳播時對這兩層參數(shù)的影響是災難性的表現(xiàn)出來就是「每個 epoch 最后 loss 尖刺一下」。我見過有人為此把學習率砍半其實是數(shù)據(jù)加載的問題。num_workers4在機械硬盤上開太高反而更慢開了pin_memory才真正省下主機到顯存的那段拷貝時間。3.3 數(shù)據(jù)增強的邊界能加什么不能加什么字符識別的增強比自然圖像窄得多?？梢约虞p微旋轉±3 度、小幅平移±5%、對比度抖動、隨機加噪點。不能加水平翻轉字符會變成鏡像、大角度旋轉超出手寫體常識、隨機裁剪會切掉字符。import random def augment(img): # 只在訓練集上調(diào)用驗證集和推理一律走原圖 if random.random() 0.3: img cv2.convertScaleAbs(img, alpharandom.uniform(0.8, 1.2), betarandom.randint(-20, 20)) if random.random() 0.2: h, w img.shape[:2] M cv2.getRotationMatrix2D((w / 2, h / 2), random.uniform(-3, 3), 1.0) img cv2.warpAffine(img, M, (w, h), borderValue255) return img增強函數(shù)里最忌諱的是「訓練加了、驗證也加了」。驗證集的唯一職責是反映真實分布一旦對它做隨機變換準確率曲線就失去了參考價值你根本不知道模型是在進步還是在適應增強。這條我在自己項目里定成硬規(guī)則augment只在trainTrue的分支里調(diào)用。4. 網(wǎng)絡與訓練CNN 逐位分類頭的完整實現(xiàn)前面鋪墊的數(shù)據(jù)和結構到這里收口。這一章拆三段代碼網(wǎng)絡定義、訓練循環(huán)、推理解碼每一段都能直接抄進自己的項目改。4.1 CNN 主干與逐位分類頭網(wǎng)絡結構上沒有花活四段卷積加兩層全連接重點是最后一層的形狀處理。# models/cnn.py import torch.nn as nn class CaptchaCNN(nn.Module): def __init__(self, num_classes, max_len4): super().__init__() self.max_len max_len self.features nn.Sequential( nn.Conv2d(1, 32, 3, padding1), nn.BatchNorm2d(32), nn.ReLU(inplaceTrue), nn.MaxPool2d(2), # 60x160 - 30x80 nn.Conv2d(32, 64, 3, padding1), nn.BatchNorm2d(64), nn.ReLU(inplaceTrue), nn.MaxPool2d(2), # - 15x40 nn.Conv2d(64, 128, 3, padding1), nn.BatchNorm2d(128), nn.ReLU(inplaceTrue), nn.MaxPool2d(2), # - 7x20 nn.Conv2d(128, 128, 3, padding1), nn.BatchNorm2d(128), nn.ReLU(inplaceTrue), nn.MaxPool2d((3, 2)), # - 2x10 ) self.head nn.Sequential( nn.Flatten(), nn.Linear(128 * 2 * 10, 512), nn.ReLU(inplaceTrue), nn.Dropout(0.3), nn.Linear(512, max_len * num_classes), ) def forward(self, x): x self.features(x) x self.head(x) # 關鍵一步把一維輸出拆回 (batch, 字符位置, 類別) return x.view(-1, self.max_len, self.num_classes)邏輯說明四次池化把空間維度壓到2×10Flatten后的長度是 2560接 512 維隱層。最后的view是整個設計的樞紐——如果不拆模型輸出是個 144 維向量沒法逐位算交叉熵拆開之后logits[:, i, :]就是第 i 個字符位置的分類分布損失可以直接逐位相加。參數(shù)說明Dropout(0.3)放在兩層全連接之間字符識別這種小數(shù)據(jù)集上 0.3 到 0.5 都試過0.5 會欠擬合0.3 比較穩(wěn)。最后一個池化用(3, 2)是為了把 7 壓成 2、20 壓成 10非對稱池化在這種寬扁輸入上比強行方形池化更合理。num_classes傳NUM_CLASSES含 blankmax_len傳MAX_LEN兩個都從config.py來。還有一點容易忽略輸入必須是(B, 1, H, W)且 H、W 和訓練時完全一致。動態(tài)尺寸的網(wǎng)絡不是不能寫但全連接層會立刻鎖死尺寸后面改圖片寬高就得重訓所以一開始統(tǒng)一到 60×160 是省事的做法。4.2 訓練循環(huán)損失、優(yōu)化器和學習率調(diào)度訓練循環(huán)里最值得講的是損失怎么算以及為什么必須做梯度裁剪。# train.py節(jié)選 import torch import torch.nn.functional as F def train_one_epoch(model, loader, optimizer, device): model.train() loss_sum, char_correct, char_total 0.0, 0, 0 for imgs, targets in loader: imgs, targets imgs.to(device), targets.to(device) logits model(imgs) # (B, L, C) # 逐位交叉熵取平均 loss 0.0 for i in range(model.max_len): loss loss F.cross_entropy(logits[:, i, :], targets[:, i]) loss loss / model.max_len optimizer.zero_grad() loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm5.0) optimizer.step() loss_sum loss.item() * imgs.size(0) char_correct (logits.argmax(-1) targets).sum().item() char_total targets.numel() return loss_sum / len(loader.dataset), char_correct / char_total邏輯說明F.cross_entropy內(nèi)部已經(jīng)做了log_softmax加負對數(shù)似然不要在它前面再手動過一遍 softmax否則等于算了兩遍梯度會被壓扁到幾乎不動。逐位求和再除以max_len而不是直接相加是為了讓損失量級和單個分類任務對齊學習率不用跟著字符長度重新調(diào)。參數(shù)說明clip_grad_norm_的max_norm5.0是經(jīng)驗值字符識別里梯度爆炸大多來自 BatchNorm 在小 batch 上的方差抖動裁剪能擋住絕大部分尖刺。訓練循環(huán)外配套調(diào)度器optimizer torch.optim.Adam(model.parameters(), lr1e-3, weight_decay1e-4) scheduler torch.optim.lr_scheduler.ReduceLROnPlateau( optimizer, modemax, factor0.5, patience3 ) # 每個 epoch 結束用驗證集整串準確率驅動 scheduler.step(val_acc)patience3表示連續(xù) 3 個 epoch 驗證準確率不漲就把學習率砍半。這個策略比固定步長衰減更適合小數(shù)據(jù)集因為收斂曲線經(jīng)常是階梯式的卡住三個 epoch 之后往往還能再上一個臺階。weight_decay1e-4對 Adam 來說相當于 L2 正則在三千張左右的訓練集上能明顯壓住過擬合。驗證函數(shù)里我只算兩個指標——整串準確率和單字符準確率torch.no_grad() def evaluate(model, loader, device): model.eval() full_ok, full_total 0, 0 char_ok, char_total 0, 0 for imgs, targets in loader: imgs, targets imgs.to(device), targets.to(device) pred model(imgs).argmax(-1) # (B, L) full_ok (pred targets).all(dim1).sum().item() full_total imgs.size(0) char_ok (pred targets).sum().item() char_total targets.numel() return full_ok / full_total, char_ok / char_total關鍵在all(dim1)只有四個位置全對才算整串正確這個指標才是業(yè)務真正關心的。單字符準確率 95% 聽起來漂亮四個字符乘起來只剩 81%整串準確率才是能拿去交付的數(shù)字。兩個指標一起看還能定位問題——單字符高、整串低說明模型在個別位置上系統(tǒng)性混淆通常是對應字符樣本不足。4.3 推理解碼把 logits 還原成字符串推理代碼短但坑集中。# predict.py節(jié)選 import cv2 import torch from charset import IDX2CHAR torch.no_grad() def predict_one(model, path, device, img_w160, img_h60): model.eval() img cv2.imread(path, cv2.IMREAD_GRAYSCALE) img cv2.resize(img, (img_w, img_h), interpolationcv2.INTER_AREA) img cv2.medianBlur(img, 3) img img.astype(float32) / 255.0 img (img - 0.5) / 0.5 x torch.from_numpy(img).unsqueeze(0).unsqueeze(0).to(device) # (1,1,H,W) ids model(x).argmax(-1)[0].cpu().tolist() return .join(IDX2CHAR[i] for i in ids)邏輯說明unsqueeze用了兩次第一次補通道維、第二次補 batch 維最后得到(1, 1, 60, 160)和訓練時DataLoader吐出來的形狀完全對齊。model.eval()不能漏它把 BatchNorm 從按 batch 統(tǒng)計切到用滑動平均值漏掉這一行單張推理時 BN 會拿自己這一張圖的方差去歸一化輸出會飄得非常離譜——這個現(xiàn)象很像「模型沒訓好」實際只是忘了切模式。參數(shù)說明img_w、img_h必須和config.py里的IMG_W、IMG_H一致建議直接從 config import 而不是寫默認值寫死默認值是遲早要出事的。IDX2CHAR從charset.py來和訓練時的CHAR2IDX同源這是保證索引不亂的根本。批量推理時把循環(huán)換成DataLoader再把join換成列表推導即可速度能快三到五倍。如果要導出 ONNX 給別的語言用torch.onnx.export的輸入形狀要寫死成(1, 1, 60, 160)動態(tài) batch 雖然支持但很多推理引擎對動態(tài)軸的處理不一致反而增加調(diào)試成本。5. 常見問題排查訓練不收斂、準確率虛高、顯存爆掉的真實踩坑下面五條是這類項目里出現(xiàn)頻率最高的問題每條按現(xiàn)象、原因、解決寫。看的時候對照自己的日志別急著改模型結構。5.1 loss 一路降到 0.1 就卡死驗證整串準確率停在 30% 左右現(xiàn)象訓練損失很漂亮前 10 個 epoch 從 4.0 掉到 0.1之后紋絲不動。驗證集整串準確率在 30% 上下徘徊單字符準確率能到 70%。原因最典型的是學習率太大導致模型掉進一個「只認部分位置」的局部解。四個位置里有三個位置猜得準第四個位置全錯整串準確率就恒定在低位。另一種可能是最后一個位置的樣本分布和前面不同——比如生成數(shù)據(jù)時第四個字符的坐標抖動范圍更小模型學到的特征沒有泛化。解決先把學習率從1e-3降到3e-4重跑看曲線形狀有沒有變化。還是卡就打印每個位置的單獨準確率定位到具體是哪個位置在拖后腿。如果確實是某個位置的問題檢查數(shù)據(jù)生成代碼里那個位置的坐標范圍、顏色范圍是不是和其他位置不一致。我遇到過一次是生成腳本里random.randint(0, 6)寫成了random.randint(0, 60)字符被抖到畫布外模型學不到任何東西。提示逐位打印準確率的代碼只有五行加上去比盲猜快得多。5.2 訓練集 99%驗證集 40%但兩批圖明明是分開生成的現(xiàn)象訓練集準確率一路飆到 99% 以上驗證集卡在 40% 不動損失曲線在兩邊分叉得越來越大。原因數(shù)據(jù)泄漏。最常見的形式是訓練集和驗證集用了同一個隨機種子生成或者生成完之后按文件順序切分導致高度相似的樣本兩邊都有。另一種隱蔽的情況是標簽寫錯——驗證集的標注文件里有一批標簽和實際圖片對不上模型輸出其實是對的評測腳本判它錯。解決先把驗證集里挑 20 張圖人眼看一遍確認標簽沒錯。然后算一下兩批圖的哈希md5重復的直接揪出來。生成腳本里訓練集和驗證集必須用不同的種子并且切分時按標簽分層抽樣別讓某個字符在驗證集里完全缺席。我一般會在切分后打印兩邊字符頻率的分布做一次比對這一步花不了一分鐘能省下幾小時的懷疑人生。5.3 換了字符集之后模型輸出固定幾個字符怎么訓都一樣現(xiàn)象把字符集從小寫字母擴到大小寫加數(shù)字重新訓練之后模型輸出永遠是0000或者aaaa。原因CHAR2IDX改了但IDX2CHAR沒同步改或者推理腳本里 import 的是另一份舊的映射表。訓練時標簽編碼用的是新表解碼用的是舊表兩邊一錯位輸出看起來就像模型啥也沒學會。解決字符映射表只能存在一個地方訓和推理都從charset.pyimport。加一個自檢函數(shù)訓練啟動時跑一遍from charset import CHARSET, CHAR2IDX, IDX2CHAR assert all(IDX2CHAR[CHAR2IDX[c]] c for c in CHARSET), 字符映射不互逆 assert len(CHARSET) len(set(CHARSET)), 字符集有重復字符第二行斷言防的是字符集里混進重復字符比如013456789里漏看了個3映射表的長度和實際類別數(shù)對不上模型最后一層維度會算錯但報錯信息很難指向根因。5.4 把 batch_size 從 64 調(diào)到 8loss 直接變成 NaN現(xiàn)象為了在顯存小的機器上跑把 batch 改小訓練幾百步之后損失變成nan之后再也回不來。原因BatchNorm 在極小 batch 上方差估計極不穩(wěn)定。batch 為 8 時每個通道只有 8 個樣本參與統(tǒng)計方差可能接近 0除下來數(shù)值爆炸反向傳播時梯度變成inf參數(shù)被污染后整個訓練崩掉。解決三條路按優(yōu)先級排。一是保持 batch 不小于 32顯存不夠就降分辨率或者減小通道數(shù)二是把 BatchNorm 換成 GroupNorm它對 batch 大小不敏感代價是收斂稍慢一點三是用梯度累積optimizer.step()每累積 4 個小 batch 調(diào)一次等效于把 batch 放大四倍但 BN 統(tǒng)計仍然是按小 batch 算的所以必須配合方案二才徹底。# 梯度累積 GroupNorm 的組合寫法 loss loss / 4 loss.backward() if step % 4 0: torch.nn.utils.clip_grad_norm_(model.parameters(), 5.0) optimizer.step() optimizer.zero_grad()5.5 訓練時準確率很好換了批圖推理結果全錯現(xiàn)象驗證集上整串準確率 90%拿幾張新生成的圖去推理輸出幾乎是隨機的。原因推理腳本的預處理和訓練不一致。常見差異包括訓練用cv2.imread讀灰度推理用 PIL 讀 RGB 再手動轉灰度兩個庫的灰度轉換系數(shù)不同訓練做了中值濾波推理忘了訓練歸一化到[-1,1]推理只除以 255。這些差異單看都微不足道疊加起來足以讓模型失效。解決把預處理抽成一個函數(shù)訓練和推理都調(diào)它。參數(shù)從同一個 config 讀別在推理腳本里寫默認值。我習慣在訓練開始前隨手存一張預處理后的中間結果到磁盤推理時拿同樣一張圖跑一遍兩張圖逐像素比對差超過 1e-6 就說明路徑不一致。這個檢查不用改任何業(yè)務代碼兩分鐘能做完。6. 二次開發(fā)換字符集、改變長、上部署的改造路徑真拿這個項目去接需求改動能落到三個地方按改動成本從低到高排。6.1 換字符集與變長輸出的具體改法換字符集是最簡單的一種。只改charset.py的CHARSET字符串和config.py的MAX_LEN然后從頭重訓。別試圖在舊權重上繼續(xù)訓類別數(shù)一變最后一層全連接的維度就變了加載權重必然報 shape 不匹配硬改strictFalse會丟掉整個分類頭等于重訓還多了個錯誤來源。字符長度不固定時把逐位分類頭換成 CTC。主干網(wǎng)絡和數(shù)據(jù)集基本不動改三處import torch.nn as nn # 1) 分類頭輸出時間步而非字符位置把最后的 view 改成 # return x.view(-1, self.num_classes, T) 然后 permute # 2) 損失換成 CTCLossblank 必須是 0 ctc nn.CTCLoss(blank0, zero_infinityTrue) log_probs model(imgs).log_softmax(2).permute(1, 0, 2) # (T, B, C) input_lengths torch.full((B,), T, dtypetorch.long) loss ctc(log_probs, targets_flat, input_lengths, target_lengths) # 3) 解碼走貪心argmax 之后去重、去 blank def greedy_decode(ids): out, prev [], -1 for i in ids: if i ! prev and i ! 0: out.append(IDX2CHAR[i]) prev i return .join(out)參數(shù)說明zero_infinityTrue是必須開的否則當某個樣本的標簽長度超過時間步 T 時損失會返回inf并污染整個 batch 的梯度。T 的大小由特征圖的寬度決定輸入 160 寬經(jīng)過四次池化剩 10 個時間步意味著標簽長度最多 10四位字符綽綽有余但如果要識別十幾位的長串就得減少池化次數(shù)或者加寬輸入。這個約束在寫網(wǎng)絡結構的時候就要算清楚訓到一半發(fā)現(xiàn) T 不夠只能推倒重來。改造前建議先用小數(shù)據(jù)集跑通整條鏈路確認識別正確再上全量。判斷標準很直接訓練 500 步之后loss應該穩(wěn)定下降到 3 以下如果一直在 8 附近晃八成是input_lengths或target_lengths傳錯了單位。6.2 落地前的驗證清單上線前我會過一遍這張表每一項都對應過真實的翻車場景。改造點涉及文件驗證方法主要風險換字符集charset.py、config.py訓練前跑互逆斷言新舊映射混用導致亂碼改圖片尺寸config.py、models/cnn.py打印 Flatten 后維度全連接層維度不匹配換 CTCmodels/cnn.py、train.py單 batch 過擬合測試時間步不足導致 inf導出 ONNXpredict.py與 PyTorch 輸出逐元素比對BN 未切 eval 模式加數(shù)據(jù)增強data/dataset.py驗證集不加增強增強污染驗證指標單 batch 過擬合測試是我最常用的手段拿 8 張圖反復訓 200 步如果損失降不到接近 0說明網(wǎng)絡容量或者數(shù)據(jù)管線有問題跟超參無關。這個測試能在十分鐘內(nèi)排掉一大半「訓練不收斂」的偽問題。從那以后我每次動數(shù)據(jù)管線都會先拿 8 張圖做一遍過擬合測試確認這條路走得通再去碰全量訓練。字符識別這行沒有玄學絕大部分「模型學不會」都是數(shù)據(jù)和預處理在背后捅刀子把這條紀律守住能省下的時間遠超想象。希望幫到你。本文還有配套的精品資源點擊獲取