Como medir se o Jev melhorou o processo: acerto, custo por decisão e tempo de ciclo

Fala aí, beleza? Plugar o Jev no fluxo é a parte fácil

Provar que ele melhorou o processo é o que separa piloto de produção…

E aqui tem uma sacada: o Jev é o primeiro modelo System One da TypeSafe AI, ele recebe o estado (texto, log, ticket, JSON) mais perguntas tipadas e devolve decisões tipadas (Noul, Choice, Score) com confiança calibrada, em vez de texto livre

Isso muda COMO você mede

Porque agora existe um terceiro caminho no meio do fluxo: além de acertar e errar, o sistema pode escalar o caso pra uma pessoa ou pra um modelo de raciocínio quando a confiança fica baixa

Se você só olhar "acurácia", você mede errado

O que vem abaixo é um roteiro de métricas pra defender ou derrubar a decisão de manter a integração, com os números que dá pra medir de verdade e os erros comuns de cada etapa

O que você precisa ter antes de medir

Antes de sair rodando comparação, junta esse kit:

• Baseline registrado do processo anterior: quem decidia, quanto acertava, quanto demorava e quanto custava. Sem baseline você não tem comparação, tem opinião
• Conjunto de casos rotulados por você (ground truth próprio), com o mix real de casos que chega no seu fluxo
• Logs das respostas do Jev, guardando o id versionado do modelo, as answers, a confidence e o objeto usage
• Versão do modelo fixada no código

Esse último merece parágrafo próprio

Pré-inscrição Curso Jev

Domine o Jev e coloque decisões de IA dentro do seu sistema

Você vai aprender a usar o Jev, o System One Model da TypeSafe AI, pra automatizar decisões com resposta tipada e confiança medida, sem depender de chat nem de alguém revisando cada passo. Entre na lista de espera para garantir a condição de lançamento!

Quero minha vaga

Por que pinar jev-1.13.0 e não jev-latest:

A documentação é direta: se você calibrou thresholds contra uma versão específica, fixe o ID daquela versão em vez do alias, porque os aliases mudam de modelo sem aviso

Hoje o jev-latest resolve pra jev-1.13.0

Amanhã pode resolver pra outra coisa, e aí todo o seu corte de confiança calibrado com suor vira abóbora sem ninguém perceber

Tome cuidado! Esse é o tipo de bug que não estoura log, só piora a métrica devagar

O alerta metodológico que ninguém te conta:

Os números divulgados pela própria TypeSafe no anúncio são fortes: até 193,6x mais rápido e 444,6x mais barato em testes internos de pico, latência de 70 a 500 ms fim a fim contra 3 a 329 s de modelos de fronteira, e cerca de 67,8% no benchmark interno de quatro workflows

Porém: essas medições são de concordância com modelos de fronteira (GPT-6 Astra e Claude Fable 5.1), não contra ground truth independente

Ou seja, servem de referência de ordem de grandeza, não de prova do seu caso

O seu ground truth é o único que decide se o Jev melhorou o SEU processo 🙂

Roteiro em 7 passos para medir o impacto do Jev

1. Congele o baseline e o conjunto de avaliação. Mesmo mix de casos, mesma janela, mesma definição de "acerto". O erro comum aqui é comparar o mês passado (humano) com este mês (Jev) e esquecer que o mix de casos mudou, então você mede sazonalidade achando que mede modelo
2. Instrumente o log de cada decisão com o id versionado do modelo, a confidence, as probabilities e o usage. Toda resposta de Choice e Score traz a propriedade probabilities (a distribuição) e a confidence, que colapsa essa distribuição num número de 0 a 1. O erro comum é logar só a resposta final: aí você perde o custo (que sai do usage) e perde a calibração (que sai da distribuição), e não consegue refazer nenhuma conta depois
3. Calcule acerto por faixa de confiança e plote confiança contra acurácia nos seus dados, que é exatamente o que a documentação orienta a fazer pra testar thresholds. O erro comum é usar um threshold único pra todas as ações: a doc diz que o corte não é um número único, ações diferentes no mesmo sistema devem ser liberadas em níveis diferentes conforme a consequência do erro, com piso de 0,5 pra capturar o que o modelo reporta como genuinamente incerto, e corte mais alto pra operação destrutiva do que pra leitura
4. Meça a taxa de escalonamento humano e a cobertura automática. Escalonamento não é falha, é custo. Um sistema que cobre a maior parte dos casos com acerto alto pode ser melhor que um que tenta cobrir tudo com acerto médio, depende do preço do erro no seu processo. O erro comum é contar caso escalado como "erro do modelo" e concluir que o Jev é ruim, quando o escalonamento é justamente o mecanismo funcionando
5. Calcule custo por decisão a partir dos input_tokens, somando o custo do que escalou. O Jev 1.13.0 é cobrado só por token de entrada: US$ 0,042 por 1 milhão de tokens de entrada e US$ 0,00 nos tokens de saída, com janela de contexto de 32.000 tokens. O erro comum é medir só o custo do Jev e esquecer que cada caso escalado carrega o custo do modelo caro (ou da hora da pessoa) junto
6. Meça tempo de ciclo fim a fim, do estado entrando até a ação executada, incluindo a fila do escalonamento humano. O erro comum é reportar só a latência da chamada de API: se o caso incerto fica 4 horas esperando alguém abrir a fila, o seu tempo de ciclo não melhorou, ele só mudou de lugar
7. Revalide a política quando o modelo ou as perguntas mudarem. Trocou a versão do modelo, reescreveu uma pergunta tipada, mudou o schema? A calibração anterior não vale mais. O erro comum é tratar threshold como constante de projeto, quando ele é um resultado de medição com validade

Sobre onde coletar os dados: o Jev roda na Vercel AI Gateway (modelo typesafe-ai/jev, chamado com a função experimental_evaluate do AI SDK na versão 7 ou superior) e na Cloudflare Workers AI (identificador typesafe/jev), além da API direta da TypeSafe

Se o seu fluxo antigo já rodava em cima de templates de automação no n8n, o baseline de tempo e volume provavelmente já está no histórico de execuções, é só não jogar fora

O cálculo do custo por decisão na prática:

A resposta da API traz o id versionado do modelo que respondeu e um objeto usage com input_tokens e output_tokens, então o custo por decisão sai de dado medido, não de estimativa

PRECO_ENTRADA_POR_MILHAO = 0.042  # USD, jev-1.13.0

def custo_da_decisao(resposta):
    uso = resposta["usage"]
    entrada = uso["input_tokens"]
    # saida custa 0.00 no jev-1.13.0, entra na conta so por clareza
    return (entrada / 1_000_000) * PRECO_ENTRADA_POR_MILHAO


def linha_de_log(resposta, decisao):
    return {
        "model": resposta["model"],          # ex: "jev-1.13.0"
        "confidence": decisao["confidence"],
        "probabilities": decisao["probabilities"],
        "input_tokens": resposta["usage"]["input_tokens"],
        "custo_usd": custo_da_decisao(resposta),
    }

Guardando o model em cada linha, quando a métrica mudar de patamar você sabe se foi a versão do modelo ou o seu prompt tipado

Se você roda na Cloudflare Workers AI, a conta muda de unidade: lá o preço da plataforma é US$ 0,011 por 1.000 Neurons, com 10.000 Neurons por dia gratuitos. Meça em Neurons consumidos e converta, senão você compara laranja com maçã

E quem já mantém monitoramento de custos em tempo real num fluxo n8n tem meio caminho andado: é o mesmo raciocínio de alerta por linha de execução, só trocando a métrica

Como referência externa de ordem de grandeza, o JevBench, benchmark comunitário não afiliado à TypeSafe, mede custo por 1.000 decisões (e não por token) com cerca de 950 tokens de entrada por decisão em média, e registra o Jev 1.13.0 em cerca de US$ 0,040 por 1.000 decisões. Se o seu custo medido estourar MUITO isso, provavelmente o seu estado está inchado

Como automatizar a medição do threshold com o Janus

Fazer a curva de confiança x acurácia na mão funciona, mas dá trabalho e você vai refazer isso toda vez que mudar alguma coisa

Existe um atalho da comunidade: o Janus, projeto do repositório FirasSX914/Janus, pacote janus-decide no PyPI

Ele mede em quais casos usar o Jev e quando rotear pra outro modelo, com base nos seus dados rotulados

E tem uma decisão de design que eu acho muito massa: ele não vem com threshold padrão e se recusa a rodar sem política medida nos seus dados. Nada de número mágico caído do céu

1. Instale o pacote com pip install janus-decide
2. Rode janus measure pra varrer os níveis de confiança observados, escolher o ponto de operação e gravar o janus.json. Esse arquivo é a sua política, versione ele junto com o código
3. Rode janus check pra verificar se a política ainda vale: ele confere se é o mesmo hash de pergunta e as mesmas versões de modelo resolvidas. É o teste de regressão da sua calibração
4. Use janus explain quando alguém perguntar por que um caso escalou e outro não. Auditoria de decisão é o que salva a integração na reunião, não o gráfico bonito

pip install janus-decide

janus measure    # varre confianca, escolhe o ponto de operacao, grava janus.json
janus check      # mesma pergunta? mesmas versoes resolvidas? politica ainda vale?
janus explain    # por que este caso escalou e aquele nao

O erro comum aqui é importar threshold de outro dataset porque "alguém usou e funcionou"

Não funciona: o ótimo é específico do conjunto de dados. No Banking77 a acurácia pica em 0,67, no Web of Science o ponto é 0,37

Mesmo modelo, mesma métrica, corte quase pela metade. Já dá pra imaginar o estrago de copiar o número do post de outra pessoa, né?

Lendo o resultado: quando manter, quando ajustar e quando derrubar

Agora a parte que interessa: o que os quatro números juntos querem dizer

Os dois cenários abaixo são resultados medidos publicamente pelo Janus, e eles são úteis porque mostram os dois lados da moeda

Cenário 1: manter, a cascata compensa

No Banking77 com roteamento por confiança do Jev pra DeepSeek no threshold 0,67, a medição deu 80,2% de acurácia a US$ 0,1033 por 500 decisões, com cobertura de 88,4% e o modelo caro acionado em 11,6% das requisições

É esse o formato de veredito que você quer levar pra defender a integração: acerto, custo, cobertura e corte, os quatro na mesma linha

Cenário 2: ajustar ou simplificar, a cascata não paga

No Web of Science a história vira: a cascata chega a 52,8%, exatamente o mesmo que o Jev sozinho atinge, e custa US$ 0,1474 contra US$ 0,1006

Traduzindo: você pagou a mais pra não ganhar acerto nenhum

Aqui o veredito honesto não é "derruba o Jev", é "derruba a cascata" e roda só o modelo barato, ou repensa o escalonamento

Por isso medir separado importa: sem os dois custos lado a lado, esse caso passa batido como "tá funcionando"

Cenário 3: acerto baixo por limitação conhecida

Antes de culpar o threshold, passa a sua tarefa nessa checklist. A página de jaggedness do jev-1.13.0 lista onde o modelo erra:

• leitura literal da pergunta (escopo, negação e condições implícitas lidos ao pé da letra)
• contagem não confiável
• tarefas que exigem precisão numérica
• comparações de data e hora
• estado grande e irrelevante
• instruções contraditórias
• consistência estrutural entre várias respostas

Se o seu caso ruim cai em "negação lida ao pé da letra" ou "instrução contraditória", o problema é a pergunta tipada, e reescrever o prompt resolve mais que mexer no corte

Se cai em contagem, precisão numérica ou comparação de data e hora, o problema é tarefa errada pro modelo, e nenhum threshold vai salvar

Se o acerto é bom nas faixas altas de confiança e ruim nas baixas, aí sim é threshold, e é só calibrar

Três diagnósticos diferentes, três ações diferentes. Fazer essa triagem antes de decidir evita aquele clássico de ficar meses girando parâmetro de um problema que não era de parâmetro

Vídeo: contexto sobre orquestrar vários modelos

Todo esse papo de cascata e roteamento entre modelos tem um pano de fundo maior: a ideia de combinar modelos diferentes numa resposta só

Pra começar do zero nesse assunto, este vídeo do canal mostra a Sakana Fugu, a IA que usa vários modelos ao mesmo tempo

O próximo passo: transformar a medição em rotina

O grande erro de quem avalia adoção de modelo é tratar isso como evento único

Não é veredito, é relatório recorrente

As quatro métricas lado a lado (acerto contra o seu ground truth, taxa de escalonamento, custo por decisão e tempo de ciclo fim a fim), sempre com a versão do modelo anotada na planilha

No dia em que um dos quatro pular de patamar, você vai saber exatamente qual mudou e contra qual versão comparar

O próximo passo concreto: separa de 200 a 500 casos rotulados seus, roda a medição com a versão pinada em jev-1.13.0 e compara com o baseline ANTES de expandir o escopo

Se os números segurarem, expande com relatório na mão

E fica de olho num detalhe que pesa na decisão de dependência: o Jev segue em early access, com lista de espera e convites liberados em ondas

Medir bem também é isso, saber de quem você está dependendo 😀

Até o próximo post!