Raft mostra como as empresas podem avaliar agentes de IA antes de implementar em fluxos de trabalho

Raft lançou uma análise prática de como as empresas podem verificar a confiabilidade de agentes de IA antes de confiar-lhes processos de negócios reais. A ideia principal do artigo é simples: um agente não pode ser confiado com base em uma demonstração ou taxa média de sucesso — ele precisa ser executado regularmente através de evals com critérios claros.

Por que há pouca confiança

Conforme os sistemas de agentes transitam de experimentos para cenários de trabalho, o negócio enfrenta uma pergunta racional: o que fazer se o agente comete erros, viola regras ou começa a se comportar de forma estranha. Com um humano, você pode analisar o incidente, mudar a motivação e introduzir controles. Com IA, isso não funciona.

Um modelo não possui incentivos inerentes para se comportar "corretamente", portanto a confiança nele não pode ser construída em sentimentos, promessas de fornecedor ou um único piloto bem-sucedido. Os autores propõem ver a confiança como repetibilidade de resultados. Se um sistema recebe consistentemente dados de entrada similares e produz reliamente o resultado esperado, ele pode ser confiado com essa classe de tarefas.

Se toda ação precisa de verificação manual, o valor da automação desaparece rapidamente. Portanto, evals aqui atuam não como análise adicional, mas como mecanismo básico de liberação de um agente para trabalho.

Como construir um eval set

O ponto de partida é um ground truth set: uma coleção de casos reais ou o mais próximo possível da realidade, onde dados de entrada estão ligados ao resultado esperado. Normalmente tal conjunto é compilado a partir de tarefas históricas que a equipe já processou manualmente. O artigo enfatiza especificamente que evals não requerem milhares de exemplos como o fine-tuning requer. O que importa mais é que cada caso seja inequívoco: dois especialistas independentes devem responder da mesma forma se o agente passou na verificação ou não. Um eval set típico consiste em várias camadas:

• tarefas com dados de entrada específicos e critérios de sucesso
• execuções de teste do agente com resultados finais
• um ou mais graders para diferentes aspectos de qualidade
• transcrição de etapas: chamadas de ferramentas, ações intermediárias e lógica de roteamento

Como exemplo, Raft descreve um agente de suporte de e-commerce que processa devoluções. Um caso testa uma devolução simples dentro de 30 dias, outro testa uma rejeição para uma solicitação fora da política, um terceiro testa uma situação ambígua onde você não pode nem automaticamente reembolsar nem simplesmente rejeitar sem esclarecimento. Este design mostra algo importante: você precisa avaliar não apenas a resposta final, mas também o comportamento ao longo do caminho até ela.

Às vezes o melhor resultado não é uma ação, mas escalação correta para um humano. Para as próprias verificações, três abordagens podem ser misturadas. Graders determinísticos funcionam onde sinais precisos importam, como valores de reembolso ou invocações de ferramentas.

Juízes de LLM são úteis para avaliar tom, completude e clareza da resposta. Humanos são necessários no início para coletar dados de referência e calibrar avaliadores automatizados, caso contrário o sistema rapidamente começará a medir o que é conveniente em vez do que realmente importa para o negócio.

Que métricas observar

Uma ênfase separada no artigo é o fato de que sistemas de agentes são não-determinísticos. Portanto, verificar rigorosamente cada etapa não faz sentido: o mesmo bom resultado pode ser alcançado através de diferentes caminhos. 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 questões ao mesmo tempo: o resultado está correto e o caminho até ele era razoável? Taxa de sucesso de 95% parece ótima — até que os erros sejam false positives. É por isso que apenas pass rate é insuficiente.

Para decisões binárias, é útil observar confusion matrix, precision, recall e F1, porque diferentes tipos de erro custam ao negócio de formas diferentes. Um agente que aprova devoluções muito facilmente cria uma categoria de risco; um agente que massivamente rejeita solicitações legítimas cria uma completamente diferente. Além disso, os autores lembram sobre armadilhas típicas: lei de Goodhart, deterioração de eval set e ilusão de um dashboard "verde", quando a métrica parece boa mas reclamações reais de usuários crescem.

O que significa

Para empresas que desejam implantar agentes de IA em suporte, operações ou desenvolvimento, a conclusão principal é uma: primeiro você precisa construir um sistema de verificação, e apenas depois escalar automação. Os times vencedores não são aqueles cujo agente parece mais inteligente em uma demonstração, mas aqueles que entendem o custo de seus erros, conseguem medir qualidade contra cenários e regularmente atualizam evals junto com o produto.