Bucles de reparación y validación

Incluso con esquemas, la salida puede fallar: JSON truncado por un límite de tokens, campos adicionales alucinados, una cadena donde se requería un número o una regla de negocio incumplida. Un bucle de reparación detecta el fallo y se lo devuelve al modelo para que lo corrija.

Es la red de seguridad que convierte una tasa de éxito del 98 % en una del 99,9 %.

El bucle canónico es: generar, validar y, si no es válido, volver a solicitar la respuesta con el error específico, hasta un número limitado de intentos.

La calidad de la reparación depende de la precisión de los comentarios. 'JSON no válido' ayuda poco; 'El campo rating debe ser un entero entre 1 y 5, pero se obtuvo 7' casi siempre lo corrige en un solo turno.

Devuelva al modelo el mensaje de error exacto del validador, incluida la ruta y el motivo.

La validación tiene varios niveles; compruebe primero el más barato:

• Sintáctica — ¿se puede analizar como JSON?
• Estructural — ¿coincide con el esquema?
• Semántica — ¿los valores cumplen las reglas de negocio y las invariantes entre campos?

Un descuento no puede superar el subtotal aunque ambos sean números válidos; esa es una comprobación semántica.

Antes de realizar una llamada al modelo, pruebe correcciones deterministas y económicas para los defectos habituales:

• Elimine los bloques de código de Markdown.
• Extraiga el objeto JSON más externo de la prosa que lo rodea.
• Elimine las comas finales.

Recurra a una reparación mediante el modelo solo si falla la limpieza determinista.

Si finish_reason == 'length', el JSON está incompleto; reparar el fragmento es inútil. En su lugar, aumente max_tokens, reduzca la carga solicitada o transmita la respuesta y solicite una continuación. Distinga la truncación de una salida mal formada, porque requieren respuestas opuestas.

Una reparación sin límites supone un riesgo de costes y latencia, y un modelo atascado podría repetir el bucle indefinidamente. Limite siempre los intentos, añada un presupuesto por solicitud y defina una alternativa (degradar el servicio de forma controlada, enviar la solicitud a revisión humana o devolver un valor predeterminado seguro).

En las llamadas de funciones, el canal de reparación es el resultado de la herramienta. Devuelva un error estructurado y el modelo se autocorregirá en el siguiente turno; no hace falta un bucle independiente.

Cuando un bucle de reparación envuelve una acción (y no solo una generación), asegúrese de que los reintentos sean idempotentes. Use claves de idempotencia para que una llamada repetida no cobre dos veces ni duplique un registro. Valide antes de confirmar los efectos secundarios, nunca después.

La tasa de reparación es un indicador temprano de calidad. Un aumento de esta tasa indica una regresión del prompt, un esquema demasiado estricto o una deriva del modelo. Registre los intentos por éxito y las principales rutas de error, y genere una alerta cuando se disparen.

La canalización más sólida combina varias defensas: decodificación restringida o un modo de esquema estricto para minimizar los fallos, limpieza determinista para las correcciones económicas y un bucle limitado de reparación mediante el modelo para los casos residuales poco frecuentes. Ninguna capa es suficiente por sí sola.

Canalizaciones de reparación sólidas:

• Valide por niveles: sintáctico, estructural y semántico.
• Devuelva al modelo errores precisos y asociados a rutas concretas.
• Pruebe la limpieza determinista antes de pagar por una llamada al modelo.
• Detecte la truncación por separado y vuelva a generar la respuesta.
• Limite los intentos, garantice la idempotencia y supervise las tasas de reparación.

Ha completado la generación estructurada. Próximo curso: barreras de seguridad y validación de salidas.