Métricas de agentes de IA: sucesso e cobertura

Escolha a unidade antes de calcular uma taxa

Um trace é uma interação registrada. Um resultado de teste avalia um cenário em relação a uma execução. Uma assertion verifica uma expectativa dentro desse teste. Um trace pode corresponder a vários cenários, e um teste pode conter várias assertions. Essas contagens não são intercambiáveis.

Os cálculos abaixo são exemplos sintéticos para seu relatório de avaliação, não resultados medidos do Mibo nem uma promessa de que toda métrica aparece como widget no painel. Mantenha resultados de comportamento, aplicabilidade e qualidade das evidências em colunas separadas.

Calcule a taxa de aprovação de assertions sem contar verificações ignoradas como aprovadas

Suponha que um relatório contenha 50 registros de assertions: 15 aprovadas, 5 reprovadas e 30 ignoradas porque uma dependência impediu a avaliação. A população pontuada contém 20 assertions.

• Taxa de aprovação: 15 / (15 + 5) = 75%.
• Taxa de falha: 5 / (15 + 5) = 25%.
• Ignoradas: 30 / 50 = 60% dos registros. Investigue por que essas verificações nunca foram avaliadas.

Informar 5 / 50 = 10% como taxa de falha diluiria as falhas com verificações não avaliadas. Informe “15 aprovadas, 5 reprovadas, 30 ignoradas” junto da pontuação. Uma verificação dependente ignorada também é diferente de um cenário que não era aplicável.

A pontuação de execução do Mibo divide as assertions aprovadas pelas que podem ser pontuadas e exclui as ignoradas por dependências. Sua métrica de qualidade agregada calcula a média das pontuações dos resultados registrados. São agregações diferentes: um resultado com 1/1 aprovada e outro com 1/9 aprovada têm média de 55,6%, enquanto reunir suas assertions resulta em 2/10 = 20%. Informe qual agregação você usa.

Quando nenhuma assertion pode ser pontuada, o avaliador atual retorna uma pontuação de 1,0. Isso também ocorre quando todas são ignoradas. Confira as contagens de aprovadas, reprovadas e ignoradas antes de tratar a pontuação como evidência de uma avaliação bem-sucedida.

Defina métricas de resultados e ferramentas com contratos explícitos

• Taxa de sucesso do cenário: execuções que atendem a todos os resultados obrigatórios / execuções aplicáveis com evidências suficientes. Defina os resultados obrigatórios antecipadamente e informe as execuções excluídas separadamente. Uma pontuação média de assertions não equivale automaticamente a essa taxa.
• Precisão do roteamento: solicitações roteadas corretamente / solicitações rotuladas com roteamento observável. Rotule as rotas esperadas a partir da entrada; selecionar apenas traces que já estão na rota correta oculta falhas de roteamento.
• Correção dos argumentos de ferramentas: chamadas com os argumentos obrigatórios validados / chamadas inspecionadas que exigem esses argumentos. Conte também as execuções em que a chamada obrigatória nunca ocorreu; elas desaparecem de um denominador baseado apenas em chamadas.
• Taxa de alegações de conclusão sem respaldo: respostas avaliadas que afirmam que uma ação teve sucesso sem evidências de apoio / respostas avaliadas que alegam conclusão. Use critérios semânticos explícitos e revise julgamentos contestados.
• Contagem de ações não autorizadas: alterações de estado proibidas observadas, agrupadas por cenário e gravidade. Mantenha esse dado visível mesmo quando a taxa geral de aprovação for alta.

Use o fluxo de testes com seis casos para definir esses contratos antes de coletar pontuações. Um status HTTP de sucesso, sozinho, não comprova nenhum deles.

Meça a cobertura de cenários separadamente da qualidade

Imagine 100 traces de produção capturados: 60 correspondem a pelo menos um cenário configurado, 25 não correspondem a nenhum, 10 não têm entrada utilizável e 5 não podem ser classificados. Neste exemplo, esses grupos de traces são mutuamente exclusivos.

• Proporção de correspondências entre os traces capturados: 60 / 100 = 60%. Isso descreve a amostra capturada, não todo o tráfego de produção se a exportação ou a amostragem omitiu interações.
• Proporção de correspondências entre os traces classificáveis: 60 / (60 + 25) = 70,6%. Identifique explicitamente esse denominador mais restrito.
• Sem correspondência: inspecione as 25 solicitações em busca de cenários ausentes ou erros de classificação. Elas não são 25 testes bem-sucedidos.
• Não classificáveis: investigue separadamente os 10 traces sem entrada e os 5 com classificação indisponível. Não os transforme em aprovações nem os remova sem informar.

O Mibo distingue os resultados de classificação matched, no_match, empty_input e unavailable. Verificações invariantes ainda podem executar sem correspondência com um cenário condicional. Como um trace pode corresponder a vários cenários, somar as contagens por cenário pode contar traces mais de uma vez; remova duplicatas antes de informar a cobertura do tráfego.

Trate evidências ausentes e erros do avaliador como problemas separados

Um span ausente pode significar que uma ação nunca ocorreu ou que a instrumentação não a registrou. Determine se o trace está completo antes de interpretar assertions negativas. O tratamento de dados ausentes varia conforme a verificação; um campo ausente nem sempre recebe um status de instrumentação separado.

Para verificações semânticas, mantenha um pequeno conjunto de exemplos rotulados por engenheiros como aceitáveis ou inaceitáveis. Compare o avaliador com esses rótulos, inspecione divergências e atualize os critérios quando forem ambíguos. Revise essa calibração quando o modelo ou o prompt do avaliador mudar.

A taxa de alucinação do Mibo se baseia nas falhas entre as assertions hallucination_check configuradas. Sem essas assertions, não há uma taxa medida. Ela não mede toda possível afirmação sem respaldo em todo o tráfego.

Compare latência e custo com a mesma carga de trabalho

Informe a latência de ponta a ponta separadamente das durações do modelo e das ferramentas. Escolha uma convenção de percentis, inclua o tamanho da amostra e informe timeouts e medições de tempo ausentes. Um p95 menor não é uma melhoria de qualidade se o agente agora ignora ferramentas obrigatórias.

Tokens medem uso, não um valor monetário. Estimativas de custo precisam dos preços aplicáveis do modelo, das categorias de tokens, das novas tentativas e das cobranças de ferramentas. Compare por tarefa concluída quando seu objetivo for concluir tarefas e mantenha visíveis os custos de tentativas com falha.

Ao comparar versões, mantenha constantes, quando possível, a composição de cenários, os dados de teste, o avaliador e a janela de medição. Caso contrário, uma mudança para solicitações mais fáceis pode parecer uma melhoria. Inspecione os resultados por cenário antes de aceitar um ganho agregado.

Escreva um relatório de lançamento que sustente uma decisão

• Escopo: versões do agente, da suíte e do avaliador, cenários, quantidade de execuções e condições dos dados de teste.
• Comportamento: contagens de aprovações e falhas, regra de agregação, falhas críticas e links para as evidências relevantes nos traces.
• Pontos cegos: verificações ignoradas, traces incompletos, tráfego sem correspondência e classificação indisponível.
• Operações: distribuição de latência, timeouts, premissas de uso ou custo e tamanhos de amostra.
• Decisão: qual cenário bloqueia o lançamento, o que precisa ser corrigido e o que exige mais execuções ou revisão humana.

Cinco execuções bem-sucedidas não estabelecem uma probabilidade de sucesso de 100% em produção. Informe “5/5 com estes dados de teste” e amplie os testes em torno de falhas importantes. Escolha limites com base nas consequências de um erro, não em uma pontuação arbitrária do setor.

Conecte métricas a um teste que você consiga inspecionar

Comece com um cenário da biblioteca de casos de teste de agentes, defina suas verificações e inspecione uma execução aprovada e outra reprovada. O fluxo de avaliação do Mibo conecta verificações configuradas às evidências de execução para que o resultado leve a uma correção concreta.

Para detalhes de implementação, use a referência de assertions e o guia de ingestão OpenTelemetry. Escolha métricas apenas depois de confirmar que sua instrumentação fornece os campos necessários.