O que é otimização de prompt?

Otimização de prompt é alterar um prompt e verificar, contra um conjunto de casos com resposta esperada, se a alteração melhorou. O ciclo tem quatro peças: uma métrica, uma variação, uma medição e uma escolha. Sem a primeira, as outras três não decidem nada. É a peça que quase todo mundo pula, e é por isso que a maior parte das melhorias de prompt é palpite.

Esse conjunto de casos tem nome: conjunto de avaliação. Ele é pré-requisito de tudo que vem depois — de otimizadores automáticos como o DSPy até o uso de um modelo como juiz. Nenhum deles dispensa o conjunto. Todos consomem o conjunto.

Vale separar duas coisas que costumam vir juntas. Escrever um prompt bom é engenharia de prompts. Otimizar é outra atividade: é decidir, com evidência, qual de duas versões você coloca em produção.

O ciclo

A métrica é definida uma vez e fica parada. Ela responde a pergunta “o que conta como resposta certa aqui?”, e responder isso é mais difícil do que parece, porque obriga você a decidir coisas que estavam confortavelmente vagas. Se o modelo extrai o valor certo mas em formato errado, isso é acerto ou erro? Se ele acerta a categoria mas escreve três parágrafos a mais, conta?

As outras três peças giram. Você gera uma variação do prompt, roda o conjunto inteiro nela, recebe uma nota, compara com a nota anterior e fica com a que mediu melhor. Uma rodada de 50 casos leva alguns minutos, e o resultado é um número que substitui uma discussão.

Repare que a variação pode vir de qualquer lugar. Pode ser você reescrevendo a instrução, pode ser um script gerando dez versões, pode ser um otimizador proposto por outro modelo. Do ponto de vista do ciclo, tanto faz: a variação é a peça barata. A cara é a medição, e é ela que decide.

Sem métrica, o ciclo não fecha

O fluxo mais comum em equipes que ainda não têm conjunto é este: alguém percebe um comportamento ruim, mexe no prompt, testa com dois ou três exemplos no chat, acha que ficou melhor e faz o deploy. O ciclo parece o mesmo. Tem variação, tem teste, tem decisão.

O que falta é a única parte que importa: saber se melhorou. Três exemplos escolhidos por quem acabou de escrever a mudança são a amostra mais enviesada possível, porque são os casos que a mudança foi feita para resolver. A pergunta que ninguém responde é o que aconteceu com os outros noventa e sete.

Existe um sintoma fácil de checar. Pergunte ao time qual era a taxa de acerto do prompt antes da última alteração. Se não houver número, não houve otimização — houve troca de palpite, que às vezes melhora e às vezes não, e ninguém fica sabendo qual das duas.

O que serve de métrica

Escolha o critério mais barato que ainda separe certo de errado. Em ordem de custo:

Verificação programática. O JSON parseia, o campo total bate com o valor esperado, a categoria está na lista, o código gerado passa nos testes, o SQL roda sem erro. É determinístico, custa quase nada e cobre mais casos do que a maioria das pessoas imagina antes de tentar. Sempre que a saída puder ser reduzida a algo verificável, reduza.

Rótulo humano. Alguém lê a saída e diz se está boa. É o padrão-ouro e é caro: 100 casos revisados com atenção consomem uma tarde. Na prática você usa isso para construir o conjunto uma vez e para auditar periodicamente, não a cada rodada.

Um modelo como juiz. Você pede a um LLM que compare duas respostas ou pontue uma delas contra um critério escrito. Um trabalho de 2023 mediu mais de 80% de concordância entre o GPT-4 como juiz e a preferência humana no MT-Bench, e observou que dois humanos concordam entre si mais ou menos no mesmo nível¹. Isso é bom o bastante para muita coisa, e o mesmo trabalho é explícito sobre os vieses: o juiz prefere a primeira resposta que vê, prefere respostas longas e prefere texto do próprio modelo.

Um detalhe prático que economiza discussão: a métrica não precisa ser uma nota de zero a dez. Um binário por caso, passou ou não passou, é mais estável, mais fácil de auditar e o suficiente para comparar duas versões.

Quantos casos

Vinte casos pegam erro grosseiro: o prompt que quebra em entrada vazia, o formato que sai errado em metade das vezes. Para decidir entre duas versões parecidas, vinte não bastam.

A conta é simples. Com 50 casos e uma taxa de acerto de 80%, o intervalo de confiança de 95% vai de aproximadamente 69% a 91%. Com 200 casos, a mesma taxa dá um intervalo de aproximadamente 74,5% a 85,5%. Ou seja: num conjunto de 50, uma melhoria de três pontos percentuais não significa nada isoladamente.

Há uma boa notícia. Como você roda os dois prompts exatamente nos mesmos casos, a comparação é pareada, e o que importa não é a taxa absoluta de cada um, mas em quais casos eles discordam. Se o prompt novo acerta seis casos que o antigo errava e erra um que o antigo acertava, isso é bem mais informativo do que a diferença entre 74% e 84% sugere. Guarde o resultado caso a caso, não só o agregado.

O que exatamente se muda

O ciclo não diz o que variar. Na prática as alavancas são poucas, e esta é mais ou menos a ordem do retorno por esforço.

O formato da saída. Pedir uma palavra em minúscula, ou um JSON com campos nomeados, em vez de deixar o modelo escolher. Costuma ser a mudança de maior efeito por caractere escrito, e é a mais fácil de medir, porque o critério vira programático no mesmo movimento.

Os exemplos. Quantos, quais e onde. Prompts baseados em exemplos resolvem ambiguidade de fronteira que nenhuma instrução resolve bem, e são a alavanca que os otimizadores automáticos mexem primeiro: o compilador descrito no paper do DSPy, em 2023, funciona criando e coletando demonstrações².

A instrução. Reordenar, cortar, tornar explícito o que estava implícito. É onde as pessoas gastam mais tempo e onde o retorno é mais irregular, porque o espaço de variação é grande demais para busca manual.

A decomposição. Quebrar uma chamada em duas, primeiro classificar e depois extrair, costuma render mais que qualquer reescrita, e muda o conjunto de avaliação junto, porque agora existem dois pontos onde medir.

O modelo e seus parâmetros. Não é prompt, mas entra na mesma comparação e usa o mesmo conjunto. Vale medir cedo: às vezes a resposta é que o prompt está bom e o modelo é que está errado para a tarefa.

Uma regra que economiza retrabalho: mude uma alavanca por rodada. Formato e exemplos alterados juntos dão um número que não diz qual dos dois funcionou, e você vai carregar os dois para sempre.

Otimização automática

Otimizador automático é um programa que ocupa as caixas de variação e seleção do ciclo. A ideia é sempre a mesma: proponha candidatos, meça cada um, fique com o melhor. O que muda entre as abordagens é como os candidatos são propostos.

O OPRO, de 2023, usa o próprio modelo como otimizador: ele recebe as instruções já testadas junto com as notas que cada uma obteve e propõe instruções novas. Os autores reportam prompts que superam os escritos por humanos em até 8% no GSM8K e em até 50% em tarefas do Big-Bench Hard³. São ganhos relativos sobre uma baseline específica, não um número que se transporta para o seu caso.

O DSPy trata o pipeline inteiro como um programa e compila os prompts contra uma métrica que você fornece. No paper de 2023, programas compilados superaram few-shot padrão em geralmente mais de 25% com GPT-3.5 e mais de 65% com llama2-13b-chat, e superaram pipelines com demonstrações escritas por especialistas em faixas de 5% a 46% e 16% a 40%². O trabalho seguinte na mesma linha, de 2024, otimiza instruções e demonstrações de cada módulo em separado e reporta até 13 pontos de acurácia acima das baselines em cinco de sete programas testados com Llama-3-8B⁴.

O padrão nos quatro casos é o mesmo, e é o ponto deste artigo: o otimizador consome uma métrica e um conjunto. Adotar DSPy sem conjunto de avaliação não automatiza nada — só move o palpite para dentro de uma biblioteca.

O que fica em volta

O conjunto de avaliação não nasce de brainstorm. Os casos bons vêm do que já aconteceu em produção: as entradas que apareceram, as saídas que deram problema, as reclamações abertas. Sem observabilidade você inventa casos, e casos inventados testam o sistema que você imagina ter.

Na outra ponta está o custo, que não é detalhe. Ele limita o tamanho do conjunto e o número de candidatos que você consegue avaliar, e os dois se multiplicam. Um checklist de LLMOps razoável trata esses quatro elementos como um sistema só.

Onde falha

Você acerta o conjunto e erra a produção. Se você testou quarenta variações contra os mesmos cinquenta casos, a vencedora venceu em parte por sorte: com ruído de alguns pontos percentuais e quarenta tentativas, a melhor por acaso está acima da média só por ter sido a mais sortuda. O remédio é banal e quase nunca é feito: separe um conjunto de validação no começo, nunca olhe para ele durante a escolha e confirme o vencedor nele no fim.

A métrica vira o alvo. Se o critério é “o juiz gostou”, o processo vai descobrir que o juiz gosta de respostas longas e educadas, e você vai otimizar verbosidade. O viés de verbosidade está documentado no mesmo trabalho de 2023 sobre LLM-as-a-judge¹. Toda métrica proxy tem uma versão disso; a defesa é olhar as saídas vencedoras de vez em quando, e não só a nota.

O conjunto envelhece. A distribuição de entradas muda quando o produto muda, quando entra um cliente novo, quando o time de suporte reescreve o formulário. Um conjunto montado há oito meses mede um problema que talvez não seja mais o seu.

Trocar o modelo invalida o resultado. O prompt otimizado é um artefato ajustado ao modelo e à versão em que foi medido. A evidência pública sobre quanto disso transfere entre modelos é fina, e a suposição confortável, a de que o que melhorou num melhora no outro, não deveria ser feita sem medir. Troca de modelo é motivo para rodar tudo de novo.

Tarefa sem resposta certa. Texto criativo, tom de voz, escolha editorial. Aí a métrica é preferência, preferência é mais barulhenta que acerto, e você precisa de mais casos e de comparação pareada para tirar qualquer conclusão. Vale fazer, mas com expectativa calibrada.

Como começar

1. Junte 20 casos reais do seu log. Não invente casos. Pegue os que apareceram, incluindo os feios.
2. Escreva o critério de aceitação antes de olhar as saídas. Depois de olhar, você vai escrever um critério que a saída atual satisfaz.
3. Meça o prompt que está em produção hoje. Esse número é sua linha de base, e ter esse número já coloca você à frente da maioria.
4. Mude uma coisa por vez. Duas mudanças juntas que dão +4 pontos podem ser +9 e −5.
5. Só aceite diferença maior que o ruído. Na dúvida, aumente o conjunto antes de aumentar a confiança.
6. Separe um holdout que você não usa para escolher. Vinte por cento basta.
7. Automatize depois. Otimizador automático em cima de conjunto ruim otimiza ruído mais rápido.

Quanto custa uma rodada

Ordem de grandeza, para dimensionar. Um conjunto de 100 casos, com prompt de 2 mil tokens e entrada de 500, consome cerca de 250 mil tokens de entrada por rodada, mais uns 30 mil de saída. Se o juiz for outro LLM, aproximadamente dobre.

Uma sessão de otimização automática que avalia 30 candidatos multiplica isso por 30: em torno de 7,5 milhões de tokens de entrada e 900 mil de saída. Nos preços praticados em julho de 2026 para modelos de uso geral, entre US$ 1 e US$ 5 por milhão de tokens de entrada e entre US$ 5 e US$ 25 por milhão de saída, isso dá algo entre 10 e 60 dólares por sessão. Barato para uma decisão que fica em produção por meses, e a conta muda bastante se o conjunto tiver mil casos em vez de cem.

O que raramente é barato é a primeira montagem do conjunto: rotular 100 casos com atenção consome uma tarde de alguém que entende do domínio. É esse custo, e não o de tokens, que faz a etapa ser pulada.

Footnotes

1. Zheng et al. (2023) mediram a concordância entre juízes LLM e preferência humana no MT-Bench e no Chatbot Arena, e catalogaram os vieses de posição, de verbosidade e de preferência pelo próprio texto. ↩ ↩²

2. Khattab et al. (2023) mostraram que compilar um pipeline declarativo contra uma métrica supera few-shot escrito à mão e, em vários casos, demonstrações montadas por especialistas. ↩ ↩²

3. Yang et al. (2023) usaram o modelo como otimizador, alimentando-o com as instruções já avaliadas e suas notas para propor as próximas. ↩

4. Opsahl-Ong et al. (2024) separaram a otimização de instruções da de demonstrações em pipelines de vários módulos, sem rótulos por módulo. ↩