Sete casos que nenhum teste previu
A suíte de eval da versão nova tinha passado com nota alta: 94 em 100 casos de teste, zero regressão nos que já tinham dado problema antes. O time queria trocar o agente em produção naquela mesma tarde. A gente segurou por três dias.
Nesses três dias, o agente novo rodou em paralelo com o antigo: recebia os mesmos pedidos reais, gerava a resposta dele, mas nada do que ele dizia chegava no cliente. Só o agente antigo, o que já estava validado, continuava respondendo de verdade. No fim do terceiro dia a gente comparou os dois logs, linha por linha. Apareceram sete casos em que a resposta do agente novo mudava de um jeito que nenhum caso de teste cobria. Nenhum era grave. Mas nenhum tinha passado pela cabeça de quem escreveu os testes, porque eram combinações de pedido que só apareceram no tráfego real daquela semana.
Esse não é um cuidado de time paranoico. Uma pesquisa da VentureBeat com 157 empresas de mais de 100 funcionários, feita em junho de 2026 e publicada em julho, achou que metade já colocou em produção um agente ou recurso de IA que tinha passado nas avaliações internas e mesmo assim falhou na frente de um cliente de verdade. Dois terços das empresas já deixam, ou estão caminhando pra deixar, mudança de agente ir pra produção só com o eval automático aprovando, sem ninguém olhando antes. E o motivo mais citado pra desconfiar do eval, apontado por 29% dos respondentes, é que ele não bate com o que acontece no mundo real.
Por que o eval erra pro lado bonito
Eval mede o que alguém pensou em testar. Um conjunto de casos escrito por gente que conhece o produto, revisado, com respostas esperadas definidas antes. É bom pra pegar regressão: a versão nova quebrou algo que a versão antiga fazia certo. É ruim pra pegar o que ninguém imaginou, porque cliente real não segue roteiro. Ele manda mensagem cortada, muda de assunto no meio, repete a mesma pergunta com palavras diferentes, cola um número errado sem querer.
Eval mede o que a gente pensou em testar. Sombra mede o que o cliente de verdade manda.
Quanto mais a versão nova muda o caminho de decisão do agente (o prompt de sistema, a lista de ferramentas disponíveis, o modelo por trás), maior a chance de o eval passar limpo e ainda assim existir um bolsão de comportamento que ninguém cobriu. E como o eval é o portão mais barato e mais rápido, a tentação de tratar ele como suficiente cresce junto com a pressão pra entregar.
Como a sombra funciona na prática
O mecanismo é simples de descrever e chato de manter: o agente novo processa o mesmo input que chega em produção, ao mesmo tempo, mas a saída dele fica presa num log em vez de sair pro cliente. Um script compara as duas respostas depois:
para cada pedido no periodo:
resposta_antiga = log_producao[pedido.id]
resposta_nova = log_sombra[pedido.id]
if resposta_antiga != resposta_nova:
marcar_para_revisao(pedido.id, resposta_antiga, resposta_nova)
A parte que dá trabalho não é rodar os dois agentes ao mesmo tempo, é revisar as divergências sem virar ruído. Nem toda resposta diferente é erro: às vezes o agente novo simplesmente escreveu melhor. O que interessa é separar divergência de estilo de divergência de decisão, tipo o agente escolher uma ferramenta diferente ou chegar numa conclusão diferente sobre o mesmo pedido. Isso é o que a gente constrói quando monta um agente de produção pra cliente, dentro do trabalho de IA e automação: a esteira de comparação faz parte da entrega, não é um extra.
Sombra tem custo, e nem toda mudança merece
| Só eval | Eval mais sombra | |
|---|---|---|
| O que pega | Regressão nos casos já escritos | Regressão mais comportamento não previsto no tráfego real |
| Tempo até produção | Minutos | Dias |
| Custo de inferência | Uma chamada por pedido | Duas chamadas por pedido durante a janela |
| Onde falha | Casos fora do que foi testado | Praticamente nada, se a janela for longa o bastante |
A sombra custa tempo e custa duas vezes a chamada de modelo durante a janela, porque os dois agentes estão processando o mesmo pedido. Pra uma correção de texto que não muda decisão nenhuma, isso é desperdício: sobe direto depois do eval. Mas pra qualquer mudança que mexa no prompt de sistema, na lista de ferramentas ou no modelo por trás, a sombra é obrigatória aqui. A régua que a gente usa: se a mudança pode alterar qual decisão o agente toma, e não só como ele escreve a decisão, ela passa pela sombra antes de ir pro cliente.
O que fazer na segunda de manhã
Antes de trocar a versão de um agente que já está em produção, pergunta: essa mudança altera o caminho de decisão ou só o texto de saída? Se altera decisão, instrumenta o agente pra rodar em paralelo por alguns dias antes do corte, comparando saída sem deixar a versão nova agir de verdade. Não precisa de ferramenta cara pra isso, precisa só de um lugar pra guardar os dois logs e alguém disposto a ler a diferença. Eval verde é condição necessária. Nunca é a única.
