LangChain Perde Reasoning Content em Modelos CoT: Como Corrigir o Bug dos Provedores LLM

Desenvolvedores que trabalham com modelos CoT através do LangChain enfrentaram uma surpresa desagradável: as classes de chat do framework—ChatOpenAI, ChatDeepSeek e similares—não preservam o bloco de conteúdo de raciocínio na resposta final. Isso significa que os usuários simplesmente esperam enquanto o modelo "pensa", sem receber nenhum feedback, enquanto o raciocínio desaparece sem deixar rastros. O problema afeta a integração com a maioria dos provedores e agregadores de LLM populares.

Quando um modelo com capacidades de raciocínio—por exemplo, da família DeepSeek-R1 ou step-3.5-flash do Stepfun—gera uma resposta, o processo de raciocínio interno é capturado em um bloco reasoning_content separado. Este bloco é exatamente o que se perde: nem ChatOpenAI nem outras classes de chat do LangChain o passam adiante na cadeia de processamento.

Por que isso importa? Modelos CoT (Chain of Thought—cadeia de raciocínio) são especificamente treinados para formar etapas explícitas de pensamento antes da resposta final. Desenvolvedores os escolhem precisamente por essa transparência: a capacidade de mostrar ao usuário como o modelo chegou à solução, ou usar etapas intermediárias para processamento posterior em um pipeline. Quando o bloco de raciocínio é perdido—o valor da abordagem CoT é diminuído.

A ausência de streaming de conteúdo de raciocínio impacta diretamente a UX. O usuário vê uma tela em branco enquanto o modelo conduz uma cadeia de raciocínio abrangendo centenas de tokens. O tempo de resposta subjetivamente percebido aumenta drasticamente, embora o modelo esteja realmente já funcionando. Para produtos onde a velocidade de resposta é crítica, isso é uma desvantagem notável.

O autor descobriu o problema na prática ao trabalhar com o modelo stepfun/step-3.5-flash através do provedor russo polza.ai. O provedor transmite o conteúdo de raciocínio no stream, porém o LangChain não o captura e não o passa adiante. Nenhum dos agregadores testados resolveu o problema por sua conta.

A solução se mostrou estar na extensão das classes de chat padrão do LangChain. A essência da abordagem: redefinir o método para processamento de chunks de streaming para que ele extraia explicitamente o campo reasoning_content da resposta do provedor e o adicione à estrutura de saída de AIMessage. Assim, o bloco de raciocínio fica disponível tanto no modo de streaming quanto em chamadas normais do modelo.

Na prática, isso significa criar uma classe de chat personalizada que herda de ChatOpenAI, com redefinição do método _stream e da lógica para montagem da mensagem final. Durante o streaming, reasoning_content começa a ser exibido imediatamente, em paralelo com a geração de raciocínio do modelo—o que fundamentalmente melhora a responsividade da interface.

O caso é importante não apenas como uma solução técnica, mas também como um sintoma de um problema mais amplo: frameworks de uso geral como LangChain se adaptam lentamente às especificidades das novas classes de modelos. Os padrões de API para transmissão de conteúdo de raciocínio variam entre diferentes provedores, não há abordagem unificada—e até que uma apareça, os desenvolvedores terão que fechar as lacunas por conta própria através de customização.

Para equipes construindo produtos em modelos CoT e LangChain, a abordagem descrita fornece um template de extensão pronto para uso. É reproduzível para qualquer provedor que retorne reasoning_content em um formato compatível com a API OpenAI.