Padrões de Prompt

O que são Padrões de Prompt?

Padrões de prompt (prompt patterns) são estruturas de prompt reutilizáveis — modelos e sequências de interação — que induzem de forma confiável um comportamento desejado em um modelo de linguagem grande (large language model, LLM) para tarefas comuns como extração de informações (information extraction), planejamento (planning), crítica/revisão (critique/review), classificação (classification) e transformação (transformation).

Um bom padrão de prompt é mais do que “uma redação esperta”. Ele é um projeto que:

  • define intenção e escopo,
  • restringe saídas (formato, tom, segurança, tamanho),
  • fornece contexto de base e exemplos,
  • e antecipa modos de falha (alucinações (hallucinations), ambiguidade (ambiguity), injeção (injection)).

Em um sentido de wiki educacional, padrões de prompt são, para a elaboração de prompts (prompting), o que padrões de projeto (design patterns) são para a engenharia de software (software engineering): eles capturam o que funciona, quando funciona e como aplicar de forma consistente.

Padrões de prompt vivem dentro da prática mais ampla de elaboração de prompts e se conectam fortemente a:

Fundamentos teóricos: por que padrões funcionam

Modelos de linguagem grandes como geradores condicionais

Modelos de linguagem grandes modernos (frequentemente baseados na Arquitetura Transformer) geram texto prevendo o próximo token dado os tokens anteriores. Um prompt se torna contexto de condicionamento que influencia:

  • qual tarefa o modelo infere,
  • qual estilo e formato ele imita,
  • quais restrições ele “tenta” satisfazer.

Como os modelos são treinados em corpora de texto vastos e muitas vezes ajustados por instrução (instruction-tuned), eles aprendem correlações entre certos estilos de instrução (“Extract fields… output JSON…”) e continuações prováveis.

Aprendizado em contexto e inferência implícita de tarefas

Modelos de linguagem grandes podem realizar aprendizado em contexto (in-context learning): eles inferem uma tarefa a partir de exemplos e instruções fornecidos no prompt. Padrões de prompt exploram isso ao:

  • tornar a tarefa explícita (“Você irá extrair…”),
  • fornecer exemplos de entrada/saída no estilo poucos exemplos (few-shot),
  • e padronizar a estrutura para que o modelo não precise adivinhar.

Prompts como contratos (e por que estrutura importa)

Um padrão de prompt é, na prática, um contrato entre usuário e modelo:

  • Entradas: quais dados o modelo pode usar (e o que ele deve ignorar),
  • Saídas: esquema (schema) obrigatório, nível de detalhe e restrições,
  • Tratamento de erros: o que fazer quando dados estão ausentes ou ambíguos.

Padrões reduzem ambiguidade, e a ambiguidade é um grande fator por trás de saídas inconsistentes e alucinações.

Por que “controle de formato (format control)” é tão importante

Muitas aplicações práticas precisam de saídas legíveis por máquina (machine-readable). Padrões que impõem esquemas (JSON, tags semelhantes a XML (XML-like tags), formatos em tópicos) reduzem erros de análise a jusante (downstream parsing errors) e permitem validação automática (automatic validation).

Quando disponível, prefira recursos da plataforma que imponham estrutura (por exemplo, “modo JSON (JSON mode)” ou “saídas estruturadas (structured outputs)”), mas padrões de prompt continuam sendo essenciais para:

  • definições de campos,
  • regras de validação,
  • e tratamento de valores ausentes/desconhecidos.

Blocos de construção centrais dos padrões de prompt

A maioria dos padrões robustos combina estes componentes:

  1. Papel / enquadramento (framing): “Você é um analista de conformidade…”
  2. Declaração de tarefa: uma única instrução clara
  3. Contexto e limites de dados: delimitadores, texto entre aspas, listas de fontes
  4. Restrições: deve/deveria/não deve; tamanho; tom; segurança
  5. Formato de saída: esquema explícito e exemplos
  6. Verificações de qualidade: autoconsistência (self-consistency), lista de verificação (checklist), citar evidências, tratamento de incerteza
  7. Ciclo de interação (interaction loop): fazer perguntas de esclarecimento ou seguir com suposições

Um modelo reutilizável frequentemente se parece com:

ROLE: {{role}}

TASK: {{task}}

INPUT:
<document>
{{input_text}}
</document>

CONSTRAINTS:
- Use only the document content.
- If a field is missing, output null.
- Do not include extra keys.

OUTPUT FORMAT (JSON):
{{schema}}

QUALITY CHECK:
- Verify each value is supported by the document.

Catálogo de Padrões de Prompt (com exemplos práticos)

1) Padrão de Contexto Delimitado (Delimited Context Pattern) (uma base para muitos outros)

Use quando: você fornece textos longos, logs, e-mails, transcrições ou múltiplas fontes.
Objetivo: impedir que o modelo misture instruções com dados e reduzir vazamento acidental de conversas anteriores.

Modelo:

You will perform {{task}}.

Only use information inside <source>...</source>.
If the answer is not in the source, say "Not found".

<source>
{{text}}
</source>

Observações:

  • Delimitadores não são segurança por si só (ver Segurança de Prompts), mas aumentam a confiabilidade.
  • Em sistemas com uso de ferramentas (tool-using systems), combine delimitadores com políticas rígidas de ferramentas e higienização de entrada (input sanitization).

2) Padrão de Extração Estruturada (Structured Extraction Pattern) (esquema primeiro)

Use quando: extrair entidades/campos de texto não estruturado para um banco de dados.
Objetivo: saída consistente e analisável, com tratamento explícito para valores ausentes.

Modelo (estilo de esquema JSON):

Extract the following fields from the text.

Rules:
- Use only the text provided.
- If a field is missing, use null.
- Output valid JSON matching the schema exactly.
- Do not add extra keys.

Schema:
{
  "invoice_number": "string|null",
  "invoice_date": "YYYY-MM-DD|null",
  "vendor_name": "string|null",
  "total_amount": "number|null",
  "currency": "string|null"
}

Text:
<doc>
{{invoice_text}}
</doc>

Exemplo de entrada:

Invoice #A-1931
Date: 5 Oct 2025
Vendor: Northwind Traders
Total Due: $1,240.50 USD

Exemplo de saída:

{
  "invoice_number": "A-1931",
  "invoice_date": "2025-10-05",
  "vendor_name": "Northwind Traders",
  "total_amount": 1240.5,
  "currency": "USD"
}

Dicas práticas:

  • Especifique regras de normalização (formatos de data, códigos de moeda, separadores decimais).
  • Adicione um campo opcional "evidence" se você precisar de auditabilidade (mas seja consistente).

3) Padrão de Classificação (Classification Pattern) (conjunto de rótulos (label set) + restrições de justificativa)

Use quando: roteamento (routing), rotulagem (tagging), moderação (moderation), triagem (triage), detecção de intenção (intent detection).
Objetivo: rótulos estáveis com o mínimo de deriva (drift).

Modelo:

Classify the user message into exactly one label from:
- BILLING
- TECH_SUPPORT
- SALES
- OTHER

Rules:
- Output only the label (no extra text).
- If uncertain, choose OTHER.

Message:
{{message}}

Variante: “rótulo + justificativa curta”
Útil quando humanos revisam os resultados:

Output JSON: {"label": "...", "justification": "one sentence"}.
Justification must quote or reference specific words from the message.

Armadilha: rótulos demais ou definições sobrepostas aumentam inconsistências. Defina rótulos com precisão.

4) Padrão de Reescrita / Transformação (Rewrite / Transformation Pattern) (preservar significado, mudar a forma)

Use quando: reformatar, simplificar, traduzir, transferência de estilo (style transfer), anonimização (redaction).
Objetivo: preservar a semântica enquanto aplica restrições rígidas.

Modelo:

Rewrite the text for {{audience}}.

Constraints:
- Preserve all factual claims.
- Do not add new information.
- Keep it under {{max_words}} words.
- Maintain bullet structure.

Text:
{{text}}

Exemplo (anonimização):

Redact personal data (names, emails, phone numbers).
Replace with [NAME], [EMAIL], [PHONE].
Return the redacted text only.

5) Padrão Planejar-Então-Executar (Plan-Then-Execute Pattern) (decomposição (decomposition) para tarefas complexas)

Use quando: tarefas de múltiplas etapas como síntese de pesquisa, migrações, planos de aula, scaffolding de projetos.
Objetivo: quebrar uma tarefa em etapas e reduzir requisitos esquecidos.

Modelo (duas etapas em um único prompt):

You will produce:
1) A plan (bulleted steps)
2) The final deliverable

Constraints:
- The final deliverable must follow the plan.
- If any requirement is ambiguous, list questions first.

Task:
{{task_description}}

Exemplo (migração de software):

Task: Plan and outline a migration from a monolith to services for a checkout system.
Constraints: include rollout strategy, data migration, and observability.

Observação importante sobre raciocínio (reasoning):
Muitas equipes querem “raciocínio passo a passo”. Por razões de segurança e de políticas, frequentemente é melhor pedir um plano conciso e considerações-chave (key considerations) em vez de exigir cadeia de pensamento (chain-of-thought) interna. Se você quer melhorar a qualidade sem raciocínio verboso, peça:

  • suposições,
  • lista de verificação,
  • artefatos intermediários (intermediate artifacts) (tabelas, planos),
  • e uma resposta final.

6) Padrão de Crítica / Revisor (Critique / Reviewer Pattern) (auto-revisão ou revisão em segunda passada)

Use quando: melhorar qualidade, capturar erros, garantir completude, checar tom.
Objetivo: separar criação de avaliação.

Modelo (duas passadas):

Step 1: Draft the answer.

Step 2: Critique the draft against this rubric:
- Correctness
- Completeness
- Clarity
- Risky claims / hallucinations
- Actionability

Step 3: Provide a revised final answer.

Exemplo (conformidade com políticas):

Critique for:
- Unsupported claims
- Missing citations (if applicable)
- Ambiguous instructions
Then revise.

Por que funciona: redigir e criticar são modos diferentes; solicitá-los explicitamente reduz a “fixação na primeira resposta (first answer lock-in)”.

7) Padrão de Lista de Verificação / Rubrica (Checklist / Rubric Pattern) (critérios explícitos de sucesso)

Use quando: você precisa de cobertura consistente (por exemplo, revisões de PR (PR reviews), análise de requisitos, planos de aula).
Objetivo: impor completude em entradas variadas.

Modelo:

Produce {{artifact}}.

Before finalizing, verify against this checklist and fix issues:
- [ ] Includes X
- [ ] Addresses Y edge case
- [ ] Defines terms Z
- [ ] Provides example

Return:
1) The checklist with pass/fail notes
2) The final artifact

Dica: se você precisa de um sinal de QA legível por máquina (machine-readable QA signal), produza JSON para os resultados da lista de verificação.

8) Padrão de Suposições e Esclarecimentos (Assumption & Clarification Pattern) (tratamento de ambiguidade)

Use quando: tarefas frequentemente não têm os detalhes necessários.
Objetivo: evitar alucinar informações ausentes e tornar a incerteza explícita.

Modelo:

If needed information is missing, ask up to 3 clarifying questions.
If the user cannot answer, proceed with clearly stated assumptions.

Return:
- Questions (if any)
- Assumptions
- Final output

Variante (sem perguntas permitidas):

Do not ask questions. Instead, list assumptions and provide a best-effort answer.
Mark any speculative content as "Assumption".

Esse padrão ajuda a prevenir o modo de falha “errado com confiança (confidently wrong)” destacado em Armadilhas da Engenharia de Prompts.

9) Padrão de Resposta Fundamentada + Evidências (Grounded Answer + Evidence Pattern) (amigável à geração aumentada por recuperação (retrieval-augmented generation, RAG))

Use quando: responder a partir de fontes fornecidas (documentos, trechos recuperados).
Objetivo: reduzir alucinações e melhorar auditabilidade.

Modelo:

Answer the question using only the sources.

For each claim, cite a source ID in brackets.
If the answer is not present, say "Not in sources".

Sources:
[1] {{snippet1}}
[2] {{snippet2}}

Question: {{question}}

Exemplo de saída:

The warranty period is 2 years [1]. Coverage excludes accidental damage [2].

Observação prática: isso funciona especialmente bem em sistemas de geração aumentada por recuperação; combine com avaliação robusta (ver Avaliação de Prompts).

10) Padrão de Uso de Ferramentas / Chamada de Função (Tool-Use / Function-Call Pattern) (fluxos de trabalho agênticos (agentic workflows))

Use quando: o modelo precisa chamar ferramentas (busca, banco de dados, execução de código) em vez de “chutar”.
Objetivo: impor “não alucine — use ferramentas”.

Modelo (conceitual):

You have access to tools: search(), get_user(), run_sql().

Rules:
- If information is needed, call the appropriate tool.
- Do not invent tool outputs.
- After tools return, produce the final answer.

Task: {{task}}

Observação de segurança: o uso de ferramentas amplia a superfície de ataque (attack surface). A elaboração defensiva de prompts (defensive prompting) ajuda, mas deve ser combinada com controles em nível de sistema (system-level controls), permissões estritas (strict permissions) e validação de entrada (input validation) (ver Segurança de Prompts).

11) Padrão de Demonstração com Poucos Exemplos (Few-Shot Demonstration Pattern) (ensinar por exemplo)

Use quando: você precisa de um estilo ou transformação consistentes e instruções sozinhas são insuficientes.
Objetivo: aproveitar aprendizado em contexto mostrando exemplos.

Modelo:

Follow the pattern in the examples.

Example 1:
Input: ...
Output: ...

Example 2:
Input: ...
Output: ...

Now do:
Input: {{input}}
Output:

Dica: mantenha exemplos representativos de casos-limite (edge cases) reais. Sobreajuste a exemplos é um risco conhecido (ver Armadilhas da Engenharia de Prompts).

Combinando padrões: construindo “programas de prompt (prompt programs)”

Aplicações reais frequentemente compõem múltiplos padrões em um pequeno fluxo em etapas (pipeline):

  1. Contexto delimitado para isolar dados
  2. Extração em campos estruturados
  3. Validação/Lista de verificação para sinalizar valores ausentes/inválidos
  4. Crítica para capturar extrações sem suporte
  5. Uso de ferramentas para buscar informações faltantes (se permitido)
  6. Geração do relatório final

Essa abordagem costuma ser mais confiável do que um único prompt monolítico (monolithic prompt), porque cada etapa tem um escopo mais estreito e critérios de sucesso mais claros.

Orientações práticas para usar padrões de prompt em produção (production)

Parametrize modelos

Trate padrões como ativos reutilizáveis com variáveis:

  • {{task}}, {{audience}}, {{schema}}, {{constraints}}, {{sources}}
  • armazene em controle de versão (version control)
  • revise mudanças como código

Isso permite testes sistemáticos e reversão (rollback) (ver Avaliação de Prompts).

Prefira regras explícitas de “conteúdo permitido (allowed content)”

Quando precisão importa, adicione restrições como:

  • “Use apenas as fontes fornecidas.”
  • “Se não estiver presente, diga ‘Not found’.”
  • “Não infira além dos dados.”

Isso não elimina alucinações, mas as reduz substancialmente e torna falhas mais fáceis de detectar.

Valide saídas automaticamente

Para saídas estruturadas:

  • validar JSON
  • impor enumerações (enums)
  • checar campos obrigatórios
  • rejeitar e tentar novamente (reject and retry) com um prompt de correção de erro (error-correction prompt)

Um padrão comum de nova tentativa:

Your previous output was invalid because: {{validator_error}}.
Return corrected JSON only, matching the schema exactly.

Decida como você quer que a incerteza apareça

Aplicações diferentes exigem comportamentos diferentes:

  • assistente voltado ao consumidor (consumer assistant): melhor esforço (best-effort) com ressalvas
  • conformidade (compliance): “desconhecido” estrito se não houver suporte
  • automação (automation): confiança (confidence) legível por máquina + caminho de escalonamento (escalation path)

Seja explícito no padrão.

Meça, não chute

Padrões de prompt devem ser avaliados como qualquer outro componente:

  • defina um conjunto de testes (test set) (incluindo casos adversariais (adversarial) e casos-limite)
  • meça correspondência exata (exact-match) / validade do esquema (schema validity) / factualidade (factuality)
  • acompanhe regressões após edições

Esse é o núcleo de Avaliação de Prompts.

Antipadrões comuns (anti-patterns) (e alternativas mais seguras)

“Faça tudo em um único prompt” para fluxos complexos

Sintoma: saída inconsistente, requisitos esquecidos.
Alternativa: Planejar-Então-Executar + Lista de verificação + saídas intermediárias estruturadas.

“Produza JSON” sem um esquema

Sintoma: chaves extras, tipos errados, JSON inválido.
Alternativa: padrão de extração esquema-primeiro, com regras de tratamento de nulos (null-handling).

Exigir raciocínio oculto ao pé da letra (hidden reasoning verbatim)

Sintoma: saídas longas demais, preocupações de privacidade/segurança, qualidade inconsistente.
Alternativa: solicitar planos, suposições e checagens; manter respostas finais concisas.

Confiar em delimitadores como fronteiras de segurança

Sintoma: injeção de prompt via texto entre aspas ainda funciona.
Alternativa: combinar elaboração defensiva de prompts com controles de sistema/ferramentas (ver Segurança de Prompts).

Quando padrões de prompt não são suficientes

Padrões de prompt melhoram a confiabilidade, mas não conseguem resolver totalmente:

  • limitações do modelo (lacunas de conhecimento, falhas de raciocínio),
  • limites de contexto (truncamento (truncation), fontes ausentes),
  • entradas adversariais (injeção de prompt),
  • veracidade (truthfulness) sem fundamentação.

Em cenários de alto risco, combine padrões com:

  • recuperação (retrieval) e citações (citations),
  • imposição de saídas estruturadas,
  • revisão humana (human review),
  • e arcabouços robustos de avaliação (eval harnesses).

Resumo

Padrões de prompt são estruturas de prompt reutilizáveis e testáveis que transformam a elaboração ad hoc de prompts em uma prática de engenharia mais sistemática. Eles funcionam porque reduzem ambiguidade, aproveitam aprendizado em contexto e fornecem contratos explícitos para entradas, restrições e formatos de saída. Os padrões mais úteis — contexto delimitado, extração estruturada, planejar-então-executar, crítica, listas de verificação e resposta fundamentada — podem ser compostos em pipelines confiáveis e avaliados ao longo do tempo.

Para próximos passos, veja: