Извлечение полей из документов — задача, где модель действительно незаменима: шаблонные парсеры ломаются от смены формы, а модель понимает документ, который видит впервые.
И это же задача, где чаще всего переоценивают результат. Модель почти всегда возвращает что-нибудь. Она не скажет «я не уверена» по своей инициативе и не сообщит, что распознала сумму с ошибкой. Ответ выглядит одинаково убедительно и когда он верный, и когда нет.
Отсюда главный принцип:
> Извлечение — это не «модель достала поля», а «модель предложила значения, а код их проверил».
Проверки — не перестраховка, а половина работы. В проектах по автоматизации процессов на них уходит примерно столько же времени, сколько на само извлечение.
Что нужно описать до начала
Схему полей. Не «достань всё важное», а точный список: имя поля, тип, обязательность, формат. Модель должна возвращать ответ строго в заданной форме — «Структурированный вывод модели».
Что делать с отсутствующим. Поле должно иметь явное значение «нет в документе». Иначе модель заполнит его правдоподобным вымыслом — это её обычное поведение при нехватке данных.
Правила нормализации. Даты к одному формату, суммы к числу, названия контрагентов к справочнику. Делает код, не модель.
Проверки. Отдельный список — ниже.
Порог неуверенности. При каком качестве извлечения документ уходит человеку.
Проверки, которые обязаны быть
Каждое поле, имеющее формальную структуру, проверяется программно. Это самая дешёвая и самая результативная часть.
| Что проверяется | Как |
|---|---|
| ИНН, КПП, СНИЛС, номер счёта | контрольная сумма по алгоритму |
| Даты | формат, разумность диапазона, порядок (дата акта не раньше договора) |
| Суммы | сумма прописью против цифрами |
| Позиции | сумма строк равна итогу |
| НДС | соответствие ставке и базе |
| Контрагент | найден в справочнике |
| Номер документа | формат, отсутствие дубля |
Контрольные суммы — самое ценное. ИНН с неверной контрольной суммой означает ошибку распознавания, и это ловится мгновенно, без всякого сравнения с эталоном.
Сверка итога с суммой строк ловит второй класс ошибок: пропущенную или задвоенную позицию. Модель, пропустившая строку в таблице, вернёт правдоподобный результат, и обнаружить это можно только арифметикой.
Отдельно повторю то, что относится ко всей автоматизации: арифметику делает код. Просить модель сложить позиции — надёжный способ получить ошибку, о которой никто не узнает.
Как работать с неуверенностью
Модель не сообщает о неуверенности сама, поэтому её приходится выводить косвенно.
Несколько прогонов. Один документ обрабатывается дважды-трижды. Совпали результаты — вероятно, верно. Разошлись — на проверку. Дорого, применяется к критичным полям.
Проверки как признак. Не прошла контрольная сумма — неуверенность обнаружена без всякой модели.
Явная просьба указать уверенность. Модель возвращает оценку по каждому полю. Работает хуже, чем хочется: оценка систематически завышена. Как вспомогательный признак годится, как единственный — нет.
Наличие подтверждения в тексте. Модель возвращает не только значение, но и фрагмент документа, откуда оно взято. Код проверяет, что фрагмент действительно есть в исходнике. Ловит выдуманные значения — приём, аналогичный цитированию источников в RAG.
Последний способ недооценён и почти бесплатен. Значение, для которого не нашлось подтверждающего фрагмента, — почти наверняка выдумка.
Разбор: счета от 200 поставщиков
Задача. Бухгалтерия получает 1 200 счетов в месяц от разных поставщиков. Формы у всех свои. Нужно завести в учётную систему.
Почему не шаблоны. Пробовали настраивать шаблоны под каждого поставщика. Их оказалось около 200, и они менялись: поставщик обновлял форму, шаблон ломался молча, ошибка обнаруживалась при сверке в конце месяца.
Что сделали.
Описали схему: номер, дата, поставщик, ИНН, позиции (наименование, количество, цена, сумма), НДС, итого. Каждое поле с типом и признаком обязательности.
Модель возвращала значения плюс фрагмент-подтверждение для каждого.
Код проверял: контрольную сумму ИНН, соответствие суммы строк итогу, ставку НДС, наличие фрагмента-подтверждения в тексте документа, наличие поставщика в справочнике.
Что показал первый месяц.
Извлечение работало заметно лучше шаблонов на новых формах — ради этого всё и делалось.
Но проверки отбраковывали примерно каждый шестой документ. Разбор причин:
| Причина отбраковки | Доля | Что оказалось |
|---|---|---|
| Сумма строк ≠ итог | ~40% | пропущена позиция в длинной таблице |
| ИНН не прошёл контроль | ~25% | ошибка распознавания скана |
| Поставщик не в справочнике | ~20% | действительно новый поставщик |
| Нет фрагмента-подтверждения | ~10% | выдуманное значение |
| Прочее | ~5% | — |
Первая строка — самая поучительная. Пропуск позиции в таблице на 15–20 строк оказался систематической проблемой. Модель возвращала правдоподобный результат, и без арифметической сверки эти счета ушли бы в учёт с заниженной суммой.
Исправили тем, что таблицу стали обрабатывать отдельно от шапки: сначала извлечь все строки, потом проверить их число против видимого в документе, потом сложить кодом.
Вторая строка решилась предобработкой сканов и правилом: при неудачной контрольной сумме — повторное распознавание области с повышенным качеством.
Что осталось человеку. Около 8% счетов после доработок: новые поставщики, действительно нестандартные документы, плохие сканы. Им форма приходила заполненной, с подсвеченным полем, вызвавшим сомнение.
Итог. Время на счёт сократилось существенно, но главное не это. Главное — исчезли молчаливые ошибки: раньше неверно введённая сумма обнаруживалась при сверке в конце месяца, теперь документ либо проходит все проверки, либо попадает человеку сразу.
Как измерять качество
Точность извлечения меряется по полям, а не по документам: «документ обработан верно» скрывает, какое именно поле подводит.
Нужен набор из 100–200 реальных документов с проверенными значениями всех полей. Собирается один раз, используется при каждом изменении.
Метрики:
- точность по каждому полю отдельно — обычно одно-два поля тянут вниз всё;
- доля документов, прошедших все проверки;
- доля ложных отбраковок — проверка сработала, а значение было верным;
- доля пропущенных ошибок — документ прошёл проверки, но значение неверное. Самая важная и самая дорогая в измерении: требует ручной сверки выборки.
Последняя метрика — единственная, которая говорит о реальном риске. Все остальные могут выглядеть прекрасно при высокой доле пропущенных ошибок.
Частые вопросы
Насколько точно ИИ извлекает данные из документов?
На хороших исходниках — достаточно точно, чтобы это имело смысл, но недостаточно, чтобы принимать результат без проверки. Модель почти всегда возвращает правдоподобный ответ и не сообщает о неуверенности. Поэтому извлечение всегда сопровождается программными проверками: контрольные суммы, сверка итогов, наличие подтверждения в тексте.
Чем это лучше шаблонов под каждого поставщика?
Шаблоны точны, пока форма не изменилась, и ломаются молча при её изменении. При сотнях контрагентов поддержка шаблонов становится отдельной работой. Модель справляется с формой, которую видит впервые, — за это платят необходимостью проверок.
Что делать, если модель выдумала значение?
Ловить это проверкой: просить возвращать не только значение, но и фрагмент документа, из которого оно взято, и программно убеждаться, что такой фрагмент в документе есть. Значение без подтверждения почти всегда выдумано. Приём дешёвый и очень результативный.
Какие проверки обязательны?
Контрольные суммы для ИНН, КПП, счетов; форматы и разумность дат; равенство суммы строк итоговой сумме; соответствие ставки НДС; наличие контрагента в справочнике. Всё, что имеет формальную структуру, проверяется кодом, а не принимается на веру.
Может ли модель посчитать итог по позициям?
Может, но не должна. Арифметику делает код: модель ошибается в сложении редко, но молча, и такая ошибка попадает в учёт. Правильное разделение — модель извлекает строки, код складывает и сверяет с указанным итогом.
Сколько документов уходит на ручную проверку?
Зависит от однородности потока и качества исходников. Ориентир для смешанного потока счетов — около десятой части после отладки проверок. Важно, чтобы человеку приходил не пустой бланк, а заполненная форма с подсвеченным сомнительным полем.
Что дальше
Формат ответа модели — «Структурированный вывод модели». Что делать с отбракованными документами — «Человек в контуре проверки». Если исходники — сканы, начните с «OCR и PDF». Как это встраивается в общий маршрут документа — «Автоматизация документооборота».