TOON: ¿El Fin del JSON en los Prompts de LLM? Menos Tokens, Más Eficiencia

¡Hola, devs!

En el mundo del desarrollo con LLMs, hay una verdad universal: los tokens cuestan dinero. Cada caracter, cada espacio, cada comilla en un prompt se suma a la factura y consume un valioso espacio de contexto. Durante años, hemos usado JSON para todo, pero seamos honestos: es increíblemente "verboso" para las máquinas que piensan en tokens.

^{{ "id": 1, "name": "Alice" }}

Cada llave, cada comilla, cada coma... se repite una y otra vez en un array. ¿Y si hubiera una forma mejor?

Recientemente, ha surgido un nuevo contendiente que está dando mucho que hablar: TOON (Token-Oriented Object Notation). Y su propuesta es simple: ser para los LLMs lo que JSON es para las APIs web, pero haciéndolo de forma mucho más eficiente.

¿Qué es Exactamente TOON?

TOON no es un reemplazo de JSON en tu base de datos o en tu API. Piénsalo más como una capa de traducción optimizada. La idea es que sigas usando JSON programáticamente, pero justo antes de enviar tus datos al LLM, los codifiques en formato TOON.

Su "salsa secreta" es combinar la estructura de indentación de YAML con un diseño tabular al estilo CSV, pero diseñado específicamente para listas de objetos.

Veamos el clásico ejemplo. Este es tu JSON:

1{
2  "users": [
3    { "id": 1, "name": "Alice", "role": "admin" },
4    { "id": 2, "name": "Bob", "role": "user" }
5  ]
6}

Y este es el equivalente en TOON:

1users[2]{id,name,role}:
2  1,Alice,admin
3  2,Bob,userLa magia es evidente:

1. Define las claves una sola vez: users[2]{id,name,role}. Las claves id, name y role no se repiten en cada fila, ahorrando una cantidad masiva de tokens en listas grandes.

2. Longitud explícita: El [2] le dice explícitamente al modelo cuántos elementos esperar. Esto actúa como un "guardrail" (barandilla) que ayuda al LLM a validar la entrada y generar salidas más coherentes.

3. Sintaxis mínima: Adiós a las llaves, corchetes y la mayoría de las comillas. Usa indentación para objetos anidados.

Las Ventajas Clave (No solo se trata de Tokens)

Según las pruebas y la especificación oficial, TOON no solo es más pequeño, sino también más inteligente.

• 💸 Eficiencia de Tokens: El GitHub oficial y varios análisis reportan ahorros del 30% al 60% en tokens en comparación con JSON formateado, especialmente en arrays grandes y uniformes. Menos tokens = menos coste de API y más datos en tu ventana de contexto.

• 🤿 "Guardrails" para el LLM: La estructura explícita ([N] y {campos}) no es solo para ahorrar espacio; es un esquema "schema-aware" que guía al LLM. Esto mejora la fiabilidad, la validación de datos y la precisión en tareas de extracción estructurada.

• 🧺 Formato Tabular: Su punto dulce son los arrays uniformes de objetos (como logs, resultados de RAG, catálogos de productos), donde logra una compacidad similar a la de CSV pero manteniendo la estructura explícita que CSV pierde.

El Debate: ¿Vale la Pena la Complejidad?

Ahora bien, no todo es perfecto. Como señala el análisis de Q2BStudio, adoptar un nuevo formato introduce una nueva capa de complejidad.

La principal crítica es que, aunque TOON ahorra tokens, reduce la legibilidad humana en comparación con un JSON bien formateado (aunque es más legible que un JSON minificado). Además, introduce una dependencia más en tu stack y una curva de aprendizaje para el equipo.

La pregunta que todo equipo debe hacerse es: ¿El ahorro de tokens justifica el coste añadido en mantenimiento, depuración y formación?

Para algunas aplicaciones, la respuesta es un "no" rotundo. Como argumentan algunos, los LLMs están entrenados para manejar JSON estándar (incluso Protobuf) extremadamente bien, y existen otras técnicas de compresión.

Cuándo NO Usar TOON

El propio repositorio de TOON es honesto sobre sus limitaciones. No es una bala de plata.

• Datos muy anidados o no uniformes: Si tus arrays contienen objetos con estructuras muy diferentes entre sí, JSON compacto (minificado) probablemente siga siendo más eficiente en tokens.

• Datos tabulares puros: Si solo tienes una tabla plana, un CSV simple sigue siendo el formato más pequeño.

• Interoperabilidad total: Si tu sistema depende al 100% de herramientas que solo entienden JSON, añadir esta capa de conversión puede ser un problema.

Conclusión: ¿Debería usar TOON en mi próximo proyecto?

Mi opinión como desarrollador: TOON es una herramienta de nicho, pero una muy poderosa en ese nicho.

No lo uses para reemplazar JSON en tus APIs o bases de datos.Considera seriamente usarlo si tu aplicación envía listas grandes y uniformes de objetos a un LLM (por ejemplo, resultados de búsqueda semántica con metadatos, logs para análisis, catálogos de e-commerce para un agente).

En esos casos, el beneficio no es solo un 30% menos de coste de API; es una potencial mejora en la precisión y fiabilidad de la respuesta del LLM gracias a las "barandillas" estructurales que ofrece el formato.

Es un estándar emergente (MIT), con SDKs oficiales en TypeScript y Python, así que la barrera de entrada es baja.

¿Mi consejo? Mídelo. Si los tokens son un cuello de botella para ti, haz una prueba A/B. Codifica tus prompts a TOON y comprueba si el ahorro en tokens y la mejora en la fiabilidad merecen la pena.

Puedes encontrar la especificación completa, benchmarks y las librerías en el repositorio oficial de GitHub: https://github.com/toon-format/toon