Saída estruturada foi uma das melhores coisas que aconteceram com integrações de LLM. Antes, você pedia JSON e rezava; hoje, com schema, o JSON volta válido. O problema é a conclusão que costuma vir junto: “agora a saída do modelo é confiável”.
Ela é analisável. Não é a mesma coisa.
A tarefa
Classificar um item e decidir automaticamente com base em quanto o modelo está seguro. A saída tem um rótulo e um número. O código usa o número para decidir se age sozinho ou manda para uma pessoa.
Note o que essa tarefa exige: não basta o número existir. Ele precisa
significar alguma coisa estável, porque vai virar um if.
O contrato de cada lado
| LLM em modo JSON | Jev (jev-1.13.0) | |
|---|---|---|
| O que garante o formato | O schema, aplicado na decodificação | O tipo da pergunta: as opções são definidas antes |
| O que devolve | Um objeto com os campos que você pediu, incluindo os inventados | Opção, nota ou probabilidade, com a distribuição completa |
| De onde vem a incerteza | De um campo que o modelo escreveu, como escreve qualquer token | De uma estatística sobre a distribuição de probabilidades |
| Contrato sobre esse número | Nenhum declarado | RLCD: a TypeSafe declara treinar para que a probabilidade corresponda à frequência |
| Entrada por milhão de tokens | US$ 0,20 a US$ 10,00, conforme o modelo, nos preços lidos em 18/09/2026 | US$ 0,042 |
| Saída por milhão de tokens | de 5 a 6 vezes a entrada do mesmo modelo | gratuita |
Os preços de OpenAI e Anthropic vêm das páginas oficiais de cada fabricante, lidos em 18 de setembro de 2026. A comparação usa só tokens de entrada, porque é o que o Jev cobra, e por isso é conservadora a favor do LLM. E, como em todas as páginas desta seção: preço não é capacidade, porque esses modelos escrevem texto e o Jev só decide.
Onde o Jev ganha
O número tem um contrato declarado. O primer de IA da TypeSafe publica o
mapeamento esperado de um modelo calibrado: desfechos com probabilidade 0,2
acontecem cerca de 20% das vezes, os de 0,8 cerca de 80%, os de 1,0 em 100%. E
publica junto a ressalva de que essas taxas descrevem grupos de previsões, não
uma resposta individual. Isso é uma promessa falsificável — você pode medir e
brigar com ela. Um campo "confianca": 0.7 escrito por um LLM não promete
nada. O assunto está em
decisões calibradas.
A distribuição inteira vem junto. Não é só o rótulo vencedor: é o peso de cada opção. É isso que permite ver que a resposta “cobrança” ganhou com 0,40 contra 0,35, o que é uma informação completamente diferente de 0,90 contra 0,05. A leitura está em probabilidade não é confiança.
O schema não pode ser satisfeito com invenção. Este é o argumento mais concreto, e ele vem de um experimento oficial. No cookbook de cascata de extração, um modelo pequeno devolveu um registro perfeitamente válido para o JSON Schema com uma descrição que a página fonte nunca disse. O comentário do próprio cookbook é direto: validação de schema é necessária e não suficiente — ela pega erro estrutural, nunca semântico. Com um Choice, a resposta só pode ser uma das opções que existem.
Menos código de defesa. Sem parsing, sem retry por JSON malformado, sem tratamento de recusa, sem campo faltando.
Onde o modo JSON ganha
Ele carrega texto junto. Um objeto pode ter categoria, prioridade e
também resumo e resposta_sugerida. O Jev não devolve texto nenhum, e a
documentação diz que forçar isso encadeando escolhas funciona mal e fica lento.
Ele aceita campos que você não enumerou. Extração de um nome próprio, de um endereço, de um trecho de justificativa: são valores abertos. O caminho equivalente no Jev é achar candidatos antes e transformar a extração em escolha entre eles, como mostra a receita de extrair valores — o que é mais trabalho.
Ele já está instalado. Se o fluxo hoje é uma chamada com schema e o time domina isso, trocar por outro fornecedor custa integração, observabilidade e uma dependência a mais. Um número calibrado que você não vai usar não paga essa conta.
Ele acomoda mudança de forma sem redesenho. Acrescentar um campo ao schema é uma linha. No Jev, cada nova dimensão é uma pergunta nova com critérios escritos — melhor no fim, mais lento no começo.
Estrutura pode ser tudo o que você precisa. Se o número nunca vira limiar e o rótulo só alimenta um relatório, a calibração é uma propriedade que você está pagando e não usando.
Como escolher
O critério é simples e direto: o que o seu código faz com o número?
- Se o número é só exibido ou registrado, modo JSON basta.
- Se o número vira um
ifque decide agir sem pessoa, ele precisa de contrato. Aí é Jev, e o motivo não é preço — é que um limiar sobre um número sem significado estável é uma decisão sem fundamento. - Se a saída tem texto e decisão misturados, separe: o LLM escreve, o Jev decide, e você para de pedir duas naturezas de coisa ao mesmo componente.
- Se você já usa modo JSON e quer melhorar sem trocar tudo, ponha o Jev como verificador em cima do que o LLM produziu. É o desenho de cascata de extração.
O índice desta seção está em comparativos, e o contraste mais amplo entre os dois tipos de modelo está em Jev vs ChatGPT.
Perguntas frequentes
Modo JSON não resolve o problema de formato?
Resolve, e bem. Saída estruturada com schema garante que o JSON é válido e que os campos existem. O que ela não garante é o conteúdo: um registro pode passar no schema e estar semanticamente errado, e o cookbook oficial de cascata mostra exatamente esse caso.
Se eu pedir um campo de confiança ao LLM, não é a mesma coisa?
Não. Esse campo é um token gerado como qualquer outro: o modelo escreve o número que parece plausível. A TypeSafe descreve o próprio treino como RLCD, voltado a devolver probabilidades calibradas, e publica o mapeamento esperado — 0,2 acontecendo cerca de 20% das vezes, 0,8 cerca de 80%. Um número autodeclarado não tem esse contrato.
Como eu sei se a minha confiança do LLM é calibrada?
Medindo. Guarde a probabilidade e o desfecho real, agrupe por faixa e compare a frequência de acerto com a faixa. É o mesmo trabalho nos dois casos; a diferença é que num dos lados existe uma promessa declarada para testar.
Quando modo JSON é suficiente?
Quando a saída precisa incluir texto livre, quando os campos são extraídos e não decididos, quando o volume é baixo, ou quando você não vai usar a incerteza para nada. Se o número nunca vai virar um limiar no código, não faz diferença de onde ele veio.
Dá para usar os dois juntos?
É o desenho da cascata oficial: um modelo barato extrai em modo texto, o Jev verifica campo por campo com perguntas de sim ou não, e só o que dispara um sinal sobe para o modelo caro. O verificador existe justamente para a metade que o schema não cobre.