A métrica de avaliação de agentes da AWS para conversas com múltiplos turnos expõe o primeiro desvio

A AWS apresentou sua Agent Evaluation Metric para conversas com múltiplos turnos em 10 de setembro de 2026, visando uma falha que as pontuações de resposta final costumam ocultar. Um agente pode tomar uma decisão ruim, carregar o estado resultante por vários turnos e terminar com uma resposta incorreta. Um avaliador no nível da tarefa registra uma conversa malsucedida. Ele não identifica onde a falha começou.

A distinção importa porque turnos posteriores podem parecer defeituosos por si só quando apenas consumiram informações corrompidas. Tratar cada turno malsucedido como um problema separado direciona engenheiros a vários sintomas, em vez de uma única causa. Isso também pode fazer uma atualização de modelo parecer pior do que realmente é.

A AWS chama sua estrutura proposta de AEM. A primeira dimensão publicada mede a correção por meio de veracidade e completude em cada turno de resposta ou ação. A disputa maior é entre uma pontuação focada apenas no resultado e uma avaliação que preserva a estrutura causal da trajetória de um agente.

Essa disputa vai além da AWS. O AgentBench já avaliou agentes em oito ambientes interativos, enquanto o tau-bench original examinou conversas envolvendo usuários, agentes, ferramentas e regras de domínio. Ambos ajudaram a deslocar a avaliação de pares isolados de prompt e resposta. O AEM leva esse argumento ao diagnóstico no nível do turno dentro de cada conversa.

A AWS transforma uma conversa malsucedida em um mapa de erros

A mudança importante não é mais uma pontuação. É um método para separar o primeiro erro de cada falha que vem depois.

A estrutura AEM começa com conversas anotadas que contêm respostas e chamadas de ferramentas esperadas. Ela avalia cada turno em relação a essa referência, atribui um resultado de aprovação ou reprovação e registra um motivo específico quando um turno falha. Esses resultados são então combinados em uma pontuação no nível da conversa.

A AWS ilustra o problema com uma solicitação de relatório de vendas em cinco turnos. Durante o turno dois, o agente escolhe a ação relevante, mas fornece “lucro” quando o parâmetro esperado é “receita”. Os turnos três a cinco operam sobre o resultado incorreto.

Uma contagem convencional de falhas vê quatro turnos com problemas. O AEM identifica uma causa-raiz no turno dois e três falhas em cascata. Os turnos posteriores recebem o rótulo prior_action_failed, indicando que suas saídas estão erradas porque dependem de um erro anterior.

Essa atribuição altera a interpretação de engenharia. Quatro falhas poderiam sugerir fragilidades em vários prompts, ferramentas ou etapas de raciocínio. Um erro-raiz aponta para um problema específico de seleção de argumento.

O AEM avalia dois tipos de turnos sob a mesma hierarquia. Um turno de resposta contém o texto apresentado a um usuário. Um turno de ação contém uma seleção de ferramenta e seus argumentos.

Para turnos de resposta, a completude pergunta se a resposta abrange tudo o que a solicitação exige. A veracidade pergunta se suas afirmações permanecem factualmente consistentes com a referência. Para turnos de ação, a completude verifica se todas as chaves de parâmetro exigidas estão presentes. A veracidade verifica se os valores fornecidos estão semanticamente corretos.

Os turnos de ação também exigem validação estrutural. O avaliador precisa determinar se o agente escolheu a ferramenta e a ação corretas antes de julgar os campos transmitidos a elas. Um objeto de argumentos perfeitamente formatado não salva uma chamada à API errada.

A versão publicada trata a correção de cada turno como binária. Cada turno passa ou falha, embora a AWS diga que a mesma decomposição pode apoiar uma avaliação contínua de afirmações ou campos individuais. A pontuação geral padrão é a proporção não ponderada de turnos aprovados.

Essa pontuação é apenas o resultado superficial. O material útil está por baixo dela: a dimensão que falhou, o campo afetado, o primeiro turno com falha, a contagem de causas-raiz, a contagem de cascatas e o comprimento da cadeia. Assim, um painel pode mostrar que a correção caiu e também identificar se a veracidade ou a completude causou a mudança.

Essa é a inversão central por trás da Agent Evaluation Metric para conversas com múltiplos turnos. Uma pontuação menor não significa necessariamente que o agente gerou muitos erros independentes. Ela pode significar que uma decisão inicial contaminou uma longa cadeia de dependências.

Pontuações de resultado ocultam a falha que os engenheiros precisam corrigir

Uma pontuação de resultado responde se o fluxo de trabalho foi bem-sucedido, enquanto a atribuição por turno responde por que ele falhou. Equipes de produção precisam das duas respostas.

A avaliação do estado final continua valiosa. Um agente de suporte emitiu o reembolso correto ou não emitiu. Um agente de pesquisa produziu um relatório fundamentado ou não produziu. Um agente de agendamento alterou a entrada de calendário pretendida ou alterou outra coisa.

O problema começa quando esse veredito se torna todo o diagnóstico. Um estado final malsucedido pode resultar de uma ferramenta errada, um argumento ausente, um valor incorreto, uma resposta incompleta ou uma ação anterior cuja saída ruim contaminou todo o restante. Essas causas exigem correções diferentes.

Uma incompatibilidade de ferramenta pode apontar para instruções de roteamento ou descrições de ferramentas. Um parâmetro ausente pode expor ambiguidade de esquema. Um valor incorreto pode indicar seleção fraca de contexto, raciocínio ou dados de referência. Uma resposta incompleta ao usuário pode revelar uma falha de apresentação, mesmo quando todas as chamadas de ferramentas foram bem-sucedidas.

Uma única pontuação holística mistura esses defeitos. Ela também oferece pouca ajuda às equipes ao comparar versões. Suponha que um novo modelo produza a mesma taxa de sucesso em tarefas que a versão anterior. Ainda assim, ele pode ter trocado menos erros de seleção de ferramenta por mais respostas incompletas.

Essa troca importa em produção. Omitir um detalhe secundário em um relatório preliminar é diferente de enviar o valor errado para um sistema financeiro. Pontuações agregadas iguais podem ocultar riscos desiguais.

A necessidade de avaliação em camadas já aparece em todo o ecossistema de agentes. Uma descrição recente de arquitetura de avaliação divide os testes em execuções, rastros e threads. As execuções cobrem operações individuais de modelo ou ferramenta. Os rastros cobrem um turno completo do agente, enquanto as threads cobrem conversas com múltiplos turnos.

Essa estrutura complementa o argumento do AEM. A avaliação no nível da conversa revela se o objetivo do usuário sobreviveu à interação completa. A evidência no nível do turno revela o momento e a dimensão em que o comportamento divergiu.

Benchmarks anteriores estabeleceram por que o comportamento interativo merece sua própria superfície de avaliação. A pesquisa AgentBench testou 27 modelos em oito ambientes e associou falhas ao raciocínio de longo prazo, à tomada de decisões e ao seguimento de instruções. Essas propriedades surgem por meio da interação, não de uma única resposta bem elaborada.

O artigo do tau-bench foi além ao simular conversas entre usuários e agentes em ambientes de varejo e companhias aéreas. Ele avaliou o estado resultante do banco de dados em relação a um estado de objetivo anotado e mediu a consistência em testes repetidos. Seus experimentos originais relataram que os principais agentes de chamadas de função concluíram menos da metade das tarefas.

Esses benchmarks e o AEM respondem a perguntas diferentes. Os benchmarks de estado final testam se um agente alcançou o resultado exigido em condições realistas. O AEM oferece uma forma de inspecionar qual turno primeiro comprometeu a correção e como o dano se propagou.

Nenhuma das visões deve substituir a outra. Um agente pode seguir uma rota inesperada, mas válida, e ainda atingir o estado correto. Uma comparação rígida de trajetória poderia penalizar essa flexibilidade. Por outro lado, uma resposta final correta pode ocultar uma rota insegura ou instável que, por acaso, se recuperou.

A resposta prática é uma pontuação em camadas. As equipes podem preservar verificações de resultado para decisões de lançamento e depois usar dimensões e rastros no nível do turno para diagnóstico. A ordenação estrita de ações deve ser aplicada apenas quando a sequência afeta a correção ou a segurança.

Isso também muda quem sofre pressão com a proposta da AWS. Fornecedores de avaliação e equipes internas de plataforma precisam ir além de uma única porcentagem de sucesso. Desenvolvedores de agentes precisam manter dados de referência mais ricos. Donos de produto precisam decidir quais dimensões merecem barreiras separadas, em vez de aceitar um único número combinado de qualidade.

Como a Agent Evaluation Metric para conversas com múltiplos turnos encontra a primeira ruptura

O AEM funciona comparando cada turno dentro de sua trajetória completa, atribuindo uma falha tipificada e preservando dependências entre ações.

O processo começa com um conjunto de dados dourado, isto é, um conjunto revisado de conversas que define o comportamento esperado. Cada exemplo precisa de mais do que uma resposta final. Ele deve incluir conteúdo correto de resposta, ferramentas esperadas, parâmetros obrigatórios, valores válidos e dependências entre turnos.

A AWS recomenda anotação humana, ou revisão humana quando um modelo mais forte ajuda a iniciar a criação das referências. Essa exigência é substancial. Um avaliador decomponível não pode produzir diagnósticos significativos quando o registro de referência subjacente é vago ou incorreto.

O avaliador primeiro estabelece o tipo de turno. Um turno de resposta é avaliado quanto à cobertura e à consistência factual. Um turno de ação é avaliado quanto à seleção de ferramenta, às chaves obrigatórias e aos valores semanticamente corretos.

O AEM usa comparação semântica onde a correspondência exata de strings seria rígida demais. “NYC” e “New York City” podem representar o mesmo valor. “Números de receita do terceiro trimestre de 2024” pode corresponder a “receita do 3º trimestre de 2024” sem compartilhar uma string idêntica.

O exemplo conceitual da AWS posiciona um avaliador semântico por trás de um limite configurável, com correspondência exata como um caminho rápido. Uma pontuação acima do limite é aprovada. Uma pontuação abaixo dele produz uma falha de veracidade.

A seleção do limite se torna uma decisão de produto, e não uma constante universal. Um avaliador estrito gera falsas falhas quando uma redação inofensiva difere. Um avaliador permissivo aceita valores que parecem relacionados, mas alteram o significado da tarefa.

Um assistente de calendário pode tratar “amanhã à tarde” como um intervalo que exige esclarecimento. Um sistema de relatórios pode exigir um período fiscal exato. Um fluxo de trabalho de conformidade pode requerer identificadores literais. Um único limite semântico não consegue expressar a tolerância ao risco de todos os domínios.

A completude tem dependência de contexto semelhante. Parâmetros opcionais não devem se tornar falhas apenas porque a trajetória dourada os utilizou. Campos obrigatórios precisam ser distinguidos dos convenientes. Caso contrário, o avaliador recompensa a imitação da referência, em vez da execução bem-sucedida.

A taxonomia de falhas torna esses julgamentos inspecionáveis. A AWS lista categorias para incompatibilidades de ferramenta ou ação, parâmetros ausentes ou extras, valores de parâmetros inconsistentes, respostas incompletas e respostas inconsistentes. Cada rótulo corresponde a uma verificação estrutural ou a uma das submetrias de correção.

Em seguida, a atribuição de dependências separa falhas originais das herdadas. Um turno recebe prior_action_failed apenas quando teria passado com informações corretas dos turnos anteriores. Essa condição é importante. Um turno posterior pode conter um novo erro independente mesmo após uma falha anterior.

Considere um agente de pesquisa que recupera o documento errado no turno dois. Em seguida, ele resume corretamente esse documento no turno três. O turno três está errado em relação ao objetivo do usuário, mas sua transformação local pode ser válida. O AEM deve marcar a decisão de recuperação como a causa-raiz e o resumo como falha herdada.

Agora suponha que o quarto turno invente uma estatística ausente no documento recuperado. Essa alucinação não é apenas herdada. Ela introduz outra causa raiz, embora a trajetória já estivesse corrompida.

Uma atribuição confiável, portanto, exige uma lógica explícita de dependências. Rotular simplesmente todos os turnos após o primeiro erro como uma cascata subestimaria falhas independentes. O valor do AEM depende de os avaliadores conseguirem distinguir o estado herdado de novos erros.

A estrutura também registra o comprimento da cadeia de ações. A AWS agrupa as cadeias em chamadas únicas, sequências de duas etapas e sequências complexas de pelo menos três etapas. Cadeias mais longas criam mais oportunidades para que um defeito inicial influencie o trabalho posterior, tornando a atribuição de causa raiz mais útil.

Depois de calculada, a saída estruturada pode alimentar dashboards e verificações de regressão. As equipes podem comparar versões de modelos pela taxa geral de sucesso, dimensão de correção, tipo de causa raiz e comprimento da cadeia. Uma versão pode então falhar porque as incompatibilidades com ferramentas aumentaram, mesmo quando uma pontuação combinada quase não mudou.

A AWS apresenta o método como independente de framework, ao mesmo tempo em que mostra integração com o SDK de avaliação Strands Agents. A documentação do avaliador personalizado descreve o sistema de avaliação ao redor, que pode coletar rastros e executar avaliadores adicionais.

Essa portabilidade é importante. A proposta é mais útil como um padrão de medição do que como um recurso específico da AWS. A sequência central permanece estável: definir dimensões, pontuar cada turno, atribuir dependências, compor os resultados e monitorar mudanças.

A Verdadeira Disputa É Entre Diagnóstico e Comportamento Flexível do Agente

Quanto mais precisamente um avaliador define um caminho correto, maior é o risco de penalizar uma alternativa válida.

Os agentes diferem dos fluxos de trabalho determinísticos porque podem chegar ao mesmo resultado por diversas rotas aceitáveis. Um agente pode recuperar o registro de um cliente antes de verificar a política. Outro pode inspecionar a política primeiro e recuperar o registro apenas quando necessário. Ambos os caminhos podem ser válidos.

Uma trajetória de referência pode transformar acidentalmente um exemplo bem-sucedido no único comportamento aceito. Esse problema se torna mais agudo quando os avaliadores comparam a ordem das ações, os campos selecionados ou a redação intermediária. Uma estrutura diagnóstica precisa de organização, mas rigidez excessiva transforma a avaliação em teste de imitação.

A AWS aborda parte desse risco ao permitir comparações semânticas e etapas invariantes à ordem. As equipes podem marcar ações cuja ordem não importa, para que sequências alternativas recebam crédito. Essa abordagem ajuda, mas não elimina o problema fundamental de design.

O conjunto de dados de referência deve codificar invariantes, não cada escolha incidental feita por um anotador. Resultados obrigatórios, ações proibidas, parâmetros essenciais e transições de estado são alvos mais robustos do que uma única transcrição preferida. Eles descrevem o que a correção exige, deixando espaço para variações legítimas.

É aqui que a pontuação baseada apenas no resultado mantém sua força. Estado do banco de dados, artefatos gerados e efeitos externos verificados podem revelar sucesso sem prescrever um caminho. Um avaliador por turno deve explicar as falhas em torno dessas verificações, não substituí-las.

A Agent Evaluation Metric para conversas com múltiplos turnos também parte de uma definição deliberadamente estreita de correção. Veracidade e completude não abrangem segurança, retenção de instruções, qualidade de planejamento, eficiência, satisfação do usuário ou comportamento de recuperação.

Um agente pode passar em todas as verificações de veracidade enquanto expõe dados confidenciais. Pode fornecer uma resposta completa após realizar chamadas desnecessárias e de alto risco. Também pode obedecer ao pedido imediato enquanto esquece uma restrição estabelecida cinco turnos antes.

A AWS descreve a correção como a primeira dimensão de um padrão extensível. Espera-se que trabalhos futuros apliquem o método à segurança, com avaliação multilíngue e multimodal planejada para depois. Até que essas dimensões cheguem e sejam validadas, o AEM não deve ser tratado como uma medida completa da qualidade de agentes.

Juízes automatizados acrescentam outra incerteza. A pontuação semântica pode depender de modelos de embeddings, pontuadores treinados ou juízes de LLM. Cada um pode introduzir sensibilidade a limiares, pontos cegos de domínio e deriva entre versões.

Um juiz também pode discordar de revisores humanos por razões fundamentadas. Especialistas de domínio podem saber que duas expressões semelhantes carregam significados operacionais distintos. Em finanças, medicina ou conformidade, um valor superficialmente equivalente pode alterar a ação permitida.

A AWS recomenda correlacionar as pontuações decompostas com rótulos humanos ou de referência para erros custosos. A correlação de Pearson ou Spearman pode mostrar se as pontuações automatizadas acompanham os julgamentos dos revisores. Essa validação deve ocorrer para cada submétrica, e não apenas para o composto final.

A revisão humana continua necessária em casos ambíguos e consequentes. O objetivo não é automatizar todos os julgamentos. É direcionar a atenção para as conversas em que uma decisão humana tem o maior valor.

O guia mais amplo de criação de agentes também recomenda estabelecer linhas de base de avaliação antes de otimizar a escolha do modelo. Ele também trata a intervenção humana e as proteções em camadas como partes de uma implantação confiável.

O AEM pode tornar essas linhas de base mais informativas. Ele não pode decidir quais erros uma organização pode tolerar. Uma resposta verdadeira, mas incompleta, e uma resposta completa, mas falsa, falham na correção, mas suas consequências de negócio podem diferir drasticamente.

A média não ponderada introduz o mesmo problema. Ela pressupõe que todo turno aprovado contribui igualmente. Os responsáveis pela produção podem eventualmente precisar de pesos para ações arriscadas, campos críticos ou mudanças irreversíveis de estado.

As equipes devem resistir a comprimir as evidências decompostas cedo demais. Um único número composto é útil para detectar tendências, mas as decisões de lançamento ainda devem examinar a mistura de falhas subjacente. A decomposição cria valor apenas quando as pessoas a preservam.

O AEM Muda a Conversa Sobre Regressão

A atribuição por turno torna comparações entre modelos acionáveis porque conecta uma queda de qualidade a uma classe e localização específicas de falha.

As equipes de agentes alteram regularmente prompts, modelos, esquemas de ferramentas, lógica de recuperação, sistemas de memória e políticas. Qualquer modificação pode melhorar uma parte de um fluxo de trabalho enquanto prejudica outra. Uma taxa final de sucesso frequentemente não tem resolução suficiente para explicar essa troca.

Suponha que um modelo menor mantenha a mesma pontuação geral de conversa, mas gere mais parâmetros ausentes em cadeias de três etapas. Esse padrão sugere que a aparente equivalência talvez não sobreviva a solicitações de produção mais complexas. Os engenheiros podem isolar essas cadeias antes de uma implantação ampla.

Outra versão pode reduzir erros factuais nas respostas enquanto aumenta incompatibilidades de ação. Os responsáveis pelo produto então enfrentam uma escolha real. Um redator melhor não é necessariamente um operador mais seguro quando seleciona a ferramenta errada com mais frequência.

As submétricas nomeadas do AEM criam pontos de comparação estáveis. A veracidade pode ser acompanhada separadamente da completude. As causas raiz podem ser agrupadas por ferramenta, ação, campo, comprimento da conversa ou versão do modelo.

A estrutura também oferece suporte à triagem operacional. Se muitos turnos que falharam compartilham uma causa inicial, as equipes podem priorizar a primeira ação com falha. Corrigir essa ação pode eliminar várias falhas posteriores de uma só vez.

Isso é mais eficiente do que ler cada rastro sinalizado em vermelho como um incidente independente. Também produz uma responsabilidade mais clara. Uma equipe de esquemas pode investigar parâmetros ausentes, enquanto uma equipe de recuperação examina valores incorretos de fontes.

Para agentes intensivos em conhecimento, o diagnóstico de rastros deve incluir as informações disponíveis quando cada ação ocorreu. As equipes precisam de prompts versionados, trechos recuperados, respostas de ferramentas e estado da conversa. Sem esse registro, um avaliador pode localizar um turno com falha sem revelar por que o modelo o escolheu.

Essa exigência conecta a avaliação à gestão do conhecimento. Uma base de conhecimento de engenharia pesquisável pode ajudar as equipes a preservar especificações, descobertas de incidentes e decisões de avaliação ao lado de suas evidências de teste.

Casos de produção devem expandir continuamente o conjunto de dados de referência. Uma solicitação surpreendente de usuário, falha de ferramenta ou correção ambígua pode se tornar um caso de regressão revisado. Isso mantém a avaliação alinhada ao comportamento real, em vez de a um roteiro estático de laboratório.

As equipes também devem armazenar caminhos alternativos bem-sucedidos. Rastros com falha mostram o que deve ser evitado, enquanto rastros bem-sucedidos diversos revelam quanta flexibilidade o avaliador deve permitir. Ambos são necessários para evitar regras de trajetória frágeis.

A maior mudança organizacional pode estar nas revisões de lançamento. Em vez de perguntar se o novo agente obteve uma pontuação maior, os revisores podem perguntar quais dimensões melhoraram, onde surgiram novas causas raiz e se cadeias mais longas se tornaram menos confiáveis.

Essa conversa é mais difícil de resumir em um único bloco de dashboard. Ela também está mais próxima das decisões que as equipes realmente precisam tomar.

Três Sinais Mostrarão se o AEM Vai Além da AWS

O AEM se torna consequente apenas se as equipes conseguirem reproduzir sua atribuição, calibrar seus juízes e ampliá-lo sem perder comparabilidade.

O primeiro sinal é a validação pública dos rótulos de causa raiz em relação a trajetórias revisadas por humanos. O exemplo desenvolvido pela AWS explica claramente o mecanismo, mas a publicação não informa números de produção internos do Amazon Quick Suite. A próxima evidência útil mediria a concordância sobre os turnos da primeira falha e os rótulos de cascata em domínios variados.

Uma alta concordância reforçaria a afirmação de que o AEM encurta a depuração. Discordâncias frequentes exporiam a atribuição de dependências como o elo mais fraco da estrutura. As equipes devem observar avaliações que separem cadeias lineares simples de fluxos de trabalho ramificados, tentativas repetidas e esforços de recuperação.

O segundo sinal é a adoção fora de um único framework. A AWS fornece uma integração com Strands Agents, mas a metodologia é descrita como portátil. Implementações em outros sistemas de rastreamento e avaliação testariam se sua taxonomia resiste a diferentes representações de turnos, chamadas de ferramentas e estado.

A adoção entre frameworks também incentivaria definições compartilhadas. Se cada plataforma interpretar veracidade, completude e falha herdada de forma diferente, as pontuações continuarão locais. Esquemas comuns e casos de referência tornariam as comparações mais confiáveis.

O terceiro sinal é a expansão prometida além da correção. A segurança será o teste mais importante porque o comportamento seguro nem sempre pode ser representado como outra comparação de campos factuais. Uma ação perigosa pode usar parâmetros corretos, seguir o pedido do usuário e ainda violar a política.

Uma extensão de segurança bem-sucedida mostraria que o método decompor-avaliar-compor lida com dimensões qualitativamente diferentes. Uma extensão fraca sugeriria que o AEM é melhor entendido como um depurador focado em correção, e não como uma métrica geral de qualidade de agentes.

Os desenvolvedores não devem esperar esse roteiro antes de melhorar seus testes. Comece escolhendo várias conversas consequentes e anotando os resultados, ações obrigatórias, campos críticos e estrutura de dependências. Execute o agente repetidamente e compare o primeiro erro genuíno com os turnos posteriores que o herdaram.

Mantenha as verificações de estado final ao lado dos vereditos por turno. Revise casos semanticamente ambíguos com especialistas de domínio. Registre caminhos alternativos válidos para que o avaliador não confunda flexibilidade com falha.

A Métrica de Avaliação de Agentes para conversas de múltiplos turnos apresenta um argumento convincente para mudar a unidade de diagnóstico. Seu valor duradouro dependerá de equipes independentes conseguirem concordar sobre o que falhou primeiro. A próxima pergunta para qualquer equipe de agentes é concreta: quando seu painel reporta uma conversa malsucedida, ele consegue identificar a decisão que realmente a causou?