1. 先说结论：DBnet到底是“检测网络”还是“分割网络”，以及多类别检测真正要改的地方
做过一段时间OCR的人应该都清楚，绝大多数开源OCR方案里，文本检测和文本识别是两套独立模型。检测模型负责把“哪里有钱”圈出来，识别模型负责把“钱上的字”读出来。DBnet（Differentiable Binarization Network）就是检测阶段常用的一种方案，尤其在中文场景、票据、自然街景文本上表现很稳。但这里有个很容易被忽略的点：DBnet本质上是一个语义分割网络，它输出的不是“框”，而是一张和原图同等尺寸的概率图。检测框是后处理从概率图里捞出来的。
那“多类别文本检测”是什么意思？常规DBnet只回答一个问题：这个像素是不是文本。多类别版本要回答两个问题：这个像素是不是文本？如果是，它属于哪一类文本？比如“标题文字”“正文文字”“页眉页脚文字”，或者“招牌文字”“屏幕文字”“印刷文字”。这种需求在实际业务里非常常见。我做过的某个档案数字化项目里，需要把扫描件里的“标题区”和“正文区”分别检测出来，后续才能做不同的识别模型和排版还原。当时只用普通DBnet检测，拿到的是一堆无差别文本框，后面还得靠版面分析算法二次切分，非常绕。
所以多类别DBnet的改动核心，不在网络骨架，而在三个地方：输出通道数、损失函数、后处理逻辑。骨架完全可以用原来的ResNet-18或ResNet-50，FPN结构也不动。真正动刀的是分割头（segmentation head）的输出通道从原来默认的几路，改成“类别数 + 几路辅助图”的结构。
这里先解释一个误区。我见过不少开发者以为，多类别检测就是训练多个二分类检测模型，每个类别一个模型。不是不行，但工程上很蠢。首先推理速度直接翻N倍，其次多个模型之间可能出现同一个文本区域被重复检测、边界不一致的情况。合并结果时你还要写一堆空间去重逻辑。而单模型多分类分割方案，天然就能保证每个像素只有一个类别归属，检测框和类别是绑定的，省掉一整套后处理麻烦。
另外一个需要注意的点是DBnet的“可微分二值化”。这个机制是整个算法性能的关键。普通分割网络做完分割之后，需要用一个固定阈值把概率图二值化，这个操作不可导，所以阈值只能靠经验调，比如设成0.3还是0.4，每换一个数据集就要重新试。DBnet在分割头里额外预测了一张“阈值图”（threshold map），然后通过一个可微分的近似二值化公式把概率图和阈值图结合，这样训练的时候阈值也在被网络学习，模型对低对比度、模糊边界的文本区域更鲁棒。多类别版本里，这个阈值图依然保留，它只负责区分“文本/背景”，不负责区分具体类别。类别信息完全由概率图的通道维度来承载。
明白了这一层，后面所有改动都顺理成章了。
2. 数据准备工作：从“一个框一个类”到“逐像素类别掩码”的标签改造
训练多类别DBnet，第一件让我头疼的事就是标签格式。常规检测数据的标注是一个多边形加一个文本字符串，比如：
{"transcription": "某某银行", "points": [[x1,y1],[x2,y2],...]}这种格式对DBnet来说不够用。DBnet是分割网络，它要求的标签是一张和原图尺寸一致的单通道掩码图（mask），前景像素为1，背景为0。多类别版本则要求掩码里每个前景像素再带上类别ID。所以你要做的事情是：把多边形的标注，栅格化成逐像素的类别分配。
具体做法上，我拆成了五个步骤：
- 把多边形的类别名称映射成整数ID。比如“标题”=1，“正文”=2，“页眉”=3。
- 新建一张全零的掩码图，尺寸和原图一致。
- 遍历标注，对每个多边形用
cv2.fillPoly填充对应类别ID。 - 同一个像素被两个不同类别的多边形覆盖时，后画的覆盖先画的，或者根据类别优先级手动指定。
- 保存为单通道PNG文件，不要用JPEG，JPEG压缩会在边缘产生伪影，导致训练时类别边界噪声。
这一步别小看，它直接决定了最终模型的上限。我在第一次做的时候偷懒，直接用开源脚本从json标签生成掩码，结果忽略了步骤4的冲突处理。有一个样本里，“标题”和“正文”两个多边形挨得很近，边缘有几像素重叠，生成出来的掩码那个位置类别值是后画的类别，但原图那里其实是两个区域的分界线。训练出来的模型在那几类边界上总是抖动，检测框歪歪扭扭，后来查了半天才发现是标签问题，一直以为是网络收敛不好。
这里分享一个我在实际项目中用下来的标签增强技巧：对掩码做轻微的形态学腐蚀。原因是DBnet训练时，在真实文本边界附近会给“概率图”的标签做一个收缩处理（shrink），因为太靠近边界的位置，到底是前景还是背景本身就存在歧义，直接喂二值标签会让网络在边界上无所适从。DBnet官方实现里对原始多边形做了Vatti clipping算法收缩，多类别掩码也要做同样处理。所以你要生成的不是一张严格的掩码，而是一张“收缩过的前景掩码”。收缩幅度一般用偏移量shrink_ratio控制，常用的做法是让收缩后区域占原多边形面积的某个比例，比如0.4。在代码里可以直接调用pyclipper库实现：
import pyclipper def shrink_polygon(points, shrink_ratio=0.4): poly = pyclipper.scale_to_clipper(points) offset = pyclipper.PyclipperOffset() offset.AddPath(poly, pyclipper.JT_ROUND, pyclipper.ET_CLOSEDPOLYGON) # 负值表示收缩，尺度需按缩放比例换算 scaled_offset = -shrink_ratio * pyclipper.Area(poly) ** 0.5 shrunk = offset.Execute(scaled_offset) return [pyclipper.scale_from_clipper(p) for p in shrunk[0]]如果你用的是PyTorch全套，这一层预处理建议走离线脚本，提前把所有训练样本的掩码生成好存盘，不要放到Dataset类的__getitem__里实时算。原因有两个：第一，实时算多边形栅格化会让训练DataLoader成为性能瓶颈；第二，标签生成过程如果包含随机操作，不方便复现，出错也不好排查。离线生成好，训练时只管读图，出了什么问题直接看存盘文件。
类别不平衡是另一个大坑。我的项目里“正文”类别占了全部文本像素的约80%，“标题”可能只有10%，“页眉”更少。直接训练，模型会把所有文本都预测成“正文”。后面我的处理方式是给损失函数加上类别权重，这个在下一节详细说。但这里提前提醒：你必须在数据准备阶段就统计各类别的像素占比，这个数据在设定损失权重时是必需的。
3. 模型结构改动：输出头怎么加通道，损失函数怎么从二分割切到多类
网络结构改动其实不复杂，难的是把每个改动点的“为什么”讲清楚。
常规DBnet的分割头会输出三个分支：概率图（probability map）、阈值图（threshold map）、二值图（binary map）。在官方实现里，这三个分支共享同一组特征，最后通过nn.Conv2d(inner_channels, 1, ...)各自输出单通道图。多类别版本要把概率图从单通道改成多通道：每一路代表一个类别的文本概率。比如3个文本类别，概率图就是3通道。阈值图和二值图仍然是单通道，因为“文本/背景”这件事和“哪个类别”是正交的。
具体实现上，我是这样改的。首先定义一个类别数参数：
num_classes = 3 # 背景不算，这里只算前景类别数然后在分割头的__init__里：
self.prob_map_conv = nn.Conv2d(inner_channels, num_classes, kernel_size=3, padding=1) self.thresh_map_conv = nn.Conv2d(inner_channels, 1, kernel_size=3, padding=1) # binary map 的卷积仍然输出单通道 self.binary_map_conv = nn.Conv2d(inner_channels, 1, kernel_size=3, padding=1)注意，binary_map在训练时是辅助监督，它用概率图和阈值图通过可微二值化公式算出来，目的是帮助网络在阈值学习上更稳定；推理时真正用的是概率图。多类别版本里，binary_map不再承担分类任务，它只约束“这个像素是否属于任意文本类别的概率”。所以它的监督标签就是普通的二值掩码（前景任意类别=1，背景=0），仍然用BCE loss。
接下来是损失函数，这是多类别改造里最重要的部分。DBnet原版的损失函数是三部分之和：
L = L_prob + L_thresh + α * L_binaryL_prob和L_binary都用BCE loss，L_thresh用的是预测阈值图和标签阈值图之间绝对差的L1 loss。多类别版本里，L_prob要从BCE改成带权重/带类别信息的损失。我选用的方案是：L_prob = cross_entropy_loss(pred_prob_map, gt_mask)，其中gt_mask的每个像素值取值范围是0到num_classes（0是背景）。同时把类别权重传进去：
ce_loss = nn.CrossEntropyLoss(weight=class_weight_tensor)class_weight_tensor怎么定？我在前一个项目里用的是“逆频率开根号”的经验公式。先统计训练集里每类像素数量n_c（背景也算一类），然后：
w_c = sqrt(total_pixels / (num_classes * n_c))这样做的效果是：像素占比越低的类别，权重越高，但不至于高到把背景都带偏。注意背景类别的n_0通常是巨大的，算出的权重会很小，这其实是好事，让模型更关注前景区域的分类正确性。有一次我把权重算错了，背景权重给得过高，模型把所有像素都预测成背景，检测结果直接为空，损失看起来却还在下降。调试了很久才发现是权重列表的顺序和类别ID对不上。
阈值图的标签生成，在原版实现里是基于收缩多边形和原始多边形的边界区域做插值生成的。多类别版本不需要给阈值图区分类别，直接复用原版逻辑就行。这里阈值图的作用是帮助网络在文本边界附近形成更锐利的预测，它和分类任务没有耦合，所以改动最小。
训练过程中，我建议前几个epoch先把L_binary的权重α调低一些，比如0.1甚至0。原因是多类别分割刚开始收敛很慢，概率图还没学会区分类别，这时候binary分支的梯度会拖慢分类分支的学习。等训练一段时间后，再把α恢复到默认的1.0。这个经验是在一次训练震荡严重时摸索出来的，后面会细说。
4. 推理端后处理：从概率图到“带类别的检测框”的完整链路
训练好模型之后，拿到一张输入图，前向传播得到三样东西：多通道概率图（B, num_classes, H, W）、单通道阈值图、单通道二值图。接下来怎么做后处理，这是决定最终检测效果的关键环节。
我的推理链路分四步，每一步都有讲究。
第一步，对概率图做argmax，得到每个像素的类别索引。这一步把num_classes通道压缩成一张单通道的类别图。但直接全局argmax有个隐患：如果一个像素在所有类别上的概率都很低（比如都是0.1），argmax仍然会强行给它指定一个类别。为了解决这个问题，我加了一个“可信度门槛”：
max_prob, pred_cls = prob_map.max(dim=1, keepdim=True) pred_mask = (max_prob > 0.5).float() * pred_cls.float()这里阈值0.5是经验值，如果召回不够就调低到0.4，精度不够就调高到0.6。本质是：只有在某个类别概率超过门槛时才认定该像素属于该类别，否则视为背景。
第二步，对每个类别单独做连通域分析。为什么要按类别分开做？因为不同类别可能紧挨着，比如扫描件里标题下方紧跟着正文，如果混在一起做连通域，两个区域会被连成一个巨大的连通域，类别信息全丢了。按类别分开后，每个连通域天然就属于同一类别。
连通域提取用的是cv2.connectedComponentsWithStats。这一步同时能拿到每个连通域的面积和最小外接矩形，面积小于某个阈值的连通域直接滤掉。面积阈值我一般设成图片尺寸万分之一左右，太小了基本都是噪声。这一步在大图上的效果尤其明显，因为大图上经常有零散的小噪点被误检成文本。
第三步，把每个连通域的像素集合转成检测框。工程上最省事的方式是取连通域像素的最小外接矩形（cv2.minAreaRect）。但这里有个细节：如果两个类别区域靠得太近，矩形会互相重叠。我在处理票据项目时遇到过“标题”和“正文”的框叠在一起，导致后续版面还原时标题和正文互相粘连。解决办法是：对每个连通域先做一次形态学膨胀，再做矩形拟合，让框尽量贴合连通域的实际形状。膨胀核大小用3x3，效果比较温和。
contours, _ = cv2.findContours(mask.astype(np.uint8), cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) for cnt in contours: if cv2.contourArea(cnt) < min_area: continue rect = cv2.minAreaRect(cnt) box = cv2.boxPoints(rect)第四步，同一个连通域的类别归属做“投票确认”。虽然连通域已经是从某类通道里提取的，但实际运行中，一个连通域内部可能有少量像素被argmax分到其他类别（主要是边界噪声）。所以我用scipy.ndimage.label或直接用类别图的众数来修正整个连通域的类别。这一步看起来多余，但在类别颜色相近（比如深红标题和黑色正文）、光照不均的图片上，它能把小片段噪声统一回主类别，让我少写不少后处理纠错逻辑。
还有一个多类别场景特有的问题：一个物理区域只允许一个类别，但一个连通域横跨了两个类别区域。这种情况在语义分割输出里偶尔出现，原因是预测概率图在两个类别间形成了“桥”。我的策略是优先相信面积大的类别，把整个连通域归到大面积类别名下，框用整个连通域的外接矩形。如果两个类别面积非常接近，则把连通域沿类别边界切分成两个框。这个切分逻辑我写在工程代码里了，但实际触发频率不高，大部分情况下直接归一大类就行。
推理速度方面，多类别比单类别增加的耗时主要在连通域分析上，每多一个类别就要多遍历一次Mask。我实测下来，一张1080p的图片，3类文本检测的推理时间大概比单类别多出15%到20%，主要时间都花在connectedComponentsWithStats上。如果对性能敏感，可以改成只对max_prob > threshold的综合前景Mask做一次连通域分析，再在每个连通域内部统计类别，速度会快很多，代价是“域内部有两个类别”时逻辑稍复杂。
5. 踩坑实录：多类别DBnet训练中我遇到的最麻烦的几个问题
讲完主流程，这部分是我最想写的，因为训练多类别DBnet的过程踩了不少坑，而且这些问题在单类别训练时基本碰不到。
第一个坑是训练初期概率图损失震荡。我在前面提到过，训练最开始我把binary branch的权重α调低才稳定下来。具体现象是：前几个epoch训练损失曲线上下跳动幅度很大，尤其L_prob部分，像锯齿一样。排查后我认为原因是：多类别交叉熵在类别分布极不均匀时梯度不稳定，背景类像素数量过多，主导了梯度方向。单独做数据层面处理不够，加上α调低之后，模型先专注学习“哪里是文本”，再学习“文本中哪一类”，相当于把两个任务解耦了，训练一下就平滑了。训练中期（大概总epoch的30%之后）再把α拉回1.0，不会出现反复。
第二个坑是“类别消失”。训练到中途，有一次我评估验证集，发现“页眉”类别的召回率直接从上次的60%掉到了0%。看预测结果，模型把所有页眉区域都预测成了“正文”。排查路径如下：先确认验证集标签有没有问题，没有；再看训练日志里每个类别的损失值，发现“页眉”类别对应的损失值一直比其他类别高一个数量级；最后检查训练样本分布，发现某次切分数据集时，“页眉”样本恰好被全部分到训练集的一部分，某几个batch里完全没有“页眉”样本。模型长时间看不到某类样本，就会慢慢遗忘它。这个问题靠设置类别权重能缓解，但根本解法是打乱训练数据时做类别索引的分层采样，让每个step/epoch里每类样本都至少出现几次。我当时改成按“是否包含页眉样本”做分组采样后，问题就没再出现过。
第三个坑是阈值图退化。多类别训练里，如果损失把关不严，阈值图分支会逐渐退化成一个几乎全零的平面。我在训练中期发现二值图输出变得非常模糊，边界不锐利，检测框全往外扩了一圈。原因是多类别交叉熵的回传梯度主要影响概率图分支，阈值分支收到的梯度相对较弱，网络优化的重点会偏到概率图上。解决办法是给阈值损失加一个放大系数，比如把L_thresh乘上10再参与总损失。这个做法没有理论依据，纯粹是实测中试出来的，但效果很直接，阈值图的数值分布立刻恢复正常。
第四个坑是“类别名称和检测框输出不匹配”的工程问题。训练时类别顺序是["背景","标题","正文","页眉"]，推理后处理里，我写了一个类别ID到名称的映射表。后来调整了训练数据，把“页眉”和“页脚”合并成一类，但映射表忘了更新，导致所有页眉框输出了错误标签。这种低级错误在改动频繁的项目里非常容易发生，我后来把类别的定义和映射统一放在一个配置文件里，训练脚本和推理脚本共用一份，同时任何一次类别定义变更都强制触发版本号更新。工程规范确实能省不少这种完全跟算法无关的调试时间。
第五个坑是和多尺度推理相关的。DBnet在检测大文本时，如果直接整图推理，小字体区域经常被漏检。多类别版本里这个现象也没什么不同，只是更隐蔽：小字漏检后，由于后处理是按类别分别做连通域的，漏检不会影响其他类别，但是整个版面最终输出的框数量明显变少。我做的是两阶段推理：先用原图跑一遍，如果遇到检测框过多或过少的情况，再对图像做0.5倍、1.0倍、1.5倍多尺度推理，把多尺度结果做一个NMS合并。多类别场景NMS有个注意点：不同类别的两个框即使IoU很高，也不能合并，因为它们的类别标签不同。所以NMS要拆成按类别分别做，或者合并时把类别一致性作为硬约束。我一开始图省事，跨类别也做NMS，结果标题框和正文框重合度高的时候被吞掉了一个，版面信息直接丢失。
另外，多类别DBnet训练时的图片增强策略和单类别也不太一样。单类别常用随机旋转、随机裁剪、颜色抖动。多类别场景下，随机旋转容易把细长文本（比如页眉）转成接近水平或垂直，类别边界上的掩码栅格化会引入噪声。我最后是强制限制旋转角度在正负10度以内，并且对颜色抖动做了更保守的设置，因为类别之间的颜色差异在某些场景（比如深红标题和黑色正文）是区分特征，颜色抖动太狠会抹平这种差异。这一点在自然场景数据集上可能不成立，但在票据、文档扫描这类版面颜色相对固定的场景，效果差别明显。
6. 实际项目里的性能调优：该换多大主干网络，以及如何量化收益
最后聊一下部署和工程选型，这部分内容在纯算法帖里经常被跳过，但实际问题往往出在这里。
我最早在某个跨平台项目里用的是ResNet-50做主干，多类别3类，训练效果好，但CPU推理速度达不到要求，一张A4扫描件跑检测要1.2秒左右。后来换了MobileNetV3做主干，速度降到0.3秒，代价是检测精度大约掉了2到3个点。对于“标题/正文/页眉”这种类别区分很明显、文字区域本身也比较规整的版面，MobileNetV3完全够用；但如果你的场景是自然街景里的小招牌文字、反光屏幕文字，建议还是保留ResNet-18以上级别的主干。
这里有一个很实用的结论：多类别数目的增加对推理耗时的影响，远小于主干网络的替换。从1类扩到4类，分割头输出通道从1到4，这部分计算量相对于整个网络来说非常小。真正的大头在特征提取层。所以如果你的需求是“检测类别多一点但不要变慢”，优先考虑轻量主干加多类输出，而不是固守原来的大主干不舍得换。
多类别DBnet部署成服务时还有一个容易踩的坑：阈值图和分类概率图的输出范围不一样。分类概率图是softmax后的，值域0到1；阈值图是网络直接回归的，值域没有硬约束，实践中大概在0.3到0.8之间。如果你直接把两张图都转成uint8存成PNG做调试，阈值图看起来会非常“亮”，容易误判成模型出错。正确的调试做法是分开做归一化再可视化，或者只可视化概率图。
从量化收益的角度看，多类别DBnet最值钱的产出不只是“多了一个类别标签”，而是给下游任务省掉了大量启发式规则。拿我处理的那个档案数字化项目来说，以前检测完还需要专门写一套版面分析逻辑——按坐标位置判断哪些框是标题、哪些是正文、哪些是页眉，规则写了上百行还总有例外。改成多类别检测后，这些规则直接删掉了大约七成，后续的识别模型也可以按类别单独优化，比如标题用更大尺度的识别模型，页眉用专门训练过的模型，准确率都有明显提升。整体流水线的维护成本，比单类别+规则方案低得多。
如果你打算在现有OCR框架里引入多类别检测，我建议的落地路径是这样：先梳理清楚业务上到底需要区分哪几类，类别数量控制在5个以内，类别之间要有明确的像素级差异（形状、位置或颜色至少占一个），不要为了“多分类”而硬造类别。然后按本文的数据处理、模型改造、损失调整、后处理四步走通一个最小demo，再用真实数据做几轮迭代。这类方案的复杂度和调试成本确实比纯检测高，但一旦稳定下来，收益非常可观。
我个人实际体会最深的是：多类别DBnet一开始会让人觉得“不就是加了几个输出通道吗”，真正做了才发现，数据标签的组织方式、损失函数的权重策略、后处理起连通域的逻辑，每一处都会跟单类别版本产生微妙但关键的差异。把这些差异踩明白，比单纯把网络跑通本身更值钱。
