В большинстве компаний есть люди, которые весь день переносят данные из PDF в учётную систему: номер счёта, ИНН, сумму, НДС, позиции. Рядом юрист в сороковой раз читает договор поставки, чтобы найти пункт о штрафах и сроке оплаты. А менеджер разбирает почту, где заявки приходят то письмом, то вложением, то фотографией бланка.
Это рутина, на которой нейросети уже работают надёжно. Ниже разбираем, как устроена автоматизация документов нейросетью: какие задачи она закрывает, чем отличается от привычного OCR, где обязательно нужен человек, как мерить точность на своих документах и как запустить пилот без большого бюджета.
Какие задачи решает автоматизация документов нейросетью
Подход, который называют IDP (intelligent document processing, интеллектуальная обработка документов), закрывает четыре типовых класса задач. Почти в каждой компании среднего размера есть хотя бы два из них.
Извлечение данных из счетов, актов и накладных
Модель получает скан или PDF и возвращает структурированные поля: поставщик, ИНН и КПП, номер и дата документа, сумма, ставка НДС, позиции с количеством и ценой. Дальше эти данные попадают в учётную систему как черновик документа, а бухгалтер проверяет и проводит его, а не набирает вручную.
Обработка счетов ИИ особенно полезна, когда поставщиков много и у каждого свой макет. Шаблонные решения ломаются на каждом новом формате, а языковая модель ориентируется по смыслу: ей не важно, в каком углу листа стоит итоговая сумма.
Сверка документов между собой
Счёт сверяется с заказом, акт — с договором, накладная — со счётом. Модель извлекает данные, а сравнение делает обычный код: совпадают ли суммы, количество, цены, реквизиты. Расхождения попадают в очередь сотруднику с подсветкой, что именно не сошлось.
Анализ договоров нейросетью по чек-листу
Юрист задаёт список проверок: срок оплаты не больше N дней, неустойка не выше установленного уровня, есть пункт о конфиденциальности, подсудность в нужном городе, нет одностороннего права менять цену. Модель проходит по договору и для каждого пункта чек-листа возвращает ответ, цитату из текста и номер пункта.
Решение о подписании остаётся за юристом. Задача модели — снять первичное чтение и показать, куда смотреть, особенно когда договоры приходят на бланке контрагента, а не по вашему шаблону.
Разбор входящих заявок и писем
Письмо или вложение превращается в карточку в CRM: кто пишет, что нужно, какие позиции и количество, срочность, к какому менеджеру отправить. Сюда же относятся заявки в свободной форме и фотографии заполненных бланков. Ошибка здесь обычно стоит недорого: заявку просто передадут другому менеджеру, поэтому это хороший кандидат для первого проекта.
Чем языковая модель отличается от классического OCR
OCR (оптическое распознавание символов) решает одну задачу: превратить изображение в текст. Чтобы из этого текста получить поля, к нему добавляют шаблоны и правила: «сумма — справа от слова „Итого“». Пока формат один, это работает. Новый поставщик с другим макетом — и нужен новый шаблон.
Языковая модель работает на следующем уровне: она читает текст как человек и понимает, что «К оплате», «Всего с НДС» и «Итого к перечислению» — одно и то же поле. Современные мультимодальные модели принимают и картинку напрямую. На практике распознавание документов нейросетью чаще строят гибридно: OCR даёт точный текст и координаты, LLM раскладывает его по полям.
| OCR с шаблонами | OCR + языковая модель | |
|---|---|---|
| Новый формат документа | Нужен новый шаблон | Обычно работает без доработки |
| Текст в свободной форме | Плохо | Хорошо: письма, договоры, заявки |
| Предсказуемость | Высокая на знакомых формах | Нужны проверки и контроль ошибок |
| Стоимость обработки | Низкая | Выше: оплата модели или своих серверов |
Где в контуре нужен человек
Главный риск языковой модели — уверенная ошибка: она может прочитать «8» как «3» или подставить правдоподобный ИНН, которого нет в документе. Поэтому автоматизация документооборота строится не как «модель всё делает сама», а как поток с контрольными точками.
- Проверки кодом. Контрольная сумма ИНН, сумма позиций равна итогу, НДС посчитан по ставке, дата в разумных пределах, контрагент есть в справочнике.
- Порог уверенности. Документ, где модель сомневается или проверки не прошли, уходит в ручную очередь.
- Подтверждение значимых действий. Оплата, подписание, отправка контрагенту — только после согласия сотрудника.
- Выборочный контроль. Даже из потока, прошедшего автоматически, часть документов регулярно проверяется вручную, чтобы заметить деградацию.
Нейросеть не заменяет бухгалтера или юриста, она убирает из их дня ручной ввод и первичное чтение.
Удобный интерфейс проверки важнее, чем кажется: сотрудник видит скан и извлечённые поля рядом, подсвеченные спорные места и правит их в один клик. Если проверка неудобная, люди начинают её пропускать, и смысл контроля теряется.
Точность: как мерить её на своих документах
Цифры точности из презентаций почти бесполезны: они получены на чужих документах. Скан хорошего качества от крупного поставщика и фотография мятого акта с печатью поверх суммы — разные задачи. Мерить качество нужно только на своих документах, и делается это так:
- Соберите выборку. 200–500 реальных документов того типа, который автоматизируете, с теми же сканами, фотографиями и макетами, что приходят в работу.
- Разметьте эталон. Для каждого документа сотрудник вручную заполняет правильные значения полей. Это самая скучная и самая важная часть.
- Считайте по полям. Точность ИНН, суммы, даты и позиций считается отдельно: ошибка в сумме и ошибка в названии товара стоят по-разному.
- Отделите автоматический поток. Посчитайте, какая доля документов проходит все проверки без человека и сколько ошибок в этой доле пропущено.
- Повторяйте при изменениях. Новая версия модели, другие инструкции, новые поставщики — прогон на той же выборке показывает, стало лучше или хуже.
Интеграция с учётной системой, CRM и ЭДО
Извлечение данных из документов само по себе мало что даёт, если результат потом копируют руками. Ценность появляется, когда поток замкнут: документ пришёл, распознан, проверен и оказался в нужной системе.
- Откуда приходят документы: почтовый ящик, ЭДО, сканер, загрузка в личном кабинете, мессенджер.
- Куда уходит результат: учётная система (например, 1С), CRM, ERP, таблица реестра.
- Какие справочники нужны для сверки: контрагенты, номенклатура, договоры, заказы.
- Что происходит при ошибке интеграции и кто об этом узнаёт.
- Как сохраняется связь между исходным файлом и созданной записью, чтобы любой документ можно было открыть и проверить.
Отдельный случай — ЭДО. Документы, пришедшие через оператора электронного документооборота в формализованном виде, уже содержат структурированные данные, и распознавать их не нужно. Нейросеть здесь полезна для неформализованных вложений и для сверки с договором.
Технически это обычная разработка сервиса: очереди, хранилище файлов, интерфейс проверки, коннекторы к системам, журнал действий. Именно этим мы и занимаемся в веб-сервисах: разбираем процессы, проектируем архитектуру и интеграции, переносим данные и обучаем сотрудников. Примеры проектов можно посмотреть в нашем портфолио.
Безопасность и 152-ФЗ
Счета, договоры и заявки почти всегда содержат коммерческую тайну, а часто и персональные данные: ФИО подписантов, телефоны, паспортные данные в договорах с физлицами. Поэтому первый вопрос — куда уходит документ, когда его обрабатывает модель.
- Облачная модель зарубежного провайдера. Быстрый старт, но для персональных данных это трансграничная передача: о ней нужно уведомлять Роскомнадзор, и допустима она не во все страны.
- Российский облачный провайдер. Данные обрабатываются в РФ, вопрос трансграничной передачи снимается, но остаётся договор с провайдером и оценка его мер защиты.
- Модель в своём контуре. Открытая модель на серверах компании или в арендованном облаке в России: документы не покидают периметр, но нужны серверы с GPU и время на настройку.
Коротко по 152-ФЗ: нужно законное основание обработки, запись и хранение персональных данных граждан РФ ведутся в базах на территории России, а оператор обязан принять меры защиты. Практичный приём — обезличивание: перед отправкой в модель ФИО и номера документов заменяются метками.
Пилот: проверить идею за ограниченный срок
Автоматизацию документов не стоит начинать с проекта «на весь документооборот». Пилот ограничивают по сроку, обычно несколькими неделями, и по охвату: один тип документов, один процесс, одна команда.
- Выбор документа. Тот, которого много и который однообразно обрабатывают вручную: входящие счета, акты, заявки на общий ящик.
- Базовая линия. Сколько документов в месяц, сколько минут уходит на каждый, сколько ошибок находят потом.
- Метрика и порог. Например, доля документов, прошедших без правок, и допустимое число пропущенных ошибок. Значения, при которых масштабируем и при которых останавливаемся, фиксируются до старта.
- Прототип на готовой модели. Схема полей, инструкции, проверки кодом и простой интерфейс проверки. Без обучения своей нейросети.
- Работа на живом потоке. Модель предлагает, сотрудники подтверждают. Так собираются реальные ошибки без риска для учёта.
- Решение. Сравнение с базовой линией и порогом. Дальше — интеграция и масштабирование либо остановка.
Результат «не окупается, останавливаемся» — тоже нормальный исход пилота. Узнать это за несколько недель дешевле, чем после полугода разработки.
Если после документов захочется дать сотрудникам или клиентам ассистента, который отвечает по регламентам и базе знаний, многие принципы те же: ограниченные источники, проверки и человек в контуре.
Частые вопросы
Можно ли полностью убрать человека из обработки документов?
Для части потока — да: типовые документы от постоянных контрагентов с высокой уверенностью модели и успешной сверкой можно проводить без ручной проверки. Но очередь для исключений и выборочный контроль остаются всегда: новые форматы, спорные документы и ошибки модели должен видеть человек.
Какая точность у нейросети при распознавании документов?
Универсальной цифры нет: она зависит от качества сканов, разнообразия форматов и того, какие поля извлекаются. Единственный надёжный способ узнать точность — прогнать модель на 200–500 ваших реальных документах с эталонными значениями и посчитать результат по каждому полю отдельно.
Нужно ли обучать собственную нейросеть под наши документы?
Как правило, нет. Для извлечения данных и проверки договоров хватает готовой языковой модели, понятной схемы полей, инструкций и нескольких примеров. Дообучение имеет смысл, когда документов очень много, они специфичны и готовые модели стабильно ошибаются на одних и тех же местах.
Можно ли обрабатывать документы с персональными данными?
Можно, если соблюдать 152-ФЗ: иметь законное основание обработки, хранить данные граждан РФ в базах на территории России и защищать их. Проще всего использовать модели, развёрнутые в своём контуре или у российского провайдера, либо обезличивать данные перед отправкой. Схему стоит согласовать с юристом.
Сколько длится пилот по автоматизации документов?
Обычно пилот ограничивают несколькими неделями и одним типом документов. Этого достаточно, чтобы собрать тестовый набор, проверить качество на своих данных и понять, окупится ли полноценное внедрение. Точный срок зависит от объёма документов и того, нужна ли интеграция уже на этапе пилота.
