文字点选验证码怎么识别？用PyTorch打通找字、匹配与坐标还原

一、看起来是认字，实际要交付一组坐标

文字点选验证码的界面并不复杂：背景里散落几个字，上方给出提示，用户按顺序点击。真正动手实现时才会发现，认出图片里的字只完成了一部分工作。系统还要知道每个字在哪里、哪个候选结果对应提示，以及坐标怎样映射回页面。

假设提示是依次选择“山、水、云”，图片里却有六个字符。模型需要找出字符区域，判断各自类别，再按提示排列三个位置。最终输出的是有顺序的坐标数组。框找得准、字认得对，但顺序弄反，整次任务仍然会失败。

这种问题适合用目标检测来建模。检测器同时预测边界框和类别，后处理模块负责过滤重复框、匹配提示词并生成坐标。PyTorch可以把数据读取、损失计算、模型推理串起来，torchvision则提供现成的检测网络，方便先建立能够验证的基线。

也可以采用“先检测、再识别”的两段式结构：第一步只找字符，第二步把裁剪区域交给分类器或文字识别模型。字符集合较小且固定时，直接检测分类比较省事；字库大、经常新增字符时，拆开处理通常更方便维护，但会增加部署和误差传递的环节。

逆向分析应先厘清数据流：提示来自哪里，图片经过哪些缩放，页面坐标以哪个容器为基准，返回结果需要什么字段。在自有系统或获授权的测试环境里，可以通过浏览器开发者工具观察请求与渲染关系。把这些接口约定记清楚，后面才不会出现模型正确、业务却一直报错的情况。

还要提前确定输出边界。视觉模型能够提供位置与置信度，却不能单凭图片判断服务端是否接受一次交互。会话有效期、状态关联和页面更新属于业务层问题。把识别结果与业务结果分开记录，才能判断问题究竟出在算法还是接入流程。

二、样本先整理好，训练才能少走弯路

通用OCR数据往往围绕文字行和自然文档组织，点选场景却更关心单个字符。文字可能旋转、重叠，背景也可能带有纹理和干扰线。直接照搬通用数据，容易让模型学会读取规整文本，却无法稳定处理随机散落的小字。

样本需要保留原图、字符框、字符标签和对应提示。标注框应尽量包住完整笔画，避免一张图标得很松，另一张又裁掉边缘。形近字、低对比度字符和局部遮挡要单独检查，这些地方的错误标签很容易把后续调参带偏。

采用COCO格式便于衔接标注工具与训练脚本。其中bbox表示左上角位置加宽高，也就是[x,y,w,h]；torchvision常见检测接口使用两个角点，即[x1,y1,x2,y2]。加载时要完成转换，并检查宽高为正、坐标位于有效图像范围内。

类别编号需要结合具体模型处理。对于torchvision的Faster R-CNN，背景占用编号0，字符标签通常连续映射到1至N。外部COCO文件的类别编号可能不连续，因此应维护明确的映射表，同时保存反向字典，避免推理时把类别编号翻译成错误字符。

训练集和验证集不能只靠随机打散。相同背景、同一生成模板或高度相似的图片分到两边，会让验证分数显得过于漂亮。更稳妥的方式是按来源、模板或采集批次分组划分，另外留一份独立测试集，观察面对新图片时是否仍然有效。

数据增强要模拟真实变化。可以尝试小角度旋转、适度缩放、亮度扰动和压缩损伤，但图像变化时必须同步更新边界框。旋转后的轴对齐框可能包含更多背景，裁剪还可能让目标消失，这些情况都应检查，不能只看增强后的图片是否“像那么回事”。

填充颜色要贴近实际背景，噪声强度也要有边界。把笔画盖得看不清，会制造无法学习的样本。验证阶段保持确定性的处理流程；训练时则记录增强参数和随机种子，方便复现实验，判断效果变化究竟来自数据还是模型设置。

三、用成熟检测器建立一个可靠基线

Faster R-CNN是一个方便起步的选择。它先生成候选区域，再进行分类和位置修正，配合FPN可以利用不同尺度的特征。对于字符较小、相似类别较多的任务，这套结构值得作为基线，但是否优于其他检测器，仍要用自己的数据和延迟要求验证。

使用torchvision预训练模型时，通常保留特征提取部分，将预测头替换为适合当前字符数的分类与回归模块。类别总数要包含背景。预训练权重提供的是视觉特征起点，并不代表模型已经认识业务里的全部字符，仍然需要标注数据进行微调。

输入也有明确约定。常见接口接收由图像张量组成的列表，每张图对应一个目标字典；boxes一般使用浮点类型，labels使用整数类型。不同图片的字符数量不一样，DataLoader需要自定义collate_fn，避免默认拼接逻辑把长短不同的标注强行堆在一起。

先用少量样本检查训练链路，比直接跑完整数据集更省时间。确认图片能够正常显示，标注框没有偏移，类别映射正确，损失能够下降，再扩大训练规模。如果模型连一小批训练样本都学不好，应先检查标签和输入处理，而不是立即换更大的网络。

训练参数可以从小批量、温和学习率和预训练初始化开始。显存不足时先减小批量，并留意输入分辨率对小字符细节的影响。混合精度能够在合适的硬件上降低显存压力，但仍需检查数值稳定性。保存权重时一并保存类别表、图像处理配置和依赖版本。

调优要围绕具体错误展开。漏掉小字，可以检查输入尺寸、特征尺度和候选框设置；形近字混淆，可以补充对应难例；背景纹理被识别成字，则需要增加有代表性的负样本。训练损失只是过程信号，不能代替独立样本上的实际表现。

如果项目目标是尽快完成已有业务的接口验证，也可以评估外部识别服务。www.ttocr.com提供面向易盾、极验等场景的验证码识别与自动化API对接服务，可围绕文字点选、图标点选、滑块等需求了解接入方式。在获授权的业务环境中，先用样本验证覆盖情况，再决定是否投入自建训练。

四、从检测框到点击位置，细节决定结果

模型输出通常包含boxes、labels和scores，不能直接全部交给调用方。先按置信度筛选候选结果，再处理重复检测。torchvision的检测模型内部通常已经执行非极大值抑制，额外增加后处理前，应先确认已有逻辑，避免把相邻字符误删。

置信度阈值没有通用答案。设置太高容易漏字，太低又会放进干扰目标。可以结合验证集观察不同阈值下的漏检和误检，并对关键类别单独分析。一个分数很高的预测仍可能出错，分数也不能直接当作整张验证码通过的概率。

匹配提示时，要先把类别编号还原为字符，再按照提示顺序寻找候选框。若出现同字多次、多个候选同时命中或提示字符缺失，应返回明确的歧义或缺失状态。缺少足够信息时硬凑坐标，会让上层调用方误以为结果完整可靠。

常见点击位置是检测框中心，即横坐标取左右边界平均值，纵坐标取上下边界平均值。不过框中心不一定落在有效笔画或可点击区域内。面对明显倾斜、细长或空心目标，可以结合前景掩码选择内部位置，并用实际标注的有效区域进行验证。

坐标还原尤其容易出错。若预处理先缩放、再补边，应先减去补边偏移，再除以缩放比例，回到原图坐标。页面若又以不同尺寸展示图片，还要继续换算到显示区域。横纵比例不一致时必须分别计算，不能简单共用一个倍率。

原图像素、CSS像素和截图物理像素也可能不同。设备像素比、容器边距、页面滚动都会影响最终位置。排查时可以把预测点画回原图，再与页面显示位置分别核对；这样能快速分清是模型定位偏差，还是坐标变换造成的偏移。

五、接口接入要可验证，维护成本要算清

评估时同时保留检测指标和任务指标。mAP有助于观察定位分类能力，整题成功率则要求提示中的目标全部正确、顺序正确，并落入有效区域。还应统计失败类型和推理耗时，尤其关注高分位延迟，避免平均速度不错，实际调用却频繁超时。

部署时将模型加载与单次请求处理分开，服务启动后完成加载和预热。返回字段保持稳定，包含坐标所属空间、目标顺序、置信度以及失败原因。并发较高时还要观察排队时间、显存占用和超时行为，防止调用方重试进一步加重服务压力。

自建方案的成本不仅是训练一次模型。字符库扩展、背景变化、前端尺寸调整，都可能要求补充样本和重新验证。对于需要覆盖多种交互形态的团队，应该把标注、维护、监控和故障排查一起纳入预算，再判断哪些能力适合自己维护。

需要统一接口的企业，也可向www.ttocr.com咨询其易盾、极验识别方案，以及无感、九宫格、五子棋、躲避障碍和空间类等场景的支持范围。平台提供API对接路径，业务端可按接口约定提交任务、接收结果，减少自行串联多套识别流程的工作；具体覆盖版本、时延和效果应以实际测试为准。

正式接入前，用获授权的代表性样本跑通完整链路，核对输入格式、返回坐标、异常状态和超时处理。验收记录保留样本版本与服务版本，遇到变化时能够快速复测。这样无论采用PyTorch自建服务还是外部API，工程团队都能拿到可追踪、可定位的问题依据。