Ингосстрах учит мультимодальную LLM сомневаться: ошибки в документах ищут по logprobs

Команда перспективных технологий Центра развития искусственного интеллекта СПАО «Ингосстрах» опубликовала на Хабре разбор того, как находить ошибки в ответах мультимодальной LLM, которая вытаскивает структурированные данные из входящих документов напрямую, минуя OCR. Инструмент, который для этого выбрали, не требует отдельной модели-оценщика: это logprobs, логарифмы вероятностей токенов, которые модель и так выдаёт при генерации. Сам вопрос практический: какие из тысяч обработанных документов отправить человеку, а какие пропустить дальше автоматически.

Валидный JSON без гарантий

Задача относится к классу Intelligent Document Processing (IDP). На входе скан или фото документа, на выходе JSON с полями: ФИО, номер паспорта, даты, суммы. Мультимодальная модель читает изображение сама, без промежуточного распознавания текста.

У такой схемы есть неприятное свойство. Ошибка в одной цифре паспорта или в букве фамилии не нарушает формат ответа. Структура корректна, парсер доволен, а неверные данные уходят в следующую систему под видом достоверных. Заказчики это быстро заметили и стали просить confidence score: оценку, по которой можно отсеивать подозрительные результаты.

В классических OCR-пайплайнах вроде CRNN, Surya, EasyOCR или Tesseract такая оценка обычно доступна для символа, слова или строки. Авторы оговариваются: она не гарантирует правильность и может требовать калибровки, но служит исходным сигналом для отбора. У LLM-системы Ингосстраха такого сигнала не было.

Откуда берётся сигнал

Модель на каждом шаге выбирает следующий токен, учитывая изображение, инструкцию и уже сгенерированный текст. Для выбранного токена можно получить logprob. Чем ниже значение, тем менее ожидаемым было продолжение для самой модели.

Важная оговорка из статьи: logprobs не отвечают на вопрос «поле распознано верно?». Они говорят лишь о том, насколько уверенно модель шла по своей траектории. Модель может уверенно ошибаться, а правильный ответ может получить низкую вероятность из-за редкого формата или плохого скана. Поэтому команда не использует сырые вероятности напрямую, а строит из них оценку риска и сверяет её с реальными ошибками на данных компании.

Что известно из опубликованного вступления:

• задача: извлечение структурированных данных из входящих документов (IDP);
• архитектура: мультимодальная LLM без отдельного этапа OCR;
• запрос бизнеса: confidence score для маршрутизации документов на ручную проверку;
• источник сигнала: token logprobs выбранных токенов;
• проверка: на реальных данных, конкретные метрики качества приведены в полной статье.

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

Как применять подход

Ниже мои выводы из постановки задачи, а не пересказ результатов авторов.

Первое: оценивать стоит поля, а не весь документ. Средняя уверенность по ответу легко размывает один сомнительный токен в номере паспорта, поэтому логично смотреть на минимум или иную агрегацию по токенам конкретного поля.

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

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

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

Для команд, которые строят LLM-пайплайны обработки документов, главный вывод простой: confidence score можно получить почти бесплатно, но только после проверки на собственных данных он превращается из числа в рабочий инструмент маршрутизации.