Seu Agente IA está melhorando ou apenas acumulando correções?

Um cliente faz uma pergunta, o Agente IA responde de maneira inadequada e alguém da empresa percebe o problema. A equipe abre o prompt, acrescenta uma nova instrução e publica a alteração.

O problema parece resolvido.

Alguns dias depois, outra conversa apresenta um comportamento inesperado. Uma nova regra é adicionada. Depois outra. Aos poucos, o prompt se transforma em uma coleção de correções criadas para situações isoladas.

Esse processo produz a sensação de melhoria, mas não garante que o Agente ficou melhor. A instrução adicionada para corrigir uma conversa pode prejudicar outras dez. Uma mudança de modelo pode alterar comportamentos que funcionavam. Uma nova ferramenta pode resolver uma etapa do atendimento e criar falhas em outra.

Sem testes, cada alteração é uma aposta.

A avaliação contínua muda essa dinâmica. Em vez de apenas corrigir uma conversa problemática, a empresa transforma o erro em um teste repetível. A partir daquele momento, qualquer nova versão do Agente precisa demonstrar que resolveu o problema sem perder capacidades que já possuía.

Corrigir um erro não é o mesmo que melhorar o Agente

Corrigir um erro significa alterar o sistema até que determinada conversa funcione.

Avaliar significa definir o que deveria acontecer, executar novamente o cenário e verificar se o comportamento esperado continua sendo produzido depois de cada mudança.

Essa diferença modifica a forma como um Agente é desenvolvido.

Uma correção isolada desaparece dentro do histórico de alterações. Um teste passa a fazer parte da memória operacional do sistema. Ele registra uma situação que a empresa já encontrou e que não deveria voltar a acontecer.

A documentação de boas práticas de avaliação da OpenAI recomenda começar cedo, criar testes específicos para as tarefas reais, registrar as execuções e ampliar continuamente o conjunto de avaliações. Ela também alerta contra avaliações baseadas apenas na percepção de que o sistema “parece estar funcionando”.

A Anthropic apresenta uma separação útil entre dois tipos de avaliação:

Avaliações de capacidade perguntam o que o Agente consegue fazer e ajudam a encontrar os limites atuais do sistema.

Avaliações de regressão verificam se o Agente continua executando corretamente aquilo que já fazia antes. Quando uma capacidade passa a funcionar de forma consistente, ela pode entrar na suíte de regressão e ser executada a cada mudança relevante.

Na prática, uma conversa problemática pode começar como uma avaliação de capacidade:

O Agente consegue identificar que este cliente precisa falar com um atendente humano?

Depois que o problema é resolvido, o mesmo cenário se transforma em um teste de regressão:

O Agente ainda encaminha corretamente esse tipo de cliente depois das últimas alterações?

Essa lógica complementa uma ideia importante: prompt não é operação. A confiabilidade do Agente depende do conjunto formado por instruções, contexto, ferramentas, regras, dados, roteamento e supervisão.

Conversas reais são matéria-prima, não testes prontos

As conversas de produção são uma das fontes mais valiosas para melhorar um Agente porque revelam situações difíceis de prever durante sua criação.

Usuários escrevem com erros, omitem informações, misturam assuntos, mudam de intenção, respondem apenas parte de uma pergunta e utilizam expressões que não estavam na base de exemplos. Também podem solicitar algo que exige uma ferramenta, apresentar uma exceção comercial ou insistir para que o Agente viole uma regra.

A OpenAI recomenda combinar dados de produção, registros históricos, exemplos criados por especialistas e casos sintéticos. O conjunto deve representar situações comuns, casos extremos e tentativas adversariais.

Porém, copiar uma conversa para uma planilha não cria automaticamente uma avaliação.

Para que ela se transforme em um teste, é necessário definir:

* qual contexto estava disponível para o Agente;

* qual tarefa deveria ser executada;

* qual falha foi observada;

* qual comportamento seria considerado correto;

* quais comportamentos seriam inaceitáveis;

* como o resultado será avaliado.

Sem esses elementos, a equipe continua dependendo da impressão de quem lê a resposta. O teste acaba reduzido a perguntas como “parece melhor?” ou “gostamos mais desta versão?”.

Como criar um ciclo de avaliação contínua

Um processo de avaliação não precisa começar com uma plataforma complexa. Ele pode ser implementado com conversas selecionadas, uma planilha, critérios definidos e revisão humana.

O mais importante é estabelecer um ciclo que possa ser repetido.

1. Selecione conversas que carregam algum sinal

Não analise apenas os atendimentos que geraram reclamações. As falhas mais perigosas nem sempre são percebidas pelo cliente ou reportadas para a empresa.

Alguns sinais úteis são:

* conversas transferidas para atendimento humano;

* atendimentos abandonados antes da conclusão;

* respostas corrigidas manualmente pela equipe;

* uso incorreto ou ausência de uma ferramenta;

* informações inventadas ou não encontradas na base;

* orçamentos, agendamentos ou cadastros incompletos;

* conversas excessivamente longas;

* clientes que repetiram a mesma pergunta;

* atendimentos bem-sucedidos que representam comportamentos importantes.

Os bons exemplos também precisam ser preservados. Eles mostram capacidades que devem continuar funcionando depois das próximas mudanças.

Uma empresa pode começar revisando semanalmente uma amostra de conversas. Não é necessário ler todos os atendimentos. O objetivo é encontrar padrões relevantes e acrescentá-los gradualmente à base de testes.

Antes de armazenar qualquer conversa, dados pessoais e informações confidenciais devem ser removidos ou mascarados conforme as políticas da empresa.

2. Classifique a origem da falha

Um erro na resposta não significa necessariamente que o prompt está errado.

A falha pode estar em diferentes partes do sistema:

Conhecimento: o conteúdo não existia, estava desatualizado ou não foi recuperado. Nesse caso, o problema pode estar na manutenção da base de conhecimento do Agente.

Instrução: o Agente não recebeu uma orientação clara sobre como agir.

Interpretação: a intenção do usuário foi classificada incorretamente.

Contexto: uma informação apresentada anteriormente foi esquecida ou utilizada de maneira errada.

Ferramenta: o Agente escolheu a ferramenta incorreta, enviou parâmetros errados ou deixou de utilizá-la. Entender por que um Agente precisa de ferramentas ajuda a separar falhas de resposta de falhas de execução.

Regra de negócio: o sistema aplicou uma condição comercial, operacional ou financeira de maneira inadequada.

Roteamento: a conversa deveria ter sido encaminhada para outro fluxo, subagente ou atendente humano.

Comunicação: o conteúdo estava correto, mas a resposta foi confusa, extensa, repetitiva ou incompatível com o tom esperado.

Essa classificação evita que a empresa tente resolver todos os problemas adicionando frases ao prompt.

A análise de rastros é especialmente útil nesse ponto. Um rastro registra a execução completa do atendimento, incluindo chamadas ao modelo, ferramentas utilizadas, guardrails e transferências entre componentes. A documentação da OpenAI sobre avaliação de fluxos de Agentes recomenda usar rastros para identificar problemas no uso de ferramentas, handoffs, roteamento e cumprimento de instruções.

O cliente pode ter recebido uma informação errada porque a base estava incompleta. Também pode ter recebido a mesma informação porque o Agente consultou a ferramenta errada. As respostas são parecidas, mas as soluções são diferentes.

3. Transforme o erro em um caso de teste

Depois de identificar a falha, registre o cenário de maneira estruturada.

Uma ficha simples pode conter:

Nome do teste: cliente solicita alteração de horário depois de confirmar o agendamento.

Contexto inicial: o cliente já possui um agendamento confirmado para sexta-feira às 14h.

Mensagem do usuário: “Na verdade, consigo ir só depois das quatro. Pode mudar?”

Comportamento esperado: o Agente deve consultar a disponibilidade, apresentar horários válidos e alterar o agendamento somente após a confirmação do cliente.

Comportamentos proibidos: afirmar que o horário foi alterado sem executar a ferramenta; criar um segundo agendamento; cancelar o horário original antes da confirmação.

Critérios adicionais: resposta objetiva, confirmação da data e ausência de informações inventadas.

Origem: conversa real identificada na produção.

O resultado esperado não precisa ser uma frase exata. Em aplicações generativas, diferentes respostas podem estar corretas.

Por isso, é mais útil avaliar o comportamento:

* identificou corretamente a intenção;

* consultou a ferramenta necessária;

* utilizou os parâmetros corretos;

* não afirmou que uma ação foi concluída antes da execução;

* pediu confirmação quando necessário;

* produziu uma resposta compatível com o tom da empresa.

A OpenAI descreve uma abordagem semelhante em seu Agente interno de dados. Em vez de comparar apenas se o texto ou o código gerado era idêntico à referência, o sistema também comparava o resultado produzido. Assim, soluções diferentes podiam ser aceitas quando chegavam ao mesmo resultado correto. Os testes eram executados continuamente para detectar regressões durante o desenvolvimento.

4. Escolha como o teste será avaliado

Nem todos os critérios precisam ser avaliados da mesma forma.

A Anthropic divide os avaliadores de Agentes em três grupos principais: avaliadores baseados em código, avaliadores baseados em modelos e avaliadores humanos. Cada um oferece vantagens diferentes.

#### Avaliação baseada em regras ou código

É adequada para condições objetivas:

* a ferramenta correta foi utilizada;

* um campo obrigatório foi preenchido;

* o preço informado corresponde ao cadastro;

* o atendimento foi transferido;

* determinada expressão proibida apareceu;

* o agendamento foi salvo no banco;

* a conversa terminou dentro do limite estabelecido.

Esses testes são rápidos, baratos e repetíveis. Entretanto, podem se tornar rígidos demais quando várias respostas diferentes são aceitáveis.

#### Avaliação baseada em outro modelo

Um modelo pode avaliar critérios que exigem interpretação:

* a resposta foi clara;

* o Agente demonstrou compreensão do problema;

* a explicação estava fundamentada nas informações disponíveis;

* o tom foi adequado;

* a pergunta seguinte ajudou a avançar o atendimento;

* o Agente pressionou o cliente de maneira inadequada.

Para isso, o avaliador precisa receber uma rubrica específica. “Avalie se a resposta está boa” é um critério fraco. “A resposta deve explicar o próximo passo, não inventar disponibilidade e não afirmar que o agendamento foi concluído” é muito mais verificável.

A documentação da Anthropic sobre critérios de sucesso e avaliações recomenda escolher o método mais rápido e confiável para cada critério e usar rubricas detalhadas quando o julgamento depende de outro modelo.

#### Avaliação humana

A revisão humana continua necessária em casos subjetivos, decisões importantes e calibração dos avaliadores automáticos.

O objetivo não é fazer com que uma pessoa avalie todas as execuções para sempre. A revisão pode ser concentrada em amostras, cenários de alto risco, resultados duvidosos e novos tipos de falha.

Os julgamentos humanos também servem para verificar se o avaliador automatizado está atribuindo notas coerentes. Essa calibração é especialmente importante quando os critérios envolvem nuance, contexto comercial ou riscos para o cliente.

Em operações com maior impacto, vale definir com clareza quando o Agente pode agir e quando precisa de aprovação humana.

5. Avalie o resultado e o caminho percorrido

Um Agente pode chegar à resposta correta pelo caminho errado.

Imagine que ele informe corretamente o preço de um serviço, mas não consulte a fonte oficial. Naquela execução, o valor estava certo porque apareceu em uma mensagem antiga do contexto. Depois que o preço for alterado, o mesmo comportamento poderá gerar uma resposta desatualizada.

Por isso, uma boa avaliação observa duas dimensões.

Resultado: o objetivo final foi alcançado?

Trajeto: o Agente utilizou as informações, ferramentas e regras corretas?

Em um atendimento comercial, o teste pode verificar se o lead foi qualificado e se o Agente fez as perguntas necessárias antes de apresentar uma proposta.

Em um agendamento, pode verificar se o compromisso foi criado e se a disponibilidade foi consultada antes da confirmação.

Em um atendimento de suporte, pode verificar se o problema foi resolvido, quantas interações foram necessárias e se o tom permaneceu apropriado.

O artigo Demystifying evals for AI agents, da Anthropic, recomenda combinar a verificação do estado final com critérios sobre o percurso, a qualidade da interação e o uso correto de ferramentas.

6. Execute os testes antes de publicar alterações

Sempre que houver uma mudança relevante, a suíte de avaliações deve ser executada novamente.

Isso inclui alterações em:

* prompt;

* modelo;

* temperatura ou configurações;

* base de conhecimento;

* ferramentas;

* descrição das ferramentas;

* regras de roteamento;

* memória;

* guardrails;

* integrações;

* estrutura de subagentes.

O objetivo não é apenas confirmar se o novo problema foi resolvido. É verificar se capacidades anteriores foram preservadas.

Uma versão pode melhorar a qualificação comercial e piorar a objetividade. Pode reduzir respostas inventadas, mas começar a encaminhar conversas demais para humanos. Pode utilizar ferramentas com mais frequência, mas aumentar o custo e a duração dos atendimentos.

Sem uma suíte de regressão, essas trocas ficam invisíveis.

O ciclo de avaliação apresentado no OpenAI Cookbook parte da análise qualitativa das falhas, mede sua frequência e orienta melhorias específicas. Depois da alteração, o sistema é medido novamente. Quando novas falhas aparecem, o ciclo recomeça.

Esse processo amplia o que a empresa já deveria fazer ao testar um Agente IA antes do atendimento real. A diferença é que os testes não terminam no lançamento. Eles acompanham toda a vida do sistema.

7. Continue alimentando a base com produção

Uma suíte de testes nunca está definitivamente pronta.

Os usuários mudam, os produtos mudam, campanhas atraem públicos diferentes e novas exceções aparecem. O próprio comportamento do sistema pode variar quando modelos ou componentes são atualizados.

Por isso, a produção deve continuar alimentando as avaliações.

Um ciclo operacional simples pode funcionar assim:

Diariamente: sinalizar conversas com transferências, falhas de ferramentas, avaliações negativas ou abandono.

Semanalmente: revisar uma amostra, classificar falhas e selecionar novos casos de teste.

Antes de cada alteração: executar a suíte de regressão.

Depois da publicação: acompanhar os indicadores afetados e revisar uma amostra das novas conversas.

Mensalmente: analisar quais falhas mais se repetem, quais testes perderam relevância e quais capacidades precisam ser exploradas.

Com o tempo, a empresa deixa de depender apenas da memória de quem acompanha o Agente. Os problemas descobertos passam a compor uma base organizada de conhecimento sobre como o sistema deve se comportar.

Quais métricas acompanhar

Uma nota geral pode ser útil, mas raramente explica o que precisa ser melhorado.

O ideal é separar o desempenho por capacidade ou etapa do atendimento. Alguns exemplos são:

* precisão na identificação da intenção;

* taxa de uso correto de ferramentas;

* taxa de conclusão da tarefa;

* frequência de informações não fundamentadas;

* precisão das respostas baseadas em conhecimento;

* respeito às regras de negócio;

* taxa de encaminhamento correto;

* quantidade média de turnos;

* custo médio por conversa;

* latência;

* avaliação de clareza e tom;

* taxa de aprovação humana;

* desempenho por tipo de solicitação.

Essas métricas precisam ser observadas em conjunto.

Uma redução na quantidade de turnos pode parecer positiva, mas não se o Agente estiver encerrando atendimentos sem resolver o problema. Uma taxa baixa de encaminhamento humano pode indicar autonomia ou resistência inadequada em transferir casos complexos.

A métrica precisa representar o resultado desejado pela operação. O post sobre como medir se um Agente IA está funcionando aprofunda essa relação entre qualidade, resultado operacional, custo e experiência do cliente.

Erros comuns ao implementar avaliações

O primeiro erro é testar apenas exemplos fáceis. A base precisa representar a distribuição real das conversas, incluindo casos frequentes, extremos e adversariais.

O segundo é criar um teste para cada frase específica, sem identificar o padrão por trás do erro. Dez conversas diferentes podem revelar a mesma falha de roteamento. Nesse caso, elas podem formar uma categoria de avaliação, em vez de produzir dez regras desconectadas no prompt.

O terceiro é avaliar apenas a resposta final. Ferramentas utilizadas, parâmetros enviados, transferências, dados recuperados e alterações no estado do sistema também fazem parte do comportamento do Agente.

O quarto é automatizar tudo cedo demais. Antes de criar um avaliador, a equipe precisa compreender a falha e definir o que considera correto. Caso contrário, apenas automatizará um critério mal formulado.

O quinto é alterar vários componentes ao mesmo tempo. Quando prompt, modelo, ferramenta e base são modificados juntos, torna-se difícil saber o que causou a melhora ou a regressão.

O sexto é manter os testes apenas com a equipe técnica. Especialistas da operação, vendas, suporte e atendimento conhecem exceções e critérios que nem sempre são visíveis para quem desenvolve o sistema.

Um processo que pode começar com vinte testes

Uma empresa não precisa ter centenas de avaliações no primeiro mês.

Pode começar com vinte conversas importantes:

* cinco atendimentos bem-sucedidos que não podem regredir;

* cinco falhas recorrentes;

* cinco casos de uso de ferramentas;

* cinco situações de exceção ou encaminhamento humano.

Para cada uma, deve definir o contexto, o resultado esperado, os comportamentos proibidos e a forma de avaliação.

Depois, basta executar esses cenários antes das alterações importantes e acrescentar novos testes conforme a produção revelar comportamentos relevantes.

O valor da avaliação não está apenas na quantidade de casos. Está na disciplina de transformar descobertas em proteção permanente contra regressões.

A memória operacional do seu Agente

Um Agente IA não melhora simplesmente porque seu prompt ficou maior.

Ele melhora quando a empresa consegue identificar falhas, compreender suas causas, medir comportamentos e verificar se cada mudança produziu uma evolução real.

As conversas de produção mostram onde o sistema encontra dificuldades. Os rastros revelam como ele tomou suas decisões. As avaliações transformam essas descobertas em testes. A revisão humana mantém os critérios conectados à realidade da operação.

Esse ciclo cria uma forma de memória que não depende do modelo lembrar o que aconteceu. A própria empresa registra os comportamentos que precisa preservar e as falhas que não aceita repetir.

Antes de alterar novamente o prompt, transforme o erro encontrado em um teste que possa ser repetido.