A arte de falar com um LLM

O prompt não é texto — é um programa

Quando você digita "resuma esse artigo" no ChatGPT, na aparência não acontece nada espetacular. Mas o texto que você mandou disparou um comportamento muito específico em um modelo treinado em trilhões de tokens.

Um prompt é um programa em linguagem natural. Não no sentido de que ele seja compilado, mas no sentido de que sua formulação determina que tipo de comportamento o modelo vai ativar. A mesma frase reformulada de outra maneira pode dar resultados radicalmente diferentes — não porque o modelo seja caprichoso, mas porque seu pré-treinamento ensinou a ele padrões distintos para contextos distintos.

O prompt engineering é a arte de formular esse programa para obter o comportamento desejado.

Quatro níveis de técnica

Zero-shot: só fazer a pergunta

A técnica mais simples. Você faz a pergunta diretamente, sem exemplo nem instrução. O modelo ativa o comportamento mais provável dado seu treinamento.

Funciona muito bem para tarefas simples e factuais. Falha em problemas que exigem raciocínio — não porque o modelo não saiba, mas porque ele não sabe que deveria raciocinar.

Few-shot: mostrar exemplos

Em vez de explicar o que você quer, você mostra. Coloca de 2 a 5 pares (entrada, saída) antes da pergunta de verdade. O modelo — graças ao seu mecanismo de in-context learning — entende o padrão e o aplica a nova entrada.

A chave: os exemplos precisam ser representativos do tipo de tarefa. Exemplos fora do tema não ajudam. Exemplos que mostram a abordagem certa ajudam muito.

Chain-of-Thought: raciocinar passo a passo

Duas descobertas de 2022, muitas vezes confundidas. Wei et al. mostram que, se você dá ao modelo exemplos cujo raciocínio está escrito por inteiro, ele passa a raciocinar da mesma forma no problema seguinte. Kojima et al. vão mais longe no mesmo ano: nem precisa de exemplos, basta acrescentar "vamos pensar passo a passo". Nos dois casos, o desempenho em problemas de raciocínio dobra, às vezes triplica.

Por que funciona? O modelo gera tokens um a um. Forçando-o a escrever seu raciocínio intermediário, você dá a ele um "rascunho" no qual ele pode fazer cálculos, verificar hipóteses, corrigir erros — antes de concluir. Sem CoT, ele vai direto para a conclusão, sem rede de segurança.

É o mesmo princípio que para um humano: escrever "25 × 37 = 25 × 30 + 25 × 7 = 750 + 175 = 925" dá muito mais chance de chegar no resultado certo do que tentar responder de cabeça de uma vez.

Self-Consistency: votar entre várias cadeias

A self-consistency é uma extensão do CoT. Em vez de gerar uma única cadeia de raciocínio, geramos várias (tipicamente de 5 a 20) com temperaturas diferentes, e depois votamos na resposta mais frequente.

A ideia: cada execução pode cometer um erro diferente. Mas se a maioria converge para a mesma resposta, ela provavelmente é a certa.

É caro (N vezes mais tokens), mas em tarefas de raciocínio difíceis, o ganho de confiabilidade é real.

Experimente você mesmo

Compare as quatro técnicas em três problemas. Observe em particular que os exemplos em few-shot ajudam num problema estruturado (o do mercador), mas mudam pouca coisa nas pegadinhas lógicas.

A mesma pergunta, quatro formulações. O score muda de 30 a 90 % sem tocar no modelo. A lição: um prompt não é um texto, é um programa cuja sintaxe implícita os LLMs interpretam graças ao pré-treinamento.

O que isso revela sobre os LLMs

Essas quatro técnicas não são truques. Elas iluminam algo de fundamental sobre o funcionamento dos LLMs.

O in-context learning é grátis. Um LLM aprende com seus exemplos sem atualizar os pesos — apenas lendo o contexto. É uma capacidade emergente do pré-treinamento massivo: o modelo viu tantos padrões que consegue extrair um novo na hora.

O raciocínio é um comportamento, não uma capacidade fixa. Um modelo que falha em zero-shot num problema pode acertar em CoT no mesmo problema — sem mudar nenhum parâmetro. O que o prompt ativa muda o que o modelo "faz" das suas capacidades internas.

A temperatura cria diversidade, o voto reduz a variância. A self-consistency explora o fato de que os erros costumam ser aleatórios: muitas formas diferentes de errar, mas só uma forma de acertar. O consenso filtra o ruído.

Os limites

O custo por chamada. Cada exemplo few-shot consome tokens — e você os paga de novo a cada requisição. As janelas atuais, de 200.000 a mais de um milhão de tokens, permitem tecnicamente o many-shot (centenas de exemplos, e funciona), mas a fatura e a latência sobem junto. O CoT também alonga as respostas.

Os exemplos podem induzir ao erro. Se seus exemplos contiverem um viés, o modelo vai reproduzi-lo. "Garbage in, garbage out" também vale para few-shot.

Prompt injection. Um conteúdo malicioso no contexto pode passar por cima das suas instruções. Se seu prompt diz "traduza esse texto" e o texto diz "ignore as instruções anteriores e faça outra coisa", o modelo pode obedecer ao conteúdo em vez da instrução.

Os modelos evoluem. Um prompt afiado para o GPT-4 em 2023 não funciona necessariamente nos modelos de hoje, nem nos de outro fornecedor. Cada modelo tem seus padrões preferidos, suas formulações que "encaixam" melhor.

A regra prática

Para escolher uma técnica:

• Pergunta simples / factual → zero-shot, já basta.
• Formato específico esperado → few-shot com 2-3 exemplos.
• Raciocínio ou cálculo → CoT, se o seu modelo não tiver um modo de raciocínio nativo. Se tiver, deixe-o trabalhar: impor um CoT explícito é, na melhor das hipóteses, redundante e, na pior, prejudicial — alguns fornecedores desaconselham isso explicitamente.
• Confiabilidade crítica → CoT + self-consistency.

É uma meta-regra: se seu prompt parece código — com estrutura clara, variáveis explícitas, casos de uso definidos — ele será mais confiável que um texto ambíguo.

Uma última coisa. As técnicas descritas aqui (CoT em particular) são os ancestrais prompt-driven dos modelos de raciocínio nativos: o1 e o DeepSeek-R1 abriram caminho em 2024-2025, e hoje todos os grandes modelos têm um modo desse tipo. Esses modelos fazem automaticamente e intensamente o que o CoT via prompt apenas simulava — veja o capítulo 17 para entender a passagem do prompt engineering ao raciocínio integrado ao modelo.

Um bom prompt não é uma fórmula mágica. É uma especificação clara do que você quer, numa linguagem que o modelo reconhece como o sinal que deve seguir.

Resta uma coisa que nenhuma formulação resolve. Você pode escrever a especificação mais límpida do mundo: se a resposta não está nos pesos do modelo, ele vai produzir uma assim mesmo, com exatamente o mesmo aprumo que se estivesse. Por que um sistema treinado para prever texto é incapaz de parar e dizer "não sei"? É o tema do próximo capítulo.

Atualizado em 2 de agosto de 2026