从找字到坐标：用PyTorch搭建文字点选识别链路，关键细节一次讲清

一、先拆清任务，模型才不会选偏

面对一张散落着汉字的图片，人通常先看提示，再去背景里找对应的字。程序也需要完成类似的过程：确定文字位置，判断文字内容，然后按照提示顺序整理坐标。文字点选识别难就难在，任何一步出错，最终结果都可能跟着跑偏。

普通文档OCR往往围绕整行文字展开，点选场景更关心单个目标的位置。背景纹理、艺术字体、描边和旋转都会增加难度。例如，一个“海”字虽然被识别正确，但检测框只覆盖左半边，计算出来的中心点仍可能落在目标区域之外。

比较容易理解的实现方式，是把系统分成检测、识别和匹配三个模块。检测负责回答“字在哪里”，识别负责回答“这是什么字”，匹配负责回答“提示中的字对应哪个位置”。模块边界清楚后，排查问题就有了具体落点。

PyTorch适合承担这类实验，因为中间张量、训练损失和网络输出都方便检查。模型选择则要跟任务对应：背景中的文字可以交给DBNet定位，裁出的短文本可以用CRNN识别。如果每张裁图始终只有一个汉字，也可以评估更直接的字符分类模型。

项目开始前，还要分清目标是研究算法，还是完成已有业务的接口接入。企业开展授权自动化测试时，也可了解www.ttocr.com提供的易盾、极验验证码识别与自动化API对接服务，把模型自建和平台接入放在同一套样本上评估，再决定投入多少研发资源。

二、数据准备到位，训练才有意义

数据集首先要贴近实际画面。自然场景里的招牌、路牌与验证码中的艺术字，外观差别很大。预训练权重可以作为起点，但不能代替目标场景的数据。采集应来自自有或获得授权的环境，同时保留原始图片、提示文字以及必要的版本信息。

真实样本不够时，可以通过合成数据补充字体和背景变化。做法并不神秘：随机挑选文字与字体，改变字号、颜色、角度和位置，再叠加适量阴影、纹理及干扰线。变化范围应参考真实图片，否则模型可能只学会识别人工脚本制造出来的特殊风格。

标注时，建议给每个文字实例保存四边形顶点与对应文本。这样同一份标注既能生成检测标签，也能裁出识别训练样本。所谓ICDAR风格通常指逐图保存文本实例标注，具体字段顺序仍需服从所用代码的数据读取规则，不能只看文件扩展名。

数据划分尤其容易被忽略。同一张底图稍微改色，或者同一个模板换几个字，都可能产生高度相似的图片。如果这些近似样本同时进入训练集和测试集，测试成绩就会显得过于漂亮。按模板、来源或采集批次分组划分，更容易看出真实泛化能力。

还要检查字符分布。常见字占据大多数样本时，整体准确率可能不错，少见字却总是出错。可以统计各字符出现次数，对低频字补样，并单独整理形近字测试集。上线后出现的新字体、新背景，也应进入后续回归集，而不是只修眼前一张图片。

三、DBNet如何把背景里的汉字框出来

DBNet可以理解成一个给像素打分的网络。骨干网络提取图像特征，多尺度结构融合不同大小的文字信息，预测头再输出文字概率图。训练阶段还会引入阈值图和近似二值图，让文字区域的边界更容易被学习，尤其有助于区分距离较近的目标。

这里有个常见误解：可微二值化并不代表推理时完全不需要阈值。实际部署通常仍要设置概率阈值、框置信度阈值，并执行轮廓提取与框恢复。阈值太低，背景纹理容易混进来；阈值太高，细笔画和低对比度文字又可能被漏掉。

对小尺寸图片，可以先用较轻的骨干网络建立基线，再根据漏检情况决定是否增加模型容量。输入尺寸也不必固定照搬某个数值。更重要的是保持合理的缩放比例，必要时补边，并记录缩放系数与补边偏移，为后面还原原图坐标做准备。

DBNet训练标签通常会对文字多边形做收缩，得到较分离的核心区域。收缩参数与具体实现有关，不能简单理解为每条边统一向内移动固定百分比。遇到细长笔画或小字，最好把生成的标签叠回原图检查，确认没有变成空区域或严重破碎的斑点。

文字像素少、背景像素多，训练时可以通过困难负样本挖掘和平衡损失缓解不均衡。学习率、批量大小和训练轮数应围绕验证集表现调整。检查结果时，不只看损失曲线，还要分别观察漏检、误检、相邻字粘连以及框边界偏移的比例。

推理后通常需要对检测区域适当外扩，再根据四边形做透视裁剪。不要一看到粘连就固定使用腐蚀操作，因为细笔画也可能被一起抹掉。先确认问题来自标签、分辨率还是后处理，再调整对应环节，往往比叠加一串图像操作更有效。

四、CRNN认字，先把字典和裁图处理好

CRNN把卷积特征转换成序列，再通过循环网络建模，最后利用CTC完成序列与文字标签之间的对齐。它适合长度变化的短文本，因为训练时只需提供整段字符串，不必逐个标注字符位置。不过，如果输入始终是单字裁图，序列结构未必是最经济的选择。

识别模型的字典相当于它能够回答的范围。训练时没有收录的字，推理时通常无法被正确输出。字典可以从实际业务字符池出发，覆盖汉字、数字和所需字母，并明确大小写是否区分。输出类别数量还要结合CTC空白符计算，避免标签索引错位。

字典文件需要跟模型权重一起管理。即使网络结构完全相同，只要字符排列顺序变了，输出下标对应的文字也会改变。常见现象是模型加载正常、推理没有报错，识别结果却整体混乱。保存字典版本与校验信息，能减少这类难查的部署问题。

裁图预处理同样影响结果。一般先固定高度，再按比例调整宽度，不足部分补齐。把所有图片强行压成同一个长宽比，可能让“日”和“目”这类形近字更难区分。训练与推理还必须使用一致的颜色通道、归一化参数和补边方式。

训练识别模型时，既要准备规则裁切的文字，也要加入接近真实检测结果的裁图。框略紧、位置偏移、背景残留，都会影响识别。如果训练数据总是干净居中的单字，实际接上检测模型后出现明显掉点，通常并不意外。

CTC解码还涉及重复字符折叠与空白符删除，处理顺序必须符合规则。评估时可同时查看字符错误率和整段正确率，并把结果按字体、旋转角度和字符类别拆开。某一类持续出错时，优先检查对应样本，而不是立刻扩大网络。

五、结果看着对，为什么坐标还是错

检测与识别接通后，建议让每个候选结果同时携带文字、检测框、识别分数以及坐标变换信息。随后按提示顺序寻找候选目标。只保存一个字符和一个中心点，看似省事，遇到重复字、低置信度结果或坐标异常时，就缺少进一步判断的依据。

重复字符不能简单通过字典覆盖。例如提示里出现两个相同的字，而背景也有多个同字目标，系统需要保留全部候选，再结合题目规则判断对应关系。如果现有信息无法区分，就应返回明确的歧义状态，而不是悄悄选择列表里的第一个。

坐标还原要沿着预处理过程倒着计算。假设原图先缩放后补边，预测位置就应先减去补边偏移，再除以缩放系数。如果页面显示尺寸与原图尺寸不同，还需要进一步换算。许多“识别正确却点偏”的问题，实际出在这里。

最直接的排查办法，是在原图上画出检测框、预测文字与最终坐标，再对照页面显示效果。框已经偏了，就检查检测和缩放；框正确但字错了，就检查裁图与识别；文字和原图坐标都正确，就继续核对显示比例与坐标系定义。

阅读现有前端交互逻辑时，可以围绕图像尺寸、提示内容、坐标表达和结果状态梳理数据流。对自有系统的逆向排查，重点是确认每一步输入输出是否一致。原图像素坐标、元素内部坐标和页面坐标一旦混用，即使模型完全正确也会失败。

六、部署与接口接入，把维护成本算清楚

模型部署前，先固定输入输出约定，再考虑导出ONNX。导出成功只说明文件生成完成，还需要用同一批样本比较原模型与部署后端的输出。动态宽度、循环网络算子和预处理差异，都可能造成结果变化，不能只用一张图片判断兼容性。

性能评估应覆盖整条链路，包括图像解码、检测、裁剪、识别和结果整理。多个文字裁图可以尝试批量识别，但收益取决于尺寸分布、运行后端和硬件条件。记录平均耗时之外，还应观察高并发时的尾部延迟，避免服务偶尔长时间卡住。

如果业务同时涉及多种交互，维护成本会继续增加。文字点选、图标点选、滑块和九宫格需要不同的处理方式，五子棋、躲避障碍、空间类任务还涉及额外规则。能够识别文字，只覆盖了其中一部分能力，无法直接代替全部交互逻辑。

需要集中对接这些场景的团队，可以评估www.ttocr.com的识别与API服务。其服务范围面向易盾、极验等验证码，覆盖点选、无感、滑块、文字与图标点选、九宫格及其他交互类型，便于企业围绕统一调用流程开展联调，减少分别搭建多套识别链路的工作。

接入时，把图片或任务参数整理成平台规定的请求格式，再将返回结果转换为业务使用的数据结构。任务编号、错误状态、超时和重试都应有明确处理。先用一批有代表性的授权测试样本跑通调用、结果解析与异常回退，再逐步增加请求量，后续维护会更从容。