Pare de rodar novos benchmarks de modelos e comece a observar seu agente tentando cancelar uma assinatura. O abismo entre essas duas atividades é onde os sistemas de produção morrem. Um teste de turno único pode dizer se uma resposta soa agradável. Ele não pode dizer se o agente acabou de reembolsar o cliente errado, entrou em um loop de quatorze vezes contra uma API de calendário ou decidiu ignorar completamente a verificação de fraude. O texto é a coisa menos perigosa que um agente produz. Os riscos reais se escondem nas ferramentas que ele toca, nos dados que ele altera e nos momentos em que ele deveria ter pedido ajuda, mas continuou seguindo em frente.
Por que benchmarks de texto falham em produção
Pontuações altas em benchmarks padrão tornaram-se uma forma enganosa de conforto. Um agente que escreve prosa elegante ainda pode ser um risco operacional. Quando seu sistema agenda compromissos, edita registros de banco de dados ou abre tickets de suporte, o texto gerado é apenas a superfície visível do fluxo de trabalho. Por baixo, o agente está tomando decisões concretas sobre qual endpoint acessar, qual payload enviar e quando parar. Ele pode liderar um ranking de compreensão de leitura enquanto lhe custa dinheiro ao agendar recursos em duplicidade, alterar a linha errada ou vazar estados sensíveis em um arquivo de log. Você precisa verificar a mecânica do trabalho, não apenas o polimento da saída. Se um agente consegue pontuar bem em um teste de QA offline e ainda assim falhar em seu fluxo de trabalho por entrar em loop ou usar incorretamente uma ferramenta, sua avaliação está olhando para os sinais errados.
Mapeando as Cinco Dependências
A equipe da Van Data Team começa cada avaliação mapeando cinco pontos de controle específicos. Isso muda a pergunta inteiramente. Você para de perguntar se um modelo é mais inteligente que outro. Você começa a perguntar se o agente consegue realmente concluir uma tarefa de produção sob suas restrições reais.
Resultados de negócio. Defina o que "concluído" significa em termos de dinheiro e impacto no cliente. Uma tarefa não está completa apenas porque o agente emitiu um resumo. Ela está completa quando o registro de inventário está correto, o compromisso está confirmado e o cliente recebeu um número de rastreamento válido.
Estado mutável. Saiba exatamente o que o agente tem permissão para alterar. Quais tabelas, quais status, quais sinalizações de conta? Se o agente pode emitir reembolsos, reagendar tarefas ou atualizar endereços de cobrança, você precisa inventariar cada campo que ele toca.
Permissões de ferramentas. Seja explícito sobre quais endpoints de API e funções estão no escopo. Um agente com acesso a uma ferramenta de busca, uma ferramenta de escrita e uma ferramenta de notificação irá misturá-las se os limites forem vagos. Mapeie cada permissão a uma necessidade operacional específica.
Recuperação de falhas. Decida o que acontece quando a API de calendário expira, retorna um erro 500 ou devolve um JSON malformado. O agente não deve entrar em pânico, alucinar uma mensagem de sucesso ou tentar repetidamente para sempre. Ele precisa de um caminho de fallback claro.
Portões de revisão humana. Identifique os momentos em que uma pessoa deve dar o aval antes que o agente prossiga. Isso não é um sinal de fraqueza na automação. É uma válvula de segurança para mudanças de alto impacto e uma fonte de rótulos de ground-truth para suas rubricas.
Como é um plano de avaliação real
Uma vez mapeadas as dependências, você precisa de um plano de avaliação que corresponda à complexidade da produção. Métricas de apresentações de slides não ajudarão você aqui.
Construa conjuntos de testes a partir de falhas reais de produção, não de bancos de perguntas sintéticas. Se o seu agente falhou na última terça-feira ao confundir dois SKUs semelhantes, essa confusão exata deve ser um caso de teste permanente. Sua suíte de avaliação deve crescer toda vez que um incidente lhe ensinar algo novo.
Escreva rubricas que definam a conclusão bem-sucedida em termos operacionais. Critérios vagos como "útil" ou "preciso" são inúteis. Uma rubrica útil estabelece que uma tarefa de reembolso só é bem-sucedida se o ID do pagamento original foi referenciado, o valor corresponde à solicitação, um e-mail de confirmação foi enfileirado e o ID da transação foi registrado.
Defina especificações de rastreamento (trace specs) para chamadas de ferramentas e retentativas. Você precisa de observabilidade sobre o que o agente planejou, o que ele realmente chamou, quantas vezes ele tentou novamente e se a estratégia de retentativa foi apropriada. Um rastreamento sem granularidade ao nível da ferramenta é apenas uma história bonita.
Estabeleça políticas para quando alertar um humano. O agente deve conhecer seus próprios limites. Se uma solicitação exceder um limite de valor, referenciar uma conta VIP ou encontrar um estado que nunca viu antes, ele deve escalar o problema em vez de tentar adivinhar.
Instale gates de lançamento para bloquear atualizações ruins de modelos. Um novo modelo só é uma atualização se melhorar seus resultados específicos. Se ele alucinar argumentos de ferramentas com mais frequência, aumentar a latência ou introduzir novos riscos de segurança, ele não deve ser lançado. O gate mantém a produção estável, mesmo quando o fornecedor do modelo base lança uma nova versão.
Avaliação em Tempo de Execução: Observando o Agente Trabalhar
A Anthropic tem impulsionado a indústria a ir além dos testes offline em direção à avaliação em tempo de execução (runtime grading). Em vez de julgar uma transcrição após o ocorrido, a avaliação em tempo de execução permite que um sistema julgue o trabalho do agente enquanto a tarefa ainda está em andamento. Isso cria uma chance de capturar erros antes que eles se tornem problemas reais.
Adicionar um avaliador custa tokens e latência. Você não pode se dar ao luxo de avaliar cada pequeno passo. O posicionamento de cada avaliador é uma decisão de design. Coloque-os onde os erros são caros. Os checkpoints mais valiosos ficam logo antes de confirmar uma mudança de estado em um banco de dados, logo antes de processar um pagamento e logo antes de enviar uma mensagem a um cliente. Estes são os momentos em que uma decisão ruim se torna uma ação irreversível.
Cuidado com um ponto cego específico. Se o mesmo modelo realizar o trabalho e também o avaliar, ele pode deixar passar os mesmos erros. O raciocínio que produziu um erro pode facilmente racionalizar esse erro durante a revisão. Para tarefas de alto impacto, mantenha a revisão humana no processo. Deixe que as pessoas validem o próprio julgamento do avaliador, especialmente quando dinheiro ou a confiança do cliente estão em jogo.
O objetivo aqui é o controle operacional. Conecte seus dados de incidentes, suas rubricas de tarefas e seus rastreamentos de tempo de execução em um único ciclo de feedback. Avalie todo o caminho: o plano, o uso de ferramentas, o comportamento de recuperação e o resultado final. Use testes offline para capturar erros conhecidos e reproduzíveis antes do lançamento. Use rastreamentos em tempo de execução para encontrar as novas falhas que você não antecipou. Use a revisão humana para descobrir onde suas rubricas são ingênuas e precisam de ajustes.
Então pergunte a si mesmo: onde você colocaria um avaliador em tempo de execução no seu fluxo de trabalho? Antes de uma chamada de ferramenta, depois de uma chamada de ferramenta ou apenas antes de uma mudança arriscada? A maioria das equipes começa de forma muito ampla, avaliando tudo, e depois para completamente devido ao custo. Comece de forma restrita. Escolha a única ação que mais machucaria se desse errado. Coloque um avaliador lá primeiro.
Comece com um Erro Caro
A avaliação operacional não é um exercício de pesquisa. É uma maneira de dormir melhor depois que o agente estiver no ar. Você não precisa de um framework perfeito no primeiro dia. Você precisa de um fluxo de trabalho único e bem definido, uma rubrica escrita em termos de negócios claros e um avaliador posicionado no momento exato em que um erro se torna caro. Acerte isso e você terá uma base na qual poderá realmente confiar.
Se você quiser se aprofundar na avaliação de agentes e na avaliação em tempo de execução com uma comunidade de profissionais, você pode encontrar a comunidade de aprendizado GyaanSetu em https://t.me/GyaanSetuAi.