Fine-Tuning para Mejor Output JSON: Por Qué los Modelos Pequeños Fallan y Cómo Solucionarlo

Si has intentado que un modelo de 7B u 8B parámetros produzca JSON confiable, conoces el problema. Escribes un prompt cuidadoso especificando el esquema exacto. El modelo produce JSON válido el 60-70% de las veces. El otro 30-40% es una mezcla de comas finales, llaves de cierre faltantes, claves sin comillas y el ocasional campo alucinado que no estaba en tu esquema.

Esto no es un problema de prompting. Es un problema de datos de entrenamiento. Y el fine-tuning lo resuelve de manera decisiva.

El Problema del JSON en Modelos Pequeños

Los grandes modelos frontier — GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro — producen JSON válido con alta confiabilidad. Fueron entrenados en datasets masivos con extensos ejemplos de output estructurado, y su enorme cantidad de parámetros les da suficiente capacidad para internalizar la sintaxis JSON junto con todo lo demás que saben.

Los modelos pequeños (1B-8B parámetros) enfrentan una situación diferente. Vieron JSON durante el pre-entrenamiento, pero su capacidad limitada significa que las reglas estructurales compiten con la fluidez del lenguaje por los mismos pesos. El resultado es un modelo que "más o menos" conoce JSON — acierta la forma general pero falla en los detalles.

Aquí están los modos de falla concretos, medidos en Llama 3.1 8B base con una tarea de extracción estructurada en 1,000 entradas de prueba:

Esa tasa de éxito de 64.2% no es apta para producción. Incluso con lógica de reintento, estás desperdiciando tokens y agregando latencia. Y algunos modos de falla — como nombres de campo incorrectos o texto extra envolviendo el JSON — son difíciles de recuperar programáticamente.

Por Qué los Modelos Pequeños Tienen Problemas con JSON

La sintaxis JSON es rígida e implacable. El lenguaje natural tolera pequeños errores — una palabra mal escrita o un error gramatical raramente cambia el significado. JSON tiene tolerancia cero. Una sola comilla faltante, una coma extra o un corchete mal colocado produce output inválido que los parsers rechazan por completo. Los modelos pequeños optimizados para fluidez del lenguaje no ponderan la precisión sintáctica lo suficiente.

Ventanas de contexto más pequeñas pierden el rastro del anidamiento. Cuando un modelo genera un objeto JSON profundamente anidado, necesita recordar cada llave y corchete abierto para cerrarlos correctamente. En un objeto anidado de 3 niveles con arrays, el modelo podría estar 200+ tokens dentro de la generación antes de necesitar cerrar la llave exterior. Los modelos pequeños con capacidad de atención limitada pierden el rastro de esta estructura.

Los datos de pre-entrenamiento mezclan JSON con texto circundante. En el corpus de entrenamiento, JSON frecuentemente aparece dentro de bloques de código markdown, documentación, respuestas de API con encabezados y otros envoltorios. El modelo aprende que JSON "usualmente" tiene texto alrededor, por lo que a veces genera texto explicativo antes o después del objeto JSON.

Los límites de tokens no se alinean con la sintaxis JSON. El tokenizador divide {"name": en tokens que no se mapean limpiamente a los elementos estructurales de JSON. El modelo debe aprender la estructura JSON a un nivel de abstracción por encima de su vocabulario de tokens, lo cual requiere más capacidad de la que los modelos pequeños pueden disponer.

Por Qué el Fine-Tuning Lo Soluciona

El fine-tuning con miles de ejemplos correctos de JSON hace algo que el prompting no puede: desplaza los pesos del modelo para priorizar la corrección estructural para tu esquema específico.

Cuando ajustas con 2,000 ejemplos de JSON correctamente formateado, el modelo aprende:

• Los campos exactos de tu esquema. Deja de alucinar nombres de campo porque nunca ha visto otros campos en el entrenamiento.
• Patrones de anidamiento correctos. Ver miles de ejemplos de objetos correctamente anidados construye una comprensión estructural robusta que generaliza a nuevas entradas.
• Dónde empieza y termina el JSON. Los ejemplos de entrenamiento que son JSON puro (sin texto envoltorio) enseñan al modelo a producir JSON directamente.
• Manejo de casos límite. Arrays vacíos, valores null, cadenas con caracteres especiales — todo se vuelve confiable cuando se representa explícitamente en los datos de entrenamiento.

La diferencia es dramática. Aquí están los resultados de ajustar Llama 3.1 8B con LoRA (rango 16) en 2,000 ejemplos de una tarea de extracción de catálogo de productos:

El modelo ajustado no solo produce JSON válido — produce el JSON correcto. Los nombres de campo coinciden exactamente con el esquema. Los tipos de valor son correctos. El output se parsea limpiamente en el primer intento el 99.2% de las veces.

Construyendo el Dataset de Entrenamiento

La calidad de tus datos de entrenamiento determina la calidad de tu output JSON. Aquí está el enfoque sistemático:

Define Tu Esquema con Precisión

Comienza con una definición de esquema JSON. Sé explícito sobre cada campo:

{
  "type": "object",
  "properties": {
    "product_name": { "type": "string" },
    "price": { "type": "number" },
    "currency": { "type": "string", "enum": ["USD", "EUR", "GBP"] },
    "features": { "type": "array", "items": { "type": "string" } },
    "in_stock": { "type": "boolean" },
    "metadata": {
      "type": "object",
      "properties": {
        "sku": { "type": "string" },
        "weight_kg": { "type": ["number", "null"] }
      }
    }
  },
  "required": ["product_name", "price", "currency", "features", "in_stock"]
}

Genera Ejemplos Diversos

Usa un modelo frontier (GPT-4o, Claude) para generar pares de entrenamiento. La entrada es el texto crudo; la salida es el JSON correctamente formateado. Genera al menos 2,000 ejemplos y apunta a la diversidad:

• Varía la longitud y complejidad de la entrada. Descripciones de producto cortas, largas, con información faltante.
• Incluye cada caso límite. Arrays de features vacíos. Pesos null. Precios en cada moneda soportada. Productos con 1 feature y productos con 20.
• Incluye entradas adversarias. Texto que menciona JSON, texto con corchetes y llaves en el contenido, texto que podría confundir al modelo sobre dónde debe empezar el JSON.

Valida Cada Ejemplo de Entrenamiento

Este es el paso que la mayoría omite, y es el más importante. Pasa cada ejemplo de entrenamiento por un validador de JSON y un validador de esquema:

import json
import jsonschema

for example in training_data:
    # 1. ¿Es JSON válido?
    parsed = json.loads(example["output"])

    # 2. ¿Coincide con el esquema?
    jsonschema.validate(parsed, your_schema)

    # 3. ¿Son razonables los valores?
    assert parsed["price"] > 0
    assert len(parsed["product_name"]) > 0

Rechaza cualquier ejemplo que falle la validación. Un solo ejemplo malformado en el entrenamiento enseña al modelo que el output malformado es aceptable. Tolerancia cero con la calidad de los datos de entrenamiento.

Equilibra Tus Casos Límite

Si el 95% de tus ejemplos de entrenamiento tienen weight_kg no-null y solo el 5% tienen null, el modelo tendrá bajo rendimiento en los casos null. Sobremuestrea deliberadamente los casos límite:

• 10-15% de los ejemplos deben tener arrays vacíos
• 10-15% deben tener campos opcionales null
• 5-10% deben tener valores de cadena muy largos
• 5-10% deben tener estructuras profundamente anidadas

Decodificación Restringida: El Complemento Perfecto

El fine-tuning enseña al modelo a querer producir JSON válido. La decodificación restringida (también llamada muestreo basado en gramática) fuerza al modelo a producir JSON válido restringiendo la selección de tokens en cada paso de generación a solo tokens que mantienen la sintaxis JSON válida.

Usada sola, la decodificación restringida tiene un problema: el modelo puede producir JSON sintácticamente válido pero semánticamente incorrecto — llaves y corchetes correctos, pero nombres de campo o valores incorrectos. La "intención" del modelo era producir lenguaje natural, y la restricción gramatical lo forzó a una forma JSON.

Usados juntos, fine-tuning + decodificación restringida te dan resultados casi perfectos:

• El fine-tuning asegura que el modelo "intenta" producir el esquema JSON correcto con valores correctos
• La decodificación restringida captura el 0.8% restante de errores sintácticos

Esta combinación logra tasas de JSON válido de 99.9%+ en la práctica. En Ertas Deploy, el muestreo basado en gramática está disponible como opción de configuración para cualquier modelo desplegado.

Tutorial Práctico: Fine-Tuning para un Esquema de Respuesta de API

Aquí está el proceso de extremo a extremo para ajustar un modelo que produzca respuestas JSON compatibles con API:

1. Define la tarea. Extraer información estructurada de productos de descripciones no estructuradas y producir un objeto JSON que coincida con el esquema de respuesta de tu API.

2. Prepara los datos de entrenamiento. Genera 2,500 pares de entrada-salida usando un modelo frontier. Valida todos los outputs contra tu esquema. Después de la validación y filtrado, tienes 2,200 pares limpios.

3. Formatea como JSONL. Cada línea contiene una instrucción, entrada y salida:

{"instruction": "Extract product information as JSON.", "input": "The Aeropress Go travel coffee maker...", "output": "{\"product_name\": \"Aeropress Go\", \"price\": 39.95, ...}"}

4. Ajusta. En Ertas Studio: sube el JSONL, selecciona Llama 3.1 8B como modelo base, configura el rango LoRA a 16, la tasa de aprendizaje a 2e-4, y entrena por 3 épocas. El entrenamiento toma aproximadamente 45 minutos en una sola A100.

5. Evalúa. Ejecuta 200 ejemplos de prueba reservados a través del modelo ajustado. Mide la tasa de validez JSON, el cumplimiento del esquema y la precisión de valores. Compara contra el modelo base con tu mejor prompt.

6. Despliega con restricciones de gramática. Despliega en Ertas Deploy con el muestreo de gramática JSON habilitado. Esto captura la última fracción de porcentaje de errores sintácticos.

Implicaciones para Uso de Herramientas y Function Calling

La confiabilidad del output JSON no es solo sobre extracción de datos. Es la base para:

Tool calling de agentes. Cuando un agente de IA necesita llamar funciones, genera argumentos JSON. Un modelo que produce JSON inválido el 35% del tiempo es un agente que falla el 35% del tiempo. Ajustar el modelo con las firmas de tus funciones específicas hace que el tool calling sea confiable.

Flujos de trabajo multi-paso. En pipelines donde el output JSON de un modelo alimenta a otro modelo o servicio, una sola respuesta malformada rompe toda la cadena. El fine-tuning hace que los pipelines sean robustos.

APIs de cara al cliente. Si estás construyendo un producto donde el output del modelo de IA es parte de la respuesta de tu API, la confiabilidad del JSON es un tema de calidad del producto. A tus clientes no les importa por qué el JSON está malformado — solo ven un error.

Logging estructurado y analítica. Los modelos que producen esquemas JSON consistentes habilitan analítica downstream. Cuando el esquema es confiable, puedes enviar los outputs del modelo directamente a bases de datos y dashboards sin una capa de manejo de errores.

En Resumen

Los modelos pequeños son capaces de producir output JSON perfectamente confiable. Solo necesitan la señal de entrenamiento correcta. Un dataset de fine-tuning de 2,000 ejemplos, construido con validación adecuada y cobertura de casos límite, transforma una tasa de validez JSON de 64% a 99%+. Agrega decodificación restringida y llegas a 99.9%.

La inversión es pequeña: unas pocas horas de preparación de datos, $20-50 en costos de generación de datos de entrenamiento, y 45-90 minutos de tiempo de entrenamiento. El retorno es un modelo que produce output estructurado listo para producción cada vez.

---

Lectura relacionada:

• Ajusta un Modelo para Tu App — guía más amplia sobre fine-tuning específico para aplicaciones
• Cómo Ajustar un LLM: La Guía Completa — los fundamentos técnicos del proceso de fine-tuning