Chain of thought : quand passer à Tree of Thoughts ?

Tree of Thoughts va au-delà du chain of thought : ses appels supplémentaires au modèle se justifient lorsqu’on peut évaluer des solutions partielles avant de les achever. Dans le budget illustratif présenté plus bas, une recherche pourtant limitée fait passer de 1 appel de référence à 21 appels. Commencez par établir une référence avec un modèle de raisonnement, puis ajoutez des branches uniquement pour les échecs qu’une recherche peut corriger.

Sources vérifiées le 24 octobre 2026. Les résultats des benchmarks ci-dessous proviennent exclusivement de l’article scientifique original de 2023 de Shunyu Yao et de ses collègues. Les branches détaillées et les budgets d’appels au modèle sont des calculs explicatifs, pas des résultats mesurés en production.

Comment fonctionne la recherche avec Tree of Thoughts ?

Tree of Thoughts (ToT) permet à une application de comparer des solutions inachevées pour décider lesquelles méritent d’être approfondies. Un grand modèle de langage, ou LLM, propose les étapes suivantes ; un évaluateur juge les états obtenus ; une procédure de recherche détermine ce qu’il faut conserver, développer ou abandonner. Yao et ses collègues ont présenté ce cadre en mai 2023. Méthode de l’article original.

Imaginez que vous cherchiez votre chemin dans un bâtiment. À une intersection, vous pouvez examiner plusieurs couloirs avant de vous engager. Inutile de consacrer davantage d’efforts à un passage bloqué. Une voie plausible reste disponible pendant que vous en explorez une autre. L’intérêt est de pouvoir changer de direction tant que cela coûte encore peu.

Une pensée, ou thought, est une unité de travail intermédiaire utile : une équation, un mot proposé pour une grille de mots croisés ou un plan de rédaction, par exemple. Un état contient le problème initial et la solution partielle construite jusque-là. L’unité choisie doit être assez consistante pour être évaluée, mais assez petite pour qu’explorer des alternatives ait un intérêt.

La boucle repose sur trois opérations explicites :

• Créer des branches : proposer des étapes suivantes distinctes à partir de l’état courant.
• Évaluer : vérifier chaque état obtenu au regard des contraintes et de ses chances d’aboutir à une réponse valide.
• Élaguer : cesser de développer les états rejetés et consacrer le budget restant aux candidats les plus prometteurs.

L’article associe ces opérations à la recherche en largeur, qui conserve les candidats prometteurs d’un même niveau, et à la recherche en profondeur, qui suit une branche et peut revenir en arrière en cas d’échec. Le choix de la procédure dépend de la tâche. Aucune des deux n’impose d’entraîner un nouveau modèle. Cadre et algorithmes de recherche.

Pour qui développe une application, le changement essentiel est de pouvoir piloter les alternatives intermédiaires. Demander au modèle de donner une impression de réflexion ne donne pas ce contrôle à l’application.

Chain of thought et Tree of Thoughts : quelle différence ?

Tout se joue dans le moment où l’on compare les alternatives : pendant la construction d’une solution ou après avoir produit des réponses complètes.

C’est la distinction exposée dans les fondements et la méthode de Yao et ses collègues. La self-consistency standard échantillonne des chaînes complètes et retient la réponse la plus fréquente. Il faut donc pouvoir reconnaître de manière pertinente les réponses équivalentes ; faire voter sur un texte libre est moins simple que sur un résultat numérique.

Le prompting chain-of-thought peut aider à expliciter le travail intermédiaire. La self-consistency apporte de la diversité entre les tentatives menées à terme. ToT ajoute un contrôleur capable d’arrêter une piste peu prometteuse avant de payer le coût de son achèvement. Ce contrôleur introduit aussi un nouveau risque : élaguer une piste qui aurait abouti.

Deux techniques proches répondent à d’autres besoins. Le prompting few-shot fournit des exemples du comportement ou du format de sortie attendu ; il peut donc aider un générateur ou un évaluateur à respecter ses spécifications. Le prompt chaining relie des étapes, comme l’extraction de faits puis la rédaction d’une réponse. Une suite fixe d’étapes ne devient une recherche que si elle maintient plusieurs alternatives et décide lesquelles explorer.

Choisissez la structure la plus simple qui corrige l’échec observé. Un format irrégulier appelle des exemples plus clairs ou une validation. Des éléments factuels manquants appellent une récupération d’informations. Aucun de ces problèmes ne justifie automatiquement un arbre.

Exemple pas à pas : créer des branches, évaluer et élaguer

Une équation intermédiaire correcte peut tout de même mener à une impasse. C’est précisément ce que l’évaluateur doit savoir distinguer.

Reprenons l’exemple du jeu du 24 utilisé dans l’article : avec 4, 9, 10 et 13, employés chacun exactement une fois, il faut obtenir 24 à l’aide des opérations arithmétiques de base. Le déroulé ci-dessous a été construit pour expliquer le mécanisme ; il ne s’agit pas de la transcription d’un échange avec un modèle. Les états viables et impossibles ont été vérifiés en énumérant les combinaisons arithmétiques restantes. Données de l’exemple dans l’article.

1. 1

   Créer des branches à partir de l’état initial

   Le candidat A calcule 4 + 9 = 13 ; il reste 10, 13, 13.

   Le candidat B calcule 13 - 9 = 4 ; il reste 4, 4, 10.

   Les deux calculs respectent les règles. Les nombres répétés correspondent à des valeurs restantes distinctes ; l’état doit conserver cette multiplicité.

2. 2

   Évaluer les états obtenus

   Le candidat A ne peut pas atteindre 24 en utilisant chaque valeur restante une seule fois avec l’addition, la soustraction, la multiplication ou la division. Cette branche est élaguée.

   Le candidat B admet une suite valide : soustraire de 10 l’un des 4 restants, puis multiplier par l’autre 4. Cette branche est conservée.

   Cet exemple s’appuie sur une vérification arithmétique exacte pour rendre le jugement contrôlable. Dans l’article, la recherche utilisait des estimations de valeur produites par le modèle, qui peuvent être erronées.

3. 3

   Développer la branche conservée

   À partir de 4, 4, 10, on peut envisager 4 + 4 = 8, qui laisse 8, 10, ou 10 - 4 = 6, qui laisse 4, 6.

   Le premier état ne peut pas atteindre 24 avec l’opération restante. Le second le peut : 4 × 6 = 24. On conserve cette suite, puis on vérifie l’expression complète.

4. 4

   Vérifier la réponse finale

   (13 - 9) × (10 - 4) = 24 utilise chaque nombre initial une fois et donne bien le résultat recherché. La recherche s’arrête parce que la solution satisfait le contrôle prévu pour la tâche.

Pour ce petit problème, un solveur exhaustif peut tout faire ; ajouter un LLM compliquerait inutilement l’implémentation. L’exemple sert à comprendre la boucle. Dans une application, la répartition utile consiste souvent à laisser le modèle proposer des plans plausibles et le code vérifier les contraintes que le modèle ne devrait pas avoir à deviner.

Quels résultats l’article sur Tree of Thoughts a-t-il obtenus ?

Les résultats originaux montrent qu’une recherche délibérée a aidé sur les tâches choisies par les auteurs. Ils ne permettent pas de déduire le gain à attendre sur une charge de travail actuelle en production.

Pour le jeu du 24, les auteurs ont évalué GPT-4 sur 100 problèmes relativement difficiles. Les expériences ont eu lieu en mai 2023. Le tableau 2 présente les taux de réussite suivants :

Source : Yao et ses collègues, tableau 2 et configuration du jeu du 24.

La largeur désigne le nombre d’états conservés, pas le nombre d’appels au modèle. Générer les candidats et les évaluer demande du travail supplémentaire. Dans la configuration du jeu du 24, les auteurs échantillonnaient trois fois la valeur de chaque candidat. Protocole expérimental.

L’article étudiait aussi la rédaction créative et les mini-grilles de mots croisés. Ce sont des tâches différentes, avec des méthodes d’évaluation distinctes. La conclusion pratique est plus précise que « ToT améliore les modèles » : la recherche peut aider lorsqu’une orientation intermédiaire prometteuse compte et peut être évaluée. Avant d’ajouter le contrôleur, il reste nécessaire de disposer de preuves propres aux tâches de l’application.

Combien d’appels au modèle les branches ajoutent-elles ?

Comptez séparément la génération, l’évaluation et la finalisation. L’évaluateur peut consommer davantage d’appels que le générateur de candidats.

Prenons une recherche bornée à titre d’illustration, indépendamment de la configuration de l’article. Un appel désigne une requête au modèle émise par l’application. Supposons qu’un appel de proposition génère tous les enfants d’un parent, tandis que chaque enfant fait l’objet de son propre appel d’évaluation. La recherche s’arrête à la profondeur choisie, sans nouvelle tentative ni arrêt anticipé, puis un dernier appel produit la réponse.

Fixons trois enfants par parent développé, deux états conservés après chaque niveau et trois niveaux à explorer. Les nombres de parents développés sont 1, 2 et 2. On obtient donc :

• Génération : 1 + 2 + 2 = 5 appels.
• Évaluation : 3 × (1 + 2 + 2) = 15 appels.
• Réponse finale : 1 appel.
• Total : 5 + 15 + 1 = 21 appels, soit 21× la référence à 1 appel.

Si l’on répète trois fois l’évaluation de chaque candidat, le même arbre passe à 5 + 45 + 1 = 51 appels. Si l’on regroupe toutes les évaluations des candidats d’un niveau dans une seule requête, il passe à 5 + 3 + 1 = 9 appels. Le regroupement modifie le contexte et les conditions de jugement de l’évaluateur ; c’est une option d’implémentation, pas une garantie de qualité équivalente.

À titre de comparaison, la self-consistency avec cinq échantillons demandés séparément utilise cinq appels au modèle si le vote final est assuré par du code déterministe. Ajouter un modèle juge entraînerait des appels supplémentaires et modifierait cette comparaison.

La règle générale de comptage est C = Σ nₜ(g + kv) + f. Ici, nₜ est le nombre de parents développés au niveau t, g le nombre de requêtes de génération par parent, k le nombre d’enfants par parent, v le nombre de requêtes d’évaluation par enfant et f le nombre de requêtes de finalisation. Cette formule suppose que les enfants sont évalués séparément ; si vous regroupez leurs évaluations, comptez directement les requêtes correspondantes.

Comment piloter un arbre de raisonnement avec un LLM ?

Conservez l’état de la recherche et les règles d’arrêt dans le code de l’application. Confiez au modèle la proposition et l’évaluation d’éléments délimités que vous pouvez examiner.

La limite de cette architecture est la qualité de l’évaluateur. S’il ne sait pas distinguer une solution partielle viable d’une impasse convaincante, développer davantage de branches lui donne simplement plus d’occasions de se tromper.

1. 1

   Définir un état que l’on peut inspecter

   Pour une fonctionnalité de planification sous contraintes, l’état peut contenir les tâches affectées, celles qui restent à affecter, les créneaux occupés et les contraintes non satisfaites. La pensée suivante correspond alors à une proposition d’affectation. Stockez séparément l’état, l’identifiant du candidat, celui du parent et les éléments qui étayent la proposition.

   Choisissez un résultat intermédiaire vérifiable au stade actuel. Un paragraphe vague qui affirme disposer d’une bonne stratégie se prête mal à un élagage fiable.

2. 2

   Distinguer le rôle du générateur de celui de l’évaluateur

   Une consigne au générateur peut être : « Propose des affectations suivantes distinctes à partir de cet état. Pour chaque candidat, renvoie l’affectation et l’état mis à jour. Respecte les contraintes indiquées. »

   Une consigne à l’évaluateur peut être : « Vérifie chaque candidat au regard des contraintes. Renvoie son identifiant, toute contrainte enfreinte et précise si la poursuite est possible, incertaine ou exclue. Cite les champs de l’état qui justifient ce jugement. »

   Commencez par des contrôles déterministes pour les règles comme le chevauchement des créneaux ou l’absence de champs obligatoires. Si vous avez besoin du jugement d’un modèle, validez-le sur des cas connus à l’aide d’un processus d’évaluation LLM-as-a-judge.

3. 3

   Expliciter l’élagage et le budget

   Rejetez les états qui enfreignent une contrainte impérative. Classez les candidats restants, limitez le nombre d’états en attente d’exploration et éliminez les doublons. Gardez les candidats incertains disponibles lorsque le budget le permet : une faible confiance de l’évaluateur ne prouve pas qu’une branche est impossible.

   Faites respecter par le contrôleur des limites de requêtes, de profondeur, de tokens et de temps écoulé. Incluez les évaluations et les nouvelles tentatives dans ces limites. Consignez les états écartés et les motifs du rejet afin de pouvoir analyser les cas où l’élagage a supprimé la voie qui aurait réussi.

4. 4

   Vérifier avant d’accepter ou d’agir

   Utilisez un contrôle final, par exemple la satisfaction de toutes les contraintes de planification ou la réussite des tests logiciels pertinents. Si aucun candidat ne satisfait ce contrôle avant l’épuisement du budget, renvoyez un résultat non résolu ou transmettez-le pour examen.

   Limitez l’exploration des branches à un environnement isolé ou à des propositions d’action. Une branche de planification encore hypothétique ne doit pas envoyer d’invitations. Une branche de code ne doit pas déployer de changements pendant que le contrôleur compare encore les candidats.

Évaluez l’évaluateur autant que la réponse finale. Un rejet erroné peut supprimer définitivement la branche utile. Une acceptation erronée peut épuiser le reste du budget à développer une impasse. Ces deux échecs appellent des corrections différentes.

Quand un modèle de raisonnement rend-il ToT superflu ?

Un ToT externe est superflu lorsqu’un modèle de raisonnement satisfait déjà vos exigences de qualité et de latence, et que l’application n’a pas besoin de piloter les alternatives intermédiaires.

Un modèle de raisonnement effectue un travail interne avant de répondre. Les recommandations actuelles d’Anthropic en matière de prompting préconisent de donner à ses modèles de raisonnement des objectifs généraux plutôt que de prescrire chaque étape de réflexion. Cela invite à commencer par une tâche claire, des contraintes et des critères d’acceptation. Cela ne démontre pas qu’un modèle donné implémente en interne l’algorithme ToT de Yao et de ses collègues. Recommandations de prompting d’Anthropic.

Pour ajouter une petite transformation de code, commencez par essayer un modèle de raisonnement adapté et soumettez son résultat aux tests pertinents. Si cette approche de référence satisfait le critère de mise en production, un arbre externe ajoute de la gestion d’état, de l’évaluation et du traitement des échecs sans bénéfice établi.

Envisagez une recherche externe lorsque l’application peut apporter quelque chose de plus : un simulateur, un vérificateur de contraintes, des environnements de test isolés ou la nécessité de conserver plusieurs plans candidats distincts. Un modèle plus performant peut toujours jouer le rôle de générateur dans cette recherche. Le raisonnement du modèle et la recherche pilotée par l’application sont deux choix de conception distincts.

La décision se prend sur les résultats : ne conservez l’arbre que s’il améliore suffisamment les résultats vérifiés pour justifier les ressources mesurées qu’il consomme. Une réponse plus longue ou une trace plus élaborée ne constitue pas le critère de réussite.

Tree of Thoughts : quelles promesses sont exagérées ?

Un prompt qui demande à des experts imaginaires de débattre ne fournit pas, à lui seul, une recherche en arbre contrôlée. Il peut produire des alternatives, mais une implémentation ToT en production exige un état explicite, une évaluation, une sélection des branches et une politique d’arrêt. Si tout cela existe uniquement à l’intérieur d’une seule génération, rien ne garantit que la recherche décrite a été exécutée comme prévu.

L’autre exagération consiste à affirmer que davantage de branches garantit une meilleure réponse. Plusieurs branches peuvent répéter la même idée. Le juge peut partager l’hypothèse erronée du générateur. Un élagage précoce peut supprimer la seule suite utile. Un ton assuré ne remplace pas une vérification adaptée à la tâche.

Enfin, le meilleur résultat de l’article sur le jeu du 24 ne prouve pas que tous les workflows métier ont besoin de ToT. Un extracteur de documents dont la sortie ne respecte pas le schéma peut avoir besoin de meilleurs exemples et d’une validation. Un assistant de support auquel il manque une règle peut avoir besoin de la bonne source. Explorer davantage de chemins avec les mêmes informations manquantes ne fait pas apparaître le fait absent.

Utilisez la recherche pour explorer des décisions alternatives que vous pouvez évaluer. Corrigez directement le contexte manquant et le non-respect des spécifications.

Que changer dans votre application cette semaine ?

Passez à l’action si vos cas d’échec comportent des choix initiaux rattrapables et si vous disposez d’un moyen crédible d’évaluer les états intermédiaires. Il peut s’agir de modifications de code candidates vérifiées dans des environnements isolés ou de plans testés contre des contraintes de planification explicites. Commencez par un traitement ciblé de ces cas, avec un budget de recherche fixe.

Attendez si vous ne savez pas encore expliquer pourquoi une solution partielle est meilleure qu’une autre. Constituez un ensemble d’états acceptables et inacceptables, vérifiez les décisions de l’évaluateur et améliorez son jugement avant d’élargir l’arbre.

Vous êtes peu concerné si le workflow consiste en une extraction simple, une classification ou une séquence fixe qui satisfait déjà ses critères d’acceptation. Conservez sa structure plus simple.

L’action à mener dès lundi est concrète : prenez des échecs de votre workflow chain-of-thought actuel et comparez une référence fondée sur un modèle de raisonnement à une variante ToT bornée, sur les mêmes tâches réservées à l’évaluation. Gardez le vérificateur final inchangé. Relevez les résultats acceptés, les appels au modèle, les tokens, la latence et les cas où l’élagage a supprimé une voie qui aurait réussi. N’adoptez la recherche que pour les catégories de tâches où ces résultats la justifient.

Questions fréquentes sur Tree of Thoughts

Le raisonnement et le chain-of-thought désignent-ils la même chose ?

Le raisonnement est la capacité plus générale à résoudre un problème en réfléchissant. Le chain-of-thought est une approche de prompting qui utilise des étapes intermédiaires. Un modèle peut raisonner en interne sans afficher ces étapes dans sa réponse.

Qu’est-ce qu’un arbre en IA ?

Un arbre représente des états et les actions suivantes possibles. Un nœud correspond à un état ; ses enfants représentent les alternatives obtenues en effectuant une étape supplémentaire. Dans ToT, ces états sont des solutions partielles.

Qu’est-ce qu’un arbre de raisonnement ?

Dans ce contexte, il s’agit d’organiser des solutions partielles alternatives en branches, de les évaluer et de choisir lesquelles poursuivre. Le cadre précis proposé par Yao et ses collègues s’appelle Tree of Thoughts.

Qu’est-ce que le prompting tree of thought ?

Cette approche utilise un modèle de langage pour proposer et évaluer des alternatives intermédiaires, associé à une procédure de recherche qui sélectionne les états à développer. Son intérêt pratique est de pouvoir revenir sur une décision avant de terminer la réponse entière.

Quels sont les trois C du prompting ?

L’algorithme ToT de Yao et de ses collègues ne définit pas de règle des trois C. Ce moyen mnémotechnique n’en constitue pas la spécification ; l’article décrit la décomposition en pensées, leur génération, l’évaluation des états et la recherche.

Quelles sont les principales différences entre une chaîne de pensée et un arbre de pensées ?

Le CoT standard produit un seul parcours de raisonnement continu. ToT envisage explicitement plusieurs parcours partiels et les évalue pendant la recherche. La self-consistency procède encore autrement : elle échantillonne des parcours complets et agrège les réponses finales.

Quel serait un exemple de prompting chain-of-thought ?

Une démonstration arithmétique détaillée pourrait montrer 13 - 9 = 4, puis 10 - 4 = 6, puis 4 × 6 = 24. Fournir ces étapes intermédiaires à titre d’exemple illustre le CoT. Comparer plusieurs étapes possibles et décider quelle branche conserver ajoute le mécanisme de recherche ToT.

Comment expliquer simplement le chain-of-thought ?

Il relie une question à sa réponse par des étapes intermédiaires, comme des calculs ou des déductions. Ces étapes peuvent faciliter la compréhension de la tâche, mais elles peuvent aussi contenir des erreurs.

Comment fonctionne concrètement le chain-of-thought ?

Dans la configuration de prompting standard, le modèle génère une suite d’étapes intermédiaires à partir du problème et du texte déjà produit, puis fournit une réponse. Cette suite ne comporte, à elle seule, ni vérification indépendante de l’exactitude ni ensemble d’états à explorer géré par l’application.

Abonnez-vous à la newsletter pour recevoir des guides pratiques sur la création de workflows IA fiables.