Как мы оценивали OCR на русских документах — и почему все, что «распозналось», можно читать без смеха

Привет, Хабр! Меня зовут Искандер, я — AI-инженер в Лаборатории искусственного интеллекта «Честного знака», и недавно мы всерьёз занялись оцифровкой русскоязычных документов: от простых текстовых файлов до сложных документов с таблицами, списками и изображениями, поступающими из различных систем. Цель — чтобы машина читала их быстро, точно и без творческой интерпретации.

Почему это так критично для нас? Потому что каждый день к нам приходят сотни и тысячи страниц: контракты, акты, техдокументация, анкеты… Всё это надо не просто перевести в текст, а сразу использовать — для поиска, анализа, генерации выжимок или отправки в другие сервисы. А если на выходе OCR вместо «субподрядчика» выдаст «cy6пoдpялчика» — начнутся проблемы, которые уже не починишь ни регулярками, ни sense of humor’ом.

На рынке сегодня большое количество OCR-решений — и все они активно развиваются, обновляются и обещают «максимальную точность даже на луне». Но как понять, кто из них реально справляется с нашими задачами? У нас своя специфика: кириллица, широкий разброс форматов — от простых текстов до многостраничных PDF с техдокументацией — и, что важнее всего, требование стабильно работать на реальных документах, а не на идеальных примерах из туториалов.

Чтобы не гадать на кофейной гуще, мы собрали собственный модуль тестирования. С его помощью сформировали репрезентативный набор данных — максимально приближенный к тому, с чем сталкиваемся ежедневно, — и протестировали лучшие open-source OCR-движки в боевых условиях. Что из этого вышло — расскажу дальше!

На чем тестировали

Чтобы оценить, как система справляется с распознаванием текста в русскоязычных документах, было собрано 6 датасетов из реальных файлов в формате DOCX.

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

Важно: все документы в датасетах изначально созданы в DOCX (не рукописные). Для тестирования они конвертировались в PDF с удалением текстового слоя — чтобы имитировать условия работы со сканами.

Датасет 1 — документы, содержащие сплошной текст без форматирования (простые абзацы без выделений, списков, колонок и выравниваний).

Датасет 2 — документы с текстом, включающим базовое форматирование: жирный/курсивный шрифт, маркированные и нумерованные списки, заголовки, абзацы с отступами и т.п.

Датасет 3 — документы, содержащие простые таблицы (таблицы с чёткой структурой, без объединённых ячеек, вложенных элементов или сложного оформления).

Датасет 4 — документы со сложными таблицами и текстом с форматированием (таблицы с объединёнными ячейками, вложенными структурами, многоуровневыми заголовками, нестандартным выравниванием и/или фоновым оформлением, изображениями). Пример из этого датасета показан на Рисунке 1.1.

Датасет 5 – один из документов датасета 4 для тестирования производительности OCR-решений.

Датасет 6 — повторяющий по содержанию датасет 4, но используемый для измерения производительности обработки OCR-решений в многопоточном режиме.

Как тестировали

Оценка качества распознавания текста

Для объективной оценки качества различных решений распознавания текста разработан пайплайн тестирования, который использовался на датасетах 1-4.

1. Из исходных документов экспортируется текст в «идеальном» виде (ground truth).

2. Документы конвертируются в PDF с удалением текстового слоя, чтобы получить изображения страниц, имитирующие сканированные документы.

3. К этим PDF документам применяются тестируемые решения для извлечения текста.

4. Полученный текст очищается от данных форматирования (маркдаун, html теги и т.п.).

5. Полученный текст сравнивается с исходным (ground truth) с помощью различных метрик точности.

Оценка производительности распознавания текста

В рамках оценки производительности различных OCR-решений проводился тест на обработку одного и того же большого документа (датасет 5). Основной метрикой являлось время и скорость распознавания текста.

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

В то же время современные решения на основе Vision-Language Models (VLM) обладают возможностью пакетной и параллельной обработки. Для таких решений дополнительно была проведена оценка производительности на датасете 6 в многопоточном режиме.

Как оценивали

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

Оценка качества распознавания текста

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

• total_editops — средний процент ошибок (вставок, замен и удалений символов) по всем документам в выборке с учётом исходного форматирования (включая пробелы, переносы строк, пунктуацию и оформление);

• total_editops_without_formatting — аналогичный показатель, рассчитанный без учета форматирования (пробелов, переносов строк и т.п.), позволяющий оценить точность распознавания именно содержательной части текста.

Обе метрики выражены в процентах и усреднены по всему датасету, предназначенном для оценки качества текстового распознавания.

Оценка качества распознавания таблиц

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

• table_recognize — агрегированный показатель корректности детекции таблиц. Для каждого документа он принимает значения:

  • –1, если в оригинале таблицы отсутствовали, но алгоритм ошибочно их обнаружил (ложноположительное срабатывание);

  • 0, если таблицы присутствовали и были корректно распознаны (структурно и содержательно);

  • 1, если таблицы присутствовали, но не были обнаружены (ложноотрицательное срабатывание).

    Итоговое значение — среднее по всем файлам в выборке: чем ближе к 0, тем выше точность детекции.

• total_table_shape_accuracy — средняя точность в процентах совпадения размерности (числа строк и столбцов) распознанной таблицы с эталонной, рассчитанная только для документов, в которых таблица была обнаружена.

• total_editops_table — средний процент ошибок в текстовом содержании таблиц с учётом форматирования (включая выравнивание, пробелы, границы ячеек и т.п.).

• total_editops_without_formatting_table — средний процент ошибок в текстовом содержании таблиц без учёта форматирования, что позволяет оценить качество распознавания именно табличных данных, независимо от структурных особенностей их представления.

Оценка производительности распознавания текста

Для производительности смотрели на три метрики:

• Time — среднее время обработки одного документа, рассчитанное по всем документам в соответствующем датасете (в секундах).

• Page/time — средняя скорость обработки, рассчитанное по всем документам в соответствующем датасете (в секундах).

• GPU utilization — максимальное использование GPU ресурсов во время проведения экспериментов.

Участники и железо

Для тестирования выбрали различные open-source решения, которые включают и классические модульные решения, так и VLM.

1. DocsConvertor (≈ 0.1 млрд параметров) — наша собственная разработка. Мы искали решение, которое даёт качественное распознавание без зависимости от GPU: в продакшене это критично и для стоимости инфраструктуры, и для скорости масштабирования. Готовых инструментов с нужным балансом качества и ресурсоэффективности не нашлось — поэтому собрали свой пайплайн из проверенных легковесных компонентов: DocLayout-YOLO (детекция макета), DoclingTablePredictor (структура таблиц), Tesseract OCR (извлечение текста). Результат — высокая точность на CPU при минимальных аппаратных требованиях.

2. Docling (≈ 0.1 млрд. параметров) — это открытый Python-пакет, предназначенный для преобразования документов в форматы, пригодные для последующего использования в генеративных ИИ-моделях. Он поддерживает широкий спектр входных форматов, включая PDF, DOCX, PPTX и изображения, и применяет последовательность специализированных ИИ-моделей для анализа макета, распознавания таблиц и извлечения текста на каждой странице документа. На бумаге выглядит солидно, но дьявол — в деталях.

3. datalab-to/marker (≈ 0.2 млрд. параметров) — это решение для преобразования сложных неструктурированных документов (PDF, изображения, презентации и др.) в структурированные форматы, такие как Markdown, HTML и JSON. Marker использует композицию нескольких специализированных ИИ-моделей, включая Surya, для точного восстановления логической структуры, форматирования и содержимого документа, что делает его одним из ведущих open-source инструментов в области документной обработки.

4. deepseek-ai/DeepSeek-OCR (≈ 3 млрд. параметров) — это современная мультимодальная модель для оптического распознавания символов и понимания структуры документов. Её архитектура основана на двухэтапном подходе: сначала визуальный энкодер DeepEncoder сжимает информацию о макете документа, а затем декодер на базе Mixture-of-Experts (MoE) генерирует текстовое представление. Эта технология «оптического сжатия» позволяет модели эффективно обрабатывать документы высокого разрешения с минимальными вычислительными затратами.

5. Qwen/Qwen2.5-VL-7B-Instruct (≈ 7 млрд. параметров) — это мультимодальная языковая модель, которая демонстрирует передовые результаты в разнообразных задачах, включая анализ документов, распознавание диаграмм и визуальные рассуждения. Благодаря своей универсальности и высокой производительности, модель является мощным инструментом для комплексного мультимодального анализа.

6. datalab-to/chandra (≈ 9 млрд. параметров) — это open-source OCR-модель для преобразования изображений и PDF-файлов в структурированные форматы (Markdown, HTML, JSON) с сохранением исходного макета. Chandra отличается продвинутыми возможностями: она умеет распознавать рукописный текст, сложные математические формулы, точно реконструировать формы, чекбоксы и таблицы, а также поддерживает более 40 языков. Это делает её одним из самых универсальных решений для обработки сложных и разнообразных документов.

7. deepseek-ai/DeepSeek-OCR-2 (≈ 3 млрд. параметров) – это обновлённая версия модели DeepSeek-OCR, в которой вместо оригинального CLIP-энкодера используется Qwen2-энкодер, а также внедрена новая архитектура DeepEncoder V2. Этот энкодер реализует механизм Visual Causal Flow, позволяющий модели динамически переупорядочивать визуальные токены на основе их семантической значимости, а не фиксированного пространственного порядка. Кроме того, была скорректирована обучающая выборка. Решение DeepSeek-OCR-2 вышло уже в процессе подготовки статьи, и мы решили добавить его в тестирование, чтобы оценить актуальные возможности модели.

8. Qwen/Qwen3-VL-8B-Instruct — это мультимодальная языковая модель, представляющая собой значительное обновление по сравнению с предыдущими версиями. Она поддерживает контекст длиной до 256K токенов и демонстрирует улучшенные способности в распознавании текста на изображениях (OCR, а также повышенную устойчивость к сложным условиям, таким как низкая освещённость, размытость или наклон текста.

Все эксперименты проводились на единой вычислительной платформе для обеспечения сопоставимости результатов. Конфигурация тестовой системы включала: процессор AMD EPYC 7513 32-Core Processor, 1 TБ оперативной памяти и графический ускоритель NVIDIA A100 с 40 ГБ видеопамяти.

Все VLM-решения в рамках исследования тестировались с использованием фреймворка vLLM 0.12.0, что обеспечивало единые условия для сравнения производительности и масштабируемости моделей.

Итак, участники собраны, арена размечена, секундомер на старте. Пусть лучший распознает!

Скрытый текст

Полученные результаты тестирования

Наилучшие метрики среди всех OCR-решений выделены полужирным шрифтом

Результаты тестирования на датасете № 1

	table_recognize	total_editops	total_editops_without_formatting
DocsConvertor	0	1,23	0,09
Docling	-0,2	14,39	9,76
datalab-to/marker	0	0,98	0,26
deepseek-ai/DeepSeek-OCR	0	1	0,04
Qwen/Qwen2.5-VL-7B-Instruct	0	0,83	0,094
datalab-to/chandra	0	0,78	0,12
deepseek-ai/DeepSeek-OCR-2	0	1,09	0,03
Qwen/Qwen3-VL-8B-Instruct	0	1,18	0,056

Результаты тестирования на датасете № 2

	table_recognize	total_editops	total_editops_without_formatting
DocsConvertor	0	2,52	0,56
Docling	0	10,79	7,92
datalab-to/marker	0	5,21	3,44
deepseek-ai/DeepSeek-OCR	0	1,68	0,52
Qwen/Qwen2.5-VL-7B-Instruct	0	1,05	0,17
datalab-to/chandra	0	0,92	0,22
deepseek-ai/DeepSeek-OCR-2	-0,4	6,99	3,88
Qwen/Qwen3-VL-8B-Instruct	0	1,25	0,08

Результаты тестирования на датасете № 3

	table_recognize	total_table_shape_accuracy	total_editops	total_editops_without_formatting
DocsConvertor	0,17	100	2,68	1,13
Docling	0	83,33	10,47	8,21
datalab-to/marker	0,33	75	6,76	3,98
deepseek-ai/DeepSeek-OCR	0,33	100	0,31	0,03
Qwen/Qwen2.5-VL-7B-Instruct	0,17	100	0,62	0,2
datalab-to/chandra	0,17	100	0,79	0,43
deepseek-ai/DeepSeek-OCR-2	0	100	0,52	0,04
Qwen/Qwen3-VL-8B-Instruct	0,5	100	0,24	0,05

Результаты тестирования на датасете № 4

	table_recognize	total_table_shape_accuracy	total_editops	total_editops_without_formatting
DocsConvertor	0	77,97	9,03	4,22
Docling	0	34,17	11,06	6,42
datalab-to/marker	0,03	47,41	13,19	4,04
deepseek-ai/DeepSeek-OCR	0,15	38,68	4,82	2,1
Qwen/Qwen2.5-VL-7B-Instruct	0,05	31,9	7,39	4,86
datalab-to/chandra	0,05	53,5	5,73	1,88
deepseek-ai/DeepSeek-OCR-2	0,016	64,17	3	0,56
Qwen/Qwen3-VL-8B-Instruct	0,2	41,84	3,66	0,62

Результаты тестирования на датасете № 5

	GPU Utilization	Time (1 thread)	Page/Time (1 thread)	Time (multi-threaded)	Page/Time (multi-threaded)
DocsConvertor	0,02	954,33	0,07	—	—
Docling	0,27	108,86	0,64	—	—
datalab-to/marker	0,34	96,76	0,72	—	—
deepseek-ai/DeepSeek-OCR	0,85	167,25	0,42	33,81	2,07
Qwen/Qwen2.5-VL-7B-Instruct	0,85	299,17	0,23	56,05	1,25
datalab-to/chandra	0,85	579,34	0,12	76,58	0,91
deepseek-ai/DeepSeek-OCR-2	0,85	102,65	0,68	37,24	1,88
Qwen/Qwen3-VL-8B-Instruct	0,85	341,02	0,21	60,37	1,16

Результаты тестирования на датасете №6

Обощенные результаты

Результатов накопилось много, и смотреть на них по отдельности — глаз разбегается. Поэтому свели всё в одну таблицу: качество текста, таблицы, скорость, параллелизм.

*Ошибка распознавания таблиц – для данной категории считалась средняя абсолютная ошибка.

*Макс. число параллельных обработок – число, определенное по Рисунку А1.1, это количество страниц при которой скорость обработки перестает расти.

Чтобы совсем не мучиться с цифрами — перевели всё в ранги. Кто первый, кто последний, по каждой категории отдельно.

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

Выводы

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

По точности извлечения неструктурированного текста лидируют решения на базе Vision-Language Models. Сhandra показал минимальную ошибку — 0,51%, что критично для задач, где недопустимы искажения: юридические документы, финансовая отчётность, контракты. Близкие результаты демонстрируют семейство моделей Qwen (0,536 % и 0,642 %). Однако все три решения требуют GPU-инфраструктуры, что существенно влияет на стоимость эксплуатации и усложняет масштабирование. Работа с таблицами — отдельный вызов.

Здесь картина принципиально иная. DocsConvertor показал лучшие результаты как по детекции таблиц (ошибка 0,043), так и по восстановлению их структуры (88,985% точности). Это объясняется архитектурой решения: комбинация специализированных компонентов (DocLayout-YOLO для макета, DoclingTablePredictor для структуры) оказалась эффективнее универсальных VLM-моделей в задачах, требующих точного понимания геометрии документа. При этом для распознавания текста внутри ячеек VLM-решения сохраняют преимущество — DeepSeek-OCR-2 показал ошибку 1,03 % против 4,265% у DocsConvertor.

Производительность и масштабирование.

В однопоточном режиме быстрее всех работает Marker (0,72 стр/сек), однако классические OCR-движки архитектурно ограничены в параллелизации. VLM-решения здесь выигрывают: DeepSeek-OCR способен обрабатывать до 2048 параллельных запросов, что делает его предпочтительным для высоконагруженных сценариев — при условии доступности соответствующих GPU-ресурсов.

На момент написания статьи DeepSeek-OCR-2 официально не поддерживается в vLLM, гоняли через сырой экспериментальный скрипт. Так что цифры по производительности для неё — скорее ориентир, чем приговор. Как только появится нормальная поддержка — перепрогоним и обновим результаты.

Инфраструктурный контекст.

Отдельно стоит отметить разницу в требованиях к железу. DocsConvertor работает на CPU с минимальной нагрузкой (GPU utilization — 0,02), тогда как VLM-решения утилизируют GPU на 85%. Для enterprise-внедрений, где стоимость инфраструктуры и независимость от дефицитного железа критичны, это может быть определяющим фактором.

Практические рекомендации:

Отдельно про Docling: в продакшен его тащить точно не нужно. Документация сырая, memory leak’и вылезают при длительной работе, и в целом ощущение, что инструмент ещё не дорос до серьёзных нагрузок. Для быстрого прототипа или разового эксперимента — сойдёт, но не более.

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

Наш выбор

Для обработки документов в «Честном знаке» мы решили использовать комбинированный подход. Основным OCR-решением стал DeepSeek-OCR-2 — он показал наиболее сбалансированные результаты по всем ключевым метрикам. При этом часть нашей инфраструктуры работает без GPU, и в этих сценариях лучше всего себя показывает DocsConvertor: он стабильно справляется со сложными документами, даёт высокую точность на таблицах, требует минимальных ресурсов и при этом выдаёт хорошо интерпретируемый результат.

Автор статьи: Закирьянов Искандер — AI-инженер, Лаборатории искусственного интеллекта «Честного знака»