A busca atual por inferência ultraeficiente, compressão de tokens e esquemas de codificação engenhosos nos leva a perseguir desempenho e redução de custos como se a disponibilidade fosse acompanhar tudo isso naturalmente. Mas não vai. A disponibilidade não se importa com o quão engenhosa sua codificação parece em um slide de benchmark.
Recentemente, a tendência de eficiência de tokens agitou as redes sociais com o entusiasmo em torno do Token-Oriented Object Notation (TOON), um formato criado para reduzir o número de tokens usados em inferência, já que a cobrança é baseada em tokens. Então começaram as paródias, que foram tratadas como inovações sérias e se espalharam como “a morte do JSON”, provando mais uma vez que o sarcasmo não funciona bem em textos e que o entusiasmo exagerado sempre se antecipa às nuances.
A verdadeira questão aqui não é uma guerra de formatos. É o mesmo desafio operacional com o qual lidamos há décadas: equilibrar desempenho, disponibilidade e confiabilidade com os custos. Os custos diretos são medidos em recursos computacionais e de rede. Os custos indiretos se manifestam na confiança dos usuários, nos danos à marca, na carga de trabalho dos operadores e na perda de clientes. Quem já fez o planejamento de capacidade para um feriado prolongado sabe que esse desafio de equilíbrio não é novidade.
No entanto, com a inferência de IA, a disponibilidade agora inclui a correção. Um sistema que fornece respostas rapidamente, mas de forma imprecisa, não está “disponível”; está funcionando incorretamente. Basta perguntar a qualquer operador que já tenha revertido uma alteração às 3 da manhã, segurando um café morno e repensando suas escolhas profissionais.
Uma solução única não serve para todos
É por isso que o TOON merece uma perspectiva realista, e não romantizada, assim como qualquer técnica de compressão. Alguns talvez se lembrem de que, embora a compressão HTTP funcionasse muito bem com conteúdo baseado em texto, ela não fazia diferença para imagens como JPG, que já eram compactadas por padrão. Hoje, a distinção continua a mesma: dados estruturados não são instruções.
O TOON foi projetado para otimizar dados estruturados e alega proporcionar uma grande economia de tokens, com uma precisão de recuperação ligeiramente maior. Para alguns, isso pode ser útil. Mas a estrutura não é tudo. Sistemas de inferência e orientados por agentes não se limitam a registros de bancos de dados e respostas de APIs. Eles lidam com instruções, intenções e linhas de raciocínio. Economizar tokens em dados não é o mesmo que melhorar as decisões.
Considere uma instrução simples em JSON para um agente:
{
"action": "create_ticket",
"priority": "high",
"summary": "User cannot access their account",
"user_id": 84713
}
No TOON, isso é compactado para:
action: create_ticket
priority: high
summary: O usuário não consegue acessar a própria conta
user_id: 84713
Bom e compacto. Infelizmente, é aí que os benefícios terminam. O agente ainda precisa interpretar o que a ação significa no contexto. “Criar chamado” exige confirmação, localização, atribuição, categorização, encaminhamento ou correlação? O TOON economiza espaço, mas não torna o raciocínio mais claro.
Um artigo de 2025 no arXiv (2510.14453) propõe uma abordagem diferente: a saída de ferramentas em linguagem natural. Os resultados mostraram uma melhoria de mais de 18% na precisão, com uma redução de mais de 30% no número de tokens. Por quê? Porque os modelos são treinados principalmente com linguagem natural, e não com minilinguagens de dados personalizadas.
Seguindo a abordagem deles, enviamos:
Crie um chamado de suporte de alta prioridade para o usuário 84713. O problema é: o usuário não consegue acessar a própria conta.
Menos tokens do que JSON, mais clareza do que TOON e alinhado à forma como os modelos já pensam. Não se trata de escrita criativa livre. É uma instrução delimitada por um modelo e formulada em linguagem natural. Isso traz o benefício adicional de usar menos tokens e facilitar a detecção de manipulações, ou seja, oferece benefícios de segurança não intencionais.
A lição é simples: nem todas as entradas são iguais, e um único formato não atende a todos os casos de uso. Formatos de compactação como o TOON podem se destacar na transmissão de grandes conjuntos de dados estruturados. Já os modelos em linguagem natural podem ser mais eficazes ao fornecer instruções a modelos de raciocínio. Fingir que uma única solução serve para tudo é a receita para causar indisponibilidades.
A contagem de tokens é importante, mas não é uma métrica principal de sucesso
A contagem de tokens não é uma métrica principal de sucesso para a IA. Ela é uma das variáveis de uma equação que envolve diversos fatores, incluindo desempenho, confiabilidade e disponibilidade. Cada vez mais, também precisamos considerar o custo. É possível otimizar uma dessas variáveis sem melhorar o sistema como um todo e, às vezes, até piorá-lo. A história está repleta de engenheiros que perseguiram a métrica mais visível em vez do resultado mais importante.
A entrega de inferência deve equilibrar os pilares operacionais e comerciais:
- Desempenho: a rapidez com que o sistema responde
- Disponibilidade: se o sistema responde corretamente
- Confiabilidade: se responde de forma consistente
- Custo: se a empresa consegue sustentá-lo em escala
Reduza o número de tokens, mas não a clareza. Aumente a velocidade, mas não em detrimento do raciocínio. Otimize os custos, mas não os transfira para novas tentativas, escalonamentos ou revisões manuais.
O setor quase certamente acabará adotando vários formatos, usados conforme a situação. TOON para dados estruturados. Modelos em linguagem natural para instruções. JSON para compatibilidade. E, provavelmente, outros para cargas de trabalho especializadas.
Ainda estamos nos estágios iniciais, e quem afirma ter alcançado a vitória definitiva está em busca de atenção, não de soluções de engenharia. O objetivo não é escolher o formato mais compacto ou mais recente. O objetivo é escolher aquele que oferece resultados confiáveis.
Se a economia reduzir a confiabilidade, você não estará melhorando o sistema; estará apenas transferindo a falha para uma etapa posterior.
Sobre o autor
Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.
Mais publicações de Lori Mac VittiePublicações relacionadas no blog
Por que o roteamento de modelos pode se tornar uma infraestrutura de segurança
A IA agêntica expõe os limites da identidade. Modelos especializados, combinados com roteamento baseado em políticas, vinculam a autoridade à escolha do modelo, reduzindo o raio de impacto e a complexidade da governança.
Top 10 em entrega de aplicações de IA: incapacidade de lidar com a latência
A IA transforma a latência em um problema de confiança, não apenas de desempenho: respostas lentas do “assistente” parecem hesitação ou falha, e prompts e respostas com muitos tokens aumentam a carga de trabalho mesmo em sistemas funcionando normalmente.
As 10 principais ameaças à entrega de aplicações de IA: observabilidade incompleta
A IA não escala sozinha. Sem um plano de controle unificado que elimine as barreiras entre ferramentas e responsabilidades, a inferência se torna a camada mais frágil e que mais exige coordenação.
Habilidades de agentes: um padrão aberto emergente
As skills declaram intenção, mas não impõem controle. A segurança de verdade deve estar nos limites das ferramentas, onde os pensamentos dos agentes se transformam em ações e as políticas podem ser aplicadas.
De pacotes a prompts: a inferência adiciona uma nova camada à pilha
Inferência não é treinamento. Não é experimentação. Não é um exercício de ciência de dados. Inferência é um comportamento de execução em produção e funciona como uma camada de aplicação.
A influência da inferência: APIs, DPUs e o caos do contexto
A inferência de IA está remodelando a infraestrutura, multiplicando APIs, sobrecarregando a capacidade computacional e tornando o contexto mais complexo. Saiba por que uma arquitetura mais inteligente e políticas de execução são essenciais.