Avaliação de AI Agents em Produção: de Traces a Test Suites

Viacheslav Dubrov

2026-06-10 · Atualizado 2026-09-06 · 29 min · Agentes de IA

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

Atualização do artigo

Publicado originalmente em 10 de junho de 2026. Revisto e atualizado em 6 de setembro de 2026. A atualização abrange benchmarks de agents mais recentes, revisões dos graders e evidência sobre o impacto da infraestrutura nos scores.

Uma resposta final pode afirmar que um reembolso está concluído, enquanto o trace mostra que verify_identity nunca foi executado, que issue_refund foi repetido 17 vezes ou que o agent declarou sucesso antes de a base de dados ser alterada. A avaliação baseada apenas na resposta oculta estas falhas.

Para os engenheiros que operam agents com tool use em produção, a solução é transformar traces repetíveis em casos de regressão delimitados: verificações determinísticas impõem a ordem das tools, os argumentos, os loops e os invariantes; judges calibrados tratam as decisões que exigem interpretação. O resultado é uma suite versionada que deteta a mesma falha antes da próxima release.

Para uma comparação breve de tools, consulte Melhores tools para avaliar AI Agents.

Porque é que as evals de agents são diferentes

As evals tradicionais de LLM costumam avaliar um par input-output: relevância, fidelidade, correção, segurança e, talvez, estilo. Os agents acrescentam planeamento, tool calls, retries e verificações de terminação, e cada passo cria uma nova oportunidade para falhar.

Considere um agent de reembolsos. O transcript pode terminar bem, enquanto o trace está errado:

lookup_order -> issue_refund -> final_answer

A eval da resposta passa. Uma eval da trajetória deve falhar porque verify_identity nunca foi executada antes de issue_refund. Para agents com tool use, as evals baseadas apenas na resposta conseguem detetar falhas na qualidade do conteúdo, mas não conseguem demonstrar que o agent seguiu uma trajetória válida ou produziu os efeitos secundários necessários.

Existe um segundo problema: os erros acumulam-se. Se um workflow tiver 20 passos obrigatórios, cada um for bem-sucedido de forma independente e cada passo tiver a mesma fiabilidade de 95%, a taxa de sucesso end-to-end fica em cerca de 36%:

Assim, o agent pode parecer sólido em verificações isoladas e, ainda assim, falhar na maioria das execuções completas. A falha costuma estar algures a meio, e encontrá-la exige visibilidade ao nível dos componentes, não outra análise da resposta.

Duas equipas de investigação quantificaram este fenómeno.

tau-bench fornece a um agent tarefas de apoio ao cliente nos setores aéreo e retalhista. O agent conversa com um utilizador simulado, chama APIs e tem de seguir a política do domínio. Depois da conversa, o grader verifica se a base de dados chegou ao estado-alvo anotado. Um transcript plausível com as linhas erradas continua a falhar.

Com esse grading, o GPT-4o resolveu apenas 35,2% das tarefas do setor aéreo e pouco mais de 60% das tarefas de retalho. O artigo também introduziu pass^k: a probabilidade de todas as k tentativas independentes passarem, calculada como média entre tarefas.

O retalho, o split mais fácil, teve pass^8 abaixo de 25%. Para uma tarefa de retalho selecionada aleatoriamente e oito tentativas independentes, a probabilidade de as oito execuções passarem era inferior a 25%. Uma eval de uma única execução não consegue medir esta consistência.

MAST estuda as razões pelas quais os agents falham. Os autores criaram uma taxonomia com 14 modos, a partir de 150 traces anotados manualmente, e aplicaram-na a mais de 1 600 traces provenientes de 7 frameworks multi-agent populares. A taxonomia inclui definições vagas de papéis (design do sistema), um agent ignorar o que outro agent comunicou (desalinhamento entre agents) e declarar sucesso sem verificar o resultado (ausência de verificação). Estas falhas envolvem prompts, lógica de orquestração e verificações em falta no harness. Um modelo base mais forte não consegue executar um passo de verificação que nunca foi implementado, pelo que o alvo da avaliação tem de incluir o harness que envolve o modelo.

A lacuna de adoção

O inquérito State of Agent Engineering da LangChain (1 340 participantes, realizado no final de 2025) sugere que muitas equipas já têm a matéria-prima necessária para evals melhores. O relatório indica que 89% tinham algum tipo de observabilidade, 52,4% executavam evals offline e 37,3% executavam evals online.

O inquérito indica também que 57,3% dos participantes já tinham agents em produção. Quando questionados sobre o que bloqueava a passagem para produção, 32% mencionaram a qualidade e 20% a latência. Trata-se de um inquérito aos participantes da empresa, não de um censo às equipas de agents, mas expõe uma lacuna útil entre a recolha de traces e a avaliação sistemática.

Isto deixa as equipas num estado intermédio desconfortável: conseguem inspecionar uma execução problemática depois de esta ocorrer, mas continuam a lançar duas vezes a mesma falha.

Cada falha de produção diagnosticada deve deixar um trace, uma label, uma linha no dataset e um scorer. Uma falha repetível pertence à suite de regressão.

Escolha as métricas de acordo com o modo de falha

A métrica certa depende do modo de falha, não do framework. A divisão útil tem três níveis:

1. Evals de resultado respondem se a tarefa foi concluída com sucesso.
2. Evals de trajetória respondem se o percurso foi válido, eficiente e conforme à política.
3. Evals de componentes respondem qual a tool, retriever, sub-agent ou passo de decisão que falhou.

Cada nível pode ser executado offline, com casos fixos e reproduzíveis antes da release, ou online, sobre traces de produção amostrados depois da resposta. A secção sobre guardrails detalha esta divisão. As evals offline podem exigir goldens: casos guardados que associam um input ao resultado, aos invariantes das tools e aos argumentos que uma execução correta deve produzir. As evals online devem privilegiar invariantes, distribuições e verificações assíncronas que permaneçam fora do request path.

Comece pelas métricas determinísticas. Repetem-se para inputs e código fixos e são económicas de executar. As regras podem, ainda assim, ficar desatualizadas quando as tools ou a política mudam; por isso, versione o scorer juntamente com a especificação que este verifica.

Correção dos tool calls

A correção das tools compara as tools chamadas com as tools esperadas. Escolha deliberadamente o grau de rigor:

• Correspondência exata: a sequência tem de coincidir exatamente. Use-a quando a ordem for uma questão de política, por exemplo lookup_order -> verify_identity -> issue_refund.
• Correspondência ordenada: as tools obrigatórias têm de aparecer na ordem relativa correta, mas são permitidas chamadas adicionais inofensivas.
• Correspondência em qualquer ordem: as tools obrigatórias têm de aparecer, mas a ordem pode variar.

Um scorer local simples é suficiente para começar:

from collections import Counter

def tool_correctness(called: list[str], expected: list[str], mode: str = "in_order") -> float:
    if mode not in {"exact", "in_order", "any_order"}:
        raise ValueError(f"unknown matching mode: {mode}")
    if mode == "exact":
        return float(called == expected)
    if not expected:
        return 1.0
    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
assert tool_correctness(["issue_refund"], [], "exact") == 0.0
assert tool_correctness([], [], "exact") == 1.0
assert tool_correctness(["a", "b"], ["a", "a", "b"], "any_order") == 2 / 3
try:
    tool_correctness([], [], "typo")
except ValueError:
    pass
else:
    raise AssertionError("unknown modes must fail")

O score de in_order é recall da longest-common-subsequence: que fração da sequência obrigatória sobreviveu, na ordem correta. Repare no que ignora. As chamadas inúteis não o reduzem, pelo que um agent pode obter 1,0 aqui apesar de fazer o dobro das chamadas necessárias. Quando as chamadas adicionais têm custos ou alteram o estado, acompanhe também a precisão (chamadas obrigatórias correspondentes sobre o total de chamadas) e leia ambas em conjunto. O recall deteta o passo em falta; a precisão deteta o percurso errante. Nem um recall de 1,0 nem uma precisão elevada autorizam mutações adicionais. Verifique cada chamada que altera o estado relativamente às respetivas permissões, ao recurso, aos argumentos e à verificação anterior obrigatória. Com uma lista esperada vazia, apenas o modo exato significa “não são permitidas chamadas”; os outros modos não têm requisitos positivos.

A métrica Tool Correctness da DeepEval expõe os mesmos parâmetros através de should_consider_ordering e should_exact_match.

Correção dos argumentos

Chamar a tool certa com os argumentos errados é frequentemente pior do que chamar a tool errada, porque o trace parece normal.

Nos casos simples, valide o JSON Schema e os valores exatos. Nos casos semânticos, guarde os argumentos esperados e avalie as diferenças:

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

Uma métrica baseada no nome da tool não consegue detetar 2026-06-17 quando a política exige 2026-06-19. O dataset também tem de guardar os argumentos.

Nesta ilustração de uma chamada por tool, a correspondência de parâmetros é a fração dos triplos (tool, key, value) esperados que o agent acertou. Os dicionários abaixo só são válidos quando cada tool relevante tem, no máximo, uma invocação. Não os construa sobrescrevendo chamadas anteriores com o mesmo nome: isso ocultaria um reembolso errado seguido de um reembolso correto. Para chamadas repetidas, conserve os call IDs e a ordem, associe a invocação pretendida e valide cada mutação separadamente.

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 key in called_args.get(tool, {}) and called_args[tool][key] == want:
                matched += 1
    return matched / total if total else 1.0

assert argument_correctness({}, {"reschedule_delivery": {"date": None}}) == 0.0
assert argument_correctness({"reschedule_delivery": {}},
                            {"reschedule_delivery": {"date": None}}) == 0.0
assert argument_correctness({"reschedule_delivery": {"date": None}},
                            {"reschedule_delivery": {"date": None}}) == 1.0

A igualdade exata é adequada para IDs, enums e datas já normalizadas para um único formato. É inadequada para texto livre, floats e datas no formato produzido pelo modelo, em que == assinala uma resposta correta como errada. Avalie esses campos de acordo com a sua natureza: correspondência de strings normalizadas, parsing de datas ou tolerância numérica. A métrica mantém-se; muda o comparador por campo.

Eficiência, loops e becos sem saída

Um agent que conclui a tarefa depois de cinco tool calls redundantes continua a revelar um problema de planeamento e fica mais caro de executar.

Sinais económicos pelos quais deve começar:

• Taxa de chamadas redundantes: chamadas de tools idênticas, com argumentos idênticos, repetidas mais de duas vezes.
• Anomalias na forma do trace: aumentos súbitos na profundidade, no número de tool calls, na contagem de tokens, na latência ou no custo.
• Convergência do percurso: quão próxima está a execução do percurso válido mais curto conhecido para a tarefa.
• Correção da terminação: se o agent parou cedo, continuou a trabalhar depois do sucesso ou declarou sucesso sem a alteração de estado necessária.
• Adesão ao plano: se o agent escrever um plano antes de agir, verifique se o trace o seguiu. Um bom plano ignorado e um plano mau seguido na perfeição falham ambos, por razões opostas, e a diferença entre o plano e o trace indica qual delas ocorreu.

Execute estas verificações antes de um judge sempre que possível. Um detetor de loops requer apenas algumas linhas sobre o trace. Não precisa de um modelo.

Conclusão da tarefa e avaliação do resultado

Quando avaliada pelo resultado, a pergunta é: “o utilizador obteve aquilo que pediu?”

Dois padrões funcionam melhor:

• Avaliação referenceless da conclusão da tarefa: extraia o objetivo do input e avalie se o trace e a resposta final o alcançaram. Funciona online porque o tráfego de produção raramente tem outputs golden.
• Avaliação do estado do ambiente: compare as linhas finais da base de dados, ficheiros, tickets, reservas ou registos com um estado-alvo anotado. É mais robusta do que comparar transcripts, porque os agents podem encontrar percursos válidos que não escreveu previamente.

A segunda opção é melhor quando é possível implementá-la. O estado final é o contrato. O transcript é apenas evidência.

Duas ressalvas ajudam a manter esta análise honesta. Uma auditoria de 2025 a benchmarks agentic concluiu que o tau-bench avalia algumas tarefas apenas pelo estado da base de dados. Em algumas tarefas, o resultado anotado não exige nenhuma alteração de estado nem texto específico. Um agent que não faça nada pode então obter aprovação: 38% no split aéreo e 6,0% no retalho, em qualquer k. A Anthropic reportou uma execução do Opus 4.5 que “falhou” uma tarefa de reserva no tau2-bench, o benchmark sucessor. O agent encontrou uma lacuna na política que era, na realidade, o melhor resultado para o utilizador. A avaliação do estado é superior à comparação de transcripts, mas o estado-alvo continua a ser uma anotação, e as anotações têm bugs. Audite os casos que passam demasiado facilmente, não apenas os que falham.

As versões dos benchmarks e os ambientes alteram o resultado

Os números originais do tau-bench acima explicam a fiabilidade em tentativas repetidas; não correspondem à leaderboard atual de modelos. O repositório mantido do tau-bench apresenta agora o tau3-bench, que acrescenta recuperação de conhecimento e voz full-duplex. A correção de grading da versão v1.0.1, publicada em julho de 2026, altera os scores de banking_knowledge: os resultados de versões anteriores não são comparáveis nesse domínio. Fixe as revisões das tarefas e dos graders, além do modelo, e volte a atribuir scores às trajetórias guardadas quando uma anotação for corrigida.

Escolha um benchmark que exercite a interface implementada. Testes de apoio ao cliente apenas em texto não conseguem estabelecer o comportamento perante interrupções num voice agent. As tarefas de recuperação de conhecimento também precisam do corpus, da configuração de pesquisa e da evidência disponível em cada turno. Use estes formatos de tarefa para criar casos de regressão locais, em vez de importar a posição numa leaderboard pública como critério de release.

O sandbox também faz parte do teste. O estudo de infraestrutura da Anthropic de fevereiro de 2026 encontrou uma diferença de seis pontos percentuais no Terminal-Bench 2.0 entre as configurações de recursos estrita e sem limites, com o mesmo modelo, harness e tarefas. Maior margem de recursos reduziu as falhas de infraestrutura e permitiu também estratégias de solução diferentes. Registe as garantias e os limites de CPU e RAM, timeouts, concorrência, acesso à rede e tratamento de erros de infraestrutura. Reporte essas falhas separadamente, sem as remover silenciosamente do denominador de tarefas esperadas.

Evals de componentes

As métricas de resultado e de trajetória indicam que a execução falhou e, aproximadamente, onde. As evals de componentes avaliam um span: o chunk recuperado era relevante, o sub-agent devolveu o schema esperado pelo chamador, a própria resposta da tool foi parseada? Associe o score ao span, e não à execução, para que “qual foi a tool que piorou esta semana?” seja uma query, não uma nova execução.

Três verificações cobrem a maior parte do problema:

• Scoring por span: execute a métrica adequada ao tipo de span. Spans de retrieval obtêm recall e precisão face ao chunk anotado; spans de sub-agents obtêm validação do schema e o seu próprio score de correção das tools; spans de tools obtêm taxa de erros e latência.
• Interpretação dos resultados das tools: forneça ao agent um output correto, mas pouco conveniente, de uma tool (uma lista vazia, uma correspondência parcial ou um timestamp desatualizado) e verifique o que faz a seguir. Uma tool pode estar correta enquanto o agent a interpreta mal, e essa falha só se manifesta dois passos depois.
• Atribuição da falha: a falha visível costuma ocorrer downstream da falha real. Atribua-a ao primeiro span cujo output já estava errado, não ao passo que gerou o erro.

É também aqui que a matemática da acumulação apresentada no início se torna relevante. Se 20 passos parecem corretos isoladamente, a execução pode continuar a falhar na maioria das vezes. As taxas de sucesso por span mostram qual o passo que está a executar-se a 95% e qual está a executar-se a 70%.

O flywheel de trace para eval

Comece por extrair falhas de produção antes de idealizar casos adicionais de eval.

O ciclo:

1. Capture evidência suficiente do trace para reconstruir a falha, controlando o conteúdo sensível.
2. Faça o labeling do que falhou.
3. Agrupe falhas semelhantes.
4. Mantenha goldens representativos, incluindo variantes que exigem resultados diferentes.
5. Versione o dataset.
6. Execute-o em CI.
7. Continue a fazer scoring online de traces de produção amostrados.

O repositório complementar trace2evals implementa o ciclo completo para um support agent com falhas. Captura spans GenAI de OpenTelemetry, deteta falhas com regras determinísticas, elimina duplicados e transforma os casos num golden dataset versionado, voltando a executar cada golden em CI. O backend predefinido substitui o modelo por regras determinísticas que reencenam as decisões do agent com bugs, pelo que make demo reproduz todo o ciclo offline, sem API key. Execute uv sync --extra live e defina uma API key; os mesmos comandos passam então a conduzir um modelo real.

Este é um pipeline didático. A revisão analisada em 6 de setembro de 2026 ainda tem edge cases no scorer, verificações de autorização baseadas em nomes e estado partilhado entre trials. O seu adaptador de traces espera os próprios atributos de spans e formatos de mensagens. Os exemplos corrigidos aqui não atualizam esse repositório nem estabelecem autorização para produção; valide a autorização bem-sucedida e limitada ao recurso em cada mutação e isole os trials antes de confiar nos respetivos veredictos de CI.

Extraia falhas através de error analysis

O field guide de Hamel apresenta o workflow: inspecionar conversas reais, fazer notas abertas, categorizar falhas e criar testes específicos.

1. Inspecione os traces e escreva notas abertas sobre o que correu mal.
2. Agrupe falhas recorrentes em categorias nomeadas.
3. Faça o labeling dos traces de acordo com essa taxonomia.
4. Crie testes específicos para os maiores clusters acionáveis.

Não comece com labels como reasoning_issue ou tool_problem. São demasiado vagas para testar. Use labels como missing_identity_verification, date_argument_mismatch, retried_same_tool_after_429 ou stopped_before_database_update. Uma label tão específica indica exatamente o que o teste de regressão deve verificar.

Elimine duplicados antes de promover casos

O ciclo de extração de traces tem uma armadilha: adicionar para sempre todos os traces maus. Isso cria um dataset grande, caro e estreito. Passa em quase-duplicados de março, mas não deteta o novo formato do mesmo bug em junho.

Agrupe primeiro. Comece com um golden representativo por cluster e, depois, mantenha variantes com permissões, argumentos, estados de recuperação ou resultados esperados diferentes. Uma formulação semelhante não torna dois casos de política equivalentes. Guarde os IDs dos traces relacionados em metadata com acesso controlado, para que um revisor possa consultar a evidência mais tarde.

Se um cluster de falhas voltar a ocorrer depois de uma correção, o caso de regressão não generalizou. Reavalie o cluster e adicione as variantes comportamentais em falta, em vez de recolher transcripts quase idênticos.

Versione o dataset

Versione os datasets tal como versiona prompts e código. Sempre que algo significativo mudar (modelo, prompt, schema de uma tool, prompt do judge ou comportamento da aplicação), deve executar a mesma versão do dataset antes e depois.

A verificação de CI deve fixar:

• versão do dataset
• versão da aplicação
• versão do prompt
• modelo do judge
• prompt do judge
• versão do código do evaluator
• schemas das tools, política, harness e configuração de gestão de contexto
• revisão do modelo, definições de reasoning e sampling
• fixture inicial do ambiente e efeitos externos permitidos

Se algum destes elementos mudar, a comparação antes/depois fica difícil de interpretar. Um ficheiro goldens-v3.json em git é suficiente numa escala pequena. Snapshots nativos de tools em Langfuse, Phoenix, Braintrust ou LangSmith ajudam quando o dataset se torna colaborativo.

Mantenha separadas as regressões de desenvolvimento, os exemplos de calibração do judge, a validação hold-out e as amostras de monitorização. Agrupe sessões, utilizadores e tarefas relacionadas antes de fazer o split, para que quase-duplicados não escapem entre conjuntos. Quando um caso molda um prompt ou rubric, trate-o como evidência de desenvolvimento. Uma suite de falhas extraídas testa regressões conhecidas; a sua média não estima a taxa de sucesso em produção.

Faça reset do estado mutável em cada trial: ficheiros, linhas da base de dados, caches e fixtures das tools. Isole credenciais e efeitos externos e mantenha os budgets do candidato e do baseline iguais. Reporte separadamente o número de tarefas e o número de trials, juntamente com todas as tentativas iniciadas, timeouts, crashes e resultados impossíveis de avaliar. Compare resultados emparelhados nas mesmas tarefas. Estas escolhas seguem a abordagem de clean trials e avaliação de resultados descrita no guia de avaliação da Anthropic.

Execute evals em CI

Uma verificação de release tem de falhar o build quando uma métrica ultrapassa o limite acordado. Caso contrário, a suite de evals é apenas um dashboard.

Depois de restaurar a fixture do caso num trial isolado, o teste deve voltar a executar o agent atual com o input do golden. Não deve limitar-se a reproduzir o trace antigo que falhou (esboço; a versão executável está no repositório complementar):

@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 confundir esta distinção. A função do dataset é detetar a próxima versão do agent a repetir uma falha antiga, não arquivar a própria falha.

Calibre o judge antes de confiar nele

LLM-as-judge ajuda. Também é fácil enganar-se a si próprio com ele.

G-Eval avalia três benchmarks de meta-avaliação. São o SummEval, construído a partir de sumarização de notícias da CNN/DailyMail; o Topical-Chat, um benchmark de diálogo fundamentado em conhecimento; e o QAGS, que testa consistência factual em resumos da CNN/DailyMail e do XSum. Usando o GPT-4 como backbone, o G-Eval-4 atingiu uma correlação de Spearman de 0,514 com os julgamentos humanos no SummEval. A função de scoring pondera os níveis de avaliação pela probabilidade dos tokens ($\text{score} = \sum_i p(s_i)\,s_i$).

O artigo estimou as probabilidades dos tokens do GPT-4 através de 20 amostragens, porque esse modelo não as expunha na experiência. Um modelo alojado pode não expor logprobs utilizáveis; mantenha o rubric, mas não sugira que reproduziu a ponderação probabilística do artigo. Estes resultados comparam o protocolo do artigo com os seus baselines de NLG nesses benchmarks. Apoiam o teste de um judge com rubric explícito, não a sua utilização como substituto geral das métricas automáticas ou de um benchmark de trajetória para agents em produção.

MT-Bench mostrou que o GPT-4 concordava com as preferências humanas aproximadamente com a mesma frequência com que os humanos concordam entre si. Esse resultado ajudou a tornar o judging por LLM mainstream. Trabalhos posteriores expuseram enviesamentos de posição, comprimento e self-preference. Os scores do judge também podem mudar quando o prompt ou a versão do modelo muda.

JudgeBench criou pares de respostas em que uma resposta estava objetivamente errada em conhecimento verificável, reasoning, matemática e código. Com um prompt simples para o judge, o GPT-4o obteve 50,9%, pouco acima de lançar uma moeda; o prompt Arena-Hard mais forte do artigo elevou o mesmo modelo apenas para 56,6%. A troca do modelo sob esse prompt mais forte tem mais impacto: o Claude 3.5 Sonnet, o melhor judge de uso geral testado, atingiu 64,3%, e o o3-mini com esforço de reasoning elevado atingiu 80,9%. Respostas confiantes, mas erradas, continuam a ser difíceis de avaliar para um judge que não faz reasoning antes de atribuir o score.

Trate o judge como um instrumento de medição: calibre-o com labels humanos antes de o usar para avaliar qualquer coisa e volte a verificá-lo sempre que o modelo ou o prompt do judge mudar.

Quando for necessário um judge, torne o veredicto estruturado. O Schema-Guided Reasoning (SGR) fornece ao veredicto um schema para o formato do output e a sua inspeção. Structured Outputs ou constrained decoding podem impor o formato do objeto, campos obrigatórios e restrições de valores para campos como evidence, passed_criteria, failed_criteria, failure_mode e score.

Coloque os campos de evidência antes do score se isso tornar o registo mais fácil de inspecionar. A ordem dos campos é apresentação, não uma garantia de reasoning. Um veredicto válido segundo o schema pode, ainda assim, conter evidência sem suporte ou um score pouco fiável. Use calibração com labels humanos, validadores determinísticos e revisão do transcript para testar a fiabilidade do judge. O CI pode comparar um objeto JSON estável, mas isso verifica a inspeção e o formato, não prova que as etapas do rubric foram seguidas.

Um veredicto estruturado também pode alterar a curva de custos. Trate um modelo mais barato como candidato, não como substituição automática. Execute-o no mesmo conjunto de calibração com labels humanos. Compare a sua concordância, taxa de falsos passes e taxa de falsos fails com o judge maior. Use-o para casos de rotina apenas se ultrapassar os thresholds definidos pela sua aplicação. Mantenha o judge maior para divergências, casos de alto risco ou execuções de calibração.

Checklist predefinida de higiene do judge:

1. Prefira pass/fail binário sempre que possível. Escalas de cinco pontos convidam a uma falsa precisão.
2. Faça o labeling de trajetórias que cubram os modos de falha reais antes de finalizar o rubric. Escolha o tamanho da amostra com base na cobertura e na incerteza que a decisão consegue tolerar e reserve casos separados para validação.
3. Meça a concordância entre judge e humanos com o kappa de Cohen, uma matriz de confusão e recall positivo/negativo. O kappa mede a concordância depois de contabilizar a concordância esperada por acaso; quanto mais elevado, melhor. Um judge que responde sempre “pass” não tem capacidade de discriminação útil, pelo que o kappa pode ser zero ou indefinido. Decida o que fazer quando é indefinido antes de usar a métrica para aprovar uma release.
4. Decomponha critérios abrangentes. “O agent verificou a identidade antes do tool call de reembolso?” é melhor do que “A trajetória foi boa?”
5. Emita o veredicto através de um schema SGR com evidência, critérios falhados, modo de falha e score.
6. Compare judges da mesma família e de famílias diferentes com labels humanos hold-out; a separação de famílias, por si só, não estabelece fiabilidade.
7. Meça a sensibilidade à ordem dos pares. Mantenha a aleatorização ou a agregação com ordem trocada apenas se melhorar as decisões hold-out; um estudo controlado de 2026 concluiu que trocar a ordem podia prejudicar os resultados em casos adversariais.
8. Não atribua crédito por texto adicional, a menos que acrescente conteúdo correto, relevante e suportado. Uma resposta mais longa não é uma resposta melhor.
9. Fixe o modelo, o prompt, o dataset, o schema e a versão da aplicação do judge.
10. Volte a calibrar depois de alterações ao modelo, prompt, tool, política ou schema.

Um painel é outro candidato a testar. O PoLL reportou um alinhamento melhor com os julgamentos humanos, menos enviesamento intra-modelo e custos inferiores aos do seu baseline com um único GPT-4, em seis datasets. Esses resultados pertencem aos seus modelos, tarefas e preços históricos. Não estabelecem que um painel seja mais seguro na sua tarefa. Compare os falsos passes, falsos fails, custo e volume de divergências com um judge calibrado, usando labels hold-out.

Não existe um threshold universal de kappa que torne um judge adequado para CI. Reporte a matriz de confusão, as contagens de labels, a taxa de falsos passes entre falhas humanas e a taxa de falsos fails entre passes humanos, com incerteza. Escolha limites de release com base nas consequências desses erros. Use filas de revisão quando a evidência for demasiado fraca para uma aceitação automática e mantenha autorização humana para ações consequenciais quando o workflow a exigir.

Os guardrails bloqueiam inline; as evals online observam depois

As pessoas confundem estes conceitos porque ambos produzem scores. A diferença está na colocação: inline no request path, antes da release ou depois da resposta.

Guardrails são executados inline. São rápidos e visíveis para o utilizador. Um guardrail pode bloquear um tool call, redigir PII, rejeitar prompt injection ou forçar um retry antes de a resposta sair do sistema. Um falso positivo é um bug de produção. Um falso negativo é mais silencioso e pior, porque nada no request path o reporta. As verificações de schema, intervalo e política são determinísticas. A deteção de injection e PII é feita por classifiers; trate as falhas de deteção como esperadas e mantenha uma eval assíncrona a observar o que passou.

Evals offline são executadas antes da release. São reproduzíveis. Verificam prompts, modelos, tools, retrievers e políticas contra um dataset fixo.

Evals online são executadas depois da resposta, normalmente sobre tráfego amostrado. Podem usar LLM judges mais lentos porque não estão no percurso da latência. O seu objetivo é detetar drift, encontrar novos clusters de falhas e alimentar o dataset offline seguinte.

Colocar cada mecanismo no sítio errado causa problemas:

• Um judge no request path acrescenta latência e uma nova fonte de instabilidade.
• Um guardrail relegado a scoring assíncrono permite que violações de política cheguem aos utilizadores.

Nos testes de segurança, distinga entre deteção do ataque, tentativa de executar uma ação proibida e sucesso efetivo de um efeito nocivo. Reporte os efeitos nocivos bem-sucedidos por trial de ataque, com o threat model e o budget de tentativas, juntamente com o sucesso de tarefas legítimas e os bloqueios incorretos por trial benigno. Um score do detetor, por si só, não consegue demonstrar que os dados permaneceram privados ou que uma escrita foi impedida. Use alvos isolados; o relatório de incidente da Anthropic sobre avaliação de cibersegurança documenta a razão pela qual os efeitos das evals precisam de contenção.

Em sistemas de grande volume, atribua score a uma pequena amostra com um judge mais forte e a uma amostra maior com classifiers mais baratos. Emita alertas para clusters e intervalos de confiança, não para uma única estimativa ruidosa.

Escolhas de tooling

Nenhuma tool é responsável por todo o ciclo. Compare separadamente um trace/dataset store e um CI/eval runner; um único produto pode cobrir ambos, mas não precisa de comprar os dois ao mesmo vendor.

Este é um snapshot do autor, verificado em 06-09-2026. Cada link corresponde à documentação atual que usei para a afirmação sobre a capacidade. Continuam a aplicar-se os planos, licenças, API keys, acesso aos providers e requisitos de infraestrutura.

As notas sobre trade-offs descrevem a origem do custo, não o valor do custo. As páginas de preços mudam e os vendors contabilizam elementos diferentes: traces, observations, spans, scores, utilizadores, retenção ou dados processados. Confirme os preços atuais antes de se comprometer.

Recomendações por restrição:

• Escolha Phoenix quando self-hosting, privacidade e tracing compatível com OTel forem requisitos obrigatórios e a sua equipa conseguir operar o deployment.
• Escolha Langfuse quando também precisar de versionamento de datasets e experiências, e conseguir operar a sua stack de storage ou adquirir os add-ons necessários.
• Escolha DeepEval quando o contrato principal for pass/fail em CI com Python/pytest.
• Escolha Inspect AI quando o trabalho principal for avaliação de segurança ou de frontier agents em sandboxes configuráveis.
• Escolha LangSmith quando a integração com LangChain/LangGraph se adequar ao seu workflow; use Cloud ou tenha em conta o requisito Enterprise para alojamento da plataforma em BYOC ou self-hosted.
• Escolha Braintrust quando o feedback gerido em pull requests e a comparação de experiências justificarem um serviço baseado em API key.
• Escolha Promptfoo quando as verificações de prompts ou red-team forem a principal superfície de regressão e um trace store estiver fora do âmbito.

A escolha da tool é secundária. Se as falhas de produção não se transformarem em casos de teste, está sobretudo a pagar por armazenamento de traces.

Checklist prática de rollout

Construa o pipeline de evidência antes de aumentar a stack de métricas. Comece por decidir de onde virão os exemplos.

1. Comece por recolher execuções históricas. Se o agent já existir, recolha traces, tickets de suporte, relatórios de bugs, sessões com thumbs-down, transcripts de QA manual e notas de dogfooding antes de alterar a implementação. Se o agent ainda não existir, registe todas as execuções de protótipos e testes manuais desde o primeiro dia.

2. Instrumente o formato do trace. Capture mensagens, tool calls, argumentos, outputs das tools, erros, contagens de tokens, latência, custo, feedback do utilizador, versão da aplicação, versão do prompt, versão do modelo, versão do schema da tool e estado final do ambiente. Use convenções GenAI de OpenTelemetry ou spans ao estilo OpenInference se quiser portabilidade, e fixe a versão da convenção e do adaptador. Capture conteúdo de forma seletiva: redija secrets e dados pessoais, restrinja o acesso e defina a retenção antes de promover traces a datasets. Use Langfuse, LangSmith, Phoenix ou Braintrust se quiser imediatamente uma UI de traces e um workflow de datasets.

3. Transforme falhas reais em casos seed. Leia os traces antes de os resumir com um modelo. Para cada falha útil, guarde o input, o ID do trace de origem, o estado esperado, os invariantes esperados das tools, o modo de falha, a severidade e a nota do revisor. O Langfuse pode ligar itens do dataset aos traces de produção; o LangSmith pode criar datasets a partir de execuções com traces. Mantenha o link de origem para que o caso continue auditável.

4. Se não houver histórico, gere casos de cold start. Peça a um LLM para criar tarefas a partir dos requisitos do produto, políticas, schemas das tools, máquinas de estado e macros de suporte. Cubra percursos normais e falhas como permissões erradas, verificações de identidade em falta, resultados desatualizados das tools, datas ambíguas, retries depois de rate limits e outputs contraditórios das tools.

5. Não confie em casos sintéticos sem revisão humana. Os exemplos sintéticos são úteis para cobertura, não para estabelecer a verdade. Marque-os com source: synthetic e exija a aprovação de um revisor para o resultado esperado. Execute um percurso de referência conhecido como correto quando possível e valide as expectativas geradas de forma independente; usar outra família de modelos não substitui essa verificação.

6. Construa um dataset pequeno e equilibrado. Inclua sucessos, falhas, recusas, casos de fronteira, casos de muitos turnos, casos sensíveis à política e percursos alternativos válidos. Não transforme o golden no “transcript antigo exato”. Guarde tudo o que um golden deve guardar, além do modo de falha que colocou o caso na suite.

7. Adicione primeiro verificações determinísticas. A ordem obrigatória das tools quando a ordem for política, os argumentos obrigatórios, a validação do schema, as diferenças do estado final, os limites de loops e os limites de tokens e latência, bem como os invariantes específicos da tarefa, devem ser executados antes de qualquer judge.

8. Adicione um judge com estrutura SGR. Use-o apenas para a parte que exige interpretação. Calibre-o com labels humanos e teste o rubric escolhido em casos de validação intocados. Se não conseguir separar exemplos bons e maus no conjunto de calibração, corrija o rubric antes de o integrar no CI.

9. Ligue o ciclo. Execute a suite offline pequena em CI, execute a suite maior antes da release, atribua score online a tráfego de produção amostrado e promova clusters recorrentes de falhas online de volta ao dataset offline.

A sua primeira suite de eval vai falhar alguns casos. Execute-a na mesma e, depois, adicione as falhas recorrentes como casos. Uma suite que é executada todos os dias fornece evidência para a melhorar.

Referências

• repositório demo complementar trace2evals
• LangChain - State of Agent Engineering
• Anthropic - Demystifying Evals for AI Agents
• Hamel Husain - A Field Guide to Rapidly Improving AI Products
• convenções semânticas OpenTelemetry para sistemas de IA generativa
• DeepEval Tool Correctness
• DeepEval Task Completion
• DeepEval unit testing in CI/CD
• Inspect running evals
• OpenAI Structured model outputs
• Schema-Guided Reasoning: vLLM, xgrammar, and Pydantic
• Phoenix self-hosting
• Langfuse datasets and versioning
• Langfuse experiments in CI/CD
• LangSmith platform setup
• LangSmith - Create and manage datasets programmatically
• Braintrust - Create experiments
• Phoenix LLM evals
• Promptfoo GitHub Action integration
• tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains
• Why Do Multi-Agent LLM Systems Fail?
• Establishing Best Practices for Building Rigorous Agentic Benchmarks
• G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment
• Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
• Replacing Judges with Juries: Evaluating LLM Generations with a Panel of Diverse Models
• JudgeBench: A Benchmark for Evaluating LLM-based Judges
• Self-Preference Bias in LLM-as-a-Judge