5 estratégias de otimização de prompts que realmente melhoram a saída dos LLMs

Por que isso importa agora

“Otimização de prompt” e “engenharia de prompt” são usados como sinônimos na internet — e isso gera mais confusão do que deveria. Engenharia desenha um prompt do zero; otimização refina um prompt que você já tem, por meio de especificidade, estrutura e iteração, sem tocar no modelo. A distinção importa porque a maioria das pessoas que pergunta “como tiro uma saída melhor deste LLM” já tem um prompt funcionando: não precisa de uma tela em branco, precisa saber quais mudanças específicas movem o ponteiro — e quais só parecem que movem.

O que você ganha (e o que não ganha)

✅ O que as cinco estratégias entregam:

• Saída que o seu código consegue consumir (não só texto bonito).
• Menos “erros invisíveis” — dono errado, item duplicado, tarefa inventada.
• Um método para testar mudanças em vez de adivinhar.
• Redução de custo em raciocínio com variantes como Chain of Draft.

⚠️ O que elas não resolvem:

• Não substituem dados de entrada ruins: um transcripto ambíguo continua ambíguo.
• Não transformam um modelo fraco em um modelo de fronteira.
• Algumas (structured output, chain-of-thought) custam tokens a mais.

A base de teste

Tudo aqui roda sobre um exemplo deliberadamente bagunçado: um transcripto de reunião com três pessoas que precisa virar uma lista limpa de itens de ação. Três detalhes o tornam difícil — a revisão do mobile é reatribuída no meio da conversa (de Priya para Jake), a checagem do breakpoint de tablet é incorporada à mesma revisão (em vez de virar item próprio), e o dono da triagem da fila de suporte fica explicitamente em aberto. Um prompt que acerta as partes fáceis mas erra esses três detalhes não está funcionando de verdade — mesmo que a saída pareça plausível à primeira vista.

Estratégia 1 — Saída estruturada

A alavanca mais mensurável e a mais fácil de provar que não é cosmética. Pedir “liste os itens de ação” gera texto fluente, mas não gera algo que um sistema downstream consiga parsear de forma confiável. Em produção, saída não parseável não é um incômodo — é uma falha dura.

from pydantic import BaseModel, ValidationError

class ActionItem(BaseModel):
    owner: str
    task: str
    due: str

class ActionItemList(BaseModel):
    action_items: list[ActionItem]

def parse_structured_output(raw_json: str):
    try:
        return ActionItemList.model_validate_json(raw_json), None
    except ValidationError as e:
        return None, str(e)

O mesmo conteúdo pedido como prosa numerada falhou no parse (prosa não é JSON, por mais organizada que pareça). Pedido com um schema explícito, virou três objetos ActionItem validados. Essa é a diferença real: não texto mais bonito, mas a diferença entre saída que seu código usa e saída que exige um humano relendo e transcrevendo.

Estratégia 2 — Papel e persona

Atribuir um papel específico ativa uma parte diferente do treinamento do modelo, produzindo saída mais estruturada e ciente de contexto. É uma mudança pequena com efeito real, e custa nada testar. Em vez de “Extraia os itens de ação deste transcripto”, use algo como:

Você é um assistente executivo meticuloso que já participou de centenas
dessas reuniões. Você sabe que as pessoas mudam de ideia no meio da frase,
que atribuições são reatribuídas, e que um bom tomador de notas nunca
adivinha um responsável que não foi confirmado. Extraia os itens de ação.

A versão com papel prepara o modelo para esperar exatamente esse tipo de ambiguidade antes de começar a ler — o que mais importa em transcriptos bagunçados.

Estratégia 3 — Demonstrações few-shot diversas

Pesquisa consolidada aponta que a escolha das demonstrações pode impactar mais a qualidade do que a redação da própria instrução. O detalhe que quase todo mundo perde: não é “adicione exemplos” — é quais exemplos. Um conjunto que é três variações do mesmo padrão ensina quase nada de novo. A solução é selecionar exemplos diversos (por exemplo, via TF-IDF + similaridade por cosseno para evitar duplicatas próximas): um com dono confirmado, um com dono explicitamente em aberto e um em que um item é incorporado a outro anterior.

Estratégia 4 — Chain-of-thought (com um truque de custo)

Pedir raciocínio passo a passo continua útil, mas seu papel mudou: modelos de fronteira já raciocinam nativamente, então a instrução explícita importa menos do que em 2022-2023. Onde ela ainda paga o custo é em casos genuinamente ambíguos — como a reatribuição do dono no nosso transcripto. A instrução certa: “Antes de extrair cada item, trace quem foi atribuído ao longo de toda a conversa, já que atribuições às vezes mudam no meio. Reporte apenas o dono final confirmado.”

Para quem é sensível a custo, vale conhecer o Chain of Draft: pedir que cada passo de raciocínio seja rascunhado em ~5 palavras, e não em frases completas. Pesquisa indica que ele pode igualar a acurácia do chain-of-thought usando tão pouco quanto 7,6% dos tokens de raciocínio.

Estratégia 5 — Otimização automatizada e iterativa

A mais avançada da lista: em vez de ajustar o prompt “no feeling”, você pontua prompts candidatos contra casos de teste reais e deixa um processo de busca encontrar as correções que importam. É o mesmo mecanismo das ferramentas de otimização de prompt em produção — gerar variações, pontuar contra casos reais, manter o que funciona, repetir.

No exemplo, a busca começou com um prompt básico (“extraia itens de ação como JSON”) com score composto de 51,6%. Três iterações depois, descobriu e adicionou exatamente os três fragmentos que importavam para os modos de falha reais do transcripto — rastrear o dono final, não adivinhar itens sem responsável e excluir discussão geral — atingindo score 1,0. A busca encontrou o mínimo efetivo, sem jogar todas as instruções disponíveis no problema.

Tabela comparativa das estratégias

Troubleshooting: erros comuns

• ❌ Saída plausível mas o sistema rejeita → Causa: saída em prosa onde o código espera JSON. Solução: use schema estruturado (Estratégia 1).
• ❌ O dono da tarefa sai errado em transcriptos → Causa: modelo agarra a primeira menção. Solução: instrua a rastrear o dono final (Estratégia 4).
• ❌ Itens duplicados ou inventados → Causa: few-shot com exemplos quase idênticos ou sem penalidade de fabricação. Solução: diversifique os exemplos e pontue contra ground truth.
• ❌ Raciocínio caro sem ganho → Causa: chain-of-thought em modelo que já raciocina. Solução: use Chain of Draft ou dispense o raciocínio explícito.
• ❌ Prompt “melhorou” mas nada mudou → Causa: mudança cosmética sem medição. Solução: pontue contra casos reais antes e depois.

FAQ

• Qual estratégia devo aplicar primeiro? Saída estruturada — é a de maior impacto e a mais fácil de medir.
• Otimização automatizada vale o esforço? Sim, depois que o ajuste manual chegar ao limite; ela encontra correções que a intuição perde.
• Few-shot é melhor que instrução bem escrita? A seleção dos exemplos pode superar a redação da instrução; o ideal é combinar os dois.
• Chain-of-thought ainda é relevante? Menos para modelos de fronteira, mais para ambiguidade específica e modelos menores.
• Essas técnicas funcionam em português? Sim — o mecanismo é independente do idioma; apenas os exemplos e instruções devem estar na língua do seu caso.

Onde isso leva

Cinco estratégias, mas uma disciplina por baixo: parar de adivinhar o que melhora um prompt e começar a testar mudanças específicas contra casos reais. À medida que os modelos ficam mais capazes, a vantagem competitiva migra da “mágica do prompt” para a engenharia de medição — e quem dominar isso primeiro extrai mais valor do mesmo modelo.