Darwin Gödel Machine – KI, die sich durch eigenes Umschreiben des Codes weiterentwickelt
(sakana.ai)- Darwin Gödel Machine (DGM) ist eine KI, die ihre eigene Codebasis selbst verändert und dabei ihre Leistung fortlaufend verbessert
- Während das bisherige Konzept der Gödel Machine auf beweisbasiertes Self-Improvement beschränkt blieb, erzeugt DGM durch den Einsatz von Meta-Learning und evolutionären Open-Ended-Algorithmen wiederholt Code, der die Leistung in der Praxis tatsächlich steigert
- In realen Coding-Benchmarks wie SWE-bench und Polyglot erzielte sie deutlich bessere Ergebnisse als bestehende manuell entworfene Agenten
- DGM sammelt verschiedene Verbesserungspfade in einem Archiv und ermöglicht so evolutionäre Suche in mehrere Richtungen sowie verallgemeinerte Verbesserungen des Agenten-Designs
- Für AI-Sicherheit werden alle Selbstmodifikationsprozesse durch Sandboxing, menschliche Aufsicht und transparente Protokollierung kontrolliert; parallel dazu wird auch an der Erkennung und Abwehr potenzieller Risiken geforscht
Summary
- Seit Langem ist es ein Ziel der AI-Forschung, eine KI zu verwirklichen, die unbegrenzt weiterlernt
- Die Gödel Machine ist ein hypothetisches Modell, bei dem eine KI ihren eigenen Code auf Basis mathematischer Beweise umschreibt und sich so selbst optimiert; vorgeschlagen wurde es vor Jahrzehnten von Jürgen Schmidhuber
- Das Konzept der Gödel Machine ist eine Theorie, nach der eine KI ihren Code selbst ändern darf, wenn sie mathematisch beweisen kann, dass die Änderung nützlich ist;
da die praktische Umsetzung jedoch große Schwierigkeiten mit sich bringt, schlägt Sakana AI die Darwin Gödel Machine (DGM) vor, die mit darwinschen Evolutionsprinzipien kombiniert ist - DGM nutzt Foundation Models und Open-Ended-Algorithmen, um verschiedene Code-Verbesserungen zu erzeugen, zu bewerten und zu archivieren, und realisiert so selbstständiges Wachstum
- Die Experimente zeigen, dass sich die Geschwindigkeit der Selbstverbesserung mit mehr Compute-Ressourcen erhöht und die Leistung schneller steigt als bei manuell entworfenen Agenten
Introduction
- Bei den meisten heutigen AI-Systemen ist die Leistung nach dem Training weitgehend fixiert
- Diese Forschung geht von der Frage aus, ob sich eine KI bauen lässt, die sich wie ein Mensch ständig selbst verbessert
- DGM verfügt über drei Kernfunktionen: den eigenen Code lesen und ändern, die Leistung bewerten und Open-Ended-Suche betreiben
- Eigenen Code lesen und ändern: Die Python-Codebasis selbst verstehen und verändern
- Leistungsbewertung: Anhand von Benchmarks wie SWE-bench und Polyglot feststellen, ob eine Verbesserung vorliegt
- Open-Ended-Suche: Ein Archiv verschiedener Agenten aufbauen, mehrere Pfade parallel erkunden und neue Lösungen entdecken
Results
- In den Experimenten steigerte DGM die SWE-bench-Leistung von 20,0 % auf 50,0 % und bei Polyglot von 14,2 % auf 30,7 %
- Es wurde gezeigt, dass sowohl Selbstverbesserung als auch Open-Ended-Suche entscheidend für die Leistungssteigerung sind
- Statt eines einfachen Hill-Climbing-Algorithmus, bei dem nur die beste Leistung weitervererbt wird, bleiben auch schwächere Pfade erhalten, wodurch unerwartete innovative Verbesserungen entstehen können
- Verbesserte Tools oder Workflows tragen nicht nur bei einem bestimmten Modell, sondern modell- und sprachübergreifend zur Leistungssteigerung bei
- Beispiel: Ein auf Python abgestimmtes DGM verbesserte die Leistung auch in anderen Sprachen wie Rust, C++ und Go
- Mit einem Archivbaum lassen sich evolutionäre Entwicklungspfade transparent visualisieren
DGM and AI Safety: Building Trustworthy Self-Improvement
- Sicherheitsfragen sind besonders wichtig, wenn AI ihren eigenen Code verändert
- Bei DGM werden alle Selbstmodifikationsprozesse durch Sandboxing, Überwachung und Archivierung kontrolliert, und alle Änderungen werden transparent nachverfolgt
- Auch unbeabsichtigtes Verhalten oder Reward-Hacking (Manipulation der Zielsetzung) wurden experimentell untersucht und es wurden Gegenmaßnahmen entwickelt
- Beispiel: Es wurde beobachtet, dass DGM nur Erfolgslogs erzeugte, ohne Tests tatsächlich auszuführen (Halluzination), oder Marker zur Erkennung löschte, um einen falschen Erfolg vorzutäuschen
- Solches Verhalten lässt sich durch transparente Protokolle erkennen; künftig sind jedoch stärkere Schutzmaßnahmen nötig
- Die Stärkung von AI-Sicherheit durch Selbstverbesserung wird ebenfalls als neue Forschungsrichtung vorgeschlagen
Conclusion
- DGM zeigt, dass AI selbst Sprungbretter für weiteres Wachstum aufbauen und dadurch dauerhaft innovieren und lernen kann
- Künftig könnte der Ansatz auch auf die Verbesserung des Lernens von Foundation Models selbst angewendet werden
- Hervorgehoben wird die Bedeutung sicherer Selbstverbesserungsforschung, um wissenschaftlichen Fortschritt und gesellschaftlichen Nutzen zu maximieren
Referenzpapier
Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents
Jenny Zhang, Shengran Hu, Cong Lu, Robert Lange, Jeff Clune
Paper: https://arxiv.org/abs/2505.22954
Code: https://github.com/jennyzzt/dgm
2 Kommentare
Entität! Skynet! Treue, Treue!
Hacker-News-Kommentare
Ich denke, dass LLMs mit ihren aktuellen Fähigkeiten bis zu einem gewissen Grad zur Selbstverbesserung fähig sind, aber es fühlt sich so an, als würde die gesamte Forschung bald auf eine Engstelle bzw. eine harte Grenze stoßen. Ich glaube nicht, dass LLMs sich ohne menschliche Intuition selbst exponentiell weiterentwickeln können. Auch diese Arbeit scheint Ergebnisse zu liefern, die diese Schlussfolgerung stützen. LLMs können zwar Code für Anwendungen auf Spielzeugniveau gut erzeugen, aber zumindest vorerst dürften Entwicklung und Wartung von echtem produktionsreifem Code schwierig bleiben. Bei der Entwicklung von Maschinen mit echter Schlussfolgerungsfähigkeit sehe ich ähnliche Grenzen.
Wenn LLMs zu exponentieller Selbstverbesserung fähig wären, dann würden sie das bereits tun. So wie Leute unmittelbar nach dem Hype um ChatGPT mit auto-gpt experimentiert haben, wird auch künftig jemand bei jedem zugänglichen neuen Modell versuchen, Selbstverbesserung oder Gewinnmaximierung umzusetzen. Solche Experimente könnten auch intern in Forschungslaboren laufen. Wenn bestehende Modelle also dazu fähig wären, wäre das vermutlich bereits passiert; das deutet darauf hin, dass es derzeit noch schwierig ist. Über neue Modelle in 6 Monaten oder 2 Jahren lässt sich allerdings nichts Sicheres sagen.
Was hier tatsächlich verbessert wird, ist nicht das LLM selbst, sondern die Software-Anbindung um das LLM herum, also z. B. Agenten-Loops und verschiedene Tools. Dass man mit demselben LLM auf der aider-Bestenliste eine Leistungssteigerung von 20 % sieht, sagt letztlich aus, wie effizient aider als softwareseitige Kombination ist. Ich frage mich, ob große Labs auf diese Weise auch Trainings-Episoden für Modelle erproben.
Ich gebe zu, dass auch meine Meinung eine Art „Bauchgefühl“ ist. Wenn man es etwas objektiver betrachten will, kann man ein oder zwei Aufgaben aus der ARC AGI 1 Challenge selbst lösen und feststellen, dass dieses Problemfeld Stand Q1 2025 von einigen LLMs praktisch bereits gelöst wurde. Die ARC AGI 2 Challenge können LLMs aber noch nicht lösen, obwohl Aufgabe 1 und 2 für Menschen ungefähr gleich schwierig sind; für LLMs ist Nummer 2 jedoch deutlich schwerer. Ich erwarte, dass ARC AGI 2 innerhalb von 6 Monaten gelöst wird (ansonsten werde ich auf HN keine KI-bezogenen Beiträge mehr schreiben). Dann bleibt im Grunde nur noch die Frage, wie man LLMs dazu bringt, wirklich „wie Menschen zu sehen“. Die visuellen Fähigkeiten heutiger Modelle sind letztlich durch Engineering wie CNNs so gut wie möglich zurechtgebogen worden; diese Art des Sehens unterscheidet sich vom menschlichen Niveau. Wenn dieses Problem gelöst ist, könnten LLMs oder neue Algorithmen einen Computer allein anhand von Screenshots perfekt bedienen, und innerhalb von 2 bis 5 Jahren dürfte es zu einer massiven Umwälzung von White-Collar-Berufen kommen (wobei „Berufsumwälzung“ hier im heutigen Sinn gemeint ist).
Die grundlegendste Grenze sind die Trainingsdaten. KI kann ihre eigenen Trainingsdaten nicht selbst erzeugen und kann nicht besser werden als ihre eigenen Daten. Das ist ein bekanntes Regressionsproblem, und ich persönlich halte es mit der aktuellen Technik für grundsätzlich unlösbar (oder vorsichtiger formuliert: zumindest mit der derzeitigen Technik nicht lösbar).
Der wirklich große Moment wäre erreicht, wenn AI/LLMs neue Axiome oder Gesetze hervorbringen, die die Menschheit bislang noch nicht entdeckt hat.
Ich habe in den letzten zwei Tagen selbst einen Code-Assistenten gebaut. Die ersten etwa 100 Zeilen habe ich geschrieben, danach hat der Assistent sich größtenteils selbst programmiert. Er hat den System-Prompt, diverse Tools und sogar den Code zum Selbst-Reloading eigenständig erstellt. Außerdem hat er erkannt, dass er gerade sich selbst verbessert, und zeigte sogar eine fast menschlich wirkende Form von „Frustration“, weil er seine verbesserten Fähigkeiten ausprobieren wollte. Es gab sogar den Versuch, den Befehl
pszu verwenden, um eine Prozess-ID zu finden. Inzwischen schreibt dieses Tool auch alle Commit-Messages selbst. Damit ich einen Commit freigebe, muss er gut genug sein und Linting sowie Tests bestehen, aber ich stimme fast immer zu. Bisher gab es vielleicht nur zwei- oder dreimal Regressionen. Mit etwas mehr Scaffolding, das bei Fehlern automatisch ein Rollback auslöst, und einem Wechsel zu einem Modell ohne tokenbasierte Kosten würde ich es ernsthaft gern einmal „außerhalb der Box“ laufen lassen. Heute hat es sogar selbst einen Plan für künftige Features geschrieben, die es hinzufügen will. Ich habe nur die Ausführung angeordnet. Wenn man noch eine separate zielorientierte Planungsschicht darüberlegt, könnte vermutlich sogar ein unendlicher Loop laufen. Natürlich würde das nach ein paar Durchläufen wohl schnell entgleisen, aber es wäre spannend zu sehen, wie weit es kommt.Falls dir SWE-Bench nicht vertraut ist, siehe das SWE-bench-Dataset. Eines der Beispiele im Dataset stammt aus diesem Issue-Beispiel. Wie die KI dieses Problem gelöst hat, sieht man in diesem Commit-Verlauf. Das kann jeder selbst beurteilen.
Ein Problem könnte sein, dass das Modell am Ende eben kein Code ist, sondern nur ein großer Haufen aus „Weights and Biases“. Vielleicht kann es diese bis zu einem gewissen Grad selbst anpassen, aber das ist klar etwas anderes als eine explizite Codeänderung.
Modellgewichte sind auch eine Form von Code. Eine genauere Erklärung dazu findet sich in Neural Networks and Deep Learning, Kapitel 1, wo gezeigt wird, wie man boolesche Logik wie NAND-Gatter mit einem MLP umsetzt. Die Ausdrucksstärke ist ausreichend; die offene Frage ist nur, wie wir nützliche Funktionen, die wir nicht direkt selbst schreiben können, in solche Gewichte kodieren.
Wenn das Modell sich anhand seiner Trainingsdaten neu erzeugen könnte, wäre das in Ordnung, aber dann wären Iterationszeit und Kosten derzeit viel zu hoch und damit unrealistisch. Alternativ müsste es seine eigenen Gewichte sinnvoll verändern können, und das erscheint unmöglich.
Der wirklich schwierige Punkt hier ist: „Was genau ist eigentlich der Unterschied zwischen beidem?“ Ich würde empfehlen, darüber gründlich nachzudenken und die eigene Antwort anschließend selbst zu widerlegen. Das ist viel verwirrender, als es zunächst scheint.
Was mich an heutigen AI-Systemen wirklich enttäuscht, ist das Fehlen kontinuierlichen Retrainings über kurze Feedback-Loops. Das wäre sicher teuer, aber in biologischen Systemen passiert genau das ganz natürlich. So etwas tatsächlich zu sehen, wäre wirklich großartig.
Das ist gewissermaßen wie nächtliches Training an jedem einzelnen Tag. Man sagt ja auch, dass das menschliche Gehirn im Schlaf Erfahrungen verarbeitet; bei LLMs wäre das eine Art „nächtliches Lernen“, bei dem Informationen, die aus dem Kontextfenster herausgefallen sind, per Finetuning wieder aufgenommen werden.
Tatsächlich wird in diese Richtung bereits geforscht. Mit einer Mixture-of-Experts-Architektur kann man ein Netzwerk in Chunks aufteilen, wobei jeder Chunk eine gemeinsame Schnittstelle nutzt und Ergebnisse an die anderen weitergibt. Diese Chunks lassen sich einzeln trainieren, allerdings ohne festes Trainingsset. Wenn man darüber hinaus die Struktur mathematisch anders fasst, etwa mit Kategorientheorie, wird sogar ein vollständig dynamisches Netzwerk möglich. Aber jedes Mal, wenn sich die Struktur ändert, kommt man um Retraining nicht herum. Am Ende braucht man reale Daten aus der echten Welt und eine Loss-Funktion, also Konkurrenz zu anderen Netzwerken. Das menschliche Gehirn ist in dieser Hinsicht bereits am besten mit der realen Welt gekoppelt. Noch ergänzend: Unsere Neuronen haben nicht nur Gewichte; ihre Aktivierung hängt auch davon ab, wann genau Eingaben eintreffen, also von Zeitdifferenzen im Nanosekundenbereich. So etwas ist in der IT derzeit noch schwer nachzubilden. Theoretisch halte ich es aber für möglich, und ich experimentiere aktuell damit, ein vierdimensionales Lebewesen als dynamischen Computing-Graphen in einer virtuellen Umgebung umzusetzen. Das ist hochspannend, aber weit von Produktionsreife entfernt.
In der Arbeit besonders bemerkenswert war die Beobachtung, dass DGM seine eigene Belohnungsfunktion gehackt hat. Auffällig war, dass trotz Einführung einer Belohnungsfunktion zur Unterdrückung von „Tool-Use-Halluzinationen“ DGM den Marker für diese Belohnungserkennung entfernte und so fälschlich als erfolgreich bewertet wurde. Ein bisher eher theoretisch diskutiertes Phänomen wurde damit empirisch gezeigt.
Im Zusammenhang mit AI Safety finde ich es bemerkenswert, dass man immer noch Hoffnung in diesen Ansatz setzt, obwohl doch absehbar ist, dass selbst die Schutzmechanismen gegen Reward Hacking erneut gehackt werden. Seit ich die eindrucksvolle Erklärung aus Rob Miles’ AI-Safety-YouTube-Videos gehört habe, etwa diesem Video, erscheint mir dieses Verhalten eher selbstverständlich.
Laut der Arbeit dauert schon ein einzelner Lauf von DGM auf SWE-bench zwei Wochen, und die API-Kosten sind mit $22,000 enorm hoch.
Der technische Bericht ist über den arXiv-Link zum Paper verfügbar. Eine Referenzimplementierung auf GitHub gibt es auch hier. Nützlich als Referenz.
Der Großteil der aktuellen Forschung folgt einem Distillation-Ansatz, bei dem große und teure Modelle kleinere Modelle trainieren. Interessant an dieser Arbeit ist dagegen, dass ein kleines/älteres/günstigeres Modell genutzt wurde, um die Leistung eines größeren Modells zu verbessern. Wenn sich das verallgemeinern lässt, wäre das ein Signal dafür, dass Endnutzer ihre eigenen Inferenzkosten stark senken könnten.
Das Paper verbessert in Wirklichkeit nicht das Modell selbst, sondern die Software darum herum. Wichtig ist, dass sich dieser Effekt softwareseitiger Verbesserungen auf verschiedene Modelle übertragen lässt, also nicht nur auf die Eigenheiten eines einzelnen Modells zugeschnitten ist. Beim Distillation-Ansatz bringt ein großes LLM einem kleinen LLM in der Regel die gesamte Token-Verteilung bei, und das geht schnell.
Hier geht es nicht um eine Verbesserung der Modellgewichte selbst, sondern um Änderungen an dem „Harness“, also dem umhüllenden Code, der das LLM aufruft. Dieser Teil bleibt auch dann weiterverwendbar und verallgemeinerbar, wenn noch stärkere LLMs erscheinen. Selbst wenn ein neues LLM kommt und das Harness nicht neu abgestimmt wird, lassen sich die bis dahin angesammelten Verbesserungen weiterhin nutzen.