Meu sistema de classificação de intenção para RAG estava funcionando perfeitamente. Então adicionei roteamento de documentos para PDFs e políticas internas, e o prompt foi de seis instruções para catorze. Testei pontualmente alguns casos, tudo parecia certo, e fiz o deploy.
Três semanas depois, eu investigava um problema em que consultas de negação — como “Quais produtos não estão cobertos pela garantia?” — estavam sendo classificadas como consultas comuns de política, em vez de verificações de negação. O estranho é que eu não tinha alterado a lógica de classificação nem o código de roteamento. A única mudança foi o prompt do sistema.
Foi aí que entendi o problema: eu tratava meu prompt como um arquivo de configuração estático. Ele não é. Um prompt é uma API estocástica, e cada instrução que você adiciona altera o contrato da API para todos os tipos de consulta que ela já atende, não apenas aqueles em que você está pensando.
A Falha Oculta
A engenharia de software tem um nome para o que estava faltando: suíte de testes de regressão. A ideia é simples — antes de qualquer mudança entrar em produção, você roda os testes. Se algo que funcionava agora falha, o deploy não acontece. A maioria das equipes de IA não tem nada parecido para prompts. Elas descobrem falhas por relatos de usuários, não por testes automatizados.
Esse espelhamento com Test-Driven Development (Beck, 2003) não é coincidência: a disciplina força você a definir o comportamento esperado antes de mexer no código. Aplicada a prompts, significa definir qual é a classificação correta para cada categoria antes de adicionar uma nova instrução.
O Experimento: 4 Versões de Prompt, 40 Consultas de Referência
O autor construiu uma suíte de regressão com quatro versões de prompt — refletindo uma sequência real de iteração — testadas contra 40 consultas de referência distribuídas em seis categorias:
- simple_intent (10 consultas): alvo de sobrecarga de raciocínio
- comparison (8 consultas): âncora comparativa ausente
- aggregation (6 consultas): colapso de escopo numérico
- negation (6 consultas): conflito de instruções
- multi_hop (6 consultas): se beneficia de chain-of-thought
- edge_ambiguous (4 consultas): falsa confiança
As versões representam uma progressão real: v1 é o baseline com instruções mínimas; v2 adiciona raciocínio chain-of-thought global; v3 introduz roteamento de documentos que prioriza tipo de documento antes da classificação de intenção; v4 combina ambas as mudanças, triplicando a superfície de instruções — e foi essa que entrou em produção.
O Validador: Quatro Verificações Determinísticas
Em vez de usar um LLM como juiz (que introduziria subjetividade e latência), o validador aplica quatro verificações determinísticas a cada saída:
- Verificação de schema: as chaves obrigatórias do JSON de saída estão presentes?
- Verificação de padrões: os padrões de texto esperados aparecem na saída?
- Verificação de intenção: a intenção classificada corresponde ao rótulo esperado?
- Verificação de guarda: strings proibidas (“I cannot”, “As an AI”) estão ausentes?
Zero dependências externas. Python puro. Roda em menos de dois segundos em CPU.
O Resultado Alarmante: Falsa Melhoria
O resultado mais perigoso foi o que o autor chama de False Improvement (Falsa Melhoria): a acurácia geral sobe, mas uma categoria crítica desaba silenciosamente.
A v4, o “melhor” prompt com 67,5% de acurácia geral, disparou o alerta FALSE IMPROVEMENT DETECTED porque a classificação de negação caiu 66,7%. A instrução “Prioritize document routing before intent classification” da v3 fazia com que consultas de negação contendo palavras-chave de política fossem resolvidas como tipo de documento, sem que a verificação de negação jamais fosse acionada. A acurácia dos outros tipos mascarou o colapso total de uma categoria inteira.
O Que Isso Significa na Prática
Este experimento expõe três lições para quem trabalha com prompts em produção:
1. Prompts não são arquivos de configuração. Cada instrução nova compete com todas as existentes pela atenção do modelo. Instruções contraditórias não geram erro — geram degradação silenciosa.
2. Teste de regressão não é opcional. Se você modifica prompts sem uma suíte de referência, está fazendo deploy às cegas. A primeira notificação de falha virá de um usuário frustrado, não de um monitor.
3. Acurácia agregada engana. Um prompt pode melhorar no agregado enquanto destrói uma categoria inteira. Desagregue os resultados por tipo de consulta — é ali que os conflitos de instrução se manifestam.
O código completo está disponível em github.com/Emmimal/prompt-regression-suite — uma suíte pronta para ser adaptada ao seu próprio sistema de classificação.
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.
