Como validar as decisões do Jev antes de colocar em produção?

Colocar decisão automatizada em produção sem validar é entregar o processo da sua empresa pra uma caixinha que ninguém abriu

E com o Jev a conversa muda de figura, porque ele não é um LLM que cospe texto

Ele é o primeiro System One Model da TypeSafe AI: recebe estado não estruturado e devolve decisão tipada com probabilidades, em vez de string

Ou seja, tem DOIS números pra validar, não um

O primeiro é o óbvio: ele acertou? O segundo é o que quase todo mundo esquece: quando ele diz que está 0,9 confiante, ele acerta mesmo nessa mesma proporção das vezes?

Se o segundo número mente, todo o seu roteamento automático vira loteria, mesmo com acurácia bonita no papel

Bora montar essa validação direito? 🙂

O que você precisa antes de começar a validação

Primeiro o acesso

O Jev está em acesso antecipado por lista de espera desde 15/09/2026, sem data anunciada de disponibilidade geral

Fora da waitlist, ele aparece em provedores terceiros: Vercel AI Gateway (no AI SDK 7, pela experimental evaluate API, chamando o modelo typesafe-ai/jev), Cloudflare (página de modelo typesafe/jev) e OpenRouter (typesafe/jev-1.13)

Depois o básico técnico:

• Chave de API na variável de ambiente TYPESAFE_API_KEY
• SDK Python oficial, que pede Python >= 3.10 e instala com pip install "typesafe-sdk>=0.5.7" usando --extra-index-url https://pypi.typesafe.ai/
• Ou chamada direta em POST https://api.typesafe.ai/v1/systemone, com header Authorization: Bearer <API_KEY> e Content-Type: application/json

Se você trabalha dentro do Claude Code, a TypeSafe mantém uma agent skill oficial: claude plugin marketplace add typesafe-ai/skills, depois claude plugin install typesafe@typesafe-ai, e você invoca com /typesafe:typesafe-ai (a instalação é local ao projeto por padrão, com -g pra global)

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

Agora o pré-requisito que ninguém tem pronto na gaveta

Você precisa de um conjunto de casos reais com a resposta correta conhecida

Sem isso não existe validação, existe achismo com terminal aberto 😛

E um detalhe de tamanho: o OpenRouter lista a janela de contexto do Jev 1.13 em 32.000 tokens, então o estado que você manda precisa caber aí

Passo a passo para validar as decisões do Jev

1. Escolha a primitiva certa e escreva a pergunta literal

A API tem três tipos de pergunta: Choice (uma opção de um conjunto), Score (nível dentro de uma escala ordenada e descritiva) e Noul (sim/não, que retorna a probabilidade de a resposta ser sim)

Escolher errado aqui contamina tudo que vem depois, porque você vai medir a pergunta errada com precisão cirúrgica

O erro comum deste passo: escrever a pergunta que você PRETENDIA fazer, não a que está escrita. A própria página de limitações conhecidas do jev-1.13 avisa que o modelo é literal, ele responde exatamente o que está na pergunta

Esse cuidado é o mesmo de escrever uma spec antes de implementar: ambiguidade na frase vira defeito silencioso lá na frente

2. Monte o conjunto rotulado a partir de casos reais

Pega histórico de verdade: tickets já resolvidos, sinistros já julgados, posts já moderados

E inclui os casos difíceis, os que fizeram alguém da operação parar e pensar

O erro comum deste passo: montar um conjunto só com caso fácil. Aí a acurácia sai redonda, todo mundo bate palma, e a produção estoura na primeira semana com o caso ambíguo que nunca entrou na amostra

3. Rode o lote e guarde tudo

Resposta, probabilities e confidence, caso a caso

Respostas de Choice e Score trazem a propriedade probabilities (distribuição que soma 1) e um confidence entre 0 e 1 derivado dessa distribuição

Respostas de Noul NÃO trazem confidence, elas trazem a probabilidade de a resposta ser sim, que é coisa diferente

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d @caso-001.json

O erro comum deste passo: salvar só a decisão final e descartar a distribuição. Sem probabilities guardado, você não tem como refazer análise de limiar depois sem rodar o lote inteiro de novo

4. Meça acurácia contra os rótulos

Aqui é o feijão com arroz: quantos casos bateram com a resposta conhecida

Mede também por classe, não só o total. Um modelo que acerta bastante no geral pode estar errando quase tudo na classe rara, que normalmente é justo a classe cara

O erro comum deste passo: olhar a média e parar. Média esconde exatamente o subgrupo que vai te machucar

5. Plote confiança contra acurácia por faixa

Esse é o passo que separa validação de verdade de teatro

A documentação orienta isso direto: pegue um conjunto de entradas cujas respostas você conhece, rode e veja onde confiança e acurácia divergem

Na prática, você pega os resultados de Choice e Score (que são os que trazem confidence), agrupa por faixa e calcula a acurácia dentro de cada uma

Noul fica fora desse balde, porque ali o que volta é a probabilidade de a resposta ser sim, não um confidence

from collections import defaultdict

# cada item vem de uma resposta de Choice ou Score: {"esperado": ..., "resposta": ..., "confidence": 0.0 a 1.0}
baldes = defaultdict(lambda: {"n": 0, "acertos": 0, "soma_conf": 0.0})

for r in resultados:
    nivel = min(int(r["confidence"] * 10), 9)  # 0.0-0.1, 0.1-0.2 ...
    b = baldes.setdefault(nivel, {"n": 0, "acertos": 0, "soma_conf": 0.0})
    b["n"] += 1
    b["soma_conf"] += r["confidence"]
    b["acertos"] += int(r["resposta"] == r["esperado"])

print("faixa | casos | conf_media | acuracia")
for nivel in sorted(baldes):
    b = baldes.get(nivel)
    conf_media = b["soma_conf"] / b["n"]
    acuracia = b["acertos"] / b["n"]
    print(f"{nivel/10:.1f} | {b['n']:5d} | {conf_media:.2f} | {acuracia:.2f}")

O que você quer ver: a coluna de confiança média e a de acurácia andando juntas

Se na faixa 0,9 a acurácia dá 0,6, o número de confiança não serve pra decidir nada

O erro comum deste passo: faixa com 4 casos dentro. Balde vazio não mede calibração, mede ruído. Se não tiver volume, junta faixas

6. Meça estabilidade repetindo a mesma rubrica no mesmo caso

Os cookbooks oficiais de autoconsistência fazem exatamente isso: o de nouls roda uma rubrica de 14 perguntas sobre um sinistro de seguro 15 vezes, e o de choices roda uma rubrica de moderação sobre um post 15 vezes, usando um campo uid novo a cada chamada

Você repete e olha a dispersão: a decisão se manteve? a confiança oscilou quanto?

O erro comum deste passo: rodar uma vez só, ver o resultado bonito e concluir que está resolvido. Decisão instável entre execuções é um problema que só aparece quando você repete

7. Defina os limiares POR AÇÃO, não um número único

A documentação é clara nisso: o threshold sai dos seus exemplos rotulados combinados com o custo do erro e o custo da revisão humana

Cada ação é barrada num nível diferente conforme a consequência

Arquivar um ticket errado é chato. Cancelar uma cobrança errada é caro. Mesmo modelo, mesma confiança, limiares diferentes

O erro comum deste passo: escolher um 0.8 redondo porque parece um bom número. Não é metodologia, é estética

8. Fixe o ID versionado e confira os modelos da conta

Os exemplos dos docs usam jev-latest, que também é o padrão do SDK

Só que jev-latest é alias, e ele muda quando sai release novo

Se você calibrou limiar contra uma versão, fixa o ID versionado (ex: jev-1.13.0)

curl https://api.typesafe.ai/v1/models \
  -H "Authorization: Bearer $TYPESAFE_API_KEY"

Esse GET /v1/models lista os nomes aceitos pela sua conta

O erro comum deste passo: deixar o alias em produção depois de calibrar. Um dia o comportamento muda sozinho e você vai procurar bug no seu código por três dias… 🙃

Por que calibração importa tanto quanto acurácia

Vamos com dois modelos imaginários, ambos com a MESMA acurácia

O modelo A distribui a confiança direitinho: quando ele diz 0,95, ele acerta quase sempre; quando diz 0,55, ele erra bastante

O modelo B responde 0,97 em TUDO, acertando ou errando

Mesma acurácia, comportamento em produção completamente diferente

Com o modelo A você automatiza a faixa alta e manda a faixa baixa pro humano, e ganha tempo de verdade

Com o modelo B você não tem onde cortar. Ou revisa tudo, ou automatiza tudo e come todo o erro de olhos fechados

É por isso que existe o padrão documentado de roteamento por confiança: faixa alta age automaticamente, faixa média confirma ou sinaliza pra revisão, faixa baixa vai pra humano, pede esclarecimento ou cai em outro sistema, como um modelo de raciocínio mais caro

Esse padrão SÓ funciona se o número de confiança for honesto

A TypeSafe diz ter treinado o Jev com um método próprio chamado RLCD, de Reinforcement Learning for Calibrated Decisions, que otimiza justamente pra que as probabilidades acompanhem a taxa real de acerto

É uma promessa de treino, e é uma promessa interessante

Mas promessa de treino não é medição no SEU domínio, com os SEUS casos, com a SUA pergunta literal

O trabalho de calibrar continua sendo seu

Sinais de que a validação está enganando você

Sintoma: acurácia alta e confiança colada no teto em todo caso

Causa: conjunto fácil demais, sem os casos ambíguos da operação real

Prevenção: monte o conjunto puxando os casos que geraram discussão interna, retrabalho ou reclamação. Se todo mundo do time concorda na hora, aquele caso não está testando nada

Sintoma: o mesmo caso dá resposta diferente entre execuções

Causa: pergunta ambígua, rubrica mal delimitada ou estado incompleto

Prevenção: rode a mesma rubrica várias vezes sobre o mesmo caso antes de olhar acurácia, no espírito dos cookbooks oficiais. Instabilidade primeiro, métrica depois

Sintoma: erra feio em pergunta com número ou com data

Causa: está na página de limitações conhecidas do jev-1.13. O modelo é fraco em precisão numérica (não peça pra interpolar valores entre níveis de Score) e lê datas como texto, o que torna comparação, distância e janela de datas pouco confiáveis

Prevenção: faça a conta fora do modelo e pergunte só o julgamento. Data e aritmética são trabalho de código, não de decisão

Sintoma: você desenhou a pergunta B assumindo a resposta da pergunta A

Causa: perguntas enviadas na mesma requisição são avaliadas de forma independente e em paralelo. Toda pergunta vê o mesmo estado, e o resultado de uma primitiva não vira contexto oculto de outra

Prevenção: cada pergunta precisa se sustentar sozinha com o estado que foi enviado. Se existe dependência de verdade, ela é orquestração no seu código, em duas chamadas

Sintoma: o limiar que funcionava começou a se comportar diferente sem ninguém mexer

Causa: jev-latest avançou de versão

Prevenção: ID versionado fixo em produção, e revalidação do conjunto rotulado antes de subir versão nova. É a mesma disciplina de testar integrações antes de ir pra produção: você congela o que está validado e reexecuta a bateria quando algo muda embaixo

O que os benchmarks públicos mostram (e o que eles não provam)

A TypeSafe mantém um dashboard público de workflow evals em evals.typesafe.ai

Na consulta de 20/09/2026, os números eram estes, sobre 711 casos em quatro tarefas:

A diferença de custo e tempo é gritante, e é o argumento central da TypeSafe: nas próprias workflow evals eles divulgam até 193,6x mais rápido e 444,6x mais barato que LLMs

O OpenRouter fala em respostas de 70 a 500 ms de ponta a ponta, e lista o preço em US$ 0,042 por milhão de tokens de entrada e US$ 0 por milhão de tokens de saída

Agora a parte que quase não aparece nos posts empolgados sobre o assunto

Esse benchmark é operado pela própria TypeSafe

E os rótulos de referência são a média das respostas de GPT-6 Astra e Claude Fable 5.1, ambos em high thinking

Traduzindo: a métrica é concordância com referência de modelo, não correção verificada por humanos

Isso não invalida o número, mas muda o que ele significa. Concordar com outros dois modelos e estar certo no seu domínio são coisas diferentes

Esses números também valem pra aquela consulta: não dá pra afirmar como o ranking se comporta quando entram modelos novos no dashboard

Por isso a conclusão da seção é sempre a mesma: o conjunto rotulado que decide é o seu

Conclusão

Validar o Jev não é rodar dez casos e olhar se pareceu esperto

É medir acurácia e calibração juntas, definir limiar por ação conforme o custo do erro, e fixar a versão do modelo que você calibrou

Seu próximo passo é bem concreto: separa de 50 a algumas centenas de casos reais que a sua operação JÁ resolveu, transforma a regra atual em perguntas Choice, Score ou Noul, roda o lote e compara com os rótulos

Só depois desse gráfico de confiança contra acurácia é que faz sentido ligar qualquer automação

E lembrando do estado atual: o modelo segue em acesso antecipado por lista de espera desde 15/09/2026, sem data anunciada de disponibilidade geral, com os provedores terceiros como caminho alternativo

System One Model é coisa nova, tem pouca estrada rodada, e é exatamente por isso que a sua bateria de testes vale mais que qualquer benchmark de terceiro

Bora medir antes de confiar?

Até o próximo post! =)