Prompt engineering na prática: como escrever instruções que realmente funcionam

Prompt engineering ganhou um nome sofisticado para algo que no fundo é simples: a arte de dar boas instruções para um sistema de IA. Mas “simples” não significa trivial. A diferença entre um prompt medíocre e um prompt bem construído pode ser a diferença entre um sistema de IA que vai para produção e um que fica em piloto para sempre.

Este artigo é sobre prompts que funcionam em produção — não experimentos em notebook, mas instruções que rodam em escala, com dados reais, e que precisam ser confiáveis.

Por que prompts ruins custam caro

Antes das técnicas, é importante entender o custo de um prompt mal escrito em contexto empresarial.

Um prompt ambíguo gera respostas inconsistentes. Em escala, isso significa revisão humana constante — e você acaba não automatizando nada, só criando um passo extra no processo. Pior: gera falsa confiança. O sistema parece funcionar em testes, vai para produção, e começa a gerar erros que ninguém detecta a tempo.

Cada hora investida em um prompt bem estruturado economiza dezenas de horas de revisão e retrabalho depois.

Um exemplo concreto: uma empresa de logística implementou extração automática de dados de nota fiscal. O primeiro prompt tinha instruções vagas: “Extraia as informações relevantes da NF-e.” O sistema funcionava em testes controlados, mas em produção começou a confundir campos (trocava destinatário por remetente em 8% dos casos), omitia informações críticas e não tinha tratamento para notas com mais de um produto. Resultado: três semanas de desenvolvimento desperdiçadas, erosão de confiança no projeto e retorno ao processo manual.

A segunda tentativa, com prompt estruturado explicitando cada campo a ser extraído, formato de saída JSON rigoroso e instruções para casos especiais, teve taxa de acerto de 97% desde o primeiro dia de produção.

Os quatro elementos de um prompt eficaz

Um prompt robusto para produção não é uma frase solta. É uma estrutura com quatro componentes fundamentais:

1. Contexto (quem é o sistema e o que ele sabe)

O LLM não tem contexto por padrão. Você precisa fornecer:

Papel: quem o sistema está simulando (“Você é um analista de contratos especializado em direito empresarial brasileiro”). Isso não é firula — define o estilo de raciocínio e o nível de especialização que o modelo assume.

Empresa/domínio: o que o sistema precisa saber sobre o contexto (“A empresa atende clientes B2B no setor de logística, com contratos típicos de 12-36 meses envolvendo SLA de entrega”). Quanto mais específico, mais alinhada fica a resposta.

Restrições de conhecimento: o que o sistema NÃO deve inventar (“Se não souber a resposta com base no documento fornecido, diga explicitamente que não tem informação suficiente para responder. Não use conhecimento externo ou assuma informações não presentes no texto.”)

Esse último ponto é crítico para sistemas que lidam com informações sensíveis (jurídico, financeiro, compliance). Um sistema que “acha” informações que não existem é pior do que um sistema que admite não saber.

2. Tarefa (o que fazer, passo a passo)

LLMs performam melhor quando a tarefa é decomposta. Em vez de:

“Analise este contrato e me diga se tem problemas.”

Use:

*“Analise o contrato abaixo seguindo esta sequência:

1. Identifique as partes envolvidas (contratante e contratada).
2. Liste as obrigações de cada parte, organizadas por categoria (entrega, pagamento, confidencialidade).
3. Identifique cláusulas de rescisão e suas condições.
4. Aponte qualquer cláusula incomum ou potencialmente problemática, explicando o motivo da preocupação.
5. Verifique se há cláusulas de renovação automática ou foro específico.”*

A decomposição força o modelo a processar cada etapa com atenção antes de passar para a próxima. É o equivalente a dar uma checklist para um analista júnior — garante que nada essencial seja esquecido.

3. Formato de saída (como o resultado deve aparecer)

Nunca deixe o formato livre se você vai processar a saída programaticamente. Especifique exatamente a estrutura esperada:

Retorne APENAS um JSON com a seguinte estrutura:
{
  "partes": {
    "contratante": "string",
    "contratada": "string"
  },
  "obrigacoes": {
    "contratante": ["string"],
    "contratada": ["string"]
  },
  "clausulas_rescisao": ["string"],
  "alertas": [
    {
      "clausula": "string (identificação da cláusula)",
      "tipo": "string (rescisão/renovação/foro/pagamento/outro)",
      "motivo": "string (por que essa cláusula merece atenção)"
    }
  ],
  "risco_geral": "string (baixo/médio/alto)"
}

Não inclua texto antes ou depois do JSON.
Não use formatação markdown como ```json.

Especificar o formato com esse nível de detalhe reduz dramaticamente a necessidade de parsing e tratamento de exceções no código.

4. Exemplos (few-shot learning)

Para tarefas complexas ou com nuances específicas do seu domínio, incluir 2-3 exemplos de entrada e saída esperada melhora a consistência dramaticamente. Isso se chama few-shot prompting.

Exemplo para classificação de urgência de e-mails:

Classifique os e-mails abaixo quanto à urgência (Alta/Média/Baixa).

Exemplo 1:
E-mail: "O ambiente de produção está fora do ar desde as 14h. Clientes não conseguem fazer login."
Classificação: {"urgência": "Alta", "motivo": "Impacto direto em produção afetando clientes"}

Exemplo 2:
E-mail: "Precisamos revisar o contrato com fornecedor X antes do fim do mês."
Classificação: {"urgência": "Média", "motivo": "Prazo definido mas não imediato"}

Exemplo 3:
E-mail: "Sugestão de melhoria: adicionar dark mode no painel administrativo."
Classificação: {"urgência": "Baixa", "motivo": "Sugestão de funcionalidade, sem prazo crítico"}

Agora classifique este e-mail:
[e-mail do usuário]

O investimento de escrever os exemplos se paga rapidamente em redução de erros e aumento de consistência entre requisições.

Técnicas avançadas para casos específicos

Chain-of-thought para raciocínio complexo

Para tarefas que envolvem raciocínio (análise, diagnóstico, avaliação, cálculo multi-etapa), adicione ao prompt: “Pense passo a passo antes de dar a resposta final. Mostre seu raciocínio.”

Isso força o modelo a “mostrar o trabalho” — o que melhora a qualidade da resposta final E permite que você audite o raciocínio.

Exemplo de uso em análise financeira:

Analise se este investimento é viável considerando:
- Investimento inicial: R$ 500.000
- Receita projetada ano 1: R$ 180.000
- Receita projetada ano 2: R$ 320.000
- Receita projetada ano 3: R$ 450.000
- Custo operacional: 40% da receita
- Taxa mínima de atratividade: 12% a.a.

Pense passo a passo:
1) Calcule o fluxo de caixa de cada ano
2) Calcule o VPL (Valor Presente Líquido)
3) Calcule o payback simples
4) Determine se o investimento é viável ou não
5) Apresente sua conclusão com justificativa

O resultado é substancialmente melhor do que pedir apenas “esse investimento é viável?” — e você consegue rastrear onde o raciocínio pode ter falhado.

Self-consistency para alta confiabilidade

Para decisões críticas onde o custo de um erro é alto (aprovação de crédito, diagnóstico de conformidade legal, classificação de risco), use self-consistency: gere a mesma resposta 3-5 vezes com temperature > 0 e use a resposta mais frequente.

Esse método reduz variabilidade em casos limítrofes. Se em 5 execuções o modelo dá 4 vezes a mesma resposta e 1 vez uma diferente, a resposta mais frequente tende a ser mais confiável.

Para casos onde as respostas divergem muito entre execuções, isso é um sinal de que o modelo não tem confiança — e o caso deve ser escalado para revisão humana.

Grounding com documentos

Quando o modelo precisa responder com base em documentos específicos (contratos, manuais, políticas), coloque o documento no contexto e instrua explicitamente:

Você receberá um documento abaixo e uma pergunta sobre esse documento.

REGRAS OBRIGATÓRIAS:
- Responda APENAS com base no documento fornecido
- Não use conhecimento externo ou geral sobre o assunto
- Se a resposta não estiver no documento, diga explicitamente: "Essa informação não está presente no documento fornecido"
- Ao citar informações, indique a seção ou parágrafo do documento onde está a informação

Documento:
[documento aqui]

Pergunta:
[pergunta do usuário]

Isso reduz alucinações em contextos onde precisão é crítica. O grounding força o modelo a se ater aos fatos presentes no contexto, não ao conhecimento pré-treinado.

Os erros mais comuns em produção

Erro 1: Prompt vago demais

“Classifique este e-mail.”

Classifique por quê? Em quantas categorias? Com qual critério? O que fazer com e-mails que não se encaixam em nenhuma categoria?

Um prompt vago funciona em testes porque você está testando com casos óbvios. Em produção, 20% dos casos são limítrofes — e é nesses que o sistema quebra.

Erro 2: Sem tratamento de casos excepcionais

Todo sistema em produção vai receber inputs que não seguem o padrão esperado: documentos corrompidos, formulários preenchidos pela metade, textos em idiomas inesperados.

O prompt precisa instruir explicitamente o que fazer com entradas ambíguas, incompletas ou fora do escopo:

Se o documento estiver incompleto ou ilegível, retorne:
{"status": "erro", "motivo": "documento ilegível ou incompleto"}

Se o documento não for do tipo esperado (não for uma nota fiscal), retorne:
{"status": "erro", "motivo": "documento não é nota fiscal"}

Sem isso, o modelo vai tentar processar o que não deveria e gerar saídas sem sentido.

Erro 3: Ignorar o comportamento de temperature

Temperature controla aleatoriedade:

• Temperature baixa (0-0.3): respostas mais consistentes e determinísticas. Ideal para extração de dados, classificação, tarefas com uma resposta “certa”.
• Temperature média (0.5-0.7): equilíbrio entre criatividade e consistência. Ideal para atendimento ao cliente, respostas conversacionais.
• Temperature alta (0.8-1.0): respostas mais criativas e variadas. Ideal para geração de conteúdo, brainstorming, quando você quer diversidade.

Para sistemas de extração de dados estruturados, sempre use temperature ≤ 0.2. Para geração de conteúdo criativo, temperature ≥ 0.7.

Erro 4: Não versionar prompts

Prompts evoluem. Você descobre casos que não funcionam, ajusta instruções, melhora exemplos. Sem controle de versão, você não sabe qual versão está em produção e não consegue fazer rollback quando algo quebra.

Trate prompts como código: versione, faça code review, teste mudanças em staging antes de produção.

Um sistema simples: cada prompt tem um ID de versão no banco de dados. Quando você muda o prompt, cria uma nova versão. Em produção, você pode fazer rollback instantâneo para a versão anterior se detectar problemas.

Um framework simples para desenvolver prompts em equipe

Prompt engineering não é trabalho solo. Aqui está um processo que funciona para equipes:

1. Draft inicial

Escreva o prompt de forma livre, capturando a intenção do que o sistema deve fazer. Não se preocupe com perfeição — foque em clareza.

2. Test set

Crie 20-30 casos de teste com entradas variadas, incluindo:

• Casos típicos (80% do volume esperado)
• Casos limítrofes (ambíguos, incompletos, incomuns)
• Casos adversariais (inputs maliciosos ou completamente fora do escopo)

Defina a saída esperada para cada caso.

3. Iteração

Rode o prompt contra o test set. Para cada falha, analise se o problema é:

• Instrução faltando ou ambígua → adicione ou esclareça
• Formato de saída não especificado → especifique
• Falta de exemplo → adicione few-shot

Repita até atingir a taxa de acerto desejada (geralmente 90-95% para produção).

4. Adversarial testing

Tente ativamente quebrar o prompt com inputs que você não previu. Peça a alguém que não participou do desenvolvimento para enviar casos estranhos.

Isso expõe vulnerabilidades antes de irem para produção.

5. Monitoramento em produção

Amostre saídas reais semanalmente para detectar deriva. Em produção, comportamentos inesperados aparecem que não apareceram em testes.

Configure alertas para padrões anômalos: queda súbita na taxa de respostas estruturadas, aumento de erros de parsing, mudança significativa no tamanho médio de resposta.

Prompt engineering não é uma atividade de configuração inicial — é uma prática contínua de manutenção e melhoria.

Quando investir em prompt vs quando investir em fine-tuning

Se você está pensando: “isso é muito trabalho, não seria mais fácil fazer fine-tuning?” — a resposta geralmente é não.

Fine-tuning faz sentido quando:

• Você tem milhares de exemplos de entrada-saída
• A tarefa envolve estilo/tom muito específico que não consegue capturar com prompts
• O volume é tão alto que o custo de contexto (enviar exemplos a cada requisição) se torna significativo

Para a maioria dos casos empresariais, prompt engineering bem feito é mais rápido, mais barato e mais flexível do que fine-tuning.

Ferramentas para gerenciar prompts em escala

Quando você tem dezenas de prompts em produção, gerenciar tudo manualmente se torna inviável. Ferramentas úteis:

Prompt management: LangSmith, PromptLayer, Helicone permitem versionar, testar e monitorar prompts de forma centralizada.

Evaluation frameworks: LangChain Eval, OpenAI Evals, Ragas (para RAG) permitem automatizar a avaliação de prompts contra test sets.

Observability: LangFuse, Arize permitem monitorar qualidade de respostas em produção e detectar deriva.

Você não precisa de todas essas ferramentas no dia 1, mas quando o projeto cresce, elas pagam o investimento rapidamente.

---

Se você está construindo um sistema de IA para a sua empresa e quer garantir que os prompts sejam robustos o suficiente para produção, fale com a gente. Desenvolvemos e mantemos prompts e pipelines de LLM para empresas brasileiras, com práticas de engenharia que garantem qualidade e confiabilidade em escala.