Tree of Thoughts: Wann sich die KI-Suche lohnt

Tree of Thoughts lohnt die zusätzlichen Modellaufrufe dann, wenn sich Teillösungen schon vor ihrem Abschluss bewerten lassen. Selbst eine kleine Suche kann aus einer Basisvariante mit 1 Aufruf insgesamt 21 Aufrufe machen, wie die Beispielrechnung weiter unten zeigt. Ausgangspunkt sollte deshalb ein Reasoning-Modell sein. Zusätzliche Suchzweige lohnen sich erst bei Fehlern, die sich durch die Suche tatsächlich beheben lassen.

Quellen geprüft am 24. Oktober 2026. Die folgenden Benchmark-Ergebnisse stammen ausschließlich aus der Originalveröffentlichung von 2023 von Shunyu Yao und Kollegen. Die durchgerechneten Suchzweige und Budgets für Modellaufrufe dienen der Veranschaulichung; sie sind keine berichteten Ergebnisse aus dem Produktivbetrieb.

Wie funktioniert die Suche mit Tree of Thoughts?

Mit Tree of Thoughts (ToT) kann eine Anwendung unfertige Lösungen vergleichen und entscheiden, welche davon weiterverfolgt werden sollen. Ein großes Sprachmodell, kurz LLM, schlägt nächste Schritte vor. Ein Evaluator bewertet die daraus entstehenden Zustände. Ein Suchverfahren entscheidet, welche Zustände erhalten bleiben, erweitert oder verworfen werden. Yao et al. stellten dieses Verfahren im Mai 2023 vor. Originalveröffentlichung: Methode.

Das lässt sich mit der Wegsuche in einem Gebäude vergleichen. An einer Abzweigung können mehrere Gänge geprüft werden, bevor die Entscheidung fällt. Ein versperrter Gang sollte keine weitere Arbeit verursachen. Ein aussichtsreicher bleibt eine Option, während ein anderer untersucht wird. Der Vorteil liegt darin, den Kurs zu ändern, solange das noch wenig Aufwand kostet.

Ein Gedanke ist dabei eine sinnvolle Einheit der Zwischenarbeit: etwa eine Gleichung, ein vorgeschlagenes Kreuzworträtselwort oder ein Schreibplan. Ein Zustand hält die ursprüngliche Aufgabe und die bisherige Teillösung fest. Die Einheit muss groß genug sein, um sie bewerten zu können, und klein genug, damit es sich lohnt, Alternativen auszuprobieren.

Die Schleife besteht aus drei erkennbaren Schritten:

• Verzweigen: Vom aktuellen Zustand aus unterschiedliche nächste Schritte vorschlagen.
• Bewerten: Jeden daraus entstehenden Zustand auf die Einhaltung der Vorgaben und seine Aussichten auf eine gültige Lösung prüfen.
• Beschneiden: Verworfene Zustände nicht weiter ausbauen und das verbleibende Budget für aussichtsreichere Kandidaten einsetzen.

Die Veröffentlichung verbindet diese Schritte mit Breitensuche und Tiefensuche. Die Breitensuche hält vielversprechende Kandidaten auf derselben Ebene vor. Die Tiefensuche folgt einem Zweig und kann zurückgehen, wenn dieser scheitert. Welches Suchverfahren passt, hängt von der Aufgabe ab. Für keines der beiden muss ein neues Modell trainiert werden. Verfahren und Suchalgorithmen.

Für die Entwicklung zählt vor allem die Kontrolle über alternative Zwischenschritte. Ein Prompt, der das Modell lediglich zu einer nachdenklich klingenden Antwort auffordert, verschafft der Anwendung diese Kontrolle nicht.

Tree of Thought und Chain of Thought: Was ist der Unterschied?

Entscheidend ist, wann Alternativen verglichen werden: während eine Lösung entsteht oder erst, nachdem vollständige Antworten vorliegen.

Diese Unterscheidung beschreiben Yao et al. in den Abschnitten zu Grundlagen und Methode. Beim üblichen Self-Consistency-Verfahren werden vollständige Gedankenketten erzeugt und die häufigste Antwort ausgewählt. Dafür muss sich sinnvoll erkennen lassen, welche Antworten gleichwertig sind. Bei frei formuliertem Text ist eine solche Abstimmung schwieriger als bei einem Zahlenergebnis.

Chain-of-Thought-Prompting kann helfen, Zwischenschritte auszudrücken. Self-Consistency sorgt für unterschiedliche vollständig ausgearbeitete Versuche. ToT ergänzt eine Steuerung, die einen schwachen Lösungsweg abbrechen kann, bevor der Aufwand für seine Fertigstellung anfällt. Diese Steuerung schafft zugleich eine neue Fehlerquelle: Sie kann einen Weg verwerfen, der zum Ziel geführt hätte.

Zwei verwandte Techniken lösen andere Probleme. Few-Shot-Prompting liefert Beispiele für das gewünschte Verhalten oder Ausgabeformat. Damit kann es einem Generator oder Evaluator helfen, die vereinbarten Vorgaben einzuhalten. Prompt Chaining verbindet Arbeitsschritte, etwa das Extrahieren von Fakten mit dem anschließenden Entwurf einer Antwort. Eine feste Abfolge wird erst dann zur Suche, wenn sie Alternativen vorhält und entscheidet, welche davon weiter untersucht werden.

Die einfachste Struktur, die den jeweiligen Fehler behebt, ist der richtige Ausgangspunkt. Uneinheitliche Formate verlangen nach klareren Beispielen oder Validierung. Fehlende Belege verlangen nach dem Abruf relevanter Informationen. Beides ist für sich genommen noch kein Grund für einen Suchbaum.

Ein durchgerechnetes Beispiel: verzweigen, bewerten, beschneiden

Eine korrekte Zwischenrechnung kann trotzdem in eine Sackgasse führen. Genau diesen Unterschied muss ein Evaluator erkennen.

Als Beispiel dient das Game of 24 aus der Veröffentlichung: Mit 4, 9, 10 und 13, jeweils genau einmal verwendet, soll durch die Grundrechenarten 24 entstehen. Der folgende Ablauf wurde zur Veranschaulichung konstruiert; er ist kein aufgezeichnetes Modellprotokoll. Welche Zustände lösbar und welche unlösbar sind, wurde durch vollständiges Durchgehen der verbleibenden Rechenkombinationen geprüft. Beispieleingabe aus der Veröffentlichung.

1. 1

   Vom Ausgangszustand verzweigen

   Kandidat A berechnet 4 + 9 = 13. Übrig bleiben 10, 13, 13.

   Kandidat B berechnet 13 - 9 = 4. Übrig bleiben 4, 4, 10.

   Beide Rechnungen sind zulässig. Die mehrfach vorkommenden Zahlen stehen für verschiedene verbleibende Werte. Der Zustand muss deshalb auch deren jeweilige Anzahl festhalten.

2. 2

   Die entstandenen Zustände bewerten

   Kandidat A kann mit den verbleibenden Werten keine 24 mehr erreichen, wenn jeder Wert genau einmal mit Addition, Subtraktion, Multiplikation oder Division verwendet wird. Dieser Zweig wird verworfen.

   Für Kandidat B gibt es eine gültige Fortsetzung: Eine verbleibende 4 wird von 10 abgezogen, das Ergebnis mit der anderen 4 multipliziert. Dieser Zweig bleibt erhalten.

   Hier macht eine exakte arithmetische Prüfung die Bewertung nachvollziehbar. Die Suche in der Veröffentlichung verwendete dagegen modellbasierte Wertschätzungen, die falsch liegen können.

3. 3

   Den verbleibenden Zweig erweitern

   Ausgehend von 4, 4, 10 kommen etwa 4 + 4 = 8 mit den verbleibenden Werten 8, 10 oder 10 - 4 = 6 mit den verbleibenden Werten 4, 6 infrage.

   Der erste Zustand kann mit der letzten Rechenoperation keine 24 erreichen. Der zweite kann es: 4 × 6 = 24. Diese Fortsetzung bleibt erhalten; anschließend wird der vollständige Ausdruck geprüft.

4. 4

   Die Endantwort prüfen

   (13 - 9) × (10 - 4) = 24 verwendet jede Ausgangszahl genau einmal und ergibt den Zielwert. Die Suche endet, weil das Ergebnis die Prüfung für diese Aufgabe besteht.

Bei diesem kleinen Rätsel kann ein vollständiger Suchalgorithmus die gesamte Aufgabe erledigen. Ein LLM wäre unnötiger Entwicklungsaufwand. Das Beispiel erklärt die Suchschleife. In einer Anwendung ist häufig eine andere Aufteilung sinnvoll: Das Modell schlägt plausible Pläne vor, und Code prüft Bedingungen, deren Einhaltung das Modell nicht erraten sollte.

Welche Ergebnisse meldete die Tree-of-Thoughts-Studie?

Die ursprünglichen Ergebnisse zeigen, dass eine gezielte Suche bei den von den Autoren gewählten Aufgaben half. Sie belegen nicht, welche Verbesserung bei heutigen Aufgaben im Produktivbetrieb zu erwarten ist.

Für Game of 24 prüften die Autoren GPT-4 an 100 vergleichsweise schwierigen Aufgaben. Die Experimente fanden im Mai 2023 statt. Tabelle 2 nennt folgende Erfolgsquoten:

Quelle: Yao et al., Tabelle 2 und Versuchsaufbau für Game of 24.

Die Breite bezeichnet die Anzahl der beibehaltenen Zustände, nicht die Anzahl der Modellaufrufe. Das Erzeugen und Bewerten der Kandidaten verursacht zusätzliche Arbeit. In der Konfiguration für Game of 24 ließen die Autoren den Wert jedes Kandidaten dreimal schätzen. Versuchsaufbau.

Die Veröffentlichung untersuchte außerdem kreatives Schreiben und Mini-Kreuzworträtsel. Das sind andere Aufgaben mit anderen Bewertungsverfahren. Die praktische Schlussfolgerung ist enger als die Behauptung, ToT mache Modelle grundsätzlich besser: Suche kann helfen, wenn eine vielversprechende Zwischenentscheidung wichtig ist und sich bewerten lässt. Bevor eine solche Steuerung hinzukommt, braucht es weiterhin Belege für die konkrete Anwendung.

Wie viele Modellaufrufe kostet die Verzweigung zusätzlich?

Erzeugung, Bewertung und Abschluss müssen getrennt gezählt werden. Der Evaluator kann mehr Aufrufe benötigen als der Kandidatengenerator.

Die folgende begrenzte Suche ist eine Beispielrechnung, unabhängig von der Konfiguration der Veröffentlichung. Ein Aufruf entspricht einer Modellanfrage aus der Anwendung. Angenommen, ein Aufruf erzeugt alle Nachfolger eines Elternzustands, während jeder Nachfolger mit einem eigenen Aufruf bewertet wird. Nach der gewählten Tiefe endet die Suche, ohne Wiederholungsversuche oder vorzeitigen Abbruch. Ein letzter Aufruf formuliert anschließend die Antwort.

Pro erweitertem Elternzustand entstehen drei Nachfolger. Nach jeder Ebene bleiben zwei Zustände erhalten, insgesamt wird über drei Ebenen erweitert. Die Anzahl der erweiterten Elternzustände beträgt damit 1, 2 und 2. Daraus folgt:

• Erzeugung: 1 + 2 + 2 = 5 Aufrufe.
• Bewertung: 3 × (1 + 2 + 2) = 15 Aufrufe.
• Endantwort: 1 Aufruf.
• Gesamt: 5 + 15 + 1 = 21 Aufrufe, also 21× so viele wie bei einer Basisvariante mit 1 Aufruf.

Wird jeder Kandidat dreimal bewertet, benötigt derselbe Baum 5 + 45 + 1 = 51 Aufrufe. Werden dagegen alle Kandidatenbewertungen einer Ebene in einer einzigen Anfrage gebündelt, sind es 5 + 3 + 1 = 9 Aufrufe. Das Bündeln verändert den Kontext und die Bewertungsbedingungen des Evaluators. Es ist eine Implementierungsoption, keine Zusage gleicher Qualität.

Zum Vergleich: Self-Consistency mit fünf separat angeforderten Antworten benötigt fünf Modellaufrufe, wenn die abschließende Abstimmung durch deterministischen Code erfolgt. Ein zusätzliches Bewertungsmodell würde weitere Aufrufe verursachen und den Vergleich verändern.

Die allgemeine Rechenregel lautet C = Σ nₜ(g + kv) + f. Dabei ist nₜ die Anzahl der auf Ebene t erweiterten Elternzustände, g die Anzahl der Erzeugungsanfragen pro Elternzustand, k die Anzahl der Nachfolger pro Elternzustand, v die Anzahl der Bewertungsanfragen pro Nachfolger und f die Anzahl der Anfragen für den Abschluss. Diese Formel setzt separate Bewertungen der Nachfolger voraus. Bei gebündelten Bewertungen müssen die entsprechenden Anfragen direkt gezählt werden.

Wie bleibt die ToT-Suche unter Kontrolle?

Suchzustand und Abbruchregeln gehören in den Anwendungscode. Das Modell sollte klar begrenzte, prüfbare Zwischenergebnisse vorschlagen und bewerten.

Die Grenze dieser Architektur liegt in der Qualität des Evaluators. Kann er eine tragfähige Teillösung nicht von einer überzeugend klingenden Sackgasse unterscheiden, schaffen zusätzliche Zweige nur weitere Gelegenheiten für Fehlentscheidungen.

1. 1

   Einen prüfbaren Zustand definieren

   Bei einer Terminplanungsfunktion mit festen Vorgaben könnte ein Zustand bereits zugewiesene Aufgaben, offene Aufgaben, belegte Zeitfenster und noch unerfüllte Bedingungen enthalten. Der nächste Gedanke wäre dann eine vorgeschlagene Zuordnung. Zustand, Kandidatenkennung, Kennung des Elternzustands und Belege werden getrennt gespeichert.

   Das Zwischenergebnis muss sich in der jeweiligen Phase prüfen lassen. Ein vager Absatz über eine gute Strategie lässt sich kaum zuverlässig als aussichtsreich oder ungeeignet einstufen.

2. 2

   Erzeugung und Bewertung klar trennen

   Eine Anweisung für den Generator könnte lauten: „Schlage ausgehend von diesem Zustand unterschiedliche nächste Zuordnungen vor. Gib für jeden Kandidaten die Zuordnung und den aktualisierten Zustand zurück. Halte die aufgeführten Bedingungen ein.“

   Eine Anweisung für den Evaluator könnte lauten: „Prüfe jeden Kandidaten anhand der Bedingungen. Gib seine Kennung, etwaige verletzte Bedingungen und eine Einschätzung zurück, ob eine Fortsetzung möglich, ungewiss oder ausgeschlossen ist. Nenne die Zustandsfelder, auf denen die Bewertung beruht.“

   Regeln wie sich überschneidende Zeitfenster oder fehlende Pflichtfelder sollten zuerst deterministisch geprüft werden. Ist ein Modellurteil nötig, muss es anhand bekannter Fälle in einem LLM-as-a-Judge-Evaluationsverfahren validiert werden.

3. 3

   Beschneidung und Budget ausdrücklich festlegen

   Zustände, die eine zwingende Bedingung verletzen, werden verworfen. Die übrigen Kandidaten werden nach Qualität geordnet; nur eine begrenzte Menge bleibt für die weitere Suche erhalten. Doppelte Zustände werden entfernt. Ungewisse Kandidaten sollten verfügbar bleiben, wenn das Budget es erlaubt: Geringe Sicherheit des Evaluators beweist nicht, dass ein Zweig unmöglich ist.

   Die Steuerung muss Grenzen für Anfragen, Suchtiefe, Tokens und verstrichene Zeit durchsetzen. Bewertungen und Wiederholungsversuche zählen mit. Außerdem muss sie festhalten, was aus welchem Grund verworfen wurde. So lassen sich Fälle untersuchen, in denen gerade der erfolgreiche Lösungsweg abgeschnitten wurde.

4. 4

   Vor Annahme oder Ausführung abschließend prüfen

   Eine Abschlussprüfung stellt beispielsweise sicher, dass alle Terminbedingungen erfüllt sind oder die relevanten Softwaretests bestehen. Qualifiziert sich kein Kandidat vor dem Ende des Budgets, wird ein ungelöstes Ergebnis zurückgegeben oder der Fall zur Prüfung weitergeleitet.

   Die Erkundung von Zweigen bleibt in einer Sandbox oder auf der Ebene vorgeschlagener Aktionen. Ein vorläufiger Zweig der Terminplanung darf keine Einladungen verschicken. Ein Codezweig darf keine Änderungen ausrollen, solange die Steuerung noch Kandidaten vergleicht.

Neben der Endantwort muss auch der Evaluator gemessen werden. Eine falsche Ablehnung kann den nützlichen Zweig endgültig entfernen. Eine falsche Annahme kann das restliche Budget in einer Sackgasse verbrauchen. Diese Fehler erfordern unterschiedliche Korrekturen.

Wann macht ein Reasoning-Modell ToT überflüssig?

Eine externe ToT-Suche ist überflüssig, wenn ein Reasoning-Modell die Anforderungen an Qualität und Latenz bereits erfüllt und die Anwendung keine Kontrolle über alternative Zwischenschritte benötigt.

Ein Reasoning-Modell leistet interne Denkarbeit, bevor es antwortet. Anthropics aktuelle Prompting-Empfehlungen raten dazu, seinen Thinking-Modellen allgemeine Ziele zu geben, statt jeden Denkschritt vorzuschreiben. Das spricht dafür, mit einer klaren Aufgabe, Bedingungen und Abnahmekriterien zu beginnen. Es belegt nicht, dass ein bestimmtes Modell intern den ToT-Algorithmus von Yao et al. umsetzt. Anthropics Prompting-Empfehlungen.

Bei einer kleinen Codeumformung bietet sich zunächst ein geeignetes Reasoning-Modell an, dessen Ergebnis durch die relevanten Tests läuft. Erfüllt diese Basisvariante das Freigabekriterium, bringt ein externer Baum zusätzliche Zustandsverwaltung, Bewertung und Fehlerbehandlung mit sich, ohne dass ein Nutzen belegt wäre.

Externe Suche bleibt eine Option, wenn die Anwendung etwas Zusätzliches beitragen kann: einen Simulator, eine Prüfung fester Bedingungen, isolierte Testumgebungen oder die Anforderung, unterschiedliche Planentwürfe zu erhalten. Ein leistungsfähigeres Modell kann weiterhin als Generator innerhalb dieser Suche dienen. Modellinternes Reasoning und eine von der Anwendung gesteuerte Suche sind getrennte Architekturentscheidungen.

Die Entscheidung muss sich an Messwerten orientieren: Der Baum bleibt nur dann, wenn er überprüfte Ergebnisse so weit verbessert, dass sein gemessener Ressourcenverbrauch gerechtfertigt ist. Eine längere Antwort oder ein aufwendigeres Ablaufprotokoll ist kein Erfolgskriterium.

Wo wird Tree of Thoughts überschätzt?

Ein Prompt, der fiktive Experten zur Diskussion auffordert, stellt allein noch keine kontrollierte Baumsuche bereit. Er kann Alternativen hervorbringen. Eine ToT-Implementierung für den Produktivbetrieb braucht jedoch ausdrückliche Zustände, Bewertungen, Zweigauswahl und Abbruchregeln. Findet all das nur innerhalb einer einzigen Modellantwort statt, lässt sich nicht voraussetzen, dass die beschriebene Suche wie beabsichtigt ausgeführt wurde.

Ebenso überzogen ist die Behauptung, mehr Zweige garantierten eine bessere Antwort. Zweige können dieselbe Idee wiederholen. Ein Bewertungsmodell kann dieselbe falsche Annahme teilen wie der Generator. Eine frühe Beschneidung kann die einzige brauchbare Fortsetzung verwerfen. Selbstsichere Formulierungen ersetzen keine Prüfung der Aufgabe.

Auch das beste Game-of-24-Ergebnis der Veröffentlichung belegt nicht, dass jeder Geschäftsprozess ToT benötigt. Bei einer Dokumentenextraktion mit abweichendem Ausgabeschema können bessere Beispiele und Validierung helfen. Fehlt einem Support-Assistenten eine Richtlinie, braucht er möglicherweise die richtige Quelle. Mehr Suchpfade durch dieselbe unvollständige Informationsgrundlage liefern die fehlende Tatsache nicht nach.

Suche lohnt sich für alternative Entscheidungen, die sich bewerten lassen. Fehlender Kontext und verletzte Schnittstellen- oder Formatvorgaben müssen direkt behoben werden.

Was lässt sich diese Woche konkret verbessern?

Handlungsbedarf besteht, wenn fehlgeschlagene Fälle frühe Entscheidungen enthalten, die sich noch korrigieren ließen, und wenn es ein belastbares Verfahren zur Bewertung der Zwischenzustände gibt. Beispiele sind mögliche Codeänderungen, die in isolierten Umgebungen geprüft werden, oder Pläne, die gegen ausdrückliche Terminbedingungen getestet werden. Für solche Fälle bietet sich zunächst ein eng begrenzter Suchpfad mit festem Budget an.

Abwarten ist sinnvoll, solange sich nicht begründen lässt, warum eine Teillösung besser ist als eine andere. Zuerst braucht es eine Sammlung akzeptabler und inakzeptabler Zustände. Daran lassen sich die Entscheidungen des Evaluators prüfen und verbessern, bevor der Baum breiter wird.

Für einfache Extraktion, Klassifikation oder eine feste Abfolge, die ihre Abnahmekriterien bereits erfüllt, ändert sich wenig. Hier sollte die einfachere Struktur erhalten bleiben.

Der konkrete Schritt für Montag: Fehlerfälle aus dem bestehenden Chain-of-Thought-Ablauf nehmen und eine Basisvariante mit Reasoning-Modell auf denselben zurückgehaltenen Testaufgaben mit einer begrenzten ToT-Variante vergleichen. Die abschließende Prüfinstanz bleibt unverändert. Erfasst werden akzeptierte Ergebnisse, Modellaufrufe, Tokens, Latenz und Fälle, in denen die Beschneidung einen erfolgreichen Weg entfernt hat. Die Suche wird nur für den Teil der Aufgaben übernommen, bei dem die Ergebnisse dafürsprechen.

Häufige Fragen zu Tree of Thoughts

Sind Reasoning und Chain-of-Thought dasselbe?

Reasoning bezeichnet die allgemeinere Fähigkeit, ein Problem gedanklich zu bearbeiten. Chain-of-Thought ist ein Prompting-Ansatz, der Zwischenschritte nutzt. Ein Modell kann intern schlussfolgern, ohne diese Schritte in seiner Antwort auszugeben.

Was ist ein Baum in der KI?

Ein Baum stellt Zustände und mögliche nächste Aktionen dar. Ein Knoten entspricht einem Zustand; seine Nachfolger sind die Alternativen, die durch einen weiteren Schritt entstehen. Bei ToT stehen diese Zustände für Teillösungen.

Was bedeutet „Tree of Reasoning“?

In diesem Zusammenhang bedeutet es, alternative Teillösungen als Zweige zu organisieren, sie zu bewerten und auszuwählen, welche weiterverfolgt werden. Das konkrete Verfahren von Yao et al. heißt Tree of Thoughts.

Was ist Tree of Thought Prompting?

Dabei schlägt ein Sprachmodell alternative Zwischenschritte vor und bewertet sie. Ein Suchverfahren wählt aus, welche Zustände erweitert werden. Der praktische Vorteil: Eine Entscheidung lässt sich noch einmal überdenken, bevor die gesamte Antwort ausgearbeitet ist.

Was sind die drei C des Promptings?

Der ToT-Algorithmus von Yao et al. definiert keine Drei-C-Regel. Diese Eselsbrücke ist keine Beschreibung seines Verfahrens. Die Veröffentlichung behandelt die Zerlegung in Gedankenschritte, deren Erzeugung, die Zustandsbewertung und die Suche.

Was unterscheidet eine Gedankenkette von einem Gedankenbaum?

Standard-CoT erzeugt einen durchgehenden Lösungsweg. ToT berücksichtigt ausdrücklich alternative Teilwege und bewertet sie während der Suche. Self-Consistency geht wiederum anders vor: Es erzeugt vollständige Wege und führt deren Endantworten zusammen.

Wie sieht ein Beispiel für Chain-of-Thought-Prompting aus?

Ein durchgerechnetes Beispiel könnte zunächst 13 - 9 = 4, dann 10 - 4 = 6 und schließlich 4 × 6 = 24 zeigen. Solche Zwischenschritte als Beispiel vorzugeben, veranschaulicht CoT. Erst der Vergleich alternativer Schritte und die Entscheidung, welcher Zweig erhalten bleibt, ergänzt den ToT-Suchmechanismus.

Wie lässt sich Chain-of-Thought einfach erklären?

Chain-of-Thought verbindet eine Frage über Zwischenschritte mit ihrer Antwort, etwa durch Rechnungen oder Schlussfolgerungen. Diese Schritte können die Aufgabe nachvollziehbarer machen, aber weiterhin Fehler enthalten.

Wie funktioniert Chain-of-Thought genau?

Im üblichen Prompting-Verfahren erzeugt das Modell eine Folge von Zwischenschritten auf Grundlage der Aufgabe und des zuvor erzeugten Textes. Anschließend gibt es eine Antwort aus. Diese Folge allein bietet weder eine unabhängige Prüfung der Korrektheit noch eine von der Anwendung verwaltete Menge offener Suchzustände.

Den Newsletter abonnieren und praktische Anleitungen für die Entwicklung verlässlicher KI-Abläufe erhalten.