Evaluation Driven Development: Como Parar de Ajustar Prompts no Escuro?
Quase toda equipe que constrói sua primeira aplicação com LLM passa pelo mesmo ritual. Alguém escreve um prompt, testa com cinco ou seis perguntas na tela, ajusta uma frase, testa de novo, acha que ficou bom e publica. Semanas depois, um usuário reclama de uma resposta absurda, alguém mexe no prompt para corrigir aquele caso e, sem perceber, quebra outros três que funcionavam. Ninguém sabe dizer se a versão atual é melhor ou pior do que a de um mês atrás, porque nunca houve uma medida.
Esse ritual tem nome: desenvolvimento por impressão. E a resposta da engenharia a ele também tem nome: Evaluation Driven Development ou EDD. Neste post, explicamos o que é, por que ele se tornou a prática profissional de quem leva IA Generativa a produção e como começar a aplicá-lo.
A Ideia Faz Sentido
Em EDD, as avaliações são escritas antes ou junto com a implementação e funcionam como a especificação executável do comportamento esperado. Cada mudança no sistema, seja no prompt, no pipeline de retrieval, no modelo ou nas ferramentas de um agente, é julgada pelo efeito que produz no conjunto de avaliações e não pela impressão de quem a fez.
A analogia com Test Driven Development é imediata e útil: primeiro se define o que “funcionar” significa, depois se constrói até que funcione. A diferença é que, em sistemas generativos, “funcionar” não é um valor exato que passa ou falha. É uma qualidade que precisa ser medida, em escala, com tolerância à variação. É exatamente por isso que o EDD não é apenas TDD com outro nome.
Por Que Testes Tradicionais Não Bastam?
Um teste unitário clássico tem três propriedades: é determinístico, é binário e compara a saída com um valor esperado exato. Em IA Generativa, nenhuma das três se sustenta. A mesma entrada produz saídas diferentes entre execuções. A qualidade é uma escala, não um sim ou não. E existem muitas respostas corretas para a mesma pergunta, redigidas de formas diferentes.
Tentar forçar o modelo tradicional gera dois problemas simétricos: testes que quebram sem que nada tenha piorado, por causa de variação inofensiva na redação, e testes que passam enquanto o sistema piora, porque a asserção era fraca demais (verificar se a resposta não está vazia, por exemplo). O EDD substitui asserções exatas por critérios, gabaritos exatos por referências e rubricas, e resultados binários por taxas de aprovação medidas em várias execuções.
O Ciclo do EDD
O ciclo tem seis etapas e começa antes do primeiro prompt. Mais importante: ele não termina com o deploy. Cada falha encontrada em produção reentra no ciclo como um novo caso de avaliação.
Definir critérios de qualidade. Antes de escrever código, a equipe descreve o que é uma boa resposta em termos verificáveis: quais informações devem estar presentes, qual o formato, qual o tom, o que nunca deve acontecer. Um critério vago como “a resposta deve ser útil” não é avaliável. Um critério útil é específico e observável: “a resposta contém o prazo de reembolso e o canal para solicitação, conforme a política vigente”.
Construir casos de avaliação. Cada critério vira exemplos concretos de entrada com o comportamento esperado. O conjunto inicial pode ser pequeno, vinte ou trinta casos já ajudam, mas precisa cobrir três famílias: os casos típicos, que representam a maior parte do tráfego; os casos de borda, com entradas ambíguas, incompletas ou fora do escopo; e os casos adversariais, como tentativas de prompt injection e pedidos de dados sensíveis.
Implementar ou ajustar. Só então o prompt, o pipeline ou o agente são construídos ou modificados, com o objetivo explícito de melhorar o resultado nos casos definidos.
Executar avaliações. O conjunto completo roda de forma automatizada, com múltiplas execuções nos casos sensíveis à variabilidade, e produz um relatório comparável com a versão anterior.
Analisar falhas. Os casos reprovados são examinados um a um para entender a causa: o retrieval falhou, o prompt foi ambíguo, o modelo alucinou, o próprio avaliador errou. Essa análise de erros é a fonte mais rica de aprendizado de todo o ciclo e é dela que saem os próximos casos e os próximos ajustes.
Decidir. Com evidência em mãos, a equipe promove a versão, itera mais uma vez ou reverte. A decisão fica registrada junto com os resultados que a justificaram.
A Pirâmide de Avaliações
Uma suíte de avaliações com centenas de casos, várias execuções e juízes baseados em LLM pode levar dezenas de minutos e ter custo monetário mensurável. Isso obriga a organizar as avaliações em camadas, executando as mais baratas com frequência e as mais caras em momentos definidos. A pirâmide de testes do software tradicional tem um equivalente direto aqui.
Na base ficam os testes determinísticos: validação de schema, parsing, campos obrigatórios, regras de negócio e guardrails. Eles não custam tokens, não erram e devem rodar a cada commit. No meio, as avaliações por componente (retrieval, extração, escolha de ferramenta), que são rápidas e apontam diretamente onde corrigir, e as avaliações end-to-end, os casos do golden dataset executados contra o sistema completo, com juízes automáticos medindo correção, fidelidade e aderência à política. No topo, a avaliação humana e a observação de produção, escassas e caras, porém as mais confiáveis. Seu papel é validar as camadas inferiores, não substituí-las.
O Que Muda Quando o EDD Funciona?
Considere um assistente que responde dúvidas sobre políticas internas de uma empresa. Na primeira versão, o prompt aprova 62% dos casos do conjunto. A equipe adiciona instruções de formato: a aderência ao formato sobe para 98% e a correção fica estável. Depois inclui exemplos few-shot: a correção sobe para 81%, mas a verbosidade piora. Isso só é percebido porque as duas dimensões são medidas. Um limite de tamanho corrige a verbosidade sem perder correção. Por fim, casos extraídos de produção expõem uma categoria de falha que ninguém havia imaginado e ela é corrigida na versão seguinte.
Sem o conjunto de avaliação, a equipe provavelmente teria celebrado a melhora da versão três e descoberto o problema de tamanho pelas reclamações dos usuários. Com ele, cada versão é justificada por uma medição, cada medição revela o próximo problema e a equipe ganha confiança para fazer mudanças maiores. Esse é o efeito cumulativo do método: o conjunto fica mais completo, as decisões ficam mais rápidas porque não dependem de debate e o medo de mexer no prompt desaparece.
Práticas Que Sustentam o Método
Algumas disciplinas fazem a diferença entre um EDD que funciona e um que vira burocracia. Avaliações são tratadas como código, vivendo no repositório com versionamento e revisão. Cada execução registra a versão completa do sistema, prompt, modelo, parâmetros e índice, para que comparações sejam justas. Limiares de aprovação são definidos antes da execução e não ajustados até a versão passar. Um subconjunto dos casos fica reservado e nunca é usado durante os ajustes, para detectar sobreajuste aos exemplos conhecidos. E a análise de erros tem tempo reservado na rotina da equipe, porque é ela que faz o conjunto evoluir.
Onde Aprender Isso na Prática?
Evaluation Driven Development é um dos eixos do curso LLMOps, Avaliação e Observabilidade de Sistemas de IA Generativa, da Data Science Academy. O curso percorre a engenharia de avaliação de ponta a ponta: critérios e rubricas, golden datasets e ground truth, avaliação offline, online e contínua, LLM as a judge calibrado contra humanos, métricas de qualidade, segurança, latência, custo e confiabilidade, e a transformação de tudo isso em SLOs e quality gates integrados ao pipeline de CI/CD.
A teoria é aplicada em seis projetos práticos, entre eles a construção de um evaluation harness profissional para uma aplicação com LLMs, o benchmarking de um sistema RAG com avaliação automatizada, o evaluation harness de um agente com tool calling e um pipeline de continuous evaluation com regression testing e quality gates.
Se a sua equipe ainda decide a qualidade de um prompt olhando meia dúzia de respostas na tela, então está na hora de dar o próximo passo:
LLMOps, Avaliação e Observabilidade de Sistemas de IA Generativa
Também ensinamos como aplicar EDD na prática em mais 2 treinamentos:
Desenvolvimento Full Stack com IA Generativa e Agentes de IA
Equipe DSA
Referências:
Your AI Product Needs Evals, de Hamel Husain
Evaluation best practices, da OpenAI
Demystifying evals for AI agents, da Anthropic