Привет, Хабр! Меня зовутИскандер, я - 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.
- Из исходных документов экспортируется текст в «идеальном» виде (ground truth).
- Документы конвертируются в PDF с удалением текстового слоя, чтобы получить изображения страниц, имитирующие сканированные документы.
- К этим PDF документам применяются тестируемые решения для извлечения текста.
- Полученный текст очищается от данных форматирования (маркдаун, html теги и т.п.).
- Полученный текст сравнивается с исходным (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.
- DocsConvertor(≈ 0.1 млрд параметров) — наша собственная разработка. Мы искали решение, которое даёт качественное распознавание без зависимости от GPU: в продакшене это критично и для стоимости инфраструктуры, и для скорости масштабирования. Готовых инструментов с нужным балансом качества и ресурсоэффективности не нашлось — поэтому собрали свой пайплайн из проверенных легковесных компонентов: DocLayout-YOLO (детекция макета), DoclingTablePredictor (структура таблиц), Tesseract OCR (извлечение текста). Результат — высокая точность на CPU при минимальных аппаратных требованиях.
- Docling(≈ 0.1 млрд. параметров) — это открытый Python-пакет, предназначенный для преобразования документов в форматы, пригодные для последующего использования в генеративных ИИ-моделях. Он поддерживает широкий спектр входных форматов, включая PDF, DOCX, PPTX и изображения, и применяет последовательность специализированных ИИ-моделей для анализа макета, распознавания таблиц и извлечения текста на каждой странице документа. На бумаге выглядит солидно, но дьявол — в деталях.
- datalab-to/marker (≈ 0.2 млрд. параметров) — это решение для преобразования сложных неструктурированных документов (PDF, изображения, презентации и др.) в структурированные форматы, такие как Markdown, HTML и JSON. Marker использует композицию нескольких специализированных ИИ-моделей, включая Surya, для точного восстановления логической структуры, форматирования и содержимого документа, что делает его одним из ведущих open-source инструментов в области документной обработки.
- deepseek-ai/DeepSeek-OCR(≈ 3 млрд. параметров) — это современная мультимодальная модель для оптического распознавания символов и понимания структуры документов. Её архитектура основана на двухэтапном подходе: сначала визуальный энкодер DeepEncoder сжимает информацию о макете документа, а затем декодер на базе Mixture-of-Experts (MoE) генерирует текстовое представление. Эта технология «оптического сжатия» позволяет модели эффективно обрабатывать документы высокого разрешения с минимальными вычислительными затратами.
- Qwen/Qwen2.5-VL-7B-Instruct(≈ 7 млрд. параметров) — это мультимодальная языковая модель, которая демонстрирует передовые результаты в разнообразных задачах, включая анализ документов, распознавание диаграмм и визуальные рассуждения. Благодаря своей универсальности и высокой производительности, модель является мощным инструментом для комплексного мультимодального анализа.
- datalab-to/chandra(≈ 9 млрд. параметров) — это open-source OCR-модель для преобразования изображений и PDF-файлов в структурированные форматы (Markdown, HTML, JSON) с сохранением исходного макета. Chandra отличается продвинутыми возможностями: она умеет распознавать рукописный текст, сложные математические формулы, точно реконструировать формы, чекбоксы и таблицы, а также поддерживает более 40 языков. Это делает её одним из самых универсальных решений для обработки сложных и разнообразных документов.
- deepseek-ai/DeepSeek-OCR-2(≈ 3 млрд. параметров) – это обновлённая версия модели DeepSeek-OCR, в которой вместо оригинального CLIP-энкодера используется Qwen2-энкодер, а также внедрена новая архитектура DeepEncoder V2. Этот энкодер реализует механизм Visual Causal Flow, позволяющий модели динамически переупорядочивать визуальные токены на основе их семантической значимости, а не фиксированного пространственного порядка. Кроме того, была скорректирована обучающая выборка. Решение DeepSeek-OCR-2 вышло уже в процессе подготовки статьи, и мы решили добавить его в тестирование, чтобы оценить актуальные возможности модели.
- 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
datalab-to/marker
deepseek-ai/DeepSeek-OCR
Qwen/Qwen2.5-VL-7B-Instruct
datalab-to/chandra
deepseek-ai/DeepSeek-OCR-2
Qwen/Qwen3-VL-8B-Instruct
Результаты тестирования на датасете № 2
table_recognize
total_editops
total_editops_without_formatting
DocsConvertor
datalab-to/marker
deepseek-ai/DeepSeek-OCR
Qwen/Qwen2.5-VL-7B-Instruct
datalab-to/chandra
deepseek-ai/DeepSeek-OCR-2
Qwen/Qwen3-VL-8B-Instruct
Результаты тестирования на датасете № 3
table_recognize
total_table_shape_accuracy
total_editops
total_editops_without_formatting
DocsConvertor
datalab-to/marker
deepseek-ai/DeepSeek-OCR
Qwen/Qwen2.5-VL-7B-Instruct
datalab-to/chandra
deepseek-ai/DeepSeek-OCR-2
Qwen/Qwen3-VL-8B-Instruct
Результаты тестирования на датасете № 4
table_recognize
total_table_shape_accuracy
total_editops
total_editops_without_formatting
DocsConvertor
datalab-to/marker
deepseek-ai/DeepSeek-OCR
Qwen/Qwen2.5-VL-7B-Instruct
datalab-to/chandra
deepseek-ai/DeepSeek-OCR-2
Qwen/Qwen3-VL-8B-Instruct
Результаты тестирования на датасете № 5
GPU Utilization
Time (1 thread)
Page/Time (1 thread)
Time (multi-threaded)
Page/Time (multi-threaded)
DocsConvertor
datalab-to/marker
deepseek-ai/DeepSeek-OCR
Qwen/Qwen2.5-VL-7B-Instruct
datalab-to/chandra
deepseek-ai/DeepSeek-OCR-2
Qwen/Qwen3-VL-8B-Instruct
Результаты тестирования на датасете №6
Обобщенные результаты
Результатов накопилось много, и смотреть на них по отдельности — глаз разбегается. Поэтому свели всё в одну таблицу: качество текста, таблицы, скорость, параллелизм.
Ошибка распозн. таблиц*
Ошибка распозн. текста, %
Распозн. структуры таблицы, %
Ошибка распозн. текста в таблицах, %
Скорость обработки, c
Макс. число паралл. обработок*
DocsConvertor
datalab-to/marker
deepseek-ai/DeepSeek-OCR
Qwen/Qwen2.5-VL-7B-Instruct
datalab-to/chandra
deepseek-ai/DeepSeek-OCR-2
Qwen/Qwen3-VL-8B-Instruct
*Ошибка распознавания таблиц – для данной категории считалась средняя абсолютная ошибка.
*Макс. число параллельных обработок – число, определенное по Рисунку А1.1, это количество страниц при которой скорость обработки перестает расти.
Чтобы совсем не мучиться с цифрами — перевели всё в ранги. Кто первый, кто последний, по каждой категории отдельно.
Ошибка распозн. таблиц*
Ошибка распозн. текста, %
Распозн. структуры таблицы, %
Ошибка распозн. текста в таблицах, %
Скорость обработки, c
Макс. число паралл. обработок*
DocsConvertor
datalab-to/marker
deepseek-ai/DeepSeek-OCR
Qwen/Qwen2.5-VL-7B-Instruct
datalab-to/chandra
deepseek-ai/DeepSeek-OCR-2
Qwen/Qwen3-VL-8B-Instruct
Ну и финальный аккорд — усредняем ранги и получаем итоговую таблицу. Это и есть ответ на главный вопрос: кто лучший, если смотреть сразу по всем критериям.
Среднее значение ранга
DocsConvertor
datalab-to/marker
deepseek-ai/DeepSeek-OCR
Qwen/Qwen2.5-VL-7B-Instruct
datalab-to/chandra
deepseek-ai/DeepSeek-OCR-2
Qwen/Qwen3-VL-8B-Instruct
Проведённое тестирование выявило ключевую закономерность: ни одно из существующих 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-внедрений, где стоимость инфраструктуры и независимость от дефицитного железа критичны, это может быть определяющим фактором.
Практические рекомендации:
Рекомендуемое решение
Обоснование
Документы с таблицами, ограниченные ресурсы
DocsConvertor
Лучшая точность по таблицам, работа на CPU
Максимальная точность текста, есть GPU
datalab-to/chandra
Минимальная ошибка распознавания
Плотные табличные данные с цифрами
deepseek-ai/DeepSeek-OCR-2
Лучшее качество текста внутри ячеек
Высокая скорость, простые документы
datalab-to/marker
Максимальная производительность в однопоточном режиме
Высокая точность, большое количество запросов
deepseek-ai/DeepSeek-OCR
Низкая ошибка распознавания, высокая масштабируемость
Быстрые эксперименты, ограниченные ресурсы
Низкий порог входа
Отдельно про Docling: в продакшен его тащить точно не нужно. Документация сырая, memory leak’и вылезают при длительной работе, и в целом ощущение, что инструмент ещё не дорос до серьёзных нагрузок. Для быстрого прототипа или разового эксперимента — сойдёт, но не более.
Рынок OCR-решений меняется быстро, и я уверен, что через полгода часть этих результатов устареет. Постараемся держать бенчмарк актуальным, но без фанатизма. Если знаете что-то, что мы пропустили — пишите в комментарии, будем рады.
Для обработки документов в «Честном знаке» мы решили использовать комбинированный подход. Основным OCR-решением сталDeepSeek-OCR-2— он показал наиболее сбалансированные результаты по всем ключевым метрикам. При этом часть нашей инфраструктуры работает без GPU, и в этих сценариях лучше всего себя показываетDocsConvertor: он стабильно справляется со сложными документами, даёт высокую точность на таблицах, требует минимальных ресурсов и при этом выдаёт хорошо интерпретируемый результат.
Автор статьи:Закирьянов Искандер- AI-инженер, Лаборатории искусственного интеллекта «Честного знака»
