En janvier 2022, des chercheurs chez Google ont publié un article qui a changé la façon dont on parle à l’IA. Ils ont découvert qu’ajouter une phrase toute simple avant de demander à des modèles de langage de résoudre des problèmes pouvait faire grimper la précision de 17,7 % à 78,7 % sur des problèmes de maths en énoncé.

La phrase ? « Let’s think step by step. » (En français : « Réfléchissons étape par étape. »)

Ce n’était pas de la magie. C’était l’incitation par chaîne de pensée (chain-of-thought prompting), une technique qui donne à l’IA l’équivalent d’un papier brouillon pour dérouler un problème.

La recherche derrière tout ça

Jason Wei et ses collègues à Google Brain ont mené des expériences sur trois grands modèles de langage. Ils ont testé le raisonnement arithmétique, des questions de bon sens et de la manipulation symbolique. Le même schéma ressort, toutes catégories confondues : quand les modèles « montrent leur travail », ils donnent plus de bonnes réponses.

Sur le benchmark de maths GSM8K, leur modèle à 540 milliards de paramètres atteint 58 % de précision avec l’incitation en chaîne de pensée. Les consignes standard ? Nulle part. Un suivi utilisant la self-consistency a poussé ce résultat à 74 %.

Le résultat le plus frappant vient de Sports Understanding. PaLM 540B a atteint 95 % de précision, en battant des experts humains sans aide qui ont obtenu 84 %.

Quelques mois plus tard, des chercheurs de l’Université de Tokyo et de Google ont publié « Large Language Models are Zéro-Shot Reasoners ». Ils ont constaté que vous n’avez même pas besoin d’exemples. Il suffit d’ajouter « Let’s think step by step » et la précision sur MultiArith bondit de 17,7 % à 78,7 %. GSM8K passe de 10,4 % à 40,7 %.

Soit un gain de 61 points de pourcentage avec une seule phrase.

Pourquoi ça marche ?

Un utilisateur de Hacker News, leobg, a bien expliqué le mécanisme :

“I think the idea is that the LLM cannot think internally. It’s output is its thinking process. Especially with an auto regressive architecture like GPT, where each output token becomes part of the input. I imagine it like handing the LLM a piece of scratch paper.”

Ça capture quelque chose d’important. Les modèles de langage génèrent un jeton à la fois. Chaque jeton devient le contexte du suivant. Quand vous demandez une réponse immédiate, le modèle doit compresser tout le raisonnement dans le choix du tout premier mot. Mais quand vous demandez des étapes, chaque conclusion intermédiaire devient une partie de l’entrée pour ce qui suit.

Prenez ce problème de maths : « Roger a 5 balles de tennis. Il achète 2 boîtes de 3. Combien de balles de tennis a-t-il maintenant ? »

Le résoudre demande de comprendre l’énoncé, d’identifier les opérations, et de calculer correctement. Demander la réponse directement force le modèle à tout faire d’un coup, dans le saut entre question et nombre.

Demander des étapes lui permet de poser chaque brique. Roger commence avec 5. Il achète 2 boîtes. Chaque boîte contient 3 balles. Donc il achète 6 balles. 5 plus 6 fait 11.

Chaque phrase contraint la suivante. Le modèle construit vers la réponse au lieu de la deviner.

Le piège dont personne ne parle d’abord

Voici ce que les articles qui surfent sur la mode oublient : l’incitation en chaîne de pensée ne marche qu’avec de gros modèles.

La recherche originale a montré que c’est une « propriété émergente de l’échelle du modèle ». En dessous d’environ 100 milliards de paramètres, demander un raisonnement étape par étape dégrade en fait les performances. Les petits modèles produisent des chaînes qui ressemblent à du raisonnement, mais avec des erreurs logiques. Des étapes qui sonnent sûres d’elles conduisent à des réponses fausses plus souvent que si on demandait simplement la réponse.

Si vous utilisez un petit modèle local, cette technique peut se retourner contre vous. Testez. Comparez les résultats avec et sans l’instruction étape par étape. Ne partez pas du principe que la recherche s’applique à votre configuration.

Deux façons de procéder

Approche sans exemple (zéro-shot) : ajoutez simplement la phrase. Pas besoin d’exemples.

« Une batte et une balle coûtent $1.10 au total. La batte coûte $1 de plus que la balle. Combien coûte la balle ? Réfléchissons étape par étape. »

Ça marche étonnamment bien. Ça ne coûte rien de plus en longueur de consigne.

Approche avec quelques exemples (few-shot) : montrez d’abord au modèle à quoi ressemble un bon raisonnement.

Voici un problème de maths et comment le résoudre étape par étape :

Question : Il y a 15 arbres dans le bosquet. Des ouvriers du bosquet vont planter des arbres aujourd’hui. Une fois terminé, il y aura 21 arbres. Combien d’arbres les ouvriers ont-ils planté aujourd’hui ?

Raisonnement : On commence avec 15 arbres. On finit avec 21 arbres. La différence correspond à ce qui a été planté. 21 moins 15 égale 6.

Réponse : 6

Maintenant, résous celui-ci de la même façon : [votre question réelle]

L’approche avec quelques exemples consomme plus de jetons, mais produit souvent de meilleurs résultats sur des tâches complexes. Les exemples enseignent le format et la profondeur, pas seulement l’idée générale de « montrer son travail ».

Les tâches qui en profitent

L’incitation en chaîne de pensée brille pour les problèmes en plusieurs étapes, là où les erreurs se cumulent. Problèmes de maths en énoncé. Casse-têtes logiques. Planification en plusieurs étapes. Tout ce pour quoi vous prendriez vous-même un papier brouillon.

L’analyse d’IBM souligne des usages concrets : des bots de service client qui découpent les problèmes, des tâches de recherche qui demandent de formuler des hypothèses, des explications pédagogiques en maths et en sciences. La technique marche le mieux quand la tâche a réellement des étapes intermédiaires qui influencent la réponse finale.

Un autre commentateur sur Hacker News, travisjungroth, a fait une remarque qui m’est restée :

“Most writing about anything difficult is product, not process. Articles get drafts before being published. People think about answers before writing them down. How to Solve It does a great job explaining this about math problems. The steps to the proof are not the steps to creating the proof. So when you go to solve a problem by mimicking the solutions to problems, something is missing.”

C’est important. La solution publiée d’un problème de maths ne ressemble en rien au processus réel qui permet de la trouver. Les modèles de langage, entraînés sur des réponses finales « nettoyées », n’ont jamais vu le travail brouillon qui y mène. Demander des étapes recrée quelque chose qui manquait dans l’entraînement.

Les tâches qui n’en profitent pas

Les recherches simples n’y gagnent rien. Demander « Quelle est la capitale de la France ? » avec des instructions étape par étape produit juste une sortie plus longue, sans amélioration de précision. Le modèle a déjà cette réponse à portée de main.

Les tâches qui demandent de la créativité plutôt que du raisonnement s’améliorent moins. Écrire de la poésie, générer du texte publicitaire, trouver des idées de noms. Il n’y a pas de logique à dérouler. Les forcer dans un cadre de raisonnement paraît artificiel et peut contraindre la sortie inutilement.

Des travaux récents ont montré que les bénéfices ne se généralisent pas aussi largement que le laissait penser l’emballement du début. Les consignes en chaîne de pensée (CoT) améliorent les modèles sur certaines tâches de planification spécifiques, mais se transfèrent mal d’un domaine à l’autre. Les gains sont réels, mais plus étroits qu’on ne le dit parfois.

Et il n’y a aucune garantie que le raisonnement soit fidèle. Le modèle peut produire des étapes plausibles qui ne reflètent pas vraiment la manière dont il a trouvé la réponse. Ça crée un risque de fausse confiance. Vous voyez une chaîne logique et vous supposez que c’est correct, alors que ça peut être une rationalisation a posteriori plutôt qu’un raisonnement authentique.

Le coût de calcul compte

Plus de jetons, c’est plus de temps et plus d’argent. Si vous appelez une API, des réponses avec chaîne de pensée coûtent plus cher que des réponses directes. Sur des volumes élevés, ça grimpe vite.

Demandez-vous si le gain de précision justifie le coût. Un bot de service client qui répond à des FAQ simples n’a probablement pas besoin de chaînes de raisonnement. Un système qui fait des calculs financiers, si.

Passer à la pratique

Pour les problèmes de maths et de logique, commencez sans exemple (zéro-shot). Ajoutez « Let’s think step by step » (ou en français « Réfléchissons étape par étape ») à votre consigne. Comparez les résultats à votre base.

Pour les tâches complexes en plusieurs étapes, envisagez une approche avec quelques exemples (few-shot) qui montre la profondeur de raisonnement que vous voulez. Un ou deux bons exemples surpassent souvent le sans-exemple (zéro-shot) pur sur des problèmes difficiles.

Pour tout ce qui ressemble à de la planification, essayez de découper la tâche en phases explicites. Demandez le plan d’abord, puis l’exécution. C’est de la chaîne de pensée appliquée au niveau de la tâche plutôt qu’au niveau de la phrase.

Si la précision compte plus que la vitesse, ajoutez une étape de vérification. Une fois que le modèle a trouvé une réponse, demandez-lui de vérifier le raisonnement. Ça rattrape certaines erreurs qui passent au premier tour.

Voici un exemple qui montre la différence en pratique :

Sans chaîne de pensée :

« Le chiffre d’affaires d’une entreprise a augmenté de 20 % en Q1 puis a baissé de 15 % en Q2. Quel est le changement net ? »

Modèle : « 5 % de croissance »

Cette réponse est fausse. Le modèle a multiplié au lieu de calculer des pourcentages composés.

Avec chaîne de pensée :

« Le chiffre d’affaires d’une entreprise a augmenté de 20 % en Q1 puis a baissé de 15 % en Q2. Quel est le changement net ? Voyons cela étape par étape. »

Modèle : « En partant de 100 comme base. Après 20 % de croissance : 100 x 1.20 = 120. Après une baisse de 15 % depuis ce nouveau montant : 120 x 0.85 = 102. Changement net : 102 - 100 = 2, soit 2 % de croissance. »

Le raisonnement forcé empêche l’erreur de raccourci. Le modèle ne peut pas sauter à « 20 moins 15 » parce qu’il doit dérouler le calcul réel.

Des variantes à connaître

La technique de base a engendré plusieurs extensions.

Self-consistency génère plusieurs chemins de raisonnement et retient la réponse majoritaire. Si vous demandez au modèle de résoudre un problème cinq fois avec une chaîne de pensée, et qu’il donne la même réponse quatre fois, cette réponse est probablement la bonne. Cette approche a fait passer la précision sur GSM8K de 58 % à 74 % dans la recherche de suivi chez Google.

Tree of Thoughts explore plusieurs branches de raisonnement en parallèle, au lieu de s’engager sur une seule trajectoire. Utile quand il existe vraiment différentes approches d’un problème et que vous voulez en explorer plusieurs avant de choisir.

Least-to-Most prompting découpe les problèmes complexes en sous-problèmes, résout d’abord les plus simples, puis réutilise ces solutions pour attaquer les parties difficiles. Pratique pour des problèmes avec une hiérarchie naturelle ou des dépendances.

Ces variantes ajoutent de la complexité. Maîtrisez d’abord la version simple. La plupart des gens obtiennent déjà beaucoup de valeur en ajoutant « let’s think step by step » et n’auront jamais besoin de versions plus élaborées.

La vue d’ensemble

L’incitation en chaîne de pensée marche parce qu’elle exploite la façon dont ces modèles fonctionnent réellement. Ce sont des prédicteurs du jeton suivant. Chaque mot contraint la probabilité de ce qui vient après. Demander un raisonnement crée des contraintes utiles qui s’accumulent jusqu’à des réponses correctes.

Ça peut devenir obsolète. Des modèles entraînés spécifiquement pour raisonner, comme ceux avec des modes de « pensée » intégrés, peuvent internaliser ces schémas. La consigne explicite pourrait devenir inutile, à mesure que le comportement se retrouve « cuit » dans les poids du modèle.

Mais pour l’instant, avec les modèles actuels, la technique reste précieuse. Ça coûte une phrase et ça peut multiplier la précision sur les bonnes tâches. La clé, c’est de savoir lesquelles.

Comment savoir si le raisonnement qu’un modèle vous montre est le raisonnement qu’il a réellement utilisé ?