Chain-of-thought prompting: quando ajuda e quando desperdiça tokens

Chain-of-thought prompting aparece em quase todo tutorial de LLM como um upgrade gratuito: adicione "pense passo a passo" e veja a acurácia subir. A realidade é mais condicional. Uma meta-análise de 2025 cobriu mais de 100 papers, 20 datasets e 14 modelos diferentes, e a conclusão é incômoda para qualquer pessoa que paga por token: fora de matemática e raciocínio simbólico, CoT com frequência acrescenta custo sem acrescentar precisão. Saber quando esse limite se aplica é o que separa engenharia de prompt disciplinada de cargo-cult.

O domínio documentado do CoT é mais estreito do que o hype sugere

O paper de Sprague et al., publicado no ICLR 2025, com pesquisadores de UT Austin, Johns Hopkins e Princeton, é o tratamento quantitativo mais rigoroso dessa questão até hoje. O achado é específico: CoT aumenta acurácia de forma confiável em tarefas com estrutura composicional ou simbólica, como aritmética com múltiplos passos, lógica formal e raciocínio algorítmico, onde a resposta correta depende de uma sequência explícita de estados intermediários. Nesses casos, forçar o modelo a articular os passos direciona a geração para outputs internamente consistentes.

Fora desse domínio restrito, o cenário desmorona. Em recuperação de conhecimento, raciocínio de senso comum, classificação e geração de linguagem natural, CoT produz resultados comparáveis ou piores do que prompts de resposta direta. O paper registra que boa parte da literatura reportando ganhos com CoT estava concentrada justamente nas categorias de tarefas onde ele funciona, o que inflou a percepção de que a técnica é geral.

CoT como método é sólido. A condição de escopo que o acompanha é o que raramente aparece com clareza. Se você está rodando um modelo em cálculos financeiros com múltiplos passos, debugging de código ou satisfação de restrições formais, o custo em tokens compra acurácia real. Se você está classificando tickets de suporte, gerando descrições de produto ou sumarizando reviews, o que a pesquisa sugere é que você provavelmente está pagando por uma performance de confiança, não por um ganho de capacidade.

Um achado paralelo de um relatório do Wharton Generative AI Lab de junho de 2025 acrescenta uma dimensão relevante sobre tipo de modelo: para modelos com raciocínio nativo, como a série o da OpenAI ou o Claude com extended thinking ativado, adicionar instruções explícitas de CoT pode inflar a latência com retornos marginais de acurácia, porque o modelo já realiza raciocínio interno antes de surfaçar a resposta. Minha leitura das evidências é que empilhar CoT explícito sobre um modelo que já raciocina nativamente é mais ou menos equivalente a pedir para alguém narrar o próprio pensamento enquanto já está pensando.

O problema do ticket de suporte ilustra a lacuna de fidelidade

Um cenário concreto e reproduzível que torna os achados de Sprague tangíveis: imagine um classificador de tickets de suporte com cinco categorias, cobrança, entrega, trocas e devoluções, problemas técnicos e acesso a conta. Rodado com prompt de resposta direta e com CoT completo sobre algumas centenas de tickets, a diferença de acurácia entre as duas abordagens tende a ser negligenciável para esse tipo de tarefa, mas as respostas com CoT chegam a ser quatro a seis vezes mais longas.

O problema mais relevante é o que Li, Cao, Chen et al. chamam de "faithfulness" em seu paper de 2025 sobre efetividade e fidelidade do CoT: o raciocínio que o modelo produz não reflete necessariamente o processo computacional que gerou a resposta. Em tarefas de classificação especialmente, o modelo às vezes produz uma cadeia de raciocínio confiante e detalhada descrevendo um caminho de decisão errado e, ainda assim, chega ao rótulo correto. O raciocínio declarado e o output real estão parcialmente desacoplados.

Para um time de produto automatizando roteamento de tickets, isso é em grande parte inofensivo. Para qualquer fluxo onde um revisor humano está auditando a lógica, é um problema sério. O revisor lê uma justificativa que soa plausível, assume que o modelo raciocinou corretamente e confia no output mais do que deveria. O CoT está funcionando como artefato de persuasão, não como rastro de raciocínio. Você paga o custo de tokens por um texto que distorce o processo de QA enquanto o comportamento real de classificação do modelo permanece inalterado.

Isso não é um caso extremo raro. Minha leitura da literatura de faithfulness é que esse desacoplamento é especialmente provável em tarefas onde o modelo tem priors fortes de pattern-matching, que é exatamente onde o prompt direto já funciona bem e o CoT não acrescenta nada.

CoT truncado é pior do que nenhum CoT

Um modo de falha que raramente aparece em tutoriais: truncar uma cadeia de raciocínio no meio não equivale a remover o CoT do prompt. Pesquisa coberta em um paper de fevereiro de 2026 sobre raciocínio incompleto (arXiv 2602.14444) encontrou que comparar ausência de raciocínio explícito contra CoT truncado a 10% do seu orçamento natural produz resultados piores do que CoT completo ou nenhum CoT. Uma cadeia parcial quebra a estrutura interna da qual o modelo depende quando o raciocínio é de fato necessário.

As implicações práticas são específicas. Se você está trabalhando com orçamentos de token apertados ou janelas de contexto limitadas e não consegue garantir um rastro de raciocínio completo, é melhor mudar para prompt de resposta direta do que limitar o output do CoT no meio do pensamento. Isso importa em ambientes de produção onde configurações de max_tokens interagem com prompts de raciocínio, e em qualquer sistema onde CoT está ativado por padrão mas as respostas são truncadas por processamento posterior.

Existe uma solução mais elegante. A abordagem Focused Chain-of-Thought, descrita em um paper de novembro de 2025 (arXiv 2511.22176), separa extração de informação de raciocínio ao alimentar o modelo com input estruturado, uma tabela ou campos marcados em vez de um parágrafo cru, antes de invocar qualquer etapa de raciocínio. O resultado reportado é uma redução significativa nos tokens gerados com acurácia equivalente, porque inputs estruturados reduzem os passos de raciocínio de preenchimento e a tendência do modelo de reafirmar o contexto antes de engajar com o problema. Se você está pagando por raciocínio, estruturar seus inputs antes de invocá-lo é a alavanca de custo mais acionável disponível agora.

A decisão antes de ativar CoT

A pergunta prática antes de adicionar CoT a qualquer prompt é se a tarefa tem as propriedades estruturais que tornam o raciocínio explícito necessário. Algumas perguntas diagnósticas que ajudam a delimitar:

• Resolver essa tarefa requer estados intermediários explícitos, onde um erro no passo três se propaga para uma resposta final errada?
• A resposta correta é composicionalmente dependente de uma sequência de sub-respostas, ou pattern-matching direto sobre o input já produz o output correto?
• Você está usando um modelo com raciocínio nativo que já executa CoT interno antes de gerar uma resposta?
• Você tem restrições de orçamento de token que podem resultar em um rastro truncado?

Se a tarefa é sequencialmente composicional, matemática com múltiplos passos, código que requer manutenção de estado de variáveis, lógica formal, CoT está justificando o custo. Se a tarefa é classificação, extração, sumarização ou geração onde o modelo pode partir do input diretamente para um output correto, prompt direto com input bem estruturado é o caminho mais eficiente, com base no que a pesquisa disponível indica. A abordagem de input estruturado do Focused CoT te dá a disciplina de contexto explícito sem o overhead de tokens de um rastro de raciocínio completo.

A premissa padrão na maioria dos conselhos de prompt engineering vai na direção contrária: adicione CoT a menos que tenha um motivo para não adicionar. Dado o estado atual da pesquisa, esse padrão deveria ser invertido para qualquer classe de tarefa fora de raciocínio formal.

Na prática

Boa parte das tarefas de IA que rodam no meu dia a dia de operações de catálogo cai na categoria de classificação e extração: mapear atributos de fornecedor para campos da taxonomia interna, sinalizar descrições de produto inconsistentes, rotear problemas de conteúdo para o time certo. Essas tarefas são estruturalmente similares ao cenário do ticket de suporte descrito acima.

O que observo bate com o que a pesquisa descreve de forma qualitativa: respostas com instrução de passo a passo tendem a ser mais longas e, se alguma coisa, um pouco menos consistentes do que prompts de resposta direta com inputs bem estruturados. Ao mudar para campos estruturados e remover a instrução de CoT nesses fluxos de classificação de catálogo, os outputs ficaram visivelmente mais limpos, com retorno mais rápido e custo menor de API, sem nenhuma perda observável de precisão.

FAQ

"Pense passo a passo" ainda funciona em 2026?

Em tarefas de matemática, código e raciocínio formal, sim. A meta-análise de Sprague et al. no ICLR 2025 confirma que CoT ajuda de forma confiável onde as tarefas têm estrutura composicional ou simbólica. Em classificação, recuperação e geração, prompt de resposta direta com inputs estruturados performa de forma comparável a uma fração do custo em tokens.

Devo usar CoT com o extended thinking do Claude?

Extended thinking no Claude é um recurso de raciocínio nativo que já executa CoT interno antes de gerar a resposta. Adicionar instruções explícitas de CoT por cima é provavelmente redundante e pode inflar a latência. A documentação da Anthropic sobre extended thinking detalha quando o recurso é adequado e como ele interage com a estrutura do prompt.

O que acontece se minha resposta de CoT for cortada por um limite de token?

Com base no paper "Broken Chains" de 2026, CoT truncado performa pior do que CoT completo ou nenhum CoT. Se seu orçamento de token não consegue garantir um rastro de raciocínio completo, remova a instrução de CoT e use prompt direto estruturado.

Existe uma alternativa mais barata ao CoT completo para tarefas complexas?

Focused Chain-of-Thought, descrito em um paper de novembro de 2025 no arXiv (2511.22176), estrutura o contexto de input antes do raciocínio em vez de pedir ao modelo que raciocine sobre texto cru. Reporta reduções relevantes de tokens com acurácia equivalente em tarefas de raciocínio. Vale testar antes de commitar com CoT completo em qualquer fluxo de alto volume.

O erro mais caro em prompt engineering é aplicar a técnica certa na classe de tarefa errada em escala. CoT é genuinamente útil em um domínio específico, e esse domínio é menor do que a maioria dos tutoriais implica.