LangChain perd le reasoning content des modèles CoT : comment corriger ce bug avec les fournisseurs de LLM

Les développeurs qui exploitent des modèles CoT via LangChain ont eu une mauvaise surprise : les classes de chat du framework, ChatOpenAI, ChatDeepSeek et leurs équivalentes, ne conservent pas le bloc reasoning content dans la réponse finale. Concrètement, l'utilisateur attend que le modèle « réfléchisse » sans recevoir le moindre retour, et le raisonnement lui-même disparaît sans laisser de trace. Le problème touche l'intégration avec la plupart des fournisseurs et agrégateurs de LLM populaires.

Lorsqu'un modèle doté d'une fonction de raisonnement, par exemple de la famille DeepSeek-R1 ou step-3.5-flash de Stepfun, génère une réponse, son processus de raisonnement interne est consigné dans un bloc distinct, reasoning_content. C'est précisément ce bloc qui se perd : ni ChatOpenAI ni les autres classes de chat de LangChain ne le transmettent à la suite de la chaîne de traitement.

Pourquoi est-ce important ? Les modèles CoT (Chain of Thought, ou chaîne de raisonnement) sont spécifiquement entraînés à formuler des étapes de réflexion explicites avant la réponse finale. Les développeurs les choisissent justement pour cette transparence : elle permet de montrer à l'utilisateur comment le modèle est parvenu à sa conclusion, ou d'exploiter les étapes intermédiaires dans la suite du pipeline.

Si le bloc de raisonnement se perd, l'approche CoT perd sa valeur. L'absence de streaming du reasoning content pénalise directement l'UX. L'utilisateur fixe un écran vide pendant que le modèle déroule une chaîne de raisonnement de plusieurs centaines de tokens.

Le temps de réponse perçu s'envole, alors même que le modèle travaille déjà. Pour les produits où la vitesse perçue est critique, c'est un handicap réel. L'auteur a constaté le problème en pratique avec le modèle stepfun/step-3.

5-flash, utilisé via le fournisseur russe polza.ai. Le fournisseur transmet bien le reasoning content dans le flux, mais LangChain ne le récupère pas et ne le relaie pas.

Aucun des agrégateurs testés ne réglait le problème de son côté. La solution passe par l'extension des classes de chat standard de LangChain. Le principe : redéfinir la méthode de traitement des chunks en streaming pour qu'elle extraie explicitement le champ reasoning_content de la réponse du fournisseur et l'ajoute à la structure de sortie AIMessage.

Le bloc de raisonnement devient ainsi accessible aussi bien en mode streaming que lors d'un appel classique au modèle. En pratique, il s'agit de créer une classe de chat personnalisée qui hérite de ChatOpenAI, en redéfinissant la méthode _stream et la logique d'assemblage du message final. En streaming, le reasoning_content s'affiche immédiatement, au fur et à mesure que le modèle génère son raisonnement, ce qui améliore radicalement la réactivité de l'interface.

Ce cas compte non seulement comme solution technique, mais aussi comme symptôme d'un problème plus large : les frameworks généralistes comme LangChain s'adaptent lentement aux spécificités des nouvelles classes de modèles. Les standards d'API pour transmettre le reasoning content varient d'un fournisseur à l'autre, sans approche unifiée, et tant qu'elle n'émergera pas, les développeurs devront combler eux-mêmes les lacunes par la personnalisation. Pour les équipes qui bâtissent des produits sur des modèles CoT et LangChain, l'approche décrite fournit un modèle d'extension prêt à l'emploi.

Elle est reproductible pour tout fournisseur qui renvoie le reasoning_content dans un format compatible avec l'API OpenAI.