Um novo JSON focado na LLM?

Se, para o desenvolvimento web, tivemos o JSON como formato universal, será que para o desenvolvimento de aplicações de IA e LLMs precisaremos de um novo formato — aqui proposto como "TOON" — pensado especificamente para as necessidades de modelos, orquestração de ferramentas, multimodalidade e governança?

Abaixo proponho uma versão melhorada e completa do seu artigo: por que considerar um novo formato, que problemas ele resolve, um comparativo prático com JSON e um exemplo de especificação mínima para começar a discutir um padrão.

Por que repensar o formato de dados para IA/LLM?

JSON é simples, legível e amplamente adotado. Porém, aplicações modernas baseadas em LLMs trazem requisitos novos ou mais complexos:

• prompt templates, instruções contextuais e histórico conversacional estruturado;

• invocação segura e tipada de ferramentas externas (APIs, executores, agentes);

• multimodalidade (imagens, áudio, vídeo) e referências a grandes blobs;

• streaming/partial delivery de respostas e tokens;

• metadados de proveniência, crédito e auditoria (quem perguntou, quando, qual versão do modelo);

• políticas de segurança e privacidade embutidas;

• necessidade de validação e contratos (schema) entre orquestradores e modelos.

TOON é uma proposta de formato (hipotético) que busca responder a essas necessidades preservando legibilidade e interoperabilidade.

O que TOON deveria trazer (resumo)

• Estrutura de prompt/response explícita (templates, variáveis, slots multimodais).

• Spec para invocação de ferramentas (schema de entrada/saída, permissões).

• Metadados de execução: modelo, parâmetros, versões, custo estimado.

• Streaming e checkpoints (partial tokens, eventos).

• Referência a conteúdo grande por URI + cheksum; suporte a blobs binários.

• Assinatura/prova e políticas de privacidade vinculadas ao objeto.

• Extensibilidade e retrocompatibilidade (pode ser um superconjunto/convencionamento sobre JSON).

Comparativo prático: JSON vs TOON (proposta)

Exemplo mínimo (proposta de "TOON" — formato JSON-like)

{
  "toon_version": "0.1.0",
  "id": "req-2026-04-19-1234",
  "meta": {
    "created_at": "2026-04-19T12:34:56Z",
    "author": "app.example.com",
    "model": {
      "name": "gpt-xyz",
      "version": "2026-04",
      "params": {"max_tokens": 1024, "temperature": 0.2}
    },
    "provenance": {
      "signed_by": "did:example:alice",
      "signature": "MEUCIQDx..."
    }
  },
  "prompt": {
    "template": "Resuma o texto em 3 bullets. Se houver termo técnico, acrescente definição curta.",
    "slots": {
      "document": {
        "type": "text/markdown",
        "source": {"uri": "ipfs://Qm...", "checksum": "sha256:..."},
        "inline": null
      }
    },
    "language": "pt-BR"
  },
  "tools": [
    {
      "name": "web_search",
      "allowed": true,
      "schema": {
        "input": {"q": "string", "limit": "int"},
        "output": {"results": "array"}
      }
    }
  ],
  "stream": {
    "enabled": true,
    "checkpoint_every": 128
  },
  "privacy": {
    "consent": "user:consented",
    "retention_days": 30,
    "redact": ["ssn", "email"]
  }
}

Notas sobre o exemplo:

• Mantém sintaxe JSON (para compatibilidade), mas define campos padrão e estruturas que facilitam validação e orquestração.

• Pode ser serializado em CBOR/MsgPack para eficiência quando necessário.

• Assinaturas e cheksums garantem integridade e auditoria.

Considerações de design e adoção

• Compatibilidade: idealmente TOON seria um conjunto de convenções/uma camada sobre JSON (ou uma especificação que tem um serializador JSON), evitando fragmentação.

• Ferramentas: para adoção, é crucial oferecer bibliotecas (validadores, conversores, linters), adaptadores para frameworks e integração com plataformas de modelos.

• Governança: uma especificação aberta (W3C-like / IETF-like) e registro de extensões ajudam interoperabilidade e segurança.

• Privacidade e compliance: o formato deve facilitar políticas de retenção, consentimentos e mecanismos de anonimização/redaction.

• Performance: oferecer opções de serialização binária (CBOR) e streaming chunked para grandes outputs.

• Segurança: assinatura, verificação de origem e controle de execução de ferramentas embutidas para mitigar comportamento arbitrário.

Riscos e limites

• Sobrecarga de complexidade: criar um formato muito complexo pode prejudicar a adoção; foco em um núcleo minimalista é preferível.

• Fragmentação: múltiplos "TOONs" incompatíveis minariam o objetivo — padronização e governança são essenciais.

• Evolução rápida do ecossistema: a especificação precisa suportar extensões e evolução sem quebrar compatibilidade.

Conclusão

Não é obrigatório criar um "novo JSON": muitas necessidades podem ser cobertas por convenções, schemas e boas práticas sobre JSON, ou por serializações eficientes como CBOR com um perfil padronizado. Porém, dado o volume de requisitos específicos de aplicações LLM (prompt templates, orquestração de ferramentas, multimodalidade, governança e streaming), vale a pena discutir e projetar um padrão — seja um conjunto de conventions (TOON como convenção) ou uma especificação formal — que torne mais fácil construir aplicações seguras, auditáveis e interoperáveis.

Referências

1. SCHICK, T. et al. Toolformer: Language Models Can Teach Themselves to Use Tools. 2023. Disponível em: https://arxiv.org/abs/2302.04761. Acesso em: 19 abr. 2026.

2. YAO, S. et al. ReAct: Synergizing Reasoning and Acting in Language Models. 2022. Disponível em: https://arxiv.org/abs/2210.03629. Acesso em: 19 abr. 2026.

3. UKE, Martin. The anatomy of tool-calling in LLMs: a deep dive. 07 jan. 2026. Disponível em: https://martinuke0.github.io/posts/2026-01-07-the-anatomy-of-tool-calling-in-llms-a-deep-dive/. Acesso em: 19 abr. 2026.

4. OPENAI. Function / Tool calling. Disponível em: https://developers.openai.com/docs/guides/function-calling. Acesso em: 19 abr. 2026.

5. PROMPTLAYER. Prompt registry / Tool-calling. Disponível em: https://docs.promptlayer.com/features/prompt-registry/tool-calling. Acesso em: 19 abr. 2026.

6. JSON. The JavaScript Object Notation. Disponível em: https://www.json.org/json-en.html. Acesso em: 19 abr. 2026.

7. JSON-SCHEMA. JSON Schema. Disponível em: https://json-schema.org/. Acesso em: 19 abr. 2026.

8. JSON-LD. JSON-LD. Disponível em: https://json-ld.org/. Acesso em: 19 abr. 2026.

9. OPENAPI INITIATIVE. OpenAPI. Disponível em: https://www.openapis.org/. Acesso em: 19 abr. 2026.

10. ASYNCAPI. AsyncAPI. Disponível em: https://www.asyncapi.com/. Acesso em: 19 abr. 2026.

11. W3C. PROV — Primer. Disponível em: https://www.w3.org/TR/prov-primer/. Acesso em: 19 abr. 2026.

12. W3C. Verifiable Credentials Data Model. Disponível em: https://www.w3.org/TR/vc-data-model/. Acesso em: 19 abr. 2026.

13. W3C. Decentralized Identifiers (DIDs) Core. Disponível em: https://www.w3.org/TR/did-core/. Acesso em: 19 abr. 2026.

14. MOZILLA DEVELOPER NETWORK. Server-sent events (SSE). Disponível em: https://developer.mozilla.org/en-US/docs/Web/API/Server-sent\_events. Acesso em: 19 abr. 2026.

15. MOZILLA DEVELOPER NETWORK. WebSockets API. Disponível em: https://developer.mozilla.org/en-US/docs/Web/API/WebSockets\_API. Acesso em: 19 abr. 2026.

16. gRPC. gRPC — A high performance, open-source universal RPC framework. Disponível em: https://grpc.io/. Acesso em: 19 abr. 2026.