- CoRT (Chain of Recursive Thoughts) ist ein Projekt, bei dem ein AI-Modell eine Antwort nicht sofort endgültig festlegt, sondern selbst mehrfach Alternativen erzeugt und bewertet, um die finale Antwort auszuwählen
- Der Ablauf besteht aus dem Erzeugen einer ersten Antwort, dem Festlegen der benötigten Anzahl von Denk-Runden, dem Erzeugen von 3 Alternativen pro Runde, der Bewertung aller Antworten und der Auswahl der besten Antwort
- Bei Tests mit Mistral 3.1 24B wird angegeben, dass sich die Antwortqualität, insbesondere bei Programmieraufgaben, für ein kleineres Modell deutlich verbessert habe
- Die Web UI befindet sich noch in einer frühen Entwicklungsphase; unter Windows wird
start_recthink.bat verwendet, unter Linux der Ablauf mit pip, npm und recthink_web.py
- Zentrale Bestandteile sind Selbstbewertung, kompetitive Alternativgenerierung, iterative Verbesserung und dynamische Denktiefe; das Projekt ist unter der MIT-Lizenz veröffentlicht
Was CoRT macht
- CoRT ist ein Ansatz, der ein AI-Modell seine eigene Antwort rekursiv überprüfen, Alternativen erzeugen und anschließend die beste Antwort auswählen lässt
- Ziel ist, dass die AI eine einmal gegebene Antwort nicht einfach übernimmt, sondern sich selbst hinterfragt und den Versuch wiederholt
- Das README beschreibt dies als eine Art „AI battle royale“, bei dem die aus mehreren Kandidatenantworten überlebende Antwort als finales Ergebnis verwendet wird
Methode zur Antwortgenerierung
- Der Verarbeitungsablauf besteht aus folgenden Schritten
- Die AI erzeugt eine erste Antwort
- Die AI bestimmt die benötigte Anzahl von Denk-Runden
- In jeder Runde werden 3 alternative Antworten erzeugt
- Alle Antworten werden bewertet
- Die beste Antwort wird ausgewählt
- Die finale Antwort ist das Ergebnis, das durch wiederholte Alternativgenerierung und Bewertung ausgewählt wurde
Tests und Beispiele
- CoRT wurde in Tests auf Mistral 3.1 24B angewendet
- Das README gibt an, dass die Version mit CoRT insbesondere bei Programmieraufgaben bessere Ergebnisse lieferte als die Version ohne CoRT
- Als Beispiele sind Ergebnisbilder von Mistral 3.1 24B + CoRT und Mistral 3.1 24B non CoRT enthalten
Ausführung
- Die Web UI befindet sich noch in einer frühen Entwicklungsphase
- Unter Windows wird beschrieben,
start_recthink.bat zu öffnen und zu warten, bis die Installation der Abhängigkeiten abgeschlossen ist
- Die Ausführung unter Linux erfolgt wie folgt
pip install -r requirements.txt
cd frontend && npm install
cd ..
python ./recthink_web.py
- In einer neuen Shell wird das Frontend gestartet
cd frontend
npm start
Direkte Ausführung und Komponenten
- Für die direkte Ausführung installiert man die Abhängigkeiten, setzt
OPENROUTER_API_KEY und führt anschließend das Python-Skript aus
pip install -r requirements.txt
export OPENROUTER_API_KEY="your-key-here"
python recursive-thinking-ai.py
- Die vier zentralen Elemente, die das Projekt hervorhebt, sind
-
Self-evaluation
- Competitive alternative generation
- Iterative refinement
- Dynamic thinking depth
- Beiträge werden per PR angenommen; die Lizenz ist MIT
1 Kommentare
Hacker-News-Kommentare
Man sieht oft den Trend, mehrere Modelle gegeneinander antreten zu lassen oder sie im Schwarm laufen zu lassen, in der Hoffnung, dass dadurch auf magische Weise kollektive Intelligenz entsteht. Nach eigenen Experimenten und der Arbeit von ASU/Microsoft Research komme ich aber zu einem einfacheren Schluss: LLMs sind miserable Prüfer für andere LLMs
In Subbarao Kambhampatis Vortrag „(How) Do LLMs Reason/Plan?“ erzeugt GPT-4 selbstbewusst einen nachweislich falschen Beweis zur Graphenfärbung, bis ein symbolischer SAT-Solver als Schiedsrichter hinzukommt https://www.youtube.com/watch?v=0u2hdSpNS2o
Die Arbeit von Stechly et al. quantifiziert, dass die Genauigkeit sogar sinkt, wenn man GPT-4 seine eigenen Antworten kritisieren lässt, während ein externer, sounder Verifier bei Planungs- und Rätselaufgaben insgesamt eine Verbesserung um etwa 30 Prozentpunkte bringt https://arxiv.org/abs/2402.08115
Mit anderen Worten: Für heutige autoregressive Modelle ist Verifikation schwieriger als Generierung, und man braucht Prüfer, die tatsächlich über die Welt schlussfolgern, etwa Compiler, Linter, SAT-Solver oder Datensätze mit korrekten Antworten
Deshalb bringt es meist wenig, mehrere LLMs übereinanderzustapeln. Auch das Positionspapier zu „LLM-Modulo“ sieht autoregressive Modelle nicht in der Lage, sich selbst zu verifizieren oder langfristig zu planen; man solle sie stattdessen als Ideengeneratoren mit hohem Recall behandeln und sie mit einem einzelnen, sounden Verifier umgeben https://arxiv.org/abs/2402.01817
In eigenen Tests war es besser, eine Debatte zwischen fünf Modellen durch ein starkes Modell plus Verifier zu ersetzen: Die Antworten waren gleich gut oder besser, bei deutlich geringerer Latenz und weniger Orchestrierungsaufwand
Bücher oder Filme sind gute Beispiele: Es ist leicht zu sagen, dass eine Figur flach ist, aber überraschend schwer, eine tiefgründige und interessante Figur zu schaffen
Ähnlich ist es im Software Engineering: Ein LLM, das per Prompt nach Sicherheitslücken suchen soll, kann in generiertem Code auf potenziell verwundbare Stellen hinweisen
Wenn man aber von einem anderen LLM erwartet, Denkfehler in einem mathematischen Beweis zu finden, muss es im Grunde die gesamte Schlussfolgerung erneut durchführen; ob das eine nennenswerte Leistungssteigerung bringt, ist fraglich
Auch in Frameworks wie LangChain oder LlamaIndex ist er tief in die Evaluierung von RAG-Pipelines integriert https://arxiv.org/abs/2411.15594
Ich frage mich, wie es wäre, ein LLM zusätzlich Unit-Tests für den erzeugten Code erstellen zu lassen und dann auch alle bestehenden Unit-Tests der Anwendung auszuführen
Wenn man überprüft, ob der Code kompiliert und die Unit-Tests bestehen, wird bis zu einem gewissen Grad evidenzbasierte Verifikation möglich, und die KI kann die Testergebnisse lesen und nutzen, um ihre eigenen Fehler zu korrigieren
Training auf Korpusdaten kann Sprünge im einstelligen Faktorbereich bringen, aber Training auf Interaktionsdaten mit einer OODA-Schleife, die beobachten und sich anpassen kann, ist viel mächtiger
Wenn ich KI machen würde, würde ich es vermutlich so tun. Tatsächlich baue ich aber BrowserBox
Generate-and-test ist besonders nützlich, wenn es einen zuverlässigen, relativ schnellen und speichereffizienten Prüfalgorithmus gibt und ein exakter Generierungsalgorithmus, der nur richtige Antworten erzeugt, langsam ist oder viel Speicher verbraucht
In diesem Fall ist der Generator das LLM, und der Prüfer bzw. „Verifier“ ist ein Compiler, Linter, SAT-Solver, ein Datensatz mit korrekten Antworten usw.
Generate-and-test hängt auch mit Trial-and-Error zusammen, und Trial-and-Error gibt es vermutlich schon seit der Altsteinzeit
Eine Methode, die ich gelegentlich nutze: Zuerst lasse ich ein AI-Chatmodell die Antwort auf ein Problem liefern und es dann als Bericht aufschreiben, warum diese Antwort richtig ist, sodass auch jemand — oder eine AI — ohne Kenntnis des Ausgangsproblems oder Fachgebiets es verstehen kann.
Danach lasse ich ein zweites AI-Modell, das das Problem nicht kennt, den Bericht bewerten und einen Bericht schreiben, in dem es Erklärungen einfordert, die das ursprüngliche Modell nicht geliefert hat, oder logische Unstimmigkeiten aufzeigt.
Diesen Bericht gebe ich an das ursprüngliche Modell zurück und lasse es die Antwort unter Einbeziehung der nötigen Informationen oder Korrekturen neu schreiben; das wiederhole ich, bis das zweite Modell überzeugt ist oder das erste Modell alle Änderungswünsche umgesetzt hat.
Das ist sehr grob, aber in den Fällen, in denen ich es ausprobiert habe, kamen ziemlich gute Ergebnisse heraus.
Der endgültige Plan ist meist deutlich ausgewogener und durchdachter.
Interessanterweise funktioniert diese Technik auch gut, wenn man sie auf sich selbst anwendet. Es hilft tatsächlich, zuerst nach Schwachstellen zu suchen, bevor man den Plan erneut betrachtet.
Zum Beispiel einen mit technischem Fokus, einen mit Marketing-Fokus und einen weiteren mit Kontext zu persönlichen Zielen.
Wenn man dieselbe Frage in Chats mit unterschiedlichem Kontext stellt, ist das ähnlich, als würde man dasselbe Problem aus mehreren Perspektiven betrachten, und auch die Schlussfolgerungen können je nach Kontext ziemlich unterschiedlich ausfallen.
Das wirkte wie eine ziemlich gute Idee, aber der Token-Verbrauch dürfte stark steigen.
Außerdem bereitet mir Sorge, dass ein LLM, das als Richter eingesetzt wird, möglicherweise auch Schwierigkeiten hat, korrekt zu bewerten, wenn es von vornherein keine ausreichend gute Antwort erzeugen kann.
Ich würde so etwas gern in größerem Maßstab als ständig laufenden Diskussionssenat ausprobieren.
Statt jeweils auf einen Prompt zu antworten, würde man ihm eine Aufgabenliste geben, eventuell mit Deadlines, und den Senat daran arbeiten lassen: Er teilt sich für Teilaufgaben in Gruppen auf, stellt Ergebnisse infrage und macht Vorschläge.
Darüber hinaus könnte man einen Baum von Analysten bauen, bei dem übergeordnete Knoten Vorschläge nur dann nach oben weiterreichen, wenn sie eine Unteranalyse für besonders aufschlussreich halten.
Ich habe deutlich gesehen, dass die Ergebnisse besser oder schlechter werden können, wenn man ein Modell anweist, ein Problem aus einer bestimmten Perspektive anzugehen. Wenn man verschiedene Perspektiven und eine kritische Analyse ihrer Ergebnisse zusammen erzeugt, könnten beeindruckende Resultate entstehen.
Dieser Ansatz würde gewaltige Mengen an Tokens erzeugen, aber die Kosten pro Token entwickeln sich in eine Richtung, die so etwas möglich macht. Denkbar wäre auch ein AI-spezifischer IRC-Server, an den jeder sein eigenes Modell anschließen und den man wie einen gemeinsamen Diskussionsraum nutzen kann.
Wenn man Zeit investiert, es ausprobiert, stecken bleibt und zurückkommt, sagt es locker: „Stimmt, gut gefunden! Sie sind fast am Ziel! Die nächsten Schritte sind X und Y“, und liefert dann wieder dasselbe detaillierte Tutorial wie zuvor, nur mit leicht veränderten Stellen wie den falschen Flags.
Es fühlt sich an, als hätte man es mit einem übermotivierten Praktikanten zu tun, der Arbeit abliefert, ohne sie zu überprüfen; es dürfte deutlich besser werden, wenn man vor den ersten Bot einen zweiten Bot setzt, der fragt: „Bist du dir wirklich sicher?“
Ich hatte es nach dem Berater-Konzept aus Civilization II gebaut, und es funktionierte ziemlich ordentlich, hatte aber gewisse Grenzen, weil es an ein einzelnes LLM, Mistral, gebunden war.
Und es war so schwergewichtig, dass es meinen Rechner zum Glühen brachte.
Es wäre interessant zu sehen, was dabei herauskommt, wenn man genügend Zeit und Tokens gibt.
Eine viel einfachere und eingeschränktere Strategie, die ich häufig nutze, ist, ans Ende einer Nachricht zu hängen: „Denke vor der Antwort einmal innerhalb von Tags nach, übe innerhalb von Tags einmal Selbstkritik und schreibe am Ende die finale Antwort.“
Das funktioniert ziemlich gut. Ähnlich brauchbar ist es auch, einfach zu sagen: „Finde die 5 größten Probleme an diesem Vorschlag“; wenn man 5 erzwingt, findet es meistens irgendetwas, auch wenn vieles davon wenig relevant ist.
In Schritt 1 lasse ich einen Plan erstellen, in Schritt 2 die Schwächen des Plans herausarbeiten, und in Schritt 3 den Plan unter Berücksichtigung dieser Schwächen aktualisieren.
Andere Fragen, die ich häufig stelle, sind etwa: „Was haben wir übersehen?“ oder „Welche Aspekte gibt es in Bezug auf Performance, Sicherheit, Recht und Kosten?“
Man kann auch ein paarmal nachhaken mit Prompts wie „Gibt es noch etwas?“, besonders wenn man die zu berücksichtigenden Themen vorgibt. Nach jedem Durchlauf lasse ich den Plan unter Einbeziehung dieser Überlegungen aktualisieren.
Etwas anders, als ich nach dem Titel erwartet hatte. Ich dachte, es ginge ausdrücklich um ein adversariales Verfahren
Ich habe das nicht selbst ausprobiert und weiß nicht, ob es funktioniert. Aber es hilft, ChatGPT mit separaten Prompts jeweils zu fragen: „XYZ ist wahr, erkläre warum“ und „XYZ ist falsch, erkläre warum“, und dann zu schauen, welche Seite überzeugender ist
https://github.com/evalstate/fast-agent
Ich weiß nicht, warum jemand das für neu hält. Vielleicht zeigt das auch den Zustand von HN
Der Ansatz selbst sieht gut aus, aber man darf auf keinen Fall direkt andeuten: „Du liegst falsch“. Normalerweise nimmt es dann einfach an, dass es selbst falsch liegt
Umso beeindruckender ist es, wenn es auf diese Weise tatsächlich widerspricht und sich verteidigt
Solche Experimente sind ziemlich interessant, deshalb baue ich gerade einen Graph-Editor im Stil von Unreal-Engine-Blueprints, mit dem Leute solche Workflows entwerfen können
Der Nutzer-Prompt geht an einen Agenten, der einen ersten Versuch erstellt; dieser Gesprächsverlauf wird dann an einen „Agenten“ mit einem anderen System-Prompt weitergereicht, der zum harten Kritiker wird, ein Bestehen-/Durchfallen-Signal ausgibt, und das Ganze läuft in einer Schleife, bis der Kritiker auf „bestanden“ entscheidet, bevor es an den Nutzer ausgegeben wird
Ideal wäre eine kleine Website, die den eigenen LLM-Endpunkt aufruft und Workflow-Graphen speichern, laden und teilen kann
Mistral Small 3.1 und Gemma 3 fühlen sich wie die ersten halbwegs brauchbaren Modelle an, die lokal laufen können, aber diese Brauchbarkeit ist nur der Keim; man braucht ein Framework, das sie weiter auf Kurs hält
Wenn man ihnen innerhalb einer Iterationsschleife Python-Ausführungsrechte gibt und sagt, sie sollen die Welt erkunden, fangen sie an, Dinge wie Nachrichten herunterzuladen und zu lesen
Wenn man GPT zum Beispiel anweist, gemein zu sein, konnte man GPTs Fähigkeit, Unsinn oder schlampiges Denken aufzuspüren, ein Stück weit so hinbekommen wie bei Gemini. Höflichkeit scheint eine Menge Wertvolles herauszufiltern
Aber das Ergebnis wird unangenehm zu lesen. Gemini scheint das im Training in zwei Schritten zu behandeln und den ersten Schritt zu einem privaten „Denken“ gemacht zu haben
Deshalb braucht es meiner Meinung nach einen zweistufigen Ansatz, der diese „gemeine“ Ausgabe danach etwas menschlicher glättet. Wenn man so arbeitet, wird es nach kurzer Zeit ziemlich ermüdend
Eine Gruppenchat-UI mit unterschiedlichen LLM-Persönlichkeiten hätte vermutlich ebenfalls großen Wert. Das Nachrichtenobjektformat wirkt so, als sei es mit mehreren Nutzern und mehreren AIs im Kopf entworfen, etwa mit einem Namen pro Nachricht, aber so eine UI habe ich noch nicht gesehen
Noch besser wäre Unterstützung für mehrere Anbieter. Sie haben unterschiedliche Stärken, ähnlich wie wenn man eine zweite Meinung einholt
consortium schickt denselben Prompt parallel an mehrere Modelle und sendet alle Antworten an ein Moderatormodell zur Bewertung. Der Moderator entscheidet, ob weitere Iterationen nötig sind
Man kann auch weitere Iterationen erzwingen, bis ein Vertrauensschwellwert oder eine Mindestanzahl an Iterationen erreicht ist
Mit dem PR, den ich für llm-openrouter erstellt habe, kann man Modell-Aliase speichern, die mehrere Modelloptionen enthalten. Zum Beispiel kann man mit
llm openrouter save -m qwen3 -o online -o temperature 0, system "research prompt" --name qwen-researchereinen Spezialisten für Online-Recherche erstellenEin anderes Mitglied kann im JSON-Modus Entitäten extrahieren, wieder ein anderes einen Blindentwurf schreiben. Der Moderator nutzt all das, um eine gute Antwort zusammenzuführen
Wir müssen schnell einen Weg finden, diese GPUs mit Ökostrom zu betreiben. Sonst bringen die AIs die Erde zum Schmelzen, während sie untereinander über die optimale Lösung für Tic-Tac-Toe diskutieren
Manchmal ist es der einfachste Weg, eine winzige Aufgabe zu erledigen, aber der Unterschied bei den Backend-Kosten muss ziemlich groß sein. Dem Nutzer wird das am Ende völlig egal sein. Es fühlt sich nicht real an
Dass AI ständig gegen sich selbst laufen muss, wird bereits als gegeben hingenommen
Ich glaube, so bringt man Machine-Learning-Modelle dazu, neue Ideen hervorzubringen
Durch Selbstdebatte diagonalisiert man über alle Ideen, die bereits ausprobiert und verworfen wurden, während bestimmte Konsistenzbedingungen erhalten bleiben. Natürlich ist das viel leichter gesagt als getan
Conway’s Game of Life, nur dass statt farbiger Quadrate mit Regeln LLMs mit bestimmten Gewichten ununterbrochen miteinander reden und irgendwo als Worte oder Handlungen auftauchen
https://news.ycombinator.com/item?id=43835798
Wie weit wird das gehen? Werden wir AI-Agent-Scrum-Teams bekommen, die alle paar Stunden Stand-up-Meetings abhalten?
Werden wir Regierungsbürokratien mit Agenten nachbilden, die den ganzen Tag ein Thema diskutieren, um die beste Position zu finden?
AI-Agenten mit unterschiedlichen Rollen betrieben ein Scrum-Team, und die Prompts der einzelnen Agenten waren so formuliert, dass sie allen widersprechen oder ihren eigenen Standpunkt sehr kritisch darlegen sollten; die endgültige Entscheidung traf dann ein Mediator
Der Vortragende behauptete, dass es bei ihnen gut funktioniert habe
Menschen haben unterschiedliche Erfahrungen und Perspektiven, auch wenn das bei LLMs weniger stark ausgeprägt ist. Trotzdem reicht manchmal schon ein anderer Hut. Zum Beispiel wie der Unterschied zwischen Code-Reviewer und Coder
Irgendwann wird es einen Punkt geben, an dem der Effekt abflacht, und um diesen Punkt zu bestimmen, wird es wohl auch ein AI-Komitee geben
Schließlich will man ja nicht den Ozean zum Kochen bringen
Schön, dass man das leicht forken und damit herumspielen kann
Ich habe gerade meine eigene Iteration begonnen, bei der ich Nash Equilibrium hinzufüge und „Prompt Engineering“ als Multi-Agent-Verhandlung neu formuliere. Mich würde interessieren, was andere darüber denken
https://github.com/faramarz/NECoRT/
Meine Einschätzung ist, dass Enterprise-LLMs kein großes Problem mit den zusätzlichen Rechenkosten haben werden und eher bevorzugen, komplexe Finanzfragen über mehrere Modellierungsoptimierungen abzustimmen
Mit öffentlichen Repositories und Contributions bin ich noch nicht sehr vertraut; falls ich etwas falsch mache, wäre ich dankbar, wenn mich jemand darauf hinweist
Die Absicht ist, die ursprüngliche Codebasis zu forken, die Theorie zu testen und sie am Ende als PR einzureichen