Data ExtractionDocument AILLM API

LLM-извлечение данных: из PDF в структурированный JSON (2026)

15 авг. 2026 г.1 мин чтения

Конвейер счетов обработал 40,000 документов в прошлом квартале. Отчёт о сверке выглядел идеально — пока кто-то не заметил, что 3% полей вендора были тихо неверны: переставленный номер счёта, налоговая строка, прикреплённая не к той строке, потерянный символ валюты. Никто не заметил, потому что извлечение не упало. Оно сработало — с неверным ответом.

В этом и состоит особый ужас извлечения из документов: отказы молчаливы. Нет ошибки 500, когда поле схемы возвращается пустым, но валидированным, нет исключения, когда сдвигается колонка таблицы. LLM-извлечение данных — одна из самых ценных LLM-нагрузок 2026 года — счета, контракты, формы, заявки — и одна из самых вводящих в заблуждение по бенчмаркам, потому что вендорские бенчмарки пишут вендоры, на документах, которые льстят их парсерам.

Это руководство покрывает конвейер извлечения от начала до конца — парсинг, схема, извлечение, валидация — с честным бенчмарк-вопросом (только LLM против вендоров парсинга против open source, на ваших документах), дизайном схемы, который предотвращает тихую порчу данных, обработкой PII, которая держит это в рамках закона, и моделью затрат на 1,000 документов.

Что на самом деле включает извлечение из документов

Ключевой вывод: извлечение — это цепочка из пяти этапов — парсинг, понимание, определение схемы, извлечение, валидация — и любой этап может отказать молча.

PDF → 1. Parse (layout, tables, OCR) → 2. Understand (vision or text)
        → 3. Schema (what fields, what types) → 4. Extract (LLM)
        → 5. Validate (types, required, confidence) → JSON

Цепочка прочна настолько, насколько прочно её самое слабое звено, и этапы отказывают по-разному: парсинг ломается на сканах и многоколоночных макетах, понимание — на повёрнутом или залитом водяными знаками контенте, схема — когда поля отсутствуют и никто не замечает, а валидация — когда её вообще не реализовали. Задача конвейера — сделать каждый отказ громким вместо тихого.

Почему извлечение проваливается в продакшне

Ключевой вывод: три класса отказов — ошибки парсинга, дрейф схемы и отсутствие валидации — и только один из них попадает в логи.

Ошибки парсинга. Отсканированные документы без OCR, таблицы, прочитанные как «текстовый суп», многоколоночные макеты, сплющенные в мусорный порядок. Парсер определяет потолок; LLM не может извлечь то, что парсер уничтожил.
Дрейф схемы. Документы меняются — появляется новое поле, вендор меняет шаблон — а схема остаётся фиксированной. Извлечения молча возвращают отсутствующие поля, которые проходят валидацию, потому что «отсутствие» не было правилом.
Отсутствие валидации. Нет проверок типов, нет правил обязательных полей, нет скоринга уверенности. Конвейер возвращает JSON, а JSON, который выглядит правильно, но не является таковым, хуже, чем отсутствие JSON: он питает нижестоящие системы правдоподобной ложью.

Собственные сравнения индустрии — вроде сопоставления парсеров 2026 от pdfmux — стабильно показывают, что выбор парсера двигает точность сильнее, чем выбор модели. Это первый урок: бенчмаркайте парсер на своих документах до того, как бенчмаркать модель.

Нейтральный тест: только LLM против парсеров против open source

Ключевой вывод: прогоните трёхсторонний тест на собственном корпусе — простые текстовые документы, сканы и таблицы — потому что рейтинг инвертируется по типу документа.

Ландшафт 2026 года включает три семейства:

Только LLM — подайте документ (текст или изображение) напрямую в мультимодальную модель. Работает на чистых цифровых PDF; деградирует на сложных макетах.
Вендоры парсинга — LlamaParse, Unstructured и аналоги, которые нормализуют макет до LLM. Лидеры бенчмарков на сложных документах, по цене за страницу.
Open source — Docling, Marker и новые специализированные модели извлечения вроде NuExtract3 (модель vision-language с 4B параметров и открытыми весами, построенная для структурированного извлечения, самохостингуемая по ценовой структуре NuExtract). Контроль и потолок затрат — ценой эксплуатации.

Тест, который всё решает: три набора документов — чистые цифровые, сканы и документы с тяжёлыми таблицами — через все три семейства, с измерением точности на уровне полей (а не совпадения «выглядит похоже»), стоимости за 1,000 документов и доли отказов. Честный прогноз: только LLM выигрывает чистый набор, вендоры выигрывают сканы, а open source выигрывает колонку затрат при объёмах — и именно ваш корпус решает, какая колонка важна.

Как собрать конвейер: парсинг → схема → извлечение → валидация

Ключевой вывод: дизайн схемы — этап с максимальным рычагом: строгая схема с валидацией превращает извлечение из надежды в контракт.

Основной цикл, независимый от провайдера, — на унифицированном chat endpoint:

import json
from openai import OpenAI

client = OpenAI()  # unified endpoint

SCHEMA = {  # the contract: required fields fail loudly
    "type": "object",
    "required": ["invoice_number", "vendor", "total"],
    "properties": {
        "invoice_number": {"type": "string"},
        "vendor": {"type": "string"},
        "total": {"type": "number"},
        "currency": {"type": "string", "enum": ["USD", "EUR", "GBP"]},
    },
}

def extract(page_text: str) -> dict:
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        response_format={"type": "json_schema", "json_schema": {"name": "invoice", "schema": SCHEMA}},
        messages=[{"role": "user", "content": f"Extract the invoice data as JSON:\n{page_text}"}],
    )
    return json.loads(resp.choices[0].message.content)

def validate(doc: dict) -> tuple[bool, list[str]]:
    errors = []
    for field in SCHEMA["required"]:
        if field not in doc or doc[field] in (None, ""):
            errors.append(f"missing required field: {field}")
    if not isinstance(doc.get("total"), (int, float)):
        errors.append("total is not a number")
    return (not errors, errors)

Четыре правила, которые делают это продакшн-уровнем:

Схема — это контракт. Обязательные поля, enums и типы — обеспечиваемые структурированным режимом вывода вашей модели (паттерн, задокументированный в этой серии) — так что «отсутствует» становится ошибкой вместо отсутствующего ключа.
Парсите до промпта. Цифровые PDF идут в LLM напрямую; сканы — через OCR или мультимодальную модель. Каталог моделей подскажет, какие модели принимают изображения; правило решения: «может ли парсер увидеть текст?»
Уверенность и очереди. Каждое извлечение получает оценку уверенности; строки с низкой уверенностью идут в очередь ручной проверки, а не в базу данных. Именно очередь делает «тихий отказ» громким — а повторяемые отказы сопоставляются со справочником error codes.
PII на обоих концах. Маскируйте персональные данные до извлечения, где возможно, сканируйте после — обработка персональных данных это требование комплаенса, а не приятный бонус конвейера, и применяется стандартный чек-лист приватности данных.

Как масштабироваться и снижать затраты

Ключевой вывод: стоимость за 1,000 документов — проектируемое число: разбиение по уровням сложности документов и пакетная обработка по объёму стабильно режут её вдвое и более.

Модель затрат: стоимость за 1,000 документов = стоимость парсинга (если есть) + токены модели × ставка модели. Рычаги:

Уровни по сложности документа. Чистые цифровые документы работают на бюджетных моделях; сканы и документы с тяжёлыми таблицами — на дорогом пути. Большинство конвейеров на 70-80% состоят из чистых документов, значит 70-80% объёма платит бюджетные ставки — кастомная маршрутизация делает решение по каждому документу механическим.
Пакетная обработка бэклога. Исторические выгрузки документов — идеальная batch-нагрузка: терпимая к задержкам, высокообъёмная, и паттерн batch-скидки из этой серии применяет скидку 50% без изменений.
Кэшируйте шаблон. Тот же вендор, тот же шаблон = тот же промпт-префикс. Стабильные префиксы попадают под кэш-цены, что в извлечении важнее почти всего остального, потому что шаблоны повторяются тысячи раз.
Строить или покупать парсер. Вендоры берут за страницу; open source — за GPU-час. Анализ TCO из этой серии показывает форму: managed-решения выигрывают ниже порогов объёма, open source — выше них, а порог зависит от вашей готовности заниматься эксплуатацией.

Частые ошибки, которые тихо портят данные

Ключевой вывод: четыре паттерна тихой порчи — каждый производит правдоподобно выглядящие неверные данные.

Схема без валидации. Схема — это описание, а не барьер. Без проверок типов и правил обязательных полей «связанное схемой» извлечение всё равно возвращает пустые поля, которые проходят как данные.
Пропуск OCR на сканах. На входе текстовый суп — на выходе мусорный JSON: отказ парсера находится выше модели, и никакой промпт его не исправит.
Нет отслеживания версий моделей. Обновления моделей меняют поведение извлечения; без закреплённых версий и регрессионного корпуса «модель стала лучше» тихо превращается в «поля сдвинулись». Версионируйте строку модели и схему вместе.
Всё на флагманской модели, всегда. Чистые документы на флагманской модели — самый дорогой способ не улучшить точность: распределяйте по уровням сложности и тратьте экономию на очередь ручной проверки.

FAQ

Можно ли извлекать из PDF только с помощью LLM?

Из чистых цифровых PDF — да. Сканы и сложные макеты требуют сначала OCR или мультимодальную модель — парсер определяет потолок, а LLM извлекает внутри него.

Как честно измерить точность извлечения?

Сопоставление на уровне полей (точное поле, точный тип, точное значение) с вручную размеченной выборкой, по каждому типу документа — плюс ошибки проверки типов и обязательных полей как отдельная метрика. Совпадение «выглядит похоже» и порождает ту проблему «3% тихо неверны», для предотвращения которой существует это руководство.

Сколько стоит извлечение за 1,000 документов?

Стоимость парсинга (если есть) плюс токены модели по вашему уровню: бюджетные модели на чистых документах обходятся намного дешевле флагманских на сканах. Распределяйте по уровням сложности — и средняя обрушится; обрабатывайте бэклог пакетами — и она упадёт вдвое снова.

Как проектировать схему?

Обязательные поля, enums и типы — обеспечиваемые через структурированный вывод, с трактовкой отсутствия обязательного поля как ошибки. Схема — это контракт между документами и вашей базой данных, и она заслуживает такого же ревью, как и то, и другое.

Нужен ли вендор парсинга или достаточно open source?

Прогоните трёхсторонний тест на своём корпусе. Вендоры лидируют на сложных макетах; open source (Docling, Marker, специализированные модели извлечения вроде NuExtract3) выигрывает по затратам и контролю при объёмах. Порог TCO реален и измерим.

Как обрабатывать PII при извлечении?

Маскируйте персональные данные до извлечения, где возможно, сканируйте вывод после и держите срок хранения минимальным — стандартные требования приватности данных применяются к извлечённым данным точно так же, как к исходным документам.

Итоги

LLM-извлечение данных — это дисциплина конвейера, а не свойство модели: парсите осознанно, определяйте схему как контракт, извлекайте внутри неё и валидируйте всё, чтобы отказы были громкими. Бенчмаркайте парсер на своих документах до модели, распределяйте по уровням сложности документов, обрабатывайте бэклог пакетами и относитесь к очереди ручной проверки как к функции. Сделанное правильно, извлечение — самая надёжная высокообъёмная нагрузка в LLM-стеке; сделанное неправильно — правдоподобно неверные данные, питающие вашу базу.

Прогоните 100 страниц через конвейер, прежде чем спорить с бенчмарком. Получите ключ TokSpan API — $5 бесплатных кредитов, чтобы прогнать выборку (quickstart), — и посмотрите затраты на документ на собственных счетах.