Le CoT visible n'améliore pas de façon universelle la génération de code SQL et pandas, selon une nouvelle étude

Des chercheurs ont testé l'un des conseils de prompting les plus répétés, « laisse le modèle réfléchir à voix haute », sur une tâche à vérification objective : la génération de code analytique exécutable. Le préprint arXiv 2610.10639 compare SQL et Python (pandas) sur des requêtes identiques. Les auteurs ne trouvent ni gain de précision universel avec une chaîne de raisonnement visible (Chain-of-Thought), ni bénéfice stable à raisonner « dans le langage de la tâche ». L'effet dépend de la persona du prompt, du langage cible, de la configuration du modèle et du mode de raisonnement interne.

Comment l'expérience est construite

Le code analytique est un bon terrain d'essai. La requête en langage naturel est ambiguë, le modèle doit s'ancrer dans le schéma de données, et le résultat obéit aux règles strictes du langage cible. Une même question sur les données peut se résoudre aussi bien par une requête SQL que par un script pandas. Les auteurs ont donc construit un benchmark où les requêtes sont appariées entre les deux langages, afin de tester une hypothèse courante : le raisonnement visible fonctionnerait mieux lorsqu'il est écrit dans la même représentation que la réponse, c'est-à-dire « penser en SQL » ou « penser en Python ».

L'expérience croise plusieurs facteurs :

• la formulation de la persona dans le prompt ;
• le langage cible : SQL ou Python (pandas) ;
• le format du CoT visible, y compris un raisonnement dans la représentation du langage cible ;
• des préfixes de contrôle ;
• la génération directe, sans raisonnement visible ;
• les configurations de raisonnement interne du modèle.

La qualité est évaluée par l'exécution du code, et non par la ressemblance du texte avec une référence. Le résumé ne donne ni résultats chiffrés ni noms de modèles : il faudra les chercher dans le texte intégral.

Ce que montrent les résultats

La conclusion principale est négative, mais utile en pratique. Le CoT visible n'apporte pas de gain de précision général. Aligner la représentation du raisonnement sur le langage cible ne fonctionne pas non plus comme une règle : cela aide dans certains cas, pas dans d'autres. Le signe et l'ampleur de l'effet dépendent de la combinaison entre persona, langage, modèle et réglages du raisonnement interne.

Les ablations de contrôle ont une valeur particulière. Elles séparent l'effet du contenu du raisonnement de celui du format du prompt. Une partie des variations de qualité peut s'expliquer par le simple fait qu'un gabarit ou un préfixe supplémentaire décale le comportement du modèle, que celui-ci raisonne de façon pertinente ou non. Les auteurs le formulent ainsi : le raisonnement visible améliore parfois la génération de code exécutable, et parfois ne fait surtout que perturber le comportement du modèle. Dans plusieurs configurations, le facteur décisif est le raisonnement interne, et non ce qui est affiché dans la réponse.

Que faire pour les équipes qui développent du text-to-SQL et des

agents analytiques

Il ne faut pas considérer le prompt « think step-by-step » comme une valeur par défaut. Il doit être validé sur vos propres données, comme n'importe quel autre paramètre. Voici l'ensemble minimal de pratiques qui découle de ce travail :

• Conservez la génération directe, sans CoT visible, comme référence obligatoire, et comparez-y vos variantes sur le résultat d'exécution des requêtes.
• Testez le prompt conjointement avec le modèle, la persona, le langage cible et le mode thinking. Le transfert de réglages d'une combinaison à l'autre n'est pas fiable.
• Ajoutez des préfixes de contrôle pour distinguer le bénéfice du raisonnement de l'effet d'un long gabarit.
• Pour les modèles de raisonnement, vérifiez séparément si le CoT visible n'entrave pas le raisonnement interne.
• N'intégrez pas de conseils du type « pense en SQL » dans le prompt système sans les avoir mesurés sur votre schéma.

Les limites sont tout aussi évidentes. Il s'agit d'un préprint en version v1, sans relecture par des pairs, et le résumé ne permet pas d'évaluer l'ampleur des effets ni la couverture des modèles. Mais comme cadre méthodologique pour déterminer où le CoT aide le code exécutable, où il ne fait que du bruit et où les réglages du modèle comptent davantage, ce travail est utile à toute équipe qui exploite un assistant analytique en production.