Jev Acertou 93%. Uma Constante Acertou 79%. Julgue o Portão Pelo Jeito Como Ele Erra

TV
Thiago Victorino
8 min de leitura
Jev Acertou 93%. Uma Constante Acertou 79%. Julgue o Portão Pelo Jeito Como Ele Erra

A equipe da Archestra pegou 100 chamadas de ferramenta reais de sessões de produção do Claude Code, deu quatro rótulos a cada uma, 400 decisões no total, e pediu ao Jev, o modelo de decisão da TypeSafe, que as classificasse. Nas 337 em que três juízes LLM concordaram, o Jev acertou 93%. Uma constante que sempre responde “benign” acertou 79%. A Archestra deixa claro o que esse piso significa para quem lê um ranking: “A model scoring 75% is worse than that baseline.” Um modelo com 75% fica abaixo da linha de base.

Uma declaração antes do argumento. A Victorino usa o Jev como portão de triagem no seu próprio pipeline de descoberta de conteúdo: ele ajuda a decidir quais artigos merecem uma leitura aprofundada por uma pessoa. Medimos o Jev contra a nossa triagem humana e chegamos a 77% de concordância, número que aparece mais adiante. Esse uso influencia a forma como lemos os resultados da Archestra, então pese a nossa leitura com isso em mente.

A nossa posição é estreita. Quando um modelo de decisão fica no caminho de controle, onde a resposta dele libera uma ação, bloqueia ou desvia para outro lugar, dois números vêm antes de qualquer acurácia de manchete: quanto uma constante acerta nos mesmos dados, e como são os erros do modelo.

Contra o Que os 93% São Medidos

O desenho do teste da Archestra merece leitura atenta antes dos números. A verdade de referência é a concordância entre três famílias de juízes (Claude Opus, GLM 5.3 Flash e Gemini 3.8 Flash). Os resultados valem para as 337 decisões em que os três concordaram, de um total de 400. Os rótulos vêm de juízes LLM, não de pessoas. Os autores chamam os resultados de preliminares e dizem que o benchmark original deles era ruim, uma admissão útil.

Nesse conjunto, o ranking parece simples:

  • Linha de base majoritária (uma constante): 79%
  • Jev, 0-shot: 93%
  • Jev, 9-shot: 95%
  • Sonnet 5, 0-shot: 98%

Lida de cima para baixo, a tabela manda escolher o Sonnet 5. Ele tem a maior acurácia das quatro linhas. A linha dos 79% muda o valor de cada ponto. O Jev fecha cerca de dois terços da distância entre a constante e o acerto total. O Sonnet 5 fecha mais. Os dois melhoram de verdade em relação a não fazer nada, e nenhum dos números diz ainda se o modelo pode ficar diante de uma fronteira de execução.

Defendemos o argumento geral em Governe a Qualidade do Código de IA por Baseline, Não por Anedota. Um modelo de decisão no caminho de controle é a versão mais aguda dele, porque nos dados da Archestra a resposta majoritária é a inofensiva.

Separe os Vazamentos das Travas

A acurácia faz a média de dois tipos de erro com custos muito diferentes. Um vazamento é uma chamada perigosa rotulada como segura: a ação roda. Uma trava é uma chamada segura rotulada como perigosa: a ação espera por uma pessoa. No caminho de controle, o primeiro tipo é o incidente.

A Archestra mediu o recall de recusa no rótulo requires_trusted, as chamadas que exigiam tratamento confiável. Eram 9. O Jev pegou 7. O Sonnet 5 pegou 4. Sobre o Sonnet 5, os autores escrevem: “It made eight errors on the strict set, and all eight were leaks.” Foram oito erros no conjunto estrito, e os oito eram vazamentos.

Mantenha o denominador à vista. Nove chamadas formam uma amostra pequena, e 7 contra 4 é uma diferença de três chamadas. Ninguém deveria ranquear modelos só com isso. O dado mostra que o modelo com maior acurácia e o modelo mais seguro podem ser modelos diferentes, e a tabela da manchete escondia isso por completo. O perigo mora na classe minoritária, então é ela que se conta à parte, com recall próprio.

Waldek Mastykarz propõe um teste que deixa isso concreto. Para cada avaliador, complete duas frases: “Se este avaliador passa, agora sei que ___” e “Se este avaliador falha, agora sei que ___”. Depois compare as duas com a afirmação que você pretende fazer. Tente com “98% de acurácia em 337 decisões com consenso”. A frase do caso aprovado nada diz sobre as 9 chamadas que importavam. Escrevemos sobre a mesma questão de ordem em revisão de segurança em Precisão Antes de Recall, e sobre testar o próprio instrumento em Calibre o Instrumento Primeiro.

Teste a Confiança Antes de Definir um Limiar

A Archestra também relata um resultado que torna o portão tentador: “among predictions with confidence of at least 0.7, it made no errors. That does not prove perfect calibration, but it makes confidence-based routing practical.” Entre as previsões com confiança de pelo menos 0,7, não houve erro, e os próprios autores avisam que isso não prova calibração perfeita. As rodadas de estabilidade explicam por que a ressalva é necessária.

Em 5 rodadas, entre 394 e 398 dos 400 rótulos voltaram idênticos na repetição. As probabilidades se moveram mais que os rótulos: a deriva chegou a 0,17 numa repetição simples e a 0,37 quando as opções de resposta foram reordenadas. A ordem das opções mudou a decisão em cerca de 4 de cada 100 casos.

Archer Hume encontrou a mesma sensibilidade. Inverter a ordem das opções levou uma probabilidade de suporte técnico de algo entre 0,84 e 0,89 para algo entre 0,93 e 0,96. A conclusão de Hume é direta: “A threshold near 0.9 could change the action even though the labels and evidence are identical.” Um limiar perto de 0,9 pode mudar a ação com rótulos e evidências idênticos. O post também mostra que o campo de confiança da API é calculado como c = (p_max − 1/K)/(1 − 1/K). É uma fórmula aplicada à maior probabilidade. Nada nela foi aprendido como estimativa de acerto.

Os números de calibração do mesmo post somam um segundo motivo de cautela. Numa amostra de 1.200 itens do MMLU, o erro esperado de calibração em dez faixas foi de 0,0313, o que parece excelente. Dentro da faixa de 0,5 a 0,6, a acurácia prevista foi de 52,8% e a observada foi de 39,3%, em 28 itens. Uma boa média pode esconder uma faixa ruim, e um limiar vive numa faixa. A recomendação de Hume serve a qualquer time prestes a instalar um corte: “Permutation tests belong in the evaluation of any implementation of this design.”

Deixe o Modelo Adiar

Tomasz Tunguz fez outro tipo de teste. Em 98 threads de e-mail de produção verificadas à mão, o classificador generativo de produção acertou 47% (46 de 98), o Jev acertou 80% (78 de 98) e o SemIf acertou 82% (80 de 98). Ele não relata linha de base constante nem distribuição de classes, então os 80% não podem ser postos contra um piso como os 93% da Archestra. O resultado se apoia em 98 threads.

A parte mais instrutiva é a execução ao vivo. Um decisor local agiu sobre 8 de 31 e-mails sem nenhum erro e adiou o resto. Essa é a arquitetura que copiaríamos para um caminho de controle: o modelo trata as chamadas de que tem certeza e entrega as outras a um caminho mais lento, seja uma pessoa, um modelo maior ou uma regra mais rígida. Um portão que adia transforma incerteza em trava, que é o erro barato.

Tunguz também cita uma redução de custo de 99%. É aritmética de preço de tabela (US$ 0,042 por milhão de tokens de entrada, saída gratuita), que a própria TypeSafe diz poder ser subsidiada. Trate isso como um preço que pode mudar. Se o desenho só funciona a esse preço, registre o que acontece quando ele se mover e como você trocaria o modelo.

Um memorando de desenho do lado da TypeSafe, intitulado “Why yet another agent” (a página não traz autor nem data), propõe chamadas a modelos de decisão para permissões e aprovações de comandos e para roteamento sensível a segurança. Ele não apresenta evidência de acurácia para esse posicionamento. O conselho da Archestra se aplica diretamente: “Never rubber-stamp a model on your execution boundary based on macro numbers alone.” Nunca aprove no automático um modelo na fronteira de execução com base só em números agregados. Simon Willison, escrevendo sobre o Jev, chega ao mesmo lugar: avaliações e experimentos estruturados importam ainda mais do que em projetos comuns com LLM. Ele acrescenta um alerta: “I really hope nobody uses Jev to rank job applicants.”

O Que o Nosso Próprio Portão Mostrou

A nossa medição é pequena e interna, e o arquivo de origem fica no nosso repositório, fora de qualquer página pública. Comparamos o Jev com a triagem humana em 61 artigos. No portão de leitura aprofundada, os dois concordaram em 77% (47 de 61). Em relevância, o Jev ficou a no máximo um ponto da nota humana em 84% (51 de 61). O Jev teria pulado 13 artigos que a pessoa escolheu ler.

Esses 13 são os nossos vazamentos: um artigo pulado não recebe leitura aprofundada. Usamos a resposta de relevância do Jev como portão e deixamos a nota composta fora da decisão. Um pipeline e 61 artigos provam pouco sobre a carga de trabalho de outra empresa. O método, ainda assim, se transfere: meça o portão contra decisões humanas e conte à parte os erros que custam caro.

Faça Isto Agora

Antes de um modelo de decisão tocar um caminho de controle, rode esta lista contra o seu próprio tráfego:

  1. Calcule a constante. Informe quanto “responder sempre o rótulo majoritário” acerta nos seus dados, ao lado de cada número de acurácia.
  2. Separe vazamentos de travas. Conte o perigoso rotulado como seguro separado do seguro rotulado como perigoso. Só o primeiro é incidente.
  3. Meça o recall na minoria perigosa. Dê a ela um denominador próprio e diga o quanto ele é pequeno.
  4. Repita e permute antes de escolher um limiar. Rode as mesmas entradas de novo, reordene as opções e registre quanto as probabilidades se movem perto do seu corte.
  5. Faça o modelo adiar. Deixe-o agir quando tiver confiança e mande o resto para um caminho mais lento. Não faça dele o único portão.
  6. Precifique a saída. Registre quanto o desenho custa se o preço de tabela mudar e como você substituiria o modelo.

Depois complete as duas frases de Mastykarz para o portão que você está prestes a colocar em produção. Se a frase do caso aprovado não menciona as chamadas perigosas, a avaliação ainda está incompleta.


Fontes

A Victorino ajuda times de engenharia a avaliar e governar os modelos que ficam no caminho de controle dos seus agentes: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa