<b>OCR для текстовых капч: где ломается пайплайн и как это чинить без лишних затрат</b>

<b>OCR для текстовых капч: где ломается пайплайн и как это чинить без лишних затрат</b>

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

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

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

Лучше всего OCR работает там, где капча статична и повторяет один шаблон. Как только появляются случайные наклоны, перекрытия, разный шрифт и фоновые линии, падает и точность, и стабильность. Для пайплайна это значит одно: держать fallback на ручной разбор или альтернативный метод, а не надеяться на один распознаватель. Снижаем косты на распознавание: сначала тестируем препроцессинг, потом уже меняем движок.

—
Для любителей keitaro vs bemob vs voluum — @tracker_stack_ubt