Testar um agente de IA não é teste de software nem benchmark de modelos. Um agente percorre um caminho que muda de execução para execução, pelo que a única medida com sentido é uma distribuição — a mesma tarefa, nas mesmas condições, vinte execuções, quantas terminaram corretamente. A aritmética é simples e brutal: um agente com 95 % de exatidão em cada passo conclui corretamente apenas cerca de 60 % das tarefas de dez passos. Um dispositivo de avaliação que funciona tem quatro partes: um conjunto de casos retirado do mundo real, medição a quatro níveis, uma campanha de regressão a cada alteração e monitorização em produção.
Porque é que o teste de software habitual não funciona aqui
O teste de software convencional pressupõe determinismo: a mesma entrada produz a mesma saída, pelo que basta cobrir os caminhos. Num agente esse pressuposto não se mantém. A mesma entrada pode produzir um caminho diferente, uma ordem de ferramentas diferente e um resultado diferente — não por causa de um erro de programação, mas por causa da forma como o modelo funciona.
A pergunta do teste muda, portanto, de natureza. Em vez de passou ou falhou, a pergunta passa a ser com que frequência tem êxito e a que distância da média está a pior falha. As equipas que se queimam são as que viram uma demonstração bem-sucedida, concluíram que o sistema funciona e descobriram em produção que a demonstração tinha sido a melhor execução em cinco.
A métrica de sucesso mais citada no setor mede um êxito único em condições ótimas. Em produção o que interessa é a estabilidade: a mesma tarefa, muitas execuções. A distância entre esses dois números é a distância entre uma demonstração e um sistema.
A aritmética que explica quase tudo
Um agente executa uma tarefa como uma cadeia de passos. Se cada passo for independente, a taxa de êxito da tarefa é o produto das probabilidades. Parece trivial até se colocarem os números.
| Exatidão por passo | Tarefa de 5 passos | 10 passos | 20 passos |
|---|---|---|---|
| 90 % | 59 % | 35 % | 12 % |
| 95 % | 77 % | 60 % | 36 % |
| 98 % | 90 % | 82 % | 67 % |
| 99 % | 95 % | 90 % | 82 % |
Daqui decorrem duas conclusões operacionais. Primeira: encurtar a tarefa vale mais do que melhorar o modelo. Passar de vinte passos para dez, com 95 % de exatidão, quase duplica a taxa de êxito, de 36 % para 60 %. Segunda: as cadeias longas exigem uma exatidão por passo muito difícil de atingir, pelo que as tarefas longas obrigam a pontos de controlo e a validação intermédia em vez de um único ciclo contínuo.
É também por isto que tarefas invulgarmente longas continuam a falhar na maior parte das vezes, mesmo com os melhores modelos disponíveis. Partir o trabalho em subtarefas com validação intermédia não é um compromisso de engenharia: é o único caminho que a matemática permite.
Como construir um conjunto de casos que lhe ensine mesmo alguma coisa
Um conjunto de testes escrito por quem construiu o agente vai falhar em produção, porque reflete aquilo que o programador imaginou. O conjunto certo vem de três fontes.
| Tipo de caso | De onde vem | Que proporção |
|---|---|---|
| Caminho nominal | Os últimos vinte pedidos tratados manualmente | ~40 % do conjunto |
| Casos-limite reais | Reclamações, reembolsos, casos que exigiram escalamento | ~40 % do conjunto |
| Casos adversos | Tentativas de injeção, entrada em falta, contradições, pedidos fora do âmbito | ~20 % do conjunto |
Cada caso precisa de uma condição de êxito definida antecipadamente. Não uma pontuação subjetiva, mas uma condição verificável: o campo foi atualizado com o valor correto, o e-mail seguiu para o endereço correto, o total coincide com o cálculo manual, ou o agente recusou agir e escalou. Um caso sem condição de êxito não é um caso de teste, é uma impressão.
Uma dimensão inicial razoável: 40 a 80 casos, cada um executado cinco a dez vezes. Parece muito, mas são alguns minutos de execução e alguns euros de custo — contra um único cliente que recebeu uma resposta errada.
Quatro níveis de medição
Medir apenas o resultado esconde a causa. Um dispositivo útil mede quatro níveis em paralelo.
| Nível | O que é medido | O que revela |
|---|---|---|
| Resultado | Se a condição de êxito foi cumprida | Se o sistema ultrapassa a fasquia do negócio |
| Caminho | A ordem das ferramentas escolhidas e o número de passos | Onde o agente começa a desviar-se, antes de o resultado quebrar |
| Ferramenta | Taxa de chamadas com argumento errado ou ferramenta inadequada | Que descrições de ferramentas precisam de correção |
| Custo | Tokens, chamadas e tempo por tarefa | Se a solução continua económica à escala |
O nível caminho é o mais importante para depuração. Um erro do agente costuma aparecer longe do sítio onde foi criado, pelo que sem um registo completo de cada chamada e de cada resultado não há forma de encontrar o passo que iniciou o desvio. O enquadramento estrutural está explicado em Anatomia de um agente de IA empresarial.
Regressão: o que parte um agente em que ninguém tocou
Um agente é um dos poucos sistemas capazes de partir sem que ninguém tenha mexido numa linha lá dentro. Há três causas principais.
Atualização do modelo. O fornecedor lança uma versão nova e o comportamento desloca-se — habitualmente melhor em média e pior em casos específicos que tinham sido calibrados para a versão anterior. Cada subida de versão do modelo exige, por isso, uma execução completa do conjunto antes da mudança.
Alteração do esquema de uma ferramenta. Um campo acrescentado, um nome alterado, um novo valor por omissão. O agente não vai rebentar; vai continuar a chamar a ferramenta da maneira que ontem estava correta.
Desvio dos dados. A forma dos pedidos que entram muda ao longo do tempo, chegam produtos novos, a linguagem dos clientes altera-se. Um conjunto de testes com um ano está a testar um mundo que já não existe.
Uma regra de trabalho simples: o conjunto corre automaticamente a cada alteração do prompt, das ferramentas ou do modelo, e é renovado trimestralmente a partir do tráfego real.
Monitorização em produção — a única coisa que mede a verdade
O conjunto mede aquilo que se lembrou de testar. A produção mede aquilo que acontece. Quatro métricas chegam para apanhar a tempo quase qualquer problema.
- Taxa de conclusão. A fatia de tarefas que terminou sem intervenção humana e sem falha.
- Taxa de escalamento. Com que frequência o agente parou e pediu um humano. Uma subida súbita sinaliza mudança nas entradas; uma descida súbita sinaliza excesso de confiança.
- Taxa de correção. Com que frequência uma pessoa alterou aquilo que o agente propôs. É a métrica mais próxima da qualidade real.
- Custo por tarefa bem-sucedida. Não o custo por chamada. As tarefas que falham e são repetidas são o custo verdadeiro — o lado financeiro está detalhado no guia de redução do custo de inferência.
A taxa de correção é também o sinal mais claro de que o ponto de aprovação está no sítio certo. Se quase ninguém corrige nada, a aprovação passou a ser um carimbo automático — um tema tratado no guia da aprovação humana.
Uma lista de verificação antes de o agente tocar num cliente
- Cada caso do conjunto tem uma condição de êxito inequívoca, escrita antes da execução.
- Cada caso corre pelo menos cinco vezes, e a métrica reportada é a estabilidade e não a melhor execução.
- O conjunto inclui casos adversos, incluindo tentativas de injeção por cada canal de entrada — veja o guia das permissões.
- Existe um registo completo das chamadas a ferramentas e dos respetivos resultados para cada execução, armazenado e pesquisável.
- Foi definida uma fasquia numérica de negócio para entrar em produção, em vez de uma sensação de suficientemente bom.
- Foi definido um cenário de recurso: o que acontece quando o agente falha e quem recebe a tarefa.
Perguntas frequentes
O que são as avaliações (evals) de um agente de IA?
Um dispositivo de teste que mede o comportamento do agente sobre um conjunto de casos predefinido, cada caso em várias execuções, e que reporta a distribuição dos resultados em vez de um êxito isolado. Cobre o resultado, o caminho, o uso de ferramentas e o custo.
De quantos casos de teste se precisa?
Um conjunto inicial de 40 a 80 casos cobre a maior parte do comportamento de um agente de tarefa única, desde que esteja repartido entre caminho nominal, casos-limite reais e casos adversos. Mais importante do que o número de casos é o número de execuções por caso, que deve ser de pelo menos cinco.
Porque é que um agente que funcionou na demonstração falha em produção?
Porque a demonstração mediu uma execução em condições confortáveis. Em produção a tarefa é mais longa, as entradas são mais sujas e os erros compõem-se ao longo dos passos. Um agente com 95 % de exatidão por passo conclui corretamente apenas cerca de 60 % das tarefas de dez passos.
Pode usar-se um modelo para julgar o agente?
Sim, mas apenas como camada complementar. O julgamento automático serve para medidas qualitativas como o tom ou a completude de uma resposta, não para condições de êxito verificáveis de forma determinista. Qualquer caso que possa ser verificado comparando valores deve ser verificado assim.
Quando se corre o conjunto de testes?
A cada alteração do prompt, das ferramentas ou da versão do modelo, mais uma renovação periódica do conjunto a partir do tráfego real. Um agente pode partir mesmo sem ninguém lhe ter tocado, sobretudo na sequência de uma atualização do modelo ou de uma alteração do esquema de uma ferramenta.
Continue a ler
Agentes de IA autoalojados: quando a infraestrutura interna se justifica – As avaliações decidem a entrada em produção. O sítio onde o agente corre decide o que vai conseguir registar, medir e reexecutar depois.