Prompt engineering virou buzzword, mas a maior parte do conteúdo sobre o assunto é superficial: "escreva prompts claros", "seja específico", "dê exemplos". Útil como conselho geral, mas insuficiente para quem constrói sistemas de IA em produção onde a qualidade do output precisa ser mensurável e consistente. Este artigo cobre técnicas com impacto real, com exemplos que você pode aplicar diretamente.
O princípio fundamental: modelos são simuladores de texto
Antes das técnicas, um modelo mental importante: LLMs não entendem suas intenções — eles completam padrões de texto. Quando você escreve um prompt, você está, implicitamente, invocando um personagem: qual tipo de texto costuma aparecer em resposta a um texto como o seu? Prompts que funcionam constroem explicitamente o contexto, o personagem e as restrições que levam ao tipo de completion que você quer.
Técnica 1: System prompt como especificação, não como instrução
A maioria das pessoas escreve system prompts como uma lista de instruções. A abordagem mais eficaz é escrever como uma especificação de comportamento — descrição do personagem, não lista de comandos:
// Fraco: lista de instruções
system: |
Você é um assistente de suporte.
Responda perguntas dos clientes.
Seja educado.
Não fale sobre concorrentes.
Responda em português.
// Forte: especificação de personagem com contexto
system: |
Você é o assistente virtual da Acme Seguros, especializado em sinistros
de automóvel. Você tem 10 anos de experiência prática em regulação de
sinistros e conhece profundamente o processo interno da empresa.
Seu objetivo principal é guiar o segurado pelo processo de abertura de
sinistro de forma clara e empática, reduzindo a ansiedade típica desse
momento.
Você:
- Usa linguagem simples, sem jargão técnico, mas com precisão
- Sempre valida o entendimento antes de prosseguir para o próximo passo
- Reconhece quando um caso requer atenção humana e transfere proativamente
- Nunca especula sobre valores de indenização — apenas explica o processo
Quando não souber algo específico sobre a apólice do cliente, diga:
"Preciso verificar os detalhes da sua apólice. Posso te conectar com um
de nossos reguladores?" — nunca invente informações sobre cobertura.
A segunda versão define implicitamente dezenas de comportamentos: tom, nível de detalhe, quando escalar, o que nunca fazer. É mais difícil de contornar por usuários tentando fazer o modelo se comportar fora do escopo.
Técnica 2: Chain-of-thought explícito
Para tarefas que exigem raciocínio — classificação com critérios múltiplos, análise, diagnóstico — forçar o modelo a mostrar o raciocínio melhora a qualidade final. O clássico "let's think step by step" funciona, mas uma versão estruturada funciona melhor:
// Prompt para classificar prioridade de ticket de suporte
user: |
Classifique o ticket abaixo. Raciocine em voz alta antes de dar o veredicto.
Ticket: "Meu sistema de pagamentos parou de funcionar às 14h. Tenho clientes
tentando pagar e não consigo processar nenhuma transação. Isso já dura 2 horas."
Raciocínio (pense antes de classificar):
- Qual o impacto no negócio do cliente?
- Quantos usuários finais são afetados?
- Existe workaround imediato?
- Há urgência de tempo?
Após raciocinar, forneça:
PRIORIDADE: [P1/P2/P3/P4]
JUSTIFICATIVA: [uma frase]
AÇÃO_IMEDIATA: [próximo passo]
// Resposta típica com chain-of-thought:
// Raciocínio:
// - Impacto: sistema de pagamentos = receita parada. Alto.
// - Usuários afetados: todos que tentam pagar = potencialmente muitos.
// - Workaround: não mencionado, assumo que não há.
// - Urgência: 2 horas já = pressão crescente, cada minuto custa receita.
//
// PRIORIDADE: P1
// JUSTIFICATIVA: Sistema de pagamentos inoperante impacta receita diretamente há 2h.
// AÇÃO_IMEDIATA: Escalar para engenheiro de plantão e iniciar war room.
O raciocínio visível tem duas vantagens: a qualidade da conclusão melhora (o modelo "pensa" antes de concluir), e você consegue auditar por que o modelo chegou àquela classificação — útil para detectar falhas de critério.
Técnica 3: Few-shot com exemplos contrastivos
Few-shot (dar exemplos no prompt) é amplamente conhecido. O que a maioria não faz: incluir exemplos negativos — casos limítrofes onde a resposta correta é diferente do intuitivo:
system: |
Você classifica sentimento de avaliações de produto como POSITIVO, NEGATIVO ou NEUTRO.
Exemplos:
---
Avaliação: "Entregou rápido, produto como esperado."
Classificação: POSITIVO
Raciocínio: Aprovação explícita de logística e produto.
Avaliação: "O produto é ok, mas o atendimento foi terrível."
Classificação: NEGATIVO
Raciocínio: Sentimento misto — quando há componente negativo explícito sobre a
experiência de compra, classifique como NEGATIVO independente de elogios parciais.
Avaliação: "Chegou em 3 dias."
Classificação: NEUTRO
Raciocínio: Informação factual sem valoração positiva ou negativa explícita.
Avaliação: "Não esperava que fosse tão bom!"
Classificação: POSITIVO
Raciocínio: Surpresa positiva = sentimento positivo, mesmo que implique expectativas baixas.
Avaliação: "Tô aguardando chegar pra ver."
Classificação: NEUTRO
Raciocínio: Estado de expectativa sem avaliação do produto — ainda não pode ser julgado.
---
Agora classifique a avaliação abaixo seguindo o mesmo padrão.
O exemplo do "produto ok, atendimento terrível" é o caso contrastivo — sem ele, o modelo poderia classificar como NEUTRO por ter componentes positivos e negativos. Incluir o caso difícil e explicar o raciocínio correto é o que torna few-shot útil de verdade.
Técnica 4: Estrutura XML para delimitar contexto
Quando você injeta conteúdo externo no prompt (documentos, dados de banco, histórico de conversa), o modelo precisa saber exatamente onde o conteúdo começa e termina. Tags XML são o delimitador mais claro:
user: |
Responda à pergunta do cliente baseando-se APENAS nas informações da
política de reembolso abaixo. Se a resposta não estiver na política,
diga "Esta informação não está disponível na nossa política de reembolso."
<politica_reembolso>
Produtos podem ser devolvidos em até 30 dias após a entrega. O produto
deve estar em estado original, com embalagem e nota fiscal. Produtos
em promoção têm prazo de 7 dias. Itens personalizados não têm direito
a reembolso, exceto em caso de defeito de fabricação.
</politica_reembolso>
<historico_conversa>
Cliente: "Comprei um produto em promoção há 10 dias. Posso devolver?"
Assistente: "Produtos em promoção têm prazo de 7 dias para devolução. Infelizmente,
como já passaram 10 dias, o prazo expirou."
Cliente: "Mas o produto veio com defeito!"
</historico_conversa>
<pergunta_atual>
"Então tenho direito a reembolso mesmo sendo promoção e depois do prazo?"
</pergunta_atual>
As tags XML ajudam o modelo a não confundir instruções do sistema com conteúdo do usuário — uma das causas mais comuns de comportamento errático. Anthropic (Claude) e OpenAI recomendam explicitamente esse padrão para RAG e injeção de contexto.
Técnica 5: Prompts negativos — diga o que não fazer
Instrução positiva ("responda com base no documento") e instrução negativa ("nunca invente informações não presentes no documento") ativam diferentes mecanismos de atenção no modelo. Prompts robustos combinam os dois:
system: |
Você é um assistente que responde perguntas sobre regulamentações tributárias
brasileiras.
FAÇA:
- Cite o artigo ou lei específica quando embasar uma afirmação
- Diga "esta matéria é controversa" quando houver interpretações conflitantes
- Sugira consultar um contador quando a situação for complexa ou de alto valor
NÃO FAÇA:
- Nunca afirme certeza sobre interpretação tributária sem citar a fonte legal
- Nunca forneça estimativas de valores de imposto sem os dados completos
- Nunca ignore contexto fornecido pelo usuário ao responder
- Nunca responda como se fosse um advogado ou contador cadastrado
A lista negativa é particularmente eficaz para casos edge que são difíceis de cobrir com exemplos positivos. Você está explicitando o espaço de comportamentos proibidos.
Técnica 6: Meta-prompts para geração de prompts
Para casos onde você precisa gerar muitos prompts variados (diferentes produtos, diferentes contextos, diferentes idiomas), use um meta-prompt — um prompt que gera outros prompts:
// Meta-prompt: gera prompts de extração para diferentes tipos de documento
user: |
Gere um prompt de sistema para extração de dados do tipo de documento abaixo.
O prompt gerado deve: definir um personagem especialista, especificar o formato
JSON de saída com todos os campos relevantes, incluir instruções para campos
ausentes (usar null), e listar 3 casos edge com tratamento correto.
Tipo de documento: {{tipo_documento}}
Campos obrigatórios: {{campos}}
Casos edge conhecidos: {{casos_edge}}
// Exemplo de uso:
tipo_documento: "Nota Fiscal Eletrônica (NF-e) brasileira"
campos: "emitente_cnpj, destinatario_cnpj, data_emissao, valor_total, itens[]"
casos_edge: "NF-e cancelada, NF-e com desconto, produto com código personalizado"
Meta-prompts são úteis quando você tem muitas variações de um mesmo padrão de extração. Você define o padrão uma vez e gera as variações automaticamente.
Como medir se seu prompt melhorou
Nenhuma técnica de prompt vale nada sem medição. O processo mínimo:
// 1. Colete casos de teste com input + output esperado
var casos = new[]
{
new TestCase(
Input: "Produto chegou errado. Quero meu dinheiro de volta.",
ExpectedClassification: "NEGATIVO",
ExpectedPriority: "P2"
),
// mínimo 20 casos cobrindo casos normais, edge cases e negativos
};
// 2. Execute ambas as versões do prompt nos mesmos casos
var resultadosV1 = await AvaliarPromptAsync(promptV1, casos);
var resultadosV2 = await AvaliarPromptAsync(promptV2, casos);
// 3. Compare métricas agregadas
Console.WriteLine($"V1 — Acurácia: {resultadosV1.Accuracy:P1}, Latência p95: {resultadosV1.P95}ms");
Console.WriteLine($"V2 — Acurácia: {resultadosV2.Accuracy:P1}, Latência p95: {resultadosV2.P95}ms");
// 4. Examine casos onde V1 acertou mas V2 errou (regressões)
var regressoes = resultadosV1.Corretos.Except(resultadosV2.Corretos);
foreach (var caso in regressoes)
Console.WriteLine($"REGRESSÃO: {caso.Input} — esperado {caso.Expected}, obtido {caso.V2Result}");
Sem esse processo, "melhorar o prompt" é superstição — você não sabe se ajudou, prejudicou ou foi neutro.
Armadilhas comuns
Prompt overfit: Você ajusta o prompt até funcionar nos 5 casos que você tem em mente, mas quebra em produção onde os inputs são mais variados. Solução: test suite amplo antes de qualquer mudança.
Instruções contraditórias: "Seja conciso" e "inclua todos os detalhes relevantes" são instruções que o modelo vai resolver arbitrariamente. Seja específico: "responda em no máximo 3 parágrafos".
Contexto insuficiente vs contexto excessivo: Modelos tendem a ignorar informações no meio de prompts muito longos (o chamado "lost in the middle" problem). Coloque as informações mais críticas no início e no final do prompt.
Assumir que o modelo "sabe" contexto implícito: "Responda como especialista" sem definir o que especialista significa naquele domínio leva a comportamentos inconsistentes. Especifique: "Você tem 10 anos de experiência em X e conhece Y em profundidade".
Prompt engineering é engenharia — não é arte nem magia. Como em qualquer parte do sistema, o que diferencia um prompt de produção de um prompt de demo é a presença de testes, versionamento e métricas. Sem isso, você está fazendo suposições sobre o comportamento do sistema mais não-determinístico da sua stack.