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 den. 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 datamängder som innehåller tusentals eller miljontals exempel. Grundmodeller, å andra sidan, tränas på tusentals datamängder samtidigt, hämtade från mycket olika källor med inkonsekventa format, proveniens och kvalitet. Denna skillnad i dataskala och heterogenitet är en grundläggande anledning till varför datahantering blir mycket svårare och viktigare när modellerna blir mer kraftfulla.

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

Tre hinder på vägen

Det första hindret är kontextfragmentering. I nästan varje organisation är signalerna, experimenten, funktiondefinitionerna och institutionella kunskapen som är relevanta för ett visst modellproblem utspridda över datawarehouses, anteckningsböcker och pipelines som aldrig var avsedda att kommunicera med varandra. Överväg ett hälsovårdssystem som bygger en sepsisdetekteringsmodell. De kliniska kriterierna som är relevanta för det problemet, såsom vitala trösklar, laboratorievärden och dokumentationsstandarder, kan finnas i helt separata moduler av ett elektroniskt hälsojournalssystem.

Det andra hindret är semantisk tvetydighet. Betydelse är inte inneboende i data, utan är kontextuell och organisatorisk. Samma fältname i två olika databaser kan referera 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 det här kvartalet, medan finansgruppen definierar det som kontant som faktiskt mottagits. Produktgruppen har en annan förståelse, eftersom den definierar termen som erkänd intäkt fördelad över en prenumerationsperiod. Alla tre hämtar från fält som bokstavligen heter “intäkt” i sina respektive system, men en tvärgruppsrapport som kombinerar dem skulle tyst blandar tre oförenliga siffror.

Det tredje och mest systematiska hindret ä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 har prövats och hur väl dessa tillvägagångssätt fungerade, kommer varje modellautomatiseringsmekanism att fortsätta upptäcka samma döda ändar, slösa bort tid och resurser.

Överväg ett datavetenskapsteam på ett detaljhandelsföretag som bygger en efterfråganprognosmodell. 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ålläckage. När de ursprungliga analytikerna flyttade till andra team eller lämnade företaget, lämnade kunskapen med dem. Utan en institutionell post om vad som har prövats, vad som misslyckades och varför, kan en modellautomatiseringsmekanism inte bygga på ackumulerad erfarenhet. Den börjar helt enkelt från scratch, om och om igen, slösar bort tid i onödan.

Vad en riktig lösning kräver

Historien om ML-automatisering är en historia om partiella lösningar. AutoML hanterade det smala problemet med hyperparameterjustering, men kunde inte hantera målmotsättningar eller resonera om organisatorisk avsikt. MLOps gjorde produktionspipeliner mer robusta och lättare att övervaka, men MLOps-verktyg utför en strategi snarare än att definiera den. Mer nyligen kodagenter representerar ett äkta 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 göra äkta autonom ML-teknik skulle behöva funktioner som ingen befintlig verktyg tillhandahåller i kombination. Det skulle behöva översätta 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 befintligt arbete till ytan, förstå varför tidigare experiment övergavs och bygga på vad kollegor redan vet.

Stränga revisionsledningar som spårar proveniens över dataversioner, funktiondefinitioner 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 beslutspunkt. 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 har löst ännu är hur man skapar en semantisk förståelse av organisatoriska data som förstår vad data betyder i en specifik institutionell kontext. MCP löser anslutningsproblemet. Det löser inte betydelseproblemet. 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äldefinierade 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.

Utmaningarna med kontextfragmentering, semantisk tvetydighet och saknad institutionell minne är inte unika för företags-ML. De manifesterar sig under olika begränsningar i konstruktionen av grundmodellsträningspipeliner, där tusentals heterogena datamängder måste aggregeras, filtreras och iterativt raffineras. Medan de två miljöerna skiljer sig åt i struktur och mål, är båda begränsade av samma underliggande flaskhals: avsaknaden av system som kan tillförlitligt återställa kontext, spåra proveniens och bygga på tidigare arbete över iterationer. Att automatisera modellutveckling i företaget är därför ett kritiskt steg på vägen mot AI-system som kan förbättra sig själva.