TL;DR
Мощные мультимодальные модели (GPT-4o, Gemini, Claude) читают документы напрямую с картинки — не хуже, чем если сначала прогнать через OCR. Это значит: загружаешь скан счёта или договора прямо в чат, без предварительного распознавания текста.
Главная ловушка при извлечении данных из документов — размытая инструкция. Неясно описанная структура того, что надо вытащить, порождает ошибки: поле «итого» смешивается с «суммой НДС», строки таблицы объединяются. Модель не угадывает намерения — она следует схеме буквально.
Исследование нашло три рычага, которые вместе поднимают точность: чёткая схема (что именно извлечь и как называется), примеры правильного вывода (few-shot), и инструкции по мышлению (указание думать перед выводом и строго соблюдать формат).
Схема метода
ШАГ 1 (один промпт): Загружаешь картинку/скан документа
ШАГ 2 (тот же промпт): Указываешь схему полей — что извлечь и как структурировать
ШАГ 3 (тот же промпт): Задаёшь формат вывода (JSON, таблица, список)
ШАГ 4 (тот же промпт): Добавляешь пример правильного вывода + инструкцию думать перед ответом
→ Результат: структурированные данные из документа
Всё выполняется в одном запросе — картинка + промпт.
Пример применения
Задача: Ты получаешь от поставщика PDF-счёт на оплату. Надо вытащить реквизиты, позиции и суммы — без ручного ввода, прямо в ChatGPT/Claude/Gemini.
Промпт:
Перед тобой фотография/скан счёта на оплату.
Внимательно изучи документ и извлеки данные строго по схеме ниже.
Думай step by step: сначала найди каждое поле визуально, потом запиши значение.
СХЕМА ИЗВЛЕЧЕНИЯ:
Заголовок документа:
- Номер счёта: (как указан в документе)
- Дата выставления: (формат ДД.ММ.ГГГГ)
- Поставщик: (название организации)
- ИНН поставщика:
- Покупатель: (название организации)
Позиции (таблица):
| № | Наименование | Кол-во | Ед. | Цена | Сумма |
Итоги:
- Сумма без НДС:
- НДС (ставка и сумма):
- Итого к оплате:
ПРИМЕР ПРАВИЛЬНОГО ВЫВОДА:
Заголовок:
- Номер счёта: 125
- Дата: 15.05.2025
- Поставщик: ООО «Снабженец»
...
ПРАВИЛА:
- Если поле не найдено — пиши "не указано"
- Суммы — в рублях с копейками
- Не додумывай данные, которых нет на документе
- Проверь итоги арифметически перед выводом
Результат:
Модель пройдётся по документу визуально, найдёт каждое поле по схеме и выведет структурированную таблицу точно в заданном формате. Если поле нечитаемо или отсутствует — укажет «не указано». Суммы проверит арифметически сама.
Почему это работает
LLM с визуальным восприятием читает документ как человек: видит структуру, шрифты, расположение блоков. OCR же переводит картинку в сплошной текст — и теряет пространственные связи. Строки таблицы превращаются в непонятный поток слов, вложенные ячейки склеиваются.
Мощные модели (особенно Gemini и GPT-4o) умеют интегрировать визуальную структуру и текст одновременно. Это их натуральная сильная сторона. OCR-текст добавляет не дополнительную информацию, а лишний шум.
Промпт работает через три усилителя: - Схема убирает двусмысленность — модель не гадает, что считать «суммой» - Пример вывода показывает формат паттерном, а не словесным описанием - Инструкция думать активирует пошаговую проверку перед финальным ответом
Рычаги управления: - Детальность схемы → чем больше документов разного типа, тем точнее описывай каждое поле - Пример вывода → замени на реальный пример из своей практики — точность вырастет - Правило арифметики → убери, если не нужна проверка; оставь — поймает ошибки модели - «Не додумывай» → критично для юридически значимых документов
Шаблон промпта
Перед тобой {тип документа} (изображение/скан).
Внимательно изучи документ и извлеки данные строго по схеме.
Думай шаг за шагом: сначала найди каждое поле визуально, потом запиши.
СХЕМА ИЗВЛЕЧЕНИЯ:
{блок 1 — название раздела}:
- {поле 1}: ({пояснение формата})
- {поле 2}:
- {поле 3}:
{блок 2 — таблица если нужна}:
| {колонка 1} | {колонка 2} | {колонка 3} |
ИТОГИ:
- {итоговое поле 1}:
- {итоговое поле 2}:
ПРИМЕР ПРАВИЛЬНОГО ВЫВОДА:
{короткий пример заполненной схемы}
ПРАВИЛА:
- Если поле не найдено — пиши "не указано"
- {специфичные правила для типа данных}
- Не додумывай данные, которых нет в документе
Что подставлять:
- {тип документа} — счёт, договор, накладная, анкета, таблица
- {блок 1} — логические разделы: «шапка», «реквизиты», «данные клиента»
- {поле N} — конкретные поля с пояснением формата даты, единиц, написания
- {пример} — отрезок реального правильного вывода (3-5 строк достаточно)
- {специфичные правила} — формат суммы, язык, округление
🚀 Быстрый старт — вставь в чат:
Вот шаблон для извлечения данных из документов.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить схему.
[вставить шаблон выше]
LLM спросит какие конкретные поля нужны, какой формат вывода предпочтителен и есть ли пример документа — потому что без этого схема останется абстрактной и точность упадёт.
Ограничения
⚠️ Тип документа имеет значение: Чем сложнее структура — вложенные таблицы, многоколоночные схемы, рукописные пометки — тем чаще модель ошибается при визуальном считывании. OCR здесь всё ещё даёт преимущество.
⚠️ Модель определяет потолок: Эффект «картинка без OCR работает» устойчиво подтверждается для топовых моделей (Gemini 1.5/2.0, GPT-4o, Nova Pro). Для слабых моделей и открытых (Llama 4) OCR всё ещё помогает — результат без него хуже.
⚠️ Claude ведёт себя иначе: Claude 3.5 Sonnet при добавлении картинки к OCR-тексту теряет точность — вероятно, хуже сшивает два потока. Если используете Claude — тестируйте оба режима.
⚠️ Few-shot в полную силу не проверяли: Исследователи сами признают, что влияние примеров в промпте систематически не тестировалось. Промпт с примером в шаблоне — разумная ставка, но не доказанная цифрами.
Как исследовали
Команда SAP и Stanford взяла два внутренних корпоративных датасета — документы цепочки поставок (C1) и финансовые документы (C2) — с ручными аннотациями и прогнала через 11 актуальных моделей в трёх режимах: только картинка, только OCR-текст, картинка + OCR. Измеряли F1 — насколько точно модель нашла нужные поля и правильно ли их заполнила.
Интересна была не сама точность, а сравнение режимов. Оказалось: у Gemini и Nova Pro изображение без OCR работает так же хорошо или лучше, чем с OCR. И это воспроизводилось при повторных запусках — не случайный выброс. Зато Pixtral и Claude при добавлении картинки к OCR начинали работать хуже, что исследователи объяснили конфликтом между текстовым и визуальным каналом.
Любопытная деталь: у open-source Llama 4 маленькая модель (Scout, 40T токенов обучения) побила большую (Maverick, 22T токенов). Больше параметров — не всегда лучше, если тренировочные данные беднее. Наконец, команда взяла лучший случай (Gemini 1.5 Pro, image-only) и улучшила промпт — три изменения дали прирост с 76.8% до 78.9%, обогнав все режимы с OCR. Это и стало финальным аргументом: правильный промпт важнее OCR.
Адаптации и экстраполяции
💡 Адаптация для договоров и оферт: Та же схема работает для юридических документов. Схема будет другой — стороны, предмет, сроки, условия расторжения — но механика идентична.
Перед тобой договор (изображение/скан).
Извлеки данные строго по схеме. Думай шаг за шагом.
СХЕМА:
Стороны:
- Заказчик (название, ИНН):
- Исполнитель (название, ИНН):
Предмет договора: (одно предложение — суть обязательства)
Срок действия: (дата начала — дата окончания)
Стоимость: (сумма, валюта, НДС)
Условия оплаты: (предоплата/постоплата, срок)
Штрафные санкции: (если указаны)
Особые условия: (нестандартные пункты, если есть)
ПРАВИЛА:
- Юридические термины переписывай дословно, не перефразируй
- Если пункт неоднозначен — цитируй фрагмент оригинала
- Не указано — если поле отсутствует в документе
🔧 Техника: добавить «проверь себя» → меньше галлюцинаций
После основного извлечения добавь: «Перечитай документ ещё раз. Проверь каждое поле — оно реально есть в тексте? Если нет — исправь на "не указано"». Это снижает риск того, что модель додумает несуществующие данные.
Ресурсы
Работа: OCR or Not? Rethinking Document Information Extraction in the MLLMs Era with Real-World Large-Scale Datasets
Авторы: Jiyuan Shen, Peiyue Yuan, Atin Ghosh (SAP), Yifan Mai (Stanford University), Daniel Dahlmeier (SAP)
Контакты: jiyuan.shen, peiyue.yuan, atin.ghosh, d.dahlmeier @sap.com · yifan@cs.stanford.edu
Инструмент оценки: VHELM (Vision Language Models Holistic Evaluation) — Lee et al., 2024