Razonamiento guiado por esquemas frente a structured outputs para LLMs

Traducción automática

Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Usa structured outputs cuando tu programa necesite campos con una estructura definida. Añade razonamiento guiado por esquemas (SGR) cuando el programa o un revisor también necesite registros intermedios, como la evidencia de las fuentes y una decisión propuesta. SGR usa structured output para expresar esos pasos; no es una garantía independiente de que la respuesta sea correcta.

Si el consumidor solo necesita una categoría y un ID de fuente, conserva esos campos. Añade campos de análisis únicamente cuando puedas explicar cómo se comprobarán o para qué se utilizarán.

Última revisión: 2026-09-08.

Qué hace cada capa

CapaQué proporcionaQué no puede establecer
Prompt de formato JSONInstrucciones para devolver JSONQue la respuesta siga un esquema
Salida restringida por un esquemaUna respuesta que sigue el esquema compatible cuando la generación finaliza correctamenteQue los valores sean verdaderos
Esquema SGRCampos intermedios con nombre y una decisión propuestaQue un campo se haya derivado correctamente de otro
Comprobaciones de la aplicaciónPruebas de la evidencia de las fuentes, los cálculos y las acciones permitidasHechos que la aplicación nunca verifica

La descripción de SGR de Rinat Abdullin utiliza esquemas como una lista de comprobación del trabajo devuelto por el modelo. En una configuración alojada en infraestructura propia, los structured outputs de vLLM pueden imponer JSON Schema mediante un backend de decodificación como XGrammar. Definir un modelo de Pydantic en Python por sí solo no activa el constrained decoding en el servidor.

Comprueba el subconjunto de esquemas compatible con el proveedor seleccionado y el estado de finalización. Una negativa, una respuesta truncada o una solicitud fallida necesitan su propia ruta de error. La guía de structured outputs de Gemini también señala el límite clave: una estructura JSON correcta no garantiza que los valores de los campos sean correctos.

Una propuesta de descuento muestra la diferencia

Supón que una herramienta de soporte puede ofrecer como máximo un descuento del 10 %. Una respuesta estructurada mínima podría contener discount_percent y customer_message. Si un revisor interno necesita pruebas, una respuesta SGR también podría contener policy_source_id y eligibility_evidence.

Esos campos adicionales proporcionan al revisor algo que inspeccionar. No hacen válida una propuesta de descuento del 15 %. Ni siquiera un esquema que limite el porcentaje al 10 % puede demostrar que este cliente cumple los requisitos.

Antes de utilizar la oferta, el código de la aplicación debe cargar la política aplicable y la ficha del cliente, comprobar la elegibilidad y calcular el importe permitido. Trata la explicación del modelo como una afirmación que debe comprobarse. Si un paso posterior del modelo necesita hechos aprobados, valídalos antes de realizar esa llamada. El orden de los campos dentro de un mismo objeto JSON no crea un paso de validación.

Cuándo ayudan los campos intermedios

SGR resulta útil cuando una respuesta incorrecta necesita un diagnóstico más preciso. Por ejemplo, un clasificador de documentos puede devolver un pasaje de origen y una categoría. Así, los revisores pueden distinguir una mala selección del pasaje de una categoría incorrecta cuando la evidencia es buena.

Es menos útil cuando cada resultado incluye una explicación larga que nadie lee ni puntúa. La salida adicional consume tokens y una explicación convincente puede seguir siendo falsa.

Compara el esquema pequeño con el esquema SGR usando los mismos casos etiquetados y el mismo modelo. Puntúa por separado la decisión final, el respaldo de la fuente y la validez de los campos. Conserva los campos intermedios si mejoran la decisión o hacen que la revisión sea lo bastante útil como para justificar el aumento de la salida. No des por hecho una mejora de la exactitud por el nombre del esquema.

Lecturas recomendadas