Como medir a confiabilidade de um agente que age, quando uma execução pode cumprir a tarefa e ainda assim causar um efeito colateral indesejado?

Pergunta em aberto

O artigo do τ-bench citado avalia um agente comparando o estado do banco de dados no fim de uma conversa com um estado-alvo anotado, e propõe o pass^k para medir a confiabilidade ao longo de tentativas repetidas. As duas medidas verificam se o objetivo foi atingido. Um agente que atua em sistemas reais pode atingir o objetivo e ainda assim fazer algo que não devia: mexer em um arquivo fora do escopo da tarefa, executar um comando com efeito mais amplo do que o necessário, enviar uma mensagem que ninguém pediu, repetir uma chamada não idempotente ou consumir várias vezes o orçamento de custo. Uma métrica de sucesso da tarefa conta essa execução como aprovada; uma contagem de incidentes em produção só registra os casos que alguém percebeu. Falta uma prática documentada para medir a segunda dimensão:

• O que é contado como efeito colateral indesejado, e por quem: uma lista fixa de efeitos proibidos por tarefa, um diff do ambiente em relação a um diff esperado, o registro de recusas de um gate de aprovação ou a revisão humana do log de ações?
• Como as duas dimensões são reportadas em conjunto: como um par (sucesso da tarefa, taxa de execuções limpas), como uma pontuação única com penalidade, ou como pass^k sobre execuções que são ao mesmo tempo bem-sucedidas e limpas?
• Quão estável é a taxa de efeitos colaterais entre versões de prompt, versões de modelo e execuções repetidas, e se ela se move na mesma direção do sucesso da tarefa ou de forma independente.
• Que parcela dos efeitos colaterais é detectada antes de acontecer, por mecanismos de dry-run e de aprovação, e que parcela só é detectada por inspeção posterior.
• Se ambientes com diff completo de estado antes e depois (contêineres, snapshots) produziram contagens diferentes das obtidas com logs de ações autorreportados.

O que uma resposta útil contém

O tipo de tarefa e o conjunto de ferramentas do agente; a definição de efeito colateral indesejado utilizada, com exemplos do que foi e do que não foi contado; o método de observação (diff do ambiente, revisão de logs, recusas do gate); o número de execuções; contagens de sucesso da tarefa e de efeitos colaterais lado a lado, por versão se várias foram comparadas; e o que a equipe mudou em consequência. Propostas sem dados devem ser identificadas como propostas, e relatos de uma única equipe devem declarar isso.