Benchmark interno para agentes de IA: como criar seu conjunto de testes

Um benchmark interno para agentes de IA é um conjunto fixo de tarefas reais do seu negócio, cada uma com uma definição escrita de resultado bom, que você executa de novo sempre que o modelo, os prompts, as ferramentas ou as permissões mudam. Ele permite julgar um modelo mais novo pelo trabalho que você de fato precisa que seja feito, e não por rankings públicos montados com tarefas que você nunca escolheu. Você o constrói a partir de trabalhos que sua equipe já fez e sabe avaliar, e depois mantém sob revisão.

Principais pontos

• Benchmarks públicos medem capacidade geral. Seu benchmark mede se um agente conclui o seu trabalho corretamente e dentro das suas regras.
• Comece por tarefas que sua equipe já concluiu, usando registros que mostrem como era um bom resultado.
• Escreva as regras de aprovação antes de o agente rodar, e separe falhas graves de diferenças de qualidade.
• Inclua casos em que o comportamento certo é parar, perguntar ou passar a tarefa para uma pessoa.
• Rode o mesmo conjunto a cada mudança de modelo, prompt, ferramenta ou permissão, e registre cada execução.

Por que notas públicas não respondem sua pergunta

Lançamentos de modelos chegam com tabelas de resultados em raciocínio geral, programação e testes de conhecimento. Esses números ajudam a comparar fornecedores em um nível alto, mas não dizem se um agente vai ler corretamente os e-mails de fornecedores, respeitar os limites de reembolso ou perceber quando um cadastro de cliente contradiz o contrato. Uma nota maior em um teste de terceiros pode conviver com uma piora justamente no fluxo do qual a sua operação depende.

O NIST AI Risk Management Framework trata a medição como uma atividade contínua, ligada ao contexto em que o sistema é usado, e não como um certificado único. Para um líder de operações, isso vira uma pergunta prática: o que notaríamos em uma segunda-feira de manhã se este agente piorasse? O seu benchmark interno é o instrumento que responde a essa pergunta.

Escolha tarefas com peso real

Comece pela lista de tarefas que o agente deve assumir e teste cada candidata com quatro perguntas. Com que frequência ela acontece? Quanto custa um erro? Duas pessoas revisoras concordariam rapidamente sobre a resposta certa? A resposta depende dos seus registros, documentos ou regras, e não só de conhecimento geral? Tarefas que pontuam alto em frequência e custo de erro entram primeiro no conjunto, mesmo quando parecem rotineiras.

• Frequência: a tarefa acontece toda semana, e não de vez em quando.
• Custo do erro: uma falha gera reclamação, problema de pagamento, questão de conformidade ou retrabalho.
• Resposta verificável: pessoas treinadas concordariam sobre se o resultado foi aprovado.
• Dependência de contexto: a resposta certa depende dos seus sistemas, políticas ou canais.
• Cobertura: o conjunto inclui casos comuns, entradas bagunçadas e alguns casos de borda já conhecidos.

A melhor fonte é uma pasta com trabalhos anteriores cujo resultado já é conhecido, como chamados bem resolvidos, pedidos expedidos corretamente ou orçamentos aceitos. Trabalho antigo oferece uma referência confiável sem exigir que alguém invente exemplos.

Transforme cada tarefa em um caso que você possa repetir

Um caso é um teste único com tudo o que é necessário para executá-lo outra vez. Guarde a entrada exatamente como o agente a receberia, o contexto que ele pode consultar, as ferramentas que pode chamar, o resultado esperado e a regra de aprovação. Quando a fonte contém dados pessoais, anonimize ou substitua por registros sintéticos que mantenham a mesma estrutura e as mesmas condições de borda. Cada registro de caso deve conter:

• Um identificador do caso e a família da tarefa, para que os resultados possam ser agrupados e comparados.
• A entrada como foi recebida, incluindo anexos e formatação imperfeita.
• O contexto que o agente pode usar, como a versão da política ou um retrato do cadastro do cliente naquele momento.
• As ferramentas que ele pode chamar e a aprovação que uma pessoa precisa dar antes de qualquer ação.
• O resultado esperado, escrito em linguagem simples, com os valores exatos registrados quando houver.
• A regra de aprovação e o nome da pessoa responsável pelo caso.

Para a maioria das equipes, de vinte a quarenta casos por família de tarefa é um ponto de partida razoável. Isso é suficiente para revelar padrões sem transformar o benchmark em um projeto à parte. Guias de avaliação de fornecedores de modelos, como o guia de evals da OpenAI, descrevem a mesma estrutura básica: um conjunto de entradas, um método para avaliar as saídas e uma execução que pode ser repetida nas mesmas condições. Para um passo a passo sobre o próprio conjunto de dados, veja como montar um conjunto de testes de referência para seu fluxo.

Escreva critérios de aprovação que outra pessoa consiga aplicar

Um critério como a resposta deve ser boa gera discussões, não medições. Divida os critérios em duas camadas. A primeira são as barreiras obrigatórias: resultados que sempre reprovam o caso, como enviar mensagem para o destinatário errado, executar uma ação sem a aprovação exigida, inventar um valor que não está na fonte ou ignorar uma instrução para parar. A segunda é a qualidade graduada: completude, tom, uso do modelo correto e se o resumo é útil para quem vai ler.

Mantenha a camada graduada simples. Uma escala de três níveves por dimensão costuma bastar para que uma equipe de operações concorde e reutilize os critérios. A documentação da Anthropic sobre avaliação de agentes aponta para avaliar o que o agente fez no ambiente, e não apenas o que ele disse. Na prática, isso significa verificar se o pedido existe no sistema com as linhas certas, e não se o agente informou que o pedido foi criado.

Registre quem avaliou cada caso e por quê. Quando duas pessoas revisoras discordam sobre um caso, a regra provavelmente estava pouco clara, então reescreva a regra antes de rodar qualquer coisa de novo.

Inclua os casos em que a resposta certa é parar

Muitas falhas de agentes não são respostas erradas, mas persistência errada. O agente insiste, chuta um dado que falta ou segue uma instrução conflitante sem sinalizar. Adicione casos em que o comportamento correto é perguntar, pausar ou passar o assunto para uma pessoa. Exemplos incluem um pedido de reembolso acima do limite aprovado, um contrato sem o bloco de assinatura ou dois registros que divergem sobre o endereço de entrega.

Conte esses casos como aprovados apenas quando o agente parar no ponto certo e entregar contexto suficiente para que a revisora decida sem ler todo o histórico. A qualidade do escalonamento faz parte da capacidade, e um benchmark que premia a conclusão confiante de tudo premiará o comportamento errado. Para o formato de passagem, veja escalonamento humano em falhas de agentes de IA, que entrega a decisão necessária.

Rode a linha de base e depois compare o candidato

O benchmark só faz sentido quando você compara execuções nas mesmas condições. Siga esta sequência sempre que avaliar uma mudança:

• Congele a configuração atual: versão do modelo, prompt, lista de ferramentas, permissões e fontes de memória.
• Rode o conjunto completo nessa configuração e registre cada resultado, incluindo as barreiras obrigatórias.
• Mude uma coisa por vez, como um modelo novo ou uma descrição de ferramenta revisada.
• Rode os mesmos casos com as mesmas regras de avaliação e, sempre que possível, com as mesmas pessoas revisoras.
• Compare os resultados caso a caso, e não apenas pela média, e leia as regressões antes das melhorias.
• Decida se adota a mudança, se a ajusta ou se mantém a configuração atual.

Exemplo ilustrativo: uma distribuidora de pequeno porte testa um modelo mais novo para o seu agente de confirmação de pedidos. O resultado geral parece melhor, mas uma família de tarefas, pedidos com envios fracionados, passa a falhar em uma barreira obrigatória porque o agente envia a confirmação antes de o estoque ser reservado. A equipe mantém a configuração atual para essa família, reescreve a instrução da ferramenta e roda apenas essa família depois da correção. A média escondeu a regressão, e é por isso que os resultados por caso importam. Para a decisão de adotar, ajustar ou reverter, veja o que fazer quando o modelo de IA muda: adotar, ajustar ou reverter.

Mantenha o conjunto atualizado e defina quem é o responsável

Um benchmark perde valor quando o negócio muda e os casos não acompanham. Quando uma política é revisada, um fornecedor muda de formato ou a equipe lança uma nova linha de produtos, revise os casos afetados e aposente aqueles que não refletem mais o trabalho real. Mantenha uma nota curta sobre cada alteração, para que futuras revisoras entendam por que o resultado esperado mudou. Entre as execuções formais, amostre semanalmente respostas reais, para que problemas de qualidade apareçam antes de chegarem ao benchmark. Um método prático para essa amostragem está descrito em como amostrar respostas de agentes de IA para checar qualidade toda semana.

A abordagem gerenciada da Be Human trata o benchmark como parte da operação, e não como um projeto pontual. Na primeira etapa, o papel útil, a memória e as ferramentas necessárias, os limites de aprovação e o critério de sucesso são definidos junto com o dono do negócio, e tarefas reais desse papel viram os casos iniciais. Na operação gerenciada, o mesmo conjunto é executado novamente quando modelos, prompts, integrações ou permissões mudam, as falhas são registradas com detalhes suficientes para rastreá-las e os casos são revisados conforme os processos evoluem. O dono do negócio mantém a decisão de adotar, ajustar ou reverter uma mudança.

Se você não tem certeza de qual tarefa deve sustentar o primeiro benchmark, o diagnóstico gratuito de IA da Be Human pode ajudar a identificar a primeira tarefa que vale entregar a um agente.

Perguntas frequentes

Quantas tarefas um benchmark interno deve incluir? Comece com uma ou duas famílias de tarefas que mais importam, com de vinte a quarenta casos cada, em vez de um conjunto amplo que ninguém tem tempo de revisar. Acrescente novas famílias só depois que o primeiro conjunto estiver estável e a equipe confiar nas avaliações. Coleções maiores se tornam úteis mais tarde, mas são mais difíceis de manter precisas.

Quem deve avaliar os resultados? A pessoa dona do processo deve definir as regras de aprovação, e pelo menos outra pessoa treinada deve revisar uma amostra das avaliações para mantê-las consistentes. Quando a verificação é objetiva, como saber se um campo foi preenchido com o valor correto, um script pode fazê-la. Julgamentos sobre tom e utilidade ainda exigem uma pessoa.

Podemos usar dados reais de clientes no conjunto de testes? Apenas quando as regras de dados da sua empresa permitirem, e com o mínimo de informação pessoal necessária para executar o caso. Anonimize nomes, dados de contato e identificadores, ou crie registros sintéticos que mantenham a mesma estrutura e as mesmas condições de borda. Guarde o conjunto com os mesmos controles de acesso que se aplicam aos sistemas de origem.

Com que frequência devemos rodar o benchmark? Rode o conjunto completo antes de qualquer mudança que possa alterar o comportamento, como uma atualização de modelo, uma nova ferramenta, um prompt revisado ou uma mudança de permissão, e rode uma amostra menor em um cronograma regular para detectar desvios. O ritmo ideal depende de quão frequentemente seus sistemas mudam. Mantenha um registro curto de cada execução para que você possa explicar depois por que uma decisão foi tomada.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.