2026-03-04 · Обновлено 2026-07-15

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

Полное руководство по OCR в 2026 году: от Пайплайны до VLMs

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

Визуально-языковые системы модели (VLMs) способны обрабатывать макеты, рукописный текст, таблицы, а также изображения с плохим качеством, которые делают невозможной работу систем распознавания обычного текста пайплайн. Традиционные движки по-прежнему остаются конкурентоспособными для чисто отпечатанного текста, особенно в тех случаях, когда важны CPU латентность и затраты на эксплуатацию. Специализированные модели подобные этим точки.ocr Общие VLMs располагаются на средних и верхних уровнях, предлагая различные компромиссы между характеристиками оборудования, уровнем конфиденциальности и качеством работы.

Традиционные движки по-прежнему остаются самым быстрым и дешёвым вариантом для создания качественных печатных документов. Ни один модель не является оптимальным решением во всех сценариях, поэтому данное руководство переходит от этапа оценки к выбору модель, а затем — к настройке процесса деплой в производственных условиях.

Сопутствующий репозиторий: Испытание OCR — демонстрация в рамках одной ноутбуки, сравнивающая 5 типов документов на 3 модель уровнях (Tesseract → dots.ocr → Gemini 3 Flash), чтобы показать резкие скачки качества и связанные с этим компромиссы в стоимости.

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

OCR теперь определяет качество на последующих этапах обработки

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

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

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

Что означает OCR в эпоху фундаментальных модели

OCR уже вышел за рамки своего первоначального определения, заключавшегося в «преобразовании отпечатанного текста в машинно читаемые символы». Сегодня речь идет о интеллекте документов: извлечении текста, структуры, таблиц, формул и семантического смысла из любого визуального входного материала. Эта область развивается от версии “OCR-1.0” (модульных пайплайны) к версии “OCR-2.0”, при которой единая конвейерная модель-система обрабатывает все этапы автоматически.

Традиционный OCR пайплайн включает три основные фазы:

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

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

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

Практическое замечание: не позволяйте маркировке «конец‑конец» ввести вас в заблуждение. В производственной среде OCR-2.0 объединяется лишь на этапе распознавания. Для генерации изображений всё равно требуется растеризация PDF, нормализация изображений (исправление наклона, коррекция DPI) для обеспечения однородного качества, а также парсинг выводимого контента с целью извлечения структурированных полей из текста модель. пайплайн стал короче, но не исчез полностью.

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

Следующие датасеты показывают, как различные задачи типа OCR приводят к формированию разных метрик. Оценки фиксируются снапшоты на основе соответствующих топ-листов, а не по результатам реального международного ранжирования датасет:

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

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

В начале 2026 года OCR Арена Здесь используется снапшот — пользователи слепо голосовали за результаты прямых сравнений. Порядок этих результатов отличался от OmniDocBench. Эти две таблицы не следует объединять в один счёт, поскольку в одной используются метрики датасет, а в другой — голоса предпочтения.

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

Традиционные движки OCR: остаются актуальными

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

Tesseract для обработки чистого текста на печати

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

EasyOCR

EasyOCR объединяет детектор CRAFT с рекогнайзером CRNN. Благодаря полной акселерации с использованием PyTorch GPU этот инструмент представляет собой быстрый инструмент для создания прототипов и распознавания текста в изображениях.

import easyocr

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

PaddleOCR

PaddleOCR (PP-OCRv5) обеспечивает обнаружение пакетов, их распознавание, а также компоненты деплой. В его документации указано поддерживаемое количество языков — более 106, а также наличие небольшой мобильной версии модель для работы в условиях с ограниченными ресурсами. Перед использованием необходимо проверить точное качество готового продукта модель и уровень поддержки выбранного языка в конкретной версии.

from paddleocr import PaddleOCR

ocr = PaddleOCR(use_angle_cls=True, lang="en")
result = ocr.ocr("receipt.jpg", cls=True)

for line in result[0]:
    bbox, (text, confidence) = line
    if confidence > 0.85:
        print(f"{text} ({confidence:.2f})")

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

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

Специализированная волна OCR

Специализированные инструменты парсинга документов модели, выпущенные в период 2025–2026 годов, включают в себя:

• точки.ocr (1,7 млрд): Открытый исходный код модель, объединяющий функции обнаружения макета, распознавания текста и определения порядка чтения. В его отчёте представлено поддержание более 100 языков с высокой точностью. OmniDocBench Результаты.
• GOT-OCR 2.0: Единая модель с 580 млн параметров типа модель, работающая на одном потребительском устройстве GPU объёмом около 4 ГБ VRAM и способная генерировать текст в формате Markdown, LaTeX и структурированную нотацию.
• DeepSeek-OCR (3B): Внедряет технологию «контекстуальной оптической компрессии» для снижения размера визуальных данных токены. Показатели её производительности throughput следует рассматривать как характерные для конкретного оборудования и датасет.
• Mistral OCR v3: Собственный сервис для извлечения текста и структуры. Тарифы и цифры, связанные с бенчмарк, могут меняться, поэтому при сравнении необходимо проверять актуальные условия платежей и положения договора с поставщиком на карте модель.

Frontier VLMs

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

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

Латентность по уровням

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

Метрики: измерение того, что имеет значение

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

• CER и WER применяются к обычному тексту. Уровень ошибок символов и слов зависит от параметров нормализации, таких как регистр букв, пробелы и знаки препинания, поэтому необходимо скорректировать протокол сравнения перед сравнением модели.
• EMR и Field F1 используются для форм и квитанций. Показатель точного совпадения имеет бинарную природу, что идеально подходит для идентификаторов налогоплательщиков и итоговых сумм. Field F1 позволяет сбалансировать точность и полноту восстановления данных в зависимости от типа поля.
• TEDS применяется к таблицам. Расстояние деревянной правки в представлении таблицы в виде дерева помогает выявлять несоответствия между ячейками, которые скрываются при использовании показателя CER.
• ANLS используется для задач VQA документов. Средняя нормализованная степень схожести Левенштейна позволяет начислять частичные баллы за ответы, содержащие незначительные OCR ошибки.

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

Тестирование VLMs с использованием OpenRouter

OpenRouter Обеспечивает гейтвейй, совместимый с OpenAI, для доступа к модели через несколько поставщиков. ID Модель и поддерживаемые функции запросов могут меняться, поэтому перед запуском примера обязательно уточните их актуальный список в каталоге гейтвейя.

import base64
from openai import OpenAI

client = OpenAI(base_url="https://openrouter.ai/api/v1", api_key="your-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", "anthropic/claude-sonnet-4.5", "qwen/qwen3-vl-8b"]
for model in models:
    print(f"\n--- {model} ---\n{extract_text('receipt.jpg', model)[:200]}...")

Для structured extraction используйте response_format при наличии JSON schema, если выбранный модель и шлюз это поддерживают. Это позволяет сделать ответ структурированным для парсинга; при этом не происходит проверки извлечённых значений на соответствие содержимому изображения:

import json

response = client.chat.completions.create(
    model="google/gemini-3-flash",
    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",
            "schema": {
                "type": "object",
                "properties": {
                    "vendor": {"type": "string"},
                    "date": {"type": "string"},
                    "items": {
                        "type": "array",
                        "items": {
                            "type": "object",
                            "properties": {
                                "description": {"type": "string"},
                                "amount": {"type": "number"},
                            },
                        },
                    },
                    "total": {"type": "number"},
                },
            },
        },
    },
)
receipt = json.loads(response.choices[0].message.content)

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

Приведённая ниже таблица представляет собой устаревшую версию снапшот из Таблица лидеров OmniDocBench и тире.ocr статья (arXiv:2512.02498). Он сравнивает результаты, указанные в той оценке, а не версии модель в текущем состоянии:

В данном снапшот PaddleOCR-VL и ocr показывают более высокие показатели по сравнению с упомянутыми общими VLMs. Этот вывод касается исключительно тестового набора OmniDocBench: одного лишь размера модель недостаточно для прогнозирования его результатов в задачах парсинга документов.

🔧 Попробуйте запустить сами: Испытание OCR Это единый запускаемый ноутбук, предназначенный для тестирования пяти типов документов (чистый счёт-фактура, помятая квитанция, ручно заполненная форма, научная статья и многоязычный документ) на трёх уровнях обработки (Tesseract → dots.ocr → Gemini 3 Flash); в нём показаны показатели CER/EMR рядом с анализом затрат.

Развертывание OCR в продакшене

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

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

Модель поэтапного перехода на резервный вариант

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

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

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

def area_weighted_confidence(ocr_result):
    """Compute area-weighted confidence from PaddleOCR output."""
    total_area, weighted_sum = 0, 0
    for line in ocr_result[0]:
        bbox, (text, conf) = line
        width = bbox[1][0] - bbox[0][0]
        height = bbox[2][1] - bbox[1][1]
        area = abs(width * height)
        weighted_sum += conf * area
        total_area += area
    return weighted_sum / total_area if total_area > 0 else 0

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

Между использованием API и самостоятельной разверткой отсутствует универсальный показатель точки безубыточности в зависимости от объёма обрабатываемых данных. Сравнение следует проводить на основе одинаковой нагрузки:

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

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

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

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

Несколько практических способов снижения рисков:

• Проверка суммы контрольных сумм. Для счетов-фактур необходимо убедиться, что суммы статей соответствуют указанной общей сумме, и выделить несоответствия для дальнейшего рассмотрения человеком.
• Проверки корректности формата с помощью регулярных выражений: даты (отсутствие месяца 13), номера телефонов (правильное количество цифр) и форматы валют.
• Сопоставление статей с общей суммой. Сравнивать извлеченную субсумму VLM с независимой суммой, полученной путем сложения всех его статей.
• Межмодульная проверка модель. Пропускать критически важные поля через два разных модели и выделять случаи несоответствий.
• Независимая перепроверка OCR. Применять второй способ извлечения данных к ключевым показателям и фиксировать различия. Согласованность результатов повышает уровень доверия лишь в том случае, если у обоих методов существенно разные механизмы возникновения ошибок; это не является доказательством их корректности.

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

1. Сопоставьте уровень модель с соответствующей классификацией документов. Для текста без специфических аномалий могут подойти традиционные движки; специализированные и универсальные VLMs оправдывают свою дополнительную стоимость при обработке более сложных страниц.
2. Не сливайте таблицы лидербордов с разными критериями оценки. Показатели OmniDocBench и настройки OCR Arena отвечают на разные вопросы.
3. Калибруйте роутинг. Пороги уверенности, классы документов, степень критичности полей и правила человеческого ревью должны учитываться в рамках одной процедуры оценки.
4. Проверяйте достоверность получаемого результата. Соответствие схеме и внутренние вычисления не могут служить доказательством того, что определённое значение действительно присутствует на изображении.
5. Оценивайте стоимость обработки успешных страниц. При сравнении APIs с вариантом самостоятельной развертки необходимо учитывать количество попыток перезапуска, этапы проверки, выполняемые корректирующие операции и критерии качества.

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

Список литературы

• OCR Таблица лидеров арены - Битвы типа «голова к голове» с участием множества пользователей модель репозиторий OCR Gauntlet - Рабочий ноутбук для тестирования архитектуры трёхуровневой структуры OCR
• OmniDocBench - Парсинг документов от начала до конца эвал тире.ocr - Парсер документов с 1,7 млрд параметров, использующий единый VLM PaddleOCR - Традиционный набор инструментов OCR и модели
• OpenRouter - Единый шлюз доступа для тестирования типа A/B модели