🤖 machine learning

iML: Executable, Problem-Grounded, and Broadly Exploratory Code-Driven AutoML

Das Paper stellt iML vor, ein Multi-Agenten-Code-getriebenes AutoML-Framework, das durch strukturierte Blueprints und iteratives Debugging ausführbare, problemorientierte und breit explorative Lösungen gewährleistet und dabei eine State-of-the-Art-Leistung sowie eine hohe Zuverlässigkeit bei diversen Machine-Learning-Benchmarks erzielt.

Ursprüngliche Autoren: Dat Le, Duc-Cuong Le, Anh-Son Nguyen, Tuan-Dung Bui, Thu-Trang Nguyen, Son Nguyen, Hieu Dinh Vo

Veröffentlicht 2026-06-02

📖 5 Min. Lesezeit🧠 Tiefgang

CC0 1.0

Ursprüngliche Autoren: Dat Le, Duc-Cuong Le, Anh-Son Nguyen, Tuan-Dung Bui, Thu-Trang Nguyen, Son Nguyen, Hieu Dinh Vo

Originalarbeit unter CC0 1.0 der Gemeinfreiheit gewidmet (http://creativecommons.org/publicdomain/zero/1.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 möchten eine komplexe Maschine bauen, wie etwa ein Hochleistungs-Rennauto, aber Sie wissen nicht, wie man Mechaniker ist. Sie bitten einen sehr intelligenten, belesenen, aber manchmal übermütigen Assistenten (eine KI), die Blaupausen zu schreiben und das Auto für Sie zu bauen.

In der Vergangenheit haben diese Assistenten oft Pläne entworfen, die auf dem Papier perfekt klangen, aber in dem Moment zusammenbrachen, als man versuchte, den Motor zu starten. Sie übersahen vielleicht, dass das Auto einen V6-Motor hat, obwohl man einen V8 erwartet hatte, oder sie vergaßen, die Räder festzuschrauben, weil sie zu sehr damit beschäftigt waren, eine wunderschöne Rede über Geschwindigkeit zu halten.

Dieses Paper stellt 𝑖ML vor, ein neues Team von KI-Assistenten, die darauf ausgelegt sind, genau diese Probleme zu lösen. Anstatt dass ein einzelner Assistent versucht, alles gleichzeitig zu erledigen, nutzt 𝑖ML ein Multi-Agenten-Team, das wie eine hochorganisierte Baustelle arbeitet. Ihr Ziel ist es, ein Modell für maschinelles Lernen (das „Auto“) zu bauen, das tatsächlich läuft, auf Basis der tatsächlich vorhandenen Materialien gebaut wurde und viele verschiedene Wege erkundet, um das Rennen zu gewinnen.

Hier ist die Funktionsweise von 𝑖ML, unterteilt in drei einfache Prinzipien:

1. Die „Läuft es auch wirklich?“-Regel (Exekutierbarkeit)

Die meisten KI-Assistenten schreiben Code, der im Text gut aussieht, aber abstürzt, wenn man versucht, ihn auszuführen. 𝑖ML betrachtet das Ausführen des Codes als den wichtigsten Test.

Die Analogie: Stellen Sie sich einen Koch vor, der nicht nur ein Rezept schreibt, sondern das Gericht auch tatsächlich kocht, probiert und – falls es zu salzig ist – es korrigiert, bevor er es dem Kunden serviert.
Wie 𝑖ML es macht: Das Team zerlegt die Aufgabe in kleine Teile (Datenaufbereitung, Modellbau). Sie bauen jeden Teil separat und versuchen dann, sie zusammenzusetzen. Wenn die Teile nicht zusammenpassen (wie ein quadratischer Steckstein in einem runden Loch), stoppt das System sofort, findet den exakten Fehler und behebt nur dieses eine Stück. Es probiert es immer wieder und repariert es, bis die gesamte Maschine reibungslos läuft. Dies stellt sicher, dass das Endergebnis in 90 % der Fälle tatsächlich funktioniert.

2. Die „Schau dir an, was du hast“-Regel (Problem-Grounding)

Manchmal erfinden KI-Assistenten Dinge dazu. Sie nehmen vielleicht an, dass Ihre Daten sauber sind, obwohl sie eigentlich unordentlich sind, oder sie nehmen an, dass Sie Verkaufszahlen vorhersagen wollen, während Sie eigentlich das Wetter vorhersagen möchten.

Die Analogie: Stellen Sie sich einen Bauunternehmer vor, der die Baupläne ignoriert, die Sie ihm gegeben haben, sowie den tatsächlichen Boden auf Ihrem Grundstück, und stattdessen beschließt, einen Swimmingpool zu bauen, weil er glaubt, dass Sie einen wollten.
Wie 𝑖ML es macht: Bevor es die erste Zeile Code schreibt, schickt 𝑖ML einen „Späher“ aus, um Ihre tatsächlichen Daten zu inspizieren. Es zählt die fehlenden Werte, prüft die Datentypen und schaut nach, was andere Experten bei ähnlichen Daten gemacht haben. Daraufhin erstellt es einen strengen Plan (einen „Blaupause“) basierend auf der Realität, nicht auf Vermutungen. Dies verhindert, dass das Team ein Modell baut, das zwar logisch fundiert, aber für Ihr spezifisches Problem nutzlos ist.

3. Die „Probiere alles aus“-Regel (Breite Exploration)

Alte AutoML-Systeme wählen oft einen Pfad und bleiben dabei, wie ein Fahrer, der nur Autobahnen kennt. Wenn die Straße zu einem Feldweg wird, bleibt er stecken.

Die Analogie: Stellen Sie sich einen Detektiv vor, der nur einen Verdächtigen überprüft. 𝑖ML ist wie ein Detektiv, der drei verschiedene Verdächtige befragt: einen, der traditionelle Methoden nutzt, einen, der High-Tech-Gadgets verwendet, und einen, der ein maßgeschneidertes Werkzeug benutzt.
Wie 𝑖ML es macht: Das Team wählt nicht nur einen Weg, um das Problem zu lösen. Es führt drei verschiedene Strategien parallel aus:
1. Traditionelle Methoden (zuverlässig, wie eine robuste Limousine).
2. Vortrainierte Modelle (Nutzung bestehender smarter Werkzeuge, wie ein Sportwagen).
3. Maßgeschneiderte neuronale Netze (Bau eines einzigartigen, individuellen Motors von Grund auf).
  Sie testen alle drei, sehen, welches das Rennen gewinnt, und wählen den Sieger. Wenn einer scheitert, geben sie nicht auf, sondern wechseln einfach zur nächsten besten Option.

Die Teamstruktur

Um dies zu ermöglichen, organisiert 𝑖ML seine KI-Agenten in spezifische Rollen:

Der Stratege: Liest das Problem und inspiziert die Daten, um den Masterplan zu erstellen.
Die Spezialisten: Verschiedene Agenten schreiben den Code für spezifische Teile (einer für die Datenbereinigung, einer für den Modellbau), damit sie sich nicht gegenseitig verwirren.
Der Assembler & Debugger: Sie setzen die Teile zusammen, testen sie, und falls etwas bricht, agieren sie wie ein Mechaniker mit einem Diagnosegerät, um genau den defekten Bolzen zu finden und zu reparieren, ohne das ganze Auto neu bauen zu müssen.

Die Ergebnisse

Die Autoren haben dieses System mit zwei schwierigen Herausforderungen getestet (wie den berühmten Kaggle-Data-Science-Wettbewerben).

Zuverlässigkeit: Während andere Systeme etwa die Hälfte der Zeit scheiterten, ein funktionierendes Ergebnis zu liefern, war 𝑖ML in 90 % der Fälle erfolgreich.
Leistung: 𝑖ML hat nicht nur funktioniert, sondern es hat gewonnen. Es hat in 45 % der Wettbewerbe „Medaillen“ (Spitzenplatzierungen) errungen und damit sowohl ältere automatisierte Tools als auch andere KI-Agenten geschlagen.
Robustheit: Selbst wenn die Anweisungen vage waren oder auf das absolute Minimum reduziert wurden (wie „korrigiere diese Daten“, ohne zu erklären wie), war 𝑖ML immer noch in 70 % der Fälle erfolgreich, indem es sich auf die Inspektion der tatsächlichen Daten statt auf die Textanweisungen verließ.

Kurz gesagt: 𝑖ML ist ein System, das aufhört zu raten, anfängt zu testen und ein Team von Spezialisten zusammenstellt, um sicherzustellen, dass das fertige Machine-Learning-Modell nicht nur eine schöne Idee, sondern eine funktionierende, hochperformante Realität ist.

Technisches Resümee: $i$ ML – Ausführbares, problemgestütztes und breit exploratives, codebasiertes AutoML

1. Problemstellung

Obwohl Automated Machine Learning (AutoML) den Zugang zu maschinellem Lernen demokratisiert hat, stehen bestehende Systeme vor erheblichen Einschränkungen hinsichtlich Flexibilität, Transparenz und Ausführungszuverlässigkeit. Traditionelle AutoML-Tools operieren oft als starre „Black Boxes“, die auf vordefinierte Suchräume (z. B. tabellarische Daten) beschränkt sind und nicht in der Lage sind, Pipelines für komplexe oder multimodale Probleme anzupassen.

Jüngste LLM-basierte Agenten (Large Language Model) haben sich in Richtung Code-driven AutoML entwickelt, das ausführbaren Code für die Vorverarbeitung, das Training und die Evaluierung synthetisiert. Aktuelle Ansätze leiden jedoch unter drei kritischen Mängeln:

Mangelnde Ausführbarkeit: Generierter Code erscheint im Text oft plausibel, scheitert jedoch während der Ausführung aufgrund von Laufzeitfehlern, Typ-Fehlpaarungen oder unverifizierten Annahmen.
Unzureichende Problemgestützung: Entscheidungen in der Planung beruhen häufig auf unverifizierten textuellen Annahmen oder „halluzinierten“ Dateneigenschaften statt auf einer empirischen Analyse des tatsächlichen Datensatzes.
Eng geführte Exploration: Viele Systeme verpflichten sich vorzeitig auf einen einzigen Modellierungspfad (z. B. die Verfeinerung eines monolithischen Skripts oder das Einbetten in ein festes Backend wie AutoGluon) und versäumen es so, diverse, aktuelle Lösungsstrategien über traditionelles ML, vortrainierte Adaption und benutzerdefinierte neuronale Architekturen hinweg zu explorieren.

2. Methodik: Das $i$ ML-Framework

Die Autoren führen $i$ ML ein, ein Multi-Agenten-Framework für codebasiertes AutoML, das darauf ausgelegt ist, drei Kernanforderungen zu erfüllen: Ausführbarkeit, Problemgestützung und breite Exploration. Das Framework operiert durch drei koordinierte Phasen:

Phase I: Code-gesteuerte strategische Planung

Anstatt direktes Prompting für den Code zu nutzen, konstruiert $i$ ML zuerst einen problemgestützten strategischen Entwurf ( $B$ ).

Aufgabenanalyse & Profiling: Ein Task Analyzer extrahiert semantische Randbedingungen, während ein Profiling Agent den Rohdatensatz ( $\mathcal{D}$ ) empirisch analysiert, um Meta-Merkmale ( $F_{meta}$ ) zu generieren, einschließlich Schema, Fehlmuster und Datenqualität.
Wissensabruf: Ein Knowledge Retriever erwirbt Domänenbeschränkungen und Vorverarbeitungsstrategien aus externen Quellen.
Entwurfsynthese: Ein Guideline Agent synthetisiert einen strukturierten Entwurf, der Vorverarbeitungsdirektiven, Modellwahl-Logik (Wahl zwischen traditionellem ML, vortrainierter Adaption oder benutzerdefinierten neuronalen Architekturen), Trainingsprotokolle und Evaluierungsmetriken spezifiziert. Dieser Entwurf fungiert als Satz architektonischer Invarianten, um den Suchraum einzugrenzen.

Phase II: Code-modulare Implementierung

Spezialisierte Coding-Agenten implementieren Komponenten separat unter expliziten Interface-Verträgen ( $IC_{\mathcal{T}}$ ).

Preprocessing Coder: Generiert ein Skript ( $S_{prep}$ ), um die Rohdaten in eine verifizierte Repräsentation ( $\mathcal{D}'$ ) zu transformieren, die strikt das vom Modellierungsstadium erforderte Schema erfüllt.
Modeling Coder: Generiert ein Skript ( $S_{model}$ ) für Training und Inferenz und stellt die mathematische Kompatibilität mit dem verifizierten $\mathcal{D}'$ sicher.
Vertragsgesteuertes Design: Diese Modularität verhindert logische Verstrickungen und ermöglicht die unabhängige Entwicklung und Reparatur von Komponenten.

Phase III: Code-verifizierbare Integration

Ein Assembler Agent integriert $S_{prep}$ und $S_{model}$ in eine einheitliche Pipeline ( $S$ ).

Dynamische Ausführung & Verifizierung: Das System führt $S_{prep}$ auf den Daten aus, um die Laufzeiteigenschaften (Formen, Typen) gegen den Interface-Vertrag zu validieren, bevor es mit dem Training fortfährt.
Iterative Fehlerbehebung: Falls die Ausführung fehlschlägt, lokalisiert ein Error Analyzer den Fehler (z. B. API-Fehlpaarungen, Tensor-Shape-Fehler) mithilfe von Laufzeit-Tracebacks. Ein Debugging Agent repariert dann iterativ die spezifische Komponente, wobei er bei Bedarf Websuchen für aktuelle Syntax nutzt, bis eine gültige Pipeline erhalten wurde.

3. Kernbeiträge

Neuartige Designprinzipien: Die Arbeit etabliert drei Kriterien für ideales Code-driven AutoML: Ausführbarkeit (zuverlässige End-to-End-Synthese), Problemgestützung (Entscheidungen basierend auf empirischen Daten und abgerufenem Wissen) und Diverse/Aktualisierte Exploration (Suche über heterogene Lösungsspuren hinweg).
Das $i$ ML-Framework: Eine Multi-Agenten-Architektur, die diese Prinzipien durch empirisches Profiling, abrufgestützte Planung, modulare Codesynthese und dynamische Verifizierung operationalisiert.
Umfassende experimentelle Validierung: Eine umfassende Evaluierung auf MLE-BENCH und einem neu eingeführten $i$ ML-BENCH (der 16 diverse Kaggle-Wettbewerbe von 2021–2025 abdeckt), die eine überlegene operative Zuverlässigkeit und kompetitive Leistung demonstriert.

4. Experimentelle Ergebnisse

Die Autoren evaluierten $i$ ML gegenüber State-of-the-Art-Baselines, einschließlich traditionellem AutoML (AutoGluon) und codebasierten Agenten (MLZERO, MLE-STAR, AutoML-Agent).

Performance auf MLE-BENCH (Lite)

Zuverlässigkeit: $i$ ML erreichte eine 90%ige gültige Submission-Rate, was MLE-STAR (55%) und AutoML-Agent (40%) deutlich übertrifft.
Kompetitive Qualität: Es sicherte sich 45% der Aufgaben mit einer Medaille (Gold/Silber/Bronze) und eine 80%ige „Above Median“-Rate.
Leistungsscore: Der Average Performance Score (APS) lag bei 0,82, was eine 52%–273%ige Verbesserung gegenüber LLM-basierten Baselines darstellt.

Performance auf $i$ ML-BENCH

Robustheit: $i$ ML erzielte den höchsten APS (0,54), was fast das Dreifache der Leistung von MLZERO (0,19) ist.
Komplexe Aufgaben: Während Baselines wie AutoGluon und MLZERO bei komplexen multimodalen Aufgaben (z. B. PetFinder, Multilabel Classification) scheiterten (Score 0,00), hielt $i$ ML hohe Werte (jeweils 0,67 und 0,69).
Gestraffte Beschreibungen: Selbst wenn die Aufgabenbeschreibungen stark auf einen generischen Prompt reduziert wurden, behielt $i$ ML eine Erfolgsquote von 70% und einen APS von 0,63 bei, was die Resilienz gegenüber ambivalenter Nutzerintention zeigt.

Ablationsstudien

Ausführbarkeit: Das Entfernen der dynamischen Verifizierung oder der modularen Integration führte zu signifikanten Einbrüchen bei den gültigen Submission-Raten und dem APS, was bestätigt, dass statische Prüfungen nicht ausreichen.
Gestützung: Das Entfernen des empirischen Datenprofilings reduzierte den APS von 0,82 auf 0,66, was beweist, dass die Datengestützung ein primärer Treiber für kompetitive Qualität ist.
Exploration: Die Beschränkung von $i$ ML auf einen einzigen Modellierungs-Track (z. B. nur traditionelles ML) führte zu einem Leistungszusammenbruch bei Nicht-Tabular-Aufgaben, was die Notwendigkeit der Multi-Track-Exploration validiert.

5. Bedeutung und Ansprüche

Die Arbeit behauptet, dass $i$ ML ein robuster Paradigmenwechsel für AutoML ist, indem es die Lücke zwischen hochgradiger strategischer Argumentation und empirisch verifizierbarer Implementierung schließt.

Zuverlässigkeit vor Plausibilität: Im Gegensatz zu früheren Agenten, die textuell plausible, aber fragile Codes generieren, erzwingt $i$ ML die Ausführbarkeit durch einen geschlossenen Kreislauf aus Assemblierung, Ausführung, Diagnose und Korrektur.
Empirische Fundierung: Durch die Verankerung der Planung in beobachteten Dateneigenschaften und abgerufenem Wissen vermeidet das System halluzinierte Annahmen, die zu Laufzeitfehlern führen.
Menschlich-kompetitive Leistung: $i$ ML zeigt, dass Code-driven AutoML die Leistungsdeckel von „Black-Box“-Optimierungstools (wie AutoGluon) durch die Architektur nativer, aufgaben-spezifischer Pipelines durchbrechen kann.

Die Autoren kommen zu dem Schluss, dass $i$ ML einen transformativen Schritt in Richtung zuverlässiger, menschlich-kompetitiver autonomer Ingenieurskunst darstellt und eine verifizierbare Grundlage für die nächste Generation von ML-Systemen bietet. Sie räumen ein, dass die Leistung bei multimodalen Aufgaben weiterhin ein Grenzgebiet für zukünftige Optimierungen ist, das Framework jedoch die Kernherausforderungen der logischen Verstrickung und der Ausführungszuverlässigkeit aktueller AutoML-Agenten erfolgreich adressiert.