Autoresearch auf eine alte Forschungsidee anwenden

• Das Autoresearch-System ist als Constraint-Optimization-Loop aufgebaut, in dem ein LLM-Agent wiederholt train.py modifiziert und so die Leistung verbessert; der Zyklus von der Hypothesenbildung bis zur Auswertung läuft dabei automatisch ab
• Die Experimente laufen in einer containerbasierten Sandbox-Umgebung, die Netzwerkzugriff und die Ausführung beliebigen Codes blockiert
• Mit dem Ukiyo-eVG-Datensatz wurden rund 11.000 japanische Holzschnittbilder samt Annotationsdaten für das Training genutzt; ein CLIP-basiertes Modell erreichte Mean Rank 34.30 und R@5 von etwa 53 %
• Die wichtigsten Verbesserungen waren die Lockerung des temperature-Parameters (-113 Mean Rank) und Hyperparameter-Tuning (-30 Mean Rank); bei 42 Experimenten an einem Tag wurde mit 13 Commits eine Leistungssteigerung von 54 % erzielt
• LLM-Agenten sind in klar definierten Suchräumen effektiv, doch nach der Phase von Strukturänderungen nahm die Instabilität zu, was die Grenzen vollständig autonomer Forschung offenlegte

---

Kerngedanke

• Autoresearch ist als Constraint-Optimization-Loop um einen LLM-Agenten herum aufgebaut; der Agent verändert train.py und verbessert dabei wiederholt die Evaluationsmetriken
  • Der Agent liest die Anweisungen in program.md und nutzt scratchpad.md als Arbeitsnotizen, um den Experimentverlauf festzuhalten
• Die Suche besteht aus mehreren Phasen; zunächst beginnt sie mit Hyperparameter-Tuning, geht dann zu kleineren Strukturänderungen über und erweitert sich später zu einer freieren Suche mit minimalen Einschränkungen
• Der gesamte Loop ist als Zyklus Hypothese aufstellen → Code ändern → trainieren → evaluieren → committen oder zurückrollen → wiederholen entworfen
• Jedes Experiment ist auf einen Abschluss in etwa 5 Minuten begrenzt, um schnelle Iterationen zu fördern und Overfitting zu vermeiden
• Der Agent darf train.py innerhalb des Zeitlimits frei verändern

• Sandboxing

  • Um Risiken durch die Ausführung beliebigen Codes zu vermeiden, läuft der Trainings-Loop in einer Container-Umgebung, und der Netzwerkzugriff ist blockiert
  • run.sh verwaltet den gesamten Experimentablauf; Claude Code darf nur train.py und program.md ändern
  • Direkte Python-Ausführung, pip-Installationen, Netzwerkzugriff, git push usw. sind sämtlich eingeschränkt
  • Die zugehörige Implementierung ist im GitHub-Repository öffentlich zugänglich

Datensatz

• Da kein Zugriff auf den im ursprünglichen Paper verwendeten medizinischen Röntgendatensatz möglich war, wurde stattdessen der Ukiyo-eVG-Datensatz verwendet
  • Er enthält rund 11.000 japanische Holzschnittbilder und Phrase-Bounding-Box-Annotationen
  • Die Bounding Boxes wurden in Gaussian Heatmaps umgewandelt und als zusätzlicher Modelleingang genutzt, ähnlich dem Expert-Attention-Mechanismus aus dem ursprünglichen eCLIP-Paper
• Die Heatmaps sollen das Modell dazu bringen, sich auf bestimmte Bereiche zu konzentrieren

Versuchsaufbau mit Claude Code

• Claude Code aktualisierte den bestehenden Forschungscode auf eine aktuelle Python-Umgebung und schrieb das Laden des neuen Datensatzes sowie das Scaffolding für den Experiment-Loop
• Außerdem wurden Cross-Validation-Splits, Evaluationslogik und die anfänglichen Ideen in program.md eingerichtet
• Als Evaluationsmetrik wurde Mean Rank verwendet; im Abschlussbericht wurde zusätzlich Recall@K angegeben
  • Mean Rank diente einer intuitiven Beurteilung, allerdings wird erwähnt, dass Median Rank wegen geringerer Empfindlichkeit gegenüber Ausreißern wohl geeigneter gewesen wäre
• Modellaufbau: CLIP-Backbone mit ViT-Small (22M) + DistilBERT (66M) + HeatmapProcessor, insgesamt rund 90M Parameter
  • Training: 800 Steps (etwa 3 Minuten pro Experiment auf einer RTX 4090)
  • Evaluation: Messung von Mean Rank und Recall@K auf einem Testset mit 1.000 Bildern
  • Baseline-Leistung: Val Mean Rank 344.68, img→txt R@1 17,2 %, txt→img R@1 16,5 %

Experimentergebnisse

• An einem Tag wurden insgesamt 42 Experimente durchgeführt, davon 13 Commits und 29 Rollbacks
  • Der Mean Rank sank von 344.68 auf 157.43, also um 54 %
• Beim abschließenden Training auf dem vollständigen Datensatz lagen die Testwerte höher als die Validierungswerte
  • Das deutet darauf hin, dass die kurzen Experimente mit 800 Steps unterfittet waren
• Endgültige Testleistung: Mean Rank 34.30, img→txt R@5 53,0 %, txt→img R@5 51,4 %

Wichtige Verbesserungspunkte

• Anpassung des Temperature-Clampings (-113 Mean Rank)

  • Im Code war der trainierbare temperature-Parameter auf 2 fixiert; der Agent lockerte diese Begrenzung und verbesserte die Leistung dadurch deutlich
  • Das war der größte einzelne Effekt im gesamten Verbesserungsprozess

• Optuna++ (-30 Mean Rank)

  • Spätere Verbesserungen kamen vor allem durch Hyperparameter-Tuning
  • Eine größere Projektionsdimension und eine Neujustierung der Lernrate brachten weitere 30 Punkte Verbesserung
  • Der Agent erledigte die für Menschen oft monotone Wiederholungsarbeit schneller und systematischer

• Bereich abnehmender Erträge

  • Ab Phase 4 (Strukturänderungen) sank die Erfolgsquote der LLM-Hypothesen stark
  • Änderungen am Attention-Mechanismus oder moonshot-Ideen scheiterten meist
  • In der späteren Suchphase gab es viele eher zufällige Versuche

• Bedeutung der Sandbox

  • Claude Code zeigte gelegentlich instabiles Verhalten, etwa indem es Berechtigungen vergaß, fehlerhafte Bash-Aufrufe versuchte oder während des Wartens auf das Training den Loop unterbrach
  • Für eine vollständig autonome Ausführung gibt es noch klare Grenzen

Abschließende Beobachtungen

• Über den gesamten Prozess hinweg verliefen die ersten 90 % reibungslos, während die letzten 10 % viel Eingriff erforderten
• Ein LLM-Agent kann innerhalb eines klar definierten Suchraums effektiv ML-Forschung betreiben
• Der Commit-Rollback-Loop von Autoresearch ist als strukturierte Suchstrategie nützlich
• Bei der Ausweitung auf unbekanntes Terrain wird der Optimierungs-Loop jedoch instabil
• Die Einschränkung, pro Experiment nur eine Änderung zuzulassen, könnte für die Erkundung größerer Ideenräume zu streng gewesen sein
  • Als künftige Verbesserungen werden eine zusätzliche Planungsphase oder die Einführung von Subagenten vorgeschlagen
• Nach Ende der Experimente kehrte die Zusammenarbeit mit Claude Code wieder in den Alltag zurück

Danksagung

• Ukiyo-eVG-Datensatz: rund 11K japanische Holzschnittbilder mit Phrase-Bounding-Box-Annotationen
• Autoresearch: basiert auf der ursprünglichen Idee von Andrej Karpathy

[GN⁺]

Hacker-News-Kommentare

• Falls der Hauptlink langsam ist, wird empfohlen, die archive.is-Version zu versuchen

• Ich nutze LLMs oft, um bestehende Forschung zu erkunden oder über Probleme auf andere Weise nachzudenken
  90 % der Ergebnisse passen nicht zu meiner Domäne, aber die restlichen 10 % waren ziemlich nützlich
  Einen Agenten zu haben, der alles tatsächlich ausprobiert, was ein LLM empfiehlt, ist aber zu teuer ($$$)
  In den Vorschlagslisten sind oft viele nicht mehr gepflegte Nischenbibliotheken
  Andererseits machen die „Fachberater“ in Unternehmen ähnlich absurde Vorschläge, also hätte ich lieber einen Agenten, der sich stattdessen mit ihnen herumschlägt

  • Der Wert eines Agenten liegt darin, dass er automatisch Experimente wiederholen kann, während der Nutzer Pause macht
    Sinnvoll ist das aber nur, wenn ein einzelner Test schnell ist. In meiner Arbeit dauert ein Test einen halben Tag, daher ist es schwer, so etwas über Nacht laufen zu lassen
  • Mich würde interessieren, in welcher Domäne du arbeitest
  • Ich habe das Gefühl, dass LLMs nützlich sind bei kurzen Sätzen, die man sich nicht merken will, oder bei Teilen, bei denen Fehler egal sind
    Wenn ich Leute sehe, die Dinge wie MCP-Server oder AGENTS.md einrichten, wirkt das für mich wie ein Beleg dafür, dass LLMs nicht wie beworben funktionieren
    Wenn man sie gut auf einen bestimmten Workflow abstimmt, sind sie großartig, aber ich bezweifle, dass sich das skalieren lässt
    Kann das ein tragfähiges Geschäftsmodell sein, wenn nicht enorme Geldsummen Training und Infrastruktur stützen?
  • Die Kosten könnten das Problem sein. Ich nutze Claude Code eher leichtgewichtig, und selbst im Max-Plan gehen mir die Tokens kaum aus

• Die Formulierung „der Agent verhielt sich wie ein Hyperparameter-Optimierungsalgorithmus“ fand ich eindrucksvoll
  Der Kern ist im Grunde eine einzige System-Prompt-Datei namens program.md, die „train.py verbessern → Training ausführen → evaluieren → Ergebnisse protokollieren“ wiederholt
  Der Rest ist einfach ein beliebiges ML-Modell

• Ein LLM mit laufendem Code zu füttern und es wiederholt Bugs beheben, Performance messen und Testabdeckung bewerten zu lassen, ist in unserem Team der Standardansatz
  Bei jeder Iteration ein anderes Modell zu verwenden, gefiel mir, weil es sich anfühlte, als bekäme man neue Blickwinkel

  • Ich frage mich, ob man diesen Ansatz auf das Training eines lokalen LLMs anwenden könnte, das auf eine bestimmte Sprache oder ein bestimmtes Framework spezialisiert ist

• Ich habe mich gefragt, warum „Autoresearch“ so viel Aufmerksamkeit bekommen hat
  Ich dachte immer, der Flaschenhals in AI/ML seien Datenqualität oder Rechenressourcen, und ich weiß nicht, ob das hier daran etwas verbessert

  • Tatsächlich gab es solche Versuche schon früher. Das Feld AutoML ist ein Beispiel, in der Praxis hat es aber nicht gut funktioniert
    Es gab auch Ansätze wie Bayesianische Optimierung oder Gaussian Processes, aber am Ende war Random Search besser
    Der Unterschied bei LLMs ist, dass sie Literatur lesen und vernünftig schlussfolgern können
    Es ist nicht perfekt, aber möglicherweise besser als bestehende Methoden
  • Der Unterschied ist, dass es über einfaches Hyperparameter-Tuning hinaus auch nichtparametrische Strukturänderungen ermöglichen kann
    Es ist kein völlig neues Konzept, aber offenbar hofft man, dass es weniger brute-force ist
  • Es gibt zwar bestehende Verfahren wie „Swarm optimization“, aber LLMs unterscheiden sich dadurch, dass sie vergangene Forschung gelernt haben und sich auf wichtige Achsen konzentrieren können
    Das heißt, ein LLM kann Forschung, die bereits jemand gemacht hat, nutzen
  • Ich stimme der Aussage nicht zu, dass „Daten oder Compute der Flaschenhals“ seien
    Im Kern geht es bei ML darum, für dieselben Eingaben X eine bessere Funktionsabbildung zu finden
    Das lässt sich nicht einfach durch mehr Compute lösen
  • Letztlich ist Autoresearch ein Ansatz, bei dem man das Denken selbst an ein LLM delegiert

• Unterm Strich hat es funktioniert. Das LLM hat Bugs gefunden und Optimierungen durchgeführt

  • In der Praxis kamen die meisten Verbesserungen allerdings durch Bugfixes + Optuna-Tuning
    So etwas lässt sich auch mit Claude Code schnell machen
    Der eigentliche Wert von Autoresearch liegt wohl in der Architekturerkundung
    Mich würde interessieren, ob jemand Erfahrung damit in explorativem Modeling hat

• Wenn man sich das Commit-Log (GitHub-Link) ansieht, war das meiste Hyperparameter-Tuning
  Dafür wären mir die Token-Kosten ($$$) zu schade

  • Es wäre wohl effizient, zu Autoresearch einen Schritt zur Kostenschätzung und Priorisierung hinzuzufügen, damit ein Mensch es vor der Ausführung prüft
    Man könnte das verbessern, indem man mit LoRa-Adaptern Kosten-Feedback gibt
  • Tatsächlich geht das auch mit Open-Source-Tools wie Optuna oder skopt ohne GPU

• Im Originalpaper wurden medizinische X-Ray-Daten verwendet, aber mangels Zugriff wurden sie durch Ukiyo-eVG (11K japanische Holzschnitte) ersetzt
  Das wirkte wie ein merkwürdiger Wechsel. Frei verfügbare medizinische Bilddaten gibt es auch im Cancer Imaging Archive

  • Stimmt. Allerdings war es mir unangenehm, medizinische Daten einem Agenten anzuvertrauen, und ich wollte Domain Transfer ausprobieren

• Ich hatte gehofft, dass jemand solche Experimente machen würde, und habe mich gefreut, dass es tatsächlich jemand getan hat
  Die Stelle „Ich war es leid, auf das Ende des Trainings zu warten, und habe den Dialog beendet“ war lustig
  Danke fürs Teilen der Ergebnisse

  • Danke, ich habe geantwortet, dass ich es mit Vergnügen gelesen habe

• Das ist weniger automatisierte Forschung als vielmehr strukturierte Versuch-und-Irrtum-Arbeit
  Letztlich ist der Kern die Qualität der Evaluationsmetrik. Wenn die schwach ist, optimiert man nur schneller in die falsche Richtung

  • Eine gute Fitness-Funktion zu entwerfen, war schon immer schwierig
  • Manche meinen, genau das sei letztlich die wissenschaftliche Methode