Как оценить LLM-извлечение данных: отдельная цена каждого поля

LLM извлекает из счетов номер, дату, сумму и валюту. На демонстрации JSON выглядит правильно, но для загрузки в учётную систему этого мало. Ошибка в описании товара и ошибка в сумме имеют разную цену. Оценивать такой проект удобнее по каждому полю и по документам, которые можно принять целиком.

Согласуйте эталон и нормализацию

В эталоне храните document_id, значения полей и отметку о том, присутствует ли поле в источнике. Пустая строка, отсутствующее поле и неразборчивый фрагмент означают разные состояния. Если человек не может прочитать номер, нельзя требовать от модели произвольное единственное значение.

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

Считайте три типа ошибок

Если поле есть в эталоне, но модель его пропустила, это пропуск. Если вернула другое значение — неверное извлечение. Если в документе поля нет, а модель заполнила его, это лишнее значение. Эти группы подсказывают разные исправления: полнота чтения, понимание поля и склонность дополнять отсутствующие сведения.

Помимо доли точных полей посчитайте число документов, где верны все критические поля. Это ближе к решению о передаче документа дальше. Критическими могут быть номер, сумма и валюта; список зависит от процесса, а не от удобства модели.

Вычислите метрики на прозрачном наборе

Код сравнивает уже нормализованные значения. В одном документе ошибочна сумма, в другом модель придумала валюту, которой не было в источнике. Результат отдельно показывает точность полей и долю документов, прошедших критические условия. Значение None здесь означает подтверждённое отсутствие поля.

truth = [{"id": "a", "number": "001", "amount": "100.00", "currency": "RUB"},
         {"id": "b", "number": "002", "amount": "200.00", "currency": None}]
pred = {"a": {"number": "001", "amount": "10.00", "currency": "RUB"},
        "b": {"number": "002", "amount": "200.00", "currency": "RUB"}}
fields = ("number", "amount", "currency")
errors = {"missing": 0, "wrong": 0, "extra": 0}
correct = passed = 0
for row in truth:
    p = pred[row["id"]]
    passed += all(p.get(f) == row[f] for f in fields)
    for f in fields:
        expected, actual = row[f], p.get(f)
        if expected == actual:
            correct += 1
        else:
            kind = "extra" if expected is None else "missing" if actual is None else "wrong"
            errors[kind] += 1
assert errors == {"missing": 0, "wrong": 1, "extra": 1}
print({"field_accuracy": correct / (len(truth) * len(fields)),
       "critical_document_pass_rate": passed / len(truth), "errors": errors})

Разберите ошибки до смены модели

Для каждого неверного поля откройте страницу и место, которое модель использовала. Сумма может оказаться налогом, промежуточным итогом или значением из приложения. Тогда полезно уточнить определение поля и сохранить примеры таких документов. Если текст не распознан, работа начинается с извлечения и OCR.

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

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

Решение об автоматическом принятии принимают после оценки на репрезентативном наборе и с учётом последствий ошибки. Даже до этого проект может приносить пользу как подготовка заполненной формы для редактора. Главное — измерять качество именно тех полей, по которым следующий этап выполняет действие.

Продолжить проект на практике

Предметные метрики нужно включить в повторяемую оценку версии приложения. В платном курсе LLMOps & Evaluation вы подготовите тестовые наборы и собственный контур проверок, добавите quality-гейты в CI/CD. Это поможет принимать решение о выпуске по качеству важных полей и сохранять отчёт сравнения версий.

Откройте программу курса и выберите следующий этап своего проекта.

По теме: Версия eval-датасета: почему одной папки с вопросами недостаточно.