aicert.study
Trayecto de Estudio/La salida estructurada es un contrato no confiable por defecto

La salida estructurada es un contrato no confiable por defecto

75 min

Recomendamos ver antes: Valide la afirmación, no la confianza, La Messages API es una máquina de estados

Objetivos de la lección

  • Forzar el formato con tool use y tool_choice en lugar de instrucciones sueltas
  • Validar, reintentar y devolver el error semántico al modelo
  • Separar fallos de forma (schema) de fallos de contenido (hecho incorrecto)

El problema

Un equipo solicita al modelo en texto libre que "responda en formato JSON con los campos nombre, valor y fecha". La mayor parte del tiempo funciona según lo previsto. De vez en cuando, el modelo envuelve el JSON en un párrafo explicativo, utiliza comillas simples en lugar de dobles u omite un campo opcional. El analizador sintáctico (parser) falla silenciosamente en producción una vez cada varios cientos de llamadas — lo bastante raro como para no manifestarse en pruebas manuales, pero lo suficientemente frecuente como para provocar incidentes reales a escala.

La causa no es que el modelo "haya fallado aleatoriamente". Es haber tratado una instrucción en lenguaje natural ("responde en JSON") como si fuera una garantía estructural, cuando en realidad las instrucciones en el prompt son sugerencias fuertes, no contratos deterministas.

Forzar el formato mediante tool use y tool_choice, no con instrucciones sueltas

La forma robusta de garantizar la estructura no consiste en pedirlo amablemente en el prompt — es utilizar tool use con un esquema JSON explícito y forzar su invocación mediante tool_choice. Incluso cuando la "herramienta" no ejecuta una acción externa real (sirviendo puramente como esquema de extracción estructurada), esta técnica resulta fundamental: defines las propiedades, los tipos y los campos requeridos, obligando al modelo a responder bajo esa estructura.

Esto reduce drásticamente los fallos de forma (JSON malformado, claves faltantes, tipos de datos erróneos) porque la generación queda restringida por la definición del esquema y no solo guiada por probabilidades de texto. No obstante, reducir no es eliminar: la validación semántica sigue siendo obligatoria — el esquema garantiza que el campo valor es un número, no que ese número sea el correcto.

Validar, reintentar y devolver el error semántico

Cuando una salida no supera la validación — ya sea de forma o de contenido —, la reacción ingenua es descartarla y reintentar con el mismo prompt original esperando mejor suerte. Esto desperdicia llamadas y latencia la mayoría de las veces, porque el modelo no recibe información nueva sobre el motivo del fallo.

La arquitectura defensiva cierra el bucle de retroalimentación: cuando la validación falla, el error específico — no un genérico "inténtalo de nuevo", sino "el campo fecha no cumple con el formato ISO-8601" o "el valor total no coincide con la suma de los conceptos" — se devuelve al modelo en el siguiente turno. Esto transforma un reintento a ciegas en una corrección guiada con una tasa de recuperación mucho más alta.

Dos fallos independientes, dos defensas independientes

Esta lección conecta directamente con la validación de salidas: los fallos de forma (esquema incorrecto) y los fallos de contenido (datos erróneos dentro de un esquema válido) son problemas ortogonales que requieren defensas independientes:

  • Defensa contra fallos de forma: tool use con esquema + tool_choice, validación automática del esquema y reintentos devolviendo el error sintáctico al modelo.
  • Defensa contra fallos de contenido: validación semántica que contrasta el dato con el documento fuente o reglas de negocio (¿el valor coincide con la factura original? ¿la fecha está en un rango permitido?), de manera totalmente independiente del formato.

Una arquitectura madura desacopla ambas capas, ya que una respuesta puede superar la primera y fallar en la segunda — una canalización que solo valida la sintaxis carece por completo de protección frente a errores semánticos, que son habitualmente los más costosos.

Dónde falla la intuición

  • "Si pido claramente en el prompt que responda en JSON, el modelo siempre cumplirá." Las instrucciones en lenguaje natural no ofrecen garantías estructurales — las anomalías de formato ocasionales son inevitables sin restricción de esquema.
  • "Si la validación falla, basta con reintentar con el mismo prompt." Sin devolver el error específico, los reintentos a ciegas presentan bajas tasas de éxito; la verdadera mejora surge al cerrar el bucle con el error semántico.
  • "Un esquema JSON estricto garantiza que los datos sean correctos." Garantiza la estructura, no la veracidad. La validación semántica contra fuentes de verdad sigue siendo imprescindible.

Ponlo en práctica

En el laboratorio de esta lección implementarás una canalización de extracción con dos capas de validación — forma y contenido — junto con un mecanismo de retroalimentación que reenvía el error específico para una segunda pasada, evaluando la mejora en la tasa de éxito frente a un reintento ciego.

Laboratorio práctico

Clona el repositorio y ejecútalo localmente:

git clone https://github.com/aicertstudy/labs
cd labs/ccar-f/lessons/09-structured-output-and-defensive-parsing
Ver carpeta en GitHub

¿Listo para ponerlo a prueba de verdad?

Haz el simulacro completo del CCAR-F, con el mismo formato del examen oficial.

Ver simulacros

Checkpoint de la lección

Cargando quiz...