Como melhorar um prompt: teste e itere com método

A primeira versão de um prompt é um rascunho. Ela muitas vezes traz algo perto do que você quer, e a distância entre perto e certo se fecha iterando: mudando o prompt de propósito, rodando de novo com a mesma entrada e conferindo se a mudança ajudou. Feita sem cuidado, a iteração vira reescrever ao acaso até que uma saída de sorte pareça boa. Feita como um pequeno experimento, ela dá um prompt que funciona nas próximas cem entradas, e não só naquela que você testou.

O método tem cinco passos: definir como é uma boa resposta, manter entradas de teste fixas, mudar uma coisa por vez, comparar as saídas e saber quando parar.

Defina como é uma boa resposta

Antes de editar qualquer coisa, anote o que a saída precisa fazer, na forma de verificações que você consiga responder com sim ou não. "Uma boa mensagem de commit" não dá para verificar. Estas dão:

1. A linha de assunto tem menos de 50 caracteres.
2. Ela segue o formato Conventional Commits (fix:, feat: e assim por diante).
3. O corpo diz por que a mudança era necessária, e não o que o diff já mostra.
4. Ela menciona o número da issue quando houver um.

Os critérios fazem dois trabalhos. Eles dizem o que acrescentar ao prompt, já que cada um muitas vezes é uma instrução que faltava. E impedem você de julgar as saídas por quão agradáveis elas soam, que é o jeito mais fácil de aceitar uma resposta confiante e errada.

Mantenha um pequeno conjunto de entradas de teste

Escolha de três a dez entradas e mantenha-as fixas enquanto trabalha. Inclua casos típicos, alguns difíceis (um campo vazio, uma entrada muito longa, um idioma que o prompt não esperava) e todas as entradas que já falharam antes. Um prompt ajustado em um único exemplo tende a se encaixar nesse exemplo e falhar no seguinte.

Escreva o prompt como um template com um espaço para a entrada, para que todas as versões rodem exatamente sobre o mesmo material.

Mude uma coisa por vez

Quando você muda o papel, o formato e os exemplos ao mesmo tempo e a saída melhora, você não sabe qual mudança fez efeito, e pode estar mantendo duas edições inúteis. Mude uma coisa, rode, compare. As abas abaixo são três versões de um prompt, cada uma com uma única mudança em relação à anterior.

Versão 1Versão 2Versão 3

EditCopy

Escreva uma mensagem de commit para este diff.- if len(password) > 8: + if len(password) >= 8: return True

Try it

Example replyReplies vary between models and runs.

Atualiza a validação do tamanho da senha

Este commit atualiza a lógica de validação de senha trocando o operador de comparação de > para >=. Com isso, senhas com exatamente 8 caracteres passam a ser consideradas válidas. Essa mudança melhora a precisão da validação e oferece uma experiência melhor aos usuários que criam contas.

A versão 1 falha nos critérios 2 e 3: o assunto não tem prefixo de tipo, e o corpo reconta o diff com mais palavras. A versão 2 acrescenta os requisitos de formato e passa nos critérios 1 e 2, mas o corpo ainda descreve o diff. A próxima edição óbvia seria outra instrução ("explique por quê"), mas o modelo não consegue explicar um motivo que nunca recebeu. A versão 3 acrescenta o contexto que faltava, e o corpo e a referência à issue vêm junto sem ninguém pedir. Essa é a lição mais comum da iteração: quando uma instrução não corrige uma saída, normalmente falta informação ao prompt, e não ênfase.

Compare as saídas lado a lado

Rode todas as versões em todas as entradas de teste, e rode cada uma mais de uma vez, porque os modelos de chat sorteiam as palavras e duas execuções do mesmo prompt diferem. Coloque as saídas lado a lado e confira com os seus critérios, não com a lembrança que você tem da última execução.

Para critérios precisos, uma segunda chamada ao modelo pode fazer a primeira rodada de avaliação. Cole as saídas em um prompt de avaliação com os critérios detalhados:

Avaliar saídas com critérios fixos

EditCopy

Fill incriterios

Confira cada saída abaixo com os critérios. Para cada critério, responda aprovado ou reprovado com um motivo curto que cite a saída. Julgue só os critérios listados. Não premie tamanho nem estilo. Critérios: 1. Linha de assunto com menos de 50 caracteres. 2. Segue o Conventional Commits. 3. O corpo diz por que a mudança era necessária, e não o que o diff mostra. 4. Menciona o número da issue. Saída A: """ fix: aceita senhas com exatamente 8 caracteres Troca a verificação de tamanho de > para >= para que senhas com exatamente 8 caracteres passem na validação. """ Saída B: """ fix: aceita senhas com exatamente 8 caracteres A página de cadastro pede pelo menos 8 caracteres, mas a verificação rejeitava senhas com exatamente esse tamanho, então quem seguia as instruções não conseguia se cadastrar. Fixes #412 """ Responda em uma tabela com uma linha por critério.

Try it

Example replyReplies vary between models and runs.

Critério	Saída A	Saída B
1. Assunto com menos de 50 caracteres	Aprovado: o assunto tem 46 caracteres	Aprovado: mesmo assunto, 46 caracteres
2. Conventional Commits	Aprovado: começa com "fix:"	Aprovado: começa com "fix:"
3. O corpo explica o porquê	Reprovado: "Troca a verificação de tamanho de > para >=" repete o diff	Aprovado: "quem seguia as instruções não conseguia se cadastrar"
4. Menciona a issue	Reprovado: nenhum número de issue	Aprovado: "Fixes #412"

Trate um modelo avaliador como um assistente, não como um juiz. Zheng et al. 2023, "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena", documentaram vieses em modelos avaliadores, incluindo a preferência por respostas mais longas e pela resposta em uma posição específica. Mantenha os critérios verificáveis, peça evidências citadas, troque a ordem de A e B quando comparar duas saídas e leia você mesmo uma amostra das saídas. Verificações como contagem de caracteres são mais confiáveis como uma linha de código do que como julgamento de um modelo.

Corrija o prompt, não a conversa

Em um chat, é tentador corrigir a resposta com mensagens seguintes: "mais curto", "não, mencione a issue", "use o outro formato". Isso traz uma boa saída e deixa o prompt tão ruim quanto estava. Quando uma correção funcionar, leve-a para o prompt e rode o prompt do zero. Da próxima vez que precisar do resultado, você cola uma mensagem em vez de repetir cinco.

Guarde as versões antigas com uma nota de uma linha dizendo o que mudou e o que isso corrigiu. Um arquivo de texto simples basta. Quando uma edição posterior piorar as coisas, você pode voltar em vez de tentar lembrar o que o prompt dizia.

Rodando uma comparação no código

Quando um prompt roda por uma API, um script curto consegue produzir a visão lado a lado para todas as versões e todas as entradas de teste. Este usa o SDK Python da OpenAI e escreve um arquivo markdown que você pode ler de cima a baixo.

from openai import OpenAI

client = OpenAI()
MODEL = "your-model-id"  # e.g. from your provider's model list

# each prompt file contains {input} where the test diff goes
PROMPTS = {
    "v2": open("prompts/commit_v2.txt").read(),
    "v3": open("prompts/commit_v3.txt").read(),
}
TESTS = [open(f"tests/diff_{i}.txt").read() for i in range(1, 6)]

with open("results.md", "w") as out:
    for i, test in enumerate(TESTS, 1):
        out.write(f"## Test {i}\n\n")
        for name, template in PROMPTS.items():
            for run in (1, 2):
                response = client.chat.completions.create(
                    model=MODEL,
                    messages=[{"role": "user", "content": template.replace("{input}", test)}],
                )
                out.write(f"### {name}, run {run}\n\n{response.choices[0].message.content}\n\n")

Quando parar

Pare quando todos os critérios passarem em todas as entradas de teste ao longo de algumas execuções. Acrescentar mais depois disso só acrescenta tamanho, e cada instrução extra é mais uma coisa que pode entrar em conflito com as outras.

Pare também quando as mudanças começarem a trocar uma falha por outra: uma edição corrige o teste 2 e quebra o teste 4, a seguinte inverte. Esse padrão significa que o prompt está sendo usado para algo que uma única instrução não consegue fixar. As saídas mais comuns são mostrar o formato com alguns exemplos (prompt few-shot), dividir o trabalho em etapas com encadeamento de prompts ou levar as partes determinísticas, como contar caracteres ou conferir um formato, para um código que verifica a saída. Se faltarem ideias, o meta prompting pode ajudar: dê a um modelo o prompt, a entrada e a saída ruim e pergunte qual parte do prompt provavelmente causou o problema.