AutoML (geautomatiseerd machine learning)

Wat is AutoML?

AutoML is software die het saaie deel van een machine learning-model bouwen voor jou doet. Je geeft ze een tabel en duidt één kolom aan als het ding dat je wil voorspellen. De tool maakt de andere kolommen bruikbaar, probeert een reeks algoritmes, zoekt per algoritme de beste instellingen, test elke kandidaat op rijen waar hij niet op getraind is, en geeft je een gerangschikte lijst van modellen met een score erbij. Wie de tool draait, schrijft geen trainingscode.

Het idee bestaat al een tijd. De onderzoeksgroep in Freiburg achter auto-sklearn publiceerde de aanpak in 2015, en H2O bracht zijn AutoML uit in 2017. Wat veranderd is: elk cloudplatform heeft er nu een versie van ingebouwd. Een Power BI-analist of een controller die wat Python kent, kan er vanuit een notebook een draaien.

Een beeld dat helpt: een model met de hand bouwen is een kleermaker die je opmeet. AutoML is een rek met vijftig kostuums in elke snit, met een spiegel ernaast. Je bent sneller aangekleed. Maar het rek weet niet voor welke gelegenheid je je kleedt.

Waar je het tegenkomt

Microsoft Fabric biedt AutoML aan in notebooks via de klasse flaml.AutoML, en logt elke poging in MLflow zodat je kan nagaan hoe de winnaar gekozen werd. Azure Machine Learning heeft automated ML met een no-code studio en voegt op het einde van een run voting- en stacking-ensembles toe. Google Vertex AI heeft AutoML voor classificatie, regressie en forecasting op tabellen. AWS SageMaker Autopilot doet hetzelfde op AWS; sinds november 2023 zit de no-code-interface in SageMaker Canvas. Buiten de cloud zijn H2O AutoML en auto-sklearn open source en draaien ze op je eigen machine.

Wat AutoML overneemt en wat bij jou blijft

Elke leverancier beschrijft het geautomatiseerde deel in ongeveer dezelfde woorden. Lege waarden worden ingevuld, tekst en categorieën worden omgezet naar cijfers, cijfers worden geschaald. Een lijst algoritmes wordt getraind: logistische regressie, random forests, gradient-boosted trees, soms een klein neuraal netwerk. Voor elk algoritme worden de hyperparameters doorzocht binnen een tijdsbudget dat jij instelt. De kandidaten worden vergeleken op data die ze niet gezien hebben, via cross-validation of een aparte validatieset, en gerangschikt op de metriek die jij koos. De meeste tools tonen ook een grafiek met feature importance, en Azure en SageMaker maken er een uitlegrapport bij.

De lijst van wat bij jou blijft is korter, maar weegt zwaarder.

• De vraag. AutoML weet niet of je wil voorspellen wie vertrekt, wie te laat betaalt of wie een telefoontje waard is. Dat zijn drie verschillende modellen met drie verschillende tabellen erachter.

• De doelkolom. De tool voorspelt de kolom die jij aanwijst. Is die slecht gedefinieerd, dan krijg je een heel precies antwoord op de verkeerde vraag.

• De data. De tabel samenstellen uit het ERP, het CRM en de helpdesk, en per rij beslissen op welke datum ze bevroren wordt, is het grootste deel van het werk. Daar is niets van geautomatiseerd.

• Wat een fout kost. Een vals alarm is een verkoper die een tevreden klant belt. Een gemiste klant is iemand die opzegt zonder dat iemand het zag aankomen. Welke van de twee het meest pijn doet, bepaalt welk model je kiest, en dat kan de tool niet weten.

• Uitrol en opvolging. Het leaderboard is een lijst bestanden. Elke maandag nieuwe klanten scoren, en merken wanneer de scores niet meer kloppen, is een aparte job. De entries over MLOps en model drift gaan daarover.

Wat op bedrijfsdata meestal wint

Voor het soort data dat een KMO heeft, rijen klanten of facturen met enkele tientallen numerieke en categorische kolommen, is de winnaar verrassend voorspelbaar. Gradient-boosted decision trees, in de smaak LightGBM, XGBoost of CatBoost, staan bijna altijd bovenaan of vlak onder de top, met random forests er net achter.

Daar zit onderzoek achter. Onderzoekers van Inria vergeleken in 2022 boommodellen met deep learning op 45 tabeldatasets en vonden dat boommodellen de beste keuze blijven op middelgrote data van rond de tienduizend rijen. De reden: ze kunnen beter om met kolommen die niets bijdragen en met de drempelachtige patronen die bedrijfsdata typisch heeft. De leveranciers kwamen in de praktijk op hetzelfde uit. De standaardlijst van FLAML, de engine achter Fabric, begint met LightGBM en XGBoost, en H2O AutoML zet in elke run een vaste reeks vooraf ingestelde GBM- en XGBoost-modellen in, plus grid searches erop.

Het praktische gevolg: een brede zoektocht is zelden nodig. Een paar boommodellen met een degelijke hyperparameter-sweep en één lineair model als leesbare referentie volstaat voor de meeste bedrijfstabellen.

Uitgewerkt voorbeeld: churn bij een abonnementsbedrijf

Een bedrijf verkoopt een maandelijks softwareabonnement aan 8.000 zakelijke klanten en verliest er jaarlijks ongeveer tien procent van. De zaakvoerder wil een lijst van klanten die je best belt voor ze opzeggen.

De doelkolom. Iemand moet beslissen wat churn betekent. Het team kiest: de klant zegt op binnen de 90 dagen na een peildatum. Ze bouwen één rij per klant per kwartaal over de voorbije twee jaar, elke rij bevroren op de eerste dag van dat kwartaal. Dat geeft zo'n 60.000 rijen met ongeveer 1.500 opzeggingen. Een positief aandeel van 2,5 procent, dus de klassen zijn sterk uit balans.

De features. Twintig kolommen, allemaal gekend op de peildatum. Uit het ERP: looptijd van het contract in maanden, plan, maandbedrag, aantal prijswijzigingen, facturen te laat betaald in de laatste zes maanden, dagen sinds de laatste upgrade, kortingspercentage, betaalwijze, aantal producten, sector en bedrijfsgrootte. Uit de helpdesk: tickets in de laatste 90 dagen, tickets in het laatste jaar, gemiddelde oplostijd, heropende tickets, categorie van het laatste ticket, dagen sinds het laatste ticket en de recentste tevredenheidsscore.

De eerste run. Het eerste leaderboard toont een model met een AUC van 0,98. Dat is geen goed nieuws. Een kolom contract_einddatum was in de tabel geslopen, en die wordt pas ingevuld nadat een klant opgezegd heeft. AutoML vond het lek in enkele seconden en bouwde het hele model erop. De kolom gaat eruit, de run wordt herhaald.

De tweede run. Na een uur zoeken staat er: een LightGBM-model op 0,82 AUC, een XGBoost-model op 0,81, een random forest op 0,80, een gradient-boosted model met beperkte boomdiepte op 0,81 en een logistische regressie op 0,78. De tool heeft de onbalans zelf aangepakt: Azure automated ML bijvoorbeeld test klassengewichten zodra de kleinste klasse 20 procent of minder van de grootste bedraagt.

De keuze. De winnaar is het LightGBM-model. Het model dat in productie gaat, is misschien toch het boommodel met beperkte diepte op 0,81, of zelfs de logistische regressie. De verkoop belt elk kwartaal de 200 hoogst gescoorde klanten, en het verschil tussen 0,82 en 0,81 is een handvol namen in die lijst. Daartegenover staat dat het eenvoudigere model makkelijker uit te leggen is als een verkoper vraagt waarom een klant op de lijst staat, minder kolommen nodig heeft die elke week vers moeten zijn, en minder kans heeft om iets vreemds geleerd te hebben over één sector. Het leaderboard rangschikt op een metriek. De beslissing valt op een bedrijfscijfer: hoeveel opzeggers die 200 telefoontjes echt opvangen, en wat een telefoontje kost.

AutoML versus een model met de hand gebouwd

Vergelijk de twee op één as: wat de mens nog moet beslissen.

Bij een model met de hand gebouwd beslist een data scientist alles. Welk algoritme, welke omzetting per kolom, welke instellingen, hoe de data gesplitst wordt, op welke metriek geoptimaliseerd wordt en wanneer het genoeg is. Elke beslissing is een plek om een fout te maken en een plek om domeinkennis toe te voegen. Het resultaat is een model plus een persoon die begrijpt waarom het werkt.

Bij AutoML neemt de tool het algoritme, de omzetting, de instellingen, de splitsing en de stopregel over. Wat overblijft: de definitie van de doelkolom, de tabel, de metriek, de leakage-check en de beslissing over de uitrol. Dat waren ook de vijf moeilijkste punten op de lijst van de data scientist. AutoML haalt het deel weg waar je code voor moest kunnen schrijven en laat het deel staan waar je de business voor moet kennen.

De eerlijke vergelijking is dus: AutoML plus een domeinexpert die de juiste vragen stelt, tegenover een data scientist die dezelfde vragen moet stellen en er ook nog de code voor schrijft.

AutoML versus een taalmodel

AutoML leeft in de wereld van voorspellingen op tabellen: een cijfer of een categorie per rij, geleerd uit duizenden rijen uit het verleden. Een large language model leeft in de wereld van tekst. Een LLM vragen om churnscores te geven op basis van 20 numerieke kolommen is het verkeerde gereedschap: je krijgt cijfers die er plausibel uitzien, zonder enige training op jouw geschiedenis, tegen een veel hogere kost per rij dan een boommodel dat duizenden rijen per seconde scoort. Omgekeerd geldt hetzelfde. Een taalmodel fine-tunen op je supporttickets is een echte techniek met een eigen entry, en het is geen AutoML, ook al zetten sommige leveranciers beide achter dezelfde knop.

Waar de twee elkaar wel raken, is bij de features. Een LLM kan de vrije tekst van een helpdeskticket omzetten in een categorie of een sentimentscore. Die score wordt dan één van de 20 kolommen waar de AutoML-run mee werkt.

Waar moet je op letten bij AutoML

Een topscore op een gelekte kolom. AutoML gebruikt elke kolom die stiekem het antwoord bevat, en sneller dan een mens dat zou doen. Een leaderboard dat te mooi oogt, is eerst een leakage-check en pas daarna een reden om te vieren. De entry over data leakage somt op hoe zo'n lek meestal ontstaat.

Een topscore op een nutteloze doelkolom. Een model dat voorspelt welke klanten vorig kwartaal opgezegd hebben, is triviaal zodra het kwartaal voorbij is. De doelkolom moet iets zijn waar je op kan reageren voor het gebeurt, met features die bevroren zijn voor het gebeurt.

Onbalans verstopt achter accuracy. Met 2,5 procent positieven is een model dat zegt dat niemand opzegt 97,5 procent accuraat. Kies voor de run start een metriek die tegen onbalans bestand is, zoals AUC of precisie op het aantal telefoontjes dat je echt kan doen.

Een model dat niemand aan de verkoop kan uitleggen. Een stacked ensemble bovenaan het leaderboard verdedig je moeilijk in een vergadering. Als de verkopers de lijst niet vertrouwen, bellen ze ze niet. Feature importance en uitlegrapporten helpen, en de eenvoudigere nummer twee kiezen helpt ook.

Het leaderboard najagen. Nog een uur zoeken brengt de AUC misschien van 0,82 naar 0,83. Het verandert weinig aan de top 200, en datzelfde uur in een betere feature uit de helpdesk steken levert meestal meer op.

De praktische regel voor een KMO is kort. Gebruik AutoML om snel een eerste model op tafel te hebben. Zet een mens op de definitie van de doelkolom, de leakage-check en de uitrol, want daar kan de tool niet helpen en daar wordt het model gewonnen of verloren.