Validación y reintento: errores de sintaxis, errores semánticos y totales que no cuadran

Bienvenidos y bienvenidas a la cápsula cinco del Módulo uno. Hoy vemos la primera parte del task statement cuatro punto cuatro: validar lo que el modelo extrae y decidir cuándo vale la pena reintentar.

La guía oficial distingue dos tipos de error. Los errores de sintaxis del esquema los elimina tool use. Los errores semánticos, como montos que no suman o datos puestos en el campo equivocado, tool use no los elimina, y los detectas con tu propio código, por ejemplo con Pydantic.

Cuando la validación falla, la guía describe un reintento con retroalimentación. Es una petición de seguimiento que lleva el documento original y la extracción fallida, junto con los errores de validación específicos. Un reintento que repite la misma petición desperdicia la llamada, porque el modelo no sabe qué hizo mal.

Los límites del reintento aparecen mucho en preguntas de respuesta múltiple. Si el error es de formato o de estructura, como una fecha con otro formato o una partida mal ubicada, entonces reintentar con el error específico funciona. Por su parte, si la información no está en el documento, como un dato que vive en un anexo que nadie entregó, entonces ningún reintento la va a crear, y lo correcto es aceptar nulo o marcar el caso para revisión humana. Además, si lo que falla es un total que no cuadra, entonces no le pides al modelo que corrija los números para que sumen, porque eso esconde un problema real del documento.

La guía propone dos campos para eso. El campo calculated total es la suma que hace el modelo de las partidas, y el campo stated total es el total que declara el documento. Cuando difieren, se marca. Y el campo conflict detected, verdadero o falso, avisa que la fuente misma es inconsistente. Así la diferencia queda registrada como dato, y no escondida en una decisión silenciosa del modelo.

Una pregunta. ¿Cuándo sirve reintentar una extracción y cuándo no?

Sirve cuando el error es de formato o de estructura y el modelo recibe el error específico para corregirse. No sirve cuando el dato no existe en el documento, ni cuando el documento mismo es inconsistente.

Pregunta uno. Una fábrica de neumáticos extrae los datos de sus órdenes de compra. Una orden declara un total de dos mil cuatrocientos, pero sus partidas suman dos mil doscientos cincuenta, y el sistema reintenta la extracción cuatro veces con el mismo resultado. ¿Qué cambio conviene? Opción A: reintentar con un modelo más grande. Opción B: extraer el total calculado junto al total declarado, activar el campo conflict detected y derivar la orden a revisión en lugar de reintentar. Opción C: promediar los dos totales. Opción D: descartar la orden en silencio.

La correcta es B. La extracción es fiel al documento, y la diferencia está en la orden, así que queda registrada como dato y alguien la revisa. La A insiste con más potencia sobre algo que el modelo no puede arreglar. La C inventa un total que nadie declaró. La D pierde un caso que sí requiere atención.

Pregunta dos, de respuesta múltiple. Elige dos. Una lavandería industrial extrae datos de sus facturas. Algunas no traen el número de contrato, que vive en otro documento. Otras traen la fecha en un formato que el validador rechaza. ¿Qué dos medidas corresponden? Opción A: reintentar ambos casos hasta que salga. Opción B: completar el contrato a partir de otras facturas del mismo cliente. Opción C: aceptar nulo y marcar como ausente el contrato que no está en el documento. Opción D: ignorar los errores de formato de la fecha. Opción E: reintentar las fechas enviando el documento, la extracción fallida y el error de validación específico. ¿Cuáles dos?

Las correctas son C y E. La C acepta que el dato no existe y lo deja marcado, y la E le da al modelo lo que necesita para corregir un error de formato. La A gasta llamadas en un dato que no aparece. La B inventa un número que el documento nunca trajo. La D deja pasar un error que sí tiene arreglo.

Resumen: el reintento con el error específico sirve para fallas de formato. No sirve cuando el dato no existe, y un total que no cuadra se registra con el campo conflict detected y se revisa. Si te sirvió, sigue el podcast, dale cinco estrellas y activa las notificaciones. En la próxima cápsula vemos los feedback loops, para aprender de los errores que el sistema ya cometió. Nos escuchamos en la próxima cápsula de EvoAcademy.