Den kritiska vägen till automatiserad modellutveckling

Nästa viktiga milstolpe för AI-forskning är att automatisera modellutveckling. Varje framsteg inom resonemang, språk och perception är, i någon mening, ett steg mot det målet. Men vägen till modellautomatisering kräver att man löser en uppsättning grundläggande utmaningar som måste lösas först.

Bron till det målet går direkt genom maskinlärning (ML) teknik. En vanlig missuppfattning är att ML är en föregångare till modern AI och att grundmodeller har ersatt det. Detta missförstår relationen. Som en akademisk disciplin omfattar ML alla aspekter av modellträning, inklusive träning av grundmodeller i centrum för den nuvarande AI-eran. Det finns dock en meningsfull skillnad i skala och datakomplexitet.

Traditionella ML-modeller tränas vanligtvis på noggrant kuraterade, domänspecifika dataset som innehåller tusentals eller miljontals exempel. Grundmodeller, å andra sidan, tränas på tusentals dataset samtidigt, hämtade från mycket olika källor med inkonsekventa format, proveniens och kvalitet. Denna skillnad i datascale och heterogenitet är en grundläggande anledning till varför datahantering blir mycket svårare och viktigare när modellerna blir mer kraftfulla.

Det gör dataförståelse till en central flaskhals i automatiserad modellutveckling. Ett AI-system som kan tolka heterogen data och förbättra pipelines som byggs runt det kunde, i princip, förbättra sin egen träningsprocess och hjälpa till att bygga bättre modeller. När AI kan förbättra processen genom vilken det tränas, sker förbättringar i nedströms till varje domän där AI tillämpas.

Tre barriärer som står i vägen

Den första barriären är kontextfragmentering. I nästan varje organisation är signalerna, experimenten, featuredefinitionerna och institutionella kunskapen som är relevanta för ett visst modelleringsproblem utspridda över datawarehouses, anteckningsböcker och pipelines som aldrig var avsedda att kommunicera med varandra. Tänk på ett hälsovårdssystem som bygger en sepsisdetektionsmodell. De kliniska kriterierna som är relevanta för det problemet, såsom vitala trösklar, labvärden och dokumentationsstandarder, kan bo i helt separata moduler av ett elektroniskt journalsystem.

Den andra barriären är semantisk tvetydighet. Betydelse är inte inneboende i data, utan är istället kontextuell och organisatorisk. Samma fältnamn i två olika databaser kan hänvisa till subtilt olika saker. Koncept som intäkt, aktiv användare och avhopp har rutinmässigt flera giltiga definitioner inom ett företag. Även ett koncept som verkar så enkelt som “intäkt” kan orsaka problem. En säljgrupp kan definiera intäkt som det totala värdet av kontrakt som undertecknats under kvartalet, medan finansgruppen definierar det som kontant som faktiskt mottagits. Produktgruppen har ännu en annan förståelse, eftersom den definierar termen som erkänd intäkt spridd över en prenumerationsperiod. Alla tre drar från fält som bokstavligen heter “intäkt” i sina respektive system, men en tvärgruppsrapport som kombinerar dem skulle tyst blanda tre oförenliga siffror.

Den tredje och mest systematiska barriären är avsaknaden av dokumenterad institutionell minne. Att spåra proveniens, lösa inkonsekvenser och upprätthålla kvalitetssignaler över så många källor är ett olöst problem, även för mänskliga team. Utan en institutionell minnesbild av vad som försöktes och hur väl dessa tillvägagångssätt fungerade, kommer varje modellautomatiseringsmekanism att fortsätta upptäcka samma döda ändar, slösa tid och resurser.

Tänk på en data science-grupp på ett detaljhandelsföretag som bygger en efterfrågeprognosmodell. Under tre år har ett dussin analytiker var och en oberoende upptäckt att råa väderdata försämrar modellens prestanda under helgveckor, att en viss leverantörs lagerflöde innehåller en systematisk fördröjning och att den standardiserade metoden för att hantera kampanjevenemang orsakar målmässig läckage. När de ursprungliga analytikerna flyttade till andra team eller lämnade företaget, försvann kunskapen med dem. Utan en institutionell registrering av vad som försöktes, vad som misslyckades och varför, kan en modellautomatiseringsmekanism inte bygga på ackumulerad erfarenhet. Den börjar från scratch, om och om igen, onödigt slösar tid.

Vad en riktig lösning kräver

Historien om ML-automatisering är en historia om partiella lösningar. AutoML hanterade det smala problemet med hyperparametertuning, men kunde inte hantera målmässiga inkonsekvenser eller resonera om organisatorisk avsikt. MLOps gjorde produktionspipelines mer robusta och lättare att övervaka, men MLOps-verktyg utför en strategi snarare än att definiera den. Mer nyligen kodagenter representerar ett verkligt steg framåt, men de har ärvt samma blind fläck. De genererar kod bra medan de opererar utan organisatorisk kontext eller institutionell minne.

Ett system som kan hantera genuint autonom ML-teknik skulle behöva funktioner som ingen befintlig verktyg tillhandahåller i kombination. Det skulle behöva kartlägga affärsmål till modellmål, vilket är en översättning som inte kan härledas från data ensam. Det skulle behöva upptäcka relevant data över fragmenterade system med inkonsekventa scheman, samtidigt som det automatiskt följer efterlevnad, styrning och säkerhetsbegränsningar, snarare än att kräva att människor hanterar dem som en separat process. Det skulle behöva institutionell minne för att bringa fram befintligt arbete, förstå varför tidigare experiment övergavs och bygga på vad kollegor redan vet.

Stränga revisionsledningar som spårar proveniens över dataversioner, featuredefinitioner och kodkommiter skulle behöva vara en kärnmekanism för att förankra systemet i vad som faktiskt hände. Och ett sådant system skulle kräva en genomtänkt mänsklig-i-loopen-design. Inte ett binärt val mellan full automatisering och full manuell kontroll, utan stöd för varierande nivåer av interaktion beroende på uppgiften, insatserna och systemets förtroende vid varje besluts punkt. Automatisering som kringgår mänsklig bedömning vid kritiska ögonblick är inte en funktion i välutformad AI; snarare är det ett felaktigt läge.

Vad ingen labb ännu har löst är hur man skapar en semantisk förståelse av organisatorisk data som förstår vad data betyder i en specifik institutionell kontext. MCP löser anslutningsproblemet. Den löser inte meningsproblemet. Det förblir den öppna forskningsfronten.

Vad som blir möjligt

De ekonomiska implikationerna av att lösa dessa problem är betydande. Anpassad ML-utveckling idag kräver specialistpraktiker och veckor av iteration, även för välavgränsade problem. Ett system som kunde navigera hela arbetsflödet autonomt från problemdefinition till dataupptäckt, modellutveckling och modellutvärdering skulle förändra den ekvationen dramatiskt, komprimera tidsramar och öppna högvärdesanvändningsfall som för närvarande är för resurskrävande att följa. Projekt som tidigare krävde team med djup ML-kompetens som arbetade i veckor kan nu slutföras på dagar utan att behöva använda så mycket av sällsynta ML-experter.