Como eu meço se um agente de IA está realmente funcionando

Sumário

Atualizado maio 2026.

TL;DR: A maioria dos operadores pula as avaliações e simplesmente assume que seus agentes funcionam. Meu framework: construir um golden set de 5–10 entradas conhecidas com saídas esperadas, definir critérios aprovado/reprovado em linguagem simples e verificar logs semanalmente. Não construa um sistema de avaliação elaborado antes de ter 10 execuções reais — essa é a armadilha que mata o momentum.

[Perspectiva do operador] Gerencio mais de 30 agentes de IA em produção na minha marca de consultoria e no Pickleland, uma instalação de pickleball em Pflugerville, TX. Em algum momento percebi que estava gastando mais tempo me preocupando se os agentes estavam derivando do que realmente usando-os. Este é o framework de avaliação no qual me estabilizei — sem doutorado necessário, sem plataforma de avaliação personalizada, sem Python.

O problema sobre o qual ninguém fala: agentes derivam silenciosamente

Quando um funcionário humano começa a fazer seu trabalho errado, você geralmente percebe. Quando um agente de IA começa a produzir resultados ruins, ele continua produzindo resultados ruins — silenciosamente, em escala, até que algo quebre mal o suficiente para que um humano finalmente olhe.

Tive um agente de conteúdo que começou a adicionar disclaimers “Como modelo de linguagem de IA” após uma atualização do modelo. Tive um agente promotor de eventos que parou de incluir links de ingressos porque um nome de variável de prompt mudou. Nenhum falhou ruidosamente. Ambos simplesmente se degradaram.

A solução não é construir um sistema de monitoramento nível NASA. É ter uma verificação simples e repetível que detecte desvios antes que se acumulem.

O que é realmente uma avaliação (para operadores)

Engenheiros usam a palavra “eval” para executar um benchmark em um modelo. Para operadores, quero dizer algo mais simples: um teste repetível que diz se seu agente ainda está fazendo o que você o construiu para fazer.

Três componentes:

1. Golden set — 5–10 entradas reais que você já viu, com saídas esperadas que você já sabe que são boas
2. Critérios aprovado/reprovado — regras em linguagem simples para o que conta como aprovado
3. Uma verificação agendada — você ou seu assistente realmente executa o teste em uma cadência

Só isso. Você não precisa de um framework. Você precisa de disciplina.

Construindo seu golden set

Extraia dos seus logs de produção. Encontre 5–10 entradas reais onde você já sabe como uma boa saída parece. Esses são sua verdade fundamental.

Para meu agente de pipeline de conteúdo, o golden set é 5 posts publicados que passaram no meu checklist de voz quando os escrevi manualmente. Para meu promotor de eventos Pickleland, são 5 posts anteriores do Facebook com engajamento acima da média (comentários + compartilhamentos, não apenas curtidas).

Regras para um bom golden set:

• Entradas reais, não hipóteses que você inventou
• Incluir pelo menos um caso limite (uma entrada complicada, curta, ou com formatação incomum)
• Manter as saídas esperadas documentadas — uma captura de tela, um arquivo de texto, uma linha em uma planilha
• Nunca deletar do golden set; apenas adicionar

Quando o agente foi confirmado como funcionando pela última vez, escreva exatamente como “bom” parecia. Isso se torna sua saída esperada.

Definindo critérios aprovado/reprovado

Critérios vagos são inúteis. “A saída deve ser boa” passará sempre porque você vai racionalizar.

Escreva seus critérios como itens de checklist que um não-especialista poderia avaliar. Aqui estão os critérios reais que uso para meu agente de pipeline de conteúdo:

Checklist aprovado/reprovado do agente de conteúdo:

• Post tem um TL;DR nas primeiras 100 palavras
• Sem frases como “no acelerado mundo de hoje” ou “Como IA”
• Pelo menos um número concreto ou estatística
• Contagem de palavras entre 800 e 2000
• Todos os links internos resolvem (sem erros 404)

Para o promotor de eventos Pickleland:

Checklist aprovado/reprovado do promotor de eventos:

• Nome do evento corresponde ao calendário fonte
• Data e hora estão corretas
• Link de ingresso está presente e não está quebrado
• Texto tem menos de 280 palavras
• Post não usa frases genéricas de preenchimento

Se 4 de 5 itens do checklist passam, a execução é aprovada. Se 3 ou menos passam, é reprovada e investigo antes da próxima execução.

Usando Claude como juiz

Para agentes com saídas longas ou complexas, uso Claude Sonnet como juiz automatizado. É mais rápido do que revisão manual e detecta coisas que eu passaria batido.

Aqui está o prompt de juiz que uso para o agente de conteúdo:

You are evaluating a blog post written by an AI agent. Your job is to check whether it meets the operator's standards.

Evaluate the following post against these criteria:
1. Starts with a direct answer or TL;DR in the first 100 words (YES/NO)
2. Contains at least one concrete number or specific example (YES/NO)
3. Free of AI-speak filler ("As an AI", "in today's fast-paced world", "delve", "it's worth noting") (YES/NO)
4. Word count is between 800 and 2000 words (YES/NO)
5. Tone matches the reference: direct, first-person, opinionated, no fluff (YES/NO)

For each criterion, respond YES or NO with one sentence of explanation.
At the end, output PASS if 4 or 5 criteria are YES, FAIL otherwise.

Post to evaluate:
---
{{post_content}}
---

Executo isso como um Cloudflare Worker que puxa o último rascunho, dispara esse prompt e escreve o resultado em uma Google Sheet. O processo todo leva 8 segundos e custa cerca de $0,003 por execução.

Para o promotor de eventos, o prompt do juiz é mais simples:

You are checking an AI-generated Facebook event post for accuracy and quality.

Source data:
- Event name: {{event_name}}
- Date: {{event_date}}
- Time: {{event_time}}
- Ticket URL: {{ticket_url}}

Generated post:
---
{{generated_post}}
---

Check:
1. Does the post correctly state the event name? (YES/NO)
2. Does the post correctly state the date and time? (YES/NO)
3. Does the post include the exact ticket URL? (YES/NO)
4. Is the post under 280 words? (YES/NO)
5. Is the tone inviting without using generic filler phrases? (YES/NO)

Output PASS if all 5 are YES, FAIL if any are NO. List which items failed.

Onde olhar: logs do Cloudflare Worker

Se você estiver executando agentes em Cloudflare Workers (o que faço para a maioria dos meus agentes leves), o log tail integrado é seu melhor amigo. Você não precisa de um serviço de logging de terceiros para começar.

O que verifico em revisões pontuais semanais:

• Erros e exceções — qualquer coisa que travou ou expirou
• Contagens de tokens — se uma execução repentinamente usa 3x os tokens normais, algo mudou
• Picos de latência — uma desaceleração repentina geralmente significa que o prompt ficou maior ou o modelo está com dificuldades
• Deriva no comprimento da saída — se a saída média caiu de 600 para 200 palavras, o agente mudou de comportamento

Passo 15 minutos toda segunda-feira de manhã nisso. Tenho um checklist simples no Notion: abrir logs para cada agente, notar qualquer anomalia, comparar o uso de tokens com a linha de base da semana passada. Esse é o processo inteiro.

A avaliação em planilha: feia mas funciona

Antes de ter qualquer automação, executava avaliações em uma Google Sheet. Ainda uso isso para novos agentes nas primeiras 4 semanas.

Estrutura:

Cinco linhas por semana. Leva 10 minutos. Se você tiver dois reprovas seguidas, para o agente e corrige o prompt antes de continuar.

Isso é constrangedoramente low-tech. Também é assim que detectei três regressões de prompt antes de chegarem à produção.

O que NÃO fazer

Não construa o sistema de avaliação antes de ter 10 execuções reais. Vi fundadores passarem duas semanas construindo um pipeline de avaliação sofisticado para um agente que só executaram duas vezes. Você não sabe o suficiente sobre como “bom” parece até ter dados reais de produção.

Não avalie com entradas sintéticas que você inventou. Casos de teste sintéticos perdem os casos limite estranhos que a produção lança em você. Sempre comece com logs reais.

Não avalie tudo. Escolha os 3–5 agentes onde a falha realmente doeria — saídas voltadas ao cliente, qualquer coisa que poste publicamente, qualquer coisa que acione um pagamento. Pule os agentes utilitários internos até ter espaço mental.

Não automatize cedo demais. Uma planilha que você realmente usa supera um dashboard do Datadog que você esquece de verificar. Comece manual, automatize depois de executar a verificação 10 vezes e saber o que realmente está procurando.

A conclusão do operador

Avaliações não precisam ter qualidade de engenharia para ser úteis. Um golden set de 5–10 entradas reais, uma lista de critérios aprovado/reprovado e 15 minutos de verificação de logs toda segunda-feira detectarão 80% da deriva de agentes antes que se acumule. Comece por aí. Se você ainda estiver executando agentes sem nenhuma avaliação, está voando às cegas — e eventualmente algo falhará publicamente o suficiente para que você deseje ter passado os 20 minutos.