O que é Prompt Sem Eval?
Prompt Sem Eval (Untested Prompt) é um smell de IA, ou seja, um sinal de problema em sistemas com LLM, do grupo Impeditivos de mudança. O prompt muda em produção sem nenhum conjunto de casos para provar que não piorou.
Conteúdo da trilha
Capítulos
Transcrição
Abertura
O pull request que mudou o extrator de notas tinha uma linha. Extraia o total da nota virou: extraia o total da nota, com duas casas decimais.
A descrição dizia: ajuste de formato, testado em três notas. O revisor aprovou. A mudança parecia inofensiva.
Uma semana depois, o acerto do campo total nas notas com desconto tinha caído. E ninguém sabia desde quando, nem quanto. Porque não havia um número de antes para comparar.
O que aconteceu foi isto. As três notas do teste eram as que motivaram a mudança. Totais redondos, sem desconto.
Para forçar as duas casas decimais, o modelo começou a juntar o valor dos produtos com o desconto.
E o total saiu errado, justamente nas notas que o time nunca olhou. Nesta aula, você vai aprender a reconhecer esse smell, e a ordem de trabalho que acaba com ele.
O diagnóstico
O ciclo é este. Alguém muda o prompt para corrigir um caso.
Testa com os poucos exemplos que tem à mão.
A mudança sai, sem comparação com a versão anterior.
O efeito aparece em casos que ninguém testou.
E os usuários descobrem a regressão. Tarde, e sem dados.
Como identificar? Mudanças de prompt passam pela revisão de código como se fossem texto, sem resultado nenhum anexado.
O teste de uma mudança é: rodei uns exemplos e pareceu ok.
Não existe um conjunto de casos com respostas esperadas guardado no repositório.
Ninguém sabe dizer o acerto atual do sistema. Só que funciona. E a troca de modelo vive sendo adiada, porque ninguém sabe o que vai quebrar.
E bugs de produção são corrigidos no prompt e nunca viram casos de teste.
Por que acontece
Um prompt parece texto, não código. Mudar uma frase não parece mudar lógica. Mas com um modelo, frase é lógica. Com duas casas decimais mudou o campo total.
Montar um dataset dá trabalho. Juntar e rotular cinquenta casos parece caro perto de uma mudança de uma linha. O custo aparece depois, na regressão silenciosa.
A saída varia. Sem saber como testar algo que não é determinístico, o time desiste de testar. Mas uma regra de nota, como comparar campos, cobre a maior parte.
E os casos do bug viram o único teste. Quem corrige um bug testa o caso que quebrou. E mais nada.
Quanto custa
O primeiro custo é a regressão silenciosa. A qualidade cai numa parte dos casos, e ninguém percebe até o custo aparecer em outro lugar. Um boleto errado. Imposto calculado sobre o total errado. Um vendedor com nota rejeitada.
Depois, medo. Sem rede de segurança, o time evita melhorar o prompt, ou trocar de modelo, mesmo quando seria mais barato.
Depois, debates sem fim. Melhorou, contra piorou, sem número para decidir.
E bugs que voltam. O erro corrigido em março volta em junho, porque nada segura.
E é assim que o buraco se esconde, com números ilustrativos. Duzentas notas no eval, seis delas com desconto. A taxa geral cai de 97 para 94%. Parece ruído. Mas na categoria desconto, seis de seis agora falham. A média escondeu justamente o buraco que o financeiro vai achar.
Um desafio
Uma pergunta para você. Você não tem eval nenhum, e precisa corrigir até amanhã um extrator que erra o total. Qual é o primeiro passo que ainda dá tempo de fazer?
Rotule as quinze notas que você já sabe que quebram. Meça o prompt atual nelas. Depois mude. Quinze casos com resposta esperada já são um eval. Medir antes dá o piso. E essas quinze vão para o repositório e rodam no pull request.
Publicar agora e abrir um card de colocar eval na próxima sprint não funciona. O card fica atrás da próxima correção. E pedir para um modelo gerar duzentas notas sintéticas como gabarito perde o desconto torto de uma nota real. Comece pelo que já falhou em produção.
O tratamento
O tratamento é uma refatoração chamada add eval before changing the prompt. E a ordem importa. É a parte que os times mais invertem.
Primeiro, guarde casos com respostas esperadas. Comece pelos bugs de produção e umas duas dúzias de exemplos que dão certo. Separe por categoria. Com desconto, item faltando, um código fiscal raro.
Meça a versão atual. Esse número é o piso. Sem ele, todo melhorou é só conversa.
Mude o prompt, ou o modelo, numa branch.
Meça de novo. Olhe a taxa geral e a taxa por categoria. Uma categoria pequena em zero é regressão, mesmo que a média fique parada.
E o caso que quebrou entra no conjunto. Senão ele volta.
E no seu pipeline, o eval roda a cada pull request que mexe num prompt, num template ou num modelo. Essa última parte importa. Um time com um eval de quarenta casos que não roda há quatro meses, com metade dos casos num formato antigo, continua com esse smell. Eval que não roda não protege nada.
Parentes próximos
Alguns parentes próximos. Antes de cada deploy, alguém faz as mesmas oito perguntas ao bot e olha as respostas. Isso é ritual, não medição. Tem nome próprio: vibe check eval.
Um time roda duzentos casos a cada mudança, mas só olha a taxa geral. Isso não é esse smell. O eval existe. Só precisa de resultado por categoria, e de alerta quando alguma cai.
E um bug de produção, total ignora desconto, corrigido no prompt. O pull request passou num eval de duzentos casos que não tinha nota com desconto nenhuma. Passou porque não enxergava o bug. Coloque a nota que quebrou, e outras parecidas.
Quando ignorar
Quando dá para viver sem? Um protótipo, na primeira semana. Antes de saber o que o sistema deve fazer, testar na mão é razoável. Comece o dataset quando aparecer o primeiro usuário de verdade.
E um script pessoal que resume as suas reuniões pode viver sem eval. Quando outra pessoa depende dele, não pode mais.
Fechamento
Então, a ideia para levar. Com um modelo, frase é lógica. Trate toda mudança de prompt como mudança de código. Com casos guardados, um número de antes, um número de depois, e o caso quebrado entrando no conjunto. Aí trocar de modelo vira uma decisão medida, tomada numa tarde.
Na próxima aula, a gente faz essa refatoração passo a passo: add eval before changing the prompt. Até lá.
Prompt Sem Eval
Untested Prompt
Prompt Sem Eval (Untested Prompt) é um smell de IA, ou seja, um sinal de problema em sistemas com LLM, do grupo Impeditivos de mudança. O prompt muda em produção sem nenhum conjunto de casos para provar que não piorou.
- Elemento
- 13/37
- Nível
- Iniciante
- Leitura
- 4 min
- Atualizado
Como reconhecer
O pull request que mudou o extrator de NF-e (nota fiscal eletrônica brasileira) tinha uma linha:
-Extraia o valor total da nota.
+Extraia o valor total da nota, com duas casas decimais.A descrição dizia “ajuste de formato, testado com 3 notas”. O revisor aprovou: a mudança parecia inofensiva. Uma semana depois, a acurácia do campo total em notas com desconto tinha caído, e ninguém sabia desde quando nem quanto, porque não havia um número antes para comparar.
As três notas do teste eram as três que motivaram a mudança: totais redondos, sem desconto. O modelo passou a concatenar “valor de produtos” e “desconto” para forçar duas casas, e o campo total saiu errado nas notas que o time não olhou.
Sinais de Prompt Sem Eval:
- Mudanças de prompt passam por code review como se fossem texto, sem nenhum resultado anexado.
- O teste de uma mudança é “rodei alguns exemplos e pareceu bom”.
- Não existe um conjunto de casos com resposta esperada guardado no repositório.
- Ninguém sabe dizer a acurácia atual do sistema, só que “está funcionando”.
- Trocar de modelo é adiado porque ninguém sabe o que vai quebrar.
- Bugs de produção são corrigidos no prompt e nunca viram caso de teste.
flowchart LR
C["1. Mudança no prompt"]:::tool --> V(["2. Teste no olho com 3 exemplos"]):::llm
V --> D["3. Deploy"]:::tool
D --> P[("4. Produção")]:::store
P --> B(["5. Reclamação semanas depois"]):::io
- Alguém muda o prompt para resolver um caso.
- A pessoa testa com os poucos exemplos que tem à mão.
- A mudança vai para produção sem comparação com a versão anterior.
- O efeito aparece em casos que ninguém testou.
- A regressão é descoberta por quem usa, tarde e sem dado.
Um eval (teste para saída de modelo) não precisa nascer grande. Precisa existir antes da mudança, com a resposta esperada escrita, e rodar de novo depois.
Por que acontece
- Prompt parece texto, não código. Mudar uma frase não dá a sensação de mudar lógica. Code review trata o diff como estilo.
- Montar o dataset dá trabalho. Juntar e anotar 50 casos parece caro diante de uma mudança de uma linha. O custo aparece depois, na regressão silenciosa.
- A saída varia. Sem saber como testar algo não determinístico, o time desiste de testar. Temperatura 0 e um critério de correção (campo igual, ou juiz com rubrica) resolvem a maior parte.
- Funcionou da última vez. Mudanças anteriores sem eval não deram problema visível, o que não quer dizer que não deram problema.
- Os casos do bug viram o único teste. Quem corrige testa o caso que quebrou. Esse viés é o irmão do Eval no Olhômetro.
Quanto custa ignorar
- Regressões silenciosas. A qualidade cai em parte dos casos e ninguém percebe até o custo aparecer em outro lugar: boleto errado, imposto calculado em cima do total errado, cliente de marketplace com NF-e recusada.
- Medo de mudar. Sem rede de proteção, o time evita melhorar o prompt ou trocar de modelo, mesmo quando sairia mais barato.
- Discussões sem fim. “Ficou melhor” contra “ficou pior”, sem número para decidir.
- Bugs que voltam. O mesmo erro corrigido em março reaparece em junho, porque nada impede.
Uma conta para ver o buraco
Os números abaixo são ilustrativos. Suponha 200 notas no eval, 6 delas com desconto. A taxa geral cai de 97% para 94%. Parece ruído. Na categoria “com desconto”, 6 de 6 passaram a falhar. A média escondeu o buraco que o financeiro vai achar.
Tratamento
| Refatoração | Escolha quando |
|---|---|
| Criar Eval Antes de Mexer no Prompt | Sempre, antes da próxima mudança. Monte o dataset, meça a versão atual e só então mude. Destinos: Bancada de Evals e Dataset de Ouro. |
Leia também O que é um eval se o conceito for novo para o time.
A ordem importa e é a parte que o time mais inverte:
- Guardar casos com resposta esperada. Comece com os bugs de produção e uns vinte exemplos felizes. Separe por categoria: com desconto, sem item, CFOP raro.
- Medir a versão atual. Esse número é o chão. Sem ele, todo “melhorou” é conversa.
- Mudar o prompt (ou o modelo) numa branch.
- Medir de novo. Olhe a taxa geral e a taxa por categoria. Uma categoria pequena a zero é regressão, mesmo com a média estável.
- O caso que quebrou entra no conjunto. Senão ele volta.
Na CI, o eval roda em todo PR que toca prompt, template ou modelo. Um conjunto que não roda há quatro meses é o mesmo que não ter conjunto.
O que você ganha
- Toda mudança de prompt vem com um número antes e depois.
- Regressões aparecem na CI, não em produção.
- Troca de modelo vira uma decisão medida em uma tarde.
- Cada bug corrigido vira um caso que impede a volta dele.
Quando ignorar
- Protótipo na primeira semana. Antes de saber o que o sistema deve fazer, testar à mão é razoável. Comece o dataset quando o primeiro usuário real aparecer.
- Uso interno de baixo risco. Um script pessoal que resume reuniões pode viver sem eval. Se outra pessoa depende dele, já não pode.
É esse smell?
Checagem da aula
Responda as 6 perguntas para concluir a aula. Só assistir não conclui: a checagem é o que conta para a trilha e para o certificado.
Perguntas rápidas
Como corrigir Prompt Sem Eval?
Com Criar Eval Antes de Mexer no Prompt. Cada refatoração traz o passo a passo seguro, com eval antes e depois.
Onde Prompt Sem Eval aparece na prática?
Nos cenários reais Extração de NF-e e contratos e Perguntas em linguagem natural para SQL.
Para ir além
Relações
- Refatorações que tratam 1
- Aparece nos cenários 2
- Aparece nas trilhas 1