LangChain Perd le Contenu de Raisonnement dans les Modèles CoT : Comment Corriger le Bug des Fournisseurs LLM

Les développeurs travaillant avec des modèles CoT via LangChain ont rencontré une mauvaise surprise : les classes de chat du framework—ChatOpenAI, ChatDeepSeek et similaires—ne préservent pas le bloc de contenu de raisonnement dans la réponse finale. Cela signifie que les utilisateurs attendent simplement pendant que le modèle « pense », sans recevoir aucun retour, tandis que le raisonnement disparaît sans laisser de trace. Le problème affecte l'intégration avec la plupart des fournisseurs et agrégateurs d'LLM populaires.

Lorsqu'un modèle avec des capacités de raisonnement—par exemple, de la famille DeepSeek-R1 ou step-3.5-flash de Stepfun—génère une réponse, le processus de raisonnement interne est capturé dans un bloc reasoning_content séparé. C'est exactement ce bloc qui est perdu : ni ChatOpenAI ni les autres classes de chat de LangChain ne le transmettent plus loin dans la chaîne de traitement.

Pourquoi est-ce important ? Les modèles CoT (Chain of Thought—chaîne de raisonnement) sont spécifiquement entraînés pour former des étapes explicites de pensée avant la réponse finale. Les développeurs les choisissent précisément pour cette transparence : la capacité à montrer à l'utilisateur comment le modèle est arrivé à la solution, ou à utiliser les étapes intermédiaires pour un traitement ultérieur dans un pipeline. Lorsque le bloc de raisonnement est perdu—la valeur de l'approche CoT est diminuée.

L'absence de streaming de contenu de raisonnement impacte directement l'UX. L'utilisateur voit un écran vide pendant que le modèle effectue une chaîne de raisonnement couvrant des centaines de tokens. Le temps de réponse subjectivement perçu augmente brusquement, bien que le modèle soit effectivement déjà en train de fonctionner. Pour les produits où la vitesse de réponse est critique, c'est un inconvénient notable.

L'auteur a découvert le problème en pratique en travaillant avec le modèle stepfun/step-3.5-flash via le fournisseur russe polza.ai. Le fournisseur transmet le contenu de raisonnement dans le flux, cependant LangChain ne le capture pas et ne le transmet pas plus loin. Aucun des agrégateurs testés n'a résolu le problème de leur côté.

La solution s'est avérée résider dans l'extension des classes de chat standard de LangChain. L'essence de l'approche : redéfinir la méthode de traitement des chunks de streaming de sorte qu'elle extraie explicitement le champ reasoning_content de la réponse du fournisseur et l'ajoute à la structure de sortie de AIMessage. Ainsi, le bloc de raisonnement devient disponible à la fois en mode streaming et lors d'appels normaux au modèle.

En pratique, cela signifie créer une classe de chat personnalisée héritant de ChatOpenAI, avec une redéfinition de la méthode _stream et de la logique d'assemblage du message final. Lors du streaming, reasoning_content commence à s'afficher immédiatement, en parallèle avec la génération du raisonnement par le modèle—ce qui améliore fondamentalement la réactivité de l'interface.

Le cas est important non seulement comme solution technique, mais aussi comme symptôme d'un problème plus large : les frameworks à usage général comme LangChain s'adaptent lentement aux spécificités des nouvelles classes de modèles. Les normes API pour la transmission du contenu de raisonnement varient d'un fournisseur à l'autre, il n'y a pas d'approche unifiée—et tant qu'une n'apparaît pas, les développeurs devront combler les lacunes par eux-mêmes grâce à la personnalisation.

Pour les équipes construisant des produits sur des modèles CoT et LangChain, l'approche décrite fournit un modèle d'extension prêt à l'emploi. Il est reproductible pour tout fournisseur renvoyant reasoning_content dans un format compatible avec l'API OpenAI.