Den kritiske vej til automatisering af modeludvikling

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

Broen til dette mål løber direkte gennem maskinlæringsingeniørarbejde (ML). 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-øjeblik. Der er dog en væsentlig forskel i skala og datakompleksitet.

Traditionelle ML-modeller trænes typisk på omhyggeligt kuraterede, domænespecifikke datasæt, der indeholder tusinder eller millioner af eksempler. Grundlæggende modeller, til gengæld, trænes på tusinder af datasæt samtidig, trukket fra vidt forskellige kilder med inkonsistente formater, proveniens og kvalitet. Denne forskel i dataskala og heterogenitet er en grundlæggende årsag til, at dataforvaltning bliver meget sværere og vigtigere, når modellerne bliver mere kraftfulde.

Det gør dataforståelse til en central flaskehals i automatisering af modeludvikling. Et AI-system, der kan fortolke heterogen data og forbedre pipelines 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, vil forbedringerne kaske nedstrøms til hvert domæne, 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 givent modelproblem, 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 vitaltærskler, laboratorieværdier 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 i stedet kontekstuel og organisatorisk. Samme feltNavn i to forskellige databaser kan referere til subtilt forskellige ting. Koncepter som omsætning, aktiv bruger og churn har rutinemæssigt 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 til at betyde 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 blande tre inkompatible tal.

Den tredje og mest systemiske barriere er fraværet af 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æstationen 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åludløsning. 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 fejlede og hvorfor, kan en modelautomatiseringsmekanisme ikke bygge på opbygget erfaring. Den starter simpelthen fra nul, 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 adresserede det snævre problem med hyperparameter-justering, men kunne ikke håndtere objektive mismatches eller resonere om institutionelt formål. 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 institutionel kontekst eller hukommelse.

Et system, der er i stand til virkelig autonom ML-ingeniørarbejde, ville kræve funktioner, 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 overensstemmelse, styring 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.

Strenge revisionsstier, der sporer proveniens på tværs af dataversioner, funktiondefinitioner og kodecommits, ville kræve at være en kernefunktion 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 veludformet AI; snarere er det en fejltilstand.

Hvad ingen laboratorium endnu har løst, er, hvordan man skaber en semantisk forståelse af institutionelle data, der forstår, hvad data betyder i en specifik institutionel kontekst. MCP løser forbindelsesproblemet. Det løser ikke endnu meningsproblemet. Det forbliver den åbne forskningsfront.

Hvad der bliver muligt

De økonomiske implikationer af at løse disse problemer er betydelige. Tilpasset ML-udvikling i dag kræver specialiserede praktikere og uger med iteration, selv for veldefinerede problemer. Et system, der kunne navigere i hele arbejdsprocessen autonomt fra problemdefinition 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 knappe ML-eksperters tid.

Udfordringerne med kontekstfragmentering, semantisk tvetydighed og manglende institutionel hukommelse er ikke unikke for enterprise ML. De manifesterer sig under forskellige begrænsninger i konstruktionen af grundlæggende modeltræningspipelines, hvor tusinder af heterogene datasæt skal samles, filtreres og iterativt forfineres. Selv om de to indstillinger adskiller sig i struktur og formål, er de begge begrænsede af den samme underliggende flaskehals: fraværet af 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.