💬 NLP

Learning to Ideate for Machine Learning Engineering Agents

Das Papier stellt MLE-Ideator vor, ein Dual-Agent-Framework, das strategische Ideenfindung von der Implementierung trennt, um die Leistung im Machine-Learning-Engineering signifikant zu steigern, wobei es zeigt, dass ein durch Reinforcement Learning trainierter Ideator sowohl ungeschulte Baselines als auch führende kommerzielle Modelle wie Claude Sonnet 3.5 übertrifft.

Ursprüngliche Autoren: Yunxiang Zhang, Kang Zhou, Zhichao Xu, Kiran Ramnath, Yun Zhou, Sangmin Woo, Haibo Ding, Lin Lee Cheong

Veröffentlicht 2026-01-27

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Yunxiang Zhang, Kang Zhou, Zhichao Xu, Kiran Ramnath, Yun Zhou, Sangmin Woo, Haibo Ding, Lin Lee Cheong

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie versuchen, eine komplexe Maschine zu bauen, wie zum Beispiel ein Hochleistungs-Rennauto, aber Sie haben nur einen sehr talentierten Mechaniker, der zwar großartig darin ist, Schraubenschlüssel zu drehen, sich aber manchmal dabei verliert, was als Nächstes zu reparieren ist.

Dieses Paper stellt eine neue Methode vor, die KI-Agenten dabei hilft, Machine-Learning-Modelle zu bauen. Sie nennen ihr System MLE-IDEATOR. So funktioniert es, aufgeschlüsselt in einfache Konzepte:

Das Problem: Der „festgefahrene Mechaniker“

Normalerweise arbeiten KI-Agenten, die Machine-Learning-Modelle bauen sollen, alleine. Sie sind wie ein Mechaniker, der versucht, ein Auto zu reparieren, etwas ausprobiert und wenn es nicht sofort perfekt funktioniert, aufgibt oder aufhört, neue Dinge auszuprobieren. Sie sind gut darin, Code zu schreiben (den Schraubenschlüssel zu drehen), aber sie haben Schwierigkeiten, neue Strategien zu entwickeln, um das Auto schneller zu machen. Sie geben sich oft mit einer „gut genug“ Lösung zufrieden, anstatt nach der „bestmöglichen“ zu streben.

Die Lösung: Der „strategische Coach“

Die Autoren teilen die Aufgabe in zwei unterschiedliche Rollen auf und schaffen so ein Team aus zwei Agenten:

Der Implementer (Der Mechaniker): Dieser Agent ist derjenige, der tatsächlich den Code schreibt, die Tests durchführt und das Modell baut. Er ist der „Macher“.
Der IDEATOR (Der strategische Coach): Dies ist ein dedizierter Agent, dessen einzige Aufgabe das Denken ist. Er schreibt keinen Code. Stattdessen beobachtet er den Mechaniker bei der Arbeit. Wenn der Mechaniker feststeckt oder gegen eine Wand läuft, hebt er die Hand (unter Verwendung einer speziellen Aktion namens <seek_help>) und bittet den Coach um Rat.

Die Analogie:
Stellen Sie sich den Implementer als einen Schachspieler vor, der sehr gut darin ist, die Figuren zu bewegen, aber manchmal die Gewinnstrategie übersieht. Der IDEATOR ist ein Großmeister, der neben ihm sitzt. Der Spieler bittet den Großmeister nicht, die Figuren zu bewegen, sondern fragt lediglich: „Was soll ich als Nächstes tun?“ Der Großmeister sieht sich das Brett an und sagt: „Ziehe deinen Springer hierher, denn das wird den Gegner in die Falle locken.“ Der Spieler führt dann diesen Zug aus.

Wie sie lernten, besser zu werden (Der Teil mit dem „Training“)

Das Paper zeigt auch, wie sie den „Coach“ (IDEATOR) dazu gebracht haben, besseren Rat zu geben.

Vorher: Der Coach erhielt lediglich einen Satz von Regeln (Prompts), denen er folgen sollte. Das war okay, aber nicht perfekt.
Nachher: Sie verwendeten eine Methode namens Reinforcement Learning (Bestärkendes Lernen). Stellen Sie sich ein Videospiel vor, in dem der Coach einen „Punkt“ erhält, jedes Mal, wenn sein Rat dem Mechaniker hilft, ein schnelleres Auto zu bauen. Wenn der Rat zu einem Unfall führt oder keine Verbesserung bewirkt, erhält der Coach einen „Abzug“.
Das Ergebnis: Nachdem der Coach dieses „Spiel“ mit nur 1.000 Beispielen gespielt hatte (eine sehr geringe Menge für eine KI), wurde er unglaublich klug. Er lernte, keine generischen Ratschläge wie „Versuch es mal intensiver“ mehr zu geben, sondern spezifische, hochwirksame Vorschläge wie „Ändere dieses spezifische Datenmerkmal“.

Die großen Erfolge

Die Autoren testeten dieses System auf einem Benchmark namens MLE-Bench (eine Sammlung von realen Machine-Learning-Herausforderungen).

Teamwork gewinnt: Allein dadurch, dass ein Coach vorhanden war (selbst wenn dieser nicht speziell trainiert wurde), konnte der Mechaniker viel besser arbeiten als alleine.
Kleines Gehirn, große Wirkung: Sie trainierten ein relativ kleines KI-Modell (Qwen3-8B), um der Coach zu sein. Überraschenderweise gab dieser kleine, trainierte Coach bessere Ratschläge als ein viel größeres, leistungsfähigeres KI-Modell (Claude Sonnet 3.5), das lediglich Anweisungen erhielt, aber nicht mit den „Spiel“-Belohnungen trainiert wurde.
Bessere Ideen: Der trainierte Coach lernte, sich auf die richtigen Dinge zu konzentrieren. Er erkannte, dass das Ändern der Daten oder Features (wie die Kraftstoffzufuhr des Autos) oft effektiver war als nur das Tuning des Modells (das Verstellen des Motors).

Die Kehrseite (Einschränkungen)

Das Paper ist ehrlich bezüglich der Nachteile:

Es kostet mehr: Es verbraucht mehr Rechenleistung und Zeit, wenn zwei Agenten miteinander kommunizieren, als wenn nur ein einzelner Agent alleine arbeitet.
Das Training ist schwerfällig: Den Coach gut zu trainieren, erfordert das Durchführen vieler Tests auf leistungsstarken Computern (GPUs), um zu sehen, ob die Ideen funktionieren, was viel Energie und Ressourcen verbraucht.

Zusammenfassung

Kurz gesagt: Dieses Paper beweist, dass man deutlich bessere Ergebnisse erzielt, wenn man die Aufgabe des Ideenfindens von der Aufgabe des Ausführens trennt. Indem man einen kleinen „Coach“ trainiert, strategischen Rat basierend auf dem zu geben, was tatsächlich funktioniert, kann man einem „Mechaniker“ helfen, bessere Machine-Learning-Modelle zu bauen, als wenn er alleine arbeiten würde.

Technisches Resümee: Lernen zur Ideenfindung für Machine-Learning-Engineering-Agenten

Problemstellung

Bestehende Agenten für Machine-Learning-Engineering (MLE), die typischerweise auf Large Language Models (LLMs) basieren, stehen vor einer kritischen Einschränkung: Sie haben Schwierigkeiten, implementierte Algorithmen iterativ auf Effektivität zu optimieren. Während diese Agenten bereits Fortschritte in der Softwareentwicklung gemacht haben, stellen ihre Standarddesigns oft die Exploration ein, sobald eine einzige gültige Lösung gefunden wurde. In MLE-Aufgaben ist eine lediglich gültige Lösung jedoch unzureichend; das Fachgebiet erfordert strategische Iteration – das Testen alternativer Modelle, das Verfeinern von Hyperparametern und das Optimieren von Datenmerkmalen, um State-of-the-Art-Ergebnisse zu erzielen.

Derzeitige Ansätze zur strategischen Iteration verlassen sich oft auf Single-Agent-Paradigmen, die strategisches Denken (Ideenfindung) mit Programmierkompetenz (Implementierung) vermengen. Diese Vermengung erzeugt einen Zielkonflikt: Kleine Sprachmodelle (SLMs) mangelt es an der Programmierkapazität, um komplexe Lösungen zu implementieren, während das Training von ihnen, beide Fähigkeiten mittels Reinforcement Learning (RL) zu meistern, ineffiziente Multi-Turn-Rollouts mit spärlichen Belohnungen (sparse rewards) erfordert. Zudem verlassen sich bestehende Multi-Agenten-Frameworks oft auf starre, prompt-gesteuerte Workflows anstatt auf dynamische, kontextbewusste Kollaboration.

Methodik: MLE-IDEATOR

Um diese strukturellen Einschränkungen zu adressieren, führen die Autoren MLE-IDEATOR ein, ein Dual-Agenten-Framework, das die hochgradige Ideenfindung explizit von der niedergradigen Implementierung entkoppelt.

1. Dual-Agenten-Architektur

Das System besteht aus zwei distinkten Agenten:

Der Implementer: Verantwortlich für die Ausführung von Code (Python/Bash) und die Verwaltung der ML-Pipeline. Er wird unter Verwendung des CodeAct-Agenten-Frameworks instanziiert.
Der IDEATOR: Ein dedizierter Agent, der für die Bereitstellung hochgradiger strategischer Vorschläge verantwortlich ist.

Interaktionsmechanismus:
Das Framework führt eine neue Aktion ein, <seek_help>, die der Implementer aufrufen kann, wenn die Leistung stagniert oder wenn er eine potenzielle Optimierungsmöglichkeit identifiziert. Der Implementer sendet eine strukturierte Abfrage, die die Problemstellung, die bisherigen Versuche und das Ziel enthält. Der IDEATOR antwortet mit einem strukturierten Output, der Folgendes enthält:

Analyse (Analysis): Ob der aktuelle Ansatz verfeinert oder zu einer vorherigen Lösung zurückgekehrt werden sollte.
Aktion (Action): Ein spezifischer imperativer Befehl oder ein Codeblock, der als Nächstes auszuführen ist.
Begründung (Rationale): Eine prägnante Rechtfertigung für die vorgeschlagene Aktion.

Dieses Design ermöglicht „Superalignment“, bei dem ein leichtgewichtiger IDEATOR einen leistungsfähigeren Implementer leitet, ohne dass das Retraining des Implementers selbst erforderlich ist.

2. RL-Trainingspipeline (MLE-IDEATOR-RL)

Um die Fähigkeit des IDEATOR zu verbessern, schlagen die Autoren eine effiziente Reinforcement-Learning-Pipeline vor, die den IDEATOR mittels ausführungsbasierter Belohnungen optimiert und so kostspielige Multi-Step-Rollouts vermeidet.

Zustandsraum ( $s_t$ ): Umfasst die Aufgabenbeschreibung, den vollständigen Trajektorienverlauf der Aktionen und Beobachtungen des Implementers, den aktuellen Leistungs-Score und den vollständigen Lösungscode.
Aktionsraum ( $\alpha$ ): Die Generierung eines strukturierten natürlichen Sprachvorschlags (Analyse, Aktion, Begründung).
Belohnungsfunktion ( $R_t$ ): Eine diskrete, dreistufige Belohnung wird basierend auf dem Ergebnis der Ausführung des IDEATOR-Vorschlags in einem einzigen Schritt durch einen eingefrorenen (frozen) Implementer zugewiesen:
- +1: Wenn die neue Leistung ( $p_{t+1}$ ) die vorherige Leistung ( $p_t$ ) übersteigt.
- 0: Wenn sich die Leistung nicht verbessert oder die Ausführung fehlschlägt.
- -1: Wenn das Ausgabeformat ungültig ist.
Trainingsalgorithmus: Die Autoren verwenden den GRPO-Algorithmus (Group Relative Policy Optimization). Der Prozess beinhaltet das Sampling von Kandidatenideen aus der aktuellen Policy, deren parallele Ausführung über einen eingefrorenen Implementer zur Berechnung der Belohnungen und die anschließende Aktualisierung der Policy-Parameter des IDEATOR. Dieser Ansatz minimiert die Abhängigkeit von teuren Multi-Step-Rollouts.

Zentrale Beiträge

Neuartiges Framework: Einführung von MLE-IDEATOR, einem Dual-Agenten-System, das die strategische Ideenfindung von der Implementierung trennt und so eine effiziente Exploration des Ideenraums ohne kostspielige Tree-Search-Orchestrierung ermöglicht.
Effiziente RL-Pipeline: Design einer Trainingspipeline für den IDEATOR unter Verwendung von ausführungsbasierten Belohnungen und GRPO, welche die Qualität der Ideen optimiert und gleichzeitig den Rechenaufwand für die vollständige Regeneration der Agenten-Trajektorie vermeidet.
Leistungsvalidierung: Demonstration, dass ein durch RL trainiertes kleines Modell (Qwen3-8B) sowohl seinem ungetrainierten Gegenstück als als auch signifikant stärkeren proprietären Modellen (Claude Sonnet 3.5) überlegen ist, wenn es als strategischer Guide für einen Implementer fungiert.

Experimentelle Ergebnisse

Die Experimente wurden auf dem MLE-Bench Datensatz durchgeführt, wobei 10 diverse Kaggle-Aufgaben für das Training und 51 gehaltene Aufgaben (held-out tasks) für die Evaluierung genutzt wurden.

Prompted Ideation: Selbst ohne RL-Training übertraf die Paarung eines Implementers mit einem durch Prompting gesteuerten IDEATOR (unter Verwendung von Claude Sonnet 3.5) die reinen Implementierungs-Baselines signifikant. Beispielsweise stieg der Avg@3-Score eines Claude Sonnet 3.5 Implementers von 50,6 (CodeAct Baseline) auf 58,5.
RL-gesteigerte Verbesserung: Der RL-trainierte Qwen3-8B IDEATOR erreichte eine relative Verbesserung von 11,5 % gegenüber seinem ungetrainierten, durch Prompting gesteuerten Gegenstück.
Übertreffen stärkerer Modelle: Der RL-trainierte Qwen3-8B IDEATOR (Best@3 Score von 63,1) übertraf den leistungsstarken, nicht-RL-trainierten Claude Sonnet 3.5 IDEATOR (Best@3 Score von 60,9), wenn beide mit demselben Implementer gekoppelt wurden.
Analyse der Ideenqualität: Ablationsstudien bestätigten, dass die Leistungssteigerungen durch die Qualität der Ideen und nicht bloß durch die Interaktion getrieben werden. „NULL IDEA“ (keine Anleitung) und „VAGUE IDEA“ (generische Ermutigung) lieferten im Vergleich zu spezifischen, kontextuellen Vorschlägen minimale Gewinne.
Strategischer Shift: Das RL-Training verschob die Verteilung der generierten Ideen hin zu empirisch effektiven Kategorien. Der RL-trainierte Modell erhöhte seinen Fokus auf Feature Engineering (+7,5 %) und Datenpräparation (+3,1 %), während weniger effektive Vorschläge wie Modelltraining und Hyperparameter-Tuning reduziert wurden.

Bedeutung und Ansprüche

Das Paper postuliert, dass die Entkopplung von Ideenfindung und Implementierung ein vielversprechender Weg zur Ausbildung strategischer KI-Systeme für wissenschaftliche Entdeckungen ist. Durch die Trennung des „Was“ (Strategie) vom „Wie“ (Implementierung) können kleine Modelle effizient lernen, stärkere Modelle zu leiten, was sie effektiv zu einem wiederverwendbaren Plug-in macht, um die Performance zu steigenern.

Die Autoren heben hervor, dass dieser Ansatz ein skalierbares Rezept bietet, um LLM-Agenten beizubringen, hochwirksame Ideen zu generieren. Die Ergebnisse legen nahe, dass mit minimalen Trainingsdaten (1K Samples aus 10 Aufgaben) ein RL-trainierter IDEATOR seine Generierungsprozesse mit hochwirksamen Strategien in Einklang bringen kann, was potenziell Aspekte der KI-Forschung und des Engineerings automatisiert, die derzeit menschliche Intuition erfordern.

Angemerkte Limitationen:
Die Autoren räumen ein, dass das Framework aufgrund zusätzlicher Schritte und erweiterter Kontextlängen höhere Inferenzkosten verursacht. Zudem ist der RL-Trainingsprozess ressourcenintensiv, da die vollständige Ausführung von ML-Lösungen zur Berechnung der Belohnungen erforderlich ist, wenngleich sie vorschlagen, dass zukünftige Arbeiten dies mittels Proxy-Belohnungsmodellen mildern könnten.