Validar, reintentar con el error y saber cuándo no reintentar

La herramienta de extracción ya garantiza JSON válido. Pero el total de la factura dice 1.250,00 y las líneas suman 1.200,00. El esquema no lo ve; lo tiene que ver tu código. La pregunta es qué hacer cuando la validación falla.

Validar en código

Las reglas de coherencia (que las líneas sumen el total, que las fechas caigan dentro del período, que un porcentaje esté entre 0 y 1) son comprobaciones deterministas: van en código, no en el prompt. Así se cumplen siempre igual y producen un error concreto.

Un truco de diseño del esquema ayuda a que el propio modelo deje la pista:

• extraer calculated_total (la suma de las líneas) al lado de stated_total (lo que dice el documento) y marcar la diferencia;
• agregar un booleano conflict_detected cuando la fuente se contradice (dos fechas de emisión distintas en dos páginas).

El reintento que corrige

Un reintento con el error (retry with error feedback) le manda al modelo tres cosas:

1. el documento original (para que compare contra la fuente);
2. la extracción fallida;
3. el error concreto: qué campo, qué regla incumple y qué valor llegó. Por ejemplo: “El campo vat_rate tiene que ser un número entre 0 y 1; llegó ‘21%’. Devolvé el campo corregido.”

“Sé más preciso” o repetir el mismo pedido no le dice qué arreglar. Si el dato puede faltar, aclaralo en el mismo mensaje: “si la fecha no está en el documento, devolvé null”. Si no, el reintento empuja al modelo a inventar.

Cuándo el reintento no sirve

Falla	¿Reintentar con feedback?
Formato distinto al del esquema (04/03/26 en vez de 2026-03-04)	Sí
Estructura mal armada, valor en el campo equivocado	Sí
Las líneas no suman el total por un error de lectura	Sí
El dato no está en el documento (contrato sin vencimiento)	No: registralo como ausente
El dato está en otro documento que no se pasó (un anexo)	No: falta la entrada, no la corrección
Timeout de la API	Reintento con espera creciente (backoff) y la misma entrada, sin feedback

Un reintento no puede crear información que la fuente no tiene. Insistir hasta obtener un valor solo produce un valor inventado.

Tope y salida

Poné un tope chico de reintentos. Al agotarlo, el documento va a revisión humana con los errores adjuntos. Si algo no puede avanzar sin validación (un reclamo que falló dos veces no se aprueba solo), lo bloquea un control en código que lee el estado de validación, no una instrucción al modelo.

Medí el bucle: tasa de aprobación al primer intento y después del reintento, por tipo de error y en el tiempo. Si casi todos los segundos intentos son por un mismo campo, el problema está en su descripción o en la instrucción de formato: corregila y volvé a medir.

El bucle en revisión de código

En una revisión en CI, el bucle de retroalimentación (feedback loop) es otro: los desarrolladores descartan hallazgos y nadie sabe por qué. Si cada hallazgo trae un campo detected_pattern con la construcción de código que lo disparó, podés agrupar los descartes. Por ejemplo, descubrir que un patrón explica el 61% de los descartes, casi todos en archivos de test, aunque en producción es valioso. El arreglo es un criterio explícito para ese contexto, con ejemplos, y volver a medir; no apagar la categoría entera.

Las trampas típicas

• Reintentar sin el documento o sin el error concreto.
• Reintentar datos que no existen en la fuente.
• Meter las reglas de sumas en el prompt en vez de en un validador.
• Reintentos sin tope, o que al fallar dejan pasar el documento en silencio.

En el examen

Preguntate dónde está la información que falta. Si está en el documento y salió mal, reintento con documento, salida fallida y error. Si no está, null o revisión humana. Si el escenario habla de descartes que no se pueden agrupar, la respuesta es detected_pattern.