Откройте любое изображение в hex-редакторе. Фото дорожного знака, чек, скриншот PDF. На нулевом смещении — заголовок формата. Через несколько килобайт вы добираетесь до пиксельных данных: три байта на пиксель в RGB, сетка чисел, где (128, 52, 19) — кирпичная стена, а (240, 238, 220) — бумага. Где-то в этой сетке находится знак «стоп» со словом «STOP», набранным белым Highway Gothic на красном фоне. Человек видит четыре буквы. Компьютер видит участок размером 47 × 19 пикселей со значениями, близкими к красному, где канал R держится около 200, а G и B падают ниже 40. Сопоставить этот участок со строкой «STOP» — это и есть оптическое распознавание символов, открытая исследовательская проблема с тех пор, как Густав Таушек запатентовал первую читающую машину в 1929 году.
OCR обманчиво сложен, потому что чтение обманчиво легко. Шестилетний ребёнок узнает букву «А» в десятке шрифтов, разного размера, при неравномерном освещении, слегка повёрнутую, частично закрытую и написанную карандашом. Компьютеру нужен конвейер: очистить изображение, найти текстовые области, сегментировать символы или последовательности глифов и классифицировать каждый. У каждой стадии есть свой режим отказа, и отказы накапливаются.
Что делает OCR сложным
Основная проблема не в классификации. Классифицировать заранее сегментированное изображение символа размером 28 × 28 пикселей в один из 62 классов (A–Z, a–z, 0–9) — задача, которую LeNet 1990-х годов решает с точностью 99%. Сложность — во всём, что предшествует классификатору.
Вариативность шрифтов. Буква «g» имеет как минимум четыре распространённых структурных варианта: одноэтажная (рукописная), двухэтажная (большинство шрифтов с засечками), петлевая в Helvetica и открытая в Futura. Модель, обученная на Tahoma, будет с измеримой частотой ошибаться на Univers. Реальный OCR охватывает сотни гарнитур плюс рукописный текст, у которого вообще нет единой топологии штрихов.
Геометрические искажения. Фотографии документов редко бывают планшетными сканами. Снимок чека на телефон вносит перспективный наклон, кривизну и неравномерный масштаб. Текст у корешка книги изгибается. Фото с доски захватывают тень фотографа. Наклон в 10 градусов снижает точность Tesseract с ~97% до менее 85% на стандартных бенчмарках. Алгоритмы выравнивания (обнаружение линий Хафа, преобразование Радона, анализ проекционного профиля) восстанавливают часть потерь, но не всё.
Освещение и шум. Неравномерное освещение превращает однородный фон в градиент, ломая глобальную пороговую обработку. Артефакты сжатия JPEG создают звон (ringing) вокруг резких краёв. В терминах OCR это означает звон вокруг штрихов букв. Шум «соль и перец» от сенсоров при слабом освещении заполняет белое пространство тёмными пикселями, похожими на знаки препинания. Ксерокопия с ксерокопии сливает тонкие штрихи, превращая «rn» в «m», а «cl» в «d».
Сложность макета. Документы содержат колонки, подписи, таблицы, заголовки, сноски и боковые панели. Текст обтекает изображения. Некоторые языки пишутся справа налево. Другие смешивают направления в одном абзаце. Определение порядка чтения (какой блок текста за каким следует) — задача анализа макета, отдельная от распознавания, и ошибка в ней перепутывает вывод, даже если каждый символ классифицирован верно.
Контекстуальная неоднозначность. Если смотреть только на пиксельный узор, «0» (ноль), «O» (заглавная буква O) и «o» (строчная буква o) идентичны во многих шрифтах без засечек. «1», «l», «I» и «|» разделяют вертикальный штрих. Разрешение добавляет ещё одно измерение: при высоте 12 пикселей «e» и «c» различаются одним горизонтальным штрихом шириной в три пикселя. Человек разрешает это из контекста. Машинам нужны языковые модели, статистические или обученные, чтобы сделать тот же выбор.
Традиционный конвейер OCR
До глубокого обучения OCR был последовательностью спроектированных вручную этапов. Каждый этап разрабатывался независимо, часто разными исследовательскими группами, и настраивался под конкретный тип искажений. Конвейер выглядел так:
Исходное изображение → Предобработка → Бинаризация → Выравнивание → Анализ макета
→ Сегментация символов → Извлечение признаков → Классификация
→ Постобработка (языковая модель) → Текстовый вывод
Предобработка и бинаризация
Цветные изображения преобразуются в оттенки серого. Подавление шума сглаживает сигнал перед пороговой обработкой. Медианный фильтр справляется с шумом «соль и перец». Гауссово размытие — с шумом сенсора. Билатеральный фильтр применяется, когда важно сохранение краёв.
Бинаризация превращает серое изображение в чёрный текст на белом фоне. Стандартный алгоритм — метод Оцу (1979): он исчерпывающе ищет порог, минимизирующий внутриклассовую дисперсию между распределениями пикселей переднего плана и фона. Оцу предполагает бимодальную гистограмму (текстовые пиксели группируются на одной интенсивности, фоновые — на другой), что работает для планшетных сканов при контролируемом освещении и не работает для телефонных фото с тенями. Локальные адаптивные методы (Sauvola, Niblack) вычисляют разный порог для каждого пикселя на основе статистики окрестности, справляясь с неравномерным освещением ценой артефактов у границ.
Выравнивание и анализ макета
Наклон документа обнаруживается путём поиска линий: либо преобразованием Хафа на граничных пикселях, либо анализом проекционного профиля, где документ поворачивается в диапазоне углов и выбирается угол с самыми резкими пиками горизонтальной проекции. Зная угол наклона, аффинное преобразование поворачивает изображение обратно.
Анализ макета сегментирует страницу на текстовые блоки. Классический подход выполняет анализ связных компонент (CCA), находя сгустки пикселей переднего плана, группирует их в слова по близости, затем группирует слова в строки, а строки — в блоки. Алгоритм XY-cut рекурсивно делит страницу, находя промежутки белого пространства вдоль горизонтальных и вертикальных проекций, строя дерево регионов. Современные реализации используют гибридный подход: CCA для начальных сгустков, затем обученную модель для классификации каждого сгустка как текста, изображения, таблицы или разделителя.
Сегментация символов
Для машинописного текста сегментация означает разрезание изображений слов на отдельные символы. Вертикальный проекционный профиль (гистограмма количества пикселей переднего плана по столбцам) даёт пики в центрах символов и впадины на границах символов. Это работает, пока два символа не соприкасаются или символ не содержит разрозненных частей («i», «j», «:», «%»). Избыточная сегментация (слишком агрессивное разрезание) с последующим слиянием на основе уверенности классификатора — одно из решений. Другое — вообще отказаться от сегментации и распознавать целые слова, что и делают современные методы на основе последовательностей.
Извлечение признаков и классификация
Получив изображение символа, нужно численно описать его для классификатора. К признакам эпохи до глубокого обучения относились:
- Сырые значения пикселей как сплющенный вектор (просто, но чувствительно к сдвигу и масштабу)
- Зонирование (Zoning): разделить ограничивающий прямоугольник символа на сетку N × N, подсчитать пиксели переднего плана в каждой ячейке, использовать подсчёты как признаки
- Градиентные признаки (HOG): гистограмма ориентированных градиентов фиксирует направления краёв, устойчива к малым сдвигам
- Scale-invariant feature transform (SIFT): обнаруживает и описывает ключевые точки, инвариантные к масштабу, повороту и освещению
Классификатором обычно служила машина опорных векторов (SVM) с RBF-ядром, обученная на десятках тысяч размеченных изображений символов для каждого шрифта. Хорошо настроенный конвейер SVM + HOG мог достигать ~98% посимвольной точности на чистом печатном тексте. На зашумлённом, наклонённом или рукописном вводе точность падала до 70–80%.
Tesseract: от HP Labs до LSTM
Tesseract — эталонный опенсорсный движок OCR. Он начинался как докторский проект в HP Labs Bristol в 1980-х, был открыт в 2005 году и поддерживается Google с 2006 года. Его архитектура чётко делится на две эпохи.
Версия 3: классический конвейер
Tesseract 3 реализовывал традиционный конвейер с несколькими инновациями. Анализ макета использовал алгоритм обнаружения табуляций, который находил границы колонок, выравнивая ограничивающие прямоугольники слов — прагматичная эвристика, настроенная под документы, которые HP сканировала в 1990-х. Сегментация символов использовала логику chopper/associator: chopper избыточно резал изображение слова на кандидатные разрезы, а associator использовал уверенность классификатора и словарь, чтобы решить, какие разрезы объединить.
Классификатор был двухпроходной системой. Первый проход (статический классификатор) сопоставлял сегментированные сгустки с прототипами (кластеризованными обучающими образцами) с помощью поиска ближайшего соседа. Второй проход (адаптивный классификатор) дообучался на самом документе, изучая конкретный шрифт, использованный в этом изображении. Адаптивному классификатору требовалась примерно страница текста для эффективной работы, поэтому Tesseract 3 плохо справлялся с однословными изображениями вроде дорожных знаков и подписей.
Tesseract 3 поставлял файлы .traineddata: архивы, содержащие кластеры прототипов, определения наборов символов, частотный словарь и таблицу неоднозначности unichar, сопоставляющую путаемые пары символов. Обучение нового языка требовало подачи в Tesseract изображений текста в паре с эталонными транскрипциями, обводки каждого символа и запуска обучающих инструментов. Многочасовой процесс для каждого языка.
Версия 4/5: LSTM заменяет конвейер
Tesseract 4 (2018) заменил весь путь распознавания одной нейронной сетью LSTM. LSTM работает с последовательностью вертикальных срезов изображения текстовой строки, каждый срез шириной в один пиксель и высотой во всю текстовую строку. Каждый срез подаётся в стек двунаправленных LSTM-слоёв. Выход — последовательность вероятностей символов с функцией потерь Connectionist Temporal Classification (CTC), которая выравнивает выходную последовательность переменной длины с эталонным текстом, не требуя заранее сегментированных позиций символов.
Модель LSTM справляется с символами переменной ширины, соприкасающимися символами и вариативностью шрифтов без механизма chopper/associator. Она всё ещё полагается на унаследованный анализ макета Tesseract для поиска текстовых строк, но распознавание строк — сквозное нейросетевое. На бенчмарке ICDAR 2017 Tesseract 4 достиг 4,4% частоты ошибок символов (CER) на печатном английском, по сравнению с 7,2% у Tesseract 3. Процесс обучения перешёл от унаследованного инструмента обводки к сопоставлению текстовых строк с транскрипциями. Всё ещё с учителем, но с одной меткой на строку вместо метки на символ.
Формат .traineddata был расширен для хранения весов модели LSTM (несколько мегабайт) вместе с унаследованными данными (словарь, таблицы unichar) в одном файле. Обучение быстрой модели LSTM с нуля занимает около 24 часов на современном GPU для языка с латинской письменностью и примерно 100 классами символов; языки CJK требуют больше времени из-за бо́льших наборов символов.
Характеристики точности
Tesseract 5 улучшил версию 4 за счёт бо́льшего обучающего корпуса и лучших параметров по умолчанию, но архитектура не изменилась. Точность сильно зависит от входных данных:
| Входные условия | Tesseract 4 CER | Tesseract 5 CER |
|---|---|---|
| Чистый скан 300 DPI, английский, одна колонка | 2,1% | 1,8% |
| Мобильное фото 150 DPI, английский | 5,8% | 4,9% |
| Чистый скан со смешанными шрифтами | 7,3% | 6,1% |
| Исторический документ (нерегулярный шрифт) | 18,4% | 16,2% |
| Рукописный текст (датасет IAM) | 28,7% | 26,3% |
Модель LSTM устраняет большинство проблем чувствительности к шрифтам версии 3, но движок всё ещё деградирует при низком разрешении (ниже 200 DPI пиксельный срез LSTM теряет детали штрихов), рукописном тексте (модель обучалась на печатных шрифтах; рукописный текст имеет принципиально иную статистику штрихов) и сложных макетах (анализ макета всё ещё работает по унаследованному коду, а не нейросетевому).
Современные подходы глубокого обучения
В академической среде OCR преодолел парадигму CTC + LSTM примерно к 2019 году. Три архитектуры сейчас доминируют в литературе.
CRNN + CTC
Convolutional Recurrent Neural Network (CRNN), опубликованная Shi et al. в 2015 году, объединяет CNN-извлекатель признаков с RNN-моделью последовательности и CTC-декодированием. CNN извлекает пространственные признаки из изображения, по сути обучаясь тому, что LSTM в Tesseract получала вручную (представления вертикальных срезов). RNN моделирует последовательные зависимости между извлечёнными признаками. CTC обрабатывает выравнивание. CRNN-CTC стала стандартным базовым уровнем: сквозное обучение, хорошее обобщение, быстрое инференс (~20 мс на строку на GPU).
Attention-based encoder-decoder
Модели на основе внимания (attention) адаптировали парадигму seq2seq из машинного перевода. CNN или визуальный энкодер создаёт карту признаков изображения. RNN-декодер генерирует выходной текст по одному символу за раз, обращая внимание на релевантные пространственные области карты признаков на каждом шаге. Механизм внимания снимает монотонное ограничение CTC: декодер может вернуться к более ранним частям изображения, когда языковая модель ожидает повторяющийся паттерн, хотя эта гибкость также создаёт риск галлюцинаций для нечитаемого ввода. Декодеры на основе внимания достигают ~1,5–3% CER на чистом печатном английском, превосходя CTC-модели на длинных последовательностях и нерегулярных макетах.
Vision Transformers (TrOCR, Donut)
TrOCR (Microsoft, 2021) применил архитектуру Transformer к OCR. Изображение разбивается на патчи, кодируется ViT-энкодером (Vision Transformer), а текст декодируется авторегрессионно текстовым Transformer-декодером. Это архитектура стандартной мультимодальной модели, обученной специально для OCR. TrOCR достигает результатов уровня state-of-the-art на печатном тексте (CER ниже 1% на чистых сканах) без какой-либо CNN-предобработки, явной языковой модели или посимвольной сегментации.
Donut (NAVER, 2022) расширил подход до понимания документов: вход — полное изображение документа, выход — структурированный JSON, извлечённый напрямую из визуальных признаков, полностью минуя конвейер OCR → NLP. Это размывает грань между OCR и парсингом документов так, что имеет значение для реальных приложений: извлечение суммы счёта, номера паспорта или таблицы из научной статьи становится одним вызовом модели вместо OCR + regex + эвристики.
Сравнение производительности (печатный английский, чистый 300 DPI)
| Метод | CER | Скорость инференса (строк/с) | Требуемые обучающие данные |
|---|---|---|---|
| Tesseract 3 (классический) | 7,2% | ~2 (CPU) | ~100K изображений символов |
| Tesseract 5 (LSTM) | 1,8% | ~15 (CPU) | ~500K текстовых строк |
| CRNN + CTC | 2,5% | ~120 (GPU) | ~2M текстовых строк |
| Attention seq2seq | 1,8% | ~60 (GPU) | ~2M текстовых строк |
| TrOCR (ViT + decoder) | 0,8% | ~20 (GPU) | ~10M текстовых строк |
| Donut (ViT + decoder) | 1,2% | ~15 (GPU) | ~12M изображений документов |
Разрыв между Tesseract и лучшими Transformer-моделями реален на бенчмарках. На практике разрыв сужается, потому что большинство промышленных систем подают Tesseract чистый, хорошо освещённый ввод с 300 DPI, и на таком вводе 1,8% CER означает одну ошибку на каждые 55 символов. Приемлемо для поисковой индексации, менее приемлемо для транскрипции юридического документа.
Неанглийский OCR: почему он сложнее
Английский OCR — решённая задача. Набор символов из 26 заглавных, 26 строчных, 10 цифр и горстки знаков препинания даёт около 70 классов. Задача многоклассовой классификации, легко решаемая силами LeNet 1990-х годов. Остальные письменности мира менее снисходительны.
CJK: взрыв набора символов
Китайский, японский и корейский (CJK) представляют собой сложнейшую задачу OCR уже по одному лишь размеру набора символов. Упрощённый китайский использует около 3 500 общеупотребительных символов и более 6 000 в общем тексте. Традиционный китайский добавляет ещё тысячу вариантных форм. Японский смешивает две слоговые азбуки (хирагана, катакана: по 46 символов) с примерно 2 000 распространённых кандзи плюс латинские буквы и цифры в одном предложении. Корейский хангыль фонетически регулярен (24 базовые буквы, объединяющиеся в слоговые блоки), но визуально плотен: один блок может содержать до шести отдельных компонентов джамо, упакованных в пространство размером примерно с два латинских символа рядом.
Система OCR для CJK не может рассматривать распознавание как 70-классовую классификацию. Это 4 000-классовая для японского, 6 000-классовая для упрощённого китайского и более 10 000-классовая для традиционного китайского, как минимум. Один только выходной слой softmax имеет больше параметров, чем целая модель OCR для латиницы. Объём обучающих данных должен масштабироваться с набором символов: ~100 размеченных образцов на класс для приемлемой точности, так что китайские обучающие наборы начинаются от 600 000 изображений текстовых строк.
Tesseract предоставляет CJK-файлы traineddata (chi_sim, chi_tra, jpn, kor), но они значительно больше латинских моделей. chi_sim.traineddata — около 50 МБ против ~15 МБ для eng.traineddata, и распознавание медленнее из-за бо́льшего пространства вывода. Точность на чистом печатном CJK-тексте составляет 2–5% CER для Tesseract 5, примерно в 2–3 раза выше частоты ошибок для английского в эквивалентных условиях.
Арабский и письменности справа налево
Арабский добавляет две проблемы помимо набора символов (28 букв с контекстуальными формами, меняющимися в зависимости от позиции в слове). Во-первых, он пишется справа налево, поэтому движок OCR должен определять направление текста и обращать порядок вывода. Во-вторых, арабский курсивен. Буквы внутри слова соединяются базовой линией, что делает сегментацию принципиально труднее, чем для в основном раздельных букв латиницы и кириллицы. Изображение арабского слова — один сплошной сгусток; сегментация на основе символов практически невозможна, поэтому подход LSTM/CTC (работающий с изображениями слов без сегментации символов) стал бо́льшим прорывом для арабского OCR, чем для английского.
Иврит, урду, фарси и пушту разделяют некоторую комбинацию этих трудностей. Tesseract предоставляет traineddata для арабского, но точность составляет около 5–8% CER на чистом печатном тексте, примерно в 4 раза хуже английского в тех же условиях.
Индийские письменности: проблема конъюнктов
Деванагари (хинди, маратхи, непали) и другие брахмические письменности представляют особую проблему: единица письма — не символ, а конъюнкт, визуально слитный кластер из согласной, гласного модификатора и иногда дополнительной согласной. Блок Unicode Devanagari содержит 128 кодовых точек, но число возможных конъюнктов превышает 1 000. «Широрекха» (горизонтальная верхняя линия, соединяющая символы в слове) усложняет сегментацию, поскольку линия сливает соседние символы в одну визуальную единицу.
Traineddata хинди от Tesseract (hin) покрывает распространённые конъюнкты, но точность отстаёт от английской в 3–4 раза на печатном тексте. Тамильский, телугу, бенгальский и другие индийские письменности поддерживаются хуже, а для некоторых вообще нет официальных файлов traineddata. Коренная причина — объём обучающих данных: высококачественные размеченные изображения текстовых строк для хинди исчисляются миллионами, а для каннада доступные датасеты — десятками тысяч.
Вертикальный текст и макеты со смешанным направлением
Японский и традиционный китайский иногда набираются вертикально: строки идут сверху вниз, а колонки — справа налево. Анализ макета Tesseract предполагает горизонтальный текст; вертикальный требует предварительного поворота или отдельного движка. Смешанный горизонтальный и вертикальный текст на одной странице, обычный для японских газет и манги, полностью ломает предположение о едином направлении и требует определения направления на уровне региона до распознавания.
Малые языки и обучающие данные
Для языков с менее чем 10 миллионами носителей качественные обучающие данные для OCR редко существуют. Консорциум Unicode закодировал более 150 письменностей, но Tesseract поставляет traineddata примерно для 120 языков, многие из которых сгенерированы из синтетического текста, отрендеренного стандартными шрифтами на чистом фоне. Синтетические данные работают для печатного текста распространёнными шрифтами и не работают для шрифтов, бумаги и качества печати, характерных для реальных документов на этих языках. Модель, обученная на синтетическом Arial при 300 DPI, не прочитает амхарский документ 1970-х годов, напечатанный на пишущей машинке.
OCR на стороне браузера с Tesseract.js
Запуск OCR в браузере был нецелесообразен до появления WebAssembly. Tesseract.js компилирует Tesseract 5 (LSTM) в WebAssembly через Emscripten, оборачивая движок C++ в JavaScript API, который запускает Web Worker на каждую задачу распознавания. Движок, языковые данные и worker загружаются из статических ресурсов. Никакого обращения к серверу за данными изображения.
Поверхность API проста: создайте worker с одним или несколькими кодами языков, передайте ему изображение, получите распознанный текст с посимвольными оценками уверенности. Несколько worker'ов могут работать параллельно, ограниченные доступными ядрами CPU. Обычно четыре параллельные задачи распознавания на потребительском ноутбуке, от шести до восьми на современных телефонах.
Производительность ограничена тремя факторами. Во-первых, WebAssembly работает примерно на 50–70% от нативной скорости; текстовая строка, занимающая 100 мс в нативном Tesseract, занимает около 160 мс в браузере. Во-вторых, файлы traineddata загружаются по сети. eng.traineddata — около 15 МБ, chi_sim.traineddata — около 50 МБ, и оба должны быть полностью загружены до начала распознавания. В-третьих, декодирование изображений (JPEG/PNG/WebP/HEIC в сырые пиксельные данные) использует встроенные декодеры браузера, которые быстры, но различаются по формату и устройству.
Преимущество в приватности структурное. OCR на стороне клиента означает, что изображение никогда не покидает устройство. Фото паспорта, банковская выписка, медицинская карта. Пиксели декодируются в браузере, аналог Textract работает в Web Worker, а результат — строка текста, которую пользователь может скопировать или сохранить. Никакой дата-центр не обрабатывает изображение. Это не функция — это отсутствие сервера, что категорически отличается от политики конфиденциальности, обещающей не смотреть.
Наш инструмент Image to Text работает именно на этом стеке: Tesseract.js с LSTM-распознаванием, Web Workers для параллельной обработки и traineddata для 12 языков (английский, испанский, французский, немецкий, португальский, итальянский, упрощённый и традиционный китайский, японский, корейский, хинди и русский). Перетащите фото, выберите языки, получите текст. Инструмент читает JPEG, PNG, WebP, BMP и GIF, применяет предварительное масштабирование с учётом разрешения (изображения с длинной стороной более 3 000 пикселей уменьшаются для сохранения разумной задержки распознавания) и выдаёт простой текст на изображение с доступной посимвольной уверенностью.
Выбор формата изображения на практике влияет на качество OCR. HEIC-фото с iPhone, преобразованные в JPEG перед OCR, приобретают артефакты сжатия вокруг краёв текста, снижающие точность распознавания. Преобразование HEIC в PNG сначала (без потерь, без артефактов квантования) сохраняет резкие края, на которые полагается LSTM. Наши конвертеры HEIC to JPG и HEIC to PNG выполняют этот этап предобработки прямо в браузере. Аналогично, фотографии при слабом освещении выигрывают от преобразования в формат, сохраняющий полный тональный диапазон перед пороговой обработкой: JPG to PNG избегает артефактов JPEG второго поколения, накапливающихся при перекодировании JPEG-источника.
Браузерный стек OCR неконкурентоспособен с серверными моделями на GPU по пропускной способности. Сервер с Tesseract на 32 ядрах CPU на нативном C++ всегда обгонит вкладку браузера. Он выигрывает в приватности, нулевой инфраструктуре и нулевой стоимости за запрос. Для сканирования нескольких страниц, чека или нескольких вывесок разница в задержке между 200 мс и 50 мс незаметна.
Куда движется OCR
OCR перестал быть самостоятельной областью исследований примерно в 2022 году и влился в более широкое пространство document AI и мультимодальных моделей. Идут три сдвига.
Мультимодальные LLM как zero-shot OCR. GPT-4V, Claude и Gemini могут читать текст с изображений без явного обучения OCR. Подайте фото документа и попросите текст — модель вернёт его. Не потому, что у неё есть специальная OCR-голова, а потому, что распознавание текста возникает из обучения на миллиардах пар изображение-текст. Качество неравномерно. На чистом печатном английском GPT-4V достигает ~1% CER, сравнимо с точно настроенным TrOCR. На фото китайских чеков с низким разрешением он может превзойти Tesseract, потому что модель использует контекст (она знает, как выглядит чек и какие числа ожидать), а не полагается только на доказательства на уровне пикселей. На рукописном тексте он хуже специализированного распознавателя, потому что в обучающем распределении было недостаточно рукописных изображений.
Компромисс — стоимость и задержка. Вызов API GPT-4V для OCR стоит 1–3 цента за страницу в зависимости от количества токенов и занимает 1–3 секунды. Tesseract работает локально за 100–500 мс и ничего не стоит за страницу. Для сканирования 200-страничного документа разница составляет $2–6 и несколько минут реального времени против нуля и менее минуты. Для разового использования (один чек, фото с доски) мультимодальная модель проще и часто точнее.
Инференс на устройстве. Модели, лежащие в основе серверного OCR, уменьшаются. ONNX Runtime Web выполняет квантованные CRNN и небольшие ViT-модели в браузере за 50–100 мс на текстовую строку на WebGPU. Фреймворк Apple Vision включает компактную OCR-модель на устройстве для iOS и macOS, доступную через VNRecognizeTextRequest без сетевого вызова. Разрыв между «серверной GPU-моделью» и «браузерной моделью» сокращается, потому что обе сходятся к одной и той же архитектурной оптимальной точке: небольшой ViT-энкодер (~20–50M параметров) с лёгким декодером, квантованный до INT8 или FP16.
Понимание документов, а не просто транскрипция. Вывод OCR — это строка. Большинство реальных задач связано с извлечением структурированной информации из этой строки: номера счетов, даты, суммы, имена, адреса. Традиционный подход объединяет OCR с regex, распознаванием именованных сущностей и маппингом схемы. Каждый этап — отдельная модель со своими режимами отказа. Сквозные модели понимания документов (Donut, LayoutLMv3, Pix2Struct) пропускают OCR и отображают изображения документов напрямую в структурированный вывод. Модель Donut, дообученная на чеках, не создаёт текстовую транскрипцию, чтобы затем парсить её. Она выдаёт {"total": "42.50", "date": "2026-07-27", "vendor": "..."} напрямую из пиксельного ввода. Этап OCR, та часть, о которой эта статья, становится невидимой деталью реализации.
Это не делает OCR устаревшим. Это делает его строительным блоком. Конвейеру всё ещё нужно обрабатывать крайние случаи: чек, сфотографированный под углом в тёмном ресторане, 50-летний машинописный документ на пожелтевшей бумаге, вывеска на языке, для которого не обучалась ни одна крупная мультимодальная модель. Специализированные OCR-движки, обученные на этих конкретных распределениях, будут превосходить по скорости и качеству модель общего назначения ещё долгие годы, потому что модель общего назначения, обученная на всём интернете, выделяет исчезающе малую долю своей ёмкости на чтение вывода амхарской пишущей машинки 1970-х годов.
OCR — не решённая задача для большинства языков мира и большинства реальных условий съёмки. Это решённая задача для чистого, 300 DPI, английского, одноколоночного, машинописного текста — самого узкого и лучше всего финансируемого сегмента пространства проблемы. Остальное всё ещё открыто.
