LLM captcha solver: может ли нейросеть сама решать капчи
В статье разобрали, где LLM действительно помогает, почему подход где пытаются решить одной LLM обычно ломается и как на практике выглядит рабочая связка с сервисом.
Если кратко, LLM должна отвечать за управление, браузерная автоматизация — за выполнение шагов, а 2Captcha
— за решение капчи через API. Такая схема стабильнее, проще в отладке и удобнее в поддержке на проде.
Почему вокруг LLM столько шума
Потому что LLM внезапно стали выглядеть как универсальнок решение: видят интерфейс, читают текст, понимают инструкции.
На этом фоне легко поверить, что капча — просто еще один тип задачки. Обзоры прямо говорят: MLLM неплохо проходят распознающие и низкоинтерактивные задачи, а вот там, где нужна точная локализация и многошаговое пространственное рассуждение, качество заметно хуже. Это опять же звучит как еще чуть‑чуть — и дожмем.
Где заканчивается хайп и начинается суровая практика
Почему капча — это не просто картинка. Практика начинается там, где надо устойчивый процент решения.
Проверяется не только ответ
Современные провайдеры прямо документируют, что проверка — это сигналы и риск, а визуальная часть (если она вообще есть) часто вторична. reCAPTCHA v3 возвращает score 0.0–1.0, и сайт сам решает, что делать дальше: пропустить, попросить дополнительное действие шаг, ограничить.
В документации по Turnstile описывается механика: сначала запускаются неинтерактивные JavaScript‑челленджи, чтобы собрать сигналы о среде/браузере, и затем результат адаптируется под конкретного посетителя.
Даже правильный ответ не помогает
Это тот самый нюанс, который ломает LLM: решили капчу, но сервер не считает сессию нормальной. С точки зрения провайдера это логично: если риск‑профиль плохой, правильные ответы могут выглядеть как признак автоматизации.
В индустрии давно применяются фингерпринты (браузерные и транспортные). Например, TLS‑отпечатки уровня JA3/JA3S как способ “профилировать” TLS‑клиентов.
Где LLM реально полезна
Понять, что на странице появилась капча
Самая недооценённая роль LLM — диагностика. Не “реши”, а “распознай, что сценарий уперся в проверку”. Это особенно важно в динамическом UI, где селекторы ломаются, а семантика интерфейса (кнопка, текст, состояние формы) остается. Именно поэтому реальные бенчмарки определили проблему капчи как отдельный класс сбоев, влияющий на end‑to‑end успех.
Продолжить сценарий после решения
Даже когда проверка пройдена, часто надо “поднять” сценарий обратно: понять, что изменилось в DOM/странице, повторить отправку формы, восстановить контекст. Здесь LLM полезна как работник, а не как “OCR‑движок”.
Почему подход с одной только LLM обычно не работает
Модель не контролирует всю среду
LLM может “понять”, что происходит, но она не является браузером. А современные проверки смотрят на client‑side signals, требуя, чтобы браузер выполнил проверки (иногда без участия человека). Cloudflare прямо описывает: при Non‑Interactive Challenge решение принимается на основе сигналов из браузера через внедренный JS, и обычно это занимает считанные секунды.
Плюс есть технические классы задач, где модели слабы: fine‑grained localization, multi‑step spatial reasoning, consistency across frames.
Как выглядит рабочая схема на практике
В рабочей архитектуре LLM не “взламывает капчу”, а управляет сценарием и делегирует узкую задачу туда, где она решается правильно.
LLM определяет контекст
LLM получает контекст (скриншот/DOM/accessibility tree), отвечает на вопрос «мы в нормальном шаге или в проверке?», классифицирует и выбирает ветку.
Сервис решает капчу
Дальше подключается специализированный анти-капча компонент (сервис), который предоставляет API‑сценарий “задача → результат”.
Сценарий выполняется дальше
После решение агент делает разблокировку и возвращает управление сценарию, снова LLM в деле.
| Компонент | Роль | Сильные стороны | Ограничения | Когда использовать |
|---|---|---|---|---|
| LLM | Контроль и оркестрация | Понимает UI “по смыслу”, устойчивее к изменению верстки, выбирает стратегию | Не контролирует низкоуровневые сигналы ; может ошибаться/галлюцинировать | Ветвление сценариев, диагностика блокировок, восстановление после сбоев |
| Браузерная автоматизация | Исполнитель действий | Клики, действия | Проблема с обработкой трудных UI | Выполнение шагов, сбор состояния страницы |
| Сервис решения | Специализированный “узкий модуль” | Стабильный работа “задача→результат”, легче масштабировать | Качество решения зависит от типа капчи и качества прокси ; юридические ограничения | Если на сайте есть антибот система |
Риски
- Юридика и правила. Автоматизация должна быть в рамках правил, ToS и закона; для публичных сайтов надо иметь легитимную цель (например, тестирование своего сервиса).
- Безопасность агента. Аагенты уязвимы к prompt injection через контент страниц. Для масштабных проектов надо defense‑in‑depth архитектура и ограничения инструментов.
Вывод
Может ли LLM решать капчи сама
Иногда — да, особенно на низкоинтерактивных задачах. Но часто LLM упирается в известные типы, где есть специфические выды, требуется точная локализация устройства.
Почему на практике связка LLM + сервис работает лучше
Представьте обычную команду на проекте.
LLM здесь играет роль координатора. Она смотрит на страницу, понимает, что сценарий уперся в проверку, и решает, что делать дальше: повторить шаг, пойти по другой ветке или подключить внешний модуль.
Браузерная автоматизация — это исполнитель. Она кликает, ждет, заполняет поля, проверяет переход на следующий шаг. То есть делает всю ту работу, которая должна выполняться стабильно и одинаково из раза в раз.
Сервис решения — это уже узкий специалист. Его задача — пройти конкретную проверку и вернуть результат в понятном формате.
Во-первых, капча сама по себе не является отдельной задачей. Это всего лишь часть общей проверки сессии. Даже если решение выполненио правильно, сайт все равно может не доверять самой сессии. Поэтому сервис не превращает плохую сессию в хорошую.
Во-вторых, система становится устойчивее, когда роли разделены. Если LLM отвечает за логику и выбор действий, а не пытается напрямую рулить каждым шагом, всю схему проще отлаживать и улучшать.
В-третьих, такую архитектуру легче поддерживать. Модуль автоматизации или сам сервис можно заменить, не трогая всю остальную логику.
В части использования агентов и моделей LLM лучше работать по тому же принципу, что и с любым автоматизированным исполнителем: давать только тот доступ, который реально нужен:
- не давать доступ к секретам, cookie и продовым токенам без необходимости;
- изолировать сессии: тестовые аккаунты, отдельные окружения;
- включать ручное подтверждение для рискованных действий;
- учитывать prompt injection: на странице может быть текст, который попытается повлиять на поведение агента.
Выносите работу с капчей в отдельный модуль: обнаружили капчу → отправили в севрис → получили результат → применили → проверили, что шаг действительно пройден.
Подход предоставлеяет практические плюсы:
- проще понять, на каком этапе все ломается;
- проще настроить ретраи и таймауты;
- при необходимости можно заменить провайдера или режим работы, не переписывая LLM-логику целиком.
Большая LLM хорошо подходит для общей логики: понять страницу, определить состояние интерфейса, выбрать следующий шаг и восстановить сценарий после сбоя. Но использовать ее как основной инструмент для решения конкретной challenge-проверки часто невыгодно.
Причина простая: большая модель универсальна, но избыточна. Она тратит больше ресурсов, стоит дороже и не всегда дает лучший результат в задаче, где важны не рассуждения, а точное распознавание конкретного типа проверки.
Для таких задач эффективнее работает узкая специализированная модель как у сервиса 2Captcha. Она не пытается понимать весь сайт или весь пользовательский сценарий. Ее задача ограничена: распознать конкретный тип captcha или challenge, вернуть результат и передать управление обратно автоматизации.
Поэтому в рабочей архитектуре большая LLM остается на уровне оркестрации, а специализированная модель или сервис решения закрывает узкую задачу проверки. Такой подход обычно быстрее, дешевле и проще в поддержке: каждый компонент делает только то, для чего он подходит лучше всего.