Como construir um harness de avaliação para tarefas de agentes

Objetivo

Decidir se uma mudança no prompt, no conjunto de ferramentas ou no modelo deixa um agente melhor ou pior nas tarefas para as quais ele é realmente usado, com um número comparável entre execuções, e não com uma impressão tirada de algumas transcrições.

Pré-requisitos

Uma lista de tarefas, cada uma com um estado final verificável (uma linha de banco de dados, um arquivo, um valor retornado); um ambiente que possa ser reiniciado entre execuções (contêiner, banco de dados de fixtures, respostas HTTP gravadas); e orçamento para execuções repetidas. O τ-bench é um exemplo documentado dessa estrutura: o agente trabalha com ferramentas de domínio e regras de política diante de um usuário simulado, e o artigo avalia comparando o estado do banco de dados ao fim da conversa com um estado-alvo anotado. Frameworks como o Inspect (UK AI Security Institute) descrevem uma avaliação como blocos combináveis (datasets, agentes, ferramentas e scorers) e oferecem sandboxing para código de modelo não confiável e aprovação de ferramentas.

Passos

1. Colete tarefas do uso real: sessões que falharam, tickets de suporte, casos extremos, e não apenas os sucessos fáceis. Escreva cada uma como uma entrada mais um oráculo (o estado final esperado ou uma verificação determinística), nunca como uma transcrição esperada.
2. Congele o ambiente: fixe versões de ferramentas, dados iniciais (seed) e respostas externas gravadas, para que uma execução com falha possa ser repetida com entradas idênticas.
3. Avalie o estado final em código. Use uma rubrica avaliada por modelo apenas onde não existir verificação determinística, e calibre-a com uma amostra de rótulos humanos.
4. Execute cada tarefa k vezes. O artigo do τ-bench propõe o pass^k, a probabilidade de que todas as k tentativas tenham sucesso, junto com o pass@k habitual; reporte os dois, pois a diferença entre eles mostra a inconsistência do agente.
5. Registre custo, número de passos e tokens de cada execução junto com a pontuação, para que uma melhoria que dobra o custo fique visível.
6. Mantenha um conjunto separado (held-out) que nunca seja usado durante o ajuste de prompts; reporte os resultados do ajuste e do conjunto separado em separado.
7. Armazene a configuração (modelo, versão do prompt, conjunto de ferramentas, seed) junto com cada resultado e execute o harness a cada mudança de prompt ou de modelo.

Resultado esperado

Uma pontuação por tarefa e por execução, com uma faixa de confiança, uma lista das tarefas que oscilam entre sucesso e falha ao longo das tentativas e o custo por tarefa concluída, tudo reproduzível a partir da configuração armazenada.

Limites e base de verificação

O artigo citado relata que os agentes de function calling mais avançados da época tiveram sucesso em menos de 50% de suas tarefas e se mostraram inconsistentes (pass^8 abaixo de 25% em seu domínio de varejo); não se afirma aqui nenhum número para outros agentes ou tarefas. A avaliação por modelo herda os vieses do avaliador, conjuntos pequenos de tarefas geram faixas de confiança largas, e o harness mede apenas o que suas tarefas cobrem.