JSON vs TOON: reducir tokens de salida al extraer datos

Estás extrayendo datos de facturas PDF con IA. Cada factura tiene una tabla con los productos importados: código arancelario, descripción, cantidad, peso, precio unitario, total. Algunas facturas tienen 15 líneas. Otras tienen 300.

Le pides al modelo que te devuelva un JSON estructurado y todo funciona — hasta que no. En un lote de facturas internacionales particularmente densas, la respuesta se truncó. El modelo llegó al límite de tokens de salida y cortó el JSON a la mitad. Datos incompletos, JSON inválido, y un pipeline roto.

Esto nos pasó en DocuTray. Y una de las opciones que evaluamos fue cambiar el formato de salida.

El cuello de botella real: tokens de salida

Cuando hablamos de límites de contexto en LLMs, la conversación suele girar alrededor del input. Gemini 3.1 Pro acepta 1M tokens de entrada, GPT-5.4 llega a 272K (o 1M con context window expandido). Suena a mucho. Pero el output es otra historia: Gemini 3.1 Pro tiene un máximo de 64K tokens de salida, GPT-5.4 de 128K.

Para procesamiento de documentos con IA, los tokens de salida son el recurso más escaso y el más caro. En Gemini 3.1 Pro los tokens de salida cuestan 6x más que los de entrada ($2 vs $12 por millón). En GPT-5.4, la proporción es 3x ($10 vs $30). En Claude Opus 4.6, 5x ($5 vs $25).

Cuando le pides a un modelo que te devuelva una tabla de 200 productos en JSON, cada línea repite las mismas keys: "codigo_arancelario", "descripcion", "cantidad", "peso_kg", "precio_unitario", "total". Esas keys se repiten 200 veces. Son tokens de salida que no aportan información nueva — solo estructura.

La pregunta es obvia: ¿se puede representar la misma data con menos tokens?

Qué es TOON y por qué lo evaluamos

TOON (Token-Oriented Object Notation) es un formato diseñado específicamente para reducir el consumo de tokens en interacciones con LLMs. La idea es simple: mantener el mismo modelo de datos que JSON, pero eliminar la sintaxis repetitiva.

Las dos diferencias clave:

1. Objetos por indentación, no por llaves. Como YAML, los objetos anidados se representan con indentación en vez de { y }.
2. Arrays tabulares. Cuando tienes un array de objetos con la misma estructura (como líneas de una factura), TOON declara los campos una vez como header y lista los valores como filas — tipo CSV, pero con contexto.

Para entender la diferencia, acá va un ejemplo concreto. Supón que extraes datos de una factura internacional con tres líneas de producto.

JSON (lo que le pides hoy al modelo):

{
  "factura": {
    "numero": "INV-2026-0847",
    "proveedor": "Shanghai Electronics Co.",
    "moneda": "USD"
  },
  "productos": [
    {
      "codigo_arancelario": "8471.30.00",
      "descripcion": "Laptop 14 pulgadas 16GB RAM",
      "cantidad": 150,
      "peso_kg": 262.5,
      "precio_unitario": 420.00,
      "total": 63000.00
    },
    {
      "codigo_arancelario": "8471.60.00",
      "descripcion": "Monitor LED 27 pulgadas",
      "cantidad": 80,
      "peso_kg": 320.0,
      "precio_unitario": 285.00,
      "total": 22800.00
    },
    {
      "codigo_arancelario": "8473.30.00",
      "descripcion": "Teclado mecánico USB-C",
      "cantidad": 500,
      "peso_kg": 225.0,
      "precio_unitario": 35.00,
      "total": 17500.00
    }
  ]
}

TOON (la misma data, menos tokens):

factura:
  numero: INV-2026-0847
  proveedor: Shanghai Electronics Co.
  moneda: USD
productos[3]{codigo_arancelario,descripcion,cantidad,peso_kg,precio_unitario,total}:
  8471.30.00,Laptop 14 pulgadas 16GB RAM,150,262.5,420.00,63000.00
  8471.60.00,Monitor LED 27 pulgadas,80,320.0,285.00,22800.00
  8473.30.00,Teclado mecánico USB-C,500,225.0,35.00,17500.00

La declaración productos[3]{codigo_arancelario,descripcion,...} dice: "lo que sigue son 3 objetos con estos campos". Los valores van como filas separadas por comas. Sin llaves, sin comillas, sin keys repetidas.

En este ejemplo con 3 productos, la diferencia no es dramática. Pero con 200 productos, cada key que se repite 200 veces en JSON se declara una sola vez en TOON. En nuestra experiencia, eso se traduce en ~40% menos tokens de salida para respuestas con tablas densas.

Los benchmarks públicos de TOON confirman números similares: en una tabla de 500 filas, JSON-compact usa 3,924 tokens vs 2,498 en TOON — 36% menos. Para un pipeline que procesa miles de facturas al mes, eso es una reducción significativa en costos y en riesgo de truncamiento.

Por qué no lo adoptamos

Hasta acá suena perfecto. Menos tokens, misma data, formato limpio. Pero cuando lo probamos en producción, encontramos tres problemas que no aparecen en los benchmarks.

1. Traducir JSON schema a TOON schema no es trivial

Nuestros schemas de extracción no son tablas planas. Una factura tiene datos del emisor (objeto anidado), datos del receptor (otro objeto anidado), líneas de producto (array), y totales con desglose de impuestos (más anidamiento). TOON brilla con arrays uniformes de objetos simples, pero cuando tienes campos anidados — un producto que a su vez tiene un objeto impuestos con iva, arancel, y otros — el formato tabular se rompe.

No todos los JSON schemas se pueden representar en TOON. Y los que sí se pueden, requieren aplanar estructuras que originalmente tenían sentido anidadas. Eso agrega complejidad al parser que recibe la respuesta y la re-estructura.

2. No se puede forzar la estructura de salida

Con JSON, los principales proveedores ofrecen structured output — le pasas un JSON schema al modelo y garantiza que la respuesta lo cumple. Con TOON no existe un equivalente. No hay un parámetro response_format: toon que puedas activar.

En la práctica, esto significa que el modelo puede decidir cambiar el orden de las columnas, omitir una que consideró vacía, o agregar una que le pareció relevante. En un lote de 500 facturas, tuvimos respuestas donde la columna peso_kg aparecía en la posición 4 en unas facturas y en la posición 5 en otras. Algunas respuestas directamente omitían columnas.

Cuando procesas documentos a escala, la consistencia es más valiosa que la eficiencia. Un JSON con structured output siempre tiene los mismos campos en el mismo lugar. Un TOON libre no te da esa garantía.

3. Los LLMs no conocen TOON (todavía)

TOON es un estándar nuevo. Los modelos no fueron entrenados con cantidades significativas de datos en este formato. Cuando le pedimos a Claude que nos respondiera en TOON, le tuvimos que pedir que buscara sobre el esquema en internet, por que lo confundio con otra cosa.

Es un problema de gallina y huevo: TOON necesita adopción para que los modelos lo aprendan, pero los modelos necesitan conocerlo para que valga la pena adoptarlo.

Qué sí funciona para reducir tokens de salida

El problema que TOON intenta resolver es real. Los tokens de salida son caros y los límites de output truncan datos. Pero la solución que encontramos más confiable no fue cambiar el formato — fue cambiar la estrategia de extracción.

En DocuTray, en vez de pedir que el modelo extraiga todo el documento en una sola llamada, partimos el documento en secciones y hacemos extracciones focalizadas. Una llamada API para los datos del header, otra para las líneas de producto, otra para los totales. Cada respuesta es más pequeña, cabe cómodamente en los límites de output, y usa JSON con structured output para garantizar la estructura.

¿Es más llamadas API? Sí. ¿Es más confiable que pedirle al modelo que responda en un formato que apenas conoce? También.

El tradeoff real

TOON resuelve un problema genuino con un enfoque elegante. Si tu caso de uso son tablas planas y uniformes — un CSV con headers, básicamente — la reducción de tokens es real y significativa. Los benchmarks no mienten.

Pero en procesamiento de documentos reales, los datos rara vez son planos. Facturas con impuestos anidados, contratos con cláusulas que referencian otras cláusulas, órdenes de compra con condiciones de pago condicionales. Ahí TOON pierde su ventaja, y la falta de structured output se convierte en un riesgo que no vale la pena tomar.

Probamos TOON, aprendimos sus límites, y elegimos otro camino. Si estás evaluando cómo reducir tus tokens de salida al extraer datos de facturas PDF, la recomendación es pragmática: antes de cambiar el formato, evalúa si puedes partir la extracción.