Avaliação contínua desafia o benchmark único para agentes de IA em produção

O benchmark de lançamento mente por omissão

Todo time que sobe um agente de IA roda uma bateria de testes antes do deploy, olha os traces de execução e tira uma nota. Depois disso, o silêncio: ninguém volta pra checar se aquele agente continua fazendo o que devia fazer na terça-feira seguinte, com dados reais e usuários reais puxando casos que o benchmark nunca cobriu.

É esse o problema que o paper Closed-Loop Agent Evaluation: Layered Measurement and Self-Calibration, submetido em 4 de novembro de 2026 por Ruifeng Ren e Gun Ahn, ataca de frente. Os autores descrevem a avaliação pontual como algo que "nem se verifica, nem chega de volta ao agente": você mede uma vez, guarda o número, e segue a vida.

A proposta deles trata avaliação como um problema estatístico sério: estimar o desempenho de um sistema quando quem avalia (humano ou outro modelo) tem viés próprio, e quando parte dos resultados é censurada, ou seja, incompleta porque o usuário não deu feedback, a conversa foi abandonada ou o dado relevante nunca chegou ao log.

Quatro camadas, um mesmo conjunto de perguntas

O método, batizado de closed-loop evaluation (avaliação em loop fechado), organiza a análise em quatro níveis que vão do pedaço mínimo de trabalho até o relacionamento de longo prazo com o usuário:

span:          uma chamada individual de ferramenta ou de modelo
trace:         a sequência de spans que completa uma tarefa
conversation:  todas as trocas de uma sessão com o usuário
engagement:    o histórico do mesmo usuário ao longo de várias conversas

Em cada um desses níveis, o mesmo conjunto de eixos é aplicado, o que os autores chamam de espinhaço (spine) de medição:

Execution:  o agente rodou sem erro e chamou a ferramenta certa?
Substance:  a resposta está correta e fundamentada nos dados disponíveis?
Trajectory: o caminho até a resposta foi eficiente e fez sentido?
Results:    o objetivo de negócio por trás da tarefa foi atingido?
Conduct:    restrição transversal (tom, política, segurança) válida em todo nível

A ideia central é que um problema de Trajectory num span isolado (o agente chamou a ferramenta errada, mas corrigiu sozinho) é um defeito diferente de um problema de Results numa conversation inteira (o usuário saiu sem resolver o que precisava), mesmo que os dois apareçam juntos no mesmo log. Benchmark de nota única mistura essas camadas numa pontuação só, e esconde onde está o problema real.

Todo veredito precisa apontar para o dado bruto

O paper insiste em dois componentes que funcionam como garantia de qualidade do próprio avaliador: Provenance (proveniência) e Adjudication (adjudicação).

Provenance exige que a conclusão de qualquer nível trace de volta até o dado atômico, o pedaço específico de log, prompt ou resposta, e até a regra versionada que gerou aquele julgamento. Na prática, isso significa que um avaliador não pode simplesmente dizer "essa resposta está errada": ele precisa apontar o trecho exato e a versão da regra que embasou o veredito, algo auditável depois.

Adjudication entra quando avaliadores discordam entre si ou quando o caso é ambíguo demais para uma regra simples resolver, criando um processo de arbitragem em vez de deixar a divergência sem solução.

O avaliador também é um agente, e ele tem fábrica

Uma escolha de design chamativa do paper é usar agentes de IA para avaliar outros agentes de IA. Um componente chamado Agent Factory (fábrica de agentes) gera esses evaluator agents sob demanda, e cada um carrega um domain knowledge pack (pacote de conhecimento específico do domínio avaliado, por exemplo regras de compliance financeiro) e um adapter harness (uma camada de adaptação que pluga o avaliador no formato de log e na API do sistema real).

Isso resolve um problema prático conhecido de quem já tentou usar "LLM como juiz": um avaliador genérico, sem conhecimento de domínio, tende a aprovar respostas plausíveis mas erradas no contexto específico do negócio. A fábrica existe justamente para não depender de um avaliador único e genérico para tudo.

Dois loops: um corrige o avaliador, o outro corrige o agente

O fechamento do loop acontece em duas camadas distintas:

• Loop interno: audita as próprias evidências, regras e métricas do avaliador, checando se o processo de julgamento continua calibrado e não degradou com o tempo.
• Loop externo: usa checagens de regressão por componente (regression checks) para alimentar melhorias no agente avaliado, fechando o ciclo entre medir e corrigir.

Os autores também descrevem um pipeline que roda esse processo inteiro de forma automática, o que indica a intenção de operacionalizar o método como parte da esteira de produção, não como um exercício manual pontual.

Os números: evidência bate holístico, mas com que agente foi medido

O paper testa o método com dois materiais: o agente de análise de negócios chamado SharpInsight, usado como estudo de caso principal, e uma adaptação do método para dados públicos de conversação.

O resultado reportado compara julgamento baseado em evidência e regra contra pontuação holística (a nota única, tipo "dou 7 de 10 para essa resposta"), usando duas métricas de concordância entre avaliadores:

ICC mede o quanto diferentes avaliadores concordam numa escala contínua, e kappa mede concordância corrigindo o efeito do acaso. A diferença no kappa (0,81 contra 0,63) é a mais relevante das duas: ela sugere que pontuação holística tem boa parte da sua "concordância" explicada por coincidência, não por critério compartilhado entre avaliadores.

Vale registrar que esse resultado vem de um único agente de caso (SharpInsight) mais uma adaptação a dados públicos, não de um benchmark amplo com múltiplos agentes de domínios variados. É um resultado do próprio grupo de autores, sem validação independente de terceiros até esta publicação.

O que muda para quem já tem agente em produção

Para o time que constrói agentes hoje, a implicação prática não é "jogue fora o benchmark de lançamento", mas sim parar de tratá-lo como suficiente. O benchmark continua útil para o gate de deploy; o que falta é instrumentar o agente para gerar, em produção, os quatro níveis (span, trace, conversation, engagement) como dados estruturados e versionados, não só logs soltos.

Isso implica custo real de engenharia: manter regras versionadas, construir os adapter harness para cada sistema, e rodar evaluator agents que, por serem agentes de IA também, geram chamadas de modelo adicionais e custo de inferência por avaliação, não contabilizado no paper. Para um agente de baixo risco e volume pequeno, esse investimento provavelmente não se paga: uma revisão humana periódica de amostras de trace continua mais barata e suficiente.

Já para agentes que tomam decisão de negócio com impacto financeiro ou regulatório, como o próprio caso SharpInsight sugere, a lacuna entre "passou no benchmark" e "está funcionando bem hoje, com os dados de hoje" é exatamente onde incidentes em produção costumam nascer sem ninguém perceber a tempo.

O que o paper ainda não responde

O texto tem sete páginas e não detalha o custo computacional do pipeline completo, nem como ele se comporta em agentes com volume de conversas ordens de grandeza maior do que o caso estudado. Também não há comparação direta com outras abordagens de avaliação contínua já discutidas na literatura de observabilidade de LLMs, o que deixa em aberto o quanto desse ganho (ICC e kappa mais altos) é específico do desenho proposto ou generalizável para qualquer esquema estruturado em camadas.

Fonte: arXiv cs.AI