• 1 de junho de 2026
• em Inteligência Artificial, Avaliação
• 12 min de leitura

Eval Judge: por que agentes de IA precisam ser avaliados como produtos, não como respostas

Um agente de IA não deve ser avaliado apenas pela fluidez da resposta. Em produção, o que importa é saber se ele roteou corretamente a intenção, seguiu as instruções certas, usou ferramentas no momento adequado e respeitou os limites de escopo e identidade.

No caso do Playbook 2.0, por exemplo, o agente pode acertar o roteamento para a etapa inicial, mas ainda falhar se não executar a saudação institucional pela ferramenta obrigatória. O Eval Judge existe para isso: transformar cada execução em um sinal objetivo de qualidade.

A maioria dos times começa tentando melhorar agentes de IA pelo prompt. Os melhores times começam medindo comportamento.

Este artigo explica o Eval Judge, o módulo de avaliação do Playbook 2.0, e mostra por que ele é necessário para agentes em produção. Também conecta a proposta com pesquisas sobre LLM-as-a-Judge, avaliação fine-grained e aprendizado contínuo.

Os artigos citados aqui não descrevem o Eval Judge diretamente. Eles oferecem a base técnica para os problemas que o sistema foi desenhado para resolver.

1. O problema de confiar só na resposta

Em uma demonstração, um agente de IA parece bom quando produz uma resposta fluida, coerente e educada. O problema é que produção não é demo.

Em produção, o agente opera em um ambiente com regras de negócio, identidade de marca, protocolos de etapa, ferramentas obrigatórias e canais com restrições de formato. Responder bem não é o suficiente. É preciso responder certo — na etapa certa, com a ferramenta certa, dentro do escopo certo.

Considere o caso de um agente configurado para atendimento comercial no WhatsApp. Ele recebe uma saudação como "Boa noite". O roteamento funciona: o sistema identifica corretamente a intenção inicial e direciona para a etapa de abertura. O agente responde "Como podemos te ajudar hoje?" de forma educada e contextual. Tudo parece correto.

Mas a execução foi incompleta. O playbook determinava que, na abertura, o agente deveria usar uma ferramenta obrigatória de saudação institucional — e ele não usou. A resposta estava correta no conteúdo, mas falhou no protocolo operacional.

Esse caso ilustra um ponto central deste artigo: um agente pode responder certo e ainda assim executar errado.

Sem um sistema de avaliação estruturada, esse tipo de falha passa despercebido. O time vê uma resposta fluida e assume que está tudo bem. O diagnóstico só aparece quando um cliente reclama ou quando o funil de vendas começa a cair sem explicação.

É por isso que, em produção, a pergunta certa não é "respondeu bem?", mas "fez o que devia, no momento certo, do jeito certo?".

2. Demo versus produção: por que a avaliação é ignorada

Muitos times de produto ignoram a avaliação sistemática porque o problema não é visível no curto prazo. Durante o desenvolvimento, o agente é testado com cenários controlados. A resposta parece boa. O teste passa. O time avança.

Em produção, porém, o agente enfrenta:

• Variabilidade de entrada: usuários reais escrevem de formas imprevisíveis.
• Mudanças no playbook: regras de negócio mudam e nem sempre são refletidas no comportamento do agente a tempo.
• Deriva de comportamento: atualizações no modelo de linguagem podem alterar respostas sem aviso.
• Ferramentas instáveis: APIs externas falham, mudam de contrato ou ficam lentas.
• Canais assimétricos: o que funciona no CMS pode não funcionar no WhatsApp.

Nenhum desses problemas é detectado por um teste unitário ou por uma inspeção manual de algumas respostas. Eles só aparecem quando cada execução é avaliada de forma sistemática contra as instruções que o agente recebeu.

A literatura sobre LLM-as-a-Judge confirma que a avaliação automatizada é viável, mas exige rubricas claras e mitigação de vieses. Zheng et al. (2023) mostram que modelos fortes podem se aproximar de preferências humanas em avaliações abertas, mas também expõem problemas como position bias, verbosity bias e self-enhancement bias. Gu et al. (2025) propõem um framework de confiabilidade que combina consistência, mitigação de viés e adaptação a cenários diversos — exatamente o que um judge operacional precisa considerar.

O Eval Judge foi desenhado a partir dessas premissas. Ele não tenta substituir o julgamento humano, mas criar uma camada sistemática de avaliação que transforme cada execução em um dado objetivo.

3. O que o Eval Judge realmente avalia

O Eval Judge tem um escopo deliberadamente restrito: ele avalia uma execução isolada do agente contra as instruções compiladas que o agente recebeu para aquela interação.

Isso é diferente de avaliar o diálogo inteiro ou a satisfação do usuário. O judge não pergunta "o usuário ficou satisfeito?". Ele pergunta "o agente fez o que deveria fazer nesta execução?".

Essa restrição de escopo é intencional e tem implicações práticas importantes:

• Foco operacional: a avaliação mede aderência a instruções, não qualidade percebida. Isso torna o resultado mais objetivo e acionável.
• Granularidade: cada execução gera um score individual. Se um agente erra uma ferramenta em uma etapa, o judge detecta, independentemente de o restante do diálogo estar correto.
• Comparabilidade: como o judge segue a mesma rubrica para todas as execuções do mesmo playbook, os scores são comparáveis entre sessões e ao longo do tempo.

O processo é assíncrono e fire-and-forget. Isso significa que o judge é executado em segundo plano, depois que a resposta já foi entregue ao usuário. A avaliação não bloqueia o fluxo síncrono de resposta. O usuário recebe a resposta rapidamente, e a avaliação acontece depois, alimentando métricas, logs e oportunidades de aprendizado.

Na prática, a execução do Eval Judge consome cerca de 5,2 segundos de runtime e utiliza aproximadamente 5.765 tokens de entrada e 557 tokens de saída por avaliação — um custo operacional baixo comparado ao valor do diagnóstico gerado.

4. Os quatro critérios da rubrica

O Eval Judge organiza a avaliação em quatro critérios fixos. Cada critério recebe um score individual de 0 a 10, além de um campo de evidência e uma ação sugerida.

4.1 Intent Analysis (Análise de Intenção)

O primeiro critério verifica se o agente identificou corretamente a intenção do usuário. Ele responde: "O agente entendeu o que o usuário queria fazer?"

Esse critério não avalia o conteúdo da resposta. Ele avalia se o roteamento de intenção estava correto. Se o usuário pergunta sobre preço e o agente roteia para uma etapa de cadastro, a análise de intenção falha, mesmo que a resposta individual seja educada.

Na prática, esse critério depende do classificador de intenção do Playbook 2.0 (Step 4 — Intent Analyst) e da confiança do roteamento. Scores baixos aqui indicam que o agente não entendeu o que o usuário queria — um problema diferente de não saber responder.

4.2 Execution (Execução)

O segundo critério verifica se o agente seguiu as instruções do playbook para aquela etapa. Ele responde: "O agente executou o protocolo correto para esta intenção?"

A execução inclui aspectos como cumprimento do roteiro da etapa, respeito à ordem das subetapas, conclusão de ações obrigatórias e alinhamento com a persona configurada. Uma resposta pode ser fluente e ainda assim falhar na execução se ignorar uma instrução do playbook.

4.3 Tools (Uso de Ferramentas)

O terceiro critério verifica se o agente usou as ferramentas certas no momento certo. Ele responde: "O agente acionou as ferramentas obrigatórias e não acionou ferramentas proibidas?"

Esse critério é especialmente importante em fluxos operacionais. Um agente de vendas pode precisar consultar o estoque, registrar um lead no CRM ou acionar um webhook de agendamento. Ferramentas obrigatórias que não são chamadas representam falha operacional, assim como ferramentas chamadas no contexto errado.

4.4 Guardrails (Limites de Escopo)

O quarto critério verifica se o agente respeitou os limites de escopo, identidade e segurança. Ele responde: "O agente se manteve dentro dos limites definidos?"

Guardrails incluem não se passar por humano, não inventar informações, não executar ações fora do escopo autorizado, não compartilhar dados sensíveis e não fazer promessas que o sistema não pode cumprir. Esse critério é o mais sensível e, na prática, costuma ter o threshold mais rigoroso.

4.5 Score composto e ação sugerida

Cada critério gera três saídas:

• Score: valor numérico de 0 a 10.
• Evidence: explicação textual do que foi observado, justificando o score.
• Suggested Action: recomendação operacional, como "revisar ferramenta obrigatória", "atualizar playbook" ou "monitorar execução".

O score geral não é uma média simples. Ele pode ser ponderado por critério, e o threshold de aprovação é configurável por playbook. Um resultado abaixo do threshold gera um alerta e, em casos de falha recorrente, pode disparar a criação de um learning candidate.

5. O caso real: quando a execução falha apesar da resposta correta

O exemplo de abertura deste artigo merece ser examinado em detalhes porque ele revela o valor real do Eval Judge.

Cenário: Um agente configurado para atendimento comercial recebe a mensagem "Boa noite". O sistema identifica a intenção como IDENTIFICAR_INTENCAO_INICIAL com confiança de 0,95. A sinapse encontrada é IDENTIFICAR_INTENCAO_INICIAL_OPENING. O agente responde "Como podemos te ajudar hoje?".

Avaliação do Eval Judge:

Critério	Score	Análise
Intent Analysis	10	A intenção foi corretamente identificada
Execution	5	A saudação foi verbal, mas não passou pela ferramenta obrigatória
Tools	1	Nenhuma tool foi chamada, contrariando o protocolo
Guardrails	10	A resposta respeitou escopo e identidade

Resultado: Score geral 6,5 (threshold 7,0). Outcome: partial (alerta).

Diagnóstico: O agente entendeu a intenção. Acertou a persona. Acertou o tom. Mas falhou na execução operacional porque ignorou a obrigatoriedade da ferramenta de saudação institucional.

Learning candidate gerado: Reforçar a obrigatoriedade de uso da ferramenta de saudação em aberturas de duas etapas, com validação antes da entrega da resposta.

Esse caso mostra algo que a maioria dos sistemas de avaliação ignora: o problema não foi "entender o que fazer", mas "cumprir o protocolo do playbook".

Em um sistema sem Eval Judge, essa execução passaria despercebida. A resposta é educada. O usuário não reclamou. O time não tem evidência de que algo errado aconteceu. Mas o lead não foi registrado pela ferramenta obrigatória. A informação foi perdida. O funil silenciosamente deixa de funcionar.

O valor do Eval Judge aqui não é gerar uma nota. É separar claramente:

• Roteamento certo (intent analysis = 10)
• Execução incompleta (execution = 5)
• Falta de ferramenta obrigatória (tools = 1)
• Guardrails preservados (guardrails = 10)

Isso mostra maturidade de produto. O time deixa de tratar tudo como "resposta ruim" e passa a diagnosticar o tipo exato de falha.

6. Como a avaliação alimenta melhoria contínua

O Eval Judge não existe isoladamente. Ele é parte do ciclo assíncrono do Playbook 2.0, junto com o Context Memory e o Learning Writer.

O fluxo é:

1. O agente executa uma interação e produz uma resposta.
2. A resposta é entregue ao usuário (fluxo síncrono).
3. Em paralelo, o Eval Judge avalia a execução contra as instruções compiladas.
4. Se o score fica abaixo do threshold, o resultado é registrado com diagnóstico.
5. Se há falha recorrente no mesmo padrão, o sistema gera um learning candidate.
6. O learning candidate é armazenado em uma learning store especializada.
7. Em execuções futuras, o Learning Recall (Step 3) recupera aprendizados relevantes e ajusta o comportamento do agente.

Esse ciclo se alinha com pesquisas sobre aprendizado contínuo em agentes. O Reflexion propõe que agentes melhorem com feedback linguístico armazenado em memória, sem retreinar o modelo a cada ajuste (Shinn et al., 2023). A diferença no Eval Judge é que o feedback não é auto-gerado pelo agente, mas produzido por um judge dedicado, com uma rubrica fixa e explícita.

O Self-Refine explora refinamento iterativo com auto-feedback durante a execução (Madaan et al., 2023). No Eval Judge, o refinamento acontece entre execuções, não durante — o que é mais realista para ambientes de produção onde latência é crítica.

A separação entre execução e avaliação também permite que diferentes pessoas participem do ciclo. O time de produto pode revisar learning candidates e aprovar mudanças no playbook. O time de engenharia pode ajustar rubricas e thresholds. O time de operações pode monitorar scores ao longo do tempo.

Isso conversa com o framework de confiabilidade de Gu et al. (2025), que defende que avaliação automatizada precisa vir acompanhada de governança e intervenção humana quando necessário.

7. Score com significado operacional

Um score de avaliação só tem valor se ele orienta uma decisão. O Eval Judge foi desenhado com essa premissa.

O score geral e os scores por critério alimentam diferentes tipos de decisão:

• Operacional imediato: scores baixos em ferramentas ou execução podem gerar alertas em tempo real para o time de operações.
• Tático (aprendizado): padrões de falha recorrentes geram learning candidates que alteram o comportamento futuro do agente.
• Estratégico (produto): a distribuição de scores ao longo do tempo mostra se o sistema está melhorando, estabilizando ou degradando.

Sem um judge, toda melhora vira opinião. O time ajusta o prompt, testa com alguns exemplos e decide se ficou melhor com base em impressão subjetiva. Com o Eval Judge, o time tem uma base objetiva para comparar versões, testar hipóteses e decidir se uma mudança realmente melhorou a execução.

Isso está alinhado com a abordagem de score rubrics customizados proposta pelo PROMETHEUS (Kim et al., 2024). Os autores mostram que rubricas explícitas e fine-grained produzem avaliações mais alinhadas com juízes humanos do que preferências genéricas. O Eval Judge aplica esse princípio em escala operacional, com uma rubrica fixa de quatro critérios que cobre os aspectos mais críticos da execução de agentes conversacionais.

O trabalho de Saha et al. (2025) no EvalPlanner também reforça a importância de separar o planejamento da avaliação da execução da avaliação. No Eval Judge, essa separação aparece na estrutura do output: primeiro o plano de avaliação (rubrica), depois a execução (scores e evidências), depois o veredito final (ação sugerida).

8. Limites e cuidados

O Eval Judge não é verdade absoluta. É uma camada de avaliação automatizada que precisa de governança e calibração contínua.

Viés de judge. Estudos sobre LLM-as-a-Judge identificam múltiplos vieses que afetam a confiabilidade das avaliações. Zheng et al. (2023) documentam position bias (preferência pela primeira ou última resposta), verbosity bias (preferência por respostas mais longas) e self-enhancement bias (preferência por textos gerados pelo mesmo modelo). Zhu et al. (2025) adicionam knowledge bias e format bias no contexto de fine-tuning de judges.

O Eval Judge mitiga alguns desses vieses pelo design: como avalia uma única execução contra instruções fixas, não há posição de resposta para influenciar o resultado. A rubrica explícita reduz o espaço para preferências arbitrárias. Mesmo assim, o viés do modelo subjacente ao judge não é eliminado — apenas atenuado.

Rubrica não cobre tudo. Quatro critérios não capturam a complexidade total de uma interação conversacional. Aspectos como tom emocional, adequação cultural e criatividade ficam de fora. O Eval Judge cobre o que pode ser verificado contra instruções compiladas. O restante permanece como responsabilidade do design do playbook e da supervisão humana.

Threshold arbitrário. O threshold de 7,0 usado no exemplo é configurável, mas ainda assim arbitrário. Um score 6,5 pode ser aceitável em alguns contextos e crítico em outros. A definição de thresholds por playbook e por critério é uma decisão de produto que precisa ser revisada regularmente.

Custo de avaliação. Embora o custo por avaliação seja baixo (cerca de 5,2 segundos e 6.300 tokens), ele se acumula em escala. Para milhares de execuções por dia, o custo operacional do judge precisa ser monitorado e otimizado. Técnicas como amostragem seletiva (avaliar apenas execuções com baixa confiança) podem reduzir o custo sem perder cobertura.

Aprendizado requer curadoria. Learning candidates gerados automaticamente precisam de revisão antes de alterar o comportamento do agente. A literatura sobre LLM-as-a-Judge recomenda validação humana periódica para calibrar e corrigir desvios (Gu et al., 2025). No Eval Judge, isso é tratado por níveis de confiança, status de aprovação e logs de decisão.

Whitehouse et al. (2025) mostram que é possível treinar judges com RL (GRPO) para desenvolver estratégias sistemáticas de avaliação, incluindo geração dinâmica de critérios e autocorreção iterativa. Essa é uma direção futura promissora para o Eval Judge, mas a versão atual prioriza simplicidade, previsibilidade e baixo custo operacional.

9. Conclusão

O Eval Judge não resolve todos os problemas de avaliação de agentes de IA. Ele resolve o problema mais imediato: criar uma camada sistemática de avaliação que transforme cada execução em um sinal objetivo de qualidade.

A proposta é simples: antes de otimizar um agente, é preciso medir se ele fez o que devia. E medir não significa ler algumas respostas e dar um palpite. Significa comparar cada execução contra instruções compiladas, usando critérios explícitos, gerando scores, evidências e ações sugeridas.

O que diferencia o Eval Judge de abordagens genéricas é o escopo restrito (uma execução, não o diálogo inteiro), a rubrica fixa de quatro critérios, a execução assíncrona e a conexão direta com o ciclo de aprendizado do Playbook 2.0.

Em produtos que usam IA conversacional em produção, a pergunta não é "o modelo é bom?". A pergunta é "cada execução está correta?". O Eval Judge foi construído para responder a segunda pergunta — e, a partir dela, melhorar a primeira.

A literatura científica atual oferece base sólida para essa abordagem. Pesquisas sobre LLM-as-a-Judge, score rubrics, separação entre planejamento e execução de avaliação, e aprendizado por reforço para judges apontam na mesma direção: avaliação sistemática não é um luxo — é um requisito de produção.

Se você quer agentes melhores, comece pelo que quase ninguém mede: a qualidade de cada execução.

Referências

GU, Jiawei et al. A Survey on LLM-as-a-Judge. arXiv:2411.15594v6, 2025.

KIM, Seungone et al. PROMETHEUS: Inducing Fine-Grained Evaluation Capability in Language Models. arXiv:2310.08491v2, 2024.

LIU, Yang et al. G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment. Proceedings of EMNLP 2023, 2023.

MADAAN, Aman et al. Self-Refine: Iterative Refinement with Self-Feedback. arXiv:2303.17651, 2023.

SAHA, Swarnadeep et al. Learning to Plan & Reason for Evaluation with Thinking-LLM-as-a-Judge. arXiv:2501.18099v2, 2025.

SHINN, Noah et al. Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv:2303.11366, 2023.

WANG, Lei et al. A Survey on Large Language Model based Autonomous Agents. Frontiers of Computer Science, 2024.

WHITEHOUSE, Chen et al. J1: Incentivizing Thinking in LLM-as-a-Judge via Reinforcement Learning. arXiv:2505.10320v3, 2025.

ZHENG, Lianmin et al. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023. arXiv:2306.05685v4, 2023.

ZHU, Liang et al. JudgeLM: Fine-Tuned Large Language Models Are Scalable Judges. ICLR 2025. arXiv:2310.17631v2, 2025.