Qwen VL распознаёт счета, накладные, сканы договоров и скриншоты по смыслу документа вместо простого прочтения символов: модель отвечает на вопрос о конкретном поле, а классический OCR отдаёт только сплошной текст. Разберём сценарии применения, пример промпта на условном документе и где ответ обязательно проверяет человек.
Сценарии применения
Qwen VL — мультимодальные модели Qwen, которые понимают изображение вместе с текстом на нём: счета, накладные, сканы договоров, скриншоты и фото товара распознаются по смыслу, и модель отвечает на вопросы про конкретные поля документа.
Qwen VL — общее название вариантов линейки Qwen с поддержкой изображений, см. vision-модели. Компания отправляет фото или скан, а в ответ получает разобранный смысл документа: какая сумма в счёте, кто поставщик, какая дата на скане договора — построчный текст без структуры тут излишен.
- Счета и накладные от поставщиков — сумма, поставщик, дата, номер
- Сканы договоров — конкретный пункт или условие по вопросу
- Скриншоты переписки или интерфейса — разбор содержимого
- Фото товара — описание для карточки маркетплейса
- Фото с объекта — проверка состояния, комплектности, соответствия
Общее в этих сценариях — источник данных живёт в виде картинки вместо структурированного файла: бумажный документ сфотографировали на телефон, скриншот вырезали из интерфейса, товар сняли на складе. Раньше это означало ручной ввод, теперь — вопрос модели к изображению.
Чем отличается от OCR
Классический OCR переводит картинку в текст посимвольно и отдаёт сплошное полотно — дальше отдельная логика ищет в этом полотне нужные поля по шаблону разметки конкретного бланка. Работает надёжно, пока формат документов стабильный, и требует доработки при каждом заметном изменении вёрстки.
Qwen VL пропускает этот промежуточный шаг: модель понимает документ целиком и отвечает прямо на вопрос — «какая сумма к оплате» или «до какого числа действует договор» — без отдельного шаблона под каждый вид бланка. Смена формата счёта у поставщика ломает жёсткую OCR-разметку, а Qwen VL подстраивается прямо в рамках того же промпта.
На практике это меняет саму роль разработчика в проекте: с OCR он пишет и поддерживает парсер под каждый шаблон бланка, с Qwen VL — формулирует и уточняет промпт, а разметку берёт на себя модель. Порог входа ниже, но и контроль над результатом смещается из кода в формулировку задачи, а значит, и ответственность за качество результата переходит к тому, кто пишет промпт.
Разница особенно заметна на разнородном потоке документов: одна компания получает счета от десятков поставщиков в разных вёрстках, и держать под каждую отдельный шаблон разметки дорого в поддержке. Каждый новый поставщик со своим форматом счёта у OCR превращается в отдельную задачу разработки — у Qwen VL это лишь ещё один документ в том же потоке.
Извлечение полей
Представьте бухгалтерию, куда каждую неделю приходит полсотни счетов от разных поставщиков в разных форматах — от аккуратного PDF до фото мятого бланка с телефона курьера. Раньше данные из них вбивали в таблицу вручную построчно; с Qwen VL это превращается в вопрос к фото — отдельная ручная задача на каждый документ отпадает.
Разберём это на условном документе — счёте от поставщика с пятью полями, которые обычно нужны бухгалтеру для проводки и оплаты.
Промпт: «Роль: ассистент бухгалтера. Задача: извлечь из счёта на фото поля — номер, дата, поставщик, сумма, срок оплаты. Формат: только JSON без пояснений вокруг; нечитаемое на фото поле помечай значением null, без угадывания». Модель возвращает пять полей JSON-объектом — недостающие данные видно сразу по null, без маскировки под правдоподобную цифру, которую иначе пришлось бы перепроверять на веру.
В примере выше видно, где проходит основная работа человека: сверить пять полей с оригиналом быстрее, чем набрать их вручную с нуля, а null в ответе сразу показывает, какое поле требует внимания. Тот же каркас промпта — роль, задача, формат — переносится на накладную или акт: меняется только список полей в задаче.
Какие документы компании годятся для такого распознавания?
Где ошибается модель
| Тип ошибки | Когда возникает | Как проверять |
|---|---|---|
| Рукописный текст | Заполнение от руки поверх бланка | Сверка с оригиналом вручную |
| Печати и штампы поверх текста | Печать перекрывает цифры или подпись целиком | Запрос копии без наложения печати сверху |
| Мелкие или смазанные цифры | Плохое качество скана или фото | Пересчёт суммы по строкам документа |
| Похожие поля без подписей | Таблица без явных заголовков над колонками | Выборочная сверка с исходным бланком поставщика |
Общий принцип проверки — выборка вместо сплошного пересчёта: часть документов сверяют полностью на старте, дальше долю сокращают по мере накопления статистики ошибок по конкретному типу документа и конкретному поставщику. Отдельно держат список полей, где цена ошибки высокая, — сумма к оплате и реквизиты, — их проверяют дольше остальных, даже когда общая доля выборки уже снижена.
- Отправить фото или скан с промптом на нужные поля
- Свериться со сгенерированным JSON, начиная с null-полей
- Выборочно перепроверить оставшиеся поля по графику
- Уточнить промпт, если один тип ошибки повторяется на потоке
Локально или API
Для договоров и счетов с коммерческой тайной подходит локальный запуск модели на своём сервере — разбор в статье как запустить Qwen локально. Для потока публичных документов или пилота хватает облачного API — инструкция в статье как получить API-ключ Qwen.
Оплата облачного Qwen VL устроена как у большинства зарубежных сервисов: прямая оплата российской картой недоступна. Сравнение Qwen с альтернативным вендором — в статье Qwen или DeepSeek для компании. Для пилота на десятке документов облачный путь обычно быстрее: ключ, промпт, проверка результата — без установки сервера ради теста гипотезы.
Смежная механика уже разобрана для конкретных потоков документов — в статьях распознавание счетов и актов через ИИ и автоматический разбор счетов поставщиков: принцип с полями и проверкой человеком там тот же, разница только в том, какая модель стоит за распознаванием.
Соберите десяток типовых документов — счетов или сканов договоров — и проверьте на них извлечение полей вручную, до внедрения в процесс. Так видна реальная доля ошибок на своих документах, без опоры на среднюю цифру из чужого кейса. Контур под весь поток документов компании собирает команда нейросетей для работы с документами.
Дальше имеет смысл встроить проверку прямо в процесс, без отдельного ручного шага: результат распознавания попадает в таблицу или CRM с пометкой уверенности по каждому полю, и сотрудник сразу видит, что читать глазами, а что можно принять без задержки.