Jev e a ilusão do JSON mode: por que forçar LLMs como classificadores custa caro · jarbasgouveia

A maioria das pessoas que coloca inteligência artificial em produção já cometeu o mesmo pecado de arquitetura: pegar um modelo gigante treinado para bater papo, mandar um prompt pedindo para ele responder apenas um JSON, e usar esse retorno para alimentar um if no código.

Funciona para validar ideia em uma tarde. Mas quando o volume sobe, a conta chega de duas formas: latência imprevisível e uma fatura salgada de tokens de saída. Para piorar, se você pede para o modelo incluir um campo "confianca": 0.95, você está baseando regras de negócio em um número que não existe no mundo real. Aquele número é apenas texto que o modelo gerou porque achou que soava convincente.

Na outra ponta do espectro, os classificadores clássicos de machine learning (como um modelo no scikit-learn, um fine-tuning de BERT ou poucas amostras via SetFit) são rápidos, rodam locais e dão distribuições de probabilidade reais. O problema deles é a rigidez operacional. Para qualquer classe nova ou mudança no texto que o usuário envia, você precisa de dataset anotado, pipeline de treino e um novo deploy.

No meio desse cabo de guerra entre a flexibilidade do prompt e o custo de um modelo generativo, a TypeSafe AI colocou no ar o Jev, criado por Diogo Almeida (um dos autores originais dos trabalhos de RLHF que deram origem ao InstructGPT e ao ChatGPT na OpenAI).

O modelo traz uma tese simples: para tomar decisões em código, geração de texto é um desperdício.

O problema do JSON mode como classificador

Quando você usa um LLM moderno com saída estruturada (JSON mode ou gramáticas BNF aplicadas no decodificador), o motor garante que a resposta respeite o seu schema. Mas o processo físico continua sendo a previsão autoregressiva de token por token.

Se a sua requisição pede para classificar um texto em três categorias, o pipeline inteiro do modelo passa por etapas desnecessárias:

O decodificador gera os tokens de formatação do JSON chave por chave. Como gerar texto é computacionalmente mais caro que ler, cada token de saída custa entre 4 e 8 vezes mais do que um token de entrada.
A latência é serial: mesmo para devolver uma única palavra, o modelo gasta de 1,5 a 5 segundos no total.
Se você pedir para o modelo devolver um percentual de certeza, aquele valor é mera alucinação estilística.

Modelos alinhados com RLHF (aprendizado por reforço com feedback humano) sofrem de colapso de modos (mode dropping): a distribuição de probabilidade da base é deformada para favorecer o tom que agrada a avaliadores humanos. O modelo aprende a soar confiante mesmo quando está chutando. A probabilidade que ele escreve no JSON não tem correlação matemática confiável com a taxa real de acerto. Como o próprio Diogo Almeida comentou no Hacker News durante o lançamento: aplicar máscaras no decodificador apenas disfarça um modelo que, se tentou prever um token proibido, já estava conceitualmente confuso.

O que é o Jev e o que muda na arquitetura

O Jev é chamado pela TypeSafe de "modelo System One", fazendo referência à divisão de Daniel Kahneman: Sistema 1 para decisões rápidas e intuitivas, e Sistema 2 para raciocínio deliberativo e lento.

A diferença fundamental é que o Jev não possui cabeça de geração de texto livre. Ele recebe um estado (que pode ser uma string, um array ou um objeto JSON) e um conjunto de perguntas tipadas com espaço de respostas fechado.

A chamada na API segue esta estrutura:

curl https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": "Prezado, venho requerer a desistência da habilitação do crédito e a liberação imediata da certidão original de trânsito em julgado.",
    "questions": {
      "desiste_habilitacao": {
        "type": "noul",
        "instructions": "O documento pede expressamente a desistência da habilitação do crédito?"
      },
      "tipo_pedido": {
        "type": "choice",
        "instructions": "Qual é a categoria principal da petição?",
        "criteria": {
          "desistencia": "Pede para sair do processo ou cancelar habilitação",
          "juntada": "Apenas anexa documentos sem novos pedidos",
          "pagamento": "Requer expedição de alvará ou levantamento de valores"
        }
      }
    }
  }'

A resposta não é um texto parseado, mas uma estrutura direta com as probabilidades calculadas:

{
  "answers": {
    "desiste_habilitacao": {
      "type": "noul",
      "noul": 0.96
    },
    "tipo_pedido": {
      "type": "choice",
      "choice": "desistencia",
      "probabilities": {
        "desistencia": 0.94,
        "juntada": 0.04,
        "pagamento": 0.02
      },
      "confidence": 0.91
    }
  },
  "usage": {
    "input_tokens": 142
  },
  "model": "jev-1.13.0"
}

O endpoint trabalha com três primitivas:

Noul: uma pergunta binária (sim ou não) que devolve um único float entre 0 e 1, indicando a probabilidade de a afirmação ser verdadeira.
Choice: escolha de uma opção dentro de uma lista de até 255 alternativas, retornando a opção vencedora, a distribuição completa de probabilidade e um índice de confiança consolidado.
Score: avaliação contínua sobre uma régua de níveis ordenados (por exemplo, de calmo a muito irritado), devolvendo a média ponderada pelas probabilidades de cada nível.

Como o modelo não cospe tokens de texto, a TypeSafe não cobra por tokens de saída: o custo é fixo em US$ 0,042 por milhão de tokens de entrada. Múltiplas perguntas sobre o mesmo texto são processadas em paralelo na mesma passada, sem que uma contamine o contexto da outra.

Calibração real via RLCD

A diferença prática não é só a ausência de texto, mas como o modelo foi treinado.

Em vez de RLHF, a TypeSafe utilizou RLCD (Reinforcement Learning for Calibrated Decisions). O objetivo da função de perda não é gerar uma frase bem escrita, mas calibrar a distribuição estatística da saída contra resultados observados.

Em um modelo calibrado:

Um evento com probabilidade 0,10 deve acontecer em aproximadamente 10% das vezes.
Um evento com probabilidade 0,90 deve acontecer em aproximadamente 90% das vezes.

Na prática, isso muda a forma como o código consome a resposta. Quando um modelo comum diz "confianca": 0.9, você não pode arriscar uma automação cega. No Jev, o número reflete a incerteza real do preditor sobre aquele conjunto de hipóteses.

O que os testes empíricos de 16 mil chamadas revelaram

No papel o marketing fala em "200 vezes mais rápido e 400 vezes mais barato". Essa conta compara o Jev cuspindo probabilidades contra a média de modelos de ponta gerando parágrafos de texto explicativo (como GPT-6 Astra ou Claude Fable 5.1).

O desenvolvedor Aman Kumar rodou uma bateria independente de 16 mil chamadas comparando o Jev contra a classe que realmente compete nessa esteira: modelos pequenos e rápidos, como gpt-5.4-mini e gpt-5.6-luna com reasoning no nível baixo.

Os resultados mostram onde o modelo funciona bem e onde ele quebra:

1. Onde ele ganha com folga (textos curtos e rótulos nítidos)

Em datasets clássicos de classificação com poucas opções e regras claras, o Jev empatou ou superou os modelos generativos pequenos, custando de 5 a 56 vezes menos:

Enron spam (2 opções): 98,7% de acurácia (contra 97,7% do mini e 98,0% do luna).
SST-2 análise de sentimento (2 opções): 95,7% de acurácia (contra 92,7% do mini).
AG News classificação de tópicos (4 opções): 91,3% de acurácia (contra 88,3% do mini).
Latência média: estável em torno de 800 a 900 milissegundos, independente do número de opções. Enquanto isso, os LLMs demoravam de 1,4 a 5 segundos porque precisavam escrever as probabilidades de cada opção na saída.

2. Onde ele quebra (documentos longos, muitas classes e regras difusas)

Quando o problema exige ler um documento inteiro para encontrar uma menção sutil ou quando o conjunto de classes cresce demais, o cenário muda:

Banking77 (77 intenções bancárias): o Jev caiu para 76,0% de acurácia, perdendo para os dois modelos generativos (o mini fez 78,7% e o luna bateu 81,7%).
Detecção de phishing em e-mails longos: em um benchmark com 2.000 mensagens, o Jev marcou 62,6% contra 81,3% do Claude Haiku 4.5. Quando a tarefa foi quebrada em 5 perguntas atômicas sim/não combinadas por regressão logística no código, a acurácia subiu para 95%.
Extração em documentos densos: em tarefas de identificar se uma página contém valores para uma entre 135 linhas de relatório financeiro, o Jev teve apenas 68,6% de concordância com o resultado real. O modelo dispara falso positivo quando a palavra é apenas mencionada no texto, sem conter o valor real.
Processamento de faturas: na própria avaliação pública da TypeSafe, a tarefa de faturas marcou 61,8% contra 79,1% dos LLMs generativos.

3. A regra das pontas

O dado mais valioso do benchmark é o comportamento das probabilidades:

Quando a confiança da resposta foi igual ou superior a 0,90, a precisão geral ficou entre 90% e 99,6% (mesmo no Banking77 com 77 classes, as respostas confiantes acertaram 89,9%).
Quando o modelo diz quase com certeza que não (noul < 0,10), ele praticamente nunca erra o descarte.
No meio do caminho (entre 0,10 e 0,90), o resultado foi errático, variando de 55% a 72% de acerto.

As pontas da distribuição são extremamente seguras; o meio é terreno incerto.

Como eu aplico isso no meu fluxo de trabalho

No Celer e nos serviços que eu toco na Ativos, a nossa esteira lida com processos judiciais pesados, certidões de precatórios, petições e anexos de centenas de páginas.

Se você coloca um agente ou um LLM generativo para inspecionar cada página de um PDF de 500 folhas procurando se é uma certidão de trânsito em julgado, um despacho de homologação de cálculo ou uma página administrativa vazia, a conta de infraestrutura explode e o tempo de processamento vai para minutos.

Por outro lado, criar um modelo supervisionado local para cada tribunal do país exige dados rotulados que a gente nem sempre tem no início. Além disso, há restrições operacionais sérias: processos judiciais envolvem dados sensíveis e segredo de justiça, o que exige cautela antes de enviar autos completos para qualquer API externa.

O desenho que resolve esse problema na prática envolve quatro decisões objetivas de engenharia:

OCR upstream obrigatório: o Jev opera apenas sobre texto. Anexos escaneados, carimbos e certidões antigas precisam passar por OCR local primeiro, e qualquer erro de OCR se propaga para a classificação.
Modelagem em N Nouls atômicos: petições judiciais reais raramente têm um único pedido. Uma petição pode pedir desistência, juntar procuração e requerer alvará ao mesmo tempo. Em vez de usar um choice multiclasse que força uma escolha excludente, é muito mais seguro disparar três perguntas noul em paralelo sobre a mesma página.
Calibração de corte pela regra do metade do menor positivo: em vez de adotar cegamente o limite de 0,05 do marketing, rodamos um lote de validação com 200 a 300 páginas reais. Se o menor score positivo de um documento crítico foi 0,12, fixamos a linha de rejeição em metade disso (0,06). Qualquer página abaixo dessa margem pode ser ignorada com segurança; o que ficar entre 0,06 e 0,90 é roteado para o modelo com raciocínio (Sistema 2) ou para o analista humano.
Bootstrap para modelos locais: usamos o Jev na fase de descoberta para rotular automaticamente milhares de páginas nas pontas de alta confiança (acima de 0,90). Esse dataset pré-classificado alimenta o treino de classificadores locais leves (como SetFit few-shot, que precisa de poucas dezenas de exemplos). Uma vez estabilizada a classe no tribunal, o modelo local assume com custo zero e total aderência à LGPD.

Modelos System One não vieram para aposentar os LLMs de raciocínio. Eles vieram para tirar dos modelos de texto um trabalho que nunca deveria ter sido feito via geração de strings.

Fontes primárias e referências:

Documentação oficial da TypeSafe AI: https://docs.typesafe.ai/introduction
Conceito de System One e treinamento com RLCD: https://docs.typesafe.ai/concepts/system-one
Modelo de preços e limites do Jev: https://docs.typesafe.ai/models
Benchmark de 16 mil chamadas em produção (Aman Kumar): https://amankumar.ai/blogs/jev-measured
Repositório público com dados dos testes: https://github.com/onlyoneaman/jev-eval
Thread de lançamento e respostas de Diogo Almeida no Hacker News: https://news.ycombinator.com/item?id=49717558