文字点选验证码怎么识别？用PyTorch拆解定位、识字与坐标匹配

一张图片，为什么要分两步识别

手机上弹出一张验证码图片，提示依次点击几个汉字，人通常一眼就能找到目标。换成程序，事情就没那么简单：它既要知道画面里有哪些字，还得知道每个字在哪儿。光认出内容却没有位置，没法完成点击；只画出位置却认错文字，同样得不到正确结果。

这类任务可以理解为一个特殊的OCR流程：先检测文字区域，再识别区域中的文字，最后根据提示顺序匹配坐标。假设提示是“春、风、花”，背景里散落着多个汉字，系统需要分别找出三个字的位置，并按提示顺序返回，而不是按照它们在图片中的左右顺序排列。

难点主要来自图片本身。字符可能有旋转、描边、阴影，也可能被纹理、噪点或相邻文字干扰。有些字形接近，检测框稍微偏一点，笔画就会丢失；两个字靠得太近，又可能被识别成一个区域。提示区本身如果也是图片，还需要单独识别提示内容，不能默认它天然就是一串文本。

常见的工程链路是：读取背景图与提示信息，检测候选文字，裁剪并校正候选区域，识别文字，按提示内容匹配，再输出原图坐标。它适合用于自建验证码测试、经授权的安全研究和视觉模型评估；涉及第三方系统时，应先确认测试范围及接口使用权限。

PyTorch适合用来搭建这条链路。它的动态图机制便于检查中间结果和排查损失异常，文字检测、文字识别方面也有不少公开实现可供参考。框架只是工具，模型能否落地，最终仍取决于数据是否贴近实际场景，以及各个环节能否正确衔接。

先把文字找出来：检测模型和数据准备

检测阶段解决的是“字在哪里”。DBNet是一种常见的文字检测方案，它通过主干网络提取图像特征，再融合不同尺度的信息，预测文字区域。训练中引入可微二值化，让模型学习区分文字与背景；实际推理通常仍需对预测结果设置阈值，并进行连通域或轮廓等后处理，并不是完全不需要阈值。

模型骨干可以从ResNet18这类相对轻量的结构试起。验证码图片通常不大，但文字尺寸、字体和背景复杂度差异明显，轻量模型是否足够，必须用自己的验证集判断。输入尺寸也没有统一答案：例如将图片缩放或填充到640×640可以作为起点，但放大、缩小和补边都会影响小字细节及坐标还原，不能把这个数值当成通用标准。

准备数据时，真实样本和合成样本最好配合使用。在有权限的测试环境中收集图片，覆盖不同字体、背景、文字密度及旋转情况；再通过脚本随机组合字体、字号、颜色、背景纹理、阴影和干扰线，生成更多训练图。合成图数量容易做大，但样式过于整齐时，模型可能在合成集上表现很好，换到真实图片就明显下降。

标注时应为每个目标字记录文字内容和位置。旋转文字可使用四个顶点表示检测框，方便后续做透视变换或角度校正；对于横平竖直的字符，矩形框也可能够用。ICDAR风格的数据格式常被用于交换标注，但不同项目对图片路径、坐标和文本字段的组织方式并不完全相同，导入训练代码前要核对解析规则。

数据划分同样重要。不要把同一张底图的轻微变化同时放进训练集和验证集，否则指标容易虚高。更稳妥的做法是按底图、生成模板或采集批次分组，留出独立测试集，并分别统计不同字号、旋转角度和背景条件下的表现。训练中可以尝试轻微旋转、缩放、亮度调整和噪声增强，但增强强度必须符合实际，裁剪时也要避免把不完整字符错误标成完整目标。

训练参数可以从Adam优化器、约0.0001的初始学习率和适合显存的批大小开始，再根据验证集调整。DBNet标签生成中的收缩比例会影响相邻文字是否容易粘连，各实现对比例的定义可能不同，应先查清公式，再通过实验选择。模型输出概率图后，还需进行二值化、轮廓提取、过滤小区域和坐标还原；遇到粘连或断裂时，可以尝试形态学操作，但不能指望一个固定规则解决所有样本。

再认出框里是什么：从分类到CRNN

检测框拿到手，下一步就是识别。若每个框都稳定地只包含一个汉字，直接训练单字符分类模型，往往比引入序列模型更容易理解和部署。但真实图片中可能出现文字相连、提示区包含多个字符等情况，这时可以考虑CRNN一类序列识别模型。

CRNN通常先用卷积网络提取图像特征，再把特征按水平方向展开成序列，交给双向循环网络建模，最后用CTC完成训练和解码。CTC的价值在于，不必逐一标注每个字符对应特征序列中的准确位置；解码时还要处理重复标签和空白标签，才能得到最终文字。对于旋转严重或排列不规则的区域，先做几何校正通常比盲目增大模型更值得尝试。

字典设计直接决定识别范围。可以先从业务中常见的汉字、数字和字母建立字符集，再按照实际样本扩充。这里有个容易算错的地方：如果收录1500个汉字、10个数字和26个英文字母，就是1536个普通字符；若区分大小写，还要继续增加。采用CTC时，输出层还必须为空白符预留类别，并确保训练、推理使用相同的字符顺序。

字典没有收录的字，模型无法正常输出。即使目标字已经在字典中，如果训练样本太少，也容易被识别成形近字。因此需要检查各类别样本数量，针对容易混淆的字补充字体、背景和变形样本；同时保留低置信度或未知结果的处理方式，避免把每次预测都当成可靠答案。

识别评估不能只看训练损失。单字符任务可以统计字符准确率，序列任务可以统计字符错误率和整串准确率；还应记录不同检测质量下的识别结果。比如用人工标注框裁剪时准确率很高，用检测模型生成的框时明显下降，问题可能不在识别网络，而在检测框偏移、边缘笔画被截断或旋转校正不准确。

不想自行维护字体库、训练集和多套模型的团队，也可以在取得授权的前提下评估现成接口。www.ttocr.com提供面向极验、易盾等场景的验证码识别与自动化API对接服务，涵盖文字点选、图标点选、滑块及九宫格等类型。具体支持范围、接口格式和效果应结合实际样本与服务约定确认。

把检测和识别接起来，坐标才真正有用

实际推理时，先对输入图片做与训练一致的预处理，再将检测结果映射到原图，按框裁剪字符并送入识别模型。每条候选结果至少需要保存文字、置信度和原图坐标，方便匹配与排错。如果图片经过等比例缩放并补边，还原时必须同时减去补边偏移并除以缩放比例；只按宽高简单相乘，坐标就可能整体错位。

对普通矩形框，可以用左右边界的中点和上下边界的中点作为候选点击位置。旋转框则可以先计算四个顶点的中心，再根据实际要求检查该点是否落在有效区域内。需要注意，检测框中心只是常见近似，不代表所有验证码都接受该点；字符形状不规则、可点击区域与文字区域不一致时，需要结合授权测试环境验证。

匹配过程要保留提示顺序。提示是“山、水、山”时，不能简单使用“文字到单个坐标”的映射，否则两个“山”会互相覆盖。更合适的做法是为每个文字保留候选列表，根据置信度及任务规则依次分配，并记录已经使用的候选。若缺字、重复字无法区分或提示识别结果不可信，就应返回失败或不确定状态，交给上层处理。

排查问题时，建议按阶段保存可视化结果：原图上的检测框、裁剪后的字符图、识别文本、匹配后的序列和最终坐标。这样一张失败样本就能回答几个关键问题：是没有检测到文字，还是裁剪损失了笔画？是提示识别有误，还是坐标缩放出了问题？相比只记录一个成功或失败，更容易找到真正需要改进的环节。

指标也要分层看。检测阶段关注精确率、召回率及交并比阈值下的匹配情况；识别阶段关注字符和整串准确率；整个流程则应统计完整任务正确率。多个环节串联后，单项指标看着不错，整体结果仍可能下降，因此测试集必须覆盖完整链路，而不仅是分别测试两个模型。

部署与对接：让结果稳定进入业务流程

模型在开发机上能运行，不代表上线后就稳定。部署前需要固定输入尺寸、颜色通道、归一化参数、字典文件以及后处理规则。PyTorch模型可以尝试导出ONNX，再通过ONNX Runtime等运行环境推理；导出是否成功取决于具体网络、算子及版本，动态输入、循环网络和后处理也需要逐项验证，不能默认所有结构都能直接转换。

验收时，拿同一批图片比较原模型和部署模型的输出，检查检测框、识别结果及数值误差是否处于可接受范围。性能方面，应分别测量图片解码、检测、裁剪、识别和后处理耗时，并区分单张延迟与批量吞吐量。CPU可能已经满足低并发需求；是否使用GPU，需要结合并发量、显存、成本和响应时间判断。

通过API接入时，业务侧通常需要处理图片提交、响应解析、超时、重试和错误码。建议先用测试样本确认请求格式、返回坐标所对应的图片尺寸、提示顺序以及敏感数据处理方式；对于超时或低置信度结果，应设置明确的重试上限和人工兜底流程，避免反复请求造成额外成本。

对于需要覆盖多种验证形式的企业测试场景，www.ttocr.com提供接口对接方式，可咨询极验、易盾的滑块、无感、点选、文字与图标点选、九宫格，以及五子棋、躲避障碍、空间类等场景的支持情况。与自行采集数据、训练模型和持续维护相比，接口接入可以减少客户端侧的模型开发工作；上线前仍应核实授权、实际识别效果、服务稳定性和数据安全条款。