Ir para o conteúdo

Tradução automática

Este artigo foi traduzido automaticamente a partir da versão original em inglês.

Avaliar Agentes de IA em Produção: De Traces a Test Suites

Uma resposta de chatbot é uma linha. Uma execução de agente é uma árvore.

Essa diferença quebra muitos hábitos de avaliação. A resposta final pode parecer correta enquanto o agente saltou uma ferramenta obrigatória, repetiu a mesma chamada 17 vezes, leu mal o resultado de uma ferramenta ou seguiu um caminho que seria ilegal em produção. Se só avaliares a resposta, falhas precisamente na parte onde o sistema realmente falhou.

TL;DR: As evals de agentes precisam de três camadas: métricas de resultado, métricas de trajetória e métricas de componente. Constrói tudo à volta deste ciclo: trace -> label -> cluster -> dedupe -> dataset versionado -> gate de CI -> monitorização online. Usa verificações determinísticas para ordem de ferramentas, argumentos, loops e invariantes. Usa juízes LLM apenas onde a verificação depende de interpretação, estrutura esses juízes com Schema-Guided Reasoning (SGR) e calibra-os face a labels humanas antes de confiares neles.

Porque é que as evals de agentes são diferentes

As evals tradicionais de LLM normalmente pontuam um único par input-output: relevância, fidelidade, correção, segurança, talvez estilo. Os agentes acrescentam planeamento, chamadas a ferramentas, retries e verificações de terminação, e cada passo é um novo ponto de falha.

Pega num agente de reembolsos. A transcrição pode acabar bem enquanto o trace está errado:

lookup_order -> issue_refund -> final_answer

A eval do output passa. Uma eval de trajetória deve falhar porque verify_identity nunca correu antes de issue_refund. Para agentes que usam ferramentas, evals que olham apenas para a resposta são smoke tests: apanham falhas totais e deixam escapar tudo o resto.

Há um segundo problema: os erros acumulam-se. Se um workflow de 20 passos for fiável a 95% em cada passo, a taxa de sucesso end-to-end continua a ficar por volta de 36%:

\[ 0.95^{20} \\approx 0.36 \]

Por isso, o agente pode parecer sólido em verificações isoladas e mesmo assim falhar na maioria das execuções completas. A falha costuma estar algures no meio, e encontrá-la exige visibilidade ao nível dos componentes, não mais uma olhadela à resposta.

Uma linha versus uma árvore: onde se escondem as falhas dos agentes

Duas equipas de investigação puseram números nisto.

tau-bench é um benchmark em que um agente trata tarefas de apoio ao cliente nos domínios de companhias aéreas e retalho: fala com um utilizador simulado, chama APIs e tem de seguir a política do domínio ao longo do processo. A avaliação ignora a transcrição. Depois de a conversa terminar, o benchmark verifica se a base de dados chegou ao estado objetivo anotado, por isso uma execução educada e plausível que deixou as linhas erradas na base de dados continua a falhar. Com esta forma de avaliação, até o GPT-4o teve sucesso em menos de metade das tarefas. O artigo também introduziu pass^k: executar a mesma tarefa k vezes e contar sucesso apenas se o agente tiver êxito em todas as k execuções. Pontuações de retalho que pareciam toleráveis numa única tentativa desceram abaixo de 25% em k = 8. Mesmo agente, mesma tarefa, oito execuções, na maioria com resultados diferentes. Essa inconsistência é invisível se a tua eval correr cada caso apenas uma vez.

MAST coloca uma pergunta diferente: não com que frequência os agentes falham, mas porquê. Os autores anotaram mais de 1.600 traces de execução de 7 frameworks multi-agente populares e organizaram as falhas em 14 modos recorrentes. Quase nenhuma é "o modelo deu uma resposta errada". São coisas como definições vagas de papéis (design do sistema), um agente ignorar o que outro agente lhe disse (desalinhamento interagente) e declarar sucesso sem verificar o resultado (sem verificação). A maioria das falhas vive no harness: os prompts, a lógica de orquestração, as verificações em falta. Um modelo base mais forte reduz estes números, mas não consegue corrigir uma etapa de verificação que nunca foi construída. É por isso que tens de avaliar o harness, não apenas o modelo dentro dele.

A lacuna de adoção

A maioria das equipas já tem a matéria-prima para evals melhores. Têm traces. Simplesmente ainda não os transformaram em testes.

O inquérito State of Agent Engineering da LangChain é o retrato público mais claro desta lacuna. Indica que 57,3% dos inquiridos já têm agentes em produção, 89% têm alguma observabilidade, 52,4% correm evals offline e 37,3% correm evals online. E quando lhes perguntam o que bloqueia a produção, 32% dos inquiridos apontam qualidade, à frente de latência com 20%. Aquilo que as evals medem é precisamente aquilo em que as equipas estão bloqueadas.

Isto deixa as equipas num estado intermédio desconfortável: conseguem inspecionar uma má execução depois do facto e, mesmo assim, voltar a enviar a mesma falha para produção duas vezes.

Uma regra resolve isto: cada falha diagnosticada em produção deve deixar para trás um trace, uma label, uma linha de dataset e um scorer. Se pode voltar a acontecer, pertence à suite de regressão.

Escolhe métricas pelo modo de falha

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

  1. Outcome evals respondem se a tarefa teve sucesso.
  2. Trajectory evals respondem se o caminho foi válido, eficiente e conforme a política.
  3. Component evals respondem qual ferramenta, retriever, subagente ou passo de decisão falhou.

Três níveis de avaliação de agentes com as respetivas métricas

Cada âmbito pode correr offline (casos fixos, reproduzíveis, antes do release) ou online (amostras de traces de produção depois da resposta); a secção de guardrails abaixo cobre esta divisão em detalhe. A versão curta: evals offline podem exigir goldens, enquanto evals online devem preferir invariantes, distribuições e verificações assíncronas que fiquem fora do request path.

Pergunta Família de métricas Contrato offline / online Determinística ou judge? Atenção a
O agente chamou as ferramentas certas? Correção de ferramentas: correspondência exata, em ordem ou em qualquer ordem Goldens exatos offline; invariantes de ferramentas obrigatórias e anomalias online Determinística Correspondência exata penaliza caminhos alternativos válidos
Chamou-as com os inputs certos? Correção de argumentos, validação de schema, correspondência de parâmetros Argumentos esperados offline; verificações de schema, intervalos e política online Ambas Ferramenta certa com argumentos errados continua errado
Desperdiçou passos? Eficiência de passos, contagem de retries, deteção de loops, custo e latência Orçamentos de passos e loops offline; drift de custo e latência online Maioritariamente determinística Elevada conclusão de tarefas pode esconder deriva cara
A tarefa teve mesmo sucesso? Conclusão da tarefa, avaliação do resultado, diff do estado final Simulador ou golden state offline; estado final, sinal do utilizador ou judge assíncrono online Judge ou verificação de estado Avalia o estado do ambiente sempre que possível
Preservou o contexto entre turns? Fidelidade multi-turn, adesão ao papel, completude da conversa Casos longos com script offline; sessões longas amostradas online Judge Testes de um só turno não dizem nada sobre o turno 14
Parou no momento certo? Correção da terminação, sucesso prematuro, trabalho infinito Testes de cenário offline; monitores de loops, timeouts e falso sucesso online Ambas "Done" pode ser um estado alucinado
Interpretou corretamente os resultados das ferramentas? Compreensão do resultado da ferramenta, verificações de estado a jusante Outputs adversariais de ferramentas offline; verificações de estado a jusante e revisão amostrada online Ambas A ferramenta pode estar certa e o agente lê-la mal

Começa por métricas determinísticas. São baratas, rápidas e não sofrem drift.

Correção de chamadas a ferramentas

A correção de ferramentas compara as ferramentas chamadas com as ferramentas esperadas. Escolhe o grau de rigor de forma deliberada:

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

Um pequeno scorer local chega para começar:

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":
        return len(set(expected) & set(called)) / len(set(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

A métrica Tool Correctness do DeepEval expõe os mesmos controlos através de should_consider_ordering e should_exact_match.

Correção de argumentos

Chamar a ferramenta certa com argumentos errados é muitas vezes pior do que chamar a ferramenta errada porque o trace parece normal.

Para casos simples, valida schema JSON e valores exatos. Para casos semânticos, guarda os argumentos esperados e avalia os deltas:

{
    "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 de ferramenta não consegue apanhar 2026-06-17 quando a política exige 2026-06-19. O dataset também tem de guardar os argumentos.

Eficiência, loops e becos sem saída

O caminho importa mesmo quando o destino é atingido. Um agente que completa a tarefa depois de cinco chamadas redundantes a ferramentas continua a sinalizar um problema de planeamento e custa mais a executar.

Sinais baratos com que deves começar:

  • Taxa de chamadas redundantes: chamadas idênticas à mesma ferramenta com os mesmos argumentos repetidas mais de duas vezes.
  • Anomalias na forma do trace: picos súbitos em profundidade, número de chamadas a ferramentas, contagem de tokens, latência ou custo.
  • Convergência de caminho: quão próxima a execução está do caminho válido mais curto conhecido para a tarefa.
  • Correção da terminação: se o agente parou demasiado cedo, continuou a trabalhar depois do sucesso ou declarou sucesso sem a alteração de estado exigida.

Corre estes checks antes de um judge sempre que puderes. Um detetor de loops são poucas linhas sobre o trace. Não precisa de modelo.

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

End-to-end, a pergunta é "o utilizador conseguiu o que pediu?"

Dois padrões funcionam melhor:

  • Referenceless task-completion judging: extrair o objetivo do input e avaliar se o trace mais a resposta final o cumpriram. Isto funciona online porque o tráfego de produção raramente tem outputs golden.
  • Environment-state grading: comparar as linhas finais da base de dados, ficheiros, tickets, reservas ou registos com um estado objetivo anotado. Isto é mais robusto do que fazer matching da transcrição porque os agentes podem encontrar caminhos válidos que tu não escreveste.

A segunda opção é melhor quando a conseguires construir. O estado final é o contrato. A transcrição é apenas evidência.

O flywheel de trace para eval

Não faças brainstorming do teu eval set primeiro. Extrai-o das falhas em produção.

O flywheel de trace para eval

O ciclo:

  1. Captura o trace completo.
  2. Faz label do que falhou.
  3. Agrupa falhas semelhantes.
  4. Mantém um golden representativo por cluster.
  5. Versiona o dataset.
  6. Corre-o em CI.
  7. Continua a pontuar traces de produção amostrados online.

Extrai falhas com análise de erro

Hamel Husain e Shreya Shankar ensinam um workflow de análise de erro precisamente para este passo; o field guide do Hamel percorre-o. Os dois primeiros passos vão buscar os nomes à investigação qualitativa, mas o método é simples: lê traces, tira notas, dá nome aos padrões.

  1. Open coding: lê 30 a 50 traces reais e escreve notas livres sobre o que correu mal.
  2. Axial coding: agrupa essas notas em 5 ou 6 categorias de falha com nome.
  3. Faz label de tudo face à taxonomia.
  4. Constrói métricas para os maiores grupos.

Não comeces com labels como reasoning_issue ou tool_problem. São demasiado vagas para testar. Usa labels como missing_identity_verification, date_argument_mismatch, retried_same_tool_after_429 ou stopped_before_database_update. Uma label com esse nível de especificidade diz-te exatamente o que o teste de regressão deve afirmar.

Remove duplicados antes de promover

O ciclo de extração de traces tem uma armadilha: acrescentar todas as más execuções para sempre. Isso cria um dataset grande, caro e estreito. Passa em quase duplicados de março enquanto falha a nova forma do mesmo bug em junho.

Agrupa primeiro. Promove um golden representativo por cluster. Guarda os IDs dos traces relacionados nos metadados para que um reviewer possa inspecionar mais tarde a evidência de produção.

Se um cluster de falhas voltar a ocorrer depois de uma correção, o caso de regressão não generalizou. Reagrupa e alarga o golden em vez de acrescentares 15 exemplos pontuais.

Versiona o dataset

Versiona datasets da mesma forma que versionas prompts e código. Sempre que algo com significado muda (modelo, prompt, schema da ferramenta, prompt do judge ou comportamento da app), queres correr a mesma versão do dataset antes e depois.

O gate de CI deve fixar:

  • versão do dataset
  • versão da app
  • versão do prompt
  • modelo do judge
  • prompt do judge
  • versão do código do evaluator

Se algum destes mexer, a tua comparação antes/depois fica turva. Um ficheiro goldens-v3.json em git chega numa escala pequena. Snapshots nativos da ferramenta em Langfuse, Phoenix, Braintrust ou LangSmith ajudam quando o dataset se torna colaborativo.

Gate de CI

Uma métrica falhada tem de se tornar um build falhado, ou a suite de evals é apenas um dashboard que ninguém lê.

O teste deve voltar a correr o agente atual face ao golden input. Não deve limitar-se a reproduzir o velho trace falhado:

@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 falhar esta distinção. O trabalho do dataset é apanhar a próxima versão do agente a repetir uma falha antiga, não arquivar a própria falha.

Calibra o judge antes de confiares nele

LLM-as-judge ajuda. Também é fácil enganares-te com ele.

A ideia já tem historial. G-Eval mostrou que um judge que percorre explicitamente uma rubrica passo a passo acompanha melhor as avaliações humanas do que as métricas automáticas mais antigas que substituiu. MT-Bench mostrou o GPT-4 a concordar com preferências humanas quase com a mesma frequência com que os humanos concordam entre si, e foi isso que tornou o julgamento por LLM mainstream. Depois chegaram as ressalvas: judges favorecem a resposta que aparece primeiro num prompt pairwise, pontuam respostas mais longas mais alto, preferem outputs da sua própria família de modelos e mudam quando o prompt ou a versão do modelo muda. JudgeBench testou judges em pares de respostas em que uma resposta é objetivamente errada e concluiu que até judges fortes ficam perto de precisão de lançamento de moeda nos casos difíceis.

Trata o judge como um instrumento de medição.

Quando um judge for necessário, torna o veredito estruturado. Schema-Guided Reasoning (SGR) é aqui o padrão por defeito: define o caminho de raciocínio do judge como um schema Pydantic, corre-o através de Structured Outputs ou constrained decoding e força o modelo a emitir campos como evidence, passed_criteria, failed_criteria, failure_mode e score.

Isto não torna o judge magicamente correto. Mas torna a medição mais reprodutível. O judge tem de percorrer os mesmos passos de rubrica predefinidos, na mesma ordem de campos, em cada execução e em qualquer modelo compatível. Um reviewer pode inspecionar campos nomeados em vez de interpretar um parágrafo. O CI pode fazer diff a um objeto JSON estável. A calibração torna-se mais fácil porque a rubrica deixa de estar escondida dentro de prosa livre.

Também altera a curva de custo. Quando a topologia de raciocínio é explícita e o output é condicionado, modelos mais baratos passam muitas vezes a ser suficientes para julgamento rotineiro. Reserva o judge maior para desacordos, casos de alto risco ou corridas de calibração, em vez de pagares por ele em cada trace.

Loop de calibração do judge

Viés O que acontece Mitigação
Posição Prompts pairwise favorecem uma das posições Trocar a ordem e fazer a média de ambas as permutações
Verbosidade Respostas mais longas recebem pontuação mais alta mesmo quando a qualidade não muda Penalizar verbosidade não suportada na rubrica
Autopreferência Um judge favorece a sua própria família de modelos Usar uma família de modelos diferente ou um júri
Sycophancy O judge dá crédito a afirmações não verificadas Exigir evidência do trace no veredito
Drift de calibração Uma atualização do modelo ou do prompt desloca as pontuações Fixar modelo e prompt do judge; recalibrar quando mudar

Checklist de higiene por defeito para judges:

  1. Prefere pass/fail binário sempre que possível. Escalas de cinco pontos convidam a falsa precisão.
  2. Faz label manual de 30 a 50 trajetórias antes de escreveres a rubrica final.
  3. Mede a concordância judge-humano com kappa de Cohen ou TPR/TNR simples.
  4. Decompõe critérios grossos. "O agente verificou a identidade antes da chamada à ferramenta de reembolso?" é melhor do que "A trajetória foi boa?"
  5. Emite o veredito através de um schema SGR com evidência, critérios falhados, modo de falha e score.
  6. Usa um judge de uma família de modelos diferente da do generator sempre que possível.
  7. Aleatoriza a ordem pairwise e faz a média das duas direções.
  8. Fixa modelo do judge, prompt, dataset, schema e versão da app.
  9. Recalibra depois de alterações a modelo, prompt, ferramenta, política ou schema.

Para scores de alto risco, usa um pequeno júri em vez de um único judge grande. PoLL testou precisamente esta configuração: um painel de judges mais pequenos, retirados de famílias de modelos distintas, com os seus vereditos agregados num único score. Em seis datasets, o painel acompanhou melhor os juízos humanos do que um único judge GPT-4, evitou o viés de autopreferência que um judge isolado transporta para os outputs da sua própria família e custou mais de sete vezes menos. Mantém revisão humana para decisões que afetem dinheiro, acesso, segurança ou conformidade.

Se um judge concorda com humanos a 0,55 kappa na tua tarefa, não o uses para bloquear deploys. Usa-o para ordenar filas de revisão. Se estiver perto de 0,75 e o custo de falha for moderado, um gate de CI é muito mais fácil de defender.

Evals online não são guardrails

As pessoas confundem estas coisas porque ambas produzem scores. Mas ficam em sítios diferentes.

Guardrails versus evals online

Guardrails correm inline. São rápidos, determinísticos e visíveis ao utilizador. Um guardrail pode bloquear uma chamada a ferramenta, redigir PII, rejeitar prompt injection ou forçar um retry antes de a resposta sair do teu sistema. Um falso positivo é um bug em produção.

Evals offline correm antes do release. São reproduzíveis. Fazem gating de prompts, modelos, ferramentas, retrievers e políticas face a um dataset fixo.

Evals online correm depois da resposta, normalmente sobre tráfego amostrado. Podem usar judges LLM mais lentos porque não estão no caminho de latência. O seu trabalho é detetar drift, encontrar novos clusters de falha e alimentar o próximo dataset offline.

Se colocares isto no sítio errado, dói de um lado ou do outro:

  • Um judge no request path adiciona latência e uma nova fonte de instabilidade.
  • Um guardrail relegado para scoring assíncrono deixa violações de política chegarem aos utilizadores.

Para sistemas de grande volume, pontua uma pequena amostra com um judge mais forte e uma amostra maior com classificadores mais baratos. Gera alertas sobre clusters e intervalos de confiança, não sobre uma única estimativa pontual ruidosa.

Escolhas de tooling

Nenhuma ferramenta cobre sozinha o ciclo inteiro. A maioria dos stacks sérios usa duas peças: um trace store e um runner de CI/eval.

Ferramenta Melhor para História em CI História de self-hosting Trade-off
DeepEval Evals de agentes e LLM nativas de Pytest Forte: deepeval test run encaixa em CI A biblioteca principal é local/open source Chamadas ao judge e funcionalidades cloud podem aumentar o custo
Inspect AI Segurança, frontier, avaliações em sandbox CLI e API Python Totalmente local/open source Não é uma plataforma de traces de produção
Phoenix Tracing OTel/OpenInference mais evals Scripts customizados Opção self-host forte O alerting gerido vive na camada comercial
Langfuse Trace store, datasets, versões de prompts Experiências e gates customizados Opção self-host forte As métricas de eval vêm menos batteries-included do que no DeepEval
LangSmith Tracing e evals para LangChain/LangGraph pytest, Vitest, workflows GitHub Self-host empresarial Closed source; atenção a preços por seat e volume de traces
Braintrust Loop de produto orientado a eval e revisão de PR Fluxo gerido de regressão em PR muito forte Empresarial/híbrido Volume de spans, dados processados e número de scores podem acumular
Promptfoo Testes de prompts e suites de red team GitHub, GitLab, Jenkins, CircleCI Core local/open source Excelente runner pré-release, não é um hub de traces

As notas de trade-off descrevem de onde vem o custo, não quanto é. As páginas de pricing mudam, e os fornecedores contam coisas diferentes: traces, observações, spans, scores, utilizadores, retenção ou dados processados. Volta a verificar o pricing atual antes de te comprometeres.

Atalhos de decisão:

  • Precisas de tracing self-hosted com portabilidade OTel: começa por Phoenix ou Langfuse.
  • Precisas de um gate de CI code-first: começa por DeepEval.
  • Já estás comprometido com LangGraph: LangSmith é conveniente.
  • Queres revisão gerida de regressões em PR: Braintrust é difícil de bater.
  • Casos de segurança e red team dominam: Promptfoo é a ferramenta mais focada.
  • Investigação em segurança ou trabalho com benchmarks controlados: Inspect AI é a melhor opção.

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

Um checklist prático de rollout

Antes de a implementação ficar sofisticada, constrói o pipeline de evidência. A primeira pergunta não é "que métrica devemos otimizar?" É "de onde virão os exemplos?"

  1. Recolhe primeiro execuções históricas. Se o agente já existe, puxa traces, tickets de suporte, bug reports, sessões com thumbs-down, transcrições de QA manual e notas de dogfooding antes de mudares a implementação. Se o agente ainda não existir, regista desde o primeiro dia cada protótipo e execução de teste manual.

  2. Instrumenta a forma do trace. Captura mensagens, chamadas a ferramentas, argumentos, outputs das ferramentas, erros, contagem de tokens, latência, custo, feedback do utilizador, versão da app, versão do prompt, versão do modelo, versão do schema da ferramenta e estado final do ambiente. Usa OpenTelemetry GenAI conventions ou spans no estilo OpenInference se quiseres portabilidade. Usa Langfuse, LangSmith, Phoenix ou Braintrust se quiseres de imediato uma UI de traces e workflow de datasets.

  3. Transforma falhas reais em casos seed. Lê os traces antes de os resumires com um modelo. Para cada falha útil, guarda o input, o ID do trace de origem, o estado esperado, as invariantes esperadas de ferramentas, o modo de falha, a severidade e a nota do reviewer. O Langfuse consegue ligar itens de dataset a traces de produção; o LangSmith consegue criar datasets a partir de traced runs. Mantém a ligação à origem para que o caso continue auditável.

  4. Se não houver histórico, gera casos cold-start. Pede a um LLM para redigir tarefas a partir de requisitos de produto, políticas, schemas de ferramentas, state machines e macros de suporte. Gera tanto happy paths como casos de "não deveria acontecer": permissões erradas, verificações de identidade em falta, resultados de ferramentas desatualizados, datas ambíguas, retries após rate limits e outputs de ferramentas que contradizem o pedido do utilizador.

  5. Não confies em casos sintéticos até um humano os rever. Exemplos sintéticos são úteis para cobertura, não para verdade. Marca-os com source: synthetic, exige que um reviewer aprove o resultado esperado, corre um caminho de referência conhecido sempre que possível e evita usar a mesma família de modelos para gerar o caso e avaliar o resultado.

  6. Constrói um dataset pequeno e equilibrado. Inclui sucessos, falhas, recusas, casos-limite, casos de muitos turns, casos sensíveis a política e caminhos alternativos válidos. Não faças do golden "a transcrição antiga exata". O golden deve codificar o resultado exigido, as invariantes permitidas e o modo de falha.

  7. Acrescenta primeiro verificações determinísticas. Ordem obrigatória de ferramentas quando a ordem é política, argumentos obrigatórios, validação de schema, diffs do estado final, limites de loops, tetos de tokens e latência e invariantes específicas da tarefa devem correr antes de qualquer judge.

  8. Acrescenta um judge com forma SGR. Usa-o apenas para a parte que precisa de interpretação. Calibra-o face a labels humanas. Se não conseguir separar bons de maus exemplos no conjunto de calibração, corrige a rubrica antes de o ligares ao CI.

  9. Liga o ciclo. Corre a pequena suite offline em CI, corre a suite maior antes do release, pontua tráfego de produção amostrado online e promove clusters recorrentes de falhas online de volta para o dataset offline.

A tua primeira suite de evals vai estar errada de formas banais. Envia-a na mesma. Uma suite que corres todos os dias é mais fácil de corrigir do que um documento de design perfeito que nunca bloqueia um mau PR.

Ideias-chave

  1. Evals de agentes são evals de traces. A resposta final é apenas um nó da execução.
  2. Seleção de ferramentas, correção de argumentos, deteção de loops, conclusão da tarefa e fidelidade multi-turn devem ficar em métricas separadas.
  3. O flywheel de produção é trace -> label -> cluster -> dedupe -> dataset -> gate de CI -> score online.
  4. Começa pelo determinístico. Verificações de ferramentas, argumentos, estado e detetores de loops são mais baratos e mais estáveis do que judges.
  5. Juízes LLM precisam de estrutura e calibração. Usa SGR para vereditos reproduzíveis e inspecionáveis, depois fixa o modelo do judge, prompt, schema, versão do dataset, versão da app e amostra de labels humanas.
  6. Evals offline fazem gating de casos conhecidos antes do release. Evals online extraem traces de produção amostrados depois da resposta. Guardrails bloqueiam comportamento inseguro inline.
  7. A maioria das equipas precisa de um trace store e de um runner de CI. Escolhe ferramentas aborrecidas que transformem rapidamente falhas de produção em testes de regressão.

Referências