Engenharia de prompt: guia prático para resultados melhores

Engenharia de prompt é a disciplina de escrever instruções que fazem um modelo de linguagem produzir a saída que você realmente quer. Não é mágica nem truque secreto: é comunicação precisa somada a algumas técnicas que aproveitam como o modelo foi treinado. Se você entende o que é um LLM e como ele opera sobre tokens, já tem a base para escrever prompts melhores. Se ainda não, vale ler antes o texto O que é um LLM.

Neste guia você vai encontrar técnicas que uso no dia a dia, com exemplos e o raciocínio por trás de cada uma. A ideia não é decorar fórmulas, mas entender por que elas funcionam.

Por que o prompt importa tanto

Um LLM prevê a continuação mais provável de um texto. Isso significa que tudo que você escreve antes da resposta molda a distribuição de probabilidades que o modelo usa para gerar o próximo token. Um prompt vago abre um leque enorme de continuações plausíveis, e o modelo escolhe uma qualquer dentro desse leque. Um prompt específico estreita esse leque e empurra o modelo para o tipo de resposta que você espera.

Pense em duas instruções. A primeira é "escreva sobre banco de dados". A segunda é "escreva três parágrafos, para um desenvolvedor júnior, explicando a diferença entre um índice B-tree e um índice hash no PostgreSQL, com um exemplo de quando cada um é preferível". A segunda produz resultados muito mais úteis simplesmente porque removeu ambiguidade. Boa parte da engenharia de prompt é isso: eliminar ambiguidade.

Dê contexto e defina o papel

Modelos respondem melhor quando sabem para quem estão escrevendo e em que situação. Definir um papel ajuda a calibrar o tom e a profundidade. Dizer "você é um revisor de segurança experiente analisando este trecho de código" muda completamente o foco da resposta em relação a "olhe este código".

O contexto também inclui restrições. Se a resposta precisa caber em um tweet, diga isso. Se não pode usar bibliotecas externas, diga isso. Se o público é leigo, diga isso. O modelo não adivinha suas restrições implícitas; ele só sabe o que está no prompt.

Um padrão que funciona bem é estruturar o prompt em blocos claros: quem você é, qual é a tarefa, qual o contexto relevante, quais as restrições e qual o formato esperado da saída. Não precisa ser rígido, mas ter esses elementos em mente evita esquecer algo importante.

Mostre exemplos: zero-shot, one-shot e few-shot

Uma das técnicas mais poderosas é dar exemplos do que você quer. Quando você não dá nenhum exemplo, isso se chama zero-shot: você descreve a tarefa e espera que o modelo entenda. Funciona para tarefas comuns.

Quando a tarefa tem um formato específico ou uma nuance difícil de descrever em palavras, dar um ou mais exemplos resolve. Um exemplo é one-shot; vários exemplos são few-shot. Se você quer que o modelo classifique mensagens como "urgente" ou "normal" seguindo um critério particular, mostrar três ou quatro mensagens já classificadas ensina o critério muito melhor do que tentar descrevê-lo por extenso.

Exemplos funcionam porque o modelo é excelente em reconhecer e continuar padrões. Ao ver entradas e saídas emparelhadas, ele infere a regra implícita e a aplica ao próximo caso. Isso costuma ser mais confiável do que uma explicação abstrata da mesma regra.

Peça o raciocínio passo a passo

Para tarefas que envolvem lógica, contas ou várias etapas, pedir que o modelo raciocine antes de responder melhora bastante a precisão. Essa técnica é conhecida como chain-of-thought, ou cadeia de raciocínio. Em vez de exigir a resposta final imediatamente, você instrui o modelo a pensar em voz alta.

A razão é mecânica. Cada token que o modelo gera fica disponível como contexto para os próximos. Ao escrever os passos intermediários, o modelo constrói um andaime que sustenta a conclusão. Pular direto para a resposta força tudo a acontecer "de cabeça", sem esse andaime, e a taxa de erro sobe.

Na prática, frases simples como "pense passo a passo antes de dar a resposta final" ou "primeiro liste as considerações, depois conclua" já ativam esse comportamento. Para problemas de programação, pedir que o modelo descreva a abordagem antes de escrever o código costuma render soluções melhores.

Especifique o formato de saída

Se você vai consumir a resposta em um programa, precisa de um formato previsível. Diga exatamente como quer a saída: uma lista, um objeto com campos nomeados, um parágrafo, uma única palavra. Quanto mais preciso o pedido de formato, menos limpeza você faz depois.

Vale reforçar o que você não quer também. Se não quer explicações antes do resultado, diga "responda apenas com a lista, sem texto introdutório". Modelos tendem a ser prolixos por padrão, então cortar o excesso explicitamente ajuda quando a saída é consumida por código.

Para saídas estruturadas que alimentam outro sistema, seja rigoroso com o esquema. Descreva cada campo, o tipo esperado e o que fazer quando um valor não existe. Ambiguidade no formato vira bug no seu parser.

Decomponha tarefas complexas

Um erro comum é jogar um problema gigante em um único prompt e esperar uma resposta perfeita. Modelos, como pessoas, se saem melhor com tarefas menores e bem delimitadas. Se você precisa gerar um artigo completo com pesquisa, estrutura e revisão, faça isso em etapas: primeiro peça um esboço, depois desenvolva cada seção, depois revise.

Essa decomposição tem duas vantagens. A primeira é qualidade: cada etapa recebe atenção focada. A segunda é controle: você inspeciona o resultado intermediário e corrige o rumo antes de seguir. Encadear prompts, onde a saída de um vira entrada do próximo, é a base de muitos sistemas de IA mais sofisticados.

Itere: o primeiro prompt raramente é o melhor

Engenharia de prompt é empírica. Você escreve, testa, observa onde a resposta falhou e ajusta. Talvez o modelo tenha ignorado uma restrição; então você a torna mais explícita. Talvez tenha inventado um detalhe; então você acrescenta "se não souber, diga que não sabe". Cada iteração fecha uma brecha.

Guarde os prompts que funcionam. Com o tempo você acumula uma biblioteca de padrões testados para as tarefas que repete. Trate prompts importantes como código: versione, comente por que estão escritos daquela forma e teste quando o modelo ou a tarefa muda.

Lide com alucinações e limites

Nenhuma técnica de prompt elimina totalmente as alucinações, aquelas afirmações que soam corretas mas são falsas. O que você pode fazer é reduzir a probabilidade e a gravidade. Peça que o modelo cite a fonte ou o trecho em que se baseou. Instrua-o a admitir incerteza em vez de inventar. Para fatos que precisam ser confiáveis, forneça você mesmo o material de referência dentro do prompt, em vez de confiar na memória do modelo.

Quando a aplicação depende de dados atualizados ou privados, a solução costuma ir além do prompt e entrar no território de recuperação de contexto, um padrão que combina busca com geração. Esse é o assunto do texto sobre RAG, que vale a leitura se você constrói aplicações sérias com IA.

Ajuste os parâmetros do modelo

Além do texto do prompt, a maioria das APIs de LLM expõe parâmetros que afetam a saída, e vale conhecê-los porque complementam a escrita do prompt. O mais importante é a temperatura, que controla o quão aleatória é a resposta. Temperatura baixa produz saídas mais previsíveis e conservadoras, ideal para tarefas que exigem precisão, como extrair dados ou classificar. Temperatura alta produz respostas mais variadas e criativas, útil para brainstorming ou escrita, mas com mais risco de o modelo se desviar.

Há também limites de tamanho de saída, que evitam respostas longas demais e controlam custo, e parâmetros que penalizam repetição. Nenhum deles substitui um bom prompt, mas ajustá-los conforme a tarefa é parte da engenharia. Um erro comum é deixar tudo no padrão e culpar o prompt quando o problema era, na verdade, uma temperatura inadequada para o tipo de tarefa. Pense nos parâmetros e no texto como duas alavancas que trabalham juntas.

Prompt de sistema e prompt de usuário

Muitas interfaces de LLM separam a instrução em duas camadas: o prompt de sistema, que estabelece o papel, as regras gerais e as restrições permanentes, e o prompt de usuário, que traz a pergunta ou tarefa específica de cada interação. Usar essa separação a seu favor deixa o comportamento mais estável. As diretrizes que valem para toda conversa vão no sistema; o que muda a cada pedido vai no usuário.

Essa estrutura também tem implicações de segurança, porque o conteúdo que vem do usuário pode conter tentativas de sobrescrever suas instruções, um ataque que exploramos no texto sobre segurança em aplicações que usam IA. Ao construir aplicações, mantenha suas instruções firmes no prompt de sistema e trate o texto do usuário sempre como dado potencialmente hostil, não como comando confiável.

Um checklist prático

Antes de considerar um prompt pronto, vale passar por alguns pontos. Eles cobrem os erros mais comuns.

• Papel e contexto: o modelo sabe para quem escreve e em que situação?
• Tarefa clara: a instrução principal é inequívoca?
• Restrições explícitas: tamanho, tom, o que evitar, tudo declarado?
• Formato definido: a saída tem estrutura previsível?
• Exemplos, se necessário: a nuance foi mostrada, não só descrita?
• Raciocínio, se necessário: tarefas lógicas pedem passo a passo?
• Tratamento de incerteza: o modelo sabe o que fazer quando não sabe?

Conclusão

Engenharia de prompt não substitui entender o problema que você está resolvendo, mas amplifica muito o que um LLM consegue entregar. As técnicas centrais são poucas e se reforçam: dar contexto, mostrar exemplos, pedir raciocínio, definir formato, decompor e iterar. Nenhuma delas é complicada. O que separa quem tira resultados medíocres de quem tira resultados excelentes é a disciplina de aplicá-las de forma consciente, testar o efeito e refinar.

Comece simples, observe onde o modelo erra e ajuste o prompt para fechar essa brecha específica. Em pouco tempo você desenvolve intuição para prever o que funciona, e escrever bons prompts deixa de ser tentativa e erro para virar parte natural do seu fluxo de trabalho com IA.