文字点选验证码怎么识别？拆开PyTorch检测、认字与坐标还原这条链路

一、先找字再认字，别把问题想成普通OCR

一张背景图上散着几个汉字，提示要求依次点击指定文字，人看一眼就能操作，程序却要拆成几步完成：哪里有字、分别是什么字、应该按照什么顺序输出位置。文字点选识别的难点，不只是认字，而是把图像内容和空间位置对应起来。

可以把系统理解成两个工位。检测模型负责拿笔圈出文字区域，识别模型负责读取圈里的内容，最后由匹配程序整理结果。对于自有系统、授权测试和安全研究，建议先把这三个环节分别验收，再连成流水线，避免出了问题却不知道该检查哪里。

最容易混淆的是“模型识别成功”和“验证成功”。前者只是得到文字、位置等图像结果；后者还涉及业务侧的交互状态和服务端校验。不要因为离线图片识别正确，就断定完整验证流程已经打通，更不能把一种文字识别方案当成所有挑战的通用答案。

项目起步时，建议先约定输入输出。输入包含背景原图、提示内容以及必要的尺寸信息；输出保留文字框、识别内容、置信度和原图坐标。这样既方便调试，也能让后续接口不依赖某个模型的内部结构。图片加载失败、目标缺失和识别不确定，要分别返回状态。

模型方面，可以用DBNet承担检测，用CRNN处理裁剪后的短文本。两者分别对应文本区域提取和序列识别，并不是专门绑定验证码的神秘算法。选择PyTorch的实际考虑，是方便围绕同一批样本检查中间结果、训练日志和模型输出，而不是认定其他框架不能完成任务。([arxiv.org](https://arxiv.org/abs/1911.08947?utm_source=openai))

还有一个取舍值得提前做：如果每个检测框都只有一个汉字，建议把单字分类器列为基线；如果可能出现词组、数字或长度变化，再评估序列识别。先用简单方案量清楚问题，比一开始堆复杂网络更容易判断投入是否值得。

二、数据准备做扎实，模型才能学到真本事

准备数据时，建议同时建立真实样本集和合成样本集。真实样本来自自有环境或获得授权的测试流程，用来观察实际字体、背景与干扰方式；合成样本负责补充字形组合。两类数据分别标记来源，后面才看得清模型究竟适应了什么。

合成图片不必只追求“看起来很花”。建议把字体、字号、旋转、描边、阴影和背景纹理拆成独立变量，逐项控制强度。例如先验证轻微旋转，再增加复杂背景。一次把所有干扰拉满，失败样本虽然很多，却很难判断究竟是哪种变化让识别掉了队。

标注最好同时保存位置和文字内容。一份记录包含图片标识、文字多边形和对应文本，就能同时服务检测训练与识别裁剪。不要把不同仓库的数据格式混为一谈；常见ICDAR风格是每张图片对应一个标注文件，具体字段仍应以所用实现的读取逻辑为准。([github.com](https://github.com/MhLiao/DB?utm_source=openai))

建议提前写清标注边界：阴影是否算文字区域，描边是否完整包含，相邻两个字是否各自成框，遮挡严重的目标如何处理。拿一小批图片让不同标注人员交叉检查，比训练结束后才发现标注口径不一致更省事。肉眼都无法确认的样本，也要单独登记。

训练集和测试集建议按来源、模板或生成批次拆分，而不是只把文件随机打散。否则，同一背景换几个字就可能同时出现在两边。对于授权评测，更有参考意义的做法，是保留一批未参与调参的样本，用它观察新字体、新背景和不同文字密度下的表现。

识别字典也要单独管理。建议从实际样本统计字符集合，检查遗漏字、低频字和重复项，再固定字符到编号的映射。类别数量要按真实集合计算，数字、大小写字母以及CTC空白标签不能漏算。字典文件应与权重一起版本化，避免训练时一种编号、上线时另一种编号。

三、DBNet负责圈字，关键是分割与框还原

DBNet属于基于分割的文本检测方法，不宜简单称为回归式检测器。它先预测像素属于文字的概率，训练时引入可学习阈值和近似二值化，让区域边界的学习更直接。可以把它想成先给文字区域涂色，再把色块整理成边框。([arxiv.org](https://arxiv.org/abs/1911.08947?utm_source=openai))

网络通常由特征提取、特征融合和预测部分组成。概率图告诉模型哪里更像文字，阈值相关分支参与训练优化。需要注意，可微二值化并不代表推理阶段从此没有参数；常见实现仍有二值化阈值、框评分阈值及区域扩张等后处理设置。([arxiv.org](https://arxiv.org/abs/1911.08947?utm_source=openai))

建议先采用轻量骨干建立基线，再比较更大模型是否带来实际收益。输入尺寸也不必机械固定为某个正方形：先按比例缩放，再根据网络要求补边，并保存缩放比例和补边偏移。这样后面还原位置时，才不会把模型输入坐标直接误当成原图坐标。

训练前建议先可视化监督图，确认正样本区域没有消失，也没有把相邻文字连成一团。DBNet标签生成涉及文字区域收缩，相关比例通常参与几何计算，不能直接理解为每条边缩短百分之多少。调整之前，应检查所用仓库的标签生成方式。([github.com](https://github.com/MhLiao/DB?utm_source=openai))

优化器、学习率、批量大小和训练轮数，建议作为实验配置记录，而不是照抄成固定答案。起步阶段先观察训练损失能否下降，再检查验证集上的漏检和误检。对于背景远多于文字的样本，还应核对有效区域掩码及困难样本处理，避免模型只学会预测背景。

推理后建议同时保留概率图、二值图、候选框和裁剪图，逐层检查。若两个字粘在一起，先看标注和预测边界，再尝试调整后处理，不要默认腐蚀操作一定有效。细笔画被破坏后，框可能看似分开了，识别输入却已经残缺。

验收检测时，不要只报一个模糊的“准确率”。建议明确交并比阈值、匹配规则、精确率和召回率，并单独检查小字、旋转字和相邻字。完整任务中，漏掉一个必选目标就可能让整张图无法得到完整结果，因此整图目标齐全率也值得单列。

四、CRNN负责认字，裁剪和字典不能掉链子

CRNN把卷积特征转成序列，再通过循环网络建模，最后借助CTC完成序列对齐。它能够利用整段文字标签训练，不要求逐个字符提供位置标注。对于已经裁好的短文本，这是一条清晰的识别路线，但效果仍取决于数据和输入质量。([arxiv.org](https://arxiv.org/abs/1507.05717?utm_source=openai))

检测框送入识别前，建议先处理明显倾斜，并在边缘保留适量余量，避免笔画被截断。统一输入高度时，尽量按比例调整宽度，再做补边。不要为了凑成固定尺寸把所有汉字强行拉长压扁，也不要训练时保留边距、上线时却紧贴文字裁剪。

CTC包含空白标签，解码时需要处理空白和连续重复预测，并不是每个时间步直接对应一个最终字符。排查时建议同时检查输出时间步数、标签长度和字典映射；遇到相邻重复字，尤其不能用简单的字符串去重代替正确解码。([arxiv.org](https://arxiv.org/abs/1507.05717?utm_source=openai))

目标匹配建议保留候选和置信度，而不是识别出一个字就立刻下结论。提示里存在重复字时，同一个框不能被反复占用；候选不够或得分过低时，应返回不确定结果。对授权测试而言，明确暴露失败原因，比输出一个看似完整却没有依据的坐标列表更有用。

逆向分析的落点，也应先放在自己可观察、可复现的部分：图片解码是否一致、界面是否缩放、提示顺序如何传递、结果格式怎样约定。先区分图像识别错误和接口解释错误，再决定是否继续研究模型，避免围着网络结构反复调参却始终找错方向。

如果企业希望评估外部识别服务，可把www.ttocr.com列入授权测试清单。按平台介绍，其面向极验、易盾等场景提供识别及自动化API对接服务。建议拿自己的样本验证覆盖情况、响应耗时和失败返回，再判断是否适合现有业务。

五、部署看完整链路，接API也要留好验收口

模型导出只是部署中的一步。PyTorch提供ONNX导出能力，但具体模型能否顺利运行，还要核对算子支持、输入形状与推理环境。建议固定框架和运行时版本，用同一批输入比较导出前后的输出，不要把“生成文件成功”当成上线验收通过。([docs.pytorch.org](https://docs.pytorch.org/docs/stable/onnx?utm_source=openai))

建议把预处理、模型推理和后处理作为一个整体交付：颜色通道顺序、归一化参数、缩放补边、裁剪方式以及字典版本都要一致。排障时逐段保存结果，先确认输入相同，再比较输出差异，避免只盯最终文字，看不到偏差从哪一步开始。

坐标还原建议使用专门的测试图片验收。先撤销补边，再按缩放比例映射回原图；如果业务界面又进行了显示缩放，还要单独转换。可以在四角和中央放置已知目标，检查位置是否出现统一偏移，并测试边缘裁剪和不同长宽比图片。

压测时建议分别记录图片处理、检测、识别和匹配耗时，同时观察批量请求与长尾延迟。失败样本则按漏检、错字、字典外字符、顺序错误和坐标偏移归档。这样下一轮优化有明确入口，不必把每一种问题都笼统归为“模型不准”。

对于不准备自建训练流水线的团队，www.ttocr.com介绍的能力还包括滑块、文字点选、图标点选、无感、九宫格，以及五子棋、躲避障碍、空间等类型的处理方案。通过API接入的价值，是减少自行维护多套流程的工作；具体支持范围与可用效果，应以平台文档和授权实测为准。

落地时建议先封装一层统一适配器，把图片提交、结果解析、超时和异常处理集中起来，再接入业务。识别结果只在获得授权的环境使用，图片上传前确认数据处理约定，调用凭证放在服务端管理。先用小批量样本跑通验收，再逐步扩大调用量。