LangChain Pierde Reasoning Content en Modelos CoT: Cómo Corregir el Bug de Proveedores LLM

Los desarrolladores que trabajan con modelos CoT a través de LangChain se han encontrado con una sorpresa desagradable: las clases de chat del framework—ChatOpenAI, ChatDeepSeek y similares—no preservan el bloque de contenido de razonamiento en la respuesta final. Esto significa que los usuarios simplemente esperan mientras el modelo "piensa", sin recibir ninguna retroalimentación, mientras que el razonamiento desaparece sin dejar rastro. El problema afecta a la integración con la mayoría de los proveedores y agregadores de LLM populares.

Cuando un modelo con capacidades de razonamiento—por ejemplo, de la familia DeepSeek-R1 o step-3.5-flash de Stepfun—genera una respuesta, el proceso de razonamiento interno se captura en un bloque reasoning_content separado. Este bloque es exactamente lo que se pierde: ni ChatOpenAI ni otras clases de chat de LangChain lo transmiten más adelante en la cadena de procesamiento.

¿Por qué es importante? Los modelos CoT (Chain of Thought—cadena de razonamiento) están específicamente entrenados para formar pasos explícitos de pensamiento antes de la respuesta final. Los desarrolladores los eligen precisamente por esta transparencia: la capacidad de mostrar al usuario cómo el modelo llegó a la solución, o de utilizar pasos intermedios para procesamiento posterior en un pipeline. Cuando se pierde el bloque de razonamiento—el valor del enfoque CoT se reduce.

La ausencia de streaming de contenido de razonamiento impacta directamente en la UX. El usuario ve una pantalla en blanco mientras el modelo realiza una cadena de razonamiento de cientos de tokens. El tiempo de respuesta subjetivamente percibido aumenta bruscamente, aunque el modelo está efectivamente funcionando. Para productos donde la velocidad de respuesta es crítica, esto es una desventaja notable.

El autor descubrió el problema en la práctica al trabajar con el modelo stepfun/step-3.5-flash a través del proveedor ruso polza.ai. El proveedor transmite el contenido de razonamiento en el stream, sin embargo LangChain no lo captura y no lo pasa más adelante. Ninguno de los agregadores probados resolvió el problema por su cuenta.

La solución resultó estar en la extensión de las clases de chat estándar de LangChain. La esencia del enfoque: redefinir el método para procesar chunks de streaming de manera que extraiga explícitamente el campo reasoning_content de la respuesta del proveedor y lo agregue a la estructura de salida de AIMessage. Así, el bloque de razonamiento queda disponible tanto en modo de streaming como en llamadas normales al modelo.

En la práctica, esto significa crear una clase de chat personalizada que herede de ChatOpenAI, con redefinición del método _stream y la lógica para ensamblar el mensaje final. Durante el streaming, reasoning_content comienza a mostrarse inmediatamente, en paralelo con la generación de razonamiento del modelo—lo que mejora fundamentalmente la capacidad de respuesta de la interfaz.

El caso es importante no solo como solución técnica, sino también como síntoma de un problema más amplio: los frameworks de propósito general como LangChain se adaptan lentamente a las especificidades de nuevas clases de modelos. Los estándares de API para transmitir contenido de razonamiento varían entre diferentes proveedores, no hay un enfoque unificado—y hasta que uno aparezca, los desarrolladores tendrán que cerrar las brechas por cuenta propia mediante personalización.

Para equipos que construyen productos sobre modelos CoT y LangChain, el enfoque descrito proporciona una plantilla de extensión lista para usar. Es reproducible para cualquier proveedor que devuelva reasoning_content en un formato compatible con la API de OpenAI.