ИИ научился понимать документы. Что теперь происходит с IDP

Для начала важно разделить три понятия:

• OCR (Optical Character Recognition) — технология оптического распознавания символов, которая преобразует изображение документа в машиночитаемый текст;
• IDP (Intelligent Document Processing) — более широкий класс систем интеллектуальной обработки документов. В такую систему могут входить OCR, классификация, извлечение данных, специализированные модели, правила валидации, маршрутизация, ручная проверка и передача результатов в корпоративные системы;
• VLM (Vision-Language Model) — мультимодальная модель, которая работает одновременно с визуальной и языковой информацией. Она может анализировать изображение документа и формировать его смысловую интерпретацию.

Таким образом, OCR и VLM — технологии и компоненты, а IDP — более широкая система обработки документов, в которой эти технологии могут использоваться.

Еще недавно интеллектуальная обработка документов строилась вокруг набора специализированных технологий: OCR отвечал за распознавание текста, отдельные модели — за классификацию и извлечение данных, а бизнес-правила — за проверку результата. 

С появлением мультимодальных моделей — VLM (Vision-Language Model) — привычный подход начал меняться. VLM способна работать непосредственно с изображением документа: распознавать текст, учитывать его расположение на странице, анализировать структуру и формировать структурированный результат. То, что раньше требовало нескольких последовательных компонентов, в некоторых сценариях теперь может выполнять одна модель.

На демо это выглядит как серьезный технологический скачок. Можно показать модели незнакомый счет или договор и практически сразу получить нужные реквизиты. Отсюда возникает вопрос: если VLM умеет не только читать документ, но и интерпретировать его содержание, что теперь происходит с IDP?

От демо до реального процесса

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

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

Для промышленной эксплуатации нужно понимать:

• насколько стабильно она работает на массовом потоке;
• насколько точны критичные поля;
• может ли система подтвердить происхождение каждого результата;
• какие проверки были выполнены;
• какие документы нужно передать человеку;
• что произойдет, если модель ошиблась или недоступна.

Именно здесь становится очевидно, что задача IDP шире, чем извлечение данных. 

VLM внутри IDP: как меняется архитектура 

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

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

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

Есть и еще одно изменение. Генеративный ИИ может помогать не только обрабатывать документы, но и быстрее создавать сами IDP-решения. По нескольким примерам документов модель может предложить набор полей, правила классификации, проверки и тестовые сценарии. Эксперт при этом контролирует результат, а специализированный конструктор превращает его в стабильный производственный процесс.

Миллион страниц: сколько стоит обработка разными подходами

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

Для ориентира можно сравнить три варианта на двух объемах: 100 тыс. и 1 млн страниц в месяц.

Для CPU-OCR возьмем две постоянно работающие виртуальные машины по 8 vCPU и 16 ГБ памяти каждая, включая резервирование. Такая конфигурация обходится примерно в 22 тыс. рублей в месяц.

Для облачной VLM возьмем российский API GigaChat Pro/Max и около 2,5 тыс. токенов на страницу — изображение, инструкция и ответ в JSON.

Для локальной VLM рассмотрим два сервера с H100, чтобы система могла продолжать работу при обслуживании одного из них.

Если пересчитать стоимость на страницу, при объеме 100 тыс. страниц CPU-OCR обойдется примерно в 22 копейки за страницу, облачная VLM — в 1,25–1,63 рубля, а локальная VLM — примерно в 4,9–7 рублей за страницу.

При объеме 1 млн страниц фиксированная стоимость CPU-инфраструктуры дает около 2,2 копейки за страницу, облачная VLM — 1,25–1,63 рубля, а локальная VLM — около 49–70 копеек за страницу.

Расчет CPU основан на тарифах российского облака: около 1,24 рубля за час 100%-ного использования vCPU и 0,33 рубля за гигабайт памяти. При полной загрузке чистая вычислительная стоимость OCR получается еще ниже — порядка 0,4–1,7 копейки на страницу в зависимости от сложности документа и скорости движка.

Для GigaChat в расчетах используется ориентир до 1792 токенов на изображение. Если добавить инструкцию и ответ, получается около 2,5 тыс. токенов на страницу. При цене 0,5 рубля за тысячу токенов для Pro и 0,65 рубля для Max один синхронный проход составляет примерно 1,25–1,63 рубля.

Один сервер с H100 в российском дата-центре сейчас оценивается примерно в 245–350 тыс. рублей в месяц. Для промышленного контура необходимы как минимум две реплики, поэтому стартовая инфраструктура составляет порядка полумиллиона рублей в месяц. Если используется более крупная модель, которой требуется несколько GPU на одну реплику, затраты будут еще выше.

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

Экономика — не единственный вопрос

При выборе архитектуры нужно учитывать не только стоимость вычислений, но и безопасность данных.

Документы, которые поступают в корпоративные системы, могут содержать персональные данные, коммерческую, банковскую, медицинскую и другую чувствительную информацию.

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

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

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

Иными словами, использование VLM в корпоративной обработке документов требует не только оценки качества модели, но и отдельного контура безопасности.

Как внедрять IDP, чтобы не получить дорогой эксперимент

1. Определить бизнес-задачу и экономику процесса. Важно зафиксировать, откуда поступает документ, кто его обрабатывает, какое решение принимается и в какую систему должен попасть результат. Затем снять исходные показатели: объем документов, сезонные пики, стоимость ручной обработки, среднее время прохождения, количество возвратов, долю ошибок и трудозатраты на их исправление. Отдельно нужно определить требования к точности критичных полей. Ошибка в комментарии и ошибка в сумме платежа имеют разную стоимость, поэтому одинаковая метрика качества для всех полей может быть бессмысленной. Наконец, следует считать полную стоимость владения. В нее входят лицензии или API, вычислительные ресурсы, хранение, интеграции, подготовка и разметка данных, ручная верификация, исправление ошибок, мониторинг, сопровождение и обновление моделей. Правильная единица сравнения здесь — не стоимость страницы или одного запроса к модели, а стоимость успешно обработанного документа.
2. Проверять нужно не «красивые» документы, а реальный поток. Для пилота необходим репрезентативный эталонный набор. В него должны входить разные версии документов, каналы поступления, языки, качество сканов, рукописные элементы, нестандартные таблицы и редкие исключения. Проверка только на качественных и заранее подготовленных документах почти неизбежно завышает результат. Не менее важно заранее определить, что считается правильным результатом. Два специалиста должны одинаково понимать, где находится номер договора, итоговая сумма или дата вступления в силу. Иначе модель будет воспроизводить противоречия, заложенные в данных. Также необходимо формализовать исключения: что делать, если поле отсутствует, реквизиты не совпадают, документ поврежден, комплект неполный или найдено несколько допустимых значений. Автоматизация должна иметь понятный маршрут для каждого такого случая.
3. Человек должен проверять риск, а не случайную выборку. Полностью автоматический процесс возможен далеко не всегда. Но и передавать человеку случайный процент документов — не лучший подход. Гораздо эффективнее риск-ориентированная верификация: специалист проверяет результаты с высокой ценой ошибки, низкой уверенностью модели, нарушенными контрольными соотношениями или новыми признаками. Так человеческая проверка становится не препятствием для автоматизации, а механизмом управления риском.
4. Еще до запуска промышленной эксплуатации нужно определить SLA: производительность в пиковые часы, допустимую очередь, правила повторной обработки, резервирование, мониторинг качества, порядок отката версии модели и действия при недоступности внешнего сервиса.
5. Наконец, стоит предусмотреть переносимость. Компания должна иметь возможность выгрузить исходные документы, разметку, эталонные наборы, схемы полей, правила и историю исправлений. Это снижает зависимость как от конкретной модели, так и от конкретного поставщика.

Новый IDP — это не просто распознавание документа

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

Если раньше основным вопросом было, насколько хорошо система распознает текст и извлекает необходимые поля, то теперь на первый план выходит более широкий вопрос: насколько надежно система принимает решение на основе документа.

В промышленной эксплуатации недостаточно получить ответ от модели. Нужно подтвердить его, проверить по бизнес-правилам, сохранить происхождение результата, оценить риск ошибки и при необходимости передать документ человеку.

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

В конечном счете выигрывает не система, которая всегда выдает ответ, а система, которая умеет подтвердить ответ, проверить его и вовремя отказаться от автоматического решения.