TL;DR
Метод разбивает извлечение данных на два шага: сначала модель определяет тип документа (например, "справка" или "договор"), потом получает узкий промпт именно под этот тип — только нужные поля и 2-4 примера, без инструкций для всех остальных типов. Вместо одного гигантского универсального промпта "на все случаи" — модель работает с чистым, сфокусированным набором правил.
Когда промпт содержит инструкции сразу для 16 разных типов документов, модель распыляет внимание между релевантными и нерелевантными частями. Она видит правила для типов, которые вообще не встретились в этом документе, и это мешает ей точно извлечь нужные поля — путаются форматы, теряются детали, растёт число ошибок. Авторы называют это "размытием внимания": чем больше в промпте лишнего, тем слабее сигнал по-настоящему нужной инструкции.
Метод решает это классификацией до извлечения: сначала пусть модель определит тип задачи из заданного списка, а потом соберите (или попросите модель собрать) промпт только из правил, относящихся именно к этому типу. Модель получает узкий, "заточенный" контекст вместо шведского стола инструкций.
Схема метода
ШАГ 1: Классификация типа документа/задачи → метка типа (например, "Счёт на оплату")
ШАГ 2: Сборка промпта под этот тип: общие правила формата + специфичные поля для этого типа + 2-4 примера → готовый промпт
ШАГ 3: Извлечение данных LVLM по собранному промпту и изображению → структурированный JSON
В оригинале шаги 1 и 2 выполняются отдельными системами (классификатор + шаблонизатор). В обычном чате это удобно объединить в один запрос, где модель сначала определяет тип "внутри себя", а потом применяет только релевантный блок правил.
Пример применения
Задача: Предприниматель получает от контрагентов вперемешку разные документы — акты, счета, УПД, накладные — и хочет через ChatGPT/Claude с загрузкой фото автоматически вытаскивать из них ключевые данные в таблицу, без ручного заполнения.
Промпт:
Ты — специалист по обработке документов.
ШАГ 1 — Определи тип документа на фото из списка:
- Счёт на оплату
- Акт выполненных работ
- УПД
- Товарная накладная
Не пиши объяснение, просто определи тип и переходи к шагу 2.
ШАГ 2 — Извлеки данные по правилам ниже.
Общие правила для всех типов:
- Вывод только в формате чистого JSON, без комментариев
- Даты — в формате "год-месяц-день"
- Если поле не найдено или нечитаемо — пиши "не определено"
- Извлекай ТОЛЬКО поля, указанные для того типа, что определён на шаге 1
Правила по типам (используй только те, что соответствуют определённому типу):
Тип "Счёт на оплату": извлеки поля — номер счёта, дата, поставщик, сумма, НДС
Пример вывода: {"номер": "145", "дата": "2024-03-11", "поставщик": "ООО Ромашка", "сумма": "45000", "ндс": "7500"}
Тип "Акт выполненных работ": извлеки поля — номер акта, дата, исполнитель, заказчик, перечень работ, сумма
Пример вывода: {"номер": "22", "дата": "2024-02-01", "исполнитель": "ИП Иванов", "заказчик": "ООО Ромашка", "работы": "монтаж оборудования", "сумма": "80000"}
[добавь аналогично для УПД и Товарной накладной]
Документ для анализа: [прикрепи фото]
Результат: Модель сначала внутри ответа (или скрыто, если попросить не показывать) определит тип документа, затем выдаст чистый JSON только с полями, релевантными этому типу — без попыток впихнуть в ответ поля из других категорий документов.
Почему это работает
Когда в промпте перемешаны правила сразу для нескольких типов задач, модель распределяет внимание по всему тексту инструкции — включая части, которые вообще не относятся к текущему документу. Это ослабляет "сигнал" от действительно нужных правил.
LLM хорошо выполняет узкие, конкретные инструкции с явными примерами — это её сильная сторона: чем чётче и короче задача, тем точнее исполнение.
Классификация "сужает" задачу до одного конкретного случая до того, как модель начинает извлекать данные. В промпт попадает только релевантная часть инструкции — модель не тратит "внимание" на лишнее.
Рычаги управления: - Список типов на шаге 1 → расширяй под свои задачи (не только документы — можно применять к типам писем, обращений клиентов, форматов отчётов) - Число примеров (2-4) → больше примеров повышает точность, но увеличивает длину промпта - Правило "не определено" → замени на своё поведение с отсутствующими полями (например, "оставь пустым" или "пометь как требующее проверки")
Ограничения
⚠️ Зависимость от первого шага: если модель неправильно определила тип документа на шаге 1, весь дальнейший промпт будет "не тот" — извлечение пойдёт по неверным правилам. Метод выигрывает только когда классификация точная.
⚠️ Нужен закрытый список типов: метод работает, когда у вас есть конечный набор известных категорий с заранее понятными полями. Для полностью непредсказуемых, разовых документов без чёткой категории смысла не даёт — вернётесь к одному общему промпту.
⚠️ Плохое качество фото: метод без дообучения (то, что применимо в обычном чате) заметно слабее справляется с печатями, водяными знаками и низким контрастом, чем версия с дополнительным обучением модели — а это уже требует кода и GPU, недоступно в чате.
Как исследовали
Исследователи собрали настоящий боевой датасет с портала электронных торгов — почти 100 тысяч фотографий документов 16 типов (лицензии, дипломы, сертификаты соцстраха и другие), с реальными помехами: печати, водяные знаки, искажения от съёмки. Сравнили метод с сильным baseline — отдельно обученным пайплайном OCR + извлечение сущностей, который тренировали специально под каждый тип документа.
Результат удивил: метод без всякого дообучения (просто классификация + узкий промпт на обычной модели Qwen2.5-VL-7B) обошёл специально обученный baseline почти на 18 процентных пунктов точности. Логика простая — обученный пайплайн заточен под каждый тип отдельно, но страдает от переноса между типами и накопления ошибок в цепочке OCR → извлечение. А классификация + узкий промпт даёт модели меньше шума при том же объёме информации.
Дополнительное дообучение самой модели поднимало результат ещё выше и особенно помогало с печатями и низким качеством фото — но это уже требует серьёзной инфраструктуры (8 GPU, несколько дней обучения) и находится за пределами того, что применимо в обычном чате.