O Juiz Falhou em Produção. O Upgrade Baixou o Erro Sem Tentar. O Guardrail Funcionou.

TV
Thiago Victorino
7 min de leitura
O Juiz Falhou em Produção. O Upgrade Baixou o Erro Sem Tentar. O Guardrail Funcionou.

Uma cliente beta do Vistaly olhou para a primeira árvore de oportunidades e soluções gerada para ela e disse: “That is a lot of first layer opportunities there. I wish I could click on this card and be like, Clean this up.” Teresa Torres pegou essa única reclamação e rodou dezesseis variantes de experimento contra ela, publicando recall e especificidade ao longo do caminho. O relato está no Product Talk, datado de setembro de 2026 nos metadados da página.

Uma ressalva antes de qualquer número. Trata-se de uma única fonte, um único produto, escrita pela pessoa que vende esse produto. Os percentuais são reduções relativas sobre as contagens de erro dela mesma, e as contagens absolutas nem todas estão na página. Leia os números como a trajetória medida de um time, e depois verifique se a forma se repete no seu próprio agente.

Três achados transferem para qualquer agente que gera estrutura. Um juiz calibrado em um conjunto de calibração está descalibrado em produção. Um upgrade de modelo pode baixar uma taxa de erro deixando de fazer o trabalho. E as variantes só de prompt trocaram um modo de falha por outro até um auditor determinístico ser ligado ao loop.

Quatro evals, e só uma delas é código

Torres construiu quatro evals para a reclamação. A de formato da árvore (tree-shape) é determinística: asserções em código sobre contagem de nós, violações de largura, contagem de filhos únicos, filhos por pai, pais de nível intermediário, profundidade máxima e contagem de CKMs. As outras três são juízes LLM: agrupamentos perdidos (missed-groupings), CKM mal enquadrado (poorly-framed-CKM) e pais que repetem os filhos (parent-restaters), esta última binária.

Essa divisão decide tudo o que vem depois. Asserções determinísticas não têm calibração para sofrer deriva. Dois dos três juízes acabaram precisando de uma segunda calibração, e boa parte da história das dezesseis variantes é descobrir o que esses juízes estavam de fato medindo.

O juiz estava calibrado. Produção discordou.

O juiz de agrupamentos perdidos começou com recall de 100% e especificidade de 43,75%. Essa especificidade significa que marcava mais da metade dos casos limpos. Vieram sete iterações: simplificar o prompt, estender, acrescentar exemplos e, nas palavras de Torres, “bumped to a smarter model”. Depois de sete rodadas, recall de 100% e especificidade de 60%. Dezesseis pontos de especificidade, a distância entre 43,75% e 60%, por sete rodadas de trabalho no próprio juiz.

A causa raiz estava em outro lugar. O juiz se confundia com erros upstream sem relação, presentes nas árvores que avaliava. O conselho de Hamel Husain era corrigir primeiro os erros upstream, conselho que Torres diz ter resistido no início. Corrigidos, o juiz de pais que repetem os filhos chegou a 100% de recall e 93% de especificidade, e o de CKM mal enquadrado a 90% de recall e 100% de especificidade. Calibrado, por qualquer padrão razoável.

A variante 1 rodou sobre dados de produção. As evals de pais que repetem os filhos e de CKM mal enquadrado saturaram acima de 90% de erro tanto na variante quanto no controle. Um juiz que encontra mais de 90% de erro nos dois braços de um experimento está relatando a si mesmo. Os juízes, calibrados em um conjunto de calibração, estavam descalibrados diante do que o produto de fato produzia. A primeira lição de Torres é a direta: recalibrar juízes com amostras de produção.

Cobrimos golden sets, juízes por critério e consenso de notas em O Golden Set de 600 Sinopses da Netflix. Os números de Torres mostram o que vem depois que o golden set passa: o mesmo juiz, movido para tráfego de produção, precisa de uma segunda calibração, e a falha se anuncia como uma taxa de erro implausível no braço de controle.

O upgrade de modelo baixou o erro deixando de fazer o trabalho

A variante 7 trocou o Sonnet 4.6 pelo Sonnet 5. Os erros de pais que repetem os filhos caíram a zero. Olhando só essa métrica, o upgrade parecia uma vitória limpa.

As contagens de pais de nível intermediário contaram outra história. Em um caso em que o Sonnet 4.6 tinha criado 6 pais intermediários, o Sonnet 5 criou 1. Em outro, o 4.6 tinha criado 11 e o Sonnet 5 criou 1. O erro caiu porque os agrupamentos deixaram de ser tentados. Um pai que não existe não repete filho nenhum.

Uma taxa de erro sem uma contagem de tentativas ao lado vai premiar isso toda vez. Pais de nível intermediário é uma das asserções de formato da árvore, e é nessa contagem que a troca aparece. Qualquer time que aprova um upgrade de modelo com base em uma única métrica de erro deveria assumir que essa troca está na mesa e conferir a contagem de tentativas antes de publicar.

Variantes de prompt, e uma troca atrás da outra

Cumulativamente ao longo das variantes 1 a 8, pais que repetem os filhos caíram cerca de 70% e CKMs mal enquadrados cerca de 54%. Esse é o efeito combinado de oito variantes, e quem procura uma única variante vencedora nesse número não vai encontrar.

As variantes que viviam no prompt seguiram trocando. Corrigir primeiro os erros upstream é a segunda lição de Torres, e ela registra que isso pode piorar o erro downstream. As variantes só de prompt moveram o erro de lugar. A terceira lição sai dessa experiência: engenharia de prompt, engenharia de contexto, orquestração e guardrails precisam ser trabalhados juntos.

De eval a guardrail

A variante 16 mudou a posição da checagem. Torres ligou uma ferramenta determinística de auditoria ao loop do agente, junto com uma correção para uma sobrecorreção de filho único. Depois de cada passo de geração, o auditor devolve seus achados ao modelo para autocorreção. Ela escolheu uma ferramenta determinística justamente para evitar mais uma chamada de LLM. O título da seção dela para esse passo é “Moving from Eval to Guardrail”.

O resultado, sobre as contagens de erro dela: redução de 78% em pais que repetem os filhos, redução de 29% em CKMs mal enquadrados e aumento de 65% em pais de nível intermediário. Os três números se moveram na direção certa ao mesmo tempo. A contagem de pais intermediários é a que mais importa aqui, porque é a contagem que caiu a 1 no teste de troca de modelo.

A eval mede a árvore depois que ela existe. O auditor roda dentro do loop e entrega ao modelo seus achados enquanto ainda há um passo para agir sobre eles. Mesmo tipo de checagem determinística, outra posição no pipeline, e a segunda posição é a que funciona como controle. Descrevemos a detecção em camadas no abstrato em Governança Prática Contra Alucinações de IA e argumentamos que avaliação é governança em Desenvolvimento Orientado por Avaliação. A variante 16 de Torres é a versão concreta das duas: checagens determinísticas promovidas de relatório a passo dentro do loop.

Faça isso agora

Escolha um juiz LLM do seu agente e pontue com ele uma amostra de saídas de produção. Se a taxa de erro passar de 90% em saídas que você considera aceitáveis, o juiz está descalibrado, e todo experimento que passou por ele fica sob suspeita. Recalibre com amostras de produção antes de mexer no agente.

Ao lado de cada taxa de erro que você acompanha, coloque uma contagem de tentativas. Para a árvore, esse número é o de pais intermediários. Para o seu agente, é aquilo que o modelo pode pular para fazer o erro sumir. Condicione qualquer troca de modelo aos dois números se movendo na direção certa.

Encontre a eval que você já roda como código determinístico. Mova-a para dentro do loop como um auditor que devolve achados ao modelo para autocorreção depois de cada passo. Sem chamada extra de LLM, sem juiz novo para calibrar. O resultado da variante 16 de Torres veio de uma ferramenta determinística colocada onde o modelo ainda tinha uma rodada para corrigir o que ela encontrou, junto com a correção da sobrecorreção de filho único.

Corrija primeiro os erros upstream e espere a métrica downstream piorar por um tempo. Planeje a sequência e avise quem lê o dashboard antes que aconteça. Se a sua rubrica de PM para julgamento de agentes ainda não tem uma linha para isso, a rubrica que cobrimos é um ponto de partida.


Fontes

A Victorino ajuda times de engenharia a mover evals de agentes de relatórios pós-fato para guardrails determinísticos dentro do loop de geração: 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