Iteração e depuração de prompts

A engenharia eficaz de prompts não consiste em encontrar uma fórmula mágica — é um processo empírico e iterativo, mais semelhante à depuração do que à escrita. Você escreve um prompt, executa-o com entradas de teste, observa onde ele falha, formula uma hipótese sobre o motivo da falha e modifica o prompt para corrigi-la. A intuição, por si só, não é confiável; você precisa de dados.

Muitos desenvolvedores cometem o erro de testar o prompt em um ou dois exemplos elaborados manualmente, obter bons resultados e colocá-lo em produção — apenas para descobrir que o prompt falha em 30% das entradas reais. Um fluxo de avaliação sistemático evita isso ao expor o prompt a exemplos diversificados e representativos antes de colocá-lo em funcionamento.

Antes de escrever seu prompt, crie um conjunto de testes de referência: uma coleção de 20 a 100 exemplos representativos de entradas, associados à saída esperada ou a critérios de aprovação. Esse conjunto de testes se torna sua referência objetiva para avaliar qualquer alteração no prompt.

Bons conjuntos de testes incluem: entradas típicas, casos extremos (strings vazias, entradas muito longas e casos ambíguos), entradas adversariais criadas para quebrar o prompt e entradas de diferentes segmentos da sua população de usuários. Quanto mais diversificado for seu conjunto de testes, mais confiança você poderá ter de que uma alteração no prompt é uma melhoria real, e não apenas um ajuste excessivo aos poucos exemplos que você tinha em mente.

Escrever um script simples de avaliação leva uma hora e economiza dias de depuração de problemas em produção. O script executa seu prompt com cada caso de teste, compara a saída com o resultado esperado e informa uma taxa de aprovação. Depois, você pode iterar no prompt e verificar imediatamente se suas alterações melhoraram a pontuação geral.

Quando seu prompt falhar em casos de teste, agrupe as falhas por tipo para identificar padrões. Os modos de falha comuns incluem:

• Falhas de formato: o modelo produz a resposta correta, mas no formato errado
• Falhas de ambiguidade: o modelo interpreta a tarefa de modo diferente do que você pretendia
• Falhas em casos extremos: o modelo funciona com entradas típicas, mas falha com entradas incomuns
• Falhas por alucinação: o modelo produz com confiança conteúdo factual incorreto
• Ignorar instruções: o modelo segue parcialmente as instruções, mas não atende a restrições específicas

Cada tipo de falha exige uma correção diferente. Falhas de formato exigem instruções de saída mais explícitas; falhas de ambiguidade exigem uma definição mais clara da tarefa ou exemplos.

O Playground da OpenAI (platform.openai.com/playground) é a ferramenta mais rápida para iterar em prompts sem escrever código. Ele permite alternar entre modelos, ajustar parâmetros com controles deslizantes, salvar versões de prompts e comparar saídas lado a lado.

Use o Playground na fase de exploração do desenvolvimento de prompts: experimente diferentes formulações, teste casos extremos de modo interativo e desenvolva sua intuição sobre o que funciona. Quando tiver chegado a um prompt promissor, passe ao código com uma estrutura de avaliação para validá-lo sistematicamente em todo o seu conjunto de testes antes de colocá-lo em produção.

Prompts são código. Eles devem ter controle de versão, ser revisados e implantados com o mesmo rigor aplicado ao código da aplicação. A abordagem mais básica é armazenar os modelos de prompt como strings em um arquivo de constantes no seu repositório, para que as alterações sejam rastreadas no git e exijam revisão de código.

Abordagens mais sofisticadas incluem armazenar prompts em um banco de dados dedicado ao gerenciamento de prompts (LangSmith, PromptLayer ou uma tabela simples do Supabase), marcar versões e executar testes A/B entre versões de prompts em produção. Isso é especialmente importante quando vários integrantes da equipe trabalham nos mesmos prompts ou quando você precisa reverter uma alteração que reduziu a qualidade em produção.

Quando tiver duas versões de prompt concorrentes, execute ambas com seu conjunto completo de testes e compare as pontuações. Até mesmo uma melhoria de 5% na precisão de um sistema em produção que processa milhares de solicitações por dia compensa o esforço da avaliação. Nunca escolha um prompt com base em um ou dois exemplos testados manualmente — compare sempre usando o conjunto completo de testes.

Para medidas de qualidade subjetivas, em que não existe uma única resposta correta (como tom, utilidade ou criatividade), você pode usar LLM como avaliador: peça a um modelo avançado, como GPT-4o, que avalie qual das duas respostas atende melhor aos seus critérios de qualidade. Isso permite ampliar a avaliação para além do que a revisão humana consegue abranger.

Por padrão, as saídas de LLM não são determinísticas. Definir temperature=0 torna as saídas quase determinísticas (o token mais provável em cada etapa), o que é essencial para a depuração, pois permite executar o mesmo prompt duas vezes e obter a mesma saída. Ao depurar, defina sempre a temperatura como 0 para conseguir isolar se uma alteração no prompt causou a mudança na saída ou se ela foi apenas uma variação aleatória.

Depois de corrigir o prompt, reative algum nível de temperatura em produção se o seu caso de uso se beneficiar da variedade (escrita criativa, geração de ideias), mas mantenha a temperatura em 0 para tarefas de extração estruturada e classificação, nas quais você deseja saídas consistentes e reproduzíveis.

Se o seu prompt estiver produzindo fatos alucinados, adicione restrições que dificultem as alucinações. Técnicas eficazes contra alucinações incluem:

• Citar fontes: 'Responda somente com base no contexto fornecido. Se a resposta não estiver no contexto, diga que não sabe.'
• Quantificar a confiança: 'Avalie sua confiança de 1 a 5. Se for inferior a 3, não responda.'
• Etapa de verificação: 'Antes de responder, verifique se cada fato que você pretende usar está presente no documento fornecido.'

Nenhuma técnica elimina completamente as alucinações, mas combinar recuperação (RAG) com restrições fortes no prompt as reduz drasticamente em aplicações que exigem muito conhecimento.

Pesquisas mostram que os LLMs prestam mais atenção às instruções no início e no fim de um prompt do que às instruções no meio. Esse problema é chamado de perdido no meio. Se você tiver um prompt longo com instruções importantes ocultas no meio e cercadas por contexto, o modelo poderá não as seguir de forma confiável.

Prática recomendada: coloque as instruções mais importantes (a definição da tarefa e as restrições críticas) logo no início do prompt do sistema e repita as restrições essenciais no final. Para documentos longos inseridos como contexto, coloque a pergunta do usuário depois do documento, e não antes dele, pois o modelo dará mais peso ao conteúdo mais recente.

O ciclo de vida do desenvolvimento de prompts tem três fases:

• Exploração: use o Playground para experimentar livremente. Concentre-se em entender o que funciona conceitualmente, não em obter uma saída perfeita.
• Avaliação: crie um conjunto de testes e uma estrutura de avaliação. Execute os prompts candidatos com o conjunto completo de testes e meça as taxas de aprovação. Faça iterações até atingir seu limite de qualidade.
• Produção: controle as versões do prompt final, adicione monitoramento para acompanhar as métricas de qualidade em produção e configure alertas para degradação da qualidade. Planeje iterações futuras quando as versões do modelo mudarem.

Ignorar a fase de avaliação é a causa mais comum de regressões na qualidade dos prompts em produção. O tempo investido em um conjunto de testes adequado se paga muitas vezes.

Nesta lição, você aprendeu que: a engenharia de prompts exige um conjunto de testes de referência e uma estrutura de avaliação para medir melhorias com confiabilidade, os modos de falha devem ser categorizados para identificar a correção adequada para cada tipo e a temperatura 0 é essencial para a depuração, enquanto o controle de versões dos prompts e o monitoramento em produção completam o ciclo de qualidade. A seguir, exploraremos como os LLMs processam texto por meio de tokens e por que a contagem de tokens é importante para o custo e o contexto.