Chain-of-Thought Prompting Explicado (Com Exemplos)
Peça ao modelo para pensar passo a passo e ele acerta problemas de várias etapas com muito mais frequência. Veja como o chain-of-thought funciona e como usá-lo bem.
Peça a um modelo de linguagem para multiplicar dois números de três dígitos e cuspir a resposta, e ele vai tropeçar com frequência. Peça ao mesmo modelo para resolver a multiplicação uma casa por vez, e a precisão dispara. Essa diferença é a ideia inteira por trás do chain-of-thought prompting: dar ao modelo espaço para raciocinar antes de se comprometer com uma resposta final. Quando um problema tem partes móveis que dependem umas das outras, o raciocínio não é enfeite. É o que te leva ao resultado certo.
Este artigo percorre as principais variações da técnica, mostra onde cada uma compensa e aponta as situações em que as etapas de raciocínio só desperdiçam tokens. Se você ainda está construindo sua base, o guia de fundamentos é uma boa leitura complementar.
Por que o raciocínio em etapas muda a saída
Um modelo gera texto um token por vez, e cada token que ele produz vira parte do contexto do próximo. Quando você força uma resposta direta, comprime um problema de várias etapas em um único salto. O modelo não tem espaço de rascunho, então faz correspondência de padrão em direção a algo que pareça plausível e frequentemente aterrissa perto da resposta, não nela.
As etapas de raciocínio mudam o formato dessa geração. Cada conclusão intermediária que o modelo anota vira um fato em que ele pode se apoiar na etapa seguinte. Um problema difícil vira uma cadeia de problemas mais fáceis, e o modelo só precisa estar localmente correto em cada elo, em vez de globalmente correto em um único lance.
Isso ajuda mais em tarefas com estas características:
- Aritmética e problemas de enunciado em que um erro em uma operação se propaga
- Quebra-cabeças de lógica com restrições que interagem
- Perguntas de múltiplos saltos que exigem encadear vários fatos
- Tarefas de planejamento em que ordem e dependências importam
Zero-Shot: o gatilho de uma linha
A versão mais leve te custa uma única frase. Você acrescenta uma instrução que empurra o modelo para um modo de raciocínio antes de responder. A redação exata importa menos que a intenção, então trate isso como uma alavanca que você pode reformular para o seu domínio.
O modelo geralmente vai estabelecer o preço por grupo, contar quantos grupos há em 21 canetas, calcular o custo total e então subtrair de 20. Compare isso com uma pergunta seca, em que ele poderia agarrar os números 21 e 20 e produzir algo confiantemente errado.
Você também pode direcionar o raciocínio. Em vez de um gatilho genérico, diga ao modelo *como* pensar: "Primeiro liste as restrições, depois elimine as opções que as violam, depois escolha o que sobrar". Uma estrutura específica do domínio costuma ganhar de uma instrução única para tudo.
Few-Shot: ensinando pelo exemplo resolvido
O zero-shot se apoia nos próprios hábitos do modelo. O few-shot mostra ao modelo exatamente como é um bom raciocínio, incluindo um ou mais exemplos resolvidos, completos com suas etapas intermediárias. O modelo imita o padrão das demonstrações, não só as respostas delas.
Como o exemplo resolvido detalha suas etapas, o modelo continua na mesma voz: ele vai nomear os dias de leitura, contar quantos caem em 21 dias e multiplicar. A demonstração faz dupla função, mostrando tanto o formato da resposta quanto o nível de detalhe do raciocínio que você espera. Se você quer uma comparação mais a fundo dos dois estilos e de quando cada um ganha, veja few-shot vs zero-shot.
Mantenha seus exemplos próximos da tarefa real. Um modelo que viu raciocínio de geometria não vai transferir essa disciplina automaticamente para um problema de agendamento, então combine o domínio das suas demonstrações com o domínio da sua consulta.
Decomposição: quebre a tarefa em partes
Às vezes a jogada mais esperta é parar de tratar o problema como um único prompt. A decomposição divide um pedido complexo em subtarefas nomeadas, cada uma das quais você pode resolver e verificar por conta própria. Você ou pede ao modelo para listar os subproblemas primeiro, ou conduz cada um você mesmo em chamadas separadas.
Um resumo de pesquisa, por exemplo, se decompõe de forma limpa:
- Extraia as afirmações-chave da fonte
- Confira cada afirmação contra o texto de apoio
- Agrupe afirmações relacionadas em temas
- Escreva o resumo a partir dos temas verificados
Resolver cada etapa isoladamente te dá pontos de inspeção. Se o resumo está errado, você consegue ver se a extração ou o agrupamento falhou, em vez de encarar um único bloco opaco de saída. Essa abordagem estruturada é um tema central na engenharia de prompt avançada, onde encadeamento e decomposição muitas vezes pesam mais do que prompts únicos espertos.
Autoconsistência e a checagem final
Uma única cadeia de raciocínio pode sair dos trilhos e ainda soar confiante. Duas técnicas se protegem contra isso.
A autoconsistência amostra várias cadeias independentes para a mesma pergunta, cada uma com um pouco de aleatoriedade, e depois pega a resposta majoritária. Se oito de dez caminhos de raciocínio chegam a 42, você confia em 42 muito mais do que em qualquer tentativa isolada. Custa mais chamadas, então reserve para perguntas em que uma resposta errada sai caro.
A autoverificação pede ao modelo que audite o próprio trabalho antes de finalizar. Uma instrução de fechamento faz muita diferença aqui:
Essa última instrução transforma a própria saída do modelo em algo que ele revisa, e não apenas algo que ele produz. Ela pega um número surpreendente de escorregões, especialmente erros de aritmética e de contagem em problemas de tempo ou de quantidade. Um construtor dedicado, como a ferramenta de prompt chain-of-thought, pode gerar essa estrutura de raciocínio-mais-verificação para você, e o otimizador de prompts ajuda a apertar a redação depois que você tem um rascunho.
Quando pular isso
Etapas de raciocínio têm um custo. Elas gastam tokens, adicionam latência e, na tarefa errada, podem até atrapalhar, inventando justificativa para um fato que o modelo já sabia com clareza. Pule o chain-of-thought explícito quando:
- A tarefa é uma consulta direta ou um único fato ("Qual é a capital do Peru?")
- Você precisa de um rótulo de classificação curto sem ambiguidade
- A saída é criativa e não tem resposta certa para verificar
- A latência importa mais do que os últimos pontinhos de precisão
Forçar "vamos pensar passo a passo" em uma recuperação simples só enche linguiça na resposta e, de vez em quando, convence o modelo a abandonar uma resposta instantânea que estava correta.
Modelos de raciocínio mudam o equilíbrio
Os modelos de raciocínio mais novos lidam com boa parte disso internamente. Eles geram uma passada de deliberação oculta antes de responder, então grudar um "pense passo a passo" genérico neles acrescenta pouco. O raciocínio já está acontecendo onde você não pode ver.
O que ainda compensa é estrutura e verificação. Dizer ao modelo *quais* dimensões considerar, em que ordem, e pedir que ele rode uma checagem final te dá alavancagem mesmo quando o raciocínio interno é forte:
- Especifique os critérios que a resposta deve satisfazer
- Peça a resposta em um formato verificável (um número, uma tabela, uma decisão rotulada)
- Solicite uma passada de verificação curta contra os critérios que você declarou
Você não está mais ensinando o modelo a raciocinar. Você está mirando o raciocínio dele no seu problema e se dando um jeito de confirmar o resultado. Esse enquadramento mantém o chain-of-thought útil muito depois de o truque cru de "pense passo a passo" parar de mover o ponteiro.
