Token-Oriented Object Notation vs JSON: A Benchmark of Plain and Constrained Decoding Generation

O estudo compara a Token-Oriented Object Notation (TOON) com o JSON, revelando que, embora a TOON ofereça uma relação promissora entre precisão e consumo de tokens para tarefas complexas, sua vantagem é frequentemente anulada pelo custo do prompt em contextos curtos, enquanto a geração de JSON padrão demonstra maior precisão geral e a decodificação restrita de JSON, apesar de economizar tokens, pode apresentar degradação significativa de desempenho.

O essencial

Imagine que você precisa enviar uma encomenda complexa para um amigo que fala uma língua diferente. Você tem três opções de como escrever a lista de itens:

1. JSON (O Padrão): É como escrever a lista em inglês, usando uma gramática que todo mundo conhece, mas que é um pouco "gorda" (muitas palavras repetidas, chaves, colchetes).
2. JSON-SO (O Guarda-Costas): É como pedir para o seu amigo escrever a lista, mas você coloca uma grade de ferro na frente dele. Ele só pode escrever se seguir regras estritas. Se ele tentar escrever algo errado, a grade bloqueia. Isso evita erros, mas às vezes atrapalha o fluxo natural de pensamento dele.
3. TOON (O Novo Idioma): É uma linguagem nova, super compacta, feita especificamente para ser lida por Inteligências Artificiais (IAs). Ela é muito mais curta e econômica, mas seu amigo nunca a viu antes. Você precisa gastar tempo ensinando a ele como funciona (o "manual de instruções") antes de ele começar a escrever.

O artigo "Token-Oriented Object Notation vs JSON" é como um teste de corrida entre essas três opções para ver qual é a mais rápida, barata e precisa. O autor, Ivan Matveev, colocou várias IAs (os "amigos") para testar.

Aqui está o resumo do que eles descobriram, usando analogias do dia a dia:

1. O Custo do "Manual de Instruções" (A Taxa de Entrada)

O TOON é muito eficiente quando a lista é longa. É como se você estivesse enviando um catálogo inteiro de 100 páginas. Se você usar o TOON, o catálogo fica minúsculo.

• O Problema: Como o TOON é novo, você precisa enviar um "manual de instruções" gigante junto com o pedido para a IA aprender a usá-lo.
• A Lição: Se o pedido for pequeno (uma lista de compras simples), o manual de instruções é maior do que a própria lista! Nesse caso, o TOON acaba gastando mais energia (tokens) do que o JSON comum. O TOON só vale a pena se a "carga" for grande o suficiente para justificar o peso do manual.

2. O Guarda-Costas (JSON-SO) vs. O Fluxo Natural

O JSON-SO (com restrição) funciona como um guarda-costas que impede a IA de cometer erros de digitação.

• Para IAs "novatas" (modelos menores): O guarda-costas é um herói! Ele impede que a IA se perca e gaste uma fortuna tentando corrigir erros.
• Para IAs "gênios" (modelos grandes): O guarda-costas às vezes atrapalha. Ele força a IA a pensar de um jeito rígido, o que faz ela começar a errar mais no início, mesmo que depois ela se recupere. Às vezes, deixar a IA escrever livremente (JSON normal) é mais rápido e preciso para os gênios.

3. O "Efeito Espelho" (Dados Alinhados vs. Caóticos)

O TOON brilha quando os dados são organizados, como uma planilha de Excel ou uma lista de compras (chamados de dados "alinhados").

• Cenário Alinhado: Se você pede uma lista de usuários ou pedidos de loja, o TOON é incrível. É rápido, curto e preciso.
• Cenário Caótico: Se você pede algo complexo, com camadas dentro de camadas (como uma árvore genealógica profunda ou um organograma de empresa), o TOON se perde. Ele não foi feito para isso. Nesse caso, o JSON tradicional ou o JSON-SO são muito melhores.

4. O Custo do Erro (A Taxa de Reparo)

Se a IA errar na primeira tentativa, você precisa pedir para ela corrigir.

• No JSON, se ela errar, você pede a correção e o custo é baixo.
• No TOON, como o "manual de instruções" é grande, quando você pede a correção, você tem que enviar o manual + o erro + a correção de novo. Isso faz o custo explodir. O TOON é barato se acertar de primeira, mas muito caro se errar.

Conclusão: Qual escolher?

• Use JSON Normal (Padrão): Para a maioria das coisas. É confiável, não precisa de manuais e funciona bem para IAs inteligentes.
• Use JSON-SO (Guarda-Costas): Se você está usando uma IA mais simples ou precisa garantir que o formato nunca quebre, mesmo que seja um pouco mais lento.
• Use TOON (O Novo Idioma): Apenas se você estiver enviando muitos dados organizados (como milhares de linhas de banco de dados ou faturas). Se o seu projeto for grande e repetitivo, o TOON pode economizar muito dinheiro e tempo a longo prazo. Mas, se for algo pequeno ou muito complexo, fique longe dele por enquanto.

Em resumo: O TOON é como um carro de Fórmula 1. É super rápido e econômico em uma pista reta e longa (dados grandes e simples), mas é difícil de pilotar, exige muito preparo e não serve para andar em ruas de terra cheias de curvas (dados complexos e pequenos). O JSON é o carro popular: não é o mais rápido, mas leva você a qualquer lugar sem dor de cabeça.

Resumo técnico

Resumo Técnico: Token-Oriented Object Notation (TOON) vs. JSON

1. Problema e Contexto

O formato JSON é o padrão de facto para serialização de dados estruturados para Grandes Modelos de Linguagem (LLMs). No entanto, o JSON é conhecido por ser "verborrágico" em termos de tokens (uso excessivo de chaves, aspas e vírgulas), o que aumenta custos e latência.
O TOON (Token-Oriented Object Notation) foi proposto como uma alternativa otimizada para reduzir significativamente o consumo de tokens ao passar dados estruturados para LLMs. Embora o TOON tenha demonstrado boa compreensão por parte dos modelos, faltava uma avaliação rigorosa sobre sua geração (produção de saída) em comparação com o JSON padrão e com técnicas de decodificação restrita (Structured Output). O desafio central é determinar se a economia de tokens na saída compensa o "imposto de prompt" (overhead instrucional) necessário para ensinar o formato TOON ao modelo, especialmente em cenários de one-shot (uma única tentativa).

2. Metodologia

Os autores realizaram um benchmark comparativo abrangente envolvendo 21 modelos de LLMs (incluindo séries Llama, Qwen, DeepSeek, Hermes e Gemma) através da API da Nebius.

• Formatos Testados:

  1. JSON (J): Geração de JSON puro (sem restrições).
  2. JSON-SO (JSO): JSON com Structured Output (decodificação restrita/constrained decoding), onde o motor de inferência força a geração de tokens válidos via máquinas de estado (ex: xgrammar).
  3. TOON (T): Geração no formato TOON usando one-shot in-context learning (um exemplo de referência no prompt).

• Casos de Teste (Complexidade Estrutural):

  • Alinhados ao TOON: Estruturas tabulares e objetos aninhados com arrays uniformes (users, order, invoice).
  • Não Alinhados: Estruturas com aninhamento profundo e recursivo (company).

• Métricas Principais:

  • Acurácia One-Shot: Porcentagem de saídas corretas na primeira tentativa.
  • Acurácia Final: Porcentagem de sucesso após ciclos de reparo (até 3 tentativas).
  • Orçamento de Tokens: Total de tokens (prompt + conclusão) consumidos para obter um resultado correto.

• Processo de Avaliação:
  As saídas foram validadas via Pydantic. Se a validação falhasse, um ciclo de reparo inseria o erro no prompt para tentar novamente. Todos os testes foram executados com temperatura 0 para garantir determinismo.

3. Contribuições e Descobertas Chave

A. O "Imposto de Prompt" vs. Eficiência de Sintaxe

• O TOON exige um prompt instrucional pesado para definir a sintaxe, o que cria um custo fixo inicial.
• Em contextos curtos ou estruturas simples, esse overhead faz com que o TOON consuma mais tokens do que o JSON padrão, anulando sua vantagem de compressão.
• A eficiência real do TOON só aparece quando o volume de dados gerados é grande o suficiente para amortizar o custo do prompt.

B. Desempenho por Tipo de Estrutura

• Cenários Alinhados (Tabulares/Transacionais): O TOON mostrou-se competitivo. Em dados tabulares simples (users), o TOON alcançou 90,5% de acurácia one-shot usando 22% menos tokens que o JSON.
• Cenários Não Alinhados (Hierarquias Profundas): O desempenho do TOON colapsou. No caso company (aninhamento profundo), a acurácia one-shot foi de 0%. Embora os ciclos de reparo tenham recuperado a acurácia final (48,6%), o custo de tokens devido às repetições tornou o processo ineficiente comparado ao JSON.

C. O Papel da Decodificação Restrita (JSON-SO)

• Para Modelos Pequenos: A decodificação restrita atuou como uma "rede de segurança". O modelo Qwen2.5-Coder-7B falhou completamente (0% de acurácia) gerando JSON puro, mas atingiu 75% de acurácia com decodificação restrita, consumindo drasticamente menos tokens.
• Para Modelos Grandes: Para modelos de raciocínio avançado (ex: Hermes-4-405B), as restrições estritas degradaram a acurácia inicial (queda de 92,5% para 35,0%), forçando o modelo a caminhos de tokens subótimos, embora a recuperação final tenha sido rápida.
• Vencedor em Dados Simples: Para dados tabulares simples, o JSON-SO foi o mais eficiente em tokens (556 tokens vs. 840 do TOON), superando até mesmo o TOON.

D. Hipótese de Escala
Os resultados sugerem uma curva não linear: o TOON só se torna vantajoso em grandes conjuntos de dados onde a economia cumulativa de sintaxe supera o overhead inicial. No entanto, isso introduz riscos de "deriva de indentação" (indentation drift) em janelas de contexto muito longas.

4. Resultados Quantitativos Relevantes

• Acurácia Final (Média Geral): O JSON puro manteve a melhor acurácia geral, seguido pelo JSON-SO e, por último, o TOON (que teve desempenho variável dependendo da estrutura).
• Custo de Tokens:
  • Em casos simples (users): JSON-SO (556) < TOON (840) < JSON (1078).
  • Em casos complexos (company): TOON (2567) foi ligeiramente mais eficiente em tokens totais que JSON (3575) após reparos, mas com risco de falha inicial alta.
• Falhas Críticas: O TOON falhou completamente na primeira tentativa em estruturas não alinhadas (0% de acurácia), exigindo múltiplos ciclos de reparo que aumentaram o custo.

5. Significado e Recomendações

O estudo conclui que o TOON não é uma substituição universal para o JSON, mas sim uma ferramenta especializada:

1. Uso Recomendado (Domínio Alinhado): O TOON é viável para fluxos de dados de alto volume e custo sensível, como:

   • Dumps de resultados SQL (linhas tabulares uniformes).
   • Documentos transacionais padrão (Pedidos, Faturas).
   • Logs e trilhas de auditoria.
   • Condição: O esquema deve ser plano ou aninhado uniformemente, e o prompt deve ser otimizado para a tarefa específica.

2. Uso Desencorajado (Domínio Não Alinhado): O TOON não é pronto para produção em:

   • Árvores de estado complexas.
   • Estruturas tipo DOM.
   • Configurações profundamente aninhadas.
   • Nestes casos, o JSON padrão ou JSON-SO (para modelos menores) são superiores em confiabilidade e eficiência.

3. Estratégia de Produção: Para pipelines ETL ou processamento em lote com dados tabulares massivos, o TOON pode reduzir significativamente a latência e o custo de tokens, desde que a estrutura de dados permaneça dentro do "domínio alinhado".

Conclusão Final:
Enquanto o TOON promete economia de tokens, a realidade prática revela que o overhead de instrução e a fragilidade em estruturas complexas limitam sua adoção imediata. A decodificação restrita (JSON-SO) mostrou-se, paradoxalmente, mais eficiente em tokens para tarefas simples do que o próprio formato otimizado TOON, sugerindo que a otimização de sintaxe (TOON) deve ser complementada por otimização de inferência (decodificação restrita) para obter os melhores resultados.