AWS Builder Center

Agentes em Produção: o que sua observabilidade não vê

Traces mostram o que o agente fez, não se estava certo. Veja por que times erram na avaliação de agentes e como montar um sistema que funciona.

Times que operam agentes em produção chegam ao mesmo ponto: o dashboard está verde, o agente completa as fases, os traces aparecem no OTEL. E mesmo assim, algo está errado nas respostas.
Esse é o gap que observabilidade sozinha não fecha. Você vê que uma ferramenta foi chamada, mas não se era a ferramenta certa para aquele contexto. Você vê que uma fase completou, mas não se o output estava correto. O agente terminou, mas atingiu o objetivo?
A distinção importa porque agentes com acesso a múltiplas ferramentas têm um espaço de falha muito maior que uma API convencional. Um erro em pricing lookup que o LLM substitui por uma estimativa baseada em dados de treino não gera exceção, não aparece no trace. Aparece na recomendação errada que chegou ao usuário.
O problema com revisão manual
Revisão manual funciona no começo. Você roda o agente, lê o output, verifica se faz sentido. Mas esse processo não é reproduzível. Quando você troca o modelo, ajusta um prompt ou redefine uma tool, não existe garantia de que a inspeção manual vai capturar a regressão que você introduziu. O que falta é automação com critério claro: o agente chamou as ferramentas certas, com os parâmetros certos, e produziu um resultado que corresponde ao objetivo?
Desenvolvimento e produção pedem coisas diferentes
Durante o desenvolvimento, o objetivo é feedback rápido. Frameworks como o DeepEval permitem definir quais ferramentas eram esperadas para uma tarefa e avaliar via LLM-as-judge se o agente cumpriu o objetivo. Mockar as dependências externas não é atalho, é a escolha correta. Você quer testar o comportamento do agente, não se a AWS retornou os mesmos dados de ontem. Com mocks controlados, o cenário é reproduzível e seguro para CI/CD sem expor dados reais de conta.
Um detalhe que passa despercebido: o modelo que julga não deveria ser o mesmo que executa. Um juiz da mesma família tende a validar as próprias escolhas. Usar um modelo de família diferente como árbitro reduz esse viés de forma significativa.
Em produção, o problema muda. Tráfego real traz edge cases que nenhum mock antecipou, e LLMs são não-determinísticos. Rodar uma avaliação uma vez não diz nada útil. O que diz algo é avaliar continuamente, acumular scores ao longo de muitas sessões e identificar padrões. O Amazon Bedrock AgentCore Evaluations integra via OpenTelemetry, amostra o tráfego de produção e agrega os resultados em dashboards que revelam deriva de comportamento ao longo do tempo.
Quando começar
O momento em que evals têm mais valor é quando você ainda está iterando em prompts, trocando modelos e ajustando definições de ferramentas. É exatamente quando uma regressão é mais fácil de introduzir e mais difícil de perceber sem automação. Esperar o agente estar em produção para começar a avaliar significa descobrir os problemas pela via mais custosa.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article