Graph of Thoughts: ein Framework, das Denkketten zu einem Operationsgraphen macht
Official Implementation of "Graph of Thoughts: Solving Elaborate Problems with Large Language Models"
Auf einen Blick
- Was ist das?
- spcl/graph-of-thoughts ist die offizielle Implementierung des GoT-Papers. Es trennt Problembeschreibung, Prompting und Ausführung, damit sich neben CoT und ToT auch eigene Graphstrukturen über einem LLM abbilden lassen. Wer den Ablauf nicht selbst verdrahten will, findet hier ein Gerüst, aber keinen fertigen Dienst.
- Für wen ist es gedacht?
- Sinnvoll ist das Framework für Teams, die eine im Paper beschriebene Ausführungsreihenfolge über einem LLM nachbauen und dabei die Kontrolle über Prompting und Parsing behalten wollen. Wer einen betreuten Dienst mit Zusagen zu Verfügbarkeit oder Kosten braucht, sollte Abstand nehmen.
- Darf ich es kommerziell nutzen?
- Erst prüfen. Die Lizenz dieses Repositorys ordnen wir nicht automatisch ein; lesen Sie vor jeder kommerziellen Nutzung die LICENSE-Datei.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 175 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem der Operationsgraph löst
Ein einzelner Prompt liefert eine Antwort. Sobald ein Problem mehrere Zwischenschritte verlangt, zwischen denen etwas zusammengeführt, bewertet oder verworfen wird, reicht diese eine Antwort nicht mehr aus. Genau dort setzt das Repository an. Das README beschreibt das Ziel so: komplexe Probleme werden als Graph of Operations (GoO) modelliert und automatisch mit einem Large Language Model als Engine ausgeführt. Der Graph ist damit das Programm, das Modell der Ausführende.
Angesprochen sind nach dieser Beschreibung zwei Gruppen. Zum einen Entwickler, die eine der im Paper untersuchten Aufgaben nachvollziehen wollen, also Sortieren, Keyword Counting und die weiteren Beispiele im Verzeichnis examples. Zum anderen Entwickler, die eine eigene Abfolge von Denkschritten brauchen und dafür nicht bei jedem Projekt die Ansteuerung des Modells neu schreiben möchten. Das README formuliert den Anspruch, dass sich neben GoT auch Graphstrukturen umsetzen lassen, die früheren Ansätzen wie CoT oder ToT entsprechen. Das ist der eigentliche Nutzen: ein gemeinsames Gerüst für mehrere Vorgehensweisen, nicht ein einzelner Algorithmus.
Generate, Score, GroundTruth: der Graph als Ablaufplan
Die Bausteine liegen im Modul operations. Ein Graph wird erzeugt, indem Operationen angehängt werden. Im Quick-Start-Beispiel für das Sortieren von 32 Zahlen entsteht eine Kette aus drei Schritten: zuerst operations.Generate(), dann operations.Score(scoring_function=utils.num_errors), schließlich operations.GroundTruth(utils.test_sorting). Generate erzeugt neue Gedanken, Score bewertet sie über die übergebene Funktion, GroundTruth vergleicht gegen eine bekannte Lösung. Der Score ist im Beispiel die Anzahl der Fehler in der sortierten Liste, wie das README erläutert.
Für den aufwendigeren GoT-Lauf wird der Graph nicht von Hand zusammengesetzt, sondern über got() aus dem Beispielmodul bezogen. Der Unterschied zwischen beiden Läufen zeigt sich dem README zufolge in den Ausgabedateien output_cot.json und output_got.json, deren finale Gedankenzustände jeweils einen Score tragen. Das Modell selbst steckt hinter language_models.ChatGPT, das mit einem Pfad zu config.json und dem Argument model_name="chatgpt" instanziiert wird. Der Controller verbindet beides: Modell, Graph, Prompter und Parser. Er ist die Stelle, an der Prompt-Erzeugung und Antwortzerlegung zusammenlaufen, und das README verweist für Details ausdrücklich auf die README-Dateien im Controller- und im Operations-Modul.
Installation und der erste Lauf
Die Installation hängt davon ab, ob der Code nur benutzt oder verändert werden soll. Für die reine Nutzung nennt das README pip install graph_of_thoughts. Wer mitarbeiten will, klont das Repository und installiert im editierbaren Modus:
git clone https://github.com/spcl/graph-of-thoughts.git cd graph-of-thoughts pip install -e .
Vorausgesetzt wird Python 3.8 oder neuer, und vor beiden Wegen soll die Python-Umgebung aktiviert sein. Ohne Zugang zu einem LLM läuft nichts. Das README verweist dafür auf graph_of_thoughts/controller/README.md, wo die Konfiguration des gewünschten Anbieters beschrieben ist. Im Beispielcode wird config.json im aktuellen Verzeichnis erwartet, mit einem OpenAI-API-Schlüssel darin. Diese Datei enthält also ein Geheimnis und gehört nicht in ein Repository.
Für einen ersten Test müssen nicht einmal eigene Skripte geschrieben werden. Aus dem Hauptverzeichnis lassen sich die Beispiele direkt starten:
python -m examples.sorting.sorting_032 python -m examples.keyword_counting.keyword_counting
Die Ergebnisse landen laut README im jeweiligen Unterverzeichnis des Beispiels. Wer den Ablauf im Code nachvollziehen will, findet dort je ein eigenes README mit Anweisungen.
Controller, Prompter, Parser: wo die Arbeit tatsächlich landet
Der Controller bekommt beim Aufruf fünf Dinge: das Sprachmodell, den Operationsgraphen, einen Prompter, einen Parser und ein Wörterbuch mit dem initialen Gedankenzustand. In den beiden Sortierbeispielen unterscheiden sich diese Wörterbücher. Der CoT-Lauf setzt original, current und method auf "cot". Der GoT-Lauf setzt original, current, phase auf 0 und method auf "got". Der Zustand ist also Teil der Konfiguration und nicht im Graphen verborgen.
Das erklärt, warum Prompter und Parser eigene Klassen sind. SortingPrompter und SortingParser stammen aus dem Beispielmodul, nicht aus der Bibliothek. Für ein anderes Problem müssen beide ersetzt werden, weil das Framework nicht wissen kann, wie eine Aufgabenstellung in Text zu gießen und wie die Antwort wieder in einen Gedankenzustand zu überführen ist. Das ist der Punkt, an dem der Aufwand entsteht. Die Bibliothek liefert den Rahmen und die Ausführungsschleife, die fachliche Anbindung bleibt beim Anwender. Wer erwartet, dass ein neues Problem durch das Austauschen eines Prompts erledigt ist, wird hier mehr Code schreiben als gedacht.
Der Ablauf endet mit ctrl.run(), gefolgt von ctrl.output_graph("output_cot.json") beziehungsweise ctrl.output_graph("output_got.json"). Der Graph wird also als JSON serialisiert, was das Nachvollziehen und Vergleichen erleichtert.
Grenzen: kein Dienst, keine Zusagen zur Reproduzierbarkeit
Das Repository ist eine Bibliothek, kein betriebener Endpunkt. Es gibt keine Angaben zu Nebenläufigkeit, Wiederholungsversuchen bei Fehlern des Anbieters oder Ratenbegrenzung. Wer viele Läufe parallel startet, muss diese Fragen selbst beantworten.
Hinzu kommt die Bindung an das Modell. Die Beispiele instanziieren language_models.ChatGPT mit model_name="chatgpt". Das README verweist für andere Anbieter auf die Controller-Dokumentation, ohne sie hier zu wiederholen. Ob ein bestimmter Anbieter unterstützt wird, lässt sich aus dem vorliegenden Material nicht ableiten. Ebenso wenig lässt sich sagen, wie stabil die Ausführung über verschiedene Modellversionen hinweg ist. Das Beispiel vergleicht Ergebnisse über die Anzahl der Fehler im sortierten Ergebnis, eine Größe, die vom Modellverhalten abhängt. Ein reproduzierbares Resultat ist damit nicht garantiert, und das README macht dazu auch keine Zusage.
Wer eine fertige Anwendung mit Betrieb, Überwachung und Kostenkontrolle sucht, ist hier falsch. Der Nutzen liegt im Nachbauen und Untersuchen von Ausführungsreihenfolgen, nicht im Produktivbetrieb ohne weitere Schichten.
Abgrenzung zu LangChain
Als Vergleich bietet sich LangChain an, weil es ebenfalls LLM-Aufrufe zu Abläufen verkettet. Der Unterschied liegt im Ausgangspunkt. LangChain stellt Bausteine für viele Anwendungsfälle bereit, von Werkzeugen über Speicher bis zu Agenten, und überlässt dem Anwender die Wahl der Struktur. Graph of Thoughts geht den umgekehrten Weg: Es beginnt bei einem expliziten Graphen aus Operationen, der vor dem Lauf feststeht, und führt ihn aus. Die Struktur ist das Erste, nicht das Ergebnis einer Komposition.
Für die im Paper beschriebenen Experimente ist das passend, weil sich ein Ablauf damit exakt beschreiben und in JSON festhalten lässt. Für eine Anwendung, die vor allem Werkzeuge aufruft und Zustand über Sitzungen hält, bringt der Operationsgraph wenig. Umgekehrt gilt: Wer die Ausführungsreihenfolge als eigenes Objekt braucht, um sie zu vergleichen oder zu verändern, muss sie in LangChain erst nachbilden. Die Entscheidung hängt also davon ab, ob der Graph im Mittelpunkt steht oder nur ein Mittel unter vielen ist.
Wartung, Lizenz und was vor dem Einsatz zu klären ist
Die letzten Veröffentlichungen im Material sind v0.0.1 vom August 2023 und v0.0.2 vom September 2023. Der letzte Push auf den Hauptzweig datiert auf März 2026, das Repository ist nicht archiviert. Aus diesen Angaben allein lässt sich kein Wartungsversprechen ableiten. Wer das Framework einbindet, sollte damit rechnen, die verwendete Version selbst festzuschreiben, etwa in einer requirements-Datei, statt auf die jeweils aktuelle Fassung zu setzen.
Die Lizenz ist als NOASSERTION ausgewiesen. Das ist keine Lizenzkennung, sondern die Abwesenheit einer maschinenlesbaren Zuordnung. Welche Bedingungen für Weitergabe oder Änderung gelten, lässt sich daraus nicht ableiten. Vor einer Nutzung in einem Produkt ist das zu klären, und zwar anhand der Dateien im Repository, nicht anhand dieser Kennung. Eine rechtliche Bewertung ist hier nicht möglich und auch nicht beabsichtigt.
Ein weiterer Kostenpunkt ist die Abhängigkeit von einem externen Modell. Jeder Lauf verbraucht Aufrufe beim Anbieter, und das Beispiel sortiert bereits 32 Zahlen. Bei größeren Graphen oder mehreren Beispielen wächst die Zahl der Aufrufe mit der Zahl der erzeugten und bewerteten Gedanken. Das README nennt dazu keine Größenordnung, und aus dem vorliegenden Material lassen sich keine Aufrufzahlen ableiten. Wer die Kosten im Blick behalten will, muss sie selbst messen.
Für wen sich der Einstieg lohnt
Der schnellste Weg zu einem eigenen Urteil führt über die beiden Befehle aus dem README: python -m examples.sorting.sorting_032 und python -m examples.keyword_counting.keyword_counting. Danach lohnt der Vergleich der Dateien output_cot.json und output_got.json, weil dort die Scores der finalen Gedankenzustände stehen. Wer diesen Vergleich nachvollziehen kann und die Struktur für ein eigenes Problem wiedererkennt, findet im Framework eine brauchbare Grundlage. Wer dabei feststellt, dass bereits der Prompter und der Parser den Großteil der Arbeit ausmachen, sollte prüfen, ob der Operationsgraph diesen Aufwand rechtfertigt.
Redaktionelles Fazit
Sinnvoll ist das Framework für Teams, die eine im Paper beschriebene Ausführungsreihenfolge über einem LLM nachbauen und dabei die Kontrolle über Prompting und Parsing behalten wollen. Wer einen betreuten Dienst mit Zusagen zu Verfügbarkeit oder Kosten braucht, sollte Abstand nehmen. Vor dem ersten Einsatz ist zu klären, unter welchen Bedingungen der Code nachgenutzt werden darf, denn das Repository trägt NOASSERTION statt einer klaren Kennung, und die im Controller-Modul beschriebene LLM-Anbindung ist gegen den eigenen Anbieter zu prüfen.
Community-Notizen