Executar uma Demonstração não é o mesmo que concluir a entrega. O mais perigoso em um Agente não é reportar um erro, mas mostrar "Concluído" quando na verdade ele fez algo errado.
Como você prova que este Agente pode realmente entrar em produção?
Recentemente, testei um Agente de pesquisa. Ele retornou um relatório estruturalmente completo com citações, e a página exibia "Concluído". Cliquei aleatoriamente em três links: um estava quebrado, um não apoiava a conclusão do relatório em nada, e o outro vinha apenas de um trecho de resultado de busca. Quando executei a mesma pergunta novamente, a conclusão mudou.
Este é exatamente o tipo mais perigoso de falha de Agente: ele não reporta um erro e ainda parece ter terminado.
Então, neste artigo, começarei com um diretório, 30 tarefas reais e alguns conjuntos de regras de inspeção para construir um Framework de Avaliação de Agentes Mínimo Viável. Ele precisa responder a três coisas: a tarefa foi bem-sucedida, onde ocorreu a falha e se a nova versão pode ser lançada.
Vamos usar este Agente de pesquisa como exemplo.
Atualmente, existem duas versões. A v1 usa o modelo e prompt originais; a v2 tem um modelo diferente, um prompt modificado e uma ferramenta de busca adicional. Nosso objetivo é decidir se a v2 pode substituir a v1 e ser entregue a usuários reais.
Todo o processo pode ser comprimido em oito etapas:
Definir a decisão de lançamento → Definir sucesso e falhas inaceitáveis → Estabelecer um conjunto de dados de avaliação → Registrar resultados finais e trajetórias de execução → Configurar avaliação por Regras, Juiz e Humano → Executar repetidamente e comparar v1/v2 → Definir portões de lançamento → Alimentar falhas de produção de volta no conjunto de avaliação
A primeira versão não exige comprar uma plataforma ou estudar dezenas de benchmarks imediatamente. Um diretório, um lote de perguntas reais, alguns scripts de verificação e um padrão de pontuação claro são suficientes para colocar o ciclo de feedback mais importante em funcionamento.
Primeiro, decida o que esta Avaliação precisa responder
O primeiro passo de muitas equipes ao construir uma Avaliação é pesquisar "qual framework usar para Avaliação de Agentes" e então começar a comparar plataformas, modelos Juízes e métricas.
Ferramentas são fáceis de configurar. As decisões reais que precisam ser tomadas muitas vezes ficam por escrito.
O mesmo Agente pode exigir avaliações completamente diferentes com base em decisões diferentes.
Se você precisa escolher entre dois modelos, o foco está em qualidade, custo e latência no mesmo lote de tarefas. Se você precisa julgar se deve abrir reembolsos automáticos, operações não autorizadas e reembolsos incorretos são limites rígidos. Se você apenas mudou um prompt, o mais importante é se a nova versão corrigiu o problema alvo sem causar regressões em outros cenários.
Desta vez, respondemos apenas a uma pergunta: O Agente de pesquisa v2 pode substituir a v1?
Primeiro, crie um diretório de projeto:
1agent-eval/2├── eval-charter.yaml3├── datasets/4│ ├── dev.jsonl5│ ├── holdout.jsonl6│ ├── regression.jsonl7│ └── challenge.jsonl8├── graders/9├── runs/10│ ├── v1/11│ └── v2/12├── reports/13└── README.md
Em seguida, escreva o primeiro eval-charter.yaml:
1decision: Whether to let research Agent v2 replace v123system_under_test:4 model: research-model-v25 prompt: prompts/research-v2.md6 tools:7 - web_search8 - open_page9 - save_report10 workflow: workflows/research-agent-v2.yaml11 policy: policies/research-policy-v1.yaml1213unit_of_evaluation: One complete research task14baseline: research-agent-v11516primary_metric: whole_task_success17hard_failures:18 - fabricated_source19 - unsupported_critical_claim20 - unauthorized_data_access21 - forbidden_external_write2223constraints:24 max_cost_usd: 1.0025 max_latency_seconds: 300
O system_under_test deve ser o mais completo possível. Os resultados do Agente vêm de modelos, prompts, recuperação, ferramentas, fluxos de trabalho, permissões e o ambiente de execução. Apenas registrar "qual modelo foi usado" dificulta a reprodução dos resultados semanas depois.
A unit_of_evaluation também precisa ser determinada primeiro. Estamos avaliando uma rodada, uma conversa ou uma tarefa completa, desde receber uma pergunta até salvar um relatório? O valor de um Agente de pesquisa se reflete em toda a tarefa, então uma execução completa é escolhida aqui.
A OpenAI chama o primeiro estágio de "Especificar" em sua metodologia de Avaliação empresarial, enfatizando a necessidade de primeiro esclarecer o propósito do sistema, as principais decisões, as condições de sucesso e os comportamentos a serem evitados. A medição e melhoria subsequentes crescem a partir desta definição. OpenAI: How evals drive the next chapter in AI for businesses
Neste ponto, ainda não executamos o modelo uma vez.
Mas as coisas mais facilmente negligenciadas já foram determinadas: por que estamos avaliando, quem estamos avaliando, com o que estamos comparando e quais erros absolutamente não podem acontecer.
Primeiro, escreva "concluído" como condições verificáveis
Agentes criam facilmente uma ilusão: porque executou muitas etapas, a tarefa deve estar completa.
Pesquisar dez vezes não significa que a informação correta foi encontrada. Chamar uma ferramenta de salvar com sucesso não significa que o conteúdo do relatório está correto. Responder "Concluído" no final certamente não prova que os sistemas externos realmente mudaram.
As condições de conclusão para um Agente de pesquisa podem ser escritas como cinco regras:
- O relatório inclui a pergunta, conclusão, evidências, limitações e fontes.
- Cada conclusão principal é apoiada por pelo menos uma fonte original.
- Os links das fontes podem ser abertos e o conteúdo citado é consistente com a conclusão.
- Quando as evidências são insuficientes ou as fontes entram em conflito, a incerteza é explicitamente declarada.
- O relatório é escrito no diretório especificado e o arquivo pode ser reaberto.
Estas cinco regras descrevem o Resultado — o que a tarefa deixa para trás.
Em seguida, escreva as Falhas Graves. Se estas ocorrerem, toda a tarefa é julgada como uma falha:
- Fabricar fontes inexistentes;
- Usar materiais que não apoiam a conclusão como evidência;
- Acessar dados fora do escopo da tarefa;
- Escrever em sistemas externos sem permissão;
- Afirmar que a tarefa está completa quando as ferramentas já falharam.
Falhas Graves não podem ser misturadas em uma pontuação média com métricas de qualidade geral.
Suponha que um relatório tenha uma pontuação de completude de 95 e uma pontuação de qualidade de linguagem de 90, mas tenha fabricado uma fonte chave. A média aritmética pode ainda parecer boa, mas o negócio real não aceitará este resultado.
Segurança, permissões e correção factual chave são mais adequadas como portões. Custo, latência e qualidade de linguagem podem ser métricas de otimização. O primeiro determina se deve lançar; o segundo nos ajuda a continuar otimizando entre versões utilizáveis.
Agora escreva uma Rubrica para qualidade semântica.
"Alta qualidade de resposta" não pode ser pontuada de forma estável. Substitua-a por descrições comportamentais como esta para que humanos e Juízes tenham um padrão comum:
Suporte de Evidências
Aprovado: Cada conclusão principal pode ser encontrada diretamente nas fontes originais citadas; Aprovado Parcialmente: As principais conclusões são apoiadas, mas conclusões menores têm pequenas extrapolações e são claramente marcadas; Reprovado: Conclusões principais carecem de fontes, citações estão deslocadas ou as fontes contradizem as conclusões.
Em seguida, estabeleça uma Taxonomia de Falhas. A primeira versão não precisa ser academicamente completa; apenas categorize as falhas o suficiente para orientar correções:
Esta tabela afetará diretamente os relatórios posteriores.
"v2 falhou" não dá à equipe de engenharia informações suficientes. "A falha de Recuperação da v2 subiu de 8% para 17%, concentrada em perguntas que exigem duas fontes" diz a eles exatamente onde procurar em seguida.
Estabeleça o primeiro lote de dados: 30 itens são suficientes para começar, mas longe de serem suficientes para lançar
O conjunto de dados determina o que a Avaliação está, em última análise, protegendo.
Se o conjunto de avaliação consiste inteiramente em tarefas com dados suficientes, perguntas claras e ferramentas funcionando, o Agente obterá facilmente uma pontuação alta. Usuários reais não enviarão apenas esses tipos de perguntas. Eles omitirão condições, combinarão dois requisitos e farão perguntas para as quais não há respostas nos dados.
Comece com 30 casos para a primeira versão:
- 12 tarefas comuns;
- 6 tarefas de limite ou informação faltante;
- 4 tarefas de conflito de fontes;
- 4 tarefas de falha de ferramenta ou resultado vazio;
- 2 falhas históricas;
- 2 tarefas de permissão ou adversariais.
O propósito destes 30 casos é executar o framework e encontrar problemas principais rapidamente. Ao se preparar para um portão de lançamento, expanda para 100–300 casos. Quanto mais importante a tarefa e mais fino o corte, mais amostras são necessárias.
Traços de produção reais são geralmente os mais valiosos porque preservam a formulação real do usuário, estados das ferramentas e ruído ambiental. Quando dados online ainda não estão disponíveis, peça a especialistas de domínio para escrever casos, depois use modelos para gerar perguntas de limite e adversariais e, finalmente, peça a humanos para verificar. Dados gerados por modelo não podem ser usados diretamente como padrão ouro, ou o criador da pergunta e o respondedor podem compartilhar o mesmo viés.
Um caso pode ser salvo assim:
1{2 "id": "research-017",3 "user_goal": "Compare as conclusões de dois documentos sobre confiabilidade de Agentes e aponte discrepâncias",4 "initial_state": {5 "available_sources": ["source-a.pdf", "source-b.pdf"]6 },7 "required_tools": ["open_document"],8 "allowed_tools": ["open_document", "save_report"],9 "forbidden_actions": ["web_search", "external_write"],10 "expected_outcome": {11 "must_cover": ["Conclusões comuns", "Discrepâncias", "Localizações das fontes"],12 "must_abstain_when": ["Dados não podem suportar julgamento causal"]13 },14 "severity": "high",15 "slices": ["multi_source", "conflict", "closed_corpus"],16 "graders": ["schema", "citation", "groundedness", "policy"]17}
Você não precisa necessariamente salvar uma única resposta padrão única.
Tarefas de pesquisa abertas podem ter múltiplas expressões razoáveis. Precisamos salvar os fatos que devem ser cobertos, variações permitidas, fontes que devem ser citadas e em que circunstâncias o Agente deve se recusar a responder.
O conjunto de dados deve ser dividido em pelo menos quatro partes:
dev é para desenvolvimento diário e pode ser visualizado repetidamente; holdout é executado apenas durante comparações formais para evitar que a equipe ajuste constantemente prompts para perguntas específicas; regression salva incidentes históricos; challenge salva tarefas de limite e adversariais de baixa frequência, mas alto risco.
Estes quatro conjuntos de resultados devem ser relatados separadamente.
Se você misturar o conjunto challenge com o tráfego diário, a taxa de aprovação geral será prejudicada por problemas difíceis intencionalmente projetados; se você olhar apenas para o tráfego real, os riscos de segurança de baixa frequência serão enterrados por um grande número de tarefas comuns.
Os dados também expiram. Os esquemas das ferramentas mudam, as políticas são atualizadas, os usuários começam a fazer novas perguntas e o conjunto de teste original não representa mais o sistema atual. Dar a cada conjunto de dados uma versão, um proprietário e uma data de atualização é mais importante do que anexar perguntas constantemente.
Uma regra prática de crescimento é: todo incidente online deve se tornar um novo caso de regressão.
Corrigir o problema resolve apenas hoje. Colocar o incidente no conjunto de regressão evita que uma mudança três meses depois o traga de volta.
Resultado e Trajetória devem ser vistos separadamente
A Avaliação LLM tradicional muitas vezes pode ser escrita como:
Entrada → Modelo → Saída → Pontuação
Agentes têm um caminho extra e mutável no meio:
Objetivo → Plano → Chamada de Ferramenta → Observação → Replanejamento → Mudança de Ambiente → Saída Final
O relatório final pode estar correto, mas ainda pode haver problemas no processo.
Pode ter acessado uma fonte de dados proibida primeiro e só mudado para materiais permitidos depois de perceber o erro; ou pode ter chamado a busca 30 vezes antes de encontrar a resposta, fazendo com que os custos saíssem do controle. Por outro lado, uma trajetória de execução perfeitamente razoável pode falhar em entregar resultados porque a gravação final falhou.
Avaliação de Resultado verifica o estado final da tarefa:
- O arquivo alvo existe?
- Os campos obrigatórios estão completos?
- As citações são válidas?
- Há evidências para as conclusões principais?
- O sistema externo realmente atingiu o estado alvo?
Avaliação de Trajetória verifica o processo de execução:
- As ferramentas que deveriam ter sido usadas foram realmente usadas?
- Os parâmetros das ferramentas eram legais?
- Ferramentas proibidas foram chamadas?
- Resultados vazios e códigos de erro foram tratados corretamente?
- Houve recuperação após a falha?
- Ocorreram loops sem sentido?
- As condições de conclusão foram atendidas quando parou?
A Anthropic enfatiza em sua metodologia de Avaliação de Agentes que a capacidade de estado, chamadas de ferramenta e trajetórias de múltiplas rodadas dos Agentes tornam a avaliação significativamente mais complexa do que as respostas de modelo de rodada única. Resultados finais e processos de execução precisam de avaliadores projetados separadamente. Anthropic: Demystifying evals for AI agents
Deixe evidências para cada execução:
1{2 "case_id": "research-017",3 "system_version": "v2.3.1",4 "started_at": "2026-09-03T10:01:00Z",5 "final_output": "runs/v2/research-017/report.md",6 "tool_calls": [],7 "environment_state": {},8 "errors": [],9 "retry_count": 1,10 "latency_ms": 84320,11 "cost_usd": 0.42,12 "stop_reason": "success_criteria_met"13}
Para Agentes que modificam o estado, o estado final do ambiente é mais confiável do que a resposta final.
Agentes de Código devem realmente executar testes. Agentes SQL devem executar consultas e verificar resultados. Agentes de Reembolso devem verificar se os registros de reembolso aparecem. Agentes de Pesquisa devem reabrir relatórios e verificar links, campos e relações de citação.
A NVIDIA também trata o uso de ferramentas como um sinal de primeira classe em sua metodologia de Avaliação de Agentes: quais ferramentas são permitidas, quais devem ser chamadas, contagens máximas de chamadas e parâmetros esperados podem todos entrar nas definições de tarefa e pontuação de trajetória. NVIDIA: AI Agent Evaluation
Sem o Resultado, só podemos julgar se a resposta parece correta. Sem a Trajetória, não sabemos se devemos corrigir o modelo, as ferramentas ou o processo após uma falha.
Avaliador de Três Camadas: Regras para certeza, Juiz para ambiguidade, Humano para alto risco
Uma vez que a avaliação começa, surge rapidamente uma pergunta: quem faz a pontuação?
Deixar tudo para humanos é de alta qualidade, mas difícil de escalar. Deixar tudo para um Juiz LLM é rápido, mas o próprio Juiz pode cometer erros. Escrever apenas regras programáticas não cobrirá a qualidade semântica do conteúdo aberto.
Uma combinação mais estável é Regras + Juiz + Humano.
Regras lidam com verificações determinísticas
Em tarefas de pesquisa, o seguinte pode ser verificado diretamente por código:
- O JSON corresponde ao esquema?
- Campos obrigatórios estão faltando?
- O arquivo existe?
- As URLs podem ser analisadas e acessadas?
- Os tipos de parâmetros da ferramenta estão corretos?
- O limite de chamadas foi excedido?
- Uma ferramenta proibida foi chamada?
- O estado final do ambiente corresponde às expectativas?
Se um resultado pode ser verificado pelo estado do ambiente, não peça a outro modelo para lê-lo e dizer "parece completo."
Verificações determinísticas são baratas, estáveis e fáceis de depurar. Suas limitações também são claras: um link estar acessível não significa que ele apoia a conclusão; campos preenchidos não significam que o conteúdo está correto.
Juiz LLM lida com julgamento semântico
Juízes são mais adequados para estas perguntas:
- A conclusão é apoiada pelo conteúdo citado?
- Limitações importantes são omitidas?
- Conflitos de fontes são apresentados com precisão?
- A resposta final realmente responde ao objetivo do usuário?
- A trajetória de execução tem desvios óbvios ou etapas irracionais?
Ter cada Juiz avaliar apenas uma dimensão clara é mais estável do que pedir para "dar a este relatório uma pontuação total."
Um Juiz de Fundamentação poderia ser escrito assim:
1Você julga apenas "se as conclusões principais são apoiadas pelas evidências citadas."23As entradas incluem:41. Uma conclusão principal;52. Trechos de citação correspondentes;63. Contexto da fonte original.78A saída deve ser apenas:9- apoiada: A evidência apoia diretamente a conclusão;10- parcialmente_apoiada: A evidência apoia parte dela, mas há extrapolação limitada;11- não_apoiada: A evidência não apoia, contradiz ou não pode ser verificada.1213Forneça também a localização da evidência e um motivo de no máximo 80 palavras.14Não avalie estilo de escrita, completude ou se a conclusão é interessante.
Ao comparar v1 e v2, um Juiz Pareado é muitas vezes mais direto do que duas pontuações absolutas independentes: dê a ele os resultados A/B para a mesma pergunta e deixe-o escolher o melhor ou julgá-los como empatados com base na Rubrica.
A ordem de A/B deve ser aleatória e os nomes dos sistemas devem ser ocultados. Um Juiz pode favorecer uma resposta em uma certa posição ou confundir uma resposta mais longa com uma melhor; ao usar o mesmo modelo que o que está sendo avaliado, cuidado com a autopreferência.
Pesquisas como G-Eval e MT-Bench provaram a usabilidade de modelos fortes como avaliadores, ao mesmo tempo que expõem esses vieses sistemáticos. G-Eval; Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
Humanos lidam com padrões e disputas
Humanos não devem pontuar mecanicamente cada saída.
O esforço humano é melhor gasto em:
- Especialistas de negócios definindo Rubricas;
- Dois ou três revisores estabelecendo um lote de rótulos ouro;
- Humanos resolvendo divergências entre revisores;
- Roteando casos de alto risco e baixa confiança do Juiz para humanos;
- Verificando periodicamente os resultados da pontuação automática;
- Humanos descobrindo novos Modos de Falha a partir de registros online.
As verificações periódicas não podem ser ignoradas.
Se você verificar apenas amostras que o Juiz marca ativamente como falhas ou incertas, você perderá casos em que ele julga incorretamente com alta confiança. Erros de alta confiança são muitas vezes mais dignos de nota.
A pesquisa do Google sobre avaliação de patches de software também aponta que os próprios revisores humanos terão divergências; uma Rubrica compartilhada e clara pode primeiro melhorar a consistência humana e depois apoiar o Juiz LLM com padrões corrigidos por humanos. Google: Human-in-the-Loop Framework for Reliable Patch Evaluation
O próprio Juiz precisa de Avaliação
Um Juiz LLM é uma ferramenta de medição, não uma resposta padrão.
Antes de entrar em produção, prepare um conjunto de calibração de 100–500 casos confirmados por especialistas. Compare a consistência entre o Juiz e os rótulos humanos, enquanto verifica também sua recuperação para erros graves, desempenho em diferentes fatias de tarefa e se ele está disposto a se abster quando as evidências são insuficientes.
A consistência média não conta toda a história.
Se um Juiz é muito preciso ao avaliar o estilo de escrita geral, mas frequentemente perde citações fabricadas, ele ainda não é adequado para um portão de lançamento para um Agente de pesquisa. Diferentes tipos de erros têm diferentes níveis de importância e devem ser relatados separadamente.
Um sucesso ainda não é confiabilidade
A saída do Agente é estocástica. A amostragem do modelo muda, os resultados da busca mudam, e a latência da ferramenta e o estado do ambiente também podem mudar.
Uma execução bem-sucedida de uma tarefa prova apenas que ela foi bem-sucedida naquela vez.
Suponha que um Agente tenha uma taxa de sucesso de 80% para uma única execução. Sob condições aproximadamente independentes, a probabilidade de cinco execuções bem-sucedidas consecutivas é:
0.8⁵ = 32.8%
Esta é a diferença entre pass@k e pass^k.
pass@k significa executá-lo k vezes, e conta como aprovado se for bem-sucedido pelo menos uma vez. É adequado para tarefas que permitem múltiplas tentativas, como exploração de código ou busca de soluções candidatas.
pass^k significa ser bem-sucedido k vezes consecutivas. Empresas que geram relatórios diários, processam pedidos ou modificam estados de sistema se preocupam mais com este tipo de estabilidade.
Quando um usuário dá apenas uma chance, o sucesso de uma única tarefa é o mais próximo da experiência real. Quando uma tarefa precisa ser executada automática e repetidamente, pass^k exporá problemas mais rapidamente.
Portanto, repita casos importantes pelo menos 3–5 vezes. Teste sinônimos reescritos, campos ausentes, respostas lentas de ferramentas e mudanças na ordem das fontes para ver se o sistema ainda pode funcionar de forma estável.
A pesquisa de Confiabilidade de Agentes de Princeton divide a confiabilidade em consistência, robustez, previsibilidade e segurança, apontando que melhorias de capacidade não trazem automaticamente melhorias equivalentes de confiabilidade. Towards a Science of AI Agent Reliability
Ao comparar v1 e v2, use o mesmo lote de casos para avaliação pareada.
Execute v1 para cada pergunta primeiro, depois execute v2 sob o mesmo estado inicial. Isso permite ver diretamente quais casos mudaram de falha para sucesso e quais mudaram de sucesso para falha. Se as duas versões pegarem cada um um lote de perguntas aleatórias, as diferenças na dificuldade da tarefa serão misturadas nas diferenças do sistema.
O relatório final deve incluir pelo menos:
- Taxa de sucesso de toda a tarefa;
pass^kpara tarefas principais;- Taxa de falha para cada Modo de Falha;
- Resultados para cada fatia de risco, dificuldade e estado da ferramenta;
- Custo por tarefa bem-sucedida;
- Latência p50 e p95;
- Taxa de erro e recuperação da ferramenta;
- Taxa de ação não autorizada;
- Intervalo de confiança de 95%.
Não faça apenas uma "pontuação de qualidade abrangente de 87,4."
As médias totais facilmente escondem problemas. A v2 pode melhorar tarefas comuns em 8 pontos percentuais, enquanto faz tarefas de conflito de fontes regredirem em 15 pontos percentuais. Misturados, você fica com um número que parece um ligeiro aumento.
Intervalos de confiança também não podem ser ignorados.
Em 100 tarefas, um aumento na taxa de sucesso de 80% para 83% não significa automaticamente que a v2 melhorou. As taxas de sucesso binárias flutuam naturalmente em vários pontos percentuais neste tamanho de amostra. Quando as amostras são insuficientes, uma conclusão mais honesta pode ser "nenhuma regressão importante encontrada", o que não prova que é significativamente melhor.
Falhas de segurança exigem cautela especial. Se você executar 100 vezes e nenhum acesso não autorizado ocorrer, significa apenas que não foi observado nessas 100 vezes. Uma estimativa aproximada comum é: se zero falhas ocorrerem em n tentativas independentes, com um nível de confiança de 95%, o limite superior da taxa de falha real é de aproximadamente 3/n. Para 100 tentativas com zero falhas, o limite superior ainda é de aproximadamente 3%.
Riscos de baixa frequência e alta perda exigem conjuntos de desafio dedicados, mais tentativas e controles de sistema rígidos; você não pode confiar apenas em observações zero no tráfego médio.
Transforme métricas em Portões de Lançamento
Após a Avaliação ser executada, outro tipo de desperdício geralmente ocorre: o relatório tem muitos gráficos, mas a equipe ainda não sabe se deve lançar.
Os Portões de Lançamento devem ser escritos antes do experimento. Se você decidir os padrões depois de ver os resultados, as pessoas naturalmente encontrarão explicações para a versão que preferem.
O Agente de pesquisa v2 pode usar um conjunto de portões como este:
1release_gate:2 primary:3 metric: paired_whole_task_success4 requirement: Existe melhoria real, e os intervalos de confiança a suportam56 non_inferiority:7 critical_workflows:8 max_allowed_drop_percentage_points: 0.5910 safety:11 critical_unauthorized_actions: 012 fabricated_sources: 013 high_risk_failure_upper_bound: abaixo_do_limite_da_política1415 reliability:16 critical_case_pass_power_k: acima_da_meta1718 efficiency:19 max_cost_increase_per_success: 5%20 max_p95_latency_increase_ms: 2002122 slices:23 no_major_regression:24 - conflicting_sources25 - insufficient_evidence26 - tool_failure27 - high_risk2829 operations:30 trace_completeness: 100%31 judge_calibrated: true32 rollback_ready: true
Esses números são apenas exemplos estruturais; os limites reais devem ser determinados com base no risco do negócio, na linha de base atual e no tamanho da amostra.
A Métrica Principal responde se o objetivo geral progrediu. A não inferioridade impede que caminhos críticos sejam sacrificados. Segurança e permissões são barreiras rígidas. Confiabilidade analisa se o sistema consegue concluir tarefas de forma estável e contínua. Eficiência foca no custo por sucesso, não no custo por requisição.
Por que usar Custo por Tarefa Bem-Sucedida?
Um Agente barato que falha com frequência e precisa ser executado três vezes ou repassado para um humano refazer pode ter um custo real maior. Olhar apenas para as taxas únicas de API pode confundir falha barata com otimização.
Depois que todas as barreiras forem aprovadas, você não precisa migrar 100% do tráfego imediatamente.
Execute uma sombra primeiro. Deixe a v2 receber requisições reais sem afetar os usuários e compare suas diferenças com o sistema atual. Depois, faça um canário, liberando apenas para uma pequena parte do tráfego de baixo risco, mantendo a capacidade de reverter. Quando os registros de execução estiverem estáveis, expanda gradualmente.
O ponto final de uma Avaliação é uma decisão de lançamento explicável e reversível.
Falhas online devem retornar para avaliação offline
Dados offline nunca conseguem cobrir completamente o mundo real.
Os usuários usarão novas expressões, páginas web externas mudarão de layout, APIs retornarão erros nunca vistos antes e as políticas de negócio serão atualizadas. Depois que um Agente for ao ar, o Framework de Avaliação precisa continuar funcionando.
O ciclo fechado completo pode ser escrito como:
Trace de produção → Avaliação Online → Mineração de falhas → Revisão humana → Conjunto Dourado → Experimento offline → Regressão → Lançamento
Online, você não precisa enviar todo registro para o Avaliador mais caro. Comece com verificações baratas: erros de ferramentas, saídas vazias, contagens de loops, anomalias de custo, citações ausentes, novas tentativas do usuário e intervenções humanas.
Em seguida, extraia três tipos de amostras dessas:
- Tarefas que claramente falharam ou dispararam alertas;
- Tarefas onde o Avaliador está incerto ou diferentes Avaliadores se contradizem;
- Amostras aleatórias do tráfego normal.
As duas primeiras ajudam a encontrar problemas rapidamente; as amostras aleatórias são responsáveis por descobrir novas falhas que o sistema desconhece.
Após a revisão humana, adicione incidentes representativos à regression e novos padrões de alto risco ao challenge. Se o problema vier de um novo cliente ou segmento de negócio, adicione-o ao design de amostragem do conjunto de teste principal.
Toda vez que você modificar um Prompt, Modelo, RAG, Habilidade, Ferramenta ou Fluxo de Trabalho, execute novamente no mesmo conjunto de casos. Altere apenas uma variável principal por vez para saber quem causou a mudança nos resultados.
Conforme o sistema continua a crescer em complexidade, você também pode medir o Ganho de Componente.
Por exemplo, fixe a tarefa, o modelo, o espaço de trabalho e o avaliador, e altere apenas se uma determinada Habilidade está carregada:
Ganho de Habilidade = Qualidade(com Habilidade) - Qualidade(sem Habilidade)
O mesmo método pode medir Ganho de Prompt, Ganho de RAG, Ganho de Ferramenta e Ganho de Memória. Isso fornece o valor marginal de um componente, não apenas "a nova pontuação total do sistema é 85."
Sistemas Multi-Agente precisam ainda mais dessa comparação. Adicionar um Planejador, Pesquisador, Crítico e Verificador aumenta custo, latência, perda de handoff e pontos de falha. Deve ser comparado com a linha de base do Agente único mais forte no mesmo lote de tarefas para provar que o ganho de qualidade é suficiente para cobrir a complexidade adicionada.
Esta parte pode ser deixada para o segundo estágio.
A primeira versão do Framework de Avaliação deve primeiro fazer um único Agente, um único fluxo de trabalho e uma decisão de lançamento clara funcionarem. As ferramentas devem aumentar conforme os problemas aumentam; você não precisa construir um Sistema Operacional de Avaliação de nível empresarial no primeiro dia.
Comece com um diretório
A Avaliação de Agentes pode ser muito pequena.
No primeiro dia, você só precisa de uma tarefa clara, 30 casos reais, algumas verificações determinísticas e uma Rubrica humana. Depois de executá-la, categorize as falhas claramente para ver se o problema vem da recuperação, ferramentas, raciocínio, verificação ou condições de parada.
Ao se preparar para o lançamento, expanda os dados para 100–300 casos, deixe traces completos, calibre o Avaliador LLM, realize tentativas repetidas para tarefas importantes e adicione intervalos de confiança e análise de segmentos aos resultados.
Depois de entrar em produção, conecte sombra, canário, alertas e reversões. Cada incidente real se torna um Caso de Regressão que não será repetido na próxima vez.
Olhando para trás, todo o método sempre girou em torno da mesma coisa:
Primeiro, esclareça qual decisão precisa ser tomada → Escreva claramente o que significa "concluído" → Construa um conjunto de dados com tarefas reais → Verifique tanto os resultados quanto as trajetórias → Use Regras, Avaliador e Humano para pontuação em camadas → Execute repetidamente para ver a confiabilidade → Use Portões de Lançamento para tomar decisões de lançamento → Alimente falhas online de volta ao conjunto de avaliação
O modelo determina se a tarefa pode ser concluída.
O Framework de Avaliação é responsável por provar que ela pode ser devolvida de forma estável, segura e explicável.
Leitura adicional:
