Prompting com chain-of-thought: quando funciona e quando só queima tokens

Chain-of-thought (CoT) virou o padrão ouro para quem quer melhores resultados com IA. "Só peça para pensar passo a passo" é praticamente um meme nessa altura do campeonato. Mas tem uma verdade incômoda: nem sempre funciona, e às vezes piora as coisas.

Depois de trabalhar bastante com Claude, percebi padrões bem claros sobre quando o CoT vale a pena e quando é só desperdício caro. Vamos separar o joio do trigo.

A Mecânica Real por Trás do Chain-of-Thought

Primeiro, entenda o que está acontecendo de verdade. Quando você pede pro Claude "pensar passo a passo" ou "mostrar seu raciocínio", você está fazendo duas coisas:

1. Criando saídas intermediárias que o Claude gera explicitamente
2. Restringindo o processo de raciocínio para seguir um caminho mais linear e verificável

Para problemas complexos—matemática, lógica, planejamento multi-etapas—essa restrição é genuinamente útil. Força o Claude a quebrar problemas ambíguos em passos discretos, o que reduz alucinações e atalhos lógicos.

Para tarefas simples? Você está só vendo o Claude narrar algo que ele conseguiria descobrir em silêncio. Todos esses passos intermediários consomem tokens. E tokens custam dinheiro.

Quando o Chain-of-Thought Realmente Funciona

Quebra-cabeças de lógica e raciocínio matemático. Esse é o habitat natural do CoT. Se você está pedindo pro Claude resolver um sistema de equações ou trabalhar em um problema de detetive, raciocínio explícito quase sempre vale a pena. Os passos estruturados pegam erros que aparecem em respostas diretas.

Teste você mesmo: peça pro Claude resolver um quebra-cabeça de lógica moderadamente difícil sem CoT, depois com "Vamos trabalhar isso passo a passo". Você vai ver que a diferença de precisão é real.

Tomada de decisão multi-etapas. Quando você precisa que Claude avalie opções sistematicamente—como escolher entre abordagens arquiteturais ou avaliar fatores de risco—o CoT força a consideração de cada dimensão. Sem isso, Claude às vezes pula etapas na avaliação.

Geração de código com decisões arquiteturais. O CoT ajuda aqui especificamente quando Claude precisa pensar sobre restrições e dependências antes de escrever. "Primeiro, vamos considerar a estrutura de dados que precisamos, depois pensar em casos extremos, depois escrever a implementação" produz código melhor que pular direto para uma solução.

Conteúdo que requer verificação de fatos. Se Claude está reunindo informações do dados de treinamento e você quer verificar seu raciocínio (em vez de só a conclusão), o CoT dá os passos intermediários para você checar.

Quando o Chain-of-Thought Desperdiça Tokens

Classificação e categorização. "Esse feedback de cliente é positivo ou negativo?" não precisa de raciocínio. O reconhecimento de padrão do Claude funciona bem sem narração. Adicionar CoT aqui só significa que você está pagando por frases como "O cliente menciona que teve um problema, o que sugere insatisfação..." antes dele dizer "Negativo."

Recuperação simples de fatos. Perguntas como "Qual é a capital da França?" ou "Quando React foi lançado?" não se beneficiam de raciocínio. Você não está testando construção de hipóteses; está testando reconhecimento de padrão. O CoT não adiciona nada além de latência e custo.

Sumarização direta. Resumir uma transcrição de reunião ou artigo não exige mostrar o trabalho. O resumo ou captura os pontos-chave ou não. O raciocínio intermediário não melhora a saída—só a torna mais longa.

Geração de texto direta. Escrever um email, post de blog ou descrição de produto não requer raciocínio passo a passo. Você quer a saída. O processo é invisível no produto final mesmo.

Tarefas onde precisão importa menos que velocidade. Se você está gerando listas criativas de brainstorm ou esboços rápidos, o CoT desacelera sem ganhos de qualidade proporcionais.

A Economia de Tokens que Ninguém Comenta

Aqui está o cálculo que a maioria das pessoas pula:

Uma resposta típica com CoT pode ser 40-60% mais longa que uma resposta direta. No Claude 3.5 Sonnet, isso é dinheiro de verdade em volume. Se você está processando 1.000 consultas de clientes por dia, adicionar 2.000 tokens de raciocínio a cada uma custa aproximadamente 15-20% a mais por consulta.

Às vezes vale a pena. Às vezes não.

Dica profissional: Teste seu caso de uso específico dos dois jeitos. Rode 20-30 exemplos com e sem CoT. Meça precisão, uso de tokens e custo. Para muitas tarefas rotineiras, você vai descobrir que os ganhos de precisão não justificam o overhead de tokens.

Um Framework Prático

Faça essas perguntas antes de adicionar CoT:

1. Essa tarefa tem múltiplos caminhos de raciocínio válidos? (Se sim, CoT ajuda a deixar claro qual o Claude escolhe.)
2. A correção é mais difícil que a geração? (Se a parte complicada é acertar, não produzir, o CoT importa.)
3. Eu me beneficiaria de ver os passos intermediários? (Se não, você não precisa deles na saída.)
4. Isso é uma tarefa única ou de alto volume? (Tarefas de alto volume precisam de eficiência. Tarefas únicas podem arcar com tokens extras.)

A Abordagem Híbrida

Aqui está no que cheguei: Use chain-of-thought condicional.

Para suas integrações de API ou processos em lote, torne o CoT opcional baseado em sinais de complexidade ou confiança. Algo assim:

Se a query toca múltiplos domínios, inclui lógica condicional, ou pede um ranking/comparação: inclua "Vamos pensar isso sistematicamente:"

Caso contrário: é só responder direto.

Outro movimento prático: peça pro Claude mostrar trabalho só para seções específicas. Você consegue os benefícios de transparência sem o overhead de resposta completa. "Resolva esse problema direto. Mostre seu raciocínio só para o primeiro passo e a conclusão final." Isso pega erros maiores sem a verbosidade.

Conversa Franca

Prompting com chain-of-thought não é ruim. É só usado demais. A técnica é legítima quando aplicada a problemas que realmente precisam dela. Mas se você está adicionando CoT a todo prompt por padrão, você provavelmente está deixando dinheiro na mesa.

A melhor prática não é "sempre use chain-of-thought." É "saiba quando raciocínio explícito está resolvendo seu problema real versus quando está só rodando o taxímetro."

Comece a prestar atenção em quais dos seus prompts melhoram com CoT e quais não. Você provavelmente vai descobrir que 30-40% dos seus casos de uso se beneficiam significativamente, enquanto o resto é só padding de tokens. Remover CoT das tarefas onde não ajuda vai deixar seus sistemas mais rápidos e baratos sem nenhuma perda de qualidade.

É aí que a otimização real está.