Den kritiske vej til automatisering af modeludvikling

Næste vigtige milepæl for AI-forskning er at automatisere modeludvikling. Hver fremgang i resonnering, sprog og perception er på en måde et skridt mod dette mål. however, vejen til modelautomatisering kræver løsning af en række grundlæggende udfordringer, der først må løses.

Broen til dette mål løber direkte gennem machine learning (ML) ingeniørarbejde. En almindelig misforståelse går ud på, at ML er en forgænger-teknologi til moderne AI, og at grundlæggende modeller har erstattet det. Dette misforstår forholdet. Som en akademisk disciplin omfatter ML alle aspekter af modeltræning, herunder træning af grundlæggende modeller i centrum af den nuværende AI-æra. Der er dog en betydelig forskel i skala og datakompleksitet.

Traditionelle ML-modeller trænes typisk på omhyggeligt udvalgte, domænespecifikke datasæt, der indeholder tusinder eller millioner af eksempler. Grundlæggende modeller, på den anden side, trænes på tusinder af datasæt samtidig, hentet fra vidt forskellige kilder med inkonsistente formater, proveniens og kvalitet. Denne forskel i datascale og heterogenitet er en grundlæggende årsag til, at dataforståelse bliver en central flaskehals i automatisering af modeludvikling. Et AI-system, der kan fortolke heterogen data og forbedre pipelinesne bygget omkring det, kunne i princippet forbedre sin egen træningsproces og hjælpe med at bygge bedre modeller. Når AI kan forbedre processen, hvormed det trænes, sker forbedringerne i alle domæner, hvor AI anvendes.

Dette gør dataforståelse til en central flaskehals i automatisering af modeludvikling. Et AI-system, der kan fortolke heterogen data og forbedre pipelinesne bygget omkring det, kunne i princippet forbedre sin egen træningsproces og hjælpe med at bygge bedre modeller. Når AI kan forbedre processen, hvormed det trænes, sker forbedringerne i alle domæner, hvor AI anvendes.

Tre barrierer, der står i vejen

Den første barriere er kontekstfragmentering. I næsten enhver organisation er signalerne, eksperimenterne, funktiondefinitionerne og institutionelle viden, der er relevant for et given modellingsproblem, spredt over datawarehouse, notebooks og pipelines, der aldrig var designet til at kommunikere med hinanden. Overvej et sundhedssystem, der bygger en sepsisdetektionsmodel. De kliniske kriterier, der er relevante for dette problem, såsom vitaltreshold, laboratoriedata og dokumentationsstandarder, kan bo i helt separate moduler af et elektronisk sundhedsjournal-system.

Den anden barriere er semantisk tvetydighed. Meningen er ikke indbygget i data, men er kontekstuel og organisatorisk. Samme feltNavn i to forskellige databaser kan referere til subtilt forskellige ting. Koncepter som omsætning, aktiv bruger og churn har ofte multiple gyldige definitioner inden for en enkelt virksomhed. Selv et koncept som “omsætning” kan forårsage problemer. En salgsteam kan definere omsætning som den samlede værdi af kontrakter, der er undertegnet i dette kvartal, mens finansholdet definerer det som kontanter, der faktisk er modtaget. Produktteamet har endnu en anden forståelse, da det definerer begrebet som anerkendt omsætning fordelt over en abonnementsperiode. Alle tre trækker fra felter, der bogstaveligt talt hedder “omsætning” i deres respektive systemer, men en tværgående rapport, der kombinerer dem, ville stille stille mixe tre inkompatible tal.

Den tredje og mest systemiske barriere er manglen på dokumenteret institutionel hukommelse. At spore proveniens, løse inkonsistenser og opretholde kvalitetssignaler på tværs af så mange kilder er et uløst problem, selv for menneskelige hold. Uden en institutionel hukommelse af, hvad der er prøvet, og hvordan disse tilgange fungerede, vil enhver modelautomatiseringsmekanisme fortsætte med at genopdage de samme døde ender, spilde tid og ressourcer.

Overvej et datavidenskabsteam i en detailhandelsvirksomhed, der bygger en efterspørgselsprognosemodel. Over tre år har en dusin analytikere hver uafhængigt opdaget, at rå vejrdata forringrer modelpræstation under ferieuger, at en bestemt leverandørs lagerfeed indeholder en systematisk forsinkelse, og at den standardmæssige tilgang til at håndtere promotionsbegivenheder forårsager måludladning. Når de oprindelige analytikere flyttede til andre hold eller forlod virksomheden, forsvandt viden med dem. Uden en institutionel optagelse af, hvad der er prøvet, hvad der mislykkedes og hvorfor, kan en modelautomatiseringsmekanisme ikke bygge på opbygget erfaring. Den starter simpelthen fra scratch, igen og igen, unødvendigt spildende tid.

Hvad en rigtig løsning kræver

Historien om ML-automatisering er en historie om delvise løsninger. AutoML løste det snævre problem med hyperparameter-justering, men kunne ikke håndtere målmodsigelser eller resonere om organisatorisk intention. MLOps gjorde produktionspipelines mere robuste og lettere at overvåge, men MLOps-værktøjer udfører en strategi snarere end definerer den. Mere nylige kodningsagenter repræsenterer et ægte skridt fremad, men de har arvet den samme blinde plet. De genererer kode godt, mens de opererer uden organisatorisk kontekst eller institutionel hukommelse.

Et system, der er i stand til virkelig autonom ML-ingeniørarbejde, ville kræve kapaciteter, som ingen eksisterende værktøj tilbyder i kombination. Det ville kræve at kortlægge forretningsmål til modelobjektiver, hvilket er en oversættelse, der ikke kan sluttes af data alene. Det ville kræve at opdage relevant data på tværs af fragmenterede systemer med inkonsistente skemaer, mens det automatisk overholder compliance-, styre- og sikkerhedsbegrænsninger, snarere end at kræve, at mennesker håndterer dem som en separat proces. Det ville kræve institutionel hukommelse for at fremme eksisterende arbejde, forstå, hvorfor tidligere eksperimenter blev opgivet, og bygge på, hvad kolleger allerede ved.

Strengt audit-spor, der sporer proveniens på tværs af dataversioner, funktiondefinitioner og kodecommits, ville kræve at være en kerne mekanisme for at grundlægge systemet i, hvad der faktisk skete. Og et sådant system ville kræve omhyggelig menneske-i-løkken design. Ikke en binær valg mellem fuld automatisering og fuld manuel kontrol, men støtte til varierende niveauer af interaktion afhængigt af opgaven, indsatsen og systemets tillid på hvert beslutningspunkt. Automatisering, der omgår menneskelig dømmekraft på kritiske øjeblikke, er ikke en funktion af vel-designet AI; snarere er det en fejltilstand.

Hvad ingen laboratorie endnu har løst, er, hvordan man skaber en semantisk forståelse af organisatorisk data, der forstår, hvad data betyder i en specifik institutionel kontekst. MCP løser problemer med tilslutning. Det løser ikke endnu meningsproblemet. Det forbliver det åbne forskningsfront.

Hvad der bliver muligt

De økonomiske implikationer af at løse disse problemer er betydelige. Tilpasset ML-udvikling i dag kræver specialister og uger med iteration, selv for veldefinerede problemer. Et system, der kunne navigere i hele arbejdsgangen autonomt fra problemdefinering til dataopdagelse, modeludvikling og modelvurdering, ville ændre denne ligning dramatisk, komprimere tidsrammer og åbne højværdi brugstilfælde, der i øjeblikket er for ressourcekrævende at forfølge. Projekter, der tidligere krævede hold med dyb ML-ekspertise, der arbejdede i uger, kan nu afsluttes på få dage uden at skulle bruge så meget af de sjældne ML-eksperters tid.

Udfordringerne med kontekstfragmentering, semantisk tvetydighed og manglende institutionel hukommelse er ikke unikke for virksomheds-ML. De manifesterer sig under forskellige begrænsninger i opbygningen af grundlæggende modeltræningspipelines, hvor tusinder af heterogene datasæt skal aggregieres, filtreres og iterativt forfineres. Selv om de to indstillinger adskiller sig i struktur og objekt, er de begge begrænsede af den samme underliggende flaskehals: manglen på systemer, der kan pålideligt genskabe kontekst, spore proveniens og bygge på tidligere arbejde på tværs af iterationer. Automatisering af modeludvikling i virksomheden er derfor et kritisk skridt på vejen mod AI-systemer, der kan forbedre sig selv.