Raft mostra como avaliar agentes de IA antes de colocá-los em fluxos de trabalho

A Raft publicou uma análise prática de como as empresas podem verificar a confiabilidade de agentes de IA antes de confiar a eles processos de negócio reais. A ideia principal do artigo é simples: não se deve acreditar em um agente por causa de uma demonstração ou de uma taxa média de sucesso; é preciso submetê-lo regularmente a evals com critérios claros.

Por que confiança não basta

À medida que sistemas baseados em agentes saem dos experimentos e vão para cenários de trabalho, as empresas se fazem uma pergunta perfeitamente racional: o que fazer se o agente errar, violar regras ou começar a agir de forma estranha? Com uma pessoa, dá para analisar o incidente, mudar a motivação e introduzir controles. Com IA, isso não funciona. O modelo não tem incentivos próprios para se comportar "corretamente"; por isso, a confiança nele não pode se apoiar em impressões, promessas do fornecedor ou um único piloto bem-sucedido.

Os autores sugerem encarar a confiança como repetibilidade do resultado. Se o sistema recebe muitas vezes dados de entrada parecidos e entrega de forma estável o resultado esperado, é possível atribuir a ele essa classe de tarefas. Se, por outro lado, cada ação precisa ser reverificada manualmente, o valor da automação desaparece rapidamente. Por isso, os evals aqui não são análise adicional, mas o mecanismo básico de admissão do agente ao trabalho.

Como montar um eval set

O ponto de partida é o ground truth set: um conjunto de casos reais ou o mais próximos possível da realidade, em que os dados de entrada se ligam ao resultado esperado. Normalmente ele é montado a partir de tarefas históricas que a equipe já tratou manualmente. O artigo destaca que, para evals, não são necessários milhares de exemplos, como no ajuste fino. Mais importante é que cada caso seja inequívoco: dois especialistas independentes devem responder da mesma forma se o agente passou ou não no teste.

Um eval set típico tem várias camadas:

• tarefas com dados de entrada específicos e um critério de sucesso
• uma execução de teste do agente com o resultado final
• um ou mais graders para diferentes aspectos da qualidade
• uma transcrição dos passos: chamadas de ferramentas, ações intermediárias e a lógica do percurso

Como exemplo, a Raft descreve um agente de suporte de uma loja online que processa devoluções. Um caso testa uma devolução simples dentro de 30 dias; outro, a recusa de um pedido fora da política; e um terceiro, uma situação ambígua em que não se pode nem devolver o dinheiro automaticamente nem simplesmente recusar sem esclarecimentos. Esse desenho mostra algo importante: é preciso avaliar não só a resposta final, mas também o comportamento no caminho até ela. Às vezes o melhor resultado não é uma ação, e sim uma escalação correta para um humano.

Para as verificações em si, dá para combinar três abordagens. Graders determinísticos servem onde importam sinais exatos, como o valor do reembolso ou a chamada da ferramenta certa. Juízes LLM são úteis para avaliar tom, completude e clareza da resposta. Pessoas são necessárias no início, para reunir dados de referência e calibrar os avaliadores automáticos; do contrário, o sistema logo passa a medir o que é conveniente, e não o que realmente importa para o negócio.

Quais métricas acompanhar

O artigo dá ênfase especial ao fato de que sistemas de agentes não são determinísticos. Por isso, checar rigidamente cada passo não faz sentido: o mesmo bom resultado pode ser alcançado por caminhos diferentes. Mas o caminho ainda importa, porque consome tempo, tokens e acesso a ferramentas, e também pode violar políticas internas. Um bom eval deve responder a duas perguntas ao mesmo tempo: o resultado está correto e o caminho até ele foi razoável?

95% de aprovação parece ótimo, até que os erros estejam nos falsos positivos.

É por isso que a taxa de aprovação (pass rate) isolada não basta. Para decisões binárias, vale olhar a matriz de confusão, precision, recall e F1, porque diferentes tipos de erro custam de forma diferente ao negócio. Um agente que aprova devoluções com facilidade demais cria uma categoria de risco; um que rejeita em massa pedidos legítimos cria outra, bem diferente.

Além disso, os autores lembram armadilhas típicas: a lei de Goodhart, a desatualização do eval set e a ilusão do painel "verde", quando a métrica parece normal enquanto as reclamações reais dos usuários aumentam.

O que isso significa

Para empresas que querem implantar agentes de IA em suporte, operações ou desenvolvimento, a principal conclusão é uma só: primeiro é preciso construir o sistema de verificação e só depois escalar a automação. Vencem não as equipes cujo agente parece mais inteligente na demo, mas as que entendem o custo de seus erros, sabem medir a qualidade por cenário e atualizam regularmente os evals junto com o produto.