JSON, JSONL y TOON: qué formato de datos encaja con cada cuello de botella

Durante años, JSON ha sido la forma por defecto de escribir datos estructurados. Las APIs REST, los archivos de configuración, las bases de datos, las apps de navegador y el tráfico entre servicios se apoyan en él. Pero la manera en que el software maneja los datos no deja de cambiar. Los datasets son enormes, los eventos llegan en streams y los grandes modelos de lenguaje ya reciben datos estructurados como entrada.

Por eso han ganado atención otros dos formatos: JSONL y TOON. A primera vista pueden parecer rivales de JSON, pero cada uno responde a una pregunta distinta. JSON está pensado para intercambiar datos estructurados. JSONL, para procesar registros independientes de forma eficiente. TOON, para que los datos con forma de JSON ocupen menos y gasten menos tokens cuando van a un LLM. Preguntar cuál es «mejor» no tiene mucho sentido. Es más útil entender para qué sirve cada uno.

JSON: la base de propósito general

JSON, siglas de JavaScript Object Notation, representa datos con objetos, arrays, cadenas, números, booleanos y null. Su punto fuerte no es la sintaxis, sino el ecosistema que lo rodea: casi todos los lenguajes de programación traen una librería de JSON y las plataformas web lo soportan de forma nativa.

Un dataset típico tiene este aspecto:

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

Esa forma encaja con una app que necesita pasar información estructurada, y por eso JSON va bien para APIs REST, configuración, datos de aplicación y cualquier caso en que la estructura completa tenga un tamaño manejable.

Los problemas empiezan cuando esa misma forma se estira hasta datasets muy grandes, o cuando un LLM tiene que leer miles de objetos parecidos.

JSONL: un registro por línea

JSONL significa JSON Lines. En lugar de meter todos los registros en un gran array, escribe un objeto JSON completo en cada línea. Los mismos usuarios podrían guardarse así:

{"id":1,"name":"Alice","role":"admin"}
{"id":2,"name":"Bob","role":"user"}
{"id":3,"name":"Carol","role":"user"}

Cada línea es un registro independiente. Parece un retoque menor de sintaxis, pero cambia cómo se pueden manejar los datos. Un array JSON grande puede obligar a un programa a parsear toda la estructura antes de tocar un solo registro. Con JSONL, el programa lee una línea, la parsea, la procesa y pasa a la siguiente.

Donde más se nota es en archivos de log, streams de eventos, conjuntos de entrenamiento de ML, trabajos ETL y cualquier otro dato grande o que no para de crecer. Pensemos en un dataset de 50 GB. Cargarlo entero como un objeto gigante casi nunca es lo que quieres. Con JSONL, los registros se pueden tratar de forma incremental y la memoria se va sobre todo en los registros que se están procesando en ese momento.

Así que JSONL responde a un problema de procesamiento de datos.

TOON: menos tokens para el modelo

Ahora imagina otro problema: enviar miles de registros estructurados a un LLM. JSON funciona, pero arrastra mucha puntuación y nombres repetidos:

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

Fíjate en cómo "id", "name" y "role" se repiten en cada objeto. Al software convencional le da bastante igual. Para un LLM, en cambio, todos esos caracteres suman al número de tokens de entrada.

Ese es el hueco que cubre TOON, Token-Oriented Object Notation. Es una codificación compacta y legible del modelo de datos de JSON, pensada sobre todo para prompts y otros contextos donde importa el consumo de tokens. Los mismos registros quedan así:

users[3]{id,name,role}:
  1,Alice,admin
  2,Bob,user
  3,Carol,user

Los nombres de campo se declaran una vez y después los registros aparecen como filas. El principio es sencillo: no repetirle al modelo la misma estructura una y otra vez, sino enunciarla una vez y dar los valores.

La pregunta que plantea cada formato

Una forma de no confundir los tres es fijarse en lo que intenta resolver cada uno.

• JSON se pregunta cómo representar datos estructurados en un formato que soporte todo el mundo.
• JSONL se pregunta cómo representar muchos registros independientes para poder procesarlos por partes.
• TOON se pregunta cómo escribir datos con forma de JSON de manera más compacta cuando se envían a un LLM.

Por eso JSONL y TOON no se sustituyen entre sí. JSONL cambia cómo se organizan los registros. TOON cambia cómo se representan los datos estructurados, en nombre de la eficiencia en tokens. Y JSON sigue por debajo como formato de propósito general en muchos de estos flujos.

Escenario uno: un pipeline de logs con mucho tráfico

Piensa en un gran sistema de procesamiento de logs donde aparecen miles de eventos por segundo:

User logged in
Payment completed
Order created
Email sent

Si esos eventos se guardan como objetos JSON separados, uno por línea, un consumidor puede procesarlos a medida que llegan. Aquí es donde JSONL funciona bien. Encaja con datos grandes, que solo se añaden, que se producen de forma continua o que por naturaleza están hechos de registros, así que logs, streams de eventos, pipelines de ML, sistemas ETL y procesamiento de big data son su terreno habitual.

JSON sigue siendo la opción más natural cuando la estructura completa es un único documento lógico, o cuando las aplicaciones esperan APIs JSON normales.

Escenario dos: un agente que lee 10.000 clientes

Ahora un agente de IA necesita información sobre 10.000 clientes. Si se envía como registros al estilo JSON, cada fila repite sus claves:

{"id":1,"name":"Alice","city":"Delhi"}
{"id":2,"name":"Bob","city":"Mumbai"}
{"id":3,"name":"Carol","city":"Pune"}

TOON puede disponer una colección uniforme como una tabla, con los nombres de campo indicados una sola vez:

customers[3]{id,name,city}:
  1,Alice,Delhi
  2,Bob,Mumbai
  3,Carol,Pune

De ahí sale el ahorro de tokens. Según la especificación, TOON es una codificación basada en sangría, línea a línea, del mismo modelo de datos que usa JSON, y cada array anuncia su longitud y su lista de campos una única vez.

El proyecto también publica benchmarks en los que TOON usó bastantes menos tokens que el JSON formateado en sus datasets de prueba. Aun así, cuánto ahorras depende de la forma de los datos y del tokenizador. TOON no es automáticamente mejor para cualquier dataset. Sus mayores ganancias llegan con arrays uniformes de objetos cuyos campos se repiten.

¿Sustituirá TOON a JSON?

Decirlo es tentador y demasiado simple. La propia especificación presenta TOON sobre todo como una representación para datos con forma de JSON. Dice que TOON no pretende sustituir a JSON en APIs de propósito general, ni en casos con anidación profunda o estructuras no uniformes.

Un flujo realista mantiene JSON donde ya funciona y añade TOON solo en la frontera con el modelo:

Application data
      ↓
    JSON
      ↓
Convert for LLM
      ↓
    TOON
      ↓
     LLM

JSON sigue siendo la representación nativa de la aplicación, y TOON pasa a ser el formato que se usa cuando los datos estructurados entran en un LLM. En ese papel, TOON se parece más a una capa de traducción que a un sustituto universal.

Usarlos juntos

Los formatos también pueden convivir en una misma arquitectura. JSONL se ocupa de cómo se organizan y procesan los registros. TOON, de cómo representar datos estructurados de forma eficiente para un LLM. Una aplicación podría generar un gran stream de registros en JSONL, procesarlos de forma incremental, quedarse con el subconjunto relevante y luego codificar ese subconjunto en TOON antes de enviarlo a un modelo.

Cada formato elimina un cuello de botella distinto. JSONL ayuda con el procesamiento de registros a gran escala, TOON con la eficiencia en tokens y JSON con la interoperabilidad general.

Cómo elegir

Recurre a JSON cuando quieras una forma de propósito general y ampliamente soportada de guardar datos estructurados. APIs públicas, apps de navegador, archivos de configuración y datasets de tamaño modesto son los casos obvios. Pocos formatos igualan sus herramientas, y un dataset pequeño y convencional no da motivos para meter otra cosa.

Plantéate JSONL cuando los datos sean un montón de registros independientes que quieres procesar de forma incremental. Logs, streams de eventos, datos de entrenamiento de ML, pipelines ETL y datasets grandes son buenos ejemplos. La pregunta decisiva es si todo el dataset debe tratarse como una sola estructura o si basta con un registro cada vez. Si es lo segundo, vale la pena mirar JSONL.

Plantéate TOON cuando quien consume los datos sea un LLM y estos contengan muchos registros estructurados repetidos. Encaja con arrays uniformes en los que los mismos campos se repiten en muchos objetos, que es justo lo que su especificación señala como su punto fuerte. Los datos muy anidados o muy irregulares pueden ser más simples o incluso más pequeños en JSON. La pregunta es si se están gastando tokens en describir la misma estructura una y otra vez. Si la respuesta es sí, TOON merece una evaluación.

Presiones distintas, formatos distintos

JSON no va a desaparecer. Lo que ocurre es que distintos problemas de datos están dando lugar a formatos especializados. JSON ganó porque el software necesitaba una forma sencilla e interoperable de describir datos estructurados. JSONL surgió de la necesidad de trabajar con registros independientes, sobre todo cuando los datasets crecieron o empezaron a llegar sin pausa. TOON viene de otra presión: los LLM trabajan con tokens y enviar sintaxis estructural una y otra vez tiene un coste.

Así que el modelo mental correcto no es una cadena que termina con JSON muerto. Es este: JSON para estructura de propósito general, JSONL para procesar registros a gran escala, TOON para entradas de LLM eficientes en tokens. Es poco probable que un único formato sustituya a todos los demás. Lo sensato es elegir la representación que encaje con el cuello de botella que realmente tienes.