🤖 machine learning

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

Het artikel introduceert iML, een multi-agent code-gestuurd AutoML-framework dat uitvoerbare, probleem-gegrondde en breed verkennende oplossingen waarborgt door middel van gestructureerde blauwdrukken en iteratieve debugging, waarmee het state-of-the-art prestaties en een hoge betrouwbaarheid bereikt op diverse machine learning-benchmarks.

Oorspronkelijke auteurs: Dat Le, Duc-Cuong Le, Anh-Son Nguyen, Tuan-Dung Bui, Thu-Trang Nguyen, Son Nguyen, Hieu Dinh Vo

Gepubliceerd 2026-06-02

📖 5 min leestijd🧠 Diepgaand

CC0 1.0

Oorspronkelijke auteurs: Dat Le, Duc-Cuong Le, Anh-Son Nguyen, Tuan-Dung Bui, Thu-Trang Nguyen, Son Nguyen, Hieu Dinh Vo

Oorspronkelijk artikel vrijgegeven aan het publieke domein onder CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een complexe machine wilt bouwen, zoals een high-performance racewagen, maar je weet niet hoe je een monteur moet zijn. Je vraagt een zeer slimme, veelgelezen maar soms overmoedige assistent (een AI) om de blauwdrukken te schrijven en de auto voor je te bouwen.

In het verleden schreven deze assistenten vaak plannen die op papier perfect leken, maar uit elkaar vielen op het moment dat je de motor probeerde te starten. Ze namen bijvoorbeeld aan dat de auto een V8-motor heeft terwijl je er slechts een V6 hebt, of ze vergaten de wielen vast te draaien omdat ze te druk waren met het schrijven van een prachtige speech over snelheid.

Dit artikel introduceert 𝑖ML, een nieuw team van AI-assistenten die ontworpen zijn om deze problemen op te lossen. In plaats van één assistent die alles tegelijk probeert te doen, gebruikt 𝑖ML een multi-agent team dat werkt als een zeer georganiseerde bouwploeg. Hun doel is om een machine learning-model (de "auto") te bouwen dat daadwerkelijk rijdt, gebouwd is op de echte materialen die je hebt, en vele verschillende manieren verkent om de race te winnen.

Hieronder volgt de werking van 𝑖ML, onderverdeeld in drie eenvoudige principes:

1. De "Werkt het echt?" regel (Executability)

De meeste AI-assistenten schrijven code die er goed uitziet in tekst, maar die vastloopt wanneer je het probeert uit te voeren. 𝑖ML beschouwt het uitvoeren van de code als de belangrijkste test.

De Analogie: Stel je een chef-kok voor die niet alleen een recept opschrijft; hij kookt het gerecht ook daadwerkelijk, proeft het, en als het te zout is, past hij het aan voordat hij het aan de klant serveert.
Hoe 𝑖ML het doet: Het team verdeelt de taak in kleine onderdelen (het voorbereiden van de data, het bouwen van het model). Ze bouwen elk onderdeel afzonderlijk en proberen ze vervolgens te assembleren. Als de onderdelen niet passen (zoals een vierkante pen in een rond gat), stopt het systeem onmiddellijk, vindt de exacte fout en herstelt alleen dat specifieke stukje. Het blijft proberen en repareren totdat de hele machine soepel loopt. Dit zorgt ervoor dat in 90% van de gevallen het uiteindelijke resultaat daadwerkelijk werkt.

2. De "Kijk naar wat je hebt" regel (Problem Grounding)

Soms verzint AI-assistenten dingen. Ze kunnen aannemen dat je data schoon is terwijl deze eigenlijk rommelig is, of ze nemen aan dat je verkopen wilt voorspellen terwijl je eigenlijk het weer wilt voorspellen.

De Analogie: Stel je een aannemer voor die de blauwdrukken die je hem gaf en de werkelijke grond op je terrein negeert, en in plaats daarvan besluit een zwembad te bouwen omdat hij denkt dat je dat wilde.
Hoe 𝑖ML het doet: Voordat er ook maar één regel code wordt geschreven, stuurt 𝑖ML een "verkenner" uit om je werkelijke data te inspecteren. Het telt de ontbrekende stukken, controleert de soorten informatie en zoekt op wat andere experts met soortgelijke data hebben gedaan. Vervolgens maakt het een strikt plan (een "blauwdruk") gebaseerd op de realiteit, niet op gissingen. Dit voorkomt dat het team een model bouwt dat logisch gezien klopt, maar nutteloos is voor jouw specifieke probleem.

3. De "Probeer alles" regel (Broad Exploration)

Oude AutoML-systemen kiezen vaak één pad en houden zich daaraan vast, zoals een bestuurder die alleen op snelwegen kan rijden. Als de weg verandert in een onverhard pad, komen ze vast te zitten.

De Analogie: Stel je een detective voor die slechts één verdachte controleert. 𝑖ML is als een detective die drie verschillende verdachten ondervraagt: één die traditionele methoden gebruikt, één die high-tech gadgets gebruikt, en één die een op maat gemaakt hulpmiddel gebruikt.
Hoe 𝑖ML het doet: Het team kiest niet slechts één manier om het probleem op te lossen. Ze draaien drie verschillende strategieën parallel:
1. Traditionele methoden (betrouwbaar, zoals een stevige sedan).
2. Pre-trained modellen (gebruikmakend van bestaande slimme tools, zoals een sportwagen).
3. Custom neurale netwerken (het bouwen van een unieke, op maat gemaakte motor vanaf nul).
  Ze testen alle drie de opties, kijken welke de race wint, en kiezen de winnaar. Als één methode faalt, geven ze niet op; ze schakelen gewoon over naar de volgende beste optie.

De Teamstructuur

Om dit te realiseren, organiseert 𝑖ML zijn AI-agents in specifieke rollen:

De Strategist: Leest het probleem en inspecteert de data om de hoofdblauwdruk te creëren.
De Specialisten: Verschillende agents schrijven de code voor specifieke onderdelen (één voor het opschonen van data, één voor het bouwen van het model), zodat ze niet in de war raken.
De Assembler & Debugger: Zij voegen de stukken samen, testen ze, en als er iets breekt, fungeren zij als een monteur met een diagnose-instrument om de exacte kapotte bout te vinden en te repareren zonder de hele auto opnieuw te hoeven bouwen.

De Resultaten

De auteurs hebben dit systeem getest op twee moeilijke uitdagingen (zoals de beroemde Kaggle data science competities).

Betrouwbaarheid: Terwijl andere systemen ongeveer de helft van de tijd faaldenden om een werkend resultaat te produceren, slaagde 𝑖ML 90% van de tijd.
Prestatie: 𝑖ML werkte niet alleen; het won. Het behaalde "medailles" (toprangschikkingen) in 45% van de competities, waarmee het zowel oudere geautomatiseerde tools als andere AI-agents versloeg.
Robuustheid: Zelfs wanneer de instructies vaag waren of tot het absolute minimum waren teruggebracht (zoals "los deze data op" zonder uit te leggen hoe), slaagde 𝑖ML nog steeds 70% van de tijd door te vertrouwen op de inspectie van de werkelijke data in plaats van op de tekstuele instructies.

Kortom, 𝑖ML is een systeem dat stopt met gissen, begint met testen en een team van specialisten inzet om ervoor te zorgen dat het uiteindelijke machine learning-model niet alleen een mooi idee is, maar een werkende, hoogwaardige realiteit.

Technische Samenvatting: $i$ ML – Uitvoerbare, Probleem-gegronde en Breed Exploratieve Code-gestuurde AutoML

1. Probleemstelling

Hoewel Automated Machine Learning (AutoML) de toegang tot machine learning heeft gedemocratiseerd, kampen bestaande systemen met aanzienlijke beperkingen in flexibiliteit, transparantie en uitvoeringsbetrouwbaarheid. Traditionele AutoML-tools werken vaak als rigide "black boxes" die beperkt zijn tot vooraf gedefinieerde zoekruimtes (bijv. tabulaire data), zonder de mogelijkheid om pipelines aan te passen voor complexe of multimodale problemen.

Recente door Large Language Models (LLM) gestuurde agenten zijn verschoven naar Code-driven AutoML, waarbij uitvoerbare code wordt gesynthetiseerd voor preprocessing, training en evaluatie. De huidige benaderingen lijden echter onder drie kritieke gebreken:

Gebrek aan Uitvoerbaarheid: Gegenereerde code lijkt in tekst vaak plausibel, maar faalt tijdens de uitvoering vanwege runtime-fouten, type-mismatches of niet-geverifieerde aannames.
Onvoldoende Probleem-gronding: Beslissingen over de planning berusten vaak op ongeverifieerde tekstuele aannames of "gehallucineerde" eigenschappen van de data, in plaats op empirische analyse van de werkelijke dataset.
Beperkte Exploratie: Veel systemen committeren zich voortijdig aan een enkel modelleringspad (bijv. het verfijnen van een monolithisch script of het inkapselen van een vaste backend zoals AutoGluon), waardoor ze niet in staat zijn om diverse, actuele oplossingsstrategieën te verkennen over traditionele ML, pretrained adaptatie en aangepaste neurale architecturen heen.

2. Methodologie: Het $i$ ML-framework

De auteurs introduceren $i$ ML, een multi-agent code-driven AutoML-framework dat is ontworpen om aan drie kernvereisten te voldoen: Uitvoerbaarheid, Probleem-gronding en Brede Exploratie. Het framework werkt via drie gecoördineerde fasen:

Fase I: Code-gestuurde Strategische Planning

In plaats van directe prompting naar code, construeert $i$ ML eerst een probleem-gegronde strategische blauwdruk ( $B$ ).

Taakanalyse & Profilering: Een Task Analyzer extraheert semantische beperkingen, terwijl een Profiling Agent de ruwe dataset ( $\mathcal{D}$ ) empirisch analyseert om meta-kenmerken ( $F_{meta}$ ) te genereren, inclusclusief schema, patronen van ontbrekende waarden en datakwaliteit.
Kennisretrieval: Een Knowledge Retriever verkrijgt domeinbeperkingen en preprocessing-strategieën uit externe bronnen.
Blauwdruk Synthese: Een Guideline Agent synthetiseert een gestructureerde blauwdruk die preprocessing-richtlijnen, modelselectie-logica (keuze tussen Traditionele ML, Pretrained Adaptatie of Custom Neurale Architecturen), trainingsprotocollen en evaluatiemetrieken specificeert. Deze blauwdruk fungeert als een set architecturale invarianten om de zoekruimte te beperken.

Fase II: Code-modulaire Implementatie

Gespecialiseerde coding-agents implementeren componenten afzonderlijk onder expliciete Interface Contracts ( $IC_{\mathcal{T}}$ ).

Preprocessing Coder: Genereert een script ( $S_{prep}$ ) om de ruwe data te transformeren naar een geverifieerde representatie ( $\mathcal{D}'$ ) die strikt voldoet aan het schema dat vereist is door de modelleringsfase.
Modeling Coder: Genereert een script ( $S_{model}$ ) voor training en inferentie, waarbij wiskundige compatibiliteit met de geverifieerde $\mathcal{D}'$ wordt gewaarborgd.
Contract-gestuurd Ontwerp: Deze modulariteit voorkomt logische verstrengeling en maakt onafhankelijke ontwikkeling en reparatie van componenten mogelijk.

Fase III: Code-verifieerbare Integratie

Een Assembler Agent integreert $S_{prep}$ en $S_{model}$ in een uniforme pipeline ( $S$ ).

Dynamische Executie & Verificatie: Het systeem voert $S_{prep}$ uit op de data om runtime-eigenschappen (vormen, types) te valideren tegen het interface-contract voordat de training wordt voortgezet.
Iteratieve Debugging: Als de uitvoering faalt, lokaliseert een Error Analyzer de fout (bijv. API-mismatches, tensor-shape errors) met behulp van runtime tracebacks. Een Debugging Agent repareert vervolgens iteratief de specifieke component, waarbij indien nodig web-zoekopdrachten gebruikt voor de huidige syntaxis, totdat een geldige pipeline is verkregen.

3. Belangrijkste Bijdragen

Nieuwe Ontwerpprincipes: Het artikel stelt drie criteria vast voor ideale code-driven AutoML: Uitvoerbaarheid (betrouwbare end-to-end synthese), Probleem-gronding (beslissingen gebaseerd op empirische data en opgehaalde kennis) en Diverse/Geüpdatete Exploratie (zoeken over heterogene oplossingspaden).
Het $i$ ML-framework: Een multi-agent architectuur die deze principes operationaliseert door middel van empirische profilering, retrieval-ondersteunde planning, modulaire codesynthese en dynamische verificatie.
Uitgebreide Experimentele Validatie: Een uitgebreide evaluatie op MLE-BENCH en een nieuw geïntroduceerde $i$ ML-BENCH (die 16 diverse Kaggle-competities van 2021–2025 beslaat), wat een superieure operationele betrouwbaarheid en competitieve prestaties aantoont.

4. Experimentele Resultaten

De auteurs hebben $i$ ML geëvalueerd tegen state-of-the-art baselines, waaronder traditionele AutoML (AutoGluon) en code-driven agenten (MLZERO, MLE-STAR, AutoML-Agent).

Prestaties op MLE-BENCH (Lite)

Betrouwbaarheid: $i$ ML behaalde een 90% geldige inzending-ratio, wat aanzienlijk beter is dan MLE-STAR (55%) en AutoML-Agent (40%).
Competitieve Kwaliteit: Het behaalde 45% van de taken met een medaille (Goud/Zilver/Brons) en een 8ism "Above Median" ratio.
Prestatiescore: De Average Performance Score (APS) was 0,82, wat een verbetering van 52%–273% betekent ten opzichte van LLM-gebaseerde baselines.

Prestaties op $i$ ML-BENCH

Robuustheid: $i$ ML behaalde de hoogste APS (0,54), wat bijna drie keer de prestaties van MLZERO (0,19) is.
Complexe Taken: Terwijl baselines zoals AutoGluon en MLZERO (met een score van 0,00) faalden op complexe multimodale taken (bijv. PetFinder, Multilabel Classificatie), behield $i$ ML hoge scores (respectievelijk 0,67 en 0,69).
Gestripte Beschrijvingen: Zelfs wanneer taakbeschrijvingen aanzienlijk waren gestript tot een generieke prompt, behield $i$ ML een succesrate van 70% en een APS van 0,63, wat de veerkracht tegen ambigue gebruikersintentie aantoont.

Ablatie-studies

Uitvoerbaarheid: Het verwijderen van dynamische verificatie of modulaire integratie veroorzaakte significante dalingen in de geldige inzending-ratio's en APS, wat bevestigt dat statische controles onvoldoende zijn.
Gronding: Het verwijderen van empirische dataprofilering verminderde de APS van 0,82 naar 0,66, wat bewijst dat datagronding een primaire drijfveer is van competitieve kwaliteit.
Exploratie: Het beperken van $i$ ML tot een enkel modelleringspad (bijv. alleen Traditionele ML) resulteerde in een instorting van de prestaties bij niet-tabulaire taken, wat de noodzaak van multi-track exploratie valideert.

5. Betekenis en Claims

Het artikel claimt dat $i$ ML een robuust paradigma voor AutoML vestigt door de kloof te overbruggen tussen hoogwaardige strategische redenering en empirisch verifieerbare implementatie.

Betrouwbaarheid boven Plausibiliteit: In tegenstelling tot eerdere agenten die tekstueel plausibele maar breekbare code genereren, dwingt $i$ ML uitvoerbaarheid af via een closed-loop proces van assemblage, uitvoering, diagnose en correctie.
Empirische Gronding: Door de planning te verankeren in geobserveerde data-eigenschappen en opgehaalde kennis, vermijdt het systeem gehallucineerde aannames die leiden tot runtime-fouten.
Mens-Competitieve Prestaties: $i$ ML laat zien dat code-driven AutoML de prestatieplafonds van "black-box" optimalisatietools (zoals AutoGluon) kan overstijgen door het ontwerpen van native, taakspecifieke pipelines.

De auteurs concluderen dat $i$ ML een transformerende stap vormt naar betrouwbare, mens-competitieve autonome engineering, en een verifieerbare basis biedt voor de volgende generatie ML-systemen. Zij erkennen dat hoewel prestaties op multimodale taken een frontier blijven voor toekomstige optimalisatie, het framework erin slaagt de kernuitdagingen van logische verstrengeling en uitvoeringsbetrouwbaarheid in huidige AutoML-agenten aan te pakken.