Vale a pena automatizar a otimização de prompts?

Vale quando três condições valem juntas: existe um conjunto de avaliação com métrica automática, o prompt vai ficar em produção por meses e a tarefa tem mais de um passo. Faltando qualquer uma delas, o ajuste à mão com medição resolve o mesmo problema por menos. A pergunta que decide não é qual técnica é melhor, é quantas rodadas você vai fazer.

Isso porque a automação não muda a natureza do trabalho, muda o custo por tentativa. O ciclo continua sendo o mesmo descrito em otimização de prompt: variar, medir, escolher. O que um otimizador faz é ocupar as caixas de variação e escolha, e para isso ele consome exatamente o insumo que a maioria dos times não tem, que é um conjunto de avaliação.

Vale um aviso antes da comparação: a alternativa realista ao otimizador automático não é “escrever prompt com talento”. É ajuste manual medido, que já é disciplina o bastante para resolver muita coisa. Comparar DSPy com palpite não responde nada, porque qualquer um dos dois ganha do palpite. E existe um meio-termo pouco lembrado, que é usar um modelo para reescrever o próprio prompt em meta prompting, pagando quase nada de infraestrutura.

As duas curvas

O ajuste manual tem entrada barata. Você abre o prompt, muda uma frase, roda os casos, olha o número. Começa na primeira hora e não exige biblioteca nenhuma. O custo está no meio: cada candidato consome atenção de uma pessoa, e uma pessoa avalia poucas variações por dia antes de começar a se enganar sobre o que já testou.

A automação inverte as duas linhas. A entrada é cara: você precisa da métrica escrita, do conjunto montado e do pipeline expresso de uma forma que a ferramenta entenda. Isso custa dias, não horas. Depois disso o custo por candidato cai para tokens, e trinta candidatos passam a ser uma questão de esperar.

Há um custo do lado manual que não aparece em nenhuma planilha: a memória de quem ajusta. Depois de duas semanas mexendo no mesmo prompt, ninguém lembra com precisão qual combinação já foi testada nem com que resultado, e o time volta a testar o que já tinha descartado. Um registro por rodada resolve, e quase ninguém mantém.

A terceira linha é a que costuma decidir, e é a menos discutida. O teto do ajuste manual é o repertório de quem escreve: você testa as variações que consegue imaginar. O teto da automação é o orçamento, e o espaço que ela percorre inclui combinações que ninguém proporia, o que às vezes é a vantagem inteira e às vezes é a fonte do resultado bizarro que funciona sem que ninguém saiba por quê.

O pré-requisito que decide

Todo otimizador publicado tem a mesma assinatura de entrada: um programa, uma métrica e um conjunto de casos. O compilador do DSPy otimiza um pipeline para maximizar a métrica que você fornece¹. O APO forma “gradientes” em linguagem natural a partir de minilotes de dados². O MIPRO propõe instruções e seleciona demonstrações usando avaliação estocástica em minilote³. Nenhum deles inventa o critério.

A consequência é bem menos óbvia do que parece, porque a ferramenta não reclama. Se o seu conjunto tem doze casos escolhidos por conveniência, o otimizador roda normalmente, avalia os candidatos nesses doze e devolve o vencedor. O vencedor existe. Só não significa nada além de “foi o que se saiu melhor em doze casos específicos”, e com trinta candidatos disputando, a chance de o primeiro colocado ter sido o mais sortudo é alta.

Existe uma checagem barata antes de gastar qualquer coisa. Divida o seu conjunto ao meio de forma aleatória e meça o prompt atual em cada metade separadamente. Se os dois números ficarem longe um do outro, o conjunto é pequeno ou desigual demais para ordenar candidatos, e nenhum otimizador conserta isso.

É por isso que a ordem importa. Automação em cima de conjunto ruim não é neutra: ela acelera a produção de conclusões erradas e ainda dá a elas a aparência de método. Quem monta o conjunto primeiro pode nunca precisar do otimizador; quem monta o otimizador primeiro vai precisar do conjunto do mesmo jeito, só que depois de ter tomado decisões com base em nada.

O que o ajuste manual faz bem

Vale registrar, porque a literatura de otimização automática tende a tratar o manual como linha de base ruim.

O manual é insubstituível na decisão de decomposição. Perceber que a tarefa deve virar duas chamadas, uma que classifica e outra que extrai, é uma mudança de maior efeito que qualquer reescrita de instrução, e nenhum otimizador de prompt propõe isso, porque a estrutura do programa é entrada dele, não saída.

O manual também é o único caminho quando a métrica não existe. Tom de voz, adequação editorial, o que soa como a sua empresa. Você pode transformar parte disso em critério verificável, e deveria, mas a parte que sobra se resolve com alguém lendo saída.

E o manual é mais rápido no começo. Nas primeiras rodadas, o retorno por hora é alto porque os problemas são grosseiros: formato solto, instrução ambígua, exemplo faltando. Otimizador não é melhor que uma pessoa nesse regime, é só mais caro.

Onde o manual bate no teto

Dois trabalhos de 2023 delimitam o teto por lados diferentes, e juntos formam o argumento mais forte a favor da automação.

O primeiro mede a sensibilidade do modelo a escolhas que preservam o significado. Ao variar separadores, espaçamento e disposição dos exemplos em formatos todos plausíveis, os autores encontraram diferenças de até 76 pontos de exatidão no LLaMA-2-13B, com a sensibilidade persistindo ao aumentar o tamanho do modelo, o número de exemplos ou ao usar modelo ajustado por instrução. Eles também observam que o desempenho de um formato se correlaciona fracamente entre modelos⁴. A implicação prática é direta: existe ganho grande escondido em decisões que ninguém considera decisões, e o espaço é grande demais para busca manual.

O segundo mede o comportamento de quem escreve prompt. Em um estudo com uma ferramenta construída para apoiar desenvolvimento e avaliação sistemática de estratégias de prompt, os participantes exploraram o espaço de forma oportunista, não sistemática, e tropeçaram nas mesmas dificuldades já conhecidas de programação por usuário final. Expectativas trazidas de instruir outra pessoa e a tendência a generalizar demais apareceram como barreiras⁵. O estudo é com não especialistas em IA, então não se transporta direto para um time de engenharia, mas o padrão de exploração oportunista é reconhecível em qualquer sessão de ajuste de prompt sem conjunto na mesa.

O que a automação entrega

Números publicados, com o escopo junto, porque nenhum deles se transporta para o seu caso sem medição.

O APO, de 2023, reescreve a instrução usando críticas em linguagem natural como gradiente e busca em feixe, e relata melhorar o prompt inicial em até 31% em três tarefas de referência mais detecção de jailbreak². É a família mais simples de entender: nada além de crítica e reescrita guiadas por dados.

O DSPy trata o pipeline como programa e compila os prompts contra a métrica fornecida, criando e coletando demonstrações¹. O MIPRO, na mesma linha, separa a otimização de instrução da de demonstração em programas de vários módulos e reporta até 13 pontos de exatidão acima das linhas de base em cinco de sete programas com Llama-3-8B³.

O trabalho de 2025 que mais mexeu na conta é o GEPA. Em vez de tratar o resultado como escalar, ele lê os traços de execução em linguagem natural, diagnostica o problema e propõe a correção, mantendo uma fronteira de Pareto das próprias tentativas. Em seis tarefas, superou o GRPO em 6% na média e em até 20% usando até 35 vezes menos execuções, e ficou mais de 10% acima do MIPROv2, com 12 pontos a mais de exatidão no AIME-2025⁶. O número que importa para esta decisão é o de execuções: quando o custo por rodada cai uma ordem de grandeza, a faixa em que automatizar compensa aumenta junto.

Um detalhe some nessas comparações e vale explicitar: as alavancas que os otimizadores mexem são três, e só três. A seleção de exemplos, o texto da instrução e, em alguns casos, a escolha do modelo por módulo. Formato de saída entra de carona na instrução. Nada nessa lista inclui repartir a tarefa, trocar a fonte de dado ou corrigir um rótulo errado no conjunto, que são justamente as mudanças de maior efeito quando existem. O otimizador é excelente dentro do espaço que você delimitou e cego para o espaço que você não delimitou.

O meio-termo que quase ninguém usa

A escolha costuma ser apresentada como binária, e não é. Existe um degrau intermediário que custa um script de umas quarenta linhas e captura boa parte do ganho.

O laço é este: você pede a um modelo dez variações do prompt atual, entregando a ele a instrução em uso e os casos em que ela erra. Roda as dez no seu conjunto, guarda a nota de cada uma e devolve as três melhores com as respectivas notas, pedindo mais dez. Repete quatro ou cinco vezes.

Isso é a ideia central de otimização por proposta de modelo, a mesma que o APO formaliza com gradiente textual e busca em feixe², implementada sem framework, sem abstração de programa e sem nada que precise ser mantido depois. As vantagens são específicas: o prompt continua legível, você entende cada alteração, e o custo de abandonar é zero, porque não há dependência nova no repositório.

O que esse degrau não faz é atribuir crédito entre módulos. Se o seu sistema tem três chamadas em sequência, o script mede a saída final e não sabe qual das três melhorou, e é exatamente esse problema que o MIPRO ataca ao propor instrução e selecionar demonstração por módulo, sem rótulo intermediário³. Enquanto o seu pipeline tiver uma chamada só, o script resolve. Quando passar a ter três, o framework começa a valer o preço.

Onde a automação falha

Ela otimiza o conjunto, não a produção. Trinta candidatos avaliados nos mesmos cinquenta casos produzem um vencedor parcialmente sortudo. Separe um holdout no começo, não olhe para ele durante a busca e confirme o vencedor nele no fim.

O prompt resultante é ilegível. Instrução compilada com demonstrações selecionadas costuma ser longa e estranha. Quando alguém precisa alterar uma regra de negócio seis meses depois, não há onde encostar a mão sem recompilar.

O custo por rodada esconde o custo de contexto. Prompt otimizado quase sempre cresce, porque exemplos ajudam. Isso aparece na fatura de produção a cada requisição, não na sessão de otimização, e some do cálculo de quem só olha o ganho de exatidão.

Ela morre na troca de modelo. O artefato é ajustado ao modelo e à versão em que foi medido, e a evidência pública sobre transferência é fina. Trocar de modelo é motivo para rodar tudo de novo, e isso deveria entrar no orçamento antes da primeira compilação.

O ganho encolhe conforme o prompt melhora. As linhas de base dos papers costumam ser few-shot padrão ou instrução escrita rapidamente. Se o seu prompt já passou por dez rodadas medidas, o espaço que sobra para o otimizador é bem menor que o reportado.

A regra de decisão

1. Monte o conjunto primeiro. Vinte casos reais do log, com resposta esperada. Sem isso a discussão inteira é sobre estética.
2. Meça o prompt atual. Esse número é a linha de base e resolve metade das dúvidas sobre automatizar.
3. Faça três rodadas manuais medidas. Formato, depois exemplos, depois instrução. Uma alavanca por rodada.
4. Conte as rodadas. Se você já passou de dez e ainda está mexendo, o otimizador vai se pagar.
5. Automatize onde há muitos módulos. Pipeline de vários passos é onde a busca manual perde primeiro, porque o crédito por acerto se distribui entre etapas.
6. Reserve o holdout antes de compilar. Vinte por cento, intocado.
7. Amarre a recompilação à troca de modelo. Se ninguém tem tempo de recompilar quando o modelo mudar, prefira o prompt legível.

Quanto custa

Ordem de grandeza. Uma sessão de otimização que avalia 30 candidatos em 100 casos, com prompt de 2 mil tokens e entrada de 500, gasta 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 entrada e entre US$ 5 e US$ 25 por milhão de saída, isso dá algo entre 10 e 60 dólares. Se a métrica usa um modelo como juiz, aproximadamente dobre.

Do lado manual, três rodadas medidas em 100 casos custam menos de um dólar em tokens e um dia de trabalho de alguém que conhece o domínio. É essa assimetria que responde a pergunta do título: dinheiro quase nunca é o gargalo, e a decisão se resolve olhando quantas vezes você vai repetir o ciclo e se existe conjunto para sustentá-lo.

Footnotes

1. Khattab et al. (2023) compilam pipelines declarativos contra uma métrica fornecida, criando e coletando demonstrações em vez de escrever prompt à mão. ↩ ↩²

2. Pryzant et al. (2023) usaram críticas em linguagem natural como gradiente e busca em feixe, relatando melhora de até 31% sobre o prompt inicial. ↩ ↩² ↩³

3. Opsahl-Ong et al. (2024) separaram a otimização de instrução da de demonstração em programas de vários módulos, com até 13 pontos de exatidão acima das linhas de base em cinco de sete programas com Llama-3-8B. ↩ ↩² ↩³

4. Sclar et al. (2023) mediram diferenças de até 76 pontos de exatidão entre formatos de prompt equivalentes em significado no LLaMA-2-13B, com a sensibilidade persistindo em modelos maiores e ajustados por instrução. ↩

5. Zamfirescu-Pereira et al. (2023) observaram não especialistas explorando o espaço de prompt de forma oportunista e não sistemática, com expectativas vindas de instruir pessoas atuando como barreira. ↩

6. Agrawal et al. (2025) leem traços de execução em linguagem natural para propor correções: 6% acima do GRPO na média e até 20%, com até 35 vezes menos execuções, e mais de 10% acima do MIPROv2. ↩