De Critische Pad naar Automatisering van Modelontwikkeling

De volgende belangrijke mijlpaal voor AI-onderzoek is het automatiseren van modelontwikkeling. Elke vooruitgang in redenering, taal en perceptie is in zekere zin een stap in die richting. Het pad naar modelautomatisering vereist echter het oplossen van een reeks fundamentelere 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, waaronder 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 worden daarentegen getraind op duizenden datasets tegelijk, afkomstig van uiteenlopende bronnen met inconsistente formaten, 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 pijplijnen die eromheen zijn gebouwd kan verbeteren, kan in principe het eigen trainingsproces verbeteren en helpen bij het bouwen van betere modellen. Zodra AI het proces kan verbeteren waarop het wordt getraind, komen verbeteringen naar beneden in elk domein waar AI wordt toegepast.

Drie Barrières die in de Weg Staan

De eerste barrière is contextfragmentatie. In bijna elke organisatie zijn de signalen, experimenten, functiedefinities en institutionele kennis die relevant zijn voor een bepaald modelleerprobleem verspreid over datawarehouses, notitieboeken en pijplijnen 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 documentatiestandaards, kunnen in helemaal aparte modules van een elektronisch gezondheidsdossiersysteem 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 routinematig 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 de gerealiseerde omzet die over een abonnementsperiode is verdeeld. Alle drie halen ze gegevens op uit velden die letterlijk “omzet” heten in hun respectievelijke systemen, maar een cross-teamrapport dat ze combineert, zou stil drie onverenigbare nummers mengen.

De derde en meest systemische barrière is het ontbreken van gedocumenteerd institutioneel geheugen. Het volgen van herkomst, het oplossen van inconsistenties en het behouden van kwaliteitssignalen over zoveel bronnen 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 blijven ontdekken dat dezelfde dode einden opnieuw worden ontdekt, waardoor tijd en middelen worden verspild.

Overweeg een data science-team 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 record van wat is geprobeerd, wat is mislukt en waarom, kan een modelautomatiseringsmechanisme niet voortbouwen op opgebouwde ervaring. Het begint simpelweg opnieuw vanaf nul, steeds opnieuw, waardoor tijd 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 doelstellingmismatches 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. Recentere codeeragenten vertegenwoordigen een echte stap voorwaarts, maar ze 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, wat een vertaling is die niet alleen uit gegevens kan worden afgeleid. Het zou relevante gegevens moeten kunnen ontdekken over gefragmenteerde systemen met inconsistente schema’s, terwijl het automatisch voldoet aan nalevings-, governance- en beveiligingsbeperkingen, in plaats van te vereisen dat mensen deze als een afzonderlijk proces beheren. 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 core-mechanisme moeten zijn om het systeem te gronden in wat er werkelijk is gebeurd. En een dergelijk systeem zou een zorgvuldige human-in-the-loop-ontwerp nodig hebben. Niet een binaire keuze tussen volledige automatisering en volledige handmatige controle, maar ondersteuning voor variabele niveaus van interactie, afhankelijk van de taak, de inzet en het vertrouwen van het systeem bij elk beslissingspunt. Automatisering die menselijke oordeel overslaat op kritieke momenten is geen functie van goed ontworpen AI; het is een foutmodus.

Wat nog geen enkel lab 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 het open onderzoeksfrontier.

Wat Mogelijk Wordt

De economische implicaties van het oplossen van deze problemen zijn aanzienlijk. Aangepaste ML-ontwikkeling vandaag vereist 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 comprimeren en hoge-waarde-use-cases openen die momenteel te middelen-intensief 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’ tijd 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 model trainingspijplijnen, waarbij duizenden heterogene datasets moeten worden geaggregeerd, gefilterd en iteratief verfijnd. Hoewel de twee instellingen verschillen in structuur en doel, worden ze beide beperkt door dezelfde onderliggende bottleneck: het ontbreken van systemen die context, herkomst en eerder werk betrouwbaar kunnen herstellen over iteraties. Het automatiseren van modelontwikkeling in het bedrijf is daarom een kritische stap op het pad naar AI-systemen die zichzelf kunnen verbeteren.