Как «Честный знак» тестировал OCR для русских документов и что из этого вышло

Каждый день через системы «Честного знака» проходят тысячи страниц: контракты, акты, технические регламенты, анкеты. Задача — не просто перевести их в текст, а получить данные, пригодные для поиска, анализа и передачи в другие сервисы. Одна ошибка распознавания в названии контрагента или реквизите способна сломать автоматизированный пайплайн, и никакие регулярные выражения её не исправят.

Чтобы выбрать подходящий инструмент, команда лаборатории ИИ построила собственный модуль тестирования и сформировала шесть датасетов из реальных DOCX-файлов. Документы охватывают четыре типа сложности: сплошной текст без форматирования, текст с заголовками и списками, простые таблицы с чёткой структурой и сложные таблицы с объединёнными ячейками, вложенными структурами и фоновым оформлением. Два дополнительных датасета предназначены исключительно для замеров производительности — один для однопоточного режима, второй, из 4662 страниц, для параллельной обработки. Все файлы перед тестом конвертировались в PDF с удалённым текстовым слоем: так имитируются условия работы со сканами, а не с машиночитаемыми PDF.

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

Среди участников тестирования — как классические модульные OCR-движки, так и современные Vision-Language Models (VLM). Последние умеют обрабатывать страницы пакетами и параллельно, тогда как традиционные движки работают строго последовательно и не поддерживают эффективную многопоточность из-за архитектурных ограничений. Это принципиально важно при промышленных объёмах: скорость обработки измерялась в секундах на документ и страницах в секунду, а также фиксировалась максимальная загрузка GPU.

Один из участников — собственная разработка команды, DocsConvertor с примерно 100 миллионами параметров. Модель создавалась с прицелом на работу без GPU: в продакшен-среде это снижает стоимость инфраструктуры и упрощает масштабирование. Большинство коммерческих и open-source OCR-решений либо требуют видеокарту для приемлемой скорости, либо показывают деградацию качества на кириллице — особенно в таблицах со сложной структурой. Именно этот разрыв между обещанной «максимальной точностью» и реальным поведением на русскоязычных документах и стал поводом для создания собственного бенчмарка.