Jev ou saída estruturada de um LLM: qual escolher para classificar e rotear?

Fala aí, beleza? Classificar e rotear com IA virou tarefa de rotina: chega um ticket, um email, um evento de webhook, e alguém precisa dizer "isso vai pro time A ou pro time B"

O jeito padrão é pedir JSON pro LLM generalista que você já usa

Funciona. Só que você recebe um rótulo seco, sem saber o quanto o modelo confia naquilo

E aí a sua aplicação toma decisão de produção em cima de um "categoria": "financeiro" que pode ter vindo de uma escolha tranquila ou de um empate técnico feio

O Jev, da TypeSafe AI, nasceu exatamente nesse recorte: ele não escreve texto, ele responde pergunta tipada e já entrega a probabilidade junto

Bora comparar os dois caminhos de verdade?

O que é o Jev e o que ele faz de diferente

O Jev é o primeiro modelo da classe que a TypeSafe chama de System One, anunciado em early access

A ideia do nome é aquela separação clássica entre pensamento rápido e pensamento lento: System One é a decisão imediata, o julgamento de reflexo, não o raciocínio longo

E o desenho do modelo segue isso à risca

O Jev abre mão de geração de string. Ele é otimizado para saída estruturada e não consegue alucinar um valor fora do schema

Parada rápida pra explicar o peso disso: num LLM comum, o schema é uma restrição aplicada por cima de um gerador de texto. No Jev, não existe o caminho pelo qual um valor fora do conjunto poderia sair

Outra diferença mecânica: ele emite todas as probabilidades em paralelo, em vez de gerar token a token de forma autorregressiva

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Se você conhece a diferença entre um modelo de linguagem cuspindo palavra por palavra e um classificador que solta a distribuição de uma vez só, é bem por aí

O método de treino tem nome próprio no anúncio da TypeSafe: RLCD, de Reinforcement Learning for Calibrated Decisions. Arquitetura nova, sampler paralelo e esse treino

A empresa descreve o resultado como inteligência similar à de LLMs existentes em tarefas System One, sendo duas ordens de grandeza mais rápido e mais eficiente

De contexto: segundo a reportagem do SiliconANGLE sobre a saída do stealth, a TypeSafe AI levantou US$ 40 milhões em rodada seed liderada pela DCVC, e foi fundada por Diogo Almeida (ex-pesquisador da OpenAI) com os cofundadores Erik Gafni e Sasha Sheng

Não é isso que decide nada tecnicamente, mas ajuda a entender que o bicho não é um side project de fim de semana =)

Como funciona a saída estruturada de um LLM generalista

O outro lado do ringue você provavelmente já usa

Na API da OpenAI, você manda um response_format do tipo json_schema com strict: true, e a saída do modelo é forçada a corresponder ao schema fornecido

E isso não é detalhe pequeno: nos testes de aderência a JSON schema complexo, o gpt-4o-2024-08-06 com Structured Outputs marca 100%, enquanto o gpt-4-0613 fica abaixo de 40%

Ou seja: o problema de "o modelo devolveu um JSON quebrado e meu parse explodiu" já foi resolvido no lado generalista, e vale a pena entender bem como exigir JSON com schema antes de sair trocando de modelo

Só que formato garantido não é a mesma coisa que confiança da resposta

O schema te garante que vai chegar uma das três categorias que você listou. Ele não te diz se o modelo escolheu aquela categoria com folga ou no cara ou coroa

Pra tirar esse sinal do LLM, você desce pro nível de token: existe a structured-logprobs, biblioteca open source em Python mantida pela arena-ai, que anexa log probabilities por token às saídas estruturadas da OpenAI justamente pra avaliar confiabilidade

Funciona, é código honesto. Mas repara no que aconteceu com a sua arquitetura: você agora tem modelo + schema + validação + uma camada extra pra reconstruir confiança a partir de tokens

Jev x saída estruturada de LLM: comparação ponto a ponto

A última linha é a que mais gente esquece na hora de comparar

O Jev não é um LLM "melhor": ele é outra ferramenta, que faz um pedaço só do trabalho e não tenta fazer o resto

Como fica o código em cada caminho

São três passos de cada lado, e a natureza deles muda bastante de um caminho pro outro

1. Lado Jev: instalar o SDK

# Python (exige Python 3.10 ou superior)
pip install typesafe-sdk

# JavaScript / TypeScript
npm install @typesafe-ai/sdk

O erro comum deste passo: rodar num Python 3.9 que sobrou de outro projeto e tomar erro de instalação. Confere a versão do ambiente virtual antes, não a do sistema

2. Lado Jev: configurar a chave

export TYPESAFE_API_KEY="sua-chave-aqui"

Pelo quickstart da TypeSafe, o cliente do SDK lê a chave direto dessa variável de ambiente e usa jev-latest como modelo padrão

O erro comum deste passo: exportar a variável num terminal e rodar a aplicação em outro. Clássico, e você jura que a chave está errada

3. Lado Jev: montar a requisição

O endpoint da API System One é POST https://api.typesafe.ai/v1/systemone, com header Authorization: Bearer <API_KEY> e Content-Type: application/json

O corpo tem dois campos: state, que é o conteúdo a ser avaliado (string ou dado estruturado), e questions, um mapa com as perguntas tipadas nomeadas por você

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "state": "Cliente pedindo reembolso da cobranca duplicada de setembro",
    "questions": {
      "rota": { ... pergunta do tipo Choice com as suas opcoes ... },
      "urgencia": { ... pergunta do tipo Score ... }
    }
  }'

O erro comum deste passo: tratar questions como prompt. Não é prompt, é um mapa de perguntas tipadas com nome definido por você, e é por esse nome que você lê a resposta depois

4. Lado LLM: definir o schema

{
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "strict": true,
      "schema": { "...": "seu schema de roteamento aqui" }
    }
  }
}

O erro comum deste passo: esquecer o strict: true e achar que declarar o schema já basta. Sem ele você volta pro mundo do "quase sempre funciona"

5. Lado LLM: validar e tratar retry

Mesmo com formato garantido, o valor pode ser semanticamente errado, e é aí que entra a sua camada de validação e de nova tentativa

O erro comum deste passo: retry infinito silencioso. Se o modelo insiste numa categoria que não faz sentido pro seu domínio, o retry só queima token e latência, não conserta julgamento

6. Lado LLM: reconstruir a confiança

Se você quiser saber o quanto o modelo confiou, ainda falta plugar logprobs por token e transformar isso num número que a sua aplicação entenda

O erro comum deste passo: usar a média de logprob da resposta inteira como se fosse confiança da decisão. A string tem tokens de estrutura no meio, e eles diluem o sinal do que interessa

Perceba o desenho: no lado Jev, confiança é campo de resposta. No lado LLM, confiança é projeto

Choice, Score e Noul: qual primitiva resolve cada tipo de roteamento

A API System One tem três tipos de pergunta, e cada uma resolve um formato de decisão diferente

Choice: escolher uma opção de um conjunto

É o roteador puro. Você define o conjunto de opções e a pergunta seleciona uma

A resposta traz a opção escolhida, a probabilidade de cada opção e a confiança

Uma pergunta Choice aceita até 255 opções, então dá pra endereçar coisa grande: fila de suporte, categoria de produto, time responsável, tipo de intenção

Score: avaliar contra níveis ordenados

Quando a decisão não é "qual", é "quanto"

O Score avalia o state contra níveis ordenados e descritivos, e a resposta traz o score, a probabilidade de cada nível e a confiança

Severidade de incidente, prioridade de ticket, qualidade de um conteúdo, tudo isso mora aqui

Noul: sim ou não com valor de 0 a 1

A primitiva Noul avalia uma única pergunta ou afirmação sim/não e retorna um valor de 0 (não) a 1 (sim)

É o flag: "isso é spam?", "isso contém dado sensível?", "isso precisa de aprovação?"

O pulo do gato: tudo numa chamada só

Uma única requisição pode combinar as três primitivas

O Jev ingere o state uma vez e avalia todas as perguntas em paralelo contra ele

Isso muda a arquitetura de um roteador multi-critério de um jeito bem concreto: em vez de três chamadas encadeadas (classifica, depois pontua, depois checa o flag), você manda o conteúdo uma vez e recebe o pacote de decisões junto

Menos orquestração, menos estado intermediário pra guardar, menos lugar pra dar ruim

Usar a confiança para escalar casos duvidosos

Respostas de Choice e Score trazem a propriedade probabilities, que é a distribuição, e a propriedade confidence, um número de 0 a 1 que resume essa distribuição

E aqui vem a parte bonita pra quem escreve código de produção: escalar um caso incerto pra humano ou pra um modelo de raciocínio é lógica da aplicação sobre a probabilidade que já voltou

Sem nova pergunta, sem segunda chamada de API

O fluxo fica com aquela cara de roteador de verdade: confiança alta segue direto, confiança baixa cai na fila de revisão ou vai pro modelo caro que pensa mais

Agora o aviso, e esse é da própria documentação da TypeSafe, não meu: o corte de confiança é política da aplicação, não garantia calibrada

Ou seja, não existe um 0.8 mágico que serve pra todo mundo

A recomendação é escolher o limiar com exemplos rotulados e com o custo de errar e o custo de revisar na mesa. Um roteamento errado que só atrasa um email é uma coisa, um roteamento errado que aprova um reembolso é outra bem diferente

Se alguém te vender "o threshold ideal", desconfia na hora 😀

Modelo pequeno e especializado: o que já dá para dizer na prática

Eu não testei o Jev, ele ainda está em early access com lista de espera, e eu não vou inventar experiência que não tenho

Mas eu tenho uma experiência que rima demais com esse assunto

No vídeo sobre o Gemma3 270m eu mostro como baixar e rodar o modelo localmente na própria máquina, sem depender de uma interface web tipo a do ChatGPT

Quando testei com um prompt bem definido e de escopo pequeno, ele respondeu certinho

Aí eu testei de propósito com um prompt ruim e vago, pedindo pra criar um artigo sobre N8N sem detalhar o que é o software

Resultado: um texto genérico que nem citou o N8N… e em alguns momentos o modelo dá uma doidada e muda de linguagem no meio da resposta, coisa que um chat maior não faria

A conclusão que ficou pra mim: modelo com menos parâmetros exige prompt bem construído e tarefa de escopo bem definido, porque ele raciocina menos que os grandes

O padrão é esse, e vale a leitura pro caso do Jev também: quanto mais estreita e bem definida a tarefa, mais o especializado brilha

A diferença é que o Gemma3 270m ainda é um gerador de texto (e por isso ele consegue divagar), enquanto o Jev nem tem essa porta aberta, já que abriu mão de gerar string

Pra começar do zero com modelo pequeno rodando local e ver esse comportamento com os próprios olhos, este vídeo do canal mostra o caminho completo:

Veredito: quando cada caminho compensa

O Jev compensa quando você tem volume alto de classificação e roteamento, a decisão é fechada (escolher, pontuar, responder sim/não) e você precisa de confiança explícita pra decidir o que escalar

Nesse cenário, o código encolhe de verdade: acabou o schema gigante, acabou a camada de logprobs, acabou o retry de parse

A saída estruturada do LLM compensa quando o pipeline já roda num modelo generalista e precisa também gerar texto: classificar o ticket E redigir a resposta, categorizar E resumir

Meter mais um provedor na jogada pra ganhar um campo de confiança pode não pagar o custo de integração

E agora a parte honesta da coisa

A TypeSafe mantém uma página pública de limitações conhecidas (eles chamam de jaggedness) do jev-1.13, e eu acho muito massa que exista isso, mas é leitura obrigatória antes de você colocar o modelo numa rota crítica

A comparação de custo também precisa de asterisco: o preço que dá pra citar hoje é o do OpenRouter, que lista o Jev em beta, e o acesso direto segue em early access por lista de espera

Beta e waitlist mudam. Então trate número de hoje como número de hoje…

Conclusão

Recapitulando: pedir JSON a um LLM generalista resolve formato, e resolve bem, com strict: true forçando o schema

O que ele não resolve de graça é confiança, e é justamente aí que o Jev TypeSafe muda o jogo, entregando valor tipado, distribuição de probabilidade e um confidence de 0 a 1 numa chamada que avalia todas as perguntas em paralelo

Próximo passo concreto, na ordem certa:

1. Entrar na lista de espera da TypeSafe ou testar pelo OpenRouter em beta, usando as rotas jev-1.13 ou jev-latest
2. Montar um conjunto pequeno de exemplos rotulados do SEU domínio, com os rótulos que você já considera corretos hoje
3. Rodar os dois caminhos em cima desse conjunto e medir onde cada um erra
4. Só depois disso escolher o limiar de confiança, com o custo de errar e o custo de revisar na conta

Trocar rota em produção antes de medir é pedir pra passar vergonha na segunda-feira, haha

Faça o teste e me conta o que deu, beleza? Até o próximo post!