Tree of Thoughts: Wenn ein Pfad nicht reicht

Tree of Thoughts (ToT) ist ein Reasoning-Verfahren für Sprachmodelle, das statt eines einzelnen, linearen Gedankengangs mehrere Reasoning-Pfade parallel generiert, bewertet und per Suche (BFS oder DFS) mit Backtracking verfolgt. So kann das Modell Sackgassen erkennen, zurückspringen und Alternativen prüfen, statt an einer einmal getroffenen Fehlannahme festzuhängen. Vorgestellt wurde das Verfahren von Yao et al. im Paper "Tree of Thoughts: Deliberate Problem Solving with Large Language Models" (arXiv:2305.10601, Mai 2023, NeurIPS 2023).

• Was ist neu? ToT modelliert das Schließen als bewusste, suchgesteuerte "System-2"-Exploration über einen Baum von Zwischenzuständen statt als eine einzige Gedankenkette.
• Wann nötig? Immer dann, wenn ein einzelner Pfad nicht reicht: bei Puzzles, Planung mit Sackgassen und Aufgaben, die Lookahead und Backtracking erfordern.
• Was kostet es? Grob die 50- bis 150-fache Token-Menge eines einzelnen Chain-of-Thought-Aufrufs, plus deutlich höhere Latenz.

Warum ein einzelner Pfad oft nicht reicht

Chain of Thought (CoT) hat die Reasoning-Qualität von Sprachmodellen deutlich verbessert, indem das Modell seine Zwischenschritte explizit ausschreibt. Der Haken: CoT verläuft strikt von links nach rechts und kann nicht zurückspringen. Sobald das Modell früh eine falsche Annahme trifft, schleppt es diesen Fehler durch den gesamten restlichen Gedankengang.

Bei vielen Aufgaben fällt das kaum ins Gewicht. Bei Problemen, die echte Suche und Vorausschau verlangen, kollabiert CoT jedoch. Das klassische Beispiel aus dem Paper ist das Zahlenspiel "Game of 24" (aus vier Zahlen mit den Grundrechenarten 24 bilden). Hier muss man Kombinationen ausprobieren, Sackgassen erkennen und alternative Rechenwege wählen. Genau das kann eine lineare Kette nicht leisten: Im Paper erreichte CoT mit GPT-4 hier nur 4 Prozent Erfolg.

Tree of Thoughts adressiert dieses strukturelle Defizit. Statt einer Kette baut es einen Baum auf, in dem jeder Knoten eine partielle Lösung ist, jede Verzweigung eine alternative Fortsetzung und jedes Blatt entweder eine Lösung oder eine Sackgasse darstellt.

Die vier Designentscheidungen von ToT

Das ToT-Paper beschreibt vier modulare Bausteine, über die jede konkrete ToT-Implementierung entscheiden muss:

1. Thought-Dekomposition — Wie wird das Problem in einzelne "Thoughts" zerlegt? Ein Thought kann ein Rechenschritt, ein Absatzplan oder ein einzelnes Kreuzworträtsel-Wort sein.
2. Thought-Generator — An einem Zustand werden k Kandidaten für den nächsten Gedanken vorgeschlagen oder gesampelt.
3. State-Evaluator — Jeder Kandidat wird bewertet, entweder unabhängig (im Paper über Votes wie sure/maybe/impossible, je dreifach gesampelt) oder über relatives Ranking.
4. Suchalgorithmus — BFS (die besten b Kandidaten pro Ebene, im Paper Standard b=5) oder DFS mit Backtracking durchläuft den Baum.

Die konzeptionelle Inspiration zieht das Paper explizit aus der Problemlöseforschung von Newell und Simon aus den 1950er-Jahren: bewusstes, suchgesteuertes Schließen statt assoziativer Einzelantwort.

Schematisches Beispiel: ToT-Schleife als Pseudocode

Der folgende Pseudocode zeigt eine BFS-Variante mit Breite b und Tiefe d. Er ist als Veranschaulichung gedacht, nicht als lauffähige Implementierung.

```
frontier = [Wurzel(problem)] # Liste aktiver Zustaende
for tiefe in range(d): # z.B. d = 3 Schritte
kandidaten = []
for zustand in frontier:
for _ in range(k): # k Vorschlaege pro Zustand
t = generator(zustand) # naechster Thought
kandidaten.append(zustand + t)
bewertet = [(evaluator(c), c) for c in kandidaten]
# Sackgassen (impossible) verwerfen -> implizites Backtracking
bewertet = [x for x in bewertet if x[0] != "impossible"]
frontier = top_b(bewertet, b=5) # nur die besten b weiterverfolgen
loesung = beste(frontier)
```

Entscheidend sind zwei Stellen. Erstens die Verzweigung: Pro Zustand entstehen k Kandidaten, der Baum wird breit. Zweitens das top_b-Pruning in Kombination mit dem Verwerfen von impossible-Knoten: Schlecht bewertete Pfade werden abgeschnitten, und die Suche konzentriert die Rechenleistung auf die aussichtsreichen Zweige. Bei DFS tritt das Backtracking explizit auf: Erweist sich ein Pfad als Sackgasse, kehrt die Suche zum letzten vielversprechenden Knoten zurück.

Kosten und Nutzen: ToT gegen CoT

Der Nutzen von ToT ist auf den richtigen Aufgaben erheblich, der Preis aber ebenfalls. Die folgenden Zahlen stammen aus dem ToT-Paper (GPT-4, Bedingungen wie im Paper) und sind als relative Effektgrößen zu lesen, nicht als heutige Absolutwerte.

Diesen Qualitätsgewinnen steht ein massiver Mehraufwand gegenüber. Die folgende Tabelle ordnet ToT in das Spektrum gängiger Agent-Reasoning-Muster ein; die Token-Werte sind grobe Größenordnungen relativ zu einem einzelnen CoT-Aufruf (= 1), synthetisiert aus den Paper-Angaben und Feldberichten und auf der eigenen Last zu messen.

Im Game of 24 verbrauchte ToT laut Paper rund 5.500 Tokens pro Fall gegenüber wenigen hundert bei CoT. Die Latenz ist strikt schlechter als bei CoT, weil sie proportional zu Verzweigung, Tiefe und Sample-Rate wächst.

Die Qualität steht und fällt mit dem Generator

Ein zentraler Befund aus der Research: ToT hebt nicht jedes Modell. Die Wirkung wird vom Generator-Modell dominiert. Im Game of 24 erreichte GPT-4 mit ToT 74 Prozent, GPT-3.5 mit ToT dagegen nur 19 Prozent. Die Paper-Analyse trennt die Rollen sauber: GPT-4 als Generator plus GPT-3.5 als Evaluator ergaben 64 Prozent, in umgekehrter Konstellation (GPT-3.5 generiert, GPT-4 bewertet) nur 31 Prozent.

Noch deutlicher zeigt es ein Stanford-CS224N-Projekt: Mixtral-8x7B löste keines der zehn einfachsten Game-of-24-Puzzles, weil das Modell Zahlen halluzinierte und an einfacher Arithmetik scheiterte, was den Evaluator wertlos machte. Für die Praxis heißt das: ToT auf einem schwachen Modell verbrennt Budget, ohne das Problem zu lösen.

Wann ToT (nicht) einsetzen

Aus der Research ergeben sich klare Leitplanken für 2026.

ToT eignet sich, wenn:

• die Aufgabe Suchcharakter hat, also Lookahead, Verzweigung und potenzielle Sackgassen aufweist (Puzzles, Optimierung, Scheduling, Planung).
• ein verlässliches Bewertungssignal existiert, am besten mit verifizierbaren Belohnungen.
• ein Audit-Trail über die geprüften Alternativen gefordert ist, etwa in regulierten DACH-Branchen unter GDPR oder EU AI Act.
• bewusst ein kleines, günstiges Proposer-Modell genutzt wird, dessen schwächeres Einzelresultat durch Suche kompensiert werden soll.

ToT eignet sich nicht, wenn:

• das eingesetzte Modell die Antwort ohnehin in einem Schritt liefern kann.
• die Anwendung latenzsensitiv ist (etwa Live-Chat).
• kein klarer Evaluator vorhanden ist; ohne gutes Bewertungssignal verpufft die Suche.

Die wichtigste Einordnung aus der Research: Für allgemeines Reasoning ist explizites ToT weitgehend überholt, weil moderne Reasoning-Modelle die Baumsuche intern abbilden. ToT bleibt deshalb primär als konzeptionelle Grundlage für tree-strukturierte Agentensuche relevant und in den genannten Spezialfällen.

Vom Verfahren zum Agenten: LATS

Wer ToT in einem Agenten-Stack braucht, greift heute meist nicht zu reinem ToT, sondern zum Nachfolger LATS (Language Agent Tree Search, Zhou et al., arXiv:2310.04406). LATS kombiniert die Baumexpansion von ToT mit Self-Reflection (im Sinne von Reflexion) und Monte-Carlo-Tree-Search. In LangGraph existiert dafür ein offizielles Tutorial; ein dediziertes ToT-only-Tutorial gibt es dort nicht. Der LangChain-Blog argumentiert, dass LATS gegenüber vergleichbaren Algorithmen wie Tree of Thoughts, ReAct und Reflexion besser abschneidet. Für die Framework-Einordnung gilt: In CrewAI ist ToT nicht idiomatisch (sequenziell/hierarchisch), in AutoGen über einen Selector Group Chat aufwendig umsetzbar, und in n8n wegen der kombinatorischen Explosion nicht realistisch, abgesehen von Best-of-N-Sampling (ToT mit Tiefe 1).

Für Agenturen und B2B-Entscheider

Für Marketing-Agenturen und DACH-B2B-Teams ist die Botschaft pragmatisch: Tree of Thoughts ist kein Standardwerkzeug für den Alltag, sondern ein Spezialinstrument. In der überwiegenden Zahl der Kundenprojekte (Chatbots, Content-Pipelines, Recherche-Workflows) sind günstigere Muster wie ReAct oder ReWOO die bessere Wahl. ToT oder sein Nachfolger LATS rechnen sich nur dort, wo ein einzelner Lösungspfad nachweislich nicht ausreicht, etwa bei constraint-lastigem Copywriting, Optimierungsaufgaben oder regulierten Prozessen, die einen prüfbaren Such-Trail über verworfene Alternativen verlangen. Wer ToT erwägt, sollte vorab zwei Dinge sicherstellen: ein leistungsfähiges Generator-Modell und ein belastbares Bewertungssignal. Fehlt eines davon, vervielfachen sich die Token-Kosten ohne Gegenwert. Blck Alpaca unterstützt bei genau dieser Entscheidung, also der nüchternen Auswahl des passenden Reasoning-Musters und der sauberen Kosten-Nutzen-Abwägung, bevor in der Produktion Budget verbrannt wird.