2026-06-10 · Atualizado 2026-07-22

[!NOTE] Tradução automática Este artigo foi traduzido automaticamente a partir da versão original em inglês.

Avaliação de Agentes AI em Produção: Dos Registos até aos Conjuntos de Teste

Um chatbot fornece‑te apenas uma resposta para avaliar. Um agente, por sua vez, entrega‑te toda uma estrutura hierárquica de decisões: planos, tool calls, tentativas de repetição e o momento exato em que decidiu que tinha concluído.

Essa diferença exige um método de avaliação distinto. Uma resposta final pode parecer correta mesmo quando o agente ignorou uma ferramenta obrigatória, repetiu uma chamada 17 vezes, interpretou erradamente um resultado ou seguiu um caminho proibido pela política de produção. A avaliação baseada apenas na resposta oculta esses falhanços.

TL;DR: A avaliação de agentes requer três camadas: métricas de resultado, métricas de trajetória e métricas de componentes. Construa o processo com base neste ciclo: rastreio -> rotulagem -> agrupamento -> remoção de duplicatas -> versão dataset -> gate de CI -> monitorização em tempo real. Utilize verificações determinísticas para a ordem das ferramentas, argumentos, laços e invariantes. Empregue juízes LLM apenas quando a verificação depende de interpretação, modele esses juízes através do Reasoning Orientado por Esquema (SGR) e calibre-os com base em rotulagens humanas antes de confiar neles.

Por que as avaliações de agentes são diferentes

As avaliações tradicionais de LLM costumam considerar apenas um par entrada-saída: relevância, fidelidade, correção, segurança e, eventualmente, estilo. Os agentes introduzem mecanismos de planeamento, tool calls, tentativas repetidas e verificações de terminação, sendo que cada passo representa um novo ponto potencial de falha.

Utilize um agente de reembolso. A transcrição pode terminar bem, embora o rasto esteja incorreto:

lookup_order -> issue_refund -> final_answer

A avaliação de saída passou. A avaliação da trajetória deveria falhar porque verify_identity nunca foi executado anteriormente issue_refund. Para agentes que utilizam ferramentas, as avaliações de tipo “apenas resposta” funcionam como testes de fumagem: elas detetam falhas totais, mas passam despercebidas todos os outros problemas.

Existe um segundo problema: os erros se acumulam. Se um fluxo de trabalho tiver 20 passos obrigatórios, cada um com sucesso independente, e todos os passos apresentarem a mesma fiabilidade de 95%, a taxa de sucesso do início ao fim fica em torno de 36%:

Assim, o agente pode parecer funcional em verificações isoladas, mas ainda assim falhar na maioria das execuções completas. A falha ocorre geralmente em algum ponto intermédio, e para a identificar é necessária visibilidade a nível de componente, e não apenas uma nova análise da resposta.

Duas equipas de investigação forneceram valores concretos para isso.

tau-bench O exercício atribui tarefas de atendimento ao cliente, tanto em ambiente aéreo como no varejo, a um agente. Este deve comunicar-se com um utilizador simulado, efetuar chamadas para APIs e respeitar as políticas específicas do domínio. Após a conversa, o sistema de avaliação verifica se a base de dados atingiu o estado alvo definido nas anotações; mesmo que existam transcrições plausíveis com linhas incorretas, o teste é considerado falhado.

Sob essa classificação, até mesmo o GPT-4o obteve sucesso em menos da metade das tarefas. O artigo também apresentou pass^k: executar a mesma tarefa k conta um passe apenas se o agente tiver sucesso em todos os casos k executa-se.

As pontuações de varejo que pareciam aceitáveis numa primeira tentativa caíram para abaixo de 25% em k = 8Esse mesmo agente foi confrontado com a mesma tarefa oito vezes e produziu resultados em sua maioria diferentes. Uma avaliação realizada em apenas uma execução não consegue revelar essa inconsistência.

MAST Estudam as causas das falhas dos agentes. Os autores analisaram mais de 1.600 rastreios de execução provenientes de 7 tecnologias multi-agent frameworks populares e classificaram essas falhas em 14 padrões recorrentes. A taxonomia inclui definições vagas de papéis (design de sistema), um agente que ignora o que outro agente relatou (desalinhamento entre agentes) e a declaração de sucesso sem verificar o resultado (falta de verificação). Essas falhas estão relacionadas com prompts, a lógica de orquestração e a ausência de verificações no harness. Um modelo base mais avançado não consegue executar uma etapa de verificação que nunca foi implementada, pelo que o alvo de avaliação deve incluir o harness associado ao modelo.

A lacuna de adoção

A pesquisa da LangChain indica que muitos dos respondentes já dispõem dos recursos necessários para realizar avaliações de melhor qualidade: 89% relataram dispor de alguma forma de observabilidade, enquanto 52,4% realizaram avaliações offline e 37,3% realizaram avaliações online.

O mesmo Estado da Engenharia de Agentes Os relatórios de inquérito indicam que 57,3% dos respondentes já dispõem de agentes em produção. Quando questionados sobre os fatores que impedem a produção, 32% mencionaram a qualidade e 20% a latência. Trata‑se de um inquérito realizado pelo fornecedor junto dos seus próprios respondentes, e não de um censo das equipas de agentes, mas revela uma lacuna significativa entre a recolha de rastreios e a avaliação sistemática.

Isso deixa as equipas num estado intermédio delicado: elas podem analisar um resultado falhado posteriormente, mas ainda assim lançar duas vezes o mesmo erro.

Cada falha de produção diagnosticada deve deixar para trás um registo, uma etiqueta, uma linha dataset e um avaliador de desempenho. Uma falha repetível deve ser incluída no conjunto de testes de regressão.

Selecionar métricas por modo de falha

A métrica adequada depende do modo de falha, e não do framework. A divisão útil contempla três âmbitos:

1. As avaliações de resultado indicam se a tarefa foi concluída com sucesso.
2. As avaliações de trajetória determinam se o percurso seguido foi válido, eficiente e conforme as políticas estabelecidas.
3. As avaliações de componente identificam qual ferramenta, recuperador de informações, sub-agente ou etapa de decisão falhou.

Cada escopo pode ser executado offline, em casos fixos e reprodutíveis, antes do lançamento, ou online, em rastreios de produção amostrados, após a geração da resposta. A secção “Regras de segurança” abaixo aborda em detalhe essa divisão. As avaliações offline podem exigir dados de referência (goldens). Já as avaliações online devem priorizar invariantes, distribuições e verificações assíncronas que não interfiram no caminho da requisição.

Comece com métricas determinísticas. Elas são económicas, rápidas e não sofrem derivação.

Correção das chamadas de ferramenta

A correção da ferramenta compara as ferramentas chamadas com as ferramentas esperadas. Escolha a rigidez de forma intencional:

• Correspondência exata: a sequência deve ser idêntica. Utilize este caso quando a ordem é um critério obrigatório, por exemplo lookup_order -> verify_identity -> issue_refund.
• Correspondência em ordem sequencial: as ferramentas obrigatórias devem aparecer na ordem relativa correta, mas são permitidas chamadas adicionais inofensivas.
• Correspondência em qualquer ordem: as ferramentas obrigatórias devem estar presentes, mas a sua ordem pode variar.

Um pequeno scorer local é suficiente para começar:

from collections import Counter


def tool_correctness(called: list[str], expected: list[str], mode: str = "in_order") -> float:
    if not expected:
        return 1.0
    if mode == "exact":
        return float(called == expected)
    if mode == "any_order":
        matched = sum((Counter(called) & Counter(expected)).values())
        return matched / len(expected)

    rows = [[0] * (len(expected) + 1) for _ in range(len(called) + 1)]
    for i, tool in enumerate(called):
        for j, wanted in enumerate(expected):
            if tool == wanted:
                rows[i + 1][j + 1] = rows[i][j] + 1
            else:
                rows[i + 1][j + 1] = max(rows[i][j + 1], rows[i + 1][j])
    return rows[-1][-1] / len(expected)


called = ["lookup_order", "check_refund_policy", "issue_refund"]
expected = ["lookup_order", "verify_identity", "issue_refund"]

print(round(tool_correctness(called, expected, "exact"), 3))     # 0.0
print(round(tool_correctness(called, expected, "in_order"), 3))  # 0.667

O in_order A pontuação corresponde ao recall da subsequência comum mais longa: representa a fração da sequência exigida que foi recuperada, na ordem correta. Vale notar o que este indicador ignora. As chamadas desnecessárias não o reduzem, pelo que um agente pode atingir uma pontuação de 1,0 mesmo realizando o dobro das chamadas necessárias. Quando as chamadas adicionais implicam custos financeiros ou alteram o estado, deve-se acompanhar também a precisão (chamadas correspondentes às exigidas divididas pelo total de chamadas) e analisar ambos os valores em conjunto. O recall identifica os passos faltantes; a precisão, por sua vez, deteta os desvios.

A métrica de correção de ferramentas do DeepEval exibe os mesmos parâmetros de ajuste através de should_consider_ordering e should_exact_match.

Correção de argumentos

Chamar a ferramenta certa com argumentos incorretos costuma ser pior do que chamar a ferramenta errada, uma vez que o rasto de execução parece normal.

Em casos simples, valide JSON schema e os valores exatos. Em casos semânticos, armazene os argumentos esperados e avalie as diferenças:

{
    "trace_id": "tr_2417",
    "input": "Reschedule order A-100 for next Friday.",
    "expected_tools": ["lookup_order", "reschedule_delivery"],
    "expected_arguments": {
        "reschedule_delivery": {
            "order_id": "A-100",
            "date": "2026-06-19"
        }
    }
}

Uma métrica de nome-ferramenta não consegue detetar 2026-06-17 onde a política exige 2026-06-19. O dataset também tem de armazenar argumentos.

A pontuação associada a esse dataset é parameter-match: a fração do esperado (tool, key, value) triplica o número de respostas corretas do agente.

def argument_correctness(called_args: dict, expected_args: dict) -> float:
    total = matched = 0
    for tool, params in expected_args.items():
        for key, want in params.items():
            total += 1
            if called_args.get(tool, {}).get(key) == want:
                matched += 1
    return matched / total if total else 1.0

A igualdade exata é adequada para IDs, enums e datas. É inadequada para texto livre e valores flutuantes, onde == Assinala uma resposta correta como incorreta. Avalie esses campos de acordo com os seus próprios critérios: uma correspondência de strings normalizada, uma análise de data e uma tolerância numérica. A métrica permanece a mesma; apenas o comparador por campo é alterado.

Eficiência, laços e becos sem saída

Um agente que conclui a tarefa após cinco tentativas redundantes de tool calls continua a apresentar um problema de planeamento e consome mais recursos para ser executado.

Sinais económicos com os quais deve começar:

• Taxa de chamadas redundantes: tool calls idêntico com argumentos iguais a serem repetidos mais de duas vezes.
• Anomalias na forma do rasto: picos súbitos na profundidade, no número de chamadas de ferramentas, no número de tokens, na latência ou no custo.
• Convergência do caminho: quão próximo o processo está do caminho válido mais curto conhecido para a tarefa.
• Correção da terminação: se o agente parou precocemente, continuou a funcionar após obter sucesso ou declarou sucesso sem a alteração de estado necessária.
• Adesão ao plano: se o agente cria um plano antes de agir, verifique se o rasto o seguiu. Um bom plano que é ignorado e um plano ruim que é seguido à risca falham ambos, por razões opostas, sendo que a diferença entre o plano e o rasto indica qual delas.

Execute estes passos antes de um juiz sempre que possível. Um detetor de loops é constituído por algumas linhas adicionais ao rasto. Não necessita de um modelo.

Conclusão da tarefa e avaliação dos resultados

Do início ao fim, a questão fundamental é: “o utilizador obteve aquilo que solicitou?”

Dois padrões funcionam da melhor forma:

• Avaliação da conclusão de tarefas sem referência: extrai o objetivo a partir da entrada e avalia se o rasto, juntamente com a resposta final, o alcançou. Este método funciona em tempo real, uma vez que o tráfego de produção raramente dispõe de respostas ideais.
• Classificação do estado do ambiente: compara as linhas da base de dados, ficheiros, tickets, reservas ou registos finais com um estado de objetivo anotado. Este método é mais robusto do que a correspondência de transcrições, pois os agentes conseguem encontrar caminhos válidos que não foram especificados.

A segunda opção é a melhor quando é possível implementá‑la. O estado final corresponde ao contrato. A transcrição serve apenas como prova.

Duas ressalvas são necessárias para manter a objetividade, ambas relacionadas com o benchmark que popularizou a classificação por estado. O tau-bench pode atribuir uma nota de aprovação a um agente que não realiza nenhuma ação em determinadas tarefas inoperantes, pois o estado inicial já satisfazia o objetivo. Além disso, a Anthropic relatou uma execução do Opus 4.5 que “falhou” numa tarefa do tau2-bench ao encontrar uma brecha na política de decisão que, na verdade, resultava num desfecho melhor para o utilizador. A classificação por estado supera a correspondência de transcrições, mas o estado-alvo continua a ser uma anotação, e as anotações podem conter erros. Audite os casos que passam com demasiada facilidade, e não apenas aqueles que falham.

O volante de rastreio a avaliação

Identificar falhas na produção de minério antes de planear casos de avaliação adicionais.

O laço:

1. Capturar o rasto completo.
2. Rotular o que falhou.
3. Agrupar falhas semelhantes.
4. Manter um exemplo representativo em cada cluster.
5. Fazer a versãoção do dataset.
6. Executá‑lo em CI.
7. Continuar a avaliar os rastros de produção amostrados em tempo real.

O repositório complementar trace2evals implementa o ciclo completo para um agente de suporte com falhas. Ele captura os trechos de GenAI OpenTelemetry, deteta falhas através de regras determinísticas, elimina duplicatas dos casos num dataset padrão versionado e executa novamente cada versão padrão nos processos de CI. A configuração por padrão, baseada em scripts, não requer nenhuma chave API, portanto make demo Reproduz o processo de forma offline.

Falhas na mineração com análise de erros

Hamel Husain e Shreya Shankar explicam um fluxo de trabalho de análise de erros dedicado exatamente a esta etapa; o método de Hamel guia de campo Analisa-o detalhadamente. Os dois primeiros passos tiram o seu nome da investigação qualitativa, mas o método é simples: ler os registos, tomar notas e atribuir nomes aos padrões.

1. Codificação aberta: leia de 30 a 50 registos reais e escreva notas de forma livre sobre o que correu mal.
2. Codificação axial: agrupe essas notas em 5 ou 6 categorias de falha nomeadas.
3. Rotule tudo de acordo com a taxonomia.
4. Crie métricas para os grupos mais grandes.

Não comece com rótulos como reasoning_issue ou tool_problem. São demasiado vagos para serem testados. Utilize etiquetas como missing_identity_verification, date_argument_mismatch, retried_same_tool_after_429, ou stopped_before_database_update. Uma etiqueta que indica exatamente o que o teste de regressão deve verificar.

Elimine duplicatas antes de promover

O ciclo de mineração de rastreios apresenta um problema: a adição permanente de todos os rastreios inválidos. Isso gera um dataset que é grande, dispendioso e pouco abrangente. Ele transmite duplicatas quase idênticas de março, ao mesmo tempo que ignora a nova manifestação do mesmo erro em junho.

Primeiro, agrupe-os. Selecione um representante “golden” por cluster. Armazene os IDs de rastreio relacionados nos metadados, para que um revisor possa analisar as evidências de produção posteriormente.

Se um cluster de falhas recorrer após a aplicação da correção, significa que o caso de regressão não se generalizou. É necessário recriar o cluster e ampliar o conjunto de exemplos de referência, em vez de adicionar apenas 15 novos exemplos.

Versionar o dataset

Versionar datasets da mesma forma que se faz com a versionação de prompts e de código. Sempre que ocorrem alterações significativas (no modelo, em prompt, em tool schema, no mecanismo de avaliação prompt ou no comportamento da aplicação), é necessário executar a mesma versão dataset antes e depois dessas mudanças.

O gateway CI deve fixar:

• Versão dataset
• Versão da aplicação
• Versão prompt
• Modelo de avaliação
• Avaliar prompt
• Versão do código de avaliador

Se qualquer uma dessas alterações for feita, a comparação entre o estado anterior e o posterior fica confusa. A goldens-v3.json Um ficheiro no Git funciona bem em escalas pequenas. As capturas de estado nativas das ferramentas Langfuse, Phoenix, Braintrust ou LangSmith são úteis quando o dataset passa a ser um ambiente colaborativo.

Gate CI

Uma métrica com falha deve resultar numa compilação com falha; caso contrário, o conjunto de avaliação é apenas um painel de controlo que ninguém lê.

O teste deve executar novamente o agente atual com a entrada de referência. Não se deve limitar a reproduzir o registo antigo que falhou:

@pytest.mark.parametrize("golden", GOLDENS, ids=[item["id"] for item in GOLDENS])
def test_agent_regression(golden: dict) -> None:
    answer, fresh_trace = run_agent_and_capture_trace(golden["input"])

    refired = set(flag_failures(fresh_trace)) & set(golden["failure_modes"])
    assert not refired, f"failure mode regressed: {sorted(refired)}"

    assert tool_correctness(
        called=[call["name"] for call in fresh_trace["tool_calls"]],
        expected=golden["expected_tools"],
        mode=golden.get("tool_match", "in_order"),
    ) >= golden.get("tool_threshold", 1.0)

É fácil cometer um erro nesta distinção. A função do dataset é detetar quando a próxima versão do agente repete um erro anterior, e não arquivar o erro em si.

Calibre o juiz antes de confiar nele

LLM-como juiz é útil. É também fácil enganar a si mesmo com isso.

G-Eval Solicita a um juiz que defina passos de rubrica explícitos antes da avaliação. Em seguida, soma cada nível de classificação ponderado pela sua probabilidade de ocorrência ($\text{score} = \sum_i p(s_i)\,s_i$). Este protocolo permitiu acompanhar as avaliações realizadas por humanos de forma mais eficaz do que as métricas automáticas anteriores que substituiu.

O passo ponderado por probabilidade requer os valores logprobs calculados pelo sistema de avaliação, os quais alguns modelos hospedados não disponibilizam. Mesmo assim, o resultado final continua a permitir a utilização de um critério de avaliação explícito em vez de uma simples pontuação.

MT-Bench Verificou‑se que o GPT-4 concordava com as preferências humanas com uma frequência semelhante àquela com que os próprios humanos concordam entre si, o que contribuiu para que LLM fosse utilizado como critério para avaliar o que é considerado mainstream. Trabalhos posteriores revelaram vieses relacionados com a posição, o comprimento e as preferências pessoais. As pontuações atribuídas pelos juízes também podem sofrer alterações quando há mudanças no prompt ou na versão do modelo.

JudgeBench Foram criados pares de respostas nos quais uma das respostas é objetivamente incorreta segundo conhecimentos verificáveis, raciocínio lógico, cálculos matemáticos e código. O GPT-4o obteve 50,9% nesse conjunto de testes, enquanto o juiz mais competente alcançou aproximadamente 64%. Respostas dadas com confiança, mas erradas, continuam a representar um caso difícil para os sistemas de avaliação baseados em modelos.

Trate o juiz como um instrumento de medição: calibre-o com rótulos fornecidos por humanos antes de ele avaliar qualquer coisa, e verifique-o novamente sempre que o modelo do juiz ou prompt sofrer alterações.

Quando for necessário um juiz, estruture o veredito de forma clara. Raciocínio Guiado por Esquema (SGR) define o caminho de raciocínio do juiz como um esquema Pydantic. Structured Outputs ou constrained decoding, exigindo então campos como evidence, passed_criteria, failed_criteria, failure_mode, e score.

Coloque os campos de evidência antes da pontuação. Em seguida, o avaliador aplica as mesmas fases da rubrica predefinida, na mesma ordem de campos, em cada execução e em todos os modelos compatíveis. Um revisor pode inspecionar os campos nomeados em vez de analisar um parágrafo inteiro. O CI consegue fazer comparações diferençais entre objetos estáveis JSON, enquanto o conjunto de calibração revela qual fase da rubrica divergiu da etiqueta atribuída pelo humano.

Pode também alterar a curva de custos. Trate um modelo mais barato como um candidato, e não como uma substituição automática. Execute-o no mesmo conjunto de calibração rotulado por humanos. Compare a sua concordância, a taxa de falsos positivos e a taxa de falsos negativos com as do juiz principal. Utilize-o apenas em casos rotineiros se ultrapassar os limiares definidos pelo seu conjunto de aplicação. Mantenha o juiz principal para situações de desacordo, casos de alto risco ou execuções de calibração.

Lista de verificação padrão de higiene para juízes:

1. Prefira, sempre que possível, um sistema binário de aprovação/rejeição. As escalas de cinco pontos incentivam uma precisão falsa.
2. Rotule manualmente de 30 a 50 trajetórias antes de elaborar a rubrica final.
3. Avalie a concordância entre os avaliadores e os humanos utilizando o coeficiente de kappa de Cohen (que corrige a concordância por acaso, fazendo com que um avaliador que sempre classifica como “aprovado” obtenha uma pontuação próxima de zero) ou simplesmente os valores TPR/TNR.
4. Descomponha os critérios gerais. A pergunta “O agente verificou a identidade antes do reembolso tool call?” é mais eficaz do que “A trajetória foi boa?”.
5. Emita o veredito através de um esquema SGR que inclua as evidências, os critérios não cumpridos, o modo de falha e a pontuação obtida.
6. Utilize, sempre que possível, um avaliador pertencente a uma família de modelos diferente daquela do gerador.
7. Aleatorize a ordem das comparações em pares e calcule a média nas duas direções.
8. Penalize respostas excessivamente longas na rubrica. Um texto mais extenso não significa necessariamente que seja melhor.
9. Mantenha fixos o modelo do avaliador, prompt, dataset, o esquema e a versão da aplicação.
10. Realize um recalibração após alterações no modelo, prompt, nas ferramentas, nas políticas ou nos esquemas.

Para resultados de alta importância, utilize um pequeno júri em vez de um único juiz principal. PoLL Testámos um painel composto por juízes menores provenientes de famílias de modelos distintas e combinámos as suas decisões. Ao longo de seis datasets, este painel conseguiu reproduzir com maior precisão os julgamentos humanos do que um único juiz baseado no GPT-4. Além disso, evitou o viés de preferência pessoal inerente a um único juiz e custou mais de sete vezes menos. Mantenha a revisão humana para decisões que afetem questões financeiras, de acesso, segurança ou conformidade.

Se um juiz concordar com os humanos num valor de kappa de 0,55 na sua tarefa, não o utilize para bloquear implementações. Utilize-o para ordenar as filas de revisão. Se o valor se aproximar de 0,75 e o custo de falha for moderado, é muito mais fácil justificar a utilização de uma porta de controlo de integração contínua.

As regras de segurança bloqueiam as avaliações em linha, sendo que as avaliações realizadas posteriormente são monitorizadas.

As pessoas confundem-nos porque ambos geram pontuações. A diferença reside na localização: embutida no caminho da requisição, antes da libertação, ou após a resposta.

Guardrails são executados de forma inline. São rápidos, determinísticos e visíveis para o utilizador. Um guardrail pode bloquear um tool call, remover dados PII, rejeitar prompt injection ou forçar uma tentativa de novo antes de a resposta sair do seu sistema. Um falso positivo constitui um erro em produção.

Avaliações offline são executadas antes da libertação do software. Elas são reprodutíveis e servem para validar prompts, modelos, ferramentas, recuperaadores de informação e políticas, com base num dataset fixo.

Avaliações online são executadas após a resposta, geralmente em tráfego amostrado. É possível utilizar avaliadores LLM mais lentos, uma vez que estes não se encontram no caminho de latência. A sua função é detetar desvios, identificar novos clusters de falhas e fornecer os resultados ao próximo dataset offline.

Se a colocação estiver errada, isso prejudica em ambos os casos:

• Um juiz no caminho da solicitação adiciona latência e uma nova fonte de instabilidade.
• Uma proteção relegada à avaliação assíncrona permite que as violações de política cheguem aos utilizadores.

Em sistemas de alto volume, avalie uma pequena amostra com um juiz mais preciso e uma amostra maior com classificadores mais económicos. Emita alertas para clusters e limites de confiança, em vez de uma única estimativa baseada em pontos ruidosos.

Escolhas de ferramentas

Nenhuma ferramenta isolada gere todo o ciclo de desenvolvimento. As soluções mais robustas recorrem a dois componentes principais: um repositório de rastreio e um executor de CI/evaluação.

As notas sobre os compromissos técnicos descrevem de onde provém o custo, e não qual é a sua natureza. As páginas de preços podem mudar, e os fornecedores consideram fatores diferentes: rastreios, observações, períodos de tempo, pontuações, utilizadores, taxa de retenção ou dados processados. Verifique novamente os preços atuais antes de tomar uma decisão.

Atalhos de decisão:

• Precisa de rastreio auto-hospedado com portabilidade OTel: comece com o Phoenix ou o Langfuse.
• Precisa de um gateway CI baseado em código: comece com o DeepEval.
• Já está comprometido com o LangGraph: o LangSmith é bastante prático.
• Deseja revisão de regressões em PRs gerida: o Braintrust é insuperável para isso.
• Casos de segurança e testes de equipa vermelha são predominantes: o Promptfoo é a ferramenta mais adequada.
• Pesquisa em segurança ou trabalhos controlados com benchmark: o Inspect AI é a opção mais indicada.

A escolha da ferramenta é secundária. Se as falhas em produção não se tornarem casos de teste, você está, na maior parte dos casos, a pagar apenas pelo armazenamento de rastreios.

Lista de verificação prática para implementação

Construa as evidências pipeline antes de expandir o conjunto de métricas. Comece por decidir de onde virão os exemplos.

1. Colete primeiro os registos históricos. Se o agente já existir, recolha rastreios, tickets de suporte, relatórios de erros, sessões com avaliação negativa, transcrições de testes de qualidade feitos manualmente e notas de utilização interna antes de alterar a implementação. Se o agente ainda não existir, registe cada protótipo e cada execução de teste manual desde o primeiro dia.

2. Instrumentar a forma do rasto. Capturar mensagens, tool calls, argumentos, resultados das ferramentas, erros, contagens de tokens, latência, custo, feedback do utilizador, versão da aplicação, versão de prompt, versão do modelo, versão de tool schema, e o estado final do ambiente. Utilizar OpenTelemetry Convenções de GenAI ou spans no estilo OpenInference se desejar portabilidade. Utilize o Langfuse, LangSmith, Phoenix ou Braintrust caso queira uma interface de rastreio e um fluxo de trabalho dataset imediatamente.

3. Transformar falhas reais em casos de teste de base. Leia os rastreios antes de os resumir com um modelo. Para cada falha útil, armazene a entrada, o ID do rastreio de origem, o estado esperado, as invariantes da ferramenta esperadas, o modo de falha, a gravidade e a anotação do revisor. O Langfuse consegue associar os itens dataset aos rastreios em produção; o LangSmith consegue criar datasets a partir das execuções rastreadas. Mantenha o link de origem para que o caso continue auditável.

4. Se não existir histórico, gere casos de arranque a frio. Peça a um LLM que elabore tarefas a partir de requisitos de produto, políticas, tool schemas, máquinas de estado e macros de suporte. Abranja cenários de sucesso e falhas, como permissões incorretas, ausência de verificações de identidade, tool results desatualizados, datas ambíguas, tentativas de repetição após limites de taxa e resultados contraditórios das ferramentas.

5. Não confie em casos sintéticos até que um humano os revise. Os exemplos sintéticos são úteis para a cobertura, mas não para a representação da realidade. Marque-os com source: synthetic E é necessário que um revisor aprove o resultado esperado. Sempre que possível, execute um caminho de referência com comportamento conhecido e utilize famílias de modelos diferentes para gerar o caso e avaliar o resultado.

6. Construa um dataset pequeno e equilibrado. Inclua casos de sucesso, falhas, recusas, casos de limite, cenários com turnos longos, situações sensíveis à política e caminhos alternativos válidos. Não crie a “transcrição exata original” como referência ideal; essa referência deve conter o resultado desejado, as invariantes permitidas e os modos de falha.

7. Adicione primeiro as verificações determinísticas. A ordem obrigatória das ferramentas deve ser: política de ordenação, argumentos necessários, validação do esquema, diferenças no estado final, limites de repetição, tetos para tokens e latência, e invariantes específicos da tarefa, devendo todos estes passos ser executados antes de qualquer avaliador.

8. Adicione um juiz com formato SGR. Utilize-o apenas naquela parte que requer interpretação. Calibre-o com base em etiquetas fornecidas por humanos. Se o sistema não conseguir distinguir exemplos bons de maus no conjunto de calibração, ajuste primeiro as regras de avaliação antes de integrá-lo no fluxo de integração contínua.

9. Conectar o ciclo. Execute o conjunto de testes pequeno em modo offline no CI, execute o conjunto mais extenso antes do lançamento, avalie o tráfego de produção amostrado online e promova os clusters de falhas recorrentes online de volta para o modo offline dataset.

A tua primeira suite de avaliação irá apresentar erros de formas bastante óbvias. Envia-a mesmo assim. Uma suite que runs todos os dias é mais fácil de corrigir do que um documento de design perfeito que nunca impede a aprovação de um PR defeituoso.

Referências

• repositório de demonstração complementar do trace2evals
• LangChain – Estado da Engenharia de Agentes
• Anthropic – Desvendando as avaliações para agentes AI
• Hamel Husain - Um Guia Prático para Melhorar Rapidamente os Produtos AI
• Convenções semânticas para sistemas AI generativos OpenTelemetry
• Correção da Ferramenta DeepEval
• Conclusão da Tarefa DeepEval
• Raciocínio Guiado por Esquema em vLLM: Structured Outputs utilizando xgrammar e Pydantic
• Langfuse datasets e gestão de versões
• LangSmith – Criar e gerir datasets de forma programática
• Braintrust – Avaliar de forma sistemática
• Phoenix LLM avalia
• Integração com a Action GitHub do Promptfoo
• tau-bench: Um Benchmark para Interação Ferramenta-Agente-Utilizador em Domínios do Mundo Real
• Por que é que os sistemas Multi-Agent LLM falham?
• G-Eval: Avaliação de NLG com o GPT-4, que oferece uma melhor alinhamento com os padrões humanos
• Avaliação de LLM como juiz com o MT-Bench e o Chatbot Arena
• Substituir juízes por júris: Avaliação de gerações LLM com um painel de modelos diversificados
• JudgeBench: Um Benchmark para avaliar juízes baseados em LLM
• Viés de Auto-Preferência em LLM como juiz