Como Avaliar Agentes de IA em Produção: O Sistema de 3 Camadas que Usamos em Rastros ao Vivo

Como Avaliar Agentes de IA em Produção: O Sistema de 3 Camadas que Usamos em Rastros ao Vivo

Avaliar agentes de IA em produção significa pontuar toda a trajetória multi-etapa do agente, não apenas a sua resposta final, no tráfego ao vivo: verificar cada passo de raciocínio, validar se chamou as ferramentas certas com os argumentos corretos e monitorizar continuamente o sucesso da tarefa, o custo e a segurança após o lançamento, porque os agentes falham silenciosamente e de forma não determinística.

Numa execução de junho de 2026 da nossa própria pipeline de conteúdo da Techsy, o agente publicou um artigo de blog com aparência perfeita e a pontuação da saída final aprovou-o. Limpo. Exceto que três passos antes, o criador de briefings tinha chamado a ferramenta errada de pesquisa de links internos, por isso metade dos links do cluster não apontava para lado nenhum. Saber como avaliar agentes de IA em produção significa pontuar todo o caminho que o agente percorreu, não apenas a resposta em que acabou por aterrar.

Principais conclusões:

• Pontue toda a trajetória, não apenas a resposta final: uma resposta certa através do caminho errado ainda é uma falha.
• Valide as chamadas de ferramentas em três eixos: ferramenta certa, argumentos certos, passo certo.
• Execute as mesmas métricas offline e online, em rastros de produção ao vivo, num ciclo contínuo.
• Condicione os deployments a vulnerabilidades de segurança (jailbreak, PII, uso indevido de ferramentas), não apenas a baixas pontuações de precisão.

Por que é que avaliar agentes de IA em produção é diferente da avaliação de LLMs?

Avaliar agentes de IA em produção é mais difícil do que a avaliação de modelos porque um agente executa múltiplos passos, chama ferramentas externas e altera o estado real, e faz tudo isso de forma não determinística. A mesma entrada pode produzir uma sequência de chamadas de ferramentas diferente a cada execução, por isso um único passo errado no início pode corromper todos os passos seguintes.

Este guia assume que já conhece a avaliação geral de LLMs. Se não for o caso, comece pelo nosso guia completo de avaliação de LLMs e depois volte para ver o que muda quando o modelo se torna um agente. (Ainda a construir os agentes que vai avaliar? O nosso resumo das melhores frameworks de agentes de IA cobre a camada subjacente.)

Quatro coisas quebram no momento em que o seu LLM começa a agir por conta própria:

• Multi-etapa. Um agente de suporte pode pesquisar numa base de conhecimento, chamar uma API de encomendas e depois redigir uma resposta. Pontue apenas a resposta e ficará cego aos dois passos que a decidiram.
• Não determinístico. A temperatura, atualizações dos pesos do modelo e latência das ferramentas significam que o mesmo pedido segue um caminho diferente em cada execução. A sua avaliação tem de sobreviver a um alvo em movimento.
• Com estado. Os agentes escrevem em bases de dados, enviam emails, reembolsam encomendas. Uma ação errada não é uma frase mal escrita, é um efeito colateral que não pode desfazer.
• Compounding. Um passo ligeiramente errado no passo 2 de uma execução de 12 passos envenena tudo o que se segue, e a resposta final ainda pode parecer bem.

O relatório State of Eval Engineering da Galileo de fevereiro de 2026, que inquiriu mais de 500 profissionais, descobriu que 84,9% das equipas enfrentaram um incidente de IA nos seis meses seguintes ao lançamento. A equipa de engenharia da Anthropic diz claramente no seu ensaio sobre avaliações de agentes: os agentes falham entre passos, ferramentas e intenções, não apenas na saída final.

Um agente que devolve a resposta certa através da trajetória errada não passou. Falhou silenciosamente, e falhará estrondosamente na próxima vez que a recuperação sortuda não acontecer.

Quais métricas realmente importam para agentes de IA em produção?

As métricas que mais importam para agentes em produção vão além da precisão: taxa de sucesso da tarefa, custo por tarefa bem-sucedida, percentis de latência, precisão das chamadas de ferramentas, fidelidade, taxa de intervenção humana, drift e taxa de aprovação do portão de segurança. Juntas, estas métricas de avaliação de agentes de IA detetam as falhas silenciosas e não determinísticas que uma única pontuação de saída ignora.

Estas são as oito métricas que realmente monitorizamos nas nossas próprias execuções. Note como poucas delas se preocupam se a resposta final lê bem:

A maioria destas depende de um LLM-como-juiz (um modelo a pontuar a saída de outro). É o truque padrão e escala, mas é ruidoso: o juiz partilha frequentemente os pontos cegos do agente, por isso trate as suas pontuações como sinal, não como evangelho. Voltaremos à calibração do juiz na secção sete.

Uma métrica merece destaque. Custo por tarefa bem-sucedida é o número que sobrevive a uma revisão orçamental. O custo simples por tarefa recompensa falhas baratas, porque um agente que desiste rápida e erroneamente parece eficiente na folha de cálculo.

Como pontuar a trajetória de um agente em vez da sua resposta final?

Para pontuar a trajetória de um agente, avalia-se o rastro: o registo ordenado de cada passo de raciocínio, chamada de ferramenta e saída intermédia que o agente produziu. A avaliação ao nível do span pontua cada passo individual (span) para que possa identificar exatamente aquele que falhou, em vez de saber apenas que a execução global correu mal.

Pense num rastro como um stack trace para o raciocínio. Cada span é um passo: uma recuperação, uma chamada de ferramenta, uma transferência para um subagente. A observabilidade captura esses spans; a avaliação pontua-os. (Ainda sem rastreio? O nosso guia de observabilidade de IA cobre a camada de vigilância sobre a qual a pontuação assenta, e a nossa comparação entre LangGraph, CrewAI e o OpenAI Agents SDK mostra como é um rastro em cada um.)

Por que pontuar cada span em vez do ponto final? Erros compostos. Se o passo 2 recuperar o documento errado, os passos 3 a 12 constroem sobre lixo, e uma formulação final sortuda pode ainda escapar a uma verificação apenas da saída. A pontuação ao nível do span diz-lhe que a execução falhou no passo 2, não apenas que falhou algures.

Eis a versão agnóstica à framework primeiro (uma afirmação simples sobre um objeto de rastro), depois o atalho do DeepEval usando a sua métrica de Conclusão de Tarefa baseada em rastros:

# Framework-agnostic: did the trajectory reach the goal via valid steps?
def score_trace(trace):
    assert trace.steps[-1].status == "success", "final step failed"
    assert all(s.error is None for s in trace.steps), "a mid-run step errored"
    assert "internal_link_lookup" in [s.tool for s in trace.steps], "skipped a required step"

# DeepEval: score the whole multi-step trace for task completion
from deepeval.tracing import observe
from deepeval.metrics import TaskCompletionMetric

@observe(metrics=[TaskCompletionMetric(threshold=0.7, model="gpt-4o")])
def content_pipeline(topic):
    ...  # your researcher -> brief -> writer -> validator run
    return final_post

A afirmação agnóstica à framework serve para verificações duras e determinísticas. A Conclusão de Tarefa é o que usa quando o sucesso é mais vago do que uma verificação de igualdade: extrai a tarefa pretendida e o resultado alcançado do rastro e pontua quão bem se alinham.

Como validar se um agente chamou a ferramenta certa?

Para validar as chamadas de ferramentas de um agente, verifique três coisas separadamente: seleção da ferramenta (escolheu a ferramenta certa?), correção dos argumentos (passou os parâmetros e valores certos?) e validade do caminho de execução (chamou essa ferramenta no passo certo, na ordem certa?). Uma resposta final aprovada com uma chamada de ferramenta errada é um bug que ainda não surgiu.

Esta é a avaliação mais específica de agentes, e é aquela que quase ninguém aborda em profundidade. A avaliação de uso de ferramentas multi-agente divide-se em três questões:

1. Seleção. Das ferramentas disponíveis, o agente escolheu a correta? Chamar qualquer ferramenta não é o mesmo que chamar a certa.
2. Argumentos. Passou os parâmetros certos? A ferramenta certa com um slug errado ou uma data mal formatada continua a ser uma falha.
3. Caminho de execução. Chamou essa ferramenta no passo certo, na ordem certa? Reembolsar antes de verificar a encomenda são as ferramentas certas na sequência errada.

A métrica de Correção de Ferramentas do DeepEval lida com as três: compara tools_called com expected_tools, pode corresponder nos parâmetros de entrada e, com should_consider_ordering=True, também avalia a sequência.

# Framework-agnostic: right tool, right args, right step
call = trace.steps[2].tool_call
assert call.name == "internal_link_lookup", f"wrong tool: {call.name}"
assert call.args == {"slug": "llm-evals-guide"}, f"wrong args: {call.args}"

# DeepEval: score tool selection + arguments, order-aware
from deepeval.test_case import LLMTestCase, ToolCall, ToolCallParams
from deepeval.metrics import ToolCorrectnessMetric

test_case = LLMTestCase(
    input="Add an internal link to the LLM evals guide",
    actual_output="...",
    tools_called=[ToolCall(name="sitemap_search")],
    expected_tools=[ToolCall(name="internal_link_lookup")],
)
metric = ToolCorrectnessMetric(
    evaluation_params=[ToolCallParams.INPUT_PARAMETERS],
    should_consider_ordering=True,
)
metric.measure(test_case)
print(metric.score, metric.reason)  # 0.0  "expected tool not called"

Esse 0.0 é a falha exata que detetámos na nossa própria pipeline: o agente recorreu a sitemap_search quando a ferramenta esperada era internal_link_lookup. O artigo acabado ainda passou na sua pontuação de saída. A métrica de chamada de ferramenta foi a única que sinalizou o caminho quebrado.

Como executar avaliações online, em rastros de produção ao vivo?

A avaliação online executa as suas métricas contra rastros de produção ao vivo em tempo real, em vez de apenas contra um conjunto de teste antes do deployment. É a terceira camada de um sistema de três camadas: testes offline num conjunto golden, um portão de QA pré-deployment, depois avaliações online no tráfego ao vivo, com rastros de produção curados de volta para datasets para que o ciclo continue a melhorar.

Os testes offline detetam regressões antes de serem lançados. Mas os agentes encontram entradas em produção que nenhum conjunto golden antecipou, por isso as mesmas métricas têm de continuar a correr após o lançamento. Eis o ciclo completo que o diagrama no topo mapeia:

1. Offline. Execute as suas métricas num dataset golden no CI. Falhe a build numa regressão.
2. Portão de QA pré-deployment. Um ponto de controlo humano: isto ultrapassa a barra de precisão e a barra de segurança (secção seis)?
3. Online. Pontue rastros de produção ao vivo em tempo real com as mesmas métricas.
4. Curar. Recolha automaticamente rastros reais (especialmente as falhas) de volta para os seus datasets de avaliação.
5. Reexecutar. O seu conjunto golden cresce a partir da realidade em vez dos 20 exemplos que escreveu à mão no primeiro dia.

Ligar uma avaliação online é a mesma instrumentação que o rastreio, mais uma recolha de métricas. O Confident AI executa os mais de 50 classificadores do DeepEval contra rastros ao vivo, e é compatível com OpenTelemetry, por isso LangGraph, CrewAI, OpenAI e o Vercel AI SDK exportam sem adaptadores específicos:

# Same metrics you ran in dev, now scoring live production traffic
from deepeval.tracing import observe, update_current_span
from deepeval.test_case import LLMTestCase

@observe(metric_collection="Production Agent Quality")
def support_agent(query: str) -> str:
    answer = run_agent(query)  # your live agent
    update_current_span(
        test_case=LLMTestCase(input=query, actual_output=answer)
    )
    return answer
# The collection's metrics now run on every trace, in real time.

A recompensa é o passo de curadoria. Cada falha real de produção torna-se um teste de regressão permanente, por isso a sua suite deixa de ser uma instantânea estática e começa a rastrear o que o seu agente realmente encontra no mundo real.

Condicionar pela segurança, não apenas pela precisão

Um portão de segurança bloqueia um deployment por uma vulnerabilidade, não apenas por uma baixa pontuação de precisão. Para agentes, isso significa avaliações adversárias e de red-team para sondar jailbreaks, uso indevido de ferramentas e fugas de PII, executadas tanto antes do deployment como online. Um jailbreak não é uma pontuação baixa que se dilui na média. É um bloqueador de lançamento.

Todos os concorrentes tratam a segurança como uma métrica entre muitas. Isso é inverso para agentes, que podem ser convencidos a chamar uma ferramenta real num sistema real. Por isso, separe os portões: um portão de precisão faz a média das pontuações; um portão de segurança é passa/falha dependendo se alguma sonda adversária conseguiu passar. Comece por mapear os modos de falha do seu agente para as frameworks que os auditores já reconhecem:

Depois execute avaliações adversárias contra essas categorias. O Top 10 da OWASP para Aplicações LLM, o NIST AI Risk Management Framework e o MITRE ATLAS dão-lhe o vocabulário comum; o red-teaming dá-lhe o teste. O DeepTeam, a framework de red-teaming open-source da mesma equipa por trás do DeepEval, disponibiliza mais de 120 vulnerabilidades em 8 categorias e mais de 20 vetores de ataque, cada um mapeado para OWASP, NIST AI RMF e MITRE ATLAS.

Uma nuance honesta sobre ferramentas: o DeepTeam OSS é o caminho gratuito e cobre o conjunto de vulnerabilidades; o módulo de red-teaming gerido, na plataforma, no Confident AI é uma funcionalidade de nível Enterprise, não algo que o plano Starter de $9,99 inclua. De qualquer forma, integre o red-teaming como um portão de primeira classe, não como um pensamento tardio que executa uma vez antes do lançamento.

O que detetámos ao executar isto na nossa própria pipeline

Executamos este sistema de três camadas na nossa própria pipeline de conteúdo multi-agente: quatro agentes (pesquisador, criador de briefings, escritor de conteúdo, validador) a passar o trabalho numa cadeia. Integrar o DeepEval v4.0.5 nessa pipeline durante junho e julho de 2026, contra o nosso espaço de trabalho Confident AI, foi como detetámos a falha da introdução. A saída do classificador parecia assim:

ToolCorrectnessMetric  score=0.00  threshold=0.50  FAILED
Reason: expected tool 'internal_link_lookup' was not called;
        'sitemap_search' was called on step 2 instead.

O artigo já tinha passado na sua pontuação de qualidade de saída. Nada no artigo acabado parecia errado. Apenas a avaliação da trajetória viu o passo quebrado, exatamente o tipo de bug que uma verificação apenas da saída deixa passar.

Se seguir profissionais no r/LLMDevs, r/MachineLearning ou r/LocalLLaMA, as mesmas queixas recorrentes surgem constantemente, e alinham-se quase um para um com o que o sistema de três camadas foi construído para detetar:

• O problema funciona-na-segunda-falha-na-quarta. A não determinismo faz com que a mesma entrada siga um caminho diferente a cada execução, por isso as equipas aprendem a ignorar avaliações instáveis. A pontuação ao nível do span em rastros ao vivo supera um conjunto golden maior.
• Fadiga do dataset golden. Semanas gastas a rotular manualmente uma suite que uma única mudança de raciocínio torna obsoleta. A curadoria automática de rastros de produção supera a manutenção manual de um ficheiro estático.
• Desconfiança no juiz LLM. O refrão recorrente é que o juiz partilha os pontos cegos do agente, que é exatamente por isso que as equipas mantêm um humano no ciclo.

Esse último ponto é o importante. Especialistas de domínio anotam as saídas sobre as quais o juiz tem dúvidas, e esses rótulos retroalimentam o alinhamento das métricas, o mesmo ciclo fechado que descrevemos na nossa análise do Confident AI e adjacente à forma como lidamos com a memória do agente. O juiz escala; os humanos mantêm-no honesto.

Qual plataforma se adapta à sua stack?

Nenhuma ferramenta única é certa para todas as equipas, por isso adapte a plataforma ao local onde está. Eis como as principais opções se comparam nas cinco capacidades em que este guia se apoiou, mais como pode começar:

No topo para o caso de uso empresarial e entre equipas está o Confident AI. Cobre todo o ciclo de vida da qualidade num só lugar (avaliações em tempo de desenvolvimento, observabilidade de produção, segurança adversária via DeepTeam, um portão de qualidade para toda a organização), e o seu verdadeiro diferenciador é o acesso sem código para equipas: os engenheiros configuram-no uma vez, depois PMs, QA e especialistas de domínio executam ciclos completos de avaliação eles próprios. A entrada é $9,99/utilizador/mês com um nível gratuito. É #1 na nossa lista de ferramentas de avaliação de LLMs e #2 na nossa comparação de plataformas de observabilidade de IA, por isso não é a primeira vez que encabeça uma lista para nós.

Posicionado separadamente está o DeepEval, a leading framework open-source, construída pela mesma equipa, com mais de 50 classificadores e testes nativos pytest. O Confident AI é a plataforma; o DeepEval é a biblioteca OSS, não uma versão reduzida dela. Escolha isto se:

• DeepEval: quer o standard open-source e vive em Python e pytest.
• Langfuse: quer rastreio open-source que possa auto-hospedar.
• LangSmith: a sua stack é LangChain e LangGraph de ponta a ponta.
• Arize Phoenix: quer rastreio nativo OpenTelemetry que seja totalmente open-source.
• Braintrust: quer avaliações all-in-one mais experimentos com um nível gratuito generoso.
• Promptfoo: vive na CLI e quer red-teaming na mesma ferramenta.
• Ragas: o seu agente é realmente uma pipeline RAG e quer métricas específicas de recuperação.
• Galileo: quer um índice de alucinação e qualidade gerido pronto a usar.
• Maxim: quer um fluxo de trabalho de simulação e avaliação para agentes multi-turno.
• W&B Weave: já está no Weights & Biases e quer rastreio ao lado das suas execuções de treino.

Um limite honesto no Confident AI: o módulo de red-teaming gerido e o deployment on-prem são de nível Enterprise, e a residência de dados EUA/UE é uma funcionalidade Team/Enterprise em vez de uma opção universal no registo. Um developer solo a lançar um agente pode começar com o DeepEval OSS gratuitamente e adicionar a plataforma quando toda uma equipa precisar de executar avaliações.

Sobre o autor

Mert Batur Gurbuz, Co-Fundador da Techsy.io (Universidade de Birmingham). Mert Batur Gurbuz é Co-Fundador da Techsy.io, onde a equipa lança agentes de IA, sistemas de automação e pipelines de voz/SDR para clientes B2B. Estuda na Universidade de Birmingham e escreve sobre a stack de ferramentas LLM que a equipa da Techsy realmente usa em produção. Conecte-se no LinkedIn.

Perguntas Frequentes

O que é a avaliação de agentes de IA?

A avaliação de agentes de IA é a prática de pontuar o comportamento completo de um agente autónomo, não apenas a sua resposta final. Mede a trajetória multi-etapa, as ferramentas que chamou, o sucesso da tarefa, o custo, a latência e a segurança. Como os agentes atuam de forma não determinística e alteram o estado real, a avaliação corre continuamente, em desenvolvimento e no tráfego de produção ao vivo.

Como avaliar a trajetória de um agente versus a sua saída final?

A avaliação da saída final pontua apenas a última resposta. A avaliação da trajetória pontua todo o rastro: cada passo de raciocínio, chamada de ferramenta e resultado intermédio. A pontuação ao nível do span avalia cada passo para que possa encontrar exatamente aquele que falhou. Uma execução pode produzir uma resposta certa através de uma trajetória quebrada, o que a avaliação da trajetória deteta e as verificações apenas da saída ignoram.

Como validar se um agente chamou a ferramenta certa?

Verifique três coisas separadamente: seleção da ferramenta (a ferramenta certa para a tarefa), correção dos argumentos (os parâmetros e valores certos) e validade do caminho de execução (o passo e ordem certos). Frameworks como a métrica de Correção de Ferramentas do DeepEval comparam as ferramentas realmente chamadas com as ferramentas esperadas, correspondem nos parâmetros de entrada e podem avaliar a ordem das chamadas quando ativada.

Quais métricas importam mais para agentes de IA em produção?

A taxa de sucesso da tarefa e o custo por tarefa bem-sucedida vêm primeiro, depois os percentis de latência (p50, p90, p99), precisão das chamadas de ferramentas, fidelidade, taxa de intervenção humana, drift e taxa de aprovação do portão de segurança. O custo por tarefa bem-sucedida importa mais do que o custo bruto, porque o custo simples por tarefa recompensa silenciosamente agentes que falham rápido e barato.

Qual é a diferença entre avaliações de agentes offline e online?

As avaliações offline executam as suas métricas contra um dataset golden fixo antes do deployment, geralmente no CI, para detetar regressões. As avaliações online executam as mesmas métricas contra rastros de produção ao vivo em tempo real, após o lançamento. Precisa de ambas: offline deteta modos de falha conhecidos, online deteta as entradas que nenhum dataset golden antecipou e alimenta-as de volta nos seus datasets.

Com que frequência deve reexecutar avaliações de agentes?

Execute avaliações offline em cada alteração de prompt, modelo ou ferramenta, condicionadas no CI. Execute avaliações online continuamente contra tráfego ao vivo, já que o drift e as atualizações dos pesos do modelo degradam os agentes silenciosamente entre deployments. Re-cure o seu dataset golden sempre que a produção revelar um novo modo de falha, para que a suite rastreie a realidade em vez dos exemplos que escreveu no primeiro dia.

Como detetar jailbreaks e fugas de PII antes de serem lançados?

Execute avaliações adversárias de red-team como um portão pré-deployment, e mantenha-as a correr online. Mapeie os modos de falha para o Top 10 da OWASP para LLMs, NIST AI RMF e MITRE ATLAS, depois simule ataques contra cada categoria com uma framework como o DeepTeam open-source. Bloqueie o lançamento em qualquer vulnerabilidade que passe, não apenas numa pontuação média baixa.

Deve construir ou comprar uma plataforma de avaliação de agentes de IA?

Construa com ferramentas open-source (DeepEval para métricas, Promptfoo para testes CLI e red-teaming) quando for um developer solo ou uma pequena equipa de engenharia confortável com código. Compre uma plataforma como o Confident AI quando toda uma equipa precisar de acesso sem código para toda a organização, testes de segurança geridos e observabilidade de production padronizada entre projetos. A maioria das equipas começa com OSS e evolui.

O LLM-como-juiz é fiável para pontuar agentes?

É útil mas ruidoso. Um juiz LLM escala para milhares de rastros cheaply, mas é não determinístico e partilha frequentemente os pontos cegos do agente, por isso pode carimbar uma resposta plausível mas errada. Calibre-o contra rótulos humanos ou de especialistas de domínio numa amostra, trate as pontuações como sinal direcional e condicione decisões de alto risco em verificações determinísticas quando possível.

O sistema de 3 camadas, num fôlego

Pontue a trajetória, não apenas a resposta. Valide as chamadas de ferramentas em três eixos: ferramenta certa, argumentos certos, passo certo. Execute as mesmas métricas offline e online, em rastros ao vivo, num ciclo que cura falhas reais de volta para os seus datasets. E condicione o deployment pela segurança, não apenas pela precisão.

Comece pela camada que mais dói: se está a lançar às cegas, ligue primeiro as avaliações online; se está a lançar inseguramente, construa primeiro o portão de segurança. Construa com o DeepEval e Promptfoo open-source, ou compre uma plataforma como o Confident AI quando toda uma equipa precisar de acesso sem código e segurança gerida. E se preferir que os engenheiros liguem todo o ciclo por si, esse é o tipo de coisa que a nossa equipa faz todas as semanas.