Engenharia de prompts avançada na prática: de truques a uma metodologia

O resultado do 17º teste finalmente apareceu.

Com o mesmo prompt — “analise os gargalos de desempenho deste código e sugira otimizações” —, Claude produziu uma resposta detalhada e profissional na manhã de segunda-feira. Na tarde de sexta, porém, entregou uma coleção de generalidades vazias. Troquei de modelo para testar e ChatGPT simplesmente reescreveu o código, sem perguntar se eu queria uma alteração e sem explicar por que ela seria necessária.

O desempenho dos prompts vivia oscilando entre “razoável” e “totalmente inútil”. Para quem usa IA como apoio à programação ou cria aplicações com agentes, essa instabilidade é um problema. Só depois percebi a causa: eu vinha montando prompts com truques isolados, sem nunca pensar em uma metodologia de verdade.

Este artigo procura organizar esse assunto. Vamos sair de “conhecer alguns truques” para “dominar uma metodologia sistemática”: veremos um framework de prompts em três camadas, os princípios de Chain-of-Thought e ReAct, a otimização automatizada do DSPy e as diferenças práticas entre escrever prompts para Claude e ChatGPT. No fim, apresento um método de avaliação aplicável. Sem saber se o prompt realmente funciona, qualquer otimização é apenas tentativa no escuro.

Por que precisamos passar de “truques” para uma metodologia

Você provavelmente já ouviu estes “truques”: pedir à IA que “pense passo a passo”, fornecer alguns exemplos para ela imitar ou atribuir um papel dizendo “você é especialista”. Essas técnicas funcionam, mas têm um problema: os resultados são instáveis demais.

As limitações de uma abordagem baseada em experiência

Entre 2023 e 2024, a maior parte das técnicas de prompt era orientada pela experiência. O que isso significa? Em termos simples, “vamos testar”: trocar algumas palavras, executar, manter o que funcionou e alterar de novo o que falhou. Essa abordagem tem alguns pontos fracos claros.

Resultados imprevisíveis. O mesmo prompt pode deixar de funcionar quando você troca de modelo. Até no mesmo modelo, chamadas feitas em momentos diferentes podem variar bastante em qualidade. Já vi muita gente — eu inclusive — passar horas ajustando um prompt para descobrir, no dia seguinte, que a excelente versão de ontem já não era tão boa.

Dificuldade de reprodução e transferência. Você consegue ajustar um ótimo prompt, mas um colega não obtém o mesmo resultado. Por quê? Porque o prompt pode carregar contexto implícito que nem você percebeu — o que foi dito antes ao modelo, seus hábitos de escrita e assim por diante. Como isso não está documentado, outra pessoa não consegue reproduzir o resultado.

Falta de critérios de avaliação. Afinal, o que define um bom prompt? Muitas vezes, a única resposta é uma impressão: “esta saída parece razoável”. Esse julgamento é subjetivo demais. Sem métricas quantitativas, não existe otimização sistemática.

Há um dado interessante: antes de usar um método sistemático para prompts — chamado pela empresa de “fórmula 3C”: Context, Constraint e Content —, uma fintech tinha apenas 61% de acerto na primeira compreensão. Depois de adotar o framework, o número subiu para 89%. Não é uma melhoria pequena, mas uma mudança de patamar.

A mudança de 2025 a 2026

A partir de 2025, a engenharia de prompts começou a migrar do “ajuste manual” para a “engenharia sistemática”. Três avanços são fundamentais nessa transformação.

Design modular. O prompt é dividido em componentes reutilizáveis e montado como código. Em vez de escrever um prompt longo do zero todas as vezes, você combina módulos padronizados. Cada componente pode ser testado e otimizado separadamente, o que aumenta muito a estabilidade do conjunto.

Otimização automatizada. Frameworks passam a otimizar o prompt por você. DSPy é um dos exemplos mais representativos: depois que você define a tarefa e os critérios de avaliação, ele itera automaticamente em busca da melhor configuração. A ideia central é “Programming, not prompting”.

Avaliação padronizada. Com métricas quantitativas e frameworks de teste, o resultado de um prompt pode ser medido objetivamente. Ferramentas como DeepEval e Promptfoo trabalham com dimensões como precisão, consistência, segurança e eficiência de custo. A avaliação deixa de depender de sensação e passa a depender de dados.

Para ser sincero, essas três mudanças transformaram minha forma de trabalhar. Antes, ajustar um prompt parecia uma aposta; agora se parece mais com engenharia — há projeto, testes, iteração e dados. Essa é a essência da passagem de truques para uma metodologia.

Um framework de prompts em três camadas

Dividir as técnicas de prompt em três camadas deixa tudo mais claro. A camada básica, a camada de raciocínio e a camada de sistema resolvem tipos diferentes de problema.

Camada básica: fazer o modelo entender o que você quer

Esta camada resolve a questão mais elementar: como fazer o modelo produzir o resultado desejado.

Zero-shot, ou prompt sem exemplos, significa pedir diretamente que o modelo execute a tarefa. Por exemplo:

Explique o que é uma arquitetura de microsserviços.

É uma abordagem simples e direta, adequada a tarefas fáceis ou perguntas de conhecimento geral. Em tarefas complexas ou saídas que exigem um formato específico, porém, o resultado do Zero-shot costuma ser instável.

Few-shot, ou prompt com poucos exemplos, fornece de dois a cinco exemplos para o modelo aprender. Imagine que você queira descrições de produto em um estilo mais leve:

Com base no estilo dos exemplos abaixo, escreva uma descrição para o novo produto.

Exemplo 1:
Produto: fones de ouvido Bluetooth sem fio
Descrição: um pequeno universo nos seus ouvidos, com som tão nítido que parece um show ao vivo e bateria suficiente para acompanhar um voo internacional.

Exemplo 2:
Produto: cafeteira portátil
Descrição: leve a cafeteria na mochila e prepare um café especial onde estiver, com controle preciso até dos resíduos.

Agora escreva uma descrição para uma "caneca térmica inteligente".

O modelo imita o estilo dos exemplos. A chave do Few-shot é a qualidade: os exemplos devem refletir o estilo de saída esperado. Não é preciso incluir muitos — de dois a cinco bastam —, mas eles precisam ser bons.

Role Prompting, ou prompt de papel, atribui uma identidade ao modelo. Isso ajuda a limitar o estilo e o nível técnico da saída:

Você é uma pessoa especialista em arquitetura backend, com dez anos de experiência em otimização de desempenho e design de sistemas.
Analise os problemas de desempenho do código abaixo, aponte os gargalos específicos e sugira otimizações.
Código: [cole o código]

Depois de receber um papel, o modelo tende a pensar de uma perspectiva mais profissional e a estruturar melhor a resposta. Mas o papel deve ser específico: “você é especialista” é vago; vale muito mais dizer a área de especialidade e a experiência relevante.

Saída estruturada significa exigir um formato específico, como JSON, Markdown ou tabela. A técnica é especialmente útil na extração de dados e na integração com sistemas posteriores:

Extraia as informações de produto do texto abaixo e retorne em formato JSON:
{
  "product_name": "nome do produto",
  "price": "preço",
  "features": ["lista de características"]
}

Texto: [cole o texto]

Restrições estruturais aumentam muito a utilidade da saída e reduzem o trabalho de processamento posterior.

Camada de raciocínio: fazer o modelo “saber pensar”

As técnicas desta camada permitem que o modelo, além de entender a instrução, realize raciocínios complexos.

Chain-of-Thought (CoT), ou cadeia de raciocínio, pede ao modelo que apresente o processo de raciocínio. A ideia central é simples: em vez de solicitar apenas a resposta, peça primeiro que ele explique como chegou a ela.

Em 2022, um artigo de Wei e outros pesquisadores mostrou que CoT pode elevar significativamente a taxa de acerto em tarefas de raciocínio complexo. O princípio é intuitivo: problemas complexos exigem várias etapas; escrever essas etapas cria uma espécie de “espaço de trabalho” para o modelo e reduz a chance de erro.

A maneira mais simples de usar CoT é acrescentar uma instrução ao fim do prompt:

Pense neste problema passo a passo e depois apresente a resposta.

Outra opção é o Few-shot CoT, com exemplos que mostram o raciocínio:

Pergunta: João tem cinco maçãs, dá duas para Maria e colhe mais três da árvore. Quantas maçãs João tem agora?
Raciocínio: João começa com cinco maçãs. Depois de dar duas a Maria, restam 5 - 2 = 3. Ao colher mais três, fica com 3 + 3 = 6.
Resposta: seis maçãs.

Agora resolva da mesma maneira: há 12 morangos em uma cesta. João come quatro e Maria coloca mais seis na cesta. Quantos morangos há agora?

ReAct, o ciclo de raciocínio e ação, permite que o modelo pense e execute operações alternadamente. O fluxo é Thought (pensar no próximo passo) → Action (executar uma ação) → Observation (observar o resultado) → iniciar uma nova rodada de raciocínio. Ele é especialmente útil quando a tarefa exige ferramentas externas ou busca de informações.

Você é um assistente capaz de pesquisar informações. Responda usando o formato abaixo:

Thought: [o que precisa ser feito agora]
Action: search("[conteúdo da busca]")
Observation: [resultado da busca]
... (repita até encontrar a resposta)
Final Answer: [resposta final]

Pergunta: qual filme ganhou o Oscar de Melhor Filme em 2024?

ReAct é particularmente importante no desenvolvimento de agentes. O núcleo de um agente é justamente o ciclo de “pensar, agir e receber feedback”, e ReAct oferece um modelo padronizado para ele.

Self-Consistency, ou autoconsistência, faz o modelo raciocinar várias vezes sobre o mesmo problema e escolher por votação a resposta mais confiável. É útil quando a precisão precisa ser alta, mas custa mais, pois exige várias chamadas ao modelo.

Tree of Thoughts (ToT), ou árvore de pensamentos, faz o modelo explorar diferentes caminhos de raciocínio e selecionar o melhor. É adequado a decisões complexas, como a geração de propostas criativas e o planejamento estratégico.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Camada de sistema: gestão de prompts como engenharia

Esta camada não é uma técnica isolada, mas um sistema de gestão de prompts.

Prompts modulares. Um prompt complexo é dividido em módulos reutilizáveis. O prompt de um agente, por exemplo, pode ser separado em definição de papel, definição de tarefa, restrições de saída e chamadas de ferramentas. Cada módulo é gerenciado de forma independente e combinado conforme a necessidade.

Otimização automatizada. Com um framework como DSPy, você não precisa ajustar parâmetros manualmente. Basta definir a assinatura da tarefa e as métricas de avaliação para que o framework itere e faça a otimização. Veremos isso em detalhes adiante.

Avaliação padronizada. O processo de avaliação inclui preparar um conjunto de teste, definir métricas, executar testes em lote e registrar a evolução da pontuação a cada iteração. Assim, a otimização passa a se apoiar em dados, e não em impressões.

O framework de três camadas ajuda a identificar a natureza do problema e escolher a técnica adequada. Tarefas simples ficam na camada básica; raciocínios complexos, na camada de raciocínio; e sistemas completos, na camada de sistema.

Análise aprofundada de Chain-of-Thought

A cadeia de raciocínio merece atenção especial. É uma das técnicas mais maduras para melhorar raciocínio e tem uma barreira de entrada baixa: não exige um framework complexo, apenas algumas instruções no prompt.

Zero-shot CoT versus Few-shot CoT

As duas abordagens servem a cenários diferentes.

Zero-shot CoT não fornece exemplos; apenas inclui uma instrução. A versão clássica é:

Let's think step by step.

Ou, em português:

Vamos pensar neste problema passo a passo.

É uma alternativa simples, de baixo custo e adequada à maioria dos cenários. Pesquisas mostram que até uma única frase desse tipo pode aumentar em 20% a 40% a taxa de acerto em tarefas de raciocínio complexo.

Few-shot CoT inclui exemplos completos do processo de raciocínio. Eles devem seguir a estrutura “pergunta → raciocínio → resposta”:

Pergunta: uma loja comprou 100 produtos a R$ 20 por unidade. No primeiro dia, vendeu 30 unidades a R$ 35. No segundo, vendeu 50 a R$ 30. No terceiro, liquidou o restante a R$ 15 por unidade. Qual foi o lucro total?

Raciocínio:
1. Custo total: 100 × R$ 20 = R$ 2.000
2. Receita do primeiro dia: 30 × R$ 35 = R$ 1.050
3. Receita do segundo dia: 50 × R$ 30 = R$ 1.500
4. Restante do terceiro dia: 100 - 30 - 50 = 20 unidades; receita: 20 × R$ 15 = R$ 300
5. Receita total: R$ 1.050 + R$ 1.500 + R$ 300 = R$ 2.850
6. Lucro total: R$ 2.850 - R$ 2.000 = R$ 850

Resposta: R$ 850

Agora resolva da mesma maneira:
Pergunta: uma empresa tem 200 funcionários com salário médio mensal de R$ 8.000. No início do ano, demite 30 pessoas e paga a cada uma indenização equivalente a dois salários. Depois, contrata 50 pessoas com salário de experiência de R$ 6.000 durante três meses. Como muda o gasto da empresa com salários ao longo do ano?

Few-shot CoT ajuda a orientar o modelo para um formato e um modo de raciocínio específicos. Em contrapartida, exige tempo para criar bons exemplos; exemplos ruins podem induzir o modelo ao erro.

Quando usar cada um?

• Tarefa simples, com caminho de raciocínio claro: use Zero-shot CoT; uma instrução basta.
• Tarefa complexa, que exige um formato específico de raciocínio: use Few-shot CoT com bons exemplos.
• Modelo muito capaz, como Claude 4: Zero-shot CoT costuma ser suficiente.
• Modelo menos capaz ou tarefa com alta exigência de precisão: Few-shot CoT tende a ser mais estável.

Onde CoT funciona melhor

Nem toda tarefa precisa de CoT. Ele é mais útil nestes cenários:

Raciocínio matemático e análise lógica. Essas tarefas exigem cálculos ou deduções em várias etapas; CoT ajuda o modelo a não pular nem omitir passos.

# Uma saída sem CoT pode ser:
"A resposta é R$ 850." (pula direto para o resultado e pode ter calculado errado)

# Uma saída com CoT:
"Vou calcular passo a passo..."
E então mostra cada etapa em detalhes.

Planejamento de tarefas em várias etapas. Por exemplo, pedir ao modelo que crie um plano de projeto ou projete uma arquitetura de sistema. CoT permite primeiro decompor a tarefa e depois desenvolver cada parte.

Análise de problemas antes da geração de código. Peça ao modelo que primeiro analise os requisitos, depois projete a solução e só então escreva o código, em vez de produzir código imediatamente.

Implemente um sistema de autenticação de usuários seguindo estas etapas:

Etapa 1: analise os requisitos e liste as funcionalidades centrais
Etapa 2: projete o modelo de dados e as interfaces
Etapa 3: apresente o código da implementação
Etapa 4: explique a estratégia de testes

Requisitos: [descreva seus requisitos]

Algumas variantes de CoT

Auto-CoT gera automaticamente cadeias de raciocínio. O modelo produz o processo de raciocínio dos exemplos e depois os usa como exemplos Few-shot. Isso elimina o trabalho de escrevê-los manualmente. Porém, a qualidade depende da primeira geração: se ela estiver errada, os raciocínios seguintes também serão afetados.

CoD (Chain of Debate), ou cadeia de debate, coloca dois papéis de modelo para discutir o mesmo problema, questionando o raciocínio um do outro antes de chegar a uma síntese. Pode funcionar bem em problemas complexos e abertos, mas custa mais e demora mais.

Cuidados ao usar CoT

Alguns problemas que encontrei na prática:

Não force raciocínio em excesso. Perguntas simples não precisam de CoT. Se você pergunta “qual é a população de Pequim?”, acrescentar CoT apenas deixa a resposta prolixa e pode até criar erros. A pergunta decisiva é: a tarefa exige raciocínio em várias etapas?

Os exemplos precisam corresponder à tarefa. Se os exemplos Few-shot são problemas de matemática, mas a tarefa é lógica, o modelo pode tentar resolver lógica como se fosse matemática, com um resultado ruim. O tipo de exemplo deve ser compatível com o tipo de tarefa.

Não estenda demais o raciocínio. CoT pode aumentar a precisão, mas cadeias muito longas, com dezenas de etapas, acumulam riscos de erro. Em problemas muito complexos, divida o trabalho: primeiro peça ao modelo que decomponha a questão e depois trate cada subproblema separadamente.

Em resumo, CoT é uma das técnicas mais práticas para reforçar raciocínio. Se você dominar Zero-shot e Few-shot e souber quando usar — e quando não usar — cada um, a qualidade dos prompts melhora de forma perceptível.

ReAct: combinando raciocínio e ação

ReAct é a abreviação de Reasoning + Acting. O framework combina pensamento e ação para que o modelo possa chamar ferramentas, obter informações e tomar decisões dinamicamente. Se CoT serve para o modelo “pensar direito”, ReAct serve para ele “pensar enquanto faz”.

O ciclo Thought → Action → Observation

O núcleo de ReAct é uma estrutura cíclica:

Thought (pensamento) → Action (ação) → Observation (observação) → Thought → ...

Cada rodada aproxima o sistema da solução. Veja um exemplo de perguntas e respostas apoiadas por busca:

Tarefa: descobrir a área de pesquisa dos vencedores do Prêmio Nobel de Física de 2024.

Processo executado pelo modelo:

Thought: primeiro preciso descobrir quem venceu o Prêmio Nobel de Física de 2024.
Action: search("2024 Nobel Prize in Physics winners")
Observation: [resultado da busca] O Prêmio Nobel de Física de 2024 foi concedido a John Hopfield e Geoffrey Hinton por suas contribuições na área de redes neurais artificiais.

Thought: agora sei quem são os vencedores e preciso pesquisar suas áreas de atuação.
Action: search("John Hopfield research field")
Observation: [resultado da busca] John Hopfield é físico e propôs o modelo de rede de Hopfield...

Thought: já tenho informações suficientes para responder.
Final Answer: os vencedores do Prêmio Nobel de Física de 2024, John Hopfield e Geoffrey Hinton, trabalham na área de redes neurais artificiais...

Esse ciclo permite ao modelo “buscar o que falta” durante o raciocínio. Quando encontra algo que não sabe, ele não precisa inventar; pode procurar. A diferença em relação a CoT é clara: CoT usa apenas o conhecimento interno do modelo, enquanto ReAct pode recorrer a ferramentas externas.

ReAct versus CoT: diferenças essenciais

CoT é mais adequado quando o modelo já dispõe do conhecimento necessário, como em matemática e lógica. ReAct é melhor quando a tarefa exige informações atuais, consulta a banco de dados ou chamada de API.

Estrutura de um prompt ReAct

Um prompt ReAct padrão contém estas partes:

Você é um assistente inteligente capaz de usar ferramentas. Execute a tarefa no formato abaixo:

Ferramentas disponíveis:
- search(query): pesquisa informações na internet
- database_query(sql): consulta o banco de dados
- calculate(expression): executa cálculos matemáticos

Formato:
Thought: [seu raciocínio sobre o que precisa ser feito agora]
Action: [nome da ferramenta e parâmetros, como search("termo de busca")]
Observation: [resultado da ferramenta, preenchido automaticamente]
... (podem existir várias rodadas de Thought-Action-Observation)
Final Answer: [resposta final]

Comece!

Tarefa: [sua tarefa específica]

Pontos importantes:

Defina as ferramentas disponíveis. O modelo precisa saber quais ferramentas pode usar e como chamá-las. A definição deve ser específica e incluir nome, formato dos parâmetros e tipo de retorno.

Estabeleça o formato de saída. Thought, Action e Observation precisam de um formato claro para que o sistema consiga interpretar a saída, executar a ferramenta e devolver o resultado ao modelo.

Defina uma condição de término. Oriente o modelo a produzir Final Answer quando tiver informações suficientes, evitando ciclos infinitos.

ReAct no desenvolvimento de agentes

ReAct é um dos padrões básicos da arquitetura moderna de agentes. Se você está criando um agente de IA — seja para atendimento, análise de dados ou automação de operações —, é muito provável que use suas ideias.

Em projetos reais, a implementação é mais complexa do que esse prompt simples. Você precisa de:

1. Sistema de registro de ferramentas: definir interfaces, validar parâmetros e controlar permissões.
2. Mecanismo de execução: interpretar a Action do modelo, chamar a ferramenta correspondente e devolver o resultado em formato adequado.
3. Controle de ciclo: limitar o número de rodadas e configurar timeout para evitar loops infinitos.
4. Tratamento de erros: informar ao modelo quando uma ferramenta falha, para que ele possa ajustar a estratégia.

Cuidados ao usar ReAct

O modelo precisa ser capaz o bastante. ReAct exige que o modelo mantenha contexto em várias rodadas e tome boas decisões de ação. Modelos fracos podem chamar ferramentas sem critério ou se afastar do objetivo. Claude e a família GPT-4 costumam ter bom desempenho com ReAct.

As ferramentas precisam de definições claras. Se o modelo não entende o que uma ferramenta faz, pode deixar de usá-la ou chamá-la incorretamente. Descreva cada ferramenta com o mesmo cuidado de uma documentação de API.

Evite dependência excessiva de ferramentas. Algumas informações já fazem parte do conhecimento interno do modelo. Não é necessário chamar uma ferramenta sempre. Você pode acrescentar ao prompt: “se o conhecimento interno for suficiente, forneça diretamente a Final Answer sem chamar ferramentas”.

Controle os custos. ReAct pode disparar várias chamadas a ferramentas, elevando o custo de API. Use-o em tarefas complexas; para tarefas simples, um prompt convencional é mais econômico.

ReAct transforma o prompt de um “roteiro estático” em um “programa dinâmico”, permitindo que a IA realmente execute ações para resolver problemas. É um passo essencial da IA conversacional para a IA capaz de agir.

DSPy: otimização automática de prompts

As técnicas CoT e ReAct ainda exigem que você escreva prompts manualmente. DSPy segue outro caminho: sua ideia central é “Programming, not prompting”. Em outras palavras, você define a tarefa como um programa, e o framework gera e otimiza o prompt automaticamente.

O que é DSPy

DSPy é um framework criado pelo grupo Stanford NLP. Ele transforma engenharia de prompts em um paradigma de programação: você define a estrutura de entrada e saída da tarefa, ou Signature; escolhe um Module; configura um Optimizer; e o framework itera automaticamente até encontrar uma boa configuração de prompt.

Essa abordagem oferece algumas vantagens:

Mais confiabilidade. Prompts escritos manualmente podem ter omissões, formatos incorretos ou restrições insuficientes. A definição declarativa do DSPy é mais rigorosa.

Mais facilidade de manutenção. O prompt vira código e pode receber versionamento, testes unitários e iterações contínuas.

Mais portabilidade. Ao trocar de modelo, não é necessário reajustar todo o prompt; o framework se adapta às características do novo modelo.

Componentes centrais do DSPy

Signature (assinatura da tarefa): define a estrutura de entrada e saída.

import dspy

class QuestionAnswer(dspy.Signature):
    """Responda à pergunta com uma explicação detalhada"""
    question = dspy.InputField(desc="Pergunta do usuário")
    answer = dspy.OutputField(desc="Resposta detalhada, incluindo o raciocínio")

Signature se parece com a interface de uma função: informa quais são as entradas, as saídas e os requisitos de cada campo. Você não escreve o texto exato do prompt, apenas define a estrutura.

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

Module (módulo): encapsula técnicas de prompt em componentes reutilizáveis.

# Módulo mais básico: previsão direta
qa_basic = dspy.Predict(QuestionAnswer)

# Módulo com cadeia de raciocínio
qa_cot = dspy.ChainOfThought(QuestionAnswer)

# Módulo com ReAct (requer ferramentas configuradas)
qa_react = dspy.ReAct(QuestionAnswer, tools=[search_tool, calculator_tool])

Os módulos já encapsulam as técnicas. Para usar CoT, basta escolher ChainOfThought; não é necessário escrever uma instrução como “pense passo a passo”. O framework gera o prompt adequado ao tipo de módulo.

Optimizer (otimizador): otimiza automaticamente a configuração do prompt.

from dspy.teleprompt import BootstrapFewShot

# Preparar dados de treinamento
trainset = [
    dspy.Example(question="O que é recursão?", answer="Recursão ocorre quando uma função chama a si mesma..."),
    dspy.Example(question="Explique o bubble sort", answer="O bubble sort compara elementos vizinhos..."),
]

# Configurar o otimizador
optimizer = BootstrapFewShot(max_bootstrapped_demos=3)

# Otimizar o módulo
qa_optimized = optimizer.compile(qa_cot, trainset=trainset)

O otimizador pode gerar exemplos Few-shot, ajustar a estrutura e iterar em busca de uma configuração melhor. Você fornece dados de treinamento e critérios de avaliação; ele calibra os parâmetros. É parecido com treinar um modelo de machine learning, mas o alvo da otimização é o prompt, não os pesos do modelo.

Um exemplo completo com DSPy

Vamos criar um sistema de perguntas e respostas sobre programação:

import dspy

# 1. Definir a Signature
class CodeQA(dspy.Signature):
    """Responda a perguntas de programação com explicações claras e exemplos"""
    question = dspy.InputField(desc="Pergunta relacionada a programação")
    answer = dspy.OutputField(desc="Resposta detalhada com explicação do conceito e exemplo de código")

# 2. Configurar o modelo de linguagem
lm = dspy.LM("claude-3-5-sonnet-20241022", api_key="your_key")
dspy.settings.configure(lm=lm)

# 3. Criar o módulo (com raciocínio via ChainOfThought)
qa = dspy.ChainOfThought(CodeQA)

# 4. Fazer uma chamada direta
result = qa(question="Como implementar decorators em Python?")
print(result.answer)

Neste exemplo, não escrevemos nenhum texto de prompt. O módulo ChainOfThought gera automaticamente um prompt com orientação para cadeia de raciocínio. O campo answer contém o raciocínio e a explicação detalhada.

Para melhorar o resultado, podemos acrescentar dados de treinamento e um otimizador:

# 5. Preparar os dados de treinamento
train_examples = [
    dspy.Example(
        question="O que é uma REST API?",
        answer="REST API é um estilo arquitetural para interfaces de aplicações web..."
    ),
    dspy.Example(
        question="Explique o conceito de branches no Git",
        answer="Branches do Git permitem criar linhas de trabalho independentes da linha principal..."
    ),
]

# 6. Definir a função de avaliação
def evaluate_answer(example, pred):
    """Verifica se a resposta contém palavras-chave e tem um tamanho razoável"""
    keywords = example.question.lower().split()
    has_keywords = sum(1 for k in keywords if k in pred.answer.lower()) >= 2
    length_ok = len(pred.answer) > 100
    return has_keywords and length_ok

# 7. Otimizar
optimizer = BootstrapFewShot(metric=evaluate_answer, max_bootstrapped_demos=4)
qa_optimized = optimizer.compile(qa, trainset=train_examples)

# 8. Usar o módulo otimizado
result = qa_optimized(question="Como implementar decorators em Python?")

Com base nos dados de treinamento, o otimizador gera exemplos Few-shot e ajusta o formato do prompt para elevar a qualidade da saída. Todo o processo dispensa a calibração manual do prompt.

Quando usar DSPy e quando escrever prompts manualmente

DSPy não resolve tudo. Alguns cenários combinam com o framework; outros são mais bem atendidos por prompts manuais.

Cenários adequados ao DSPy:

• Aplicações de IA que reutilizam muitas vezes a mesma categoria de prompt.
• Tarefas com estrutura clara, cujas entradas e saídas podem ser padronizadas.
• Contextos com dados de treinamento disponíveis para otimização.
• Migração entre modelos, quando cada modelo pode se comportar de maneira diferente.
• Projetos complexos com muitos prompts, difíceis de gerenciar manualmente.

Cenários adequados a prompts manuais:

• Uso pontual, sem necessidade de reutilização.
• Tarefas de estrutura vaga, cujas entradas e saídas são difíceis de padronizar.
• Ausência de dados de treinamento, o que impede a otimização.
• Validação rápida de protótipos, quando é preciso testar depressa sem configurar um framework.
• Tarefas simples que Zero-shot já resolve.

Na minha experiência, DSPy oferece ótimo retorno em aplicações de projeto e sistemas que exigem manutenção de longo prazo. A configuração inicial leva algum tempo, mas as iterações seguintes se tornam muito mais eficientes. Para consultas simples e tarefas pontuais, escrever o prompt à mão é mais direto.

Cuidados ao usar DSPy

As métricas de avaliação são fundamentais. O otimizador depende da função de avaliação. Se o critério for inadequado, a otimização pode seguir na direção errada. Vale investir tempo na criação de boas métricas.

A qualidade dos dados de treinamento importa. BootstrapFewShot usa esses dados para gerar exemplos. Dados ruins produzem exemplos ruins e podem piorar o resultado.

Evite otimização excessiva. Mais iterações não significam necessariamente mais qualidade. O otimizador pode sofrer overfitting nos dados de treinamento e ter desempenho pior em perguntas novas. Defina um limite razoável de iterações.

DSPy representa uma nova direção para a engenharia de prompts: sair do ajuste manual e seguir para a otimização automatizada. Para quem quer criar aplicações de IA de forma sistemática, é uma ferramenta que vale a pena dominar.

Claude versus ChatGPT: melhores práticas para cada modelo

Claude e ChatGPT estão entre os modelos mais usados atualmente. Muita gente pergunta por que o mesmo prompt produz respostas diferentes nos dois e como otimizar para cada um. Vamos examinar essas diferenças e algumas práticas direcionadas.

Comparação das características dos modelos

Primeiro, os principais contrastes:

Essas diferenças não são absolutas; versões e tarefas diferentes podem alterar o comportamento. De modo geral, Claude tende a raciocínio rigoroso e saídas estruturadas, enquanto ChatGPT tende a criatividade flexível e respostas rápidas.

Melhores práticas para Claude

1. Use tags XML para impor estrutura

Claude entende tags XML particularmente bem. Delimitar o conteúdo com tags melhora a qualidade da saída:

Analise os problemas de desempenho do código abaixo:

<code>
function processData(data) {
  let result = [];
  for (let i = 0; i &lt; data.length; i++) {
    result.push(transform(data[i]));
  }
  return result;
}
</code>

Use o seguinte formato para responder:

<analysis>
[análise dos problemas de desempenho]
</analysis>

<suggestions>
[sugestões de otimização]
</suggestions>

As tags XML ajudam o modelo a distinguir claramente entrada e formato de saída. Claude tende a respeitar a estrutura e a manter a análise separada das sugestões.

2. Combine papel, restrições e exemplo

Claude costuma seguir com atenção papéis e restrições. Uma estrutura completa de prompt seria:

Papel:
Você é uma pessoa especialista em otimização de desempenho, com oito anos de experiência em backend Java. Sabe identificar gargalos e propor otimizações aplicáveis.

Restrições da tarefa:
- A análise deve apontar gargalos específicos, sem observações vagas como "isso pode ser otimizado".
- As sugestões devem incluir exemplos de alteração no código.
- Se uma otimização tiver riscos, explique-os claramente.

Exemplo de saída:
<analysis>
Problema: objetos são criados repetidamente dentro do loop, o que pode aumentar a pressão de memória.
Local: loop for nas linhas 3 a 5.
</analysis>
<suggestions>
Sugestão 1: pré-aloque o tamanho do array.
Código: let result = new Array(data.length);
Risco: nenhum risco evidente.
</suggestions>

Agora analise este código:
[cole seu código]

A estrutura informa ao Claude quem ele deve ser, o que precisa fazer e como a saída deve aparecer. Assim, a resposta tende a ficar mais próxima do esperado.

3. Aproveite o contexto longo para análises detalhadas

O contexto de 200K do Claude é adequado para documentos extensos e código complexo. É possível colar um arquivo completo sem receio de truncamento:

Analise o arquivo de código completo abaixo e identifique todos os possíveis problemas de desempenho:

Código completo:
<code>
[cole o arquivo inteiro, com centenas de linhas]
</code>

Analise cada módulo separadamente e apresente os problemas de desempenho e as sugestões de otimização.

Os 128K do ChatGPT também cobrem a maioria dos casos, mas Claude leva vantagem com documentos extremamente longos.

Melhores práticas para ChatGPT

1. Defina explicitamente o formato de saída

ChatGPT tende a ser flexível e às vezes varia o formato. Por isso, imponha restrições claras:

Analise os problemas de desempenho do código. O formato da saída deve ser exatamente este:

## Análise de desempenho
- Problema 1: [descrição específica]
- Problema 2: [descrição específica]

## Sugestões de otimização
| Problema | Sugestão | Exemplo de código |
|-----|-----|---------|
| [problema 1] | [sugestão] | [código] |

Código:
[cole o código]

Restrições em Markdown, com títulos e tabelas, ajudam ChatGPT a seguir o formato com mais rigor.

2. Ajuste o parâmetro de temperatura

O parâmetro temperature do ChatGPT controla a criatividade. temperature = 0 produz saídas mais determinísticas e consistentes; valores entre 0.7 e 1 aumentam criatividade e diversidade.

# Saída determinística (adequada para geração de código e análise de dados)
response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}],
    temperature=0
)

# Saída criativa (adequada para textos e design criativo)
response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}],
    temperature=0.8
)

A API do Claude tem controles semelhantes, mas a temperatura costuma produzir um efeito mais perceptível em ChatGPT.

3. Oriente o trabalho em etapas

ChatGPT às vezes pula etapas e vai direto ao resultado. Em tarefas complexas, divida a orientação:

Execute a tarefa abaixo em etapas:

Etapa 1: liste primeiro os principais módulos funcionais do código
Etapa 2: analise as características de desempenho de cada módulo
Etapa 3: encontre os gargalos de desempenho
Etapa 4: apresente soluções de otimização

Comece apenas pela etapa 1.

Conduzir a saída passo a passo reduz a chance de o modelo pular uma parte e errar.

Prompts diferentes para a mesma tarefa

Considere a tarefa de extrair informações de produto de um texto.

Versão para Claude:

Extraia as informações de produto do texto abaixo:

<text>
[texto de apresentação do produto]
</text>

Formato de saída:
<product_info>
<name>[nome do produto]</name>
<price>[preço]</price>
<features>
<feature>[característica 1]</feature>
<feature>[característica 2]</feature>
</features>
</product_info>

Versão para ChatGPT:

Extraia as informações do produto e retorne em formato JSON.

Texto:
[texto de apresentação do produto]

Exemplo do formato de saída:
{
  "name": "nome do produto",
  "price": "preço",
  "features": ["característica 1", "característica 2"]
}

Siga rigorosamente essa estrutura JSON e não acrescente outros campos.

A diferença é que XML tende a ser mais estável com Claude, enquanto JSON acompanhado de restrições explícitas costuma funcionar melhor com ChatGPT.

Recomendações de escolha

• Raciocínio rigoroso e saída estruturada: priorize Claude.
• Saída criativa e prototipagem rápida: priorize ChatGPT.
• Documentos longos e arquivos de código completos: priorize Claude por causa do contexto de 200K.
• Geração de código e perguntas técnicas: ambos funcionam bem, com estilos um pouco diferentes.
• Redação e design criativo: priorize ChatGPT e aumente a temperatura.

Em projetos reais, você pode escolher o modelo conforme o tipo de tarefa ou testar os dois em paralelo. Os prompts precisam mesmo ser adaptados ao modelo; ignorar suas características pode piorar bastante o resultado.

Metodologia de avaliação e iteração de prompts

Até aqui, vimos muitas técnicas. Ainda falta responder a uma pergunta: como saber se um prompt é bom? Sem avaliação, otimizar é andar às cegas. Vamos organizar um sistema de avaliação e uma metodologia de iteração.

Quatro dimensões centrais de avaliação

Um bom prompt precisa atender a quatro dimensões.

Precisão. O conteúdo da saída está correto? Essa é a dimensão mais importante e também uma das mais difíceis de medir. Em tarefas objetivas, como cálculo e consulta de fatos, basta comparar a saída com a resposta certa. Em tarefas subjetivas, como redação criativa e criação de propostas, precisão passa a significar “corresponde ao esperado”, o que torna a avaliação mais complexa.

Exemplos de métodos:

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

• Matemática: compare o resultado calculado com a resposta correta.
• Geração de código: execute o código e verifique se os testes passam.
• Perguntas e respostas: confirme se a resposta contém os pontos corretos.
• Redação: use avaliação humana ou compare métricas como tamanho e cobertura de palavras-chave.

Consistência. Ao executar várias vezes o mesmo prompt, a qualidade se mantém? Um prompt que funciona hoje e falha amanhã não é adequado para produção.

Método de avaliação: execute a mesma tarefa dez vezes e meça a variação da qualidade. Uma oscilação grande indica falta de consistência.

Segurança. A saída contém conteúdo nocivo, vazamento de dados pessoais ou afirmações preconceituosas? Essa dimensão é especialmente importante em atendimento e moderação de conteúdo.

Método de avaliação: crie regras de detecção de termos sensíveis e dados privados ou use ferramentas especializadas em segurança.

Eficiência de custo. O consumo de tokens é razoável? Prompts longos demais custam caro; curtos demais podem perder qualidade. É preciso encontrar o equilíbrio.

Método de avaliação: registre o número de tokens por chamada, calcule o custo médio e compare o custo-benefício entre versões.

Ferramentas de avaliação

Estas são algumas ferramentas populares para avaliar prompts.

DeepEval. Framework open source com métricas como precisão, consistência e relevância. É adequado para testes em lote e avaliação automatizada.

from deepeval import evaluate
from deepeval.metrics import AnswerRelevancyMetric, FaithfulnessMetric

metrics = [
    AnswerRelevancyMetric(threshold=0.7),
    FaithfulnessMetric(threshold=0.8)
]

evaluate(test_cases, metrics)

Promptfoo. Ferramenta de linha de comando para testar prompts em lote, comparar saídas de modelos e gerar relatórios. É útil para validações rápidas.

promptfoo eval --prompts my_prompt.txt --providers openai:gpt-4 --tests test_cases.yaml

OpenAI Evals. Framework oficial da OpenAI, voltado principalmente à avaliação de modelos, mas também aplicável a testes de prompts.

Essas ferramentas seguem um fluxo parecido: definir o conjunto de teste → executar em lote → atribuir pontuações automaticamente → gerar um relatório. É muito mais eficiente do que testar tudo à mão.

Processo de teste A/B

Ao melhorar um prompt, o teste A/B oferece um método científico. O processo é o seguinte:

Etapa 1: prepare um conjunto de teste. Reúna de 20 a 50 amostras representativas, cobrindo cenários variados. Não use apenas tarefas simples.

Etapa 2: defina as métricas. Escolha métricas de acordo com a tarefa. Em perguntas e respostas, use “taxa de acerto + cobertura de informações”; em geração de código, “taxa de testes aprovados + nota de qualidade do código”.

Etapa 3: execute o teste de referência. Rode o prompt atual sobre todo o conjunto e registre cada métrica. Essa pontuação é o ponto de partida da otimização.

Etapa 4: crie uma versão melhorada. Com base nos problemas encontrados, desenhe uma mudança. Se a precisão for baixa, por exemplo, acrescente CoT; se a consistência for ruim, imponha restrições de formato mais rígidas.

Etapa 5: compare os testes. Execute a nova versão no mesmo conjunto e compare as métricas. Se ela pontuar melhor, adote-a.

Etapa 6: repita o ciclo. Se a melhoria for pequena, analise a causa e prepare outra alteração. Continue até atingir a meta.

Uma tabela simplificada de registro:

Registre os dados de cada mudança para manter a otimização rastreável.

Versionamento de prompts

Prompts também são código e precisam de controle de versão. Algumas recomendações:

Número de versão. Atribua um número, como v1, v2 e v3, e registre a data e a principal alteração.

Histórico de mudanças. A cada modificação, registre o que mudou, por que mudou e qual foi o resultado do teste.

## Histórico de versões do prompt

### v3 (2026-04-15)
Mudança: três exemplos Few-shot adicionados e restrições de formato aprimoradas
Motivo: o teste de consistência da v2 apresentou muita variação e formato instável
Teste: precisão subiu de 78% para 82%; variação de consistência caiu de ±10% para ±5%

### v2 (2026-04-10)
Mudança: instrução CoT "pense passo a passo" adicionada
Motivo: a precisão da v1 era baixa, com muitos erros em raciocínios complexos
Teste: precisão subiu de 65% para 78%

### v1 (2026-04-05)
Versão original, sem otimizações específicas
Teste: precisão de 65% e variação de consistência de ±20%

Armazenamento. Mantenha os arquivos de prompt junto dos dados de teste para facilitar o rastreamento. Você pode usar Git ou uma ferramenta especializada em gestão de prompts.

Pontos essenciais da otimização iterativa

Não altere coisas demais ao mesmo tempo. Mude apenas uma variável por iteração para saber qual mudança funcionou. Não acrescente CoT e Few-shot de uma só vez; teste primeiro CoT e depois Few-shot.

Acompanhe a mudança de custo. Às vezes, a precisão melhora, mas o custo em tokens dobra. Avalie o custo-benefício: a maior precisão possível nem sempre é a melhor escolha.

Registre as tentativas que falharam. Nem toda alteração melhora o resultado. Documentar os fracassos evita repetir os mesmos erros no futuro.

Defina uma meta. Não otimize indefinidamente. Estabeleça um objetivo, como 80% de precisão, e pare ao alcançá-lo. O excesso de otimização desperdiça tempo e sofre com retornos decrescentes.

Avaliação e iteração são as etapas finais da engenharia de prompts. Sem avaliação, você não sabe se o prompt é bom; sem iteração, não consegue melhorá-lo continuamente. Ao incluir as duas, a engenharia de prompts se torna um processo de engenharia completo.

Conclusão

Depois de tudo isso, a ideia central é simples: a engenharia de prompts está deixando de ser “alquimia” para se tornar engenharia.

O framework de três camadas ajuda a escolher a técnica: a camada básica resolve como “fazer o modelo entender”; a camada de raciocínio, como “fazer o modelo pensar”; e a camada de sistema, como “tornar prompts gerenciáveis”. CoT e ReAct são duas das técnicas mais práticas para reforçar raciocínio, enquanto DSPy aponta para a otimização automatizada. Claude e ChatGPT pedem abordagens específicas: tags XML para restringir Claude, formato explícito e temperatura para orientar ChatGPT. Por fim, a avaliação completa a metodologia; sem ela, não existe otimização científica.

Você pode começar com algumas ações:

Revise seus prompts atuais. Em qual camada eles se encontram? Há problemas claros, como instabilidade, custo excessivo ou formato de saída inconsistente?

Experimente DSPy. Se o seu projeto combina com uma gestão por framework, configure um módulo simples e observe o efeito da otimização automática.

Crie seus critérios de avaliação. Prepare um conjunto de teste, defina algumas métricas importantes e execute um benchmark dos seus prompts. Com dados, a otimização ganha direção.

Engenharia de prompts exige prática repetida. Mas, com uma metodologia, pelo menos você deixa de “ajustar no escuro”. Espero que este artigo ajude você a construir uma forma sistemática de pensar. Se tiver dúvidas, fique à vontade para conversar.

Referências

• PromptingGuide.ai — guia oficial de engenharia de prompts
• DSPy Official — site oficial do framework DSPy, de Stanford
• Claude Prompt Engineering Best Practices — documentação oficial da Anthropic
• Chain-of-Thought Prompting Elicits Reasoning — artigo de Wei et al., 2022
• A Systematic Survey of Prompt Engineering — revisão sistemática de 2025