OCR в 2026 году: классические пайплайны, VLMs и Document AI

Viacheslav Dubrov

2026-03-04 · Обновлено 2026-08-10 · 12 мин · Поисковые и языковые системы

Автоматический перевод Эта статья была автоматически переведена с оригинальной английской версии.

Рейтинги OCR расходятся, потому что проверяют разные документы, форматы выходных данных и подходы к оценке. Снапшот OmniDocBench и OCR Arena начала 2026 года дал заметно отличающиеся порядки моделей; эти баллы нельзя напрямую сравнивать, но само расхождение полезно. Для production-выбора нужны документы и метрики из реальной рабочей нагрузки.

Vision-language models (VLMs) умеют работать с layout, рукописным текстом, таблицами и деградировавшими изображениями, на которых ломается обычный пайплайн распознавания текста. Традиционные движки по-прежнему конкурентоспособны на чистой печати, особенно когда важны латентность на CPU и стоимость эксплуатации. Приведённый ниже устаревающий снапшот включает PaddleOCR-VL 1.6 и dots.mocr, между которыми есть разные компромиссы по железу, приватности и формату вывода. Перед текущим выбором проверьте каждый проект.

Связанный репозиторий: The OCR Gauntlet содержит три ноутбука. Основной ноутбук сравнивает до пяти OCR-движков на пяти загруженных образцах и считает CER, WER, ANLS, латентность и оценочную стоимость. В зафиксированном запуске используются Tesseract, Docling + Tesseract, Mistral OCR v3 и запуск Gemini; dots.ocr был недоступен. Не используйте строку Gemini для сравнения моделей: раннер запрашивает gemini-2.5-flash, но в зафиксированном ноутбуке этот результат помечен как Gemini 3 Flash.

Это руководство предназначено для инженеров, выбирающих OCR- или document-AI-пайплайн для реальных рабочих нагрузок, где важны текст, layout, таблицы или извлечённые поля.

После прочтения вы сможете выбрать baseline, сравнить модели по метрикам конкретной задачи и направить неуверенные или критичные поля на валидацию либо ручную проверку.

Краткую версию по выбору моделей см. в статье Лучшие OCR-модели в 2026 году: классический OCR, PaddleOCR-VL, VLMs.

OCR теперь определяет качество downstream-систем

OCR давно используется в архивах, почтовых системах, инструментах доступности и системах управления документами. RAG и document agents сделали его режимы отказа заметными для более широкой группы инженеров: downstream-модель не может восстановить текст или структуру таблицы, отброшенные на этапе извлечения.

Качество retrieval в вашей RAG-системе ограничено качеством OCR. Если при извлечении таблица искажается, дата распознаётся неправильно или абзац теряется, последующие изменения чанкинга и эмбеддингов не смогут восстановить отсутствующую информацию. Такие ошибки могут скрыть пункт договора, изменить итоговую сумму в счёте или повредить медицинскую запись.

Поэтому OCR — часть инфраструктуры retrieval и ИИ-агентов наряду с парсингом, чанкингом, эмбеддингами и индексацией. Его ошибки нужно оценивать отдельно, а не поглощать в единой end-to-end-метрике.

Что означает OCR в эпоху foundation models

OCR преобразует текст на изображении в машиночитаемые символы. Document AI — более широкая система, включающая анализ layout, разбор таблиц и формул, извлечение полей, семантический ризонинг, provenance и валидацию. В некоторых статьях для end-to-end-моделей, объединяющих несколько таких этапов, используется термин «OCR-2.0», но он не должен стирать различие между распознаванием и пониманием документов.

Традиционный OCR-пайплайн состоит из трёх основных этапов:

1. Детектирование текста: поиск областей, содержащих текст (например, CRAFT, DBNet).
2. Распознавание текста: преобразование найденных областей в последовательности символов (например, CRNN).
3. Постобработка: проверка орфографии и коррекция языковой моделью.

Это хорошо работает на чистых документах, но ошибки детектирования, распознавания и постобработки могут накапливаться. Измеряйте как точность на уровне символов, так и точность извлечения полей, чтобы читаемая страница не скрывала неправильную сумму или идентификатор.

OCR-2.0 объединяет большую часть этого пайплайна в vision-энкодер и языковой декодер. Модели вроде GOT-OCR 2.0 могут одновременно выдавать текст и структуру, а общие VLMs — сопоставлять поля с заданной схемой. Компромиссы зависят от рабочей нагрузки: это латентность, стоимость GPU или API и риск правдоподобного текста, которого на изображении нет.

Практическая оговорка: не позволяйте ярлыку «end-to-end» вводить вас в заблуждение. В production OCR-2.0 объединяет инференс модели, но не весь пайплайн обработки документов. Вам по-прежнему нужны растеризация PDF для получения изображений, нормализация изображений (deskew, настройка DPI) для стабильного качества и парсинг вывода, чтобы извлекать структурированные поля из текста модели. Пайплайн стал короче, но не исчез.

Что измеряют и упускают OCR-бенчмарки

Следующие датасеты показывают, как разные OCR-задачи приводят к разным метрикам. Размеры датасетов и метрики относятся к указанной версии датасета; оценки моделей проверяйте в текущем leaderboard соответствующего проекта.

Разрыв между «бенчмарком» и «ареной»

Рейтинги автоматических бенчмарков могут расходиться с предпочтениями людей, поскольку отличаются распределение входных данных и критерии оценки.

В OCR Arena пользователи вслепую голосуют за результаты в очных сравнениях. 2026-08-09 её текущий порядок ставил Gemini 3 Flash выше GLM-OCR и DeepSeek-OCR, тогда как в версионированной таблице OmniDocBench далее в этой статье специализированные document-модели занимали более высокие позиции, чем Gemini 3 Flash. Порядок в арене меняется после новых сравнений, поэтому это направленное свидетельство, а не воспроизводимый снапшот бенчмарка. Эти два leaderboard нельзя объединять в один балл: в одном используются метрики датасета, в другом — пользовательские голоса.

Вероятные причины включают состав документов, формат вывода, языковое покрытие и критерии джаджа. Опубликованные числа полезны для первичного отбора, но окончательный выбор требует holdout-набора из целевой рабочей нагрузки.

Традиционные OCR-движки: они всё ещё актуальны

Если традиционные движки хуже на сложных данных, зачем их использовать? Потому что на чистых структурированных данных они быстрые и дешёвые.

Традиционные движки полезны как baseline, поскольку могут работать локально на CPU. Их латентность и точность зависят от выбранной модели, разрешения страницы, языка, препроцессинга и железа, поэтому проводите бенчмарк на тех же размеченных страницах, что и при оценке VLM.

Tesseract для чистой печати

Tesseract (v5.5.x, Apache 2.0) — зрелый движок, работающий только на CPU, со 100+ языковыми пакетами. Точность на чистой печати может быть высокой после корректной растеризации и препроцессинга, но рукописный текст, scene text и сложные layout требуют отдельного тестирования. Его главное преимущество — небольшой локальный деплой на CPU, а не универсальное лидерство по точности.

EasyOCR

EasyOCR сочетает детектор CRAFT с распознавателем CRNN. При полной GPU-акселерации PyTorch это быстрый вариант для быстрого прототипирования и scene text.

Для сниппета нужны pip install easyocr, PyTorch, скачанные веса модели EasyOCR и локальный receipt.jpg. Синтаксис проверен, но репозиторий не выполняет этот код через Markdown-раннер.

import easyocr

# Three lines for complete OCR
reader = easyocr.Reader(["en"])
result = reader.readtext("receipt.jpg")
# Returns: [(bbox, text, confidence), ...]

PaddleOCR 3

PaddleOCR 3 объединяет поддерживаемые OCR, парсинг документов и пайплайны деплоя. В текущем quick start используется API predict() и явные настройки ориентации. Зафиксируйте пакет paddleocr и выбранный пайплайн: примеры для 2.x с .ocr(..., cls=True) не соответствуют API 3.x.

Для сниппета нужны pip install "paddleocr>=3,<4", совместимый рантайм PaddlePaddle, скачанные веса модели и локальный receipt.jpg. Синтаксис проверен, но репозиторий не выполняет этот код через Markdown-раннер.

from paddleocr import PaddleOCR

ocr = PaddleOCR(
    use_doc_orientation_classify=False,
    use_doc_unwarping=False,
    use_textline_orientation=False,
)

for result in ocr.predict("receipt.jpg"):
    result.print()
    result.save_to_json("output")

Специализированные и общие варианты VLM

Искривлённые чеки, наклонённые этикетки товаров, рукописный текст и плотные layout — это случаи, когда специализированные или общие VLM стоит сравнить с традиционными движками.

Волна специализированного OCR

Список моделей в этом разделе — снапшот, проверенный 2026-08-09. Это не текущий рейтинг. К специализированным моделям для парсинга документов, опубликованным в 2024–2026 годах, относятся:

• PaddleOCR-VL 1.6: Двухэтапный пайплайн: сначала выполняется анализ layout, затем компонент VLM размером 0.9B обрабатывает найденные области. PaddleOCR сообщает о поддержке 109 языков и результате 96.3 на OmniDocBench v1.6; этот результат вендора следует связывать с указанным пайплайном и версией бенчмарка.
• dots.mocr (3B): Преемник dots.ocr-1.5, выпущенный в марте 2026 года; парсит текст и структурированную графику, включая вариант, ориентированный на SVG. Исходная dots.ocr остаётся отдельной моделью 2025 года.
• GOT-OCR 2.0: Унифицированная модель с 580M параметров, выдающая обычный текст и форматированный вывод, например Markdown и LaTeX. Официальный репозиторий не публикует минимальные требования к VRAM, поэтому измеряйте пиковое потребление памяти с выбранными рантаймом, точностью, размером изображения и лимитом вывода.
• DeepSeek-OCR2: Чекпоинт, документированный в официальном репозитории на дату снапшота; он пришёл на смену исходной модели DeepSeek-OCR класса 3B, представившей «контекстуальную оптическую компрессию». Показатели throughput для любого из поколений зависят от железа и датасета.
• Mistral OCR 4.0 (mistral-ocr-4-0), снапшот 2026-08-09: Проприетарный сервис извлечения текста и структуры, документированный Mistral. OCR 3 (mistral-ocr-2512) по-прежнему доступен для существующих интеграций и используется в связанном ноутбуке. Ноутбук намеренно использует OCR 3 для воспроизводимости, а не потому, что OCR 3 новее. Цены и результаты бенчмарков меняются, поэтому при сравнении проверяйте текущие model card и условия провайдера.

Frontier VLM

Общие VLM — ещё один вариант, когда задача сочетает извлечение с визуальным или семантическим ризонингом. Примеры ниже отражают снапшот статьи начала 2026 года, а не текущий рейтинг:

• Qwen3-VL (Alibaba): Семейство VLM с открытыми весами, несколькими размерами и вариантами с длинным контекстным окном.
• Gemini 3 Flash (Google): Hosted-мультимодальная модель, занявшая высокую позицию в указанном снапшоте OCR Arena.
• Claude Opus 4.6 (Anthropic): Hosted-общая VLM с поддержкой structured outputs.
• GPT-5.2 (OpenAI): Hosted-общая VLM для смешанных визуальных и текстовых входных данных.

Измеряйте латентность по уровням

Измеряйте латентность страницы с фактическими разрешением, batch size, железом или регионом провайдера и длиной вывода. Включайте препроцессинг и ретраи в общее время: замер только модели не отражает стоимость успешно обработанной страницы.

Метрики: измеряйте то, что действительно важно

Выбирайте метрику в соответствии с типом вывода:

• CER и WER для обычного текста. Character and Word Error Rate зависят от правил нормализации — регистра, пробелов и пунктуации, — поэтому сначала зафиксируйте протокол сравнения моделей.
• EMR и Field F1 для форм и чеков. Exact Match Rate бинарна, что и требуется для ИНН и итоговых сумм. Field F1 балансирует precision и recall для каждого типа поля.
• TEDS для таблиц. Tree-Edit-Distance-based Similarity сравнивает предсказанное и эталонное HTML-дерево, выявляя структурные ошибки и ошибки в содержимом ячеек, которые CER не замечает.
• ANLS для document VQA. Average Normalized Levenshtein Similarity даёт частичный балл за ответы с небольшими OCR-ошибками.

Для реализаций: jiwer из коробки считает CER/WER, а реализации TEDS находятся в репозитории OmniDocBench.

Тестирование VLM через OpenRouter

OpenRouter предоставляет совместимый с OpenAI шлюз к моделям нескольких провайдеров. ID моделей и поддерживаемые возможности запросов меняются, поэтому перед запуском примера проверьте их в текущем каталоге шлюза.

Для сниппета нужны pip install openai, OPENROUTER_API_KEY, доступ к сети, локальный receipt.jpg и ID моделей, которые всё ещё поддерживаются OpenRouter. Синтаксис проверен, но репозиторий не выполняет этот код через Markdown-раннер.

import base64
import os
from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
)

def extract_text(image_path: str, model: str) -> str:
    with open(image_path, "rb") as f:
        image_b64 = base64.b64encode(f.read()).decode()

    response = client.chat.completions.create(
        model=model,
        messages=[{
            "role": "user",
            "content": [
                {"type": "text", "text": "Extract all text from this image, preserving layout as markdown."},
                {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_b64}"}},
            ],
        }],
        max_tokens=4096,
    )
    return response.choices[0].message.content

# Compare models by changing one string
models = [
    "google/gemini-3-flash-preview",
    "anthropic/claude-sonnet-4.5",
    "qwen/qwen3-vl-8b-instruct",
]
for model in models:
    print(f"\n--- {model} ---\n{extract_text('receipt.jpg', model)[:200]}...")

Эти ID моделей были проверены по каталогу OpenRouter 2026-08-09. Перед запуском примера снова проверьте каталог.

Для структурированного извлечения используйте response_format с JSON Schema, если выбранные модель и шлюз это поддерживают. Это может сделать ответ пригодным для парсинга, но не валидирует извлечённые значения по изображению. Следующий блок повторяет настройку, чтобы его можно было читать независимо. Для него по-прежнему нужны pip install openai, OPENROUTER_API_KEY, доступ к сети, локальный receipt.jpg и модель с поддержкой JSON Schema; раннер репозитория только проверяет синтаксис.

import base64
import json
import os
from openai import OpenAI

with open("receipt.jpg", "rb") as f:
    image_b64 = base64.b64encode(f.read()).decode()

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
)

response = client.chat.completions.create(
    model="google/gemini-3-flash-preview",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "Extract the receipt fields from this image."},
            {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_b64}"}},
        ],
    }],
    max_tokens=4096,
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "receipt",
            "strict": True,
            "schema": {
                "type": "object",
                "properties": {
                    "vendor": {"type": "string"},
                    "date": {"type": "string"},
                    "items": {
                        "type": "array",
                        "items": {
                            "type": "object",
                            "properties": {
                                "description": {"type": "string"},
                                "amount": {"type": "number"},
                            },
                            "required": ["description", "amount"],
                            "additionalProperties": False,
                        },
                    },
                    "total": {"type": "number"},
                },
                "required": ["vendor", "date", "items", "total"],
                "additionalProperties": False,
            },
        },
    },
)
receipt = json.loads(response.choices[0].message.content)

Результаты бенчмарков: что на самом деле показывают числа

Таблица ниже — один версионированный снапшот: OmniDocBench v1.6_full, официальный README на коммите 09ba2b606662695b16aafe5f5e36b7ef020e11a8, опубликованный 2026-04-10 и просмотренный 2026-08-09. Все четыре строки взяты из этой зафиксированной таблицы. В таблице не смешаны значения из более ранних таблиц статей или других leaderboard.

Вывод ограничен этой версией OmniDocBench: размер модели сам по себе не предсказывает качество парсинга документов.

Связанный ноутбук считает CER, WER, ANLS, латентность и оценочную стоимость на пяти загруженных образцах. Исключите неправильно помеченную строку Gemini, если не исправите идентичность модели и не перезапустите тесты на этих образцах.

Деплой OCR в production

!!! byte «Byte говорит»

Я доверился встроенному текстовому слою в пачке PDF. Каждый символ был правильным, но стоял не на своём месте, поэтому все таблицы превратились в бессмыслицу.

Многоуровневая архитектура позволяет отделить препроцессинг на CPU от инференса на GPU или через API и резервировать дорогие пути для документов, которым они действительно нужны.

Примечание об оркестрации: Инструменты вроде Docling могут координировать конвертацию и пакетную обработку. Политика ретраев по-прежнему относится к окружающему приложению или сервису, а для роутинга по-прежнему нужны собственные quality labels и пороги.

Многоуровневый fallback-паттерн

Начинайте с самого дешёвого пути, который достигает целевого качества, а затем калибруйте роутинг на размеченных страницах:

0. Проверьте наличие встроенного текста (Tier 0). Для PDF проверьте текстовый слой с помощью PyMuPDF или pdfplumber до растеризации, но убедитесь, что слой полный и правильно упорядочен.
1. Попробуйте быструю модель. Используйте традиционный движок для классов документов, на которых он достигает целевого качества.
2. Оцените калиброванную уверенность. Сочетайте уверенность модели с классом документа, критичностью поля и правилами валидации.
3. Переключитесь на более сильную модель. Направляйте неуверенные страницы специализированной или общей VLM.
4. Передайте критичные ошибки человеку. Ручная проверка — отдельный уровень для значений, где стоимость ошибки превышает выгоду автоматизации.

Примечание об уверенности: Сырые вероятности символов автоматически не калибруются под корректность поля. Приведённая ниже функция с учётом площади — baseline для агрегации на уровне страницы, а не универсальный роутер. Калибруйте её на размеченных страницах и задавайте отдельные правила для критичных полей: средняя оценка страницы может скрыть неправильный ID или итоговую сумму.

def area_weighted_confidence(page):
    """Compute area-weighted confidence from a PaddleOCR 3.x result."""
    total_area, weighted_sum = 0, 0
    for (x_min, y_min, x_max, y_max), score in zip(
        page["rec_boxes"], page["rec_scores"]
    ):
        area = (x_max - x_min) * (y_max - y_min)
        weighted_sum += score * area
        total_area += area
    return weighted_sum / total_area if total_area > 0 else 0

Анализ стоимости в масштабе

Универсальной точки безубыточности по объёму страниц между API и self-hosting не существует. Стройте сравнение на одной и той же рабочей нагрузке:

Используйте единую формулу: monthly pages × cost per successful page + review cost + fixed operating cost. «Успешная страница» должна соответствовать одинаковым критериям по тексту, таблицам и полям на обоих путях. Цены провайдеров и аренда GPU меняются слишком быстро, чтобы закладывать их в долговечную оценку закупки.

Обработка ошибок: проблема галлюцинаций

Ошибки VLM могут быть контекстно правдоподобными, но фактически неправильными. Итоговая сумма в чеке «$42.50» может превратиться в «$45.20»: синтаксически корректное значение, незаметное для проверки орфографии.

Синтетический пример ошибки: VLM извлекает три позиции чека и указанную итоговую сумму, которые согласуются между собой, но одна цифра отличается от изображения. Внутренняя арифметика проходит, хотя извлечение неверно. Поэтому для валидации нужны labels, привязанные к изображению, или независимый путь проверки, а не только проверки согласованности.

Несколько практических мер:

• Арифметическая сверка. Если схема их содержит, проверяйте subtotal + tax + fees + shipping - discounts с учётом допустимого округления для валюты и сопоставляйте с указанной итоговой суммой. Отправляйте на проверку отсутствующие компоненты или расхождения.
• Sanity check с помощью regex для дат (без месяца 13), телефонных номеров (корректное количество цифр) и форматов валют.
• Кросс-модельная проверка. Прогоняйте критичные поля через две разные модели и отмечайте расхождения.
• Независимый OCR cross-check. Запускайте второй путь извлечения для критичных чисел и отмечайте расхождения. Согласие повышает уверенность только тогда, когда два пути имеют достаточно разные режимы отказа; это не доказательство корректности.

Основные выводы

1. Сопоставляйте уровень модели с размеченным классом документов. Традиционных движков может быть достаточно для чистого текста; специализированные и общие VLM должны оправдывать дополнительные затраты на более сложных страницах.
2. Не объединяйте несопоставимые leaderboard. Метрики OmniDocBench и предпочтения OCR Arena отвечают на разные вопросы.
3. Калибруйте роутинг. Пороги уверенности, классы документов, критичность полей и политика ручной проверки должны оцениваться вместе.
4. Валидируйте правдоподобный вывод. Соответствие схеме и внутренняя арифметика не доказывают, что значение присутствует на изображении.
5. Считайте стоимость успешных страниц. При сравнении API и self-hosting учитывайте ретраи, проверку, фиксированные операционные расходы и quality gates.

Препроцессинг и детектирование по-прежнему важны, но production OCR теперь также требует роутинга, оценки по задачам и защиты от правдоподобных ошибок извлечения.

References

• OCR Arena Leaderboard — краудсорсинговые очные сравнения моделей
• Репозиторий The OCR Gauntlet — запускаемые ноутбуки для сравнения OCR-движков, анализа вывода Docling и оценки стоимости
• OmniDocBench — end-to-end эвалуация парсинга документов
• dots.ocr — около 3B общих параметров, включая языковую модель на 1.7B
• PaddleOCR — традиционный OCR-toolkit и модели
• OpenRouter — единый шлюз доступа для A/B-тестирования моделей