Tree-of-thought : exploration structurée

Tree-of-thought : exploration structurée

Le Tree-of-Thought (ToT) est une technique de prompting qui structure le raisonnement du modèle comme un arbre de décision. Au lieu de suivre un chemin de pensée unique et linéaire, le modèle explore plusieurs branches, évalue chacune d’elles et ne conserve que les plus prometteuses. La parenté avec un algorithme de recherche est directe : on génère des candidats, on les note, on élague. D’où son efficacité sur les problèmes qui demandent de la planification ou du backtracking.

Différence avec le Chain-of-Thought

Le Chain-of-Thought (CoT) suit un raisonnement linéaire : étape 1, étape 2, étape 3. Sa faiblesse est structurelle. Si le modèle s’engage dans une mauvaise direction à l’étape 2, tout ce qui suit hérite de l’erreur et il n’existe aucun mécanisme pour revenir en arrière — le raisonnement reste impeccablement articulé, simplement il part d’une prémisse fausse. Le Tree-of-Thought explore plusieurs directions à chaque étape et écarte les impasses avant d’avoir investi dans leur développement.

# Chain-of-Thought (linéaire)
# Étape 1 → Étape 2 → Étape 3 → Réponse

# Tree-of-Thought (arborescent)
#            Étape 1
#          /    |    \
#     Opt A  Opt B  Opt C    ← évaluation
#       |      |      ✗      ← élagage
#    Opt A1  Opt B1
#      |       |
#   Réponse  Réponse          ← sélection finale

Implémentation en un seul prompt

La version la plus simple tient dans un appel unique : le prompt impose au modèle la structure de l’exploration — générer trois approches, les évaluer, en retenir une, la développer. C’est peu coûteux et souvent suffisant pour dégrossir une question ouverte. Une limite est à connaître avant de s’y fier : le modèle propose et évalue dans le même souffle, ce qui le rend indulgent envers ses propres idées et rend l’élagage moins sévère qu’il ne devrait l’être.

from openai import OpenAI

client = OpenAI()

def tree_of_thought_simple(problem: str) -> str:
    """ToT en un seul prompt."""
    prompt = f"""Résous ce problème en utilisant l'approche Tree-of-Thought.

Problème : {problem}

Étape 1 - Génère 3 approches différentes :
- Approche A : ...
- Approche B : ...
- Approche C : ...

Étape 2 - Évalue chaque approche (forces et faiblesses) :
- Approche A : ...
- Approche B : ...
- Approche C : ...

Étape 3 - Sélectionne la meilleure approche et développe-la :
Approche retenue : ...
Développement détaillé : ...

Étape 4 - Réponse finale :
..."""

    response = client.responses.create(
        model="gpt-5.6-sol",
        input=prompt,
        temperature=0.7
    )
    return response.output_text

Implémentation multi-appels

Sur les problèmes complexes, séparez chaque étape en appels distincts. Le découpage vous apporte deux choses qu’un prompt unique ne peut pas offrir. D’abord un contrôle des températures étape par étape : 0.8 pour la génération, où la diversité des propositions fait tout l’intérêt de la méthode, puis 0.3 pour l’évaluation et le développement, où l’on attend au contraire de la rigueur et de la reproductibilité. Ensuite des résultats intermédiaires que vous pouvez inspecter, journaliser, voire soumettre à validation humaine avant de laisser la chaîne se poursuivre.

def tree_of_thought(problem: str, breadth: int = 3,
                    depth: int = 3) -> dict:
    """ToT avec exploration multi-niveaux."""
    system = "Tu es un expert en résolution de problèmes structurée."

    # Étape 1 : Générer les branches initiales
    gen_prompt = (f"Problème : {problem}\n\n"
                  f"Propose {breadth} approches différentes pour résoudre "
                  f"ce problème. Pour chaque approche, donne un titre et "
                  f"une description en 2-3 phrases. Numérote-les 1 à {breadth}.")

    branches_response = client.responses.create(
        model="gpt-5.6-terra",
        instructions=system,
        input=gen_prompt,
        temperature=0.8
    )
    branches = branches_response.output_text

    # Étape 2 : Évaluer chaque branche
    eval_prompt = (f"Problème : {problem}\n\n"
                   f"Voici {breadth} approches proposées :\n{branches}\n\n"
                   f"Évalue chaque approche sur 3 critères (note /10) :\n"
                   f"- Faisabilité\n- Efficacité\n- Simplicité\n\n"
                   f"Classe-les de la meilleure à la pire avec justification.")

    eval_response = client.responses.create(
        model="gpt-5.6-terra",
        instructions=system,
        input=eval_prompt,
        temperature=0.3
    )
    evaluation = eval_response.output_text

    # Étape 3 : Développer la meilleure branche
    dev_prompt = (f"Problème : {problem}\n\n"
                  f"Évaluation des approches :\n{evaluation}\n\n"
                  f"Développe l'approche la mieux classée en détail. "
                  f"Fournis une solution complète et actionnable.")

    solution = client.responses.create(
        model="gpt-5.6-terra",
        instructions=system,
        input=dev_prompt,
        temperature=0.3
    )

    return {
        "branches": branches,
        "évaluation": evaluation,
        "solution": solution.output_text
    }

Cas d’usage concret : architecture logicielle

Le problème ci-dessous est exactement celui où le ToT apporte quelque chose. Plusieurs stratégies sont défendables — cache, réplicas de lecture, extraction du service de recherche, déploiement blue-green —, et le choix dépend de contraintes que le prompt énonce noir sur blanc, notamment la taille de l’équipe. Un prompt direct vous rendrait la solution la plus souvent citée dans la littérature technique, indépendamment de ces contraintes ; le ToT la met en concurrence avec les autres et doit défendre son classement sur des critères de faisabilité.

problem = """
Notre API REST monolithique (Django, PostgreSQL) atteint ses limites :
- 500 requêtes/seconde max
- Temps de réponse > 2s sur les endpoints de recherche
- Déploiement = 30 minutes de downtime
- 3 développeurs dans l'équipe

Comment améliorer les performances et la disponibilité
sans réécrire toute l'application ?
"""

result = tree_of_thought(problem, breadth=4)
print(result["solution"])

Où le ToT gagne, où il vous fait perdre du temps

La technique donne le meilleur d’elle-même sur les problèmes de planification — architecture, roadmap, stratégie —, sur les problèmes sous contraintes comme l’optimisation ou l’allocation de ressources, sur le debugging complexe où plusieurs causes restent plausibles simultanément, et sur les décisions techniques du type choix de framework ou de base de données. Le point commun de ces situations est double : il existe plusieurs solutions valables, et il existe un critère explicite pour les départager.

À l’inverse, écartez-le sur les questions factuelles simples, où il n’y a rien à explorer et où vous payeriez trois appels pour une réponse évidente. Il ne fonctionne pas davantage sur les tâches créatives ouvertes, faute de critère d’évaluation défendable : classer trois slogans publicitaires sur une échelle de faisabilité n’a aucun sens. Renoncez-y enfin lorsque la latence est critique, puisque la version multi-appels enchaîne mécaniquement plusieurs requêtes API avant de rendre quoi que ce soit.

Combiner avec le réglage de raisonnement

En réglage de raisonnement élevé, les modèles GPT-5.6 effectuent déjà une exploration interne structurée. Le ToT explicite devient alors largement redondant et vous facture deux fois le même travail. Réservez-le aux situations où le raisonnement est désactivé ou faible, comme dans la comparaison ci-dessous.

# En raisonnement faible : ToT explicite utile
result = tree_of_thought(problem, breadth=3)

# En raisonnement élevé : le modèle raisonne déjà en profondeur
response = client.responses.create(
    model="gpt-5.6-sol",
    input=problem,
    reasoning={"effort": "high"}
)

Pour trancher dans votre propre contexte, prenez un problème d’architecture ou de design que vous avez réellement sur les bras cette semaine, passez-le par le ToT multi-appels avec breadth=3, puis soumettez-le tel quel dans un prompt direct. Comparez les deux solutions et, surtout, le coût en tokens de chacune. Sur une décision engageante, l’écart de qualité paie largement le surcoût ; sur une question secondaire, il ne le paie pas, et le savoir vous évitera d’appliquer la technique partout par habitude.

Points clés à retenir

• Le ToT explore plusieurs chemins de raisonnement et sélectionne le meilleur
• Version simple en un prompt ou version avancée en multi-appels
• Idéal pour la planification, l’architecture et le debugging complexe
• En raisonnement élevé, les modèles GPT-5.6 ont déjà un ToT implicite
• Le surcoût en tokens est justifié pour les décisions à fort impact