Анализ документов
От скана к структурированным данным
Проблема: Традиционный OCR даёт сырой текст с ломаной разметкой, разделёнными словами и ошибками распознавания. Для превращения этого в структурированные, валидированные данные нужен второй шаг — и LLM отлично с этим справляются.
Решение: От пикселей к валидированным данным
Анализ документов (document understanding) — это задача превратить страницу (счёт, контракт, медицинскую справку) в структурированные, машиночитаемые данные, сохранив их смысл. Традиционный OCR решает только половину проблемы: он вытаскивает символы из пикселей, но теряет структуру. Колонки сливаются, таблицы ломаются, многострочные адреса схлопываются, а смазанная цифра превращается в неверное число. На выходе — сплошная стена текста, где ты уже не отличишь, какое значение итоговое, а какое — отдельная позиция. LLM-based анализ документов идёт дальше: он читает, исправляет и структурирует содержимое за один проход рассуждения. Модель понимает, что "$I2.99" — это почти наверняка "$12.99", что "TechParts L LC" — это "TechParts LLC", а жирное число внизу — это итого, а не ещё одна строка.
Как это работает
Pipeline проходит по этапам: сырое извлечение текста (OCR или, в новых vision-language моделях, чтение изображения страницы напрямую как визуальных токенов), затем LLM-коррекция и структурирование, затем извлечение по схеме в целевой формат вроде JSON. Ключевой последний этап — валидация. Поскольку LLM с радостью угадает отсутствующее поле, каждое извлечённое значение получает маркер уверенности — поле помечается [VERIFIED] или [UNVERIFIED], чтобы downstream бухгалтерские или комплаенс-системы знали, чему доверять, а что человеку стоит перепроверить. Ты также сверяешь арифметику (сходятся ли позиции в заявленный итог?), чтобы поймать тихие галлюцинации до того, как они попадут в базу.
Когда применять и какие компромиссы
Бери этот подход, когда документы полуструктурированные и разнородные — тысячи счетов в десятках вёрсток разных поставщиков, где писать жёсткий шаблонный парсер под каждый безнадёжно. Гибкость — главный выигрыш: один промпт обрабатывает форматы, которых ты раньше не видел. Но компромиссы реальны. LLM дороже за страницу, чем классический OCR, добавляют задержку (latency) и могут выдумать правдоподобное-но-неверное значение, поэтому без валидации они рискованны для критичных полей. Конкретный пример: подаём скан чека, где OCR вернул Subtota1 $4S.00 ... Tota1 $48.60. Модель исправляет искажённые символы на Subtotal $45.00 и Total $48.60, выводит отсутствующую строку налога $3.60, помечает подытог и итог как [VERIFIED] (они сходятся), а выведенный налог отмечает как [UNVERIFIED] — чтобы человек подтвердил.
Представьте это как помощника юриста, читающего контракты для юридической фирмы:
- 1. Сырое OCR-извлечение: Сканирование изображения документа и извлечение всего текста — ожидайте ошибок: разделённые слова, ошибки распознавания, ломаная разметка
- 2. LLM-структурирование и коррекция: LLM читает сырой OCR, исправляет ошибки (разделённые слова, неверные цифры) и организует в логические секции
- 3. Извлечение по схеме: Применение целевой JSON-схемы для извлечения конкретных полей — компания, суммы, даты, позиции
- 4. Валидация и маркировка уверенности: Пометка каждого поля как [VERIFIED] или [UNVERIFIED] — перекрёстная проверка итогов, отметка предполагаемых значений, ловля галлюцинаций
Где это используется?
- Обработка счетов и чеков: Извлечение поставщика, сумм, позиций, налогов из сканов счетов — вывод в структурированный JSON для бухгалтерских систем
- Анализ контрактов: Парсинг условий, дат, сторон, обязательств из юридических документов с маркерами уверенности для неоднозначных прочтений
- Медицинские записи: Извлечение диагнозов, лекарств, лабораторных показателей из рукописных и печатных медицинских форм
- Технические чертежи и схемы: Чтение размеров, подписей, номеров деталей с инженерных чертежей и электрических схем
Интересный факт: OCR-free модели вроде mPLUG-DocOwl2 и Docopilot (CVPR 2025) полностью пропускают этап OCR — они обрабатывают изображение документа напрямую как визуальные токены. Это устраняет ошибки OCR в источнике, хотя им всё равно нужны grounding-промпты для предотвращения галлюцинаций.
Попробуйте сами!
Посмотри интерактивный pipeline ниже: как грязный OCR-вывод превращается в чистый, валидированный JSON через LLM-структурирование.
Частые вопросы
Чем LLM-анализ документов отличается от обычного OCR?
Обычный OCR только распознаёт символы на изображении и выдаёт плоский текст без структуры: колонки сливаются, таблицы ломаются, а смазанные цифры читаются неверно. LLM-анализ документов идёт дальше — он читает этот сырой текст, исправляет ошибки распознавания, восстанавливает структуру и извлекает нужные поля в формат вроде JSON по заданной схеме. По сути OCR отвечает на вопрос «какие тут символы», а LLM — «что эти символы значат и как их разложить по полям».
Как извлечь структурированные данные (JSON) из счёта или PDF с помощью LLM?
Пайплайн обычно состоит из четырёх шагов: 1) сырое извлечение текста через OCR или vision-language модель, читающую страницу напрямую; 2) LLM-коррекция — модель чинит разорванные слова и неверные цифры; 3) извлечение по схеме — ты задаёшь целевую JSON-структуру (поставщик, суммы, даты, позиции), и модель заполняет её; 4) валидация — сверка арифметики и пометка каждого поля как [VERIFIED] или [UNVERIFIED]. Главное — всегда задавать явную схему и проверять итоги, иначе модель может выдумать отсутствующие значения.
Может ли LLM ошибаться при распознавании документов и как это контролировать?
Да. LLM с радостью угадает отсутствующее или нечитаемое поле, выдав правдоподобное-но-неверное значение — это галлюцинация. Контролируют это маркерами уверенности: каждое поле помечается [VERIFIED] (значение прочитано и сошлось при перекрёстной проверке) или [UNVERIFIED] (выведено или сомнительно). Дополнительно сверяют арифметику — например, сходятся ли позиции в заявленный итог. Для критичных полей (суммы, реквизиты) [UNVERIFIED]-значения отправляют человеку на подтверждение.
Когда стоит использовать LLM для обработки документов, а когда лучше шаблонный парсер?
LLM выигрывают, когда документы полуструктурированные и разнородные — тысячи счетов в разных вёрстках поставщиков, где жёсткий шаблон под каждый формат писать бессмысленно. Один промпт обрабатывает даже форматы, которых ты раньше не видел. Но у LLM есть минусы: они дороже за страницу, добавляют задержку и могут ошибаться без валидации. Если у тебя один стабильный формат с фиксированной разметкой, классический шаблонный парсер дешевле, быстрее и предсказуемее.
Попробуй сам
Интерактивное демо этой техники
Извлечь структурированные данные из скана документа вместо сырого текста
TechParts L LC I NV-2024-0847 2024-03-15 Wid get A 50 649.50 Connector B 100 350.00 Cable Set C 25 700.00 Tax 1,869.45
{ "company": "TechParts LLC", // [VERIFIED] "invoice_number": "INV-2024-0847", // [VERIFIED] "date": "2024-03-15", // [VERIFIED] "items": [ {"name": "Widget A", "qty": 50, "unit_price": 12.99, "total": 649.50}, {"name": "Connector B", "qty": 100, "unit_price": 3.50, "total": 350.00}, {"name": "Cable Set C", "qty": 25, "unit_price": 28.00, "total": 700.00} ], "tax": 169.95, // [VERIFIED] "tax_rate": 0.10, // [UNVERIFIED — inferred] "grand_total": 1869.45 // [VERIFIED] }
JSON-схема + инструкция коррекции + маркеры уверенности превращают сырой OCR в production-ready данные. Модель исправляет ошибки и честно помечает предположения.
Квиз по уроку
1.В чём главное преимущество LLM-based анализа документов перед традиционным OCR?
Создайте бесплатный аккаунт для решения челленджей
3 челленджей с AI-проверкой для этого урока
Этот урок — часть структурированного курса по LLM.
Мой путь обучения