Rubricas de avaliação de agentes que viajam através de pilhas

Definir um rubrica pronto para viagem

Começo escrevendo o rubrica antes de olhar para qualquer saída do modelo. O rubrica deve conter três eixos independentes: sucesso da tarefa, correção da ferramenta e fidelidade. Cada eixo recebe seu próprio guia de pontuação que não menciona o nome do modelo, a versão do framework ou a formulação exata do prompt. Mantenho os guias em um arquivo de texto simples que vive ao lado do conjunto de testes, para que qualquer pessoa possa verificá-los.

Propriedades principais

- Critérios pré-registrados – as condições de sucesso são escritas antes da primeira execução. - Isolamento de eixos – as pontuações de um eixo nunca se misturam com outro. - Linguagem livre de versão – evitar frases como "a partir do GPT-4" ou "ao usar o LangChain 0.1".

Porque o sucesso da tarefa deve ser baseado no resultado

O sucesso da tarefa responde à simples pergunta: o agente concluiu o que foi solicitado? Eu julgo isso contra uma lista de verificação que olha para o estado final do mundo, e não para a redação da resposta. Por exemplo, se a tarefa for "atualizar o endereço de e-mail do usuário para alice@example.com", eu verifico o registo da base de dados após a execução. Eu não me importo se o agente disse "Eu atualizei o seu e-mail" ou "O seu e-mail agora é alice@example.com".

Lista de verificação concreta

- Pré-condição verificada (por exemplo, o utilizador existe). - Pós-condição verificada (por exemplo, o campo de e-mail é igual a alice@example.com). - Sem efeitos colaterais adicionais (por exemplo, nenhum outro campo alterado). - Opcional: latência abaixo de um limiar (por exemplo, 2 segundos).

Eu registo um resultado binário de aprovação/reprovação para cada trajectória. Se o agente falhar a pós-condição, a pontuação de sucesso da tarefa é zero, independentemente de como a prosa parece fluente.

Correcção da ferramenta como um eixo separado

A correcção da ferramenta examina as chamadas que o agente faz para APIs externas, funções ou bases de dados. Trato cada chamada como um mini-experimento: o agente escolheu a ferramenta certa, passou os argumentos certos e chamou-a o número certo de vezes? Sigo as orientações dos folhas de dicas do OWASP sobre uso seguro de ferramentas, como o Prompt Injection Prevention Cheat Sheet e o SQL Injection Prevention Cheat Sheet para evitar injeção acidental.

Rubrica de avaliação

- Ferramenta certa selecionada – 1 ponto. - Todos os argumentos correspondem ao esquema – 1 ponto por argumento. - Nenhuma chamada extra – 1 ponto se o número de chamadas for igual ao esperado. - Nenhum efeito colateral proibido (por exemplo, escrita em um registo que deve permanecer apenas de leitura) – 1 ponto.

A pontuação do eixo é a soma dos pontos dividida pelo máximo possível. Mantenho este eixo separado para que um erro no uso da ferramenta não esconda um sucesso na conclusão da tarefa.

Fidelidade: rastreio de cada afirmação

A fidelidade pergunta se todas as afirmações na saída do agente podem ser rastreadas até os resultados da ferramenta ou ao contexto que foi dado ao modelo. Trato a saída como um conjunto de afirmações e verifico cada uma delas contra as evidências. Se uma afirmação não puder ser suportada, marco-a como uma alucinação. Este eixo é mais importante quando o agente resume documentos, cita fontes ou responde a perguntas que requerem dados externos.

Verificação passo a passo

- Divido a saída em frases atômicas. - Para cada frase, listo os fatos que ela afirma. - Associar cada fato a uma linha na saída da ferramenta ou a um trecho do contexto fornecido. - Se um fato não tiver uma correspondência, conto-o como uma falha. - Pontuação de fidelidade = (número de fatos suportados) / (número total de fatos).

Registo as contagens brutas para que eu possa ver se uma queda na fidelidade vem de algumas grandes alucinações ou muitos pequenos escorregamentos.

O que isto não é

Quero deixar claro os limites de uma rubrica pronta para viagem. Ela não garante que o agente seja seguro, barato ou rápido. Ela não promete 100 % de precisão em todos os possíveis inputs. Ela não substitui uma revisão de segurança dedicada, uma análise de custos ou um benchmark de latência. A rubrica apenas mede os três eixos que defini acima. Se precisar saber se o agente vazou chaves privadas, deve executar uma verificação de gestão de segredos separada, por exemplo, usando a Secrets Management Cheat Sheet. Se precisar saber se o agente permanece dentro de um orçamento, deve rastrear o uso de tokens ou os custos de chamadas de API fora desta rubrica.

Construir trajetórias comparáveis

Uma trajetória é o registo completo do que aconteceu durante uma execução: o prompt inicial, cada chamada de ferramenta com os seus argumentos e resultados, e a saída final do modelo. Eu armazeno cada trajetória como um objeto JSON com um esquema fixo para que possa diferençar execuções automaticamente. Abaixo está um exemplo do esquema que eu uso.

Campo | Tipo | Descrição prompt | string | O prompt exato do utilizador ou do sistema enviado para o modelo. calls | array | Lista ordenada de execuções de ferramentas. calls[].tool | string | Nome da ferramenta ou API. calls[].args | object | Argumentos passados para a ferramenta. calls[].result | qualquer | Saída bruta da ferramenta. saída | string | Texto final devolvido pelo modelo. metadata | object | Etiquetas opcionais, como nome do modelo, versão do framework, carimbo de data/hora.

Como o esquema nunca muda, eu posso calcular as três pontuações do eixo para cada trajetória usando os mesmos scripts. Eu mantenho um conjunto mestre de trajetórias que abrange as tarefas principais que eu forneço e os modos de falha comuns que eu tenho visto. Quando eu mudo o modelo, eu executo novamente as mesmas trajetórias e comparo as novas pontuações com a linha de base.

Executar avaliações em cada alteração

Integro o passo de avaliação no meu pipeline de integração contínua. O pipeline faz o seguinte em cada compromisso que pode afetar o comportamento:

- Verificar o código mais recente. - Instalar as dependências do AgentGrade. - Executar o agente contra o conjunto de trajectórias fixo. - Analisar os registos e calcular as pontuações de sucesso da tarefa, correcção da ferramenta e fidelidade. - Publicar os resultados num dashboard e sinalizar qualquer eixo que diminua mais de cinco por cento em comparação com a construção anterior verde.

Esta prática detecta regressões precocemente. Por exemplo, quando mudei a biblioteca de recuperação subjacente, o eixo de correcção da ferramenta caiu de 0,96 para 0,82 porque a nova biblioteca devolveu resultados em uma ordem diferente, causando ao agente fazer chamadas extras. A queda apareceu no relatório de CI antes de qualquer utilizador notar um problema.

Também mantenho um conjunto de twenty trajectórias com pontuação humana. Todos os meses, avalio essas com uma pessoa e comparo a média com as pontuações automáticas.

Lista de verificação do operador para avaliar rubricas de Agent que viajam entre pilhas

Mantenho uma lista de verificação escrita ao lado de cada lançamento que toca neste tópico. A lista é propositadamente simples: nomear o proprietário, nomear o artifact de evidência e nomear o rollback. Se um passo não puder produzir um arquivo, um ticket ou uma linha de log, não é um passo - é um desejo.

Antes de alterar a produção

- Congele a branch ou revisão de configuração que você medirá. - Registre o modo de falha atual com uma entrada concreta e uma saída concreta. - Confirme qual identidade o trabalho é executado e se essa identidade pode alcançar dados que não deve. - Abra as referências principais que você citará: https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html, https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html.

Enquanto você executa a verificação

- Prefira um caminho reprodutível em vez de dez capturas de tela anedóticas. - Escreva o resultado seguro esperado antes de acionar a ferramenta ou consulta. - Capture o comando exato, prompt, schema ou regex em teste - não uma paráfrase. - Se o sistema pode agir (enviar, escrever, excluir, transferir), exija um limite de confirmação no mesmo passe.

Depois de terminar

- Arquive o risco residual com um proprietário e uma data, mesmo quando a varredura estiver limpa. - Não converta um check verde em linguagem de vendas que afirme completude. - Execute a mesma lista de verificação quando o modelo, a ferramenta de schema ou as regras de validação mudam.

Sinal | O que registrar | Parar o envio? Escrita ou envio inesperado | Nome da ferramenta, args, identidade | Sim até que seja controlado Falta de confirmação em ação destrutiva | Caminho de chamada e bypass | Sim Texto não confiável tratado como instrução | Superfície de origem e ação resultante | Sim para alcance do agente Varredura limpa, julgamento aberto | Itens adiados + proprietário | Apenas se o caminho central for seguro

agenteval ajuda com a primeira passagem mensurável. Escolhas de arquitetura, aprovação legal e alegações de enfrentamento ao cliente ainda precisam de um proprietário humano. Trate cada linha da lista de verificação como suporte à decisão, não como certificado.

Como explico limites aos compradores

Quando um prospecto pergunta se o produto "cobrir tudo", respondo com o limite: verificações automatizadas detectam padrões conhecidos; cadeias novas e julgamento de política ainda precisam de revisão. Essa honestidade mantém a carga de suporte baixa e mantém o blog alinhado com o que o produto realmente faz.

Se precisar de uma segunda opinião, combine este texto com as referências abaixo e com a sua própria reprodução de teste. Não pule a etapa de reprodução apenas porque um modelo escreveu um resumo confiante.

Referências

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html - https://docs.agents-squads.com/guides/config-files

Perguntas frequentes

Quantos casos de teste precisamos?

O suficiente para cobrir as tarefas que efetivamente enviamos e as maneiras como elas falham. Um punhado de trajetórias bem escolhidas supera um grande conjunto de casos fáceis.

Podemos julgar as saídas com outro modelo?

Você pode, mas registre que o juiz é um modelo e mantenha uma amostra fixa avaliada por humanos, para que você possa dizer se o juiz em si próprio se desviou.

O que é fidelidade, concretamente?

Se cada afirmação na saída é suportada pelos resultados da ferramenta ou contexto que o agente recebeu, em vez de ser produzida a partir dos próprios priors do modelo.

Deveríamos avaliar apenas a resposta final?

Não. Avalie a trajetória também — as chamadas de ferramentas são onde a maioria das falhas do agente se origina.

Com que frequência as avaliações devem ser executadas?

Em cada alteração que possa afetar o comportamento: prompt, modelo, lista de ferramentas ou configuração de recuperação.

Um bom resultado significa que o agente é seguro?

Não. Significa que ele performou bem nas tarefas que você testou. Segurança, custo e tratamento de falhas são avaliações separadas.

Referências

- NIST — Quadro de Gestão de Riscos de IA - Stanford CRFM — HELM (Avaliação Holística de Modelos de Linguagem)

Experimente o produto: AgentGrade

2026-09-20 · apenas fontes primárias · nenhum tráfego métrico fabricado · apenas suporte à decisão

Artigos relacionados

- Avaliação offline vs monitorização online para agentes de IA - Explore a matriz completa de tópicos de micro-SaaS de IA →