如何比较验证码识别器的准确率和速度

摘要

• 在相同的验证码挑战家族、接受规则和负载条件下，对比验证码求解器的准确率和速度。
• 将被接受的挑战与 API 返回的解决方案分开统计；非空 token 不能作为准确率的度量。
• 同时报告中位数和尾部延迟，并包含失败与超时，而不是只对成功请求取平均。
• 给每个服务提供全新的、等价的挑战；单次使用的 token 不能复用来做对比捷径。
• 将首次尝试的结果与重试后的结果分开，并标明样本数量与测试周期。
• 基准方法可以指导试用，但服务排名必须建立在真实可比的测量之上。

“快”和“准”只有在背后的测量方式清晰时才有意义。某个验证码求解器可能宣传的是返回 API 响应的时间，而另一个则报告完成整个浏览器步骤的时间。成功百分比可能在统计返回的 token、被接受的挑战，或者几次尝试后完成的任务。

本指南解释如何针对你自己被许可的工作负载，对这些度量进行比较。CapSolver 是一个可以通过有文档的任务接口进行评估的服务。下文的方法并未给出实际测量的服务排行榜，也不预设哪家服务表现最佳。

在比较服务前先定义“准确率”

验证码求解准确率应描述在指定挑战类型下、在清晰声明的分母条件中得到的正确或被接受结果。

对于有标准答案的图像转文本任务，精确识别是一个有用指标。统计返回文本是否在接收应用的规则下匹配预期字符。如果应用将大小写视为有区分意义，而评估却忽略大小写，那测量的其实是另一个问题。

对于 token 任务，更有用的结果是接收应用是否接受了挑战响应。服务返回一个非空 token 只说明输出已送达，而非已被接受。Google 的 reCAPTCHA 验证指南描述了验证响应的后端检查。

保持下列三项量彼此独立：

测量项	分子	分母	回答的问题
API 解题率	返回文档所述解决方案的任务数	所有有效提交的任务数	求解器是否返回了输出？
首次尝试接受率	首次尝试即被接受的挑战数	所有计划的首次尝试数	初始结果是否奏效？
最终任务完成率	在允许尝试次数和截止时间内完成的任务数	所有计划的任务数	整个工作流是否最终完成？

格式错误的测试请求应被报告为“配置失败”。不要悄悄将其从报告中剔除，但也不要把错误站点密钥算入识别准确率。说明发布的分母是否包含配置失败，以及原因。

从命名事件出发测量速度

求解速度应在两个命名事件之间测量，使用统一时钟，并对所有服务采用相同的定义。

记录客户端提交任务的时间、收到可用解答的时间，以及观察到应用接受的时间。这些时间戳区分了 API 延迟与应用所需的额外工作。如果任务结果通过轮询获取，还要记录轮询策略：客户端注意到任务完成的时间，可能晚于服务实际完成的时间。

CapSolver 的 getTaskResult 协议对异步任务的“待处理”和“已就绪”结果进行了区分。其 ImageToTextTask 在创建任务时直接返回识别结果。不要把异步测量模型强加到同步任务上，也不要在同一速度列中比较不同类型的任务。

对成功尝试至少报告中位数和某个尾部百分位（如 p95）。中位数描述观测分布的中间位置；尾部分位数展示较慢成功尝试多花了多少时间。Google 的 SRE 延迟分布指南解释了为什么平均值会掩盖尾部行为。

同时公布超时次数和截止时间。一个服务若在少数五次尝试上快速成功，却在许多其他尝试上超时，不能仅因为把失败从延迟平均值中排除，就看起来更优。

保持挑战类型与测试条件的可比性

有用的比较应将相似挑战分组，并保持主要运行条件稳定。

将 reCAPTCHA v2、reCAPTCHA v3、Turnstile 与图像文字识别分开。每一大类内部，保留与之相关的变体和参数。某一类别的结果不能推导另一类别的表现。reCAPTCHA v2 任务文档就展示了变体相关的请求字段为何重要。

对于每一组，记录批准的环境、客户端位置、并发度、请求截止时间、轮询策略、重试允许次数和测试周期。不要给一个服务单线程请求，却给另一个服务同时发起一连串请求，然后把所有差异都归因于求解器。

使用自有的测试站点或经过明确许可的工作流来进行评估。从环境可承载的小负载开始。页面可以公开访问，并不意味着你获得了进行不受限制性能测试的许可。

给每个服务提供全新的等价挑战

等价试验需要可比的挑战条件，而不是重复使用已经完成的 token。Google 文档说明 reCAPTCHA 响应为两分钟有效期的单次使用。Cloudflare 的 Turnstile 验证参考同样要求服务端验证，并描述了 5 分钟、单次使用的 token 生命周期。

在相同、被许可的条件下规划独立试验。在可能的情况下，在整个测试周期内交替不同服务的测试顺序，而不是只在空闲时段测一个服务、在繁忙时段测另一个。先制定任务分配方案，再查看结果。

对于离线图像识别，可以使用相同的、经授权标注的图像集。对于不断变化的在线挑战，要说明可比样本是如何分配的，并承认仍然存在的变动。如果在测试期间挑战总体发生了变化，就不要声称这是完美可控的实验。

兑换你的 CapSolver 奖励码

立即提升你的自动化预算！
在为 CapSolver 账户充值时使用奖励码 CAP26，每笔充值即可额外获得 5% 奖励 —— 无上限。
立即在你的 CapSolver 控制台 中兑换

使用保留失败记录的小型结果表

基准记录应保持“每次尝试一行”，并使用稳定的任务标识符关联所有重试。

下列字段是编辑性报告模板，而非任何服务的 API 模式：

字段	记录内容
任务与尝试标识符	此次尝试属于哪一个计划中的挑战
挑战家族与变体	被比较的精确任务类别
服务与客户端版本	使用的服务及集成版本
提交与结果时间	足以计算 API 延迟的信息
接受时间与证据	若可观测，应用接受响应的时间与依据
最终结果	被接受、被拒绝、超时、API 错误或配置失败
重试次数	此次是初始尝试还是后续重试
计费金额	若可用，实际费用及其计费依据

不要在共享的基准报告中存储 API 密钥、原始响应 token 或无关的个人信息。必要时将受限诊断证据单独保存。打码的任务引用与结果通常比在表格中复制完整请求更有用。

使用 API 测试 断言，使结果定义可以重复验证。如果后端不在你的可见范围内，就记录可观测的应用信号，并称其为“应用接受”，而不要声称自己掌握了内部验证分数。

阅读数字时不要掩盖权衡

有用的结果会解释接受率、延迟、重试与样本量之间的权衡，而不是把一切压缩成一个评分。

考虑下面这个纯算术的假设示例，并非对真实服务的测量对比：

计划的首次尝试数	首次尝试即被接受	首次尝试接受率	经重试后额外完成的任务数	最终完成任务数
100	90	90%	5	95

首次尝试接受率为 90 除以 100，即 90%。最终完成率为 95 除以 100，即 95%。这两个数字都没告诉你重试花了多久、额外尝试被计费了多少次。在真实报告中，这些信息需要单独的列。

再看一个 20 次成功尝试耗时的假设集合：其中 18 次耗时 2 秒，2 次耗时 20 秒。平均值是 3.8 秒，而中位数是 2 秒。按最接近秩定义，p95 为 20 秒。这三种说法都可能为真；单一平均值会掩盖长时间等待。

在报告小样本的分位数时，要说明所采用的计算方法。不同软件对分位数插值方式可能不同，因此未经解释的小数点差异不应被当作有意义的服务优势。

避免把短期试验中的小差别视为长期排名。要在相关周期内重复测量，并在每个分组中标明评估案例数量。如果某个服务只在一种挑战家族中被测试，要在结果旁边标明这一点。

单独解读 reCAPTCHA v3 分数

reCAPTCHA v3 分数描述的是一次交互的评估结果，不应被重新标记为求解器的百分比准确率。

Google 的 reCAPTCHA v3 指南描述了基于分数的决策，以及在后端检查预期动作。接收应用决定如何使用该评估。因此，分数字段的含义与“100 个计划任务中有 90 个被接受”是不同的。

对于自有应用，要记录在试验中使用的接受规则，并在不同服务之间保持一致。如果你合法地获取到分数分布，则应单独报告该分布。如果你只能观察到工作流是否继续进行，不要凭空捏造隐藏分数，也不要假设每一个被接受结果都达到了相同阈值。

选择满足你工作负载需求的求解器

选择在观测到的接受率与响应时间分布上，符合你实际需要运行的工作流的求解器。

在试验之前就设定决策标准。交互式工作流的等待预算可能更紧；离线批处理则可能容忍更久的等待，但需要明确的最终完成目标和成本上限。这些是工作负载需求，而不是宣称某个服务“普遍最快”的理由。

对于由智能体驱动的工作流，验证码工具调用评估指南讨论的是一个相关但独立的问题：智能体是否正确选择并调用了工具。要将这类评估与本文描述的求解器性能对比区分开来。

用与其他候选服务相同的任务定义和接受标准来评估 CapSolver。有用的基准应让读者能够解释：什么成功了、耗时多久，以及证据止于何处。

常见问题

问：多少验证码求解准确率才算好？

有用的目标取决于挑战家族和工作流需求。在具有代表性的样本上比较被接受的结果，并在评估任何百分比前说明分母。

问：最快的 API 响应就是最快的可用解决方案吗？

未必。提交确认、返回的解决方案和应用接受是三个不同事件。要测量与读者需求相匹配的那个事件。

问：失败尝试应当从延迟分位数里排除吗？

可以单独报告成功尝试的延迟，但失败与超时截止必须同步呈现。否则，仅展示“快速子集”会误导对整体工作负载的认知。

问：我可以复用同一个 token 来测试不同服务吗？

不可以。单次验证 token 不适合做基于重放的对比测试。针对 token 工作流，应使用全新、等价且被许可的试验。

问：本文是否对验证码求解服务进行排名？

没有。本文给出的是比较方法，并明确使用了假设性的算术示例。性能排名需要在说明条件相同的前提下，进行实际测量。