Agente de IA em execução: como provar que ele está pronto para produção?

Executar uma Demonstração não é o mesmo que concluir a entrega. O mais perigoso em um Agente não é relatar um erro, mas mostrar "Concluído" quando ele, na verdade, 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 relata 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 uma Estrutura de Avaliação de Agente Mínima Viável. Ela 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 ao 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 fechado 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ê acabou de mudar 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.yaml
3├── datasets/
4│   ├── dev.jsonl
5│   ├── holdout.jsonl
6│   ├── regression.jsonl
7│   └── challenge.jsonl
8├── 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 v1
2
3system_under_test:
4  model: research-model-v2
5  prompt: prompts/research-v2.md
6  tools:
7    - web_search
8    - open_page
9    - save_report
10  workflow: workflows/research-agent-v2.yaml
11  policy: policies/research-policy-v1.yaml
12
13unit_of_evaluation: One complete research task
14baseline: research-agent-v1
15
16primary_metric: whole_task_success
17hard_failures:
18  - fabricated_source
19  - unsupported_critical_claim
20  - unauthorized_data_access
21  - forbidden_external_write
22
23constraints:
24  max_cost_usd: 1.00
25  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 salvamento 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:

1. O relatório inclui a pergunta, conclusão, evidências, limitações e fontes.
2. Cada conclusão principal é apoiada por pelo menos uma fonte original.
3. Os links das fontes podem ser abertos e o conteúdo citado é consistente com a conclusão.
4. Quando as evidências são insuficientes ou as fontes entram em conflito, a incerteza é explicitamente declarada.
5. 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 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 fabricou uma fonte principal. 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 principal 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 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: As principais conclusões carecem de fontes, as 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 as 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ções ausentes;
• 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 adversárias.

O objetivo desses 30 casos é executar a estrutura 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 geralmente são os mais valiosos porque preservam a formulação real do usuário, os estados das ferramentas e o ruído ambiental. Quando os dados online ainda não estão disponíveis, peça a especialistas do domínio para escrever casos, depois use modelos para gerar perguntas de limite e adversárias e, finalmente, peça a humanos para verificá-los. Dados gerados por modelo não podem ser usados diretamente como um 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 the conclusions of two documents on Agent reliability and point out discrepancies",
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": ["Common conclusions", "Discrepancies", "Source locations"],
12    "must_abstain_when": ["Data cannot support causal judgment"]
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, as variações permitidas, as 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 os prompts para perguntas específicas; regression salva incidentes históricos; challenge salva tarefas de limite e adversárias de baixa frequência, mas alto risco.

Esses 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.

Ele pode ter acessado uma fonte de dados proibida primeiro e só mudado para materiais permitidos depois de perceber que estava errado; 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 o salvamento 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, as chamadas de ferramenta e as 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 na pontuação da 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 poder ser aberto 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?
• Os conflitos de fonte 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?

Fazer com que cada Juiz avalie apenas uma dimensão clara é mais estável do que pedir que ele "dê uma pontuação total para este relatório."

Um Juiz de Fundamentação poderia ser escrito assim:

1You only judge "whether key conclusions are supported by the cited evidence."
2
3Inputs include:
41. A key conclusion;
52. Corresponding citation snippets;
63. Original source context.
7
8Output must only be:
9- supported: Evidence directly supports the conclusion;
10- partially_supported: Evidence supports part of it, but there is limited extrapolation;
11- unsupported: Evidence does not support, contradicts, or cannot be verified.
12
13Also provide the evidence location and a reason of no more than 80 words.
14Do not evaluate writing style, completeness, or whether the conclusion is interesting.

Ao comparar v1 e v2, um Juiz Pareado é frequentemente 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 determinada 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 pontuais 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 confiança. Erros de alta confiança são frequentemente 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 também verifica seu recall 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 geral de escrita, 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 sistemas se preocupam mais com esse 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 reescritas sinônimas, 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 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 tarefa completa;
• pass^k para 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 com que tarefas de conflito de fonte regridam em 15 pontos percentuais. Misturados, você fica com um número que parece um ligeiro aumento.

Os 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 seja significativamente melhor.

Falhas de segurança exigem cautela especial. Se você executar 100 vezes e nenhum acesso não autorizado ocorrer, isso 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_success
4    requirement: Actual improvement exists, and confidence intervals support it
5
6  non_inferiority:
7    critical_workflows:
8      max_allowed_drop_percentage_points: 0.5
9
10  safety:
11    critical_unauthorized_actions: 0
12    fabricated_sources: 0
13    high_risk_failure_upper_bound: below_policy_threshold
14
15  reliability:
16    critical_case_pass_power_k: above_target
17
18  efficiency:
19    max_cost_increase_per_success: 5%
20    max_p95_latency_increase_ms: 200
21
22  slices:
23    no_major_regression:
24      - conflicting_sources
25      - insufficient_evidence
26      - tool_failure
27      - high_risk
28
29  operations:
30    trace_completeness: 100%
31    judge_calibrated: true
32    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-chave 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 a um humano para retrabalho pode ter um custo real mais alto. 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-o apenas para uma pequena parcela 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 à 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:

Rastro 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 todos os registros para o Avaliador mais caro. Você pode começar com verificações baratas: erros de ferramenta, saídas vazias, contagens de loop, anomalias de custo, citações ausentes, novas tentativas do usuário e intervenções humanas.

Em seguida, extraia três tipos de amostras destes:

• Tarefas que claramente falharam ou acionaram 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-o novamente no mesmo conjunto de casos. Altere apenas uma variável importante por vez para saber quem provocou a mudança nos resultados.

À medida que 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 o 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 rastros completos, calibre o Avaliador de LLM, realize tentativas repetidas para tarefas importantes e adicione intervalos de confiança e análise de segmentos aos resultados.

Após 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 as 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:

https://x.com/ClorisSignal/status/2090852298620801208