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 | Técnica | Problema que resolve | Custo de contexto | |---|---|---| | Zero-shot | Pedir uma tarefa sem exemplo, contando com o conhecimento pré-treinado | Mínimo | | Few-shot | Ensinar o formato ou o padrão esperado via exemplos no próprio prompt | Baixo a médio | | Chain-of-Thought (CoT) | Melhorar raciocínio em tarefas de múltiplos passos (matemática, lógica) | Médio | | Self-consistency | Reduzir erro de raciocínio validando múltiplos caminhos de resposta | Alto (múltiplas chamadas) | | RAG | Responder com base em dados atuais ou privados que o modelo não viu no treino | Médio a alto (busca + contexto) | | ART (Automatic Reasoning and Tool-use) | Resolver tarefas que exigem cálculo exato, dados externos ou ações no mundo real | Alto (orquestração de ferramentas) | 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 - Indexação: documentos são divididos em pedaços (chunks) e convertidos em embeddings (vetores numéricos), armazenados em um banco vetorial - Busca (retrieval): a pergunta do usuário também vira um embedding, e o sistema busca os chunks mais similares semanticamente - Aumento (augmentation): os chunks recuperados são inseridos no prompt, junto com a pergunta original - 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çã