Schema-guided reasoning 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 forma definida. Añade schema-guided reasoning (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
JSON formatting promptInstrucciones para devolver JSONQue la respuesta siga un schema
Schema-constrained outputUna respuesta que sigue el schema compatible cuando la generación finaliza correctamenteQue los valores sean verdaderos
SGR schemaCampos 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 schemas como una lista de comprobación del trabajo devuelto por el modelo. En una configuración self-hosted, los structured outputs de vLLM pueden imponer JSON Schema mediante un backend de decoding como XGrammar. Definir un modelo de Pydantic en Python por sí solo no activa el constrained decoding en el servidor.

Comprueba el subconjunto de schemas 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 schema 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 justifican su presencia los campos adicionales

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 schema pequeño con el schema 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 accuracy por el nombre del schema.

Lecturas recomendadas