Chain-of-Thought: fazendo a IA pensar passo a passo

Quando você pede a um modelo de linguagem para resolver um problema de matemática ou uma lógica de várias etapas, é comum receber uma resposta errada dita com total confiança. A técnica de Chain-of-Thought (CoT), ou "cadeia de pensamento", muda isso ao instruir o modelo a expor o raciocínio passo a passo antes de concluir. Neste artigo você vai entender por que isso funciona, como aplicar na prática, quando vale a pena e quando, na verdade, atrapalha.

O que é Chain-of-Thought

Chain-of-Thought é uma técnica de prompting em que você incentiva o modelo a gerar uma sequência de passos intermediários de raciocínio antes de dar a resposta final. Em vez de pular direto para o resultado, o modelo "pensa em voz alta", decompondo o problema em partes menores.

A ideia foi formalizada por Wei e colegas (2022), que mostraram que simplesmente fornecer exemplos com raciocínio explícito faz modelos grandes resolverem tarefas que antes erravam de forma sistemática. O ganho aparece principalmente em problemas de aritmética, raciocínio simbólico e bom senso (commonsense).

Para entender por que isso é relevante, vale lembrar como esses sistemas funcionam por dentro. Se você ainda tem dúvidas sobre os fundamentos, comece por O que é um LLM (Large Language Model)?, porque o CoT explora justamente a forma como o modelo gera texto token a token.

Uma analogia simples

Imagine pedir a alguém para multiplicar 47 por 89 de cabeça e responder imediatamente. A chance de erro é alta. Agora dê papel e caneta: a pessoa quebra a conta em passos (47 × 80, 47 × 9, soma) e acerta com facilidade. O Chain-of-Thought é o papel e a caneta do modelo: ele transforma uma resposta "de cabeça" em um cálculo desenvolvido, com cada etapa visível e verificável.

Por que pular etapas leva a erros

Um LLM gera a resposta prevendo o próximo token com base nos anteriores. Quando você pede só o resultado final de um problema complexo, o modelo precisa "comprimir" todo o raciocínio em uma única passagem de geração, sem espaço para desenvolver os passos.

Isso causa dois problemas:

Ao escrever o raciocínio, o modelo aloca mais tokens — e, portanto, mais computação — ao problema, e cada passo serve de contexto para o seguinte.

Tokens como "tempo de pensar"

Vale aprofundar a primeira razão, porque ela é contraintuitiva. Um Transformer faz uma quantidade fixa de computação por token gerado. Se a resposta sai em um único token ("30"), todo o raciocínio teve de caber naquele único passo de processamento. Ao gerar uma cadeia de raciocínio, o modelo cria uma sequência de tokens intermediários, e cada um deles carrega mais um "ciclo" de computação. Em outras palavras, escrever o raciocínio dá ao modelo literalmente mais tempo de processamento para chegar à resposta. Não é o texto em si que importa, e sim a computação extra que ele viabiliza.

Por que os erros ficam auditáveis

O segundo benefício é tão valioso quanto o primeiro, mas costuma ser subestimado: a auditabilidade. Quando o modelo só devolve "30", você não tem como saber se ele somou certo ou chegou ao número por sorte. Quando ele mostra "23 − 8 = 15; 15 + 15 = 30", qualquer pessoa — ou outro programa — consegue conferir cada passo e localizar exatamente onde um eventual erro entrou. Em aplicações sérias, essa rastreabilidade é o que permite confiar (com verificação) na saída do modelo, em vez de aceitá-la às cegas. É também o que torna possível construir verificadores automáticos que checam a coerência da cadeia.

Como aplicar na prática

A forma mais simples de ativar o Chain-of-Thought é incluir uma instrução explícita no prompt. A expressão clássica do paper de Wei e colegas (2022) é "vamos pensar passo a passo".

Pergunta: 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.

Com essa instrução, em vez de só "30", o modelo tende a produzir algo como:

Passo 1: A loja começou com 23 maçãs.
Passo 2: Vendeu 8 -> 23 - 8 = 15.
Passo 3: Recebeu 15 -> 15 + 15 = 30.
Resposta: 30 maçãs.

Esse hábito de ser explícito sobre o que você quer é o coração de todo bom prompt. Vale revisar Prompt engineering para código: como pedir o que você precisa, porque as mesmas regras de clareza valem para CoT.

Estruturando a saída para uso programático

Em aplicações reais, você quase sempre precisa extrair a resposta final do meio do raciocínio. Para isso, peça um formato delimitado e previsível:

Resolva o problema abaixo.

Primeiro, escreva seu raciocínio sob o título "Raciocínio:".
Depois, em uma linha separada, escreva apenas a resposta final
sob o título "Resposta:".

Problema: {problema}

Com um separador claro como Resposta:, seu código pode cortar a string nesse marcador e capturar só o resultado, descartando o raciocínio (ou guardando-o em log para auditoria). Sem essa estrutura, você acaba escrevendo parsers frágeis que quebram quando o modelo varia o formato.

Zero-shot vs. few-shot CoT

Existem duas formas principais de eliciar a cadeia de pensamento:

O few-shot costuma dar resultados mais consistentes em tarefas difíceis, porque o modelo imita a estrutura dos exemplos. O zero-shot é mais barato e rápido de escrever, ideal para prototipagem.

Exemplo:
Pergunta: Tenho 3 caixas com 4 ovos cada. Quantos ovos no total?
Raciocínio: 3 caixas x 4 ovos = 12 ovos.
Resposta: 12.

Agora resolva:
Pergunta: Tenho 5 sacolas com 6 laranjas cada. Quantas laranjas?
Raciocínio:

Quando escolher cada um

Use zero-shot CoT quando: você está prototipando, o orçamento de tokens é apertado, ou a tarefa é razoavelmente simples e só precisa de um empurrão para o modelo não pular etapas.

Prefira few-shot CoT quando: a tarefa tem um formato de raciocínio específico que você quer ensinar (por exemplo, um método de cálculo da sua empresa), os resultados zero-shot estão inconsistentes, ou você precisa que a saída siga uma estrutura rígida. O custo é maior — cada exemplo ocupa espaço no contexto e em cada chamada —, mas a consistência compensa em tarefas críticas. A qualidade dos exemplos importa mais que a quantidade: dois ou três exemplos bem escolhidos costumam bastar.

Onde o CoT brilha (e onde não ajuda)

O Chain-of-Thought traz ganho real quando a tarefa exige múltiplas etapas de inferência:

Por outro lado, em tarefas triviais o CoT pode ser contraproducente: adiciona latência, consome tokens e às vezes introduz divagações. Pedir raciocínio passo a passo para "qual a capital da França?" só desperdiça recurso. A regra prática: use CoT quando a resposta exigir mais de um salto de raciocínio.

O custo escondido: latência e tokens

Vale quantificar o trade-off. Uma resposta com CoT pode gerar de 5 a 20 vezes mais tokens que a resposta direta. Isso impacta três coisas: o custo (você paga por tokens gerados), a latência (mais tokens demoram mais para sair) e, em produtos com streaming, a experiência do usuário, que espera mais para ver a conclusão. Por isso muitas aplicações escondem o raciocínio do usuário final e mostram só a resposta — preservando o ganho de qualidade sem expor a "lentidão" do pensamento.

CoT e a engenharia de contexto

O Chain-of-Thought não vive isolado. Ele é uma peça dentro de um conjunto maior de decisões sobre o que entra na janela de contexto do modelo: instruções, exemplos, dados recuperados e o próprio histórico do raciocínio.

Essa visão mais ampla é tratada em Engenharia de contexto: o novo prompt engineering, que mostra como organizar tudo o que o modelo "vê". Pensar no CoT como parte do contexto ajuda a decidir quanto espaço dedicar ao raciocínio versus a outras informações.

Uma técnica complementar é a self-consistency: você gera várias cadeias de raciocínio diferentes para a mesma pergunta e escolhe a resposta mais frequente. Isso reduz o impacto de um caminho de raciocínio que deu errado.

Self-consistency em detalhe

A self-consistency, proposta por Wang e colegas (2023), parte de uma observação simples: para um problema com resposta única, existem muitos caminhos de raciocínio válidos que levam a ela, mas os caminhos errados tendem a errar de formas diferentes entre si. Então, se você gerar, digamos, dez cadeias de raciocínio com temperatura alta (para introduzir variação) e fizer uma "votação" sobre a resposta final, a resposta correta tende a ser a mais votada.

1. Gere 10 respostas com CoT, usando temperature ~0.7.
2. Extraia a resposta final de cada uma.
3. Conte a frequência de cada resposta.
4. Devolva a resposta mais frequente (voto majoritário).

O custo é dez vezes maior, então a self-consistency se justifica em tarefas de alto valor onde o erro sai caro — não no fluxo cotidiano. É um exemplo clássico de trocar computação por confiabilidade.

Do raciocínio à ação: o caminho para agentes

O CoT trata de raciocinar, mas modelos modernos também precisam agir — consultar uma API, rodar uma busca, ler um arquivo. É aí que entra uma evolução natural da ideia.

O trabalho de Yao e colegas (2023) propôs o padrão ReAct, que intercala passos de raciocínio (reasoning) com passos de ação (acting). Em vez de só pensar, o modelo decide pensar, executar uma ferramenta, observar o resultado e pensar de novo. Esse ciclo é a base de boa parte dos agentes atuais, e você encontra a explicação detalhada em O padrão ReAct: raciocínio e ação em agentes de IA.

A ligação é direta: o Chain-of-Thought é o "R" do ReAct. Dominar a cadeia de pensamento é pré-requisito para construir agentes que tomam decisões confiáveis.

CoT e os modelos de raciocínio

Vale notar uma evolução recente. Uma geração de modelos passou a ser treinada especificamente para raciocinar antes de responder, produzindo internamente uma longa cadeia de pensamento sem que você precise pedir. Nesses modelos, o CoT deixa de ser uma técnica de prompt e vira um comportamento embutido. Mesmo assim, entender o princípio continua essencial: ajuda a saber quando um problema se beneficia de raciocínio explícito, como estruturar a tarefa para facilitá-lo e como interpretar o que o modelo produz.

Variações e técnicas relacionadas

O Chain-of-Thought abriu uma família de técnicas que valem o seu conhecimento, porque cada uma resolve uma limitação específica:

Não é preciso dominar todas de uma vez. O importante é entender o princípio comum: dar ao modelo mais estrutura e mais computação para problemas que não cabem em uma única passagem de geração.

Um exemplo prático de aplicação real

Suponha um classificador de tickets de suporte que precisa decidir a prioridade de um chamado. Sem CoT, o modelo "chuta" um rótulo. Com CoT estruturado, a decisão fica auditável:

Classifique a prioridade do ticket abaixo (baixa, média, alta, crítica).

Raciocine assim, em ordem:
1. Há perda de dados ou indisponibilidade total? (se sim → crítica)
2. Quantos usuários são afetados?
3. Existe contorno (workaround) disponível?
4. Conclua a prioridade com base nos itens acima.

Ticket: "O login está fora para todos os clientes desde as 9h."

Raciocínio:

Repare que o prompt impõe a estrutura do raciocínio. Isso reduz a variância das decisões e gera um rastro que um humano pode revisar — valioso quando a classificação tem consequências reais.

Depurando um CoT que falha

Nem sempre o Chain-of-Thought resolve de primeira. Quando o modelo continua errando mesmo com raciocínio explícito, vale diagnosticar onde a cadeia quebra:

A lição é tratar o prompt como código: observe o comportamento, forme uma hipótese sobre a causa, faça uma mudança por vez e meça o efeito.

Boas práticas ao usar Chain-of-Thought

Para extrair o máximo da técnica sem cair em armadilhas:

Perguntas frequentes

CoT garante respostas corretas? Não. Ele aumenta significativamente a taxa de acerto em tarefas de múltiplas etapas, mas o modelo ainda pode errar — e às vezes apresenta um raciocínio coerente que leva a uma conclusão errada. Trate o CoT como uma melhoria estatística, não uma garantia.

Posso usar CoT com qualquer modelo? O benefício foi observado principalmente em modelos grandes. Em modelos pequenos, pedir raciocínio passo a passo pode ajudar pouco ou até atrapalhar, pois eles têm menos capacidade de manter coerência ao longo da cadeia.

CoT aumenta o custo? Sim, porque gera muito mais tokens. Avalie se o ganho de qualidade compensa o custo e a latência extras no seu caso específico.

Qual a diferença entre CoT e self-consistency? CoT gera uma única cadeia de raciocínio. Self-consistency gera várias cadeias e escolhe a resposta mais frequente, trocando mais computação por mais confiabilidade.

Conclusão

Chain-of-Thought é uma das técnicas mais simples e eficazes de prompting: ao pedir que o modelo exponha o raciocínio passo a passo, você dá a ele mais espaço de computação e torna os erros visíveis e auditáveis. Funciona especialmente bem em tarefas de várias etapas, pode ser aplicado em modo zero-shot ou few-shot e serve de base para padrões mais avançados como ReAct e self-consistency. Use com critério: reserve o raciocínio explícito para problemas que realmente exigem múltiplos saltos de inferência, estruture a saída para extração fácil, fique atento ao custo em tokens e meça o ganho no seu contexto antes de adotá-lo em todo lugar.

Referências