Еще десять лет назад автоматизация обработки документов опиралась на OCR и жесткие шаблоны. Сегодня в этой сфере все активнее заявляют о себе VLM — технологии, способные понимать контекст и быстро адаптироваться к новым задачам. Но меняют ли они правила игры полностью или лишь дополняют существующие?
Мы провели исследование и выяснили, что правила изменились, но говорить о полном забвении классических IDP-решений рано. Будущее будет за гибридом, который сочетает эффективность IDP с новыми возможностями VLM.
Почему VLM эффективны в обработке документов
Начнем с азов, но без воды
VLM, так же как и LLM, обучены на колоссальных объемах текста: книгах, статьях, коде, форумах, профессиональной документации. И при этом понимают как текст, так и изображения: могут определить, где в документе блок с подписью, печать, таблица с перекрывающимися ячейками или график с пометками ручкой.
Главная сила моделей — контекстное понимание. Представьте, что вы дали LLM отсканированный договор аренды и просите:
«Извлеки сумму ежемесячного платежа, имя арендодателя и дату окончания договора. Если дата окончания не указана явно, вычисли ее, исходя из срока действия».
Для решения задачи с помощью классического IDP нужен шаблон, предварительная разметка и обучение. VLM справится без этого. Модель прочитает текст, найдет соответствующую информацию и свяжет логические цепочки: «Срок действия договора — 11 месяцев с 01.03.2025, а значит окончание — 01.02.2026».
Круто? Круто. Невозможно отрицать новую ценность для бизнеса, которую VLM могут привнести в автоматизацию обработки документов — особенно слабо– и неструктурированных.
Но можно ли говорить, что уже сейчас модели способны заменить проприетарный софт? Мы попробовали на практике оценить их готовность к решению конкретных задач обработки документов и целесообразность внедрения для бизнеса.
Методология и метрики исследования
В рамках исследования мы проверили, насколько хорошо VLM справляются с задачей извлечения данных из документов с таблицами, в том числе многостраничных.
Методику использовали следующую:
Попросили несколько VLM извлечь поля из различных финансовых и бухгалтерских документов
Проводили замеры на облачных моделях через OpenRouter и сравнивали их с результатами нашей IDP-платформы ContentCapture 14.9
Использовали JSON-схемы для генерации ответов, чтобы модель следовала заранее зафиксированному формату ответа
Обрабатывали как одностраничные, так и многостраничные документы с небольшим числом страниц — одним запросом, аналогично одностраничным
Проводили измерения на датасете, который включает наиболее распространенные типы финансовых и бухгалтерских документов: акт выполненных работ (форма КС-2), счет, счет-фактура, ТОРГ-12, УКД, УПД. Общее количество документов — 764
Использовали синтезированные документы высокого качества, а в перспективе планируем аналогичное исследование с искаженными образцами реальных документов.
Результаты распознавания документов сравнивали по нескольким классическим метрикам:
PassThroughRate: в документе точно распознаны все поля;
FieldF1: мера количества точно найденных полей документа – чем больше правильных полей найдено, тем выше F1;
Char F1: оценка количества точно распознанных символов во всех полях документа;
Time per image: среднее время распознавания одного изображения.
Результаты: IDP vs VLM
PassThroughRate — одна из самых строгих метрик качества. Достаточно одного неверно распознанного символа в поле, чтобы результат по всему документу обнулился. По этому показателю ContentCapture с результатом 1,44 % заметно уступает большинству моделей.
Лидером стала Gemini-2.5-Flash, продемонстрировавшая 22,91 % — то есть почти в каждом пятом документе все поля распознаны без единой ошибки. Высокую точность VLM обеспечивает способность восстанавливать недостающую или искажённую информацию на основе контекста и статистических закономерностей. Если символ размыт или обрезан, модель анализирует весь документ целиком. Это позволяет ей «угадать» правильное значение с высокой вероятностью.
В отличие от традиционного OCR, который ограничен окрестным окружением, VLM видит документ целиком. За счет этого модели выдают больше чистых результатов по PassThroughRate. В то же время даже незначительные погрешности классических IDP-решений, например, опечатка или лишний пробел, приводят к обнулению метрики, несмотря на то, что остальной документ распознан идеально.
По метрике Field F1 ContentCapture лидирует с показателем 94.49%. Это говорит о том, что IDP-система успешно справляется с точным извлечением данных из полей. Ближайшие конкуренты — LLaMA-4-Maverick, Gemini-2.5-Pro — показывают неплохой результат с отставанием примерно на 3% — 91,6% и 91,4% соответственно. Однако при большом и очень большом количестве полей в абсолютном значении эта цифра будет весомой, и разрыв в показателях вырастет.
По CharF1 ContentCapture c результатом 95.09% немного уступает ряду облачных моделей. В целом, и те, и те хорошо справляются с распознаванием отдельных символов в полях. Считаем, что пока ничья.
В случае с time per image ContentCapture обрабатывает документ в среднем за 10 секунд — из них около двух секунд уходит на импорт и предварительную обработку, а 8 — непосредственно на распознавание. Это в разы быстрее большинства протестированных VLM.
Наиболее близкие результаты по скорости показали Gemini-2.0-Flash (16,5 секунд) и GPT-4o (15 секунд), однако обе модели значительно уступают ContentCapture по качеству извлечения данных.
В рамках исследования мы измеряли время ответа через сервис OpenRouter, и эти данные могут отличаться от непосредственной скорости работы моделей. Мы сознательно пошли на упрощение: во-первых, потому что точные сведения об аппаратной конфигурации и параметрах запуска моделей недоступны. Во-вторых, для целей предварительного сравнения такой подход вполне корректен.
Углубленный бенчмарк с контролем «железа» и настроек потребовал бы значительных ресурсов и времени, что выходит за рамки задачи исследования — оценить целесообразность практического использования VLM для распознавания документов здесь и сейчас.
Вот результаты по одному конкретному типу документов — ТОРГ-12. Их в исследовании было 100 штук.
Здесь картина в целом та же, что и по своду результатов:
По PassThroughRate классическое IDP-решение, предсказуемо, не проходит, а модели показывают широкий разброс результатов — от 0% у Gemma-3-27b-it до 43% у Gemini 2.5 Flash Preview 05-20. В среднем показатель — 19%.
По Field F1 ContentCapture снова показывает лучший результат — 97.09%. VLM отстают, и некоторые, довольно, прилично: на 10 и более %.
По CharF1 ContentCapture сохраняет паритет с большинством моделей, уступая лучшему результату Сlaude Sonnet 4 около 5%.
По time per image: ТОРГ-12, как и остальные документы, ContentCapture обрабатывает в среднем за 10 секунд. Результаты VLM разнятся от практически идентичных 10,6 секунд у Gemini 2.0 Flash-001 до 97 секунд у Qwen2.5-VL-72B-Instruct.
Наше исследование показало, что классическое IDP-решение успешно справляется со своей ключевой задачей — точным и быстрым извлечением данных из структурированных документов. Высокие показатели по Field F1 (94,49% в среднем, до 97% на ТОРГ-12) и низкое время обработки (10 секунд на документ) подтверждают эффективность этих систем для задач корпоративного сектора.
VLM в целом уверенно справляются с распознаванием, но в некоторых документах теряются и могут галлюцинировать — подставлять статистически вероятные, но фактически неверные значения. Это делает их ненадежными для задач, где важна абсолютная точность.
Почему VLM прямо сейчас не подходят для реального использования
Перейдем от условных метрик к практической стороне вопроса — затратам на внедрение и эксплуатацию.
ContentCapture работает на 16-ядерном процессоре, стоимость которого составляет около 150 тысяч рублей. Для обработки документов на такой машине можно запустить 16 потоков одновременно. Одна страница обрабатывается примерно 10 секунд, 16 страниц — те же 10 секунд.
VLM же требуют мощных видеокарт. При этом на ней можно обрабатывать только одну страницу за раз. Хотите обрабатывать 16 страниц параллельно? Приобретайте 16 видеокарт по 300 тысяч рублей в среднем каждая*.
Стоимость железа, необходимого для потоковой обработки с помощью VLM, обойдется в несколько миллионов рублей. Прибавьте к этому расходы на охлаждение, электропитание, обслуживание. В таких условиях даже высокое качество распознавания не всегда окупает эксплуатационные издержки.
*Выбор видеокарт огромен — от 50 тысяч рублей до нескольких миллионов. В данном примере мы ориентировались на NVIDIA RTX 5090 с 32 ГБ видеопамяти.
В итоге по точности извлечения данных ContentCapture превосходит большинство VLM, а по стоимости владения и эффективности использования ресурсов намного их опережает. Это не случайность, а результат глубокой специализации: когда речь идет о промышленной обработке миллионов документов, где на бизнес-результат влияет множество факторов, оптимизированное под задачу решение остается безальтернативным.
Будущее за интеграцией
Главный вывод, к которому нас приводят данные, заключается в том, что будущее обработки документов — не в противостоянии подходов, а в их синтезе. VLM должны использоваться как усиление классических IDP-решений.
Наиболее перспективным выглядит подход с гибридной архитектурой: быстрое и дешевое распознавание и извлечение данных через OCR с последующей контекстной постобработкой и верификацией с помощью VLM. Это позволяет компенсировать отдельные недостатки классических систем и одновременно усилить их главное преимущество — экономическую эффективность на масштабе.
Преждевременно рассчитывать, что VLM сами по себе заменят IDP. Но было бы наивно игнорировать их потенциал. Победит не тот, кто выберет одну технологию, а тот, кто заставит их работать вместе. Об этом как раз и расскажем в следующих статьях.
Это блог компании Content AI. Мы помогаем работать с информацией умнее — автоматизировать обработку документов, извлекать данные и повышать качество бизнес-процессов с помощью технологий и AI. Здесь рассказываем, как строим собственные продукты и делимся опытом, архитектурными решениями и кейсами внедрения интеллектуальной автоматизации.
Наш Telegram-канал со всеми новостями: https://t.me/content_ai