Работа с документами — задача, где агент даёт наибольшую экономию и требует наибольшего внимания к контролю. Он извлекает данные из счетов, накладных, анкет и договоров, сверяет их с учётной системой и заносит результат. Ключевое ограничение: качество определяется не моделью, а исходными документами — с чистого PDF данные извлекаются почти безошибочно, с фотографии мятой накладной результат непредсказуем.
Что делает агент
- Получает документ из почты, папки, системы документооборота.
- Определяет тип: счёт, накладная, акт, договор, что-то иное.
- Извлекает поля по шаблону типа: реквизиты, суммы, даты, позиции.
- Сверяет с базой: существует ли контрагент, совпадает ли сумма с заказом.
- Отмечает расхождения вместо того, чтобы их сглаживать.
- Заносит в учётную систему либо готовит к занесению.
- Передаёт человеку всё, что вызвало сомнение.
Пятый шаг — главный. Модель склонна выдавать правдоподобный результат даже при плохом исходнике, поэтому явное правило «при неуверенности отметить, а не додумывать» задаётся в инструкции и подкрепляется проверками в коде.
От чего зависит качество
| Исходник | Ожидаемое качество | Что делать |
|---|---|---|
| PDF с текстовым слоем | высокое | обрабатывать напрямую |
| Хороший скан | хорошее | распознавание, затем разбор |
| Фотография документа | среднее, нестабильное | контроль всех полей |
| Мятый или тёмный снимок | низкое | требовать переснять |
| Скан таблицы | нестабильное | проверять привязку строк |
Последняя строка — недооценённая проблема. При разборе таблиц строка легко теряет связь с заголовком столбца, и число попадает не в то поле. Табличные документы — накладные, спецификации — требуют отдельной проверки на этапе оценки достижимости.
Что проверять до разработки
Взять выборку реальных документов — не образцовых, а обычных, со всеми дефектами: сканы под углом, печати поверх текста, рукописные пометки. Оценить на них долю верно извлечённых полей. Это и есть потолок качества; он не вырастет от смены модели, если проблема в исходниках.
Определить критичные поля. Ошибка в сумме и ошибка в комментарии — разные по последствиям. Критичные поля проверяются человеком дольше остальных.
Выяснить, что делать с расхождениями. Сумма в счёте не совпала с заказом — это ошибка поставщика, опечатка или изменение условий? Правило должен дать владелец процесса, а не разработчик.
Общая методика проверки готовности материалов — в статье «Готовность данных к внедрению ИИ».
Режим контроля
Документы почти всегда связаны с деньгами и обязательствами, поэтому подход осторожнее, чем в других сценариях.
Первый этап — все документы проверяются человеком. Агент извлекает и предзаполняет, человек подтверждает. Экономия уже есть: проверить заполненное быстрее, чем вводить.
Второй этап — контроль по порогу. Документы до определённой суммы и без расхождений проходят автономно, остальные — на проверку.
Третий этап — выборочный контроль. Проверяется часть потока плюс всё, что агент пометил как сомнительное.
Полностью снимать контроль не стоит: ошибка в первичном документе всплывает при сверке или проверке и обходится дороже сэкономленного. Разбор границы — «Автономный агент или с подтверждением».
Типичные ошибки
- Правдоподобные значения вместо отказа. Нечитаемая цифра заменяется похожей. Самая опасная ошибка: результат выглядит нормально.
- Путаница похожих реквизитов. ИНН плательщика и получателя, дата документа и дата оплаты.
- Потеря строк в таблице. Из накладной на двадцать позиций извлекается восемнадцать, и без сверки количества это незаметно.
- Старая версия документа. Обрабатывается скан прошлой редакции договора.
- Данные из шапки бланка. Реквизиты типографии принимаются за реквизиты контрагента.
Против первой и третьей помогает одна мера: сверка контрольных величин. Сумма позиций должна совпадать с итогом, число строк — с указанным количеством. Расхождение автоматически отправляет документ человеку.
Персональные данные
Документы часто содержат сведения о людях: паспортные данные, адреса, подписи. Отсюда два следствия.
Выбор между облачной моделью и локальным развёртыванием определяется требованиями закона, а не удобством. Ответственность за передачу несёт компания, а не сервис — см. «152-ФЗ и нейросети».
Второе: оригиналы и промежуточные файлы не должны оседать в публичном хранилище и логах дольше необходимого.
Как считать эффект
- время обработки одного документа;
- доля документов, прошедших без правок;
- доля ошибок, дошедших до учётной системы (контрольная метрика);
- объём документов, обработанных за период.
Третий показатель — ограничитель. Рост скорости при увеличении числа ошибок в учёте не является улучшением: исправление такой ошибки обходится дороже, чем ручной ввод.
Расчёт: почему точность важнее скорости
Показательный пример того, как высокая точность извлечения может не давать экономии. Числа условные.
Исходные данные:
| Показатель | Значение |
|---|---|
| Документов в месяц | 800 |
| Ручной ввод одного документа | 5 минут |
| Проверка предзаполненного | 1,5 минуты |
| Исправление ошибки в учёте | 25 минут |
```
трудозатраты «до»: 800 × 5 мин = 67 часов
```
Сценарий 1. Точность извлечения 95 %, все документы проверяются человеком.
```
проверка: 800 × 1,5 мин = 20 часов
исправления: 800 × 0,05 × 2 мин = 1,3 часа
итого ≈ 21 час
экономия ≈ 46 часов
```
Ошибки ловятся на проверке, поэтому обходятся дёшево — две минуты на правку поля.
Сценарий 2. Та же точность 95 %, но проверку сняли ради скорости.
```
обработка: 0 часов человека
ошибки в учёте: 800 × 0,05 = 40 документов с ошибкой
исправление: 40 × 25 мин = 17 часов
итого ≈ 17 часов
экономия ≈ 50 часов
```
На первый взгляд второй сценарий выгоднее — 50 часов против 46. И это ловушка.
Что не попало в расчёт. Ошибка в учётной системе обнаруживается не сразу, а при сверке или проверке. К этому моменту на неверных данных могли быть сделаны платежи, отчёты, решения. 25 минут — это стоимость исправления самой записи, а не последствий.
Кроме того, 40 ошибок в месяц — это ошибки, о которых вы узнаете. Часть не обнаружится вовсе.
Правильный вывод. Разница между сценариями — 4 часа в месяц, а разница в риске — несопоставима. При такой цене отказ от проверки не окупается.
Когда проверку снимать можно: если стоимость ошибки в учёте близка к стоимости правки на проверке. Это бывает у некритичных документов — например, при регистрации входящей корреспонденции. Для счетов и накладных — практически никогда.
Что реально считать перед проектом: не только точность извлечения, но и цену необнаруженной ошибки. Именно она определяет режим контроля, а не желание ускориться.
Частые вопросы
Насколько точно агент извлекает данные из документов?
Точность определяется качеством исходников, а не моделью. С PDF, содержащим текстовый слой, результат близок к безошибочному; с фотографиями документов — нестабилен. Реальную величину нужно замерять на выборке ваших документов до разработки: это и есть достижимый потолок, и смена модели его существенно не поднимет.
Может ли агент сам заносить документы в учёт без проверки?
На первом этапе — нет. Разумная последовательность: сначала человек подтверждает все документы, затем автономно проходят те, что ниже порога суммы и без расхождений, дальше остаётся выборочный контроль. Полностью снимать проверку не стоит — ошибка в первичном документе обнаруживается при сверке и обходится дороже экономии.
Что делать с плохими сканами?
Отправлять на переснятие, а не пытаться извлечь любой ценой. Агент, который выдаёт правдоподобное значение вместо признания нечитаемости, опаснее агента, который отказывается: результат выглядит нормально и проходит проверку. Правило «при неуверенности отметить» задаётся явно и подкрепляется проверками.
Как поймать пропущенные строки в накладной?
Сверкой контрольных величин: сумма позиций должна совпадать с итогом документа, а число строк — с указанным количеством. Расхождение автоматически отправляет документ человеку. Без такой проверки потеря пары строк из длинной таблицы остаётся незамеченной.
Можно ли обрабатывать документы с персональными данными?
Можно, но выбор архитектуры при этом определяется требованиями закона, а не удобством: облачная модель, российский сервис или локальное развёртывание. Ответственность за передачу данных несёт ваша компания, а не поставщик сервиса, поэтому решение принимается до начала разработки.
Что дальше
Смежный сценарий — «ИИ-агент для обработки заявок». Проверка исходных материалов — «Готовность данных к внедрению ИИ». Где проходит граница контроля — «Автономный агент или с подтверждением». Другие задачи — «15 сценариев применения».
Замер достижимого качества на ваших документах — часть аудита процессов перед разработкой и внедрением ИИ-агента.