8. Que signifie « raisonner » pour un modèle ?

Passerelle comptait 27 bénévoles l’an dernier et en compte 41 cette année. Jusqu’ici, nous avons surtout demandé au modèle de résumer cette information. Posons maintenant une autre question :

De quel pourcentage le nombre de bénévoles a-t-il augmenté ? Peut-on dire qu’il a doublé ? Justifiez brièvement votre réponse.

La note ne contient pas directement la réponse. Pour la construire, il faut relier les deux nombres, choisir une base de comparaison, effectuer un calcul et interpréter le résultat. Recopier les données ne suffit plus.

Un modèle peut réussir cette tâche. Il peut aussi produire une formule bien présentée avec le mauvais dénominateur, ou une conclusion correcte accompagnée d’une explication incorrecte. Que faut-il alors entendre par « raisonnement » ? Et que nous apprend réellement une réponse détaillée ?

Ce chapitre examine les capacités observables et les mécanismes qui peuvent les soutenir. Les calculs et les réponses de Passerelle sont des exemples pédagogiques rédigés pour le cours, pas des résultats mesurés sur un modèle.

Raisonner : relier des informations pour établir une conclusion

Dans ce chapitre, raisonner désigne une capacité à utiliser des données, des règles ou des contraintes pour construire une conclusion. Il peut s’agir de calculer une variation, de combiner plusieurs conditions ou d’évaluer si une proposition découle des informations disponibles.

Pour Passerelle, il faut distinguer une augmentation en nombre et une augmentation en pourcentage. Dans un problème de planification, il faudrait plutôt respecter des contraintes d’horaires ou de capacité. Le type de vérification dépend donc de la tâche.

Cette définition porte sur ce que le système peut accomplir. Elle ne suppose pas qu’il réfléchisse comme une personne. Une réponse réussie ne suffit pas à établir une conscience, une intention ou une expérience subjective.

Il faut aussi distinguer réussir un exemple et posséder une capacité robuste. Un résultat correct peut provenir d’une procédure bien appliquée, d’un cas proche de l’entraînement ou d’un choix chanceux. Pour évaluer la capacité, on compare les résultats sur plusieurs problèmes, en modifiant les données et les contraintes. Un succès isolé ne révèle pas tout le mécanisme qui l’a produit.

Une solution dont on peut contrôler les étapes

Reprenons la question sur les bénévoles. Voici une résolution que vous pouvez vérifier sans modèle.

Calculer l’augmentation en nombre

L’association est passée de 27 à 41 bénévoles. La différence est :

41 − 27 = 14 bénévoles supplémentaires.

Le résultat 14 est un nombre de personnes, pas un pourcentage. Pour exprimer une augmentation relative, il faut le rapporter à une valeur de référence.

Choisir la bonne base de comparaison

La question porte sur l’augmentation depuis l’an dernier. La référence est donc l’effectif initial, soit 27 bénévoles :

Taux d’augmentation = (41 − 27) ÷ 27 × 100 ≈ 51,9 %.

Diviser par 41 donnerait environ 34,1 %. Le calcul arithmétique serait possible, mais il ne répondrait pas à la même question : il exprimerait la différence comme une part de l’effectif actuel, plutôt que comme une augmentation par rapport à l’effectif initial.

Vérifier l’interprétation

Doubler 27 donnerait 54. Comme 41 est inférieur à 54, le nombre de bénévoles n’a pas doublé. Une augmentation de 100 % aurait été nécessaire.

Une réponse finale suffisante serait donc :

Le nombre de bénévoles a augmenté de 14, soit environ 51,9 % par rapport aux 27 bénévoles de l’an dernier. Il n’a pas doublé : un doublement aurait porté l’effectif à 54.

La valeur de cette explication ne tient pas à sa longueur. Elle rend visibles les données, la formule, la base de comparaison et un contrôle de cohérence. Chacun de ces éléments peut être examiné séparément.

Pourquoi produire des étapes intermédiaires peut aider

Au chapitre sur la génération, nous avons vu qu’un token produit entre dans la séquence utilisée pour calculer les suivants. Cette propriété devient utile lorsqu’un problème comporte plusieurs opérations.

Si le modèle génère d’abord une différence, puis une formule et enfin une interprétation, ces éléments intermédiaires peuvent servir à construire la suite. Il ne doit plus produire le résultat final en s’appuyant uniquement sur l’énoncé initial : il dispose aussi du travail déjà formulé.

Cette séquence joue le rôle d’un espace de travail textuel. On rencontre parfois le terme anglais scratchpad, qui évoque un brouillon. L’analogie aide à comprendre la réutilisation des résultats intermédiaires ; elle ne signifie pas que le modèle tient un carnet conscient ou que chaque ligne est correcte.

Produire ces tokens demande aussi des calculs supplémentaires. Chaque étape de génération mobilise le réseau, puis ajoute un élément pouvant être utilisé par les étapes suivantes. Karpathy explique ce rôle des tokens intermédiaires à partir de 1 h 52 min 17 s.

Dans les modèles décrits ici, ces étapes utilisent la génération token par token pour construire une solution. Même une réponse directe demande des calculs : pour produire un seul token, le réseau transforme des représentations numériques à travers ses couches. Les étapes textuelles permettent d’étaler le travail sur une séquence plus longue. « Prédire le prochain token » décrit la sortie recherchée à chaque étape, pas toute la complexité du calcul qui permet de la produire.

Une erreur intermédiaire peut aussi se transmettre

Si le modèle écrit d’abord « la différence est de 16 bénévoles », il peut ensuite appliquer correctement une formule à ce résultat faux. La suite paraît organisée, mais repose sur une erreur.

Le modèle peut parfois repérer cette erreur et la corriger. Il peut aussi la conserver ou modifier une étape qui était correcte. L’autovérification est un comportement possible, pas une garantie indépendante de fiabilité.

Karpathy illustre à la fois l’utilité des étapes et leurs limites dans sa démonstration de problèmes arithmétiques, à partir de 1 h 54 min 06 s. Ces exemples montrent un mécanisme utile ; ils ne prouvent pas que toute réponse longue est supérieure à une réponse courte.

La chaîne de raisonnement : une méthode, pas une preuve

Une chaîne de raisonnement, ou chain of thought (CoT), est une séquence d’étapes intermédiaires générées avant une réponse finale. Elle peut décomposer le problème, proposer des opérations ou examiner des possibilités.

Dans l’étude Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, publiée initialement en 2022, Wei et ses collègues fournissent aux modèles des exemples de questions accompagnées d’étapes de résolution. Cette façon de construire le prompt améliore les résultats sur plusieurs tâches arithmétiques, symboliques et de raisonnement de sens commun étudiées.

Le point important est qu’ils ne réentraînent pas les modèles pour cette expérience : les exemples sont placés dans l’entrée. Le prompt aide à mobiliser des capacités du modèle existant.

Mais les auteurs signalent aussi les limites de leur méthode. Les étapes produites ne sont pas nécessairement correctes et peuvent conduire à des réponses correctes ou incorrectes. Les résultats dépendent des modèles et des tâches évalués.

Il serait donc excessif d’en déduire que la phrase « raisonne étape par étape » améliore toujours un assistant. Une consigne peut orienter la réponse ; elle ne remplace ni les capacités apprises ni la vérification. Les façons de solliciter un modèle de raisonnement moderne peuvent aussi différer de celles étudiées dans cette expérience historique.

Expliquer après coup n’est pas la même opération

Supposons qu’une réponse commence par « 34,1 % », puis développe une explication. Si le système génère ce texte dans cet ordre, l’explication arrive après le choix du résultat. Elle n’a donc pas pu servir d’étape intermédiaire pour produire ce résultat. Elle peut le justifier, le contrôler ou le corriger ensuite.

Karpathy souligne cette différence entre répondre d’abord et résoudre avant de conclure, vers 1 h 51 min 13 s.

Attention toutefois : l’ordre visible à l’écran ne révèle pas toujours l’ordre complet du travail. Un système peut effectuer des étapes non affichées avant de présenter une réponse qui commence par la conclusion. Nous devons donc distinguer le processus de génération de la mise en forme de la réponse destinée au lecteur.

Ce que change un modèle de raisonnement

L’expression modèle de raisonnement désigne généralement un modèle entraîné et configuré pour consacrer davantage de travail à la résolution de problèmes avant de fournir sa réponse finale. Ce travail peut inclure une décomposition, des essais, des vérifications ou des révisions.

Ce n’est pas une séparation absolue entre des modèles capables de raisonner et d’autres qui en seraient dépourvus. Un assistant généraliste peut réussir des tâches de raisonnement. Le nom décrit surtout une orientation de l’entraînement et du fonctionnement pendant l’usage, dont l’efficacité doit être évaluée.

Apprendre à partir de résultats vérifiables

Le chapitre sur l’entraînement a présenté l’apprentissage par renforcement. Dans certains entraînements au raisonnement, le signal de récompense repose sur des résultats que l’on peut contrôler : une réponse mathématique attendue ou la réussite de tests de programmation, par exemple.

Le principe est de générer des solutions, d’évaluer leur réussite, puis d’ajuster les paramètres pour favoriser les comportements qui obtiennent de meilleurs résultats. Sur notre petit problème, un évaluateur pourrait vérifier le taux d’augmentation et la conclusion sur le doublement.

Le rapport DeepSeek-R1, dans sa version de janvier 2025, fournit un exemple documenté. Pour DeepSeek-R1-Zero, les chercheurs appliquent du renforcement à un modèle de base et utilisent notamment des récompenses liées à la justesse des réponses et au format. Le modèle DeepSeek-R1 présenté dans le même rapport suit, lui, un parcours comprenant aussi des données supervisées. Ce ne sont pas deux noms pour un entraînement identique.

Le renforcement n’est donc ni la seule méthode disponible ni une étape obligatoire de tout raisonnement. Des exemples supervisés peuvent également enseigner des démarches utiles. Microsoft décrit cette place du renforcement dans LLM Fundamentals.

Ce que la récompense ne démontre pas

Vérifier seulement le résultat final ne valide pas automatiquement chaque étape. Une solution peut obtenir la bonne réponse avec une justification défectueuse. Un test de programmation peut laisser passer une erreur située hors des cas testés.

Un score élevé montre une réussite selon l’évaluation utilisée. Il ne prouve pas une compétence universelle, ni une capacité à établir des faits absents des données. La qualité du signal d’apprentissage et la diversité des évaluations restent déterminantes.

Entraîner davantage et calculer davantage sont deux choses différentes

On peut améliorer un système en modifiant ses paramètres pendant l’entraînement. On peut aussi lui permettre d’effectuer davantage de travail au moment d’une demande, avec les paramètres déjà appris. Ce second levier est appelé calcul à l’inférence, ou inference-time compute.

Dans le fonctionnement habituel décrit ici, accorder davantage de temps ou de tokens de raisonnement ne réentraîne pas le modèle sur votre question. Cela lui donne davantage de possibilités de travail pendant cette exécution.

Certains systèmes peuvent prolonger une solution, explorer plusieurs propositions ou les comparer. Ces stratégies ne sont pas présentes dans tous les produits. Le point commun est l’utilisation de ressources de calcul pendant la résolution, plutôt qu’une simple augmentation de la longueur demandée pour le texte final.

Microsoft souligne que les modèles entraînés au raisonnement peuvent mieux réussir certaines tâches complexes, avec davantage de tokens et de délai. Le bénéfice dépend de la tâche : allonger une analyse n’apporte pas nécessairement quelque chose à la reformulation d’une phrase courte.

Le temps d’attente ne mesure pas non plus, à lui seul, la qualité du raisonnement. Il peut inclure le temps de calcul, l’attente d’un service ou l’utilisation d’outils. Et un long développement peut répéter une hypothèse erronée plutôt que la résoudre.

Ce que vous voyez n’est pas tout ce que le système calcule

Une application peut afficher un texte d’étapes, un résumé ou seulement la réponse finale. Il faut distinguer trois objets :

La documentation d’Anthropic précise, par exemple, que le texte de raisonnement renvoyé dans son interface peut être un résumé. Cette propriété décrit le service documenté ; elle ne doit pas être attribuée automatiquement à toutes les applications.

L’absence d’étapes visibles ne prouve donc pas l’absence de calcul intermédiaire. Inversement, un panneau intitulé « réflexion » ne garantit pas que vous voyez tous les facteurs ayant influencé la réponse.

Une explication peut être correcte sans être un compte rendu fidèle

Deux questions doivent rester séparées. La validité demande si les étapes justifient la conclusion. La fidélité demande si le texte décrit réellement les éléments qui ont conduit le système à cette conclusion.

L’étude d’Anthropic Reasoning models don’t always say what they think, publiée en avril 2025, examine cette seconde question. Les chercheurs ajoutent des indices de réponse dans des questions, puis observent si les modèles mentionnent leur influence dans les étapes générées.

Dans les expériences étudiées, Claude 3.7 Sonnet et DeepSeek R1 peuvent modifier leur réponse en fonction de l’indice sans signaler cette influence dans leur explication. Le texte ne rapporte donc pas nécessairement tous les éléments qui ont orienté la réponse.

L’étude porte sur des conditions particulières, notamment des questionnaires à choix multiples avec indices ajoutés. Elle ne montre pas que toute explication est fausse ou inutile. Elle montre pourquoi il ne faut pas traiter une chaîne de raisonnement comme un accès garanti et complet aux causes de la réponse.

Pour utiliser le résultat, vous n’avez pas besoin d’exiger une trace interne exhaustive. Vous avez besoin d’une solution dont les données, les hypothèses, les opérations décisives et les conclusions peuvent être contrôlées.

Le raisonnement ne remplace pas les données manquantes

Les nombres 27 et 41 permettent de calculer une augmentation. Ils ne permettent pas d’expliquer pourquoi davantage de bénévoles ont rejoint Passerelle.

Une réponse qui invoque une campagne sur les réseaux sociaux peut proposer une hypothèse plausible. Sans autre information, elle ne peut pas présenter cette campagne comme un fait ni lui attribuer l’augmentation. Un développement de plusieurs pages ne comble pas ce manque de preuve.

La même prudence s’applique aux décisions. Le nombre de bénévoles a augmenté, mais faut-il organiser davantage d’ateliers ? Il faudrait connaître les besoins, les disponibilités, les locaux et les ressources. Le calcul précédent ne suffit pas à prendre cette décision.

Le raisonnement peut relier des données et examiner les conséquences d’une hypothèse. Il ne transforme pas cette hypothèse en observation. Reconnaître qu’une conclusion n’est pas établie fait partie d’une bonne résolution.

Demander une justification utile, puis la vérifier

Pour notre problème, une demande précise pourrait être :

À partir de la note de Passerelle, calcule l’augmentation du nombre de bénévoles en nombre et en pourcentage. Indique la valeur de référence, la formule et l’arrondi. Vérifie si le nombre a doublé. Donne une justification concise et n’invente pas la cause de cette évolution.

Cette consigne décrit un résultat vérifiable. Elle ne demande pas une transcription des processus internes et ne suppose pas que « plus long » signifie « meilleur ».

Le contrôle reste ensuite de votre côté. Comparez les données à la note, vérifiez le choix de la référence et refaites le calcul. Pour un problème plus long, une calculatrice, un tableur ou un programme peut fournir une vérification distincte de la prose générée.

Un outil correctement utilisé peut fiabiliser une opération arithmétique sans valider la formulation du problème. Calculer 14 ÷ 41 × 100 avec une calculatrice donne un résultat numérique correct pour cette expression, mais toujours la mauvaise base pour le taux d’augmentation demandé.

Si le modèle utilise lui-même un outil, le système combine alors génération et exécution externe. Le modèle propose l’opération ; l’outil la réalise selon ses propres règles ; il faut encore interpréter le résultat. Karpathy souligne cette distinction dans son passage sur le recours au code pour les calculs, à partir de 1 h 55 min 48 s. Un prochain chapitre développera le rôle des outils.

Exercice : une conclusion correcte suffit-elle ?

Voici deux analyses fictives de la question sur Passerelle. Elles sont écrites pour être comparées, sans utiliser un service d’IA.

Analyse A :

Le nombre de bénévoles n’a pas doublé. Il a augmenté de 14 et la variation est de 14 ÷ 41 × 100, soit environ 34,1 %.

Analyse B :

Le nombre de bénévoles n’a pas doublé : il faudrait atteindre 54 à partir de 27. L’augmentation est de 14 ÷ 27 × 100, soit environ 51,9 %. La note ne permet pas d’en établir la cause.

Comparez les analyses en suivant cet ordre :

1. Identifiez la conclusion qu’elles partagent.
2. Vérifiez la référence utilisée pour chaque pourcentage. Quelle question chaque division permet-elle de traiter ?
3. Examinez le contrôle du doublement. Dépend-il du calcul du pourcentage ?
4. Expliquez pourquoi juger seulement la première phrase laisserait passer une erreur dans l’une des analyses.

L’objectif est d’évaluer une solution, pas de choisir le texte qui paraît le plus assuré. Une conclusion juste peut coexister avec une étape incorrecte ; une réserve explicite peut être plus rigoureuse qu’une explication causale inventée.

Vérifier votre compréhension

1. Pourquoi des tokens intermédiaires peuvent-ils aider à résoudre un problème, alors que les paramètres du modèle restent fixes pendant la demande ?
2. Quelle différence y a-t-il entre fournir des exemples de résolution dans un prompt et entraîner un modèle à partir de résultats vérifiables ?
3. Pourquoi une récompense fondée sur la réponse finale ne garantit-elle pas la justesse de toutes les étapes ?
4. Que distingue une justification valide d’un compte rendu fidèle des éléments ayant influencé le modèle ? Un résumé affiché donne-t-il accès à tous les calculs du réseau ?
5. Que peut établir le calcul sur les bénévoles de Passerelle ? Quelles questions sur la cause de l’augmentation ou l’organisation future restent ouvertes ?

Le repère à conserver est le suivant : les étapes de résolution peuvent être utiles, mais leur valeur se juge par ce qu’elles permettent de vérifier. Ni leur longueur ni leur présentation comme un « raisonnement » ne suffisent à les valider.

La prochaine question : pourquoi se tromper avec assurance ?

Un modèle peut produire des étapes cohérentes, un calcul détaillé et une conclusion formulée avec confiance, tout en utilisant une donnée fausse ou une hypothèse injustifiée.

Le prochain chapitre expliquera pourquoi cette assurance apparente peut accompagner une erreur. Nous distinguerons plusieurs formes d’erreurs et les vérifications adaptées, sans supposer qu’un modèle plus bavard ou plus spécialisé en raisonnement les élimine toutes.

Chapitre précédent : Pourquoi la même question peut-elle produire des réponses différentes ?

Chapitre suivant : Pourquoi un modèle peut-il se tromper avec assurance ?

Revenir au sommaire de la formation