Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Неточную автоматическую разметку документов оказалось выгоднее проверять, чем создавать вручную. В работе DFKI и RPTU прототип GAIDA сократил работу с областями и текстом до 80,9%; препринт не проходил рецензирование, а числа получили сами авторы. Такой подход меняет критерий выбора системы: важна не только точность модели, но и время, которое человек тратит на исправления.
Человек получает редактируемый черновик документа
GAIDA связывает оптическое распознавание текста (OCR), LLM и интерфейс Label Studio в один конвейер. Сначала OCR находит области документа, распознаёт текст и возвращает координаты. Затем LLM присваивает каждой области одну из разрешённых смысловых меток, после чего человек исправляет границы, текст и классы.
Система не принимает машинный результат как готовую разметку. Экспорт становится доступен после проверки, поэтому модель отвечает за черновик, а человек — за итоговый набор данных. Ошибка распознавания требует поправить текст, неверная рамка — изменить структуру, неправильный класс — заменить метку.
Компоненты разделены общим форматом данных. OCR-модулю достаточно вернуть текст, координаты и уверенность, а LLM — принять структурированный запрос и выдать метки в машиночитаемом виде. Благодаря этому команда может менять движок распознавания, модель или правила запроса, не перестраивая интерфейс проверки.
GAIDA также записывает трудозатраты по стадиям. Авторы отдельно сравнивали ручное создание областей с проверкой результата OCR, а ручное назначение классов — с исправлением меток от LLM. Это помогает понять, какой компонент действительно экономит время, а какой лишь переносит работу в другой участок процесса.
Неточные метки всё равно ускорили работу
При назначении смысловых классов обе сравниваемые процедуры начинались с одинаковых, уже правильных областей и текстов. Поэтому результат LLM не смешивался с ошибками распознавания. На FUNSD проверка предварительных меток сократила время на 68,1%, а на WildReceipt — на 73,7%.
Метки при этом не были безошибочными. Micro F1, то есть сводная мера совпадения классов по всем областям, составила 78,86% на FUNSD и 86,98% на WildReceipt. Практический результат здесь важнее попытки полностью автоматизировать процесс: оставшиеся ошибки оказалось быстрее найти и исправить, чем назначать каждый класс с нуля.
На качество сильнее влиял выбор модели, чем усложнение запроса. Более подробные инструкции не давали стабильного улучшения, а фиксированный порядок принятия решений ухудшил результат на FUNSD. Лучше сработали правила, составленные после разбора типичных ошибок, но их настраивали на тех же данных, где затем измеряли качество, поэтому этот результат не показывает переносимость на новые документы.
Планы стоит менять вокруг проверки, а не полной автоматизации
Для команды, которая строит разметку счетов, форм или чеков, работа предлагает практичную архитектурную границу. OCR и LLM готовят предложения, интерфейс позволяет быстро их исправить, а журнал времени показывает стоимость каждого этапа. Необязательно ждать модель, которая выдаёт готовую разметку без контроля.
При выборе компонентов одной F1 недостаточно. Полезнее провести внутреннее сравнение на реальных документах и измерить, сколько времени занимает исправление пропущенных областей, распознанного текста и смысловых классов. Модель с более высокой метрикой может проиграть, если её ошибки трудно заметить или неудобно исправлять.
Архитектуру применили и к арабским чекам: код основного конвейера не меняли, а настроили распознавание смешанного письма, направление текста и правила запроса. Так собрали AraReceipt из 100 изображений с 25 классами. Этот пример подтверждает повторное использование конструкции, но не сравнивает её скорость с полностью ручной разметкой арабских документов.
Границы эксперимента заметно сужают выводы. Время измерял один разметчик, который всегда сначала выполнял ручной проход, а затем работал с подсказками на тех же изображениях. Проверка охватывала 50 документов FUNSD и 20 документов WildReceipt, причём стадии засекали отдельно, а не как непрерывный процесс. Поэтому проценты нельзя складывать в общую оценку экономии, а знакомство с документами могло ускорить повторный проход.
GAIDA стоит рассматривать не как доказательство готовой нормы производительности, а как шаблон эксперимента для собственной системы. Его главное следствие для планирования — заложить редактируемые предложения, сменные компоненты и измерение времени исправлений до того, как команда начнёт оптимизировать модели по одной итоговой метрике.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
