Глава 49. Извлечение данных из документов

Система приняла счёт на 1 280 000 рублей как счёт на 128 000. OCR потерял ноль у сгиба, LLM аккуратно заполнила JSON, Pydantic подтвердил тип Decimal. Формат был правильный, деньги нет.

Вся цепочка отработала безупречно и синхронно: сканер увидел то, что увидел, модель прочла то, что было, валидатор проверил то, что умеет. Никто не соврал. Просто ни один участник не отвечал за вопрос «а бывает ли такой счёт у этого поставщика».

Документ проходит несколько независимых проверок

файл -> антивирус -> определение типа -> OCR/layout
     -> извлечение по схеме -> нормализация
     -> арифметические и справочные проверки -> человек при сомнении

Сохраняйте исходный файл, текст OCR, координаты фрагментов, версию модели и итоговый объект. Для каждого поля возвращайте доказательство, а не только уверенность модели.

class Evidence(BaseModel):
    page: int
    quote: str
    bbox: tuple[float, float, float, float] | None = None
 
class Invoice(BaseModel):
    number: str
    date: date
    supplier_tax_id: str
    total: Decimal
    currency: Literal["RUB", "USD", "EUR"]
    evidence: dict[str, Evidence]
 
    @model_validator(mode="after")
    def plausible(self):
        if self.total <= 0:
            raise ValueError("total must be positive")
        return self

После schema validation проверьте контрольные суммы: сумма строк плюс налог должна совпасть с итогом в пределах округления; ИНН сверяется со справочником; дата не может быть позже даты загрузки без явного допуска. Цитата должна действительно встречаться на указанной странице. Confidence полезен только после калибровки на ваших документах.

Что ломается

Скан повёрнут, таблица продолжается на следующей странице, две суммы стоят рядом, рукописная правка перекрывает печать. Prompt injection может находиться прямо в PDF. Новый шаблон поставщика проходит по типам, но меняет смысл колонок. Самая неприятная ошибка выглядит правдоподобно и не вызывает исключения.

Проверки предметной области дороже модели

Качество экстрактора определяется не столько промптом и моделью, сколько набором проверок после них.

Полезный минимум для счёта:

• Арифметика. Сумма строк плюс налог сходится с итогом в пределах округления. Ловит потерянный ноль лучше любой модели.
• Справочники. ИНН существует, поставщик известен, валюта разрешена договором.
• История. Сумма отличается от типичной для этого поставщика больше чем в N раз — повод для проверки человеком, а не для проводки.
• Дубликаты. Тот же номер счёта от того же поставщика уже загружался.
• Даты. Дата документа не из будущего и не из позапрошлого десятилетия.

Каждая проверка — десять строк кода и ноль токенов. Вместе они превращают «модель обычно права» в систему, где ошибка модели не становится ошибкой бухгалтерии.

Правило главы

LLM предлагает значение, а система принимает его только вместе с происхождением и проверками предметной области.

Чеклист главы

• Сохраняются исходный файл, текст OCR, координаты фрагментов, версия модели и итоговый объект.
• Для каждого поля возвращается доказательство: страница, цитата, при возможности координаты.
• Цитата проверяется на присутствие в тексте указанной страницы.
• Арифметические и справочные проверки выполняются после схемы и до принятия документа.
• Есть проверка на дубликат документа и на аномальную сумму относительно истории поставщика.
• Confidence модели используется только после калибровки на своих документах.
• Документ, не прошедший проверки, уходит человеку с указанием конкретного расхождения.
• Новый шаблон поставщика обнаруживается и отправляется на проверку, а не проходит молча.
• Текст внутри документа считается недоверенным: инъекция в PDF не меняет поведение.
• Измеряется доля документов, прошедших без человека, и доля ошибок среди них.

Практикум

Задача 49.1 — экстрактор с доказательствами. ⭑⭑⭑

Возьмите 50 документов минимум трёх шаблонов, разметьте поля и координаты, соберите извлечение с доказательством на каждое поле.

Критерии приёмки:

• Измерен exact match по каждому полю отдельно, а не одна общая точность.
• Измерена доля документов, прошедших без участия человека.
• Каждое поле сопровождается страницей и цитатой; цитата проверяется кодом.
• Испорчены десять файлов (поворот, размытие, пропавшая строка, конфликт итогов), и по каждому зафиксировано поведение системы.
• Опасные ошибки уходят в очередь проверки, а не превращаются в чистый JSON.

Подсказки:

1. Разметку координат делайте хотя бы для полей с деньгами: именно они дают самые дорогие ошибки.
2. Отдельно посмотрите на документы, где модель уверена и неправа. Это ваш список проверок предметной области.

Задача 49.2 — проверки, которые ловят потерянный ноль. ⭑⭑

Добавьте к экстрактору набор доменных проверок и измерьте, сколько ошибок они ловят.

Критерии приёмки:

• Реализованы минимум четыре проверки: арифметика, справочник, дубликат, аномалия относительно истории.
• На размеченном наборе показано, сколько ошибок поймала каждая проверка.
• Ложные срабатывания посчитаны; для каждой проверки выбран порог с обоснованием.
• Документ, не прошедший проверку, попадает человеку с конкретной формулировкой расхождения.
• Замерено, как изменилась доля автоматически принятых документов и доля ошибок среди них.

Подсказки:

1. Проверка «сумма строк сходится с итогом» ловит непропорционально много: начните с неё.
2. История поставщика — самый дешёвый детектор аномалий. Даже грубое сравнение с медианой работает лучше, чем интуиция.