Engenharia de Prompts: de Zero-shot a Retrieval Augmented Generation

A mesma pergunta feita a um modelo de linguagem pode gerar uma resposta genérica, uma resposta certeira ou uma resposta completamente errada — e a diferença, na maioria das vezes, não está no modelo, está em como o prompt foi construído. Engenharia de Prompts é a disciplina de projetar a entrada de um LLM (instruções, exemplos, contexto, formato esperado) para extrair o resultado mais útil e confiável possível, sem alterar um único parâmetro do modelo.

O campo evoluiu rápido: começou com instruções diretas (zero-shot), passou a usar exemplos dentro do próprio prompt (few-shot), aprendeu a forçar o modelo a "pensar em voz alta" (Chain-of-Thought), depois a validar esse raciocínio com múltiplas tentativas (self-consistency), e hoje inclui técnicas que conectam o LLM a fontes de dados externas (RAG) e a ferramentas que ele mesmo decide usar (ART). Este artigo percorre essas seis técnicas, na ordem em que resolvem problemas cada vez mais complexos, com exemplos práticos de cada uma.

Visão geral rápida

Cada técnica resolve uma limitação específica da anterior. Vale seguir essa ordem para entender por que elas existem.

Zero-shot: pedir direto, sem exemplo

Zero-shot é o uso mais simples de um LLM: você descreve a tarefa e pede a resposta, sem fornecer nenhum exemplo de como fazê-la. Funciona porque o modelo já viu, durante o treinamento, bilhões de instâncias de tarefas parecidas e generaliza a partir da instrução.

Classifique o sentimento do texto abaixo como positivo, negativo ou neutro.

Texto: "O atendimento demorou, mas o produto chegou em perfeito estado."
Sentimento:

Quando usar

• Tarefas simples e bem conhecidas (classificação, tradução, resumo)
• Quando não há exemplos rotulados disponíveis
• Como primeira tentativa antes de complicar o prompt

Limitação

Zero-shot falha quando a tarefa é ambígua, exige um formato de saída muito específico, ou foge do padrão mais comum visto no treinamento. É aí que entra o few-shot.

Few-shot: ensinar pelo exemplo

Few-shot adiciona alguns exemplos completos (entrada → saída esperada) dentro do próprio prompt, antes de fazer o pedido real. O modelo não é retreinado — ele apenas usa esses exemplos como referência de padrão e formato para a resposta seguinte, dentro da mesma janela de contexto.

Classifique o sentimento como positivo, negativo ou neutro.

Texto: "Chegou antes do prazo e superou minhas expectativas."
Sentimento: positivo

Texto: "Cancelei a compra, o suporte nunca respondeu."
Sentimento: negativo

Texto: "O produto é ok, nada excepcional."
Sentimento: neutro

Texto: "O atendimento demorou, mas o produto chegou em perfeito estado."
Sentimento:

Por que funciona

Isso é chamado de in-context learning: o modelo não atualiza seus pesos, mas usa os exemplos no prompt para inferir o padrão esperado — algo como calibrar o formato e o critério de decisão só para aquela chamada.

Quando usar

• A tarefa exige um formato de saída específico (JSON, categorias customizadas, tom de escrita)
• O critério de classificação é sutil e difícil de descrever só com texto
• Poucos exemplos (2 a 8, tipicamente) já bastam — few-shot não é fine-tuning

Limitação

Few-shot melhora o padrão da resposta, mas não ajuda muito quando a tarefa exige raciocínio em várias etapas — por exemplo, um problema de matemática com múltiplos passos. Mostrar exemplos de resposta final não ensina o modelo a chegar lá.

Chain-of-Thought (CoT): forçar o raciocínio explícito

Chain-of-Thought pede (ou exemplifica) que o modelo exponha o raciocínio passo a passo antes de dar a resposta final, em vez de pular direto para a conclusão. A técnica foi descrita formalmente em 2022 (Wei et al., Google) e mostrou ganhos expressivos em tarefas de matemática, lógica e raciocínio de múltiplos passos.

Zero-shot CoT

A versão mais simples nem precisa de exemplo — basta adicionar uma instrução como "pense passo a passo":

Uma loja tinha 23 maçãs. Vendeu 8 pela manhã e recebeu mais 15 à tarde.
Quantas maçãs tem agora? Pense passo a passo antes de responder.

Passo 1: começou com 23 maçãs.
Passo 2: vendeu 8, restam 23 - 8 = 15.
Passo 3: recebeu mais 15, total 15 + 15 = 30.
Resposta: 30 maçãs.

Few-shot CoT

Combina CoT com exemplos, mostrando o raciocínio completo em cada exemplo do prompt — não só a resposta final:

Pergunta: João tinha 5 laranjas, comprou mais 3 caixas com 4 laranjas cada. Quantas tem no total?
Raciocínio: João começou com 5 laranjas. Cada caixa tem 4, e são 3 caixas, então 3 x 4 = 12.
No total: 5 + 12 = 17.
Resposta: 17

Pergunta: Uma van leva 12 passageiros por viagem e fez 4 viagens. Quantos passageiros no total?
Raciocínio:

Por que funciona

Modelos de linguagem geram a resposta token a token, prevendo o próximo com base em tudo o que já foi escrito — inclusive pelo próprio modelo na mesma resposta. Ao forçar o raciocínio intermediário a aparecer no texto, cada passo correto vira contexto para o próximo, reduzindo a chance de o modelo "pular" direto para uma conclusão errada.

Quando usar

• Problemas de matemática, lógica ou múltiplas etapas
• Tarefas onde a explicação do raciocínio também tem valor (auditoria, depuração)
• Modelos maiores se beneficiam mais de CoT do que modelos pequenos — é um efeito que só aparece de forma consistente a partir de certa escala

Self-consistency: validar o raciocínio com múltiplas tentativas

Mesmo com CoT, um LLM pode seguir um caminho de raciocínio plausível, mas errado, e chegar a uma resposta incorreta com total confiança. Self-consistency ataca esse problema gerando várias cadeias de raciocínio independentes para a mesma pergunta (com temperatura de amostragem maior que zero, para variar o caminho) e escolhendo a resposta final mais frequente entre elas — uma espécie de votação por maioria.

respostas = []
for _ in range(5):
    resposta = llm.gerar(
        prompt="Pense passo a passo: " + pergunta,
        temperature=0.7,  # cada chamada explora um caminho de raciocínio diferente
    )
    respostas.append(extrair_resposta_final(resposta))

resposta_final = max(set(respostas), key=respostas.count)

Por que funciona

Erros de raciocínio de um LLM tendem a ser inconsistentes entre execuções — cada tentativa erra de um jeito diferente — enquanto o raciocínio correto costuma convergir para a mesma resposta repetidamente. Ao amostrar vários caminhos e ficar com o mais comum, o ruído de tentativas individuais se cancela.

Quando usar

• Tarefas de alto risco onde o custo de uma resposta errada supera o custo de múltiplas chamadas ao modelo
• Problemas com resposta final verificável e curta (número, categoria, "sim/não") — mais fácil de votar entre respostas
• Não compensa para geração de texto livre (não há "resposta majoritária" clara em um parágrafo criativo)

Limitação

CoT e self-consistency melhoram o raciocínio, mas não resolvem um problema diferente: o modelo só conhece o que estava no seu conjunto de treinamento, com data de corte. Ele não sabe o preço de uma ação hoje, não conhece um documento interno da sua empresa, e não consegue fazer uma conta muito grande com precisão garantida. Para isso, entra RAG.

Retrieval Augmented Generation (RAG): trazer conhecimento externo

RAG combina um sistema de busca (retrieval) com a geração do LLM: antes de responder, o sistema busca trechos relevantes em uma base de dados externa — documentos internos, base de conhecimento, resultados de busca — e injeta esses trechos no prompt como contexto adicional. O modelo responde com base no que foi recuperado, não só no que aprendeu durante o treinamento.

Como funciona, na prática

1. Indexação: documentos são divididos em pedaços (chunks) e convertidos em embeddings (vetores numéricos), armazenados em um banco vetorial
2. Busca (retrieval): a pergunta do usuário também vira um embedding, e o sistema busca os chunks mais similares semanticamente
3. Aumento (augmentation): os chunks recuperados são inseridos no prompt, junto com a pergunta original
4. Geração: o LLM responde usando o contexto recuperado como fonte, idealmente citando de onde veio a informação

pergunta = "Qual a política de reembolso para pedidos cancelados?"

# 1 e 2: busca semântica na base de conhecimento interna
trechos = base_vetorial.buscar(pergunta, top_k=3)

# 3: monta o prompt aumentado com o contexto recuperado
contexto = "\n---\n".join(trechos)
prompt = f"""Responda a pergunta usando apenas o contexto abaixo.
Se a resposta não estiver no contexto, diga que não sabe.

Contexto:
{contexto}

Pergunta: {pergunta}
"""

# 4: geração com base no contexto
resposta = llm.gerar(prompt)

Por que funciona

RAG separa duas responsabilidades que antes ficavam misturadas: conhecimento (o que é verdade, e está atualizado) fica na base de dados, que pode ser atualizada a qualquer momento sem retreinar nada; linguagem (como formular uma resposta coerente) fica a cargo do LLM. Isso reduz alucinação — o modelo tem menos motivo para "inventar" uma resposta quando o fato relevante já está no prompt — e permite responder sobre dados privados ou recentes que nunca estiveram no treinamento do modelo.

Quando usar

• Perguntas sobre documentação interna, políticas da empresa, base de conhecimento proprietária
• Informação que muda com frequência (preços, estoque, notícias) e não pode depender da data de corte do modelo
• Redução de alucinação em domínios onde precisão factual importa mais que fluência

Automatic Reasoning and Tool-use (ART): o modelo decide quando agir

ART vai um passo além do RAG: em vez de só recuperar texto, o modelo aprende a decidir, durante o próprio raciocínio, quando invocar uma ferramenta externa — uma calculadora, uma API, um interpretador de código, uma busca na web — e como incorporar o resultado dessa ferramenta de volta no raciocínio antes de continuar. A técnica foi formalizada em um artigo de 2023 (Paranjape et al., Microsoft Research), mas o padrão geral hoje é conhecido de forma mais ampla como tool use ou function calling.

Como funciona, na prática

O modelo recebe uma descrição das ferramentas disponíveis (nome, parâmetros, o que cada uma faz) junto com o prompt. Durante a geração, ao perceber que precisa de um dado que não tem ou de um cálculo que não confia em fazer de memória, ele gera uma chamada estruturada para a ferramenta certa, o sistema executa essa chamada de verdade, e o resultado volta para o modelo continuar o raciocínio.

ferramentas = [
    {
        "nome": "calculadora",
        "descricao": "Avalia uma expressão matemática e retorna o resultado exato",
        "parametros": {"expressao": "string"},
    },
    {
        "nome": "buscar_cotacao",
        "descricao": "Retorna a cotação atual de uma moeda ou ação",
        "parametros": {"ticker": "string"},
    },
]

resposta = llm.gerar(
    prompt="Se eu converter 1.500 dólares para reais na cotação de hoje, "
           "e depois investir 20% desse valor a 0,9% ao mês, quanto rende em 6 meses?",
    tools=ferramentas,
)

# O modelo decide, na ordem certa:
# 1. chamar buscar_cotacao("USD/BRL") -> obtém a cotação real, não estimada
# 2. chamar calculadora("1500 * cotacao") -> converte com precisão exata
# 3. chamar calculadora("(valor * 0.2) * (1.009**6 - 1)") -> calcula o rendimento
# 4. gerar a resposta final combinando os resultados reais das três chamadas

Por que funciona

Um LLM é excelente em linguagem e péssimo em coisas que exigem precisão determinística ou dados em tempo real — contas grandes, cotações, resultado de uma consulta em banco de dados. ART reconhece essa divisão de trabalho: deixa o raciocínio e a orquestração com o modelo, e delega a execução exata para ferramentas especializadas, incorporando o resultado de volta no fluxo de raciocínio antes de gerar a resposta final.

Quando usar

• Tarefas que envolvem cálculo exato, conversão de unidade ou operação matemática não trivial
• Necessidade de dado em tempo real (cotação, clima, status de um pedido)
• Ações no mundo real além de gerar texto (agendar, criar um registro, disparar um webhook) — a base de qualquer agente de LLM

Como as técnicas se relacionam

Um assistente de produção raramente usa só uma técnica isolada — combina várias: few-shot para fixar o formato de saída, CoT quando a pergunta exige raciocínio, RAG para trazer contexto factual atualizado, e tool-use para qualquer cálculo ou ação que precise de precisão real. É essa combinação, não uma técnica única, que separa um protótipo de demonstração de um sistema confiável em produção.

Boas práticas

• Comece sempre pelo zero-shot — só adicione complexidade (exemplos, CoT, RAG) quando o resultado simples não for suficiente; prompt mais longo custa mais tokens e nem sempre melhora a resposta
• Em few-shot, escolha exemplos representativos e diversos — poucos exemplos muito parecidos entre si enviesam o modelo para casos específicos e prejudicam a generalização
• Peça o raciocínio, mas isole a resposta final — em CoT, estruture o prompt para o modelo terminar com um marcador claro (Resposta final:), facilitando extrair só o resultado por código
• Não use self-consistency para tudo — o custo de múltiplas chamadas só compensa quando o erro de uma resposta é caro; para tarefas simples é desperdício
• Em RAG, cite a fonte e permita "não sei" — instrua o modelo a admitir quando o contexto recuperado não contém a resposta, em vez de completar com suposição
• Em tool-use, valide a chamada antes de executar — principalmente para ferramentas que alteram estado (criar, deletar, enviar); nunca execute uma ação irreversível só porque o modelo pediu

Perguntas frequentes

Conclusão

Engenharia de prompts não é sobre encontrar "a frase mágica" — é sobre entender qual limitação do modelo está impedindo a resposta certa e escolher a técnica que resolve exatamente essa limitação. Zero-shot e few-shot ajustam o formato e o padrão de saída. Chain-of-Thought e self-consistency melhoram o raciocínio e sua confiabilidade. RAG resolve a falta de conhecimento atualizado ou privado. E ART/tool-use resolve o que nenhuma técnica de prompt sozinha resolve: precisão exata e ação real no mundo, fora do que o modelo consegue gerar apenas em texto.

Na prática, o prompt mais eficaz quase sempre combina mais de uma dessas técnicas — e a habilidade real de quem projeta prompts está em reconhecer, tarefa por tarefa, qual combinação delas resolve o problema com o menor custo possível.

Referências

• Chain-of-Thought Prompting Elicits Reasoning in Large Language Models (Wei et al., 2022)
• Self-Consistency Improves Chain of Thought Reasoning (Wang et al., 2022)
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al., 2020)
• ART: Automatic multi-step Reasoning and Tool-use for Large Language Models (Paranjape et al., 2023)
• OpenAI Prompt Engineering Guide