AI-извлечение данных из счетов: LayoutLMv3 и Donut

Почему извлечение данных из счетов ломается на потоке

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

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

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

Цена ошибки — расхождения в учёте, а не потраченные минуты. Счёт, разобранный наполовину, оплачивается дважды или не попадает в реестр, и расхождение всплывает на сверке, когда исправлять уже дороже. Очередь необработанных документов при этом закрывается руками в конце периода.

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

Эффект внедрения: скорость обработки и доля ошибок

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

Главная метрика здесь — доля счетов, прошедших без ручного касания. На поставщиках с устойчивой вёрсткой она держится в районе 85-90%, на новых контрагентах первые документы разбираются вручную, пока система не подтянет шаблон. Документы с низкой уверенностью не «додумываются»: они уходят в очередь проверки с подсветкой спорного поля — ошибка в сумме дороже лишнего клика оператора.

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

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

Способы разбора форм: шаблоны, правила и модели

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

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

Этапы внедрения: от аудита архива до передачи в работу

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

1. Аудит архива. Выгружаем несколько сотен счетов за период, размечаем типы бланков, считаем долю сканов без текстового слоя, поворотов и рукописных правок. На выходе — карта типов документов и честная оценка доли, которую извлечение закроет без оператора.
2. Схема потока документов. Описываем, откуда приходит файл, где хранится оригинал, куда уходит результат и что происходит с полем, если уверенность модели ниже порога. Схему согласуем до настройки.
3. Настройка извлечения. Обучаем модель разметки на бланках заказчика, выделяем реквизиты: номер, дата, контрагент, суммы, налог, позиции. Часть полей закрываем правилами и сверкой по справочникам — это стабильнее, чем доверять всё модели.
4. Проверка на тестовой выборке. Прогоняем на счетах, которых модель не видела, и считаем точность по каждому полю отдельно. Слабые места — позиции, рукописные реквизиты — разбираем вручную, чтобы средняя цифра их не спрятала.
5. Критерии приёмки. Фиксируем до финального прогона: точность по полям, доля счетов на ручную проверку, время обработки пакета, формат выгрузки. Не совпало — дообучаем, а не принимаем как есть.
6. Передача в эксплуатацию. Разворачиваем в контуре заказчика или в закрытом облаке, включаем журналирование и оповещения о падении точности, обучаем операторов, отдаём документацию. Через месяц сверяем фактические метрики с приёмочными и дообучаем на новых бланках.

Что заказчик получает на руки: конфигурации и регламенты

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

• Конфигурация решения — параметры разметки полей, пороги уверенности и правила валидации реквизитов; хранится в репозитории, изменение настройки не требует пересборки модели.
• Схема интеграции — путь документа от почты или скана до учётной системы, точки отказа, форматы обмена и правила повторной отправки без дублей.
• Политики доступа — роли оператора, аналитика и администратора, сроки хранения исходников и результатов распознавания, журнал действий.
• Документация — описание полей счёта и правил сопоставления, инструкция по подключению нового типа документа, разбор типовых ошибок.
• Тестовый корпус — подборка счетов с эталонными значениями и метрикой по каждому полю: после доработки сразу видно, где точность просела.
• Инструкция оператора — как разбирать очередь сомнительных документов и куда смотреть при расхождении сумм.
• Регламент сопровождения — что команда заказчика закрывает сама, что эскалируется, сроки реакции и порядок отката на предыдущую версию конфигурации.

Решение перестаёт зависеть от одного человека: изменения вносятся по инструкции, а качество проверяется на том же корпусе, что и при внедрении.

Кейс: поток входящих документов без ручной сверки

Заказчик — оптовый поставщик с тремя юридическими лицами и потоком около 4 000 входящих счетов и актов в месяц. Бухгалтерия разбирала их вручную: шесть операторов переносили реквизиты и суммы в учётную систему. На пике закрытие периода растягивалось до 11 рабочих дней, а расхождения находились уже на сверке с поставщиками.

Кейс внедрения начался с пилота: одно юрлицо, два массовых типа поставщиков, выборка 600 документов. Разметили поля, обучили модель на этих примерах, добавили правила постобработки — сходимость суммы строк с итогом, проверка реквизитов по справочнику контрагентов, отказ от автоприёмки при любом расхождении. За основу взяли LayoutLMv3: он читает текст вместе с координатами на странице, поэтому уверенно разбирает «плавающую» вёрстку счетов.

Метрики до и после

Точность разбора ключевых полей выросла с 88% до 98%, доля документов, которые проходят без участия человека, — с 37% до 91%. Остальные 9% не теряются: они попадают в очередь проверки, где подсвечены спорные поля, и оператор правит один-два реквизита вместо ввода всего документа.

Закрытие периода сократилось с 11 до 3 рабочих дней, поток вырос до 6 500 документов в месяц без расширения штата. После пилота решение раскатали на остальные юрлица и добавили новые типы форм, а модель дообучается на исправлениях операторов — доля автоприёмки продолжает расти.

Что делать, если шаблонный разбор счетов уже развёрнут?

Шаблонный разбор не нужно останавливать, чтобы начать работать с моделями. Гибридная схема пускает извлечение параллельно на том же входящем потоке: модель обрабатывает скан, правила считают свой вариант, оба результата ложатся в одну карточку с пометкой, какой маршрут дал значения. Расхождения по полям уходят в очередь проверки и пополняют разметку для дообучения.

Миграция разбора опирается на архив уже проведённых счетов: пары «скан — итоговые значения» после правок оператора дают обучающую выборку без ручной разметки. Модели класса LayoutLM и Donut учитывают и текст, и геометрию блока, поэтому обычно хватает нескольких тысяч документов на тип, чтобы поля шапки и табличная часть читались не хуже правил, а на нестандартных бланках поставщиков — заметно точнее.

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

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

Технические сомнения: точность, форматы, интеграции

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

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

Что делать со сканами низкого качества — перекосом, шумом, факсом?

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

Появился новый тип документа после запуска — переделывать всё?

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