Eval-driven development: como a LangChain propõe melhorar agentes de IA com evals
Aprofundamento CEVIU
Aprofundamento
A LangChain chama de eval-driven development (EDD) um ciclo emprestado do TDD, adaptado a agentes que não são determinísticos: a saída varia, mais de uma resposta pode estar certa e o agente escolhe os próprios passos. Por isso o teste vira um eval, que pontua execuções sobre um conjunto de exemplos, com avaliadores em código (quando a checagem é determinística) ou LLM-as-a-judge (quando não é).
O processo tem três passos: definir como é o comportamento bom, escrever o eval antes de construir e fazer a mudança comparando experimentos. No exemplo do texto, um agente de documentação interna com as ferramentas search_docs e web_search ganha uma create_ticket. A média subiu, mas "How do I connect to the VPN?" passou a abrir ticket em vez de buscar na documentação. O trace mostrou a causa: a descrição da ferramenta citava "VPN and laptop issues". Restringir a descrição a pedidos que exigem ação de TI resolveu. A LangChain ainda alerta para overfitting (use um conjunto held-out), sugere rodar evals em pytest e Vitest nos pull requests e levar falhas do tráfego real de volta ao dataset via LangSmith.
O que mudou
Não é um produto novo, e sim a consolidação de uma linha que o CEVIU já vinha cobrindo. Em 15 de outubro de 2026, o CEVIU noticiou "LangChain Detalha Metodologias para Avaliação Robusta de Agentes de IA", com foco em combinar avaliadores e analisar exemplos de traces. Em 23 de setembro de 2026, em "Avaliação de Agentes de IA: Além da Simples Chamada de Ferramentas", o tema era a pontuação por etapa. Agora a LangChain amarra isso num fluxo explícito: spec de pass/fail, eval escrito antes da mudança, baseline e comparação exemplo por exemplo.
Por que isso importa
Para quem desenvolve agentes, a leitura é prática: tratar o prompt e a descrição de ferramentas como código que precisa de teste de regressão. Olhar só a média é o erro mais fácil de cometer, e o caso do VPN mostra o motivo. Colocar evals no CI e alimentar o dataset com falhas de produção dá ao time um histórico objetivo para decidir se uma mudança fica ou volta.
Linha do tempo
CEVIU noticia a avaliação de agentes de IA por etapa, além da simples chamada de ferramentas.
CEVIU noticia metodologias da LangChain para avaliação robusta de agentes de IA.
LangChain propõe o eval-driven development, com spec pass/fail, baseline, held-out e evals em CI e produção.
Perguntas frequentes
O que é eval-driven development?
É um ciclo de desenvolvimento de agentes inspirado no TDD. Você define o comportamento esperado, escreve o dataset e o avaliador antes da mudança e depois compara experimentos para ver se houve melhora real. O objetivo é subir a pontuação do eval de forma mensurável, o chamado hill climbing.
Por que não basta olhar a média das notas?
Porque uma média maior pode esconder exemplos que pioraram. No caso do texto, os pedidos de ticket passaram a funcionar, mas uma pergunta de how-to sobre VPN começou a abrir ticket. Por isso a comparação deve ser feita exemplo por exemplo.
Como detectar overfitting no dataset de evals?
Mantenha um conjunto held-out que você não consulta durante a iteração. Se a nota sobe nos exemplos usados para ajustar o agente, mas fica estável no held-out, provavelmente há overfitting. Um 100% num dataset pequeno nem sempre é a meta certa.
Quando rodar evals no CI e quando rodar em produção?
Checagens rápidas em código podem bloquear um merge, e evals mais lentos com LLM judge podem rodar à noite ou antes de um release. Em produção, avaliadores online pontuam traces reais e as falhas encontradas viram novos exemplos no dataset.
Fontes
- langchain.comfonte original
- Categoria
- CEVIU Web Dev
- Publicado
- 12 de novembro de 2026
- Editoria
- CEVIU Web Dev

