Ingosstrakh enseña a un LLM multimodal a dudar: los errores en documentos se buscan con logprobs

El equipo de tecnologías avanzadas del Centro de Desarrollo de Inteligencia Artificial de SPAO «Ingosstrakh» ha publicado en Habr un análisis sobre cómo detectar errores en las respuestas de un LLM multimodal que extrae datos estructurados de documentos entrantes directamente, sin pasar por OCR. La herramienta elegida no requiere un modelo evaluador aparte: son los logprobs, los logaritmos de las probabilidades de los tokens que el modelo ya entrega al generar texto. La cuestión de fondo es práctica: de los miles de documentos procesados, cuáles enviar a una persona y cuáles dejar pasar automáticamente.

Un JSON válido sin garantías

La tarea pertenece a la clase Intelligent Document Processing (IDP). La entrada es el escaneo o la foto de un documento; la salida, un JSON con campos como nombre completo, número de pasaporte, fechas e importes. El modelo multimodal lee la imagen por sí mismo, sin reconocimiento de texto intermedio.

Este esquema tiene un inconveniente. Un error en una cifra del pasaporte o en una letra del apellido no altera el formato de la respuesta. La estructura es correcta, el parser queda satisfecho y los datos erróneos pasan al siguiente sistema como si fueran fiables. Los clientes lo notaron pronto y empezaron a pedir un confidence score: una estimación que permita filtrar los resultados sospechosos.

En los pipelines de OCR clásicos, como CRNN, Surya, EasyOCR o Tesseract, esa estimación suele estar disponible por carácter, palabra o línea. Los autores aclaran que no garantiza la corrección y que puede requerir calibración, pero sirve como señal de partida para la selección. El sistema basado en LLM de Ingosstrakh no disponía de esa señal.

De dónde sale la señal

En cada paso, el modelo elige el siguiente token teniendo en cuenta la imagen, la instrucción y el texto ya generado. Para el token elegido se puede obtener su logprob. Cuanto menor es el valor, menos esperada era la continuación para el propio modelo.

Una salvedad importante del artículo: los logprobs no responden a la pregunta «¿se ha reconocido bien el campo?». Solo indican con cuánta seguridad siguió el modelo su propia trayectoria. Un modelo puede equivocarse con total seguridad, y una respuesta correcta puede recibir una probabilidad baja por un formato poco habitual o un mal escaneo. Por eso el equipo no usa las probabilidades en bruto, sino que construye con ellas una estimación de riesgo y la compara con los errores reales en los datos de la empresa.

Lo que se sabe a partir de la introducción publicada:

• tarea: extracción de datos estructurados de documentos entrantes (IDP);
• arquitectura: LLM multimodal sin etapa de OCR independiente;
• petición del negocio: un confidence score para enviar documentos a revisión manual;
• fuente de la señal: los token logprobs de los tokens elegidos;
• validación: con datos reales; las métricas de calidad concretas aparecen en el artículo completo.

La introducción no incluye resultados numéricos, así que aún es pronto para juzgar hasta qué punto la estimación de riesgo separa las respuestas erróneas de las correctas.

Cómo aplicar el enfoque

A continuación, mis conclusiones a partir del planteamiento del problema, no un resumen de los resultados de los autores.

Primero: conviene evaluar los campos, no el documento entero. La confianza media de una respuesta diluye con facilidad un único token dudoso en el número de pasaporte, por lo que tiene sentido mirar el mínimo u otra agregación de los tokens de cada campo.

Segundo: el umbral de revisión debe ajustarse al coste del error. Para el nombre completo y los documentos de identidad, tiene que ser más estricto que para los campos opcionales.

Tercero: sin una muestra etiquetada, la señal no sirve. Para saber si las probabilidades bajas se correlacionan con errores reales hacen falta respuestas de referencia y una medición de la proporción de errores detectados frente a la carga de los operadores. La calibración que los autores mencionan a propósito del OCR también será necesaria aquí.

Cuarto: conviene revalidar la lógica al cambiar de modelo o de versión del prompt. La distribución de probabilidades varía de un modelo a otro, y un umbral ajustado para uno puede comportarse de otro modo en otro.

Para los equipos que construyen pipelines de procesamiento de documentos con LLM, la conclusión principal es sencilla: el confidence score se obtiene casi gratis, pero solo se convierte de un simple número en una herramienta de enrutamiento útil después de validarlo con datos propios.