Thought leaders

De Critische Pad naar Automatisering van Modelontwikkeling

mm mm
Voeg Unite.AI toe aan je voorkeursbronnen op Google
A stylized digital landscape showing illuminated lines connecting data structures. A cluster representing

Het volgende belangrijke mijlpaal voor AI-onderzoek is het automatiseren van modelontwikkeling. Elke vooruitgang in redeneren, taal en perceptie is in zekere zin een stap naar dat doel. Het pad naar modelautomatisering vereist echter het oplossen van een reeks fundamentele uitdagingen die eerst moeten worden overwonnen.

De brug naar dat doel loopt rechtstreeks door machine learning (ML) engineering. Een veelvoorkomende misvatting is dat ML een voorgaande technologie is voor moderne AI en dat foundation models deze hebben vervangen. Dit misverstaat de relatie. Als academische discipline omvat ML alle aspecten van modeltraining, inclusief de training van foundation models in het centrum van het huidige AI-moment. Er is echter een significante verschil in schaal en gegevenscomplexiteit.

Traditionele ML-modellen worden meestal getraind op zorgvuldig gecureerde, domeinspecifieke datasets met duizenden of miljoenen voorbeelden. Foundation models daarentegen worden getraind op duizenden datasets tegelijk, afkomstig van uiteenlopende bronnen met onconsistentie in formaat, herkomst en kwaliteit. Dit verschil in gegevensschaal en heterogeniteit is een fundamentele reden waarom gegevensbeheer veel moeilijker en belangrijker wordt naarmate modellen krachtiger worden.

Dat maakt gegevensbegrip een centrale bottleneck in de automatisering van modelontwikkeling. Een AI-systeem dat heterogene gegevens kan interpreteren en de pipelines die eromheen zijn gebouwd kan verbeteren, kan in principe zijn eigen trainingsproces verbeteren en helpen bij het bouwen van betere modellen. Zodra AI het proces waarin het wordt getraind kan verbeteren, komen verbeteringen naar beneden in elk domein waarin AI wordt toegepast.

Drie Barrières op de Weg

De eerste barrière is contextfragmentatie. In bijna elke organisatie zijn de signalen, experimenten, functiedefinities en institutionele kennis die relevant zijn voor een bepaald modelprobleem verspreid over datawarehouses, notebooks en pipelines die nooit zijn ontworpen om met elkaar te communiceren. Overweeg een gezondheidssysteem dat een sepsisdetectiemodel bouwt. De klinische criteria die relevant zijn voor dat probleem, zoals vitale drempels, laboratoriumwaarden en documentatiestandaarden, kunnen in helemaal aparte modules van een elektronisch gezondheidsrecordsysteem leven.

De tweede barrière is semantische ambiguïteit. Betekenis is niet inherent aan de gegevens, maar is contextueel en organisationeel. Dezelfde veldnaam in twee verschillende databases kan op subtiele wijze verschillende dingen betekenen. Concepten zoals omzet, actieve gebruiker en churn hebben meestal meerdere geldige definities binnen één bedrijf. Zelfs een concept als “omzet” kan problemen veroorzaken. Een verkoopteam kan omzet definiëren als de totale waarde van contracten die deze kwartaal zijn getekend, terwijl het financiële team omzet definieert als het daadwerkelijk ontvangen bedrag. Het productteam heeft nog een andere interpretatie, aangezien het omzet definieert als gerealiseerde omzet die over een abonnementsperiode is verdeeld. Alle drie halen gegevens uit velden die letterlijk “omzet” heten in hun respectievelijke systemen, maar een cross-teamrapport dat ze combineert, zou drie onverenigbare nummers stilzwijgend mengen.

De derde en meest systemische barrière is het ontbreken van gedocumenteerd institutioneel geheugen. Het oplossen van inconsistenties, het bijhouden van de herkomst en het behouden van kwaliteitssignalen over zoveel bronnen heen is een onopgelost probleem, zelfs voor menselijke teams. Zonder een institutioneel geheugen van wat is geprobeerd en hoe goed deze benaderingen hebben gewerkt, zal elk modelautomatiseringsmechanisme dezelfde dode einden blijven ontdekken, waardoor tijd en middelen worden verspild.

Overweeg een datascienceteam bij een detailhandelsbedrijf dat een vraagvoorspellingsmodel bouwt. In drie jaar hebben een dozijn analisten elk onafhankelijk ontdekt dat ruwe weergegevens de modelprestaties tijdens feestdagen verslechteren, dat de voorraadfeed van een bepaalde leverancier een systematische vertraging bevat en dat de standaardbenadering voor het omgaan met promotionele evenementen doellekage veroorzaakt. Toen de oorspronkelijke analisten naar andere teams gingen of het bedrijf verlieten, ging de kennis met hen mee. Zonder een institutioneel verslag van wat is geprobeerd, wat is mislukt en waarom, kan een modelautomatiseringsmechanisme niet voortbouwen op opgebouwde ervaring. Het begint simpelweg opnieuw vanaf nul, telkens opnieuw, waardoor tijd onnodig wordt verspild.

Wat een Echte Oplossing Vereist

De geschiedenis van ML-automatisering is een geschiedenis van gedeeltelijke oplossingen. AutoML loste het smalle probleem van hyperparameterafstemming op, maar kon geen rekening houden met doelafwijkingen of redeneren over organisationele intentie. MLOps maakte productiepijplijnen robuuster en gemakkelijker te bewaken, maar MLOps-gereedschappen voeren een strategie uit in plaats van deze te definiëren. Meer recente codeeragenten vertegenwoordigen een echte stap voorwaarts, maar hebben dezelfde blinde vlek geërfd. Ze genereren code goed terwijl ze zonder organisationele context of institutioneel geheugen opereren.

Een systeem dat in staat is tot echt autonome ML-engineering zou capaciteiten nodig hebben die geen enkel bestaand gereedschap in combinatie biedt. Het zou businessdoelen moeten kunnen vertalen naar modeldoelstellingen, een vertaling die niet kan worden afgeleid uit gegevens alleen. Het zou relevante gegevens moeten kunnen ontdekken over gefragmenteerde systemen met onconsistentie in schema’s, terwijl het automatisch voldoet aan nalevings-, governance- en beveiligingsbeperkingen, in plaats van mensen te laten beheren als een afzonderlijk proces. Het zou institutioneel geheugen nodig hebben om bestaand werk naar boven te brengen, te begrijpen waarom eerder experimenten zijn stopgezet en voort te bouwen op wat collega’s al weten.

Strenge audittrails die herkomst volgen over gegevensversies, functiedefinities en codecommits zouden een kernmechanisme moeten zijn om het systeem te verankeren in wat er daadwerkelijk is gebeurd. En een dergelijk systeem zou een zorgvuldige human-in-the-loop-ontwerp nodig hebben. Geen binaire keuze tussen volledige automatisering en volledige handmatige controle, maar ondersteuning voor verschillende niveaus van interactie, afhankelijk van de taak, de inzet en het vertrouwen van het systeem op elk beslissingspunt. Automatisering die menselijke oordeelkundigheid op kritieke momenten omzeilt, is geen kenmerk van goed ontworpen AI; het is een foutmodus.

Wat geen enkel lab nog heeft opgelost, is hoe een semantische begrip van organisationele gegevens kan worden gecreëerd dat begrijpt wat de gegevens betekenen in een specifieke institutionele context. MCP lost het connectiviteitsprobleem op. Het lost het betekenisprobleem nog niet op. Dat blijft de open onderzoeksfrontier.

Wat Mogelijk Wordt

De economische implicaties van het oplossen van deze problemen zijn aanzienlijk. Aangepaste ML-ontwikkeling vereist vandaag specialistische beoefenaars en weken van iteratie, zelfs voor goed afgebakende problemen. Een systeem dat de volledige workflow autonoom kan navigeren, van probleemdefinitie tot gegevensontdekking, modelontwikkeling en modelbeoordeling, zou die vergelijking dramatisch veranderen, tijdslijnen samenpersen en hoge-waardegevallen openen die momenteel te middelengevoelig zijn om na te streven. Projecten die eerder weken in beslag namen van teams met diepe ML-expertise, kunnen nu in dagen worden voltooid zonder zo veel van de schaarse ML-experts te hoeven gebruiken.

De uitdagingen van contextfragmentatie, semantische ambiguïteit en ontbrekend institutioneel geheugen zijn niet uniek voor enterprise ML. Ze manifesteren zich onder verschillende beperkingen in de constructie van foundation modeltrainingspijplijnen, waarbij duizenden heterogene datasets moeten worden geaggregeerd, gefilterd en iteratief verfijnd. Hoewel de twee instellingen verschillen in structuur en doel, zijn ze beide beperkt door dezelfde onderliggende bottleneck: het ontbreken van systemen die context kunnen herstellen, herkomst kunnen volgen en voort kunnen bouwen op eerder werk over iteraties heen. Het automatiseren van modelontwikkeling in het bedrijf is daarom een kritische stap op de weg naar AI-systemen die zichzelf kunnen verbeteren.

Doris Xin is CEO en mede-oprichter van Disarray. Als PhD aan de UC Berkeley RISELab en NSF Graduate Research Fellow, en later als vroeg ML-engineer bij LinkedIn, heeft Doris haar expertise in machine learning verfijnd.

Moustafa AbdelBaky is CTO en mede-oprichter van Disarray. Hij is een drievoudig IBM PhD Fellow met bijna twee decennia onderzoek naar autonome orkestratie over gedistribueerde systemen, edge ML en real-time AI voor NASA's autonome luchtvaart- en ruimtemissies.