OCR для текстовых капч: где библиотека ломается и как не сливать парсинг

OCR для текстовых капч: где библиотека ломается и как не сливать парсинг

Если капча состоит из букв и цифр, OCR часто даёт стабильный проход только на «чистом» рендере. Но в реальных схемах ломают не символы, а предобработку: шум, сдвиг базовой линии, разный контраст, сжатие, рандомный кернинг. Без нормализации входа библиотека начинает угадывать по форме, а не читать текст.

Рабочий пайплайн обычно такой: — выравнивание по яркости и бинаризация; — удаление фона и мелкого шума; — сегментация символов, если капча не склеена; — прогон через OCR с несколькими профилями распознавания. Для узких доменов лучше держать отдельный пресет под каждый тип капчи, чем пытаться одной моделью закрыть всё.

Ключевая ошибка — надеяться на «магический» engine без проверки confidence. Если библиотека отдала низкую уверенность, ответ надо отклонять и повторять цикл, а не отправлять в боевой запрос. Ещё один частый провал — обучение на слишком чистом датасете: модель хорошо читает тестовые картинки и разваливается на боевой разметке.

Пробиваем защиту любой сложности: сначала строим конвейер предобработки, потом меряем долю успешных чтений, latency и процент повторов. Если OCR стабильно даёт мусор, дешевле сменить стратегию, чем бесконечно подкручивать параметры.