Den kritiske veien til automatisering av modellutvikling

Det neste viktige milepælet for AI-forskning er å automatisere modellutvikling. Hver fremgang i resonnering, språk og persepsjon er, i noen forstand, et skritt mot dette målet. Imidlertid krever veien til modellautomatisering løsning av en rekke grunnleggende utfordringer som må løses først.

Broen til dette målet går direkte gjennom maskinlæring (ML) ingeniørarbeid. En vanlig misforståelse går ut på at ML er en forgjenger-teknologi til moderne AI og at grunnmodellene har erstattet den. Dette misforstår forholdet. Som en akademisk disiplin omfatter ML alle aspekter av modelltrening, inkludert trening av grunnmodellene i sentrum av den nåværende AI-økningen. Det er imidlertid en meningsfull forskjell i skala og datakompleksitet.

Tradisjonelle ML-modeller er vanligvis trenet på nøye kurerte, domenespesifikke datasamlinger som inneholder tusener eller millioner av eksempler. Grunnmodellene, på den andre siden, er trenet på tusener av datasamlinger samtidig, hentet fra svært forskjellige kilder med inkonsistente formater, proveniens og kvalitet. Denne forskjellen i datascale og heterogenitet er en grunnleggende årsak til at datahåndtering blir mye harder og viktigere når modellene blir mer kraftfulle.

Dette gjør dataforståelse til en sentral flaskehals i automatisering av modellutvikling. Et AI-system som kan tolke heterogen data og forbedre pipelines bygget rundt det, kunne i prinsippet forbedre sin egen treningsprosess og hjelpe med å bygge bedre modeller. Når AI kan forbedre prosessen ved hvilken den trenes, vil forbedringene kaske nedover til hver domene hvor AI brukes.

Tre barrierer som står i veien

Den første barrieren er kontekstfragmentering. I nesten hver organisasjon er signalene, eksperimentene, egenskapsdefinisjonene og institusjonell kunnskap relevante for et gitt modellproblema spredt over dataforvarelser, notatbøker og pipelines som aldri var designet til å kommunisere med hverandre. Overvei et helsevesen som bygger en sepsisdeteksjonsmodell. De kliniske kriteriene relevante for dette problemet, som vitalt terskel, laborverdier og dokumentasjonsstandarder, kan bo i helt separate moduler av et elektronisk helsejournal-system.

Den andre barrieren er semantisk tvetydighet. Mening er ikke innebygget i data, men er isteden kontekstuell og organisatorisk. Samme feltNavn i to forskjellige databaser kan referere til subtilt forskjellige ting. Konsepter som omsetning, aktiv bruker og churn har rutinemessig flere gyldige definisjoner innen en enkelt bedrift. Selv et konsept som “omsetning” kan forårsake problemer. En salgsavdeling kan definere omsetning som den totale verdien av kontrakter signert denne kvartalen, mens finansavdelingen definerer det som kontant faktisk mottatt. Produktavdelingen har en annen forståelse, da den definerer begrepet som anerkjent omsetning fordelt over en abonnementsperiode. Alle tre trekker fra felt som bokstavelig talt er navngitt “omsetning” i deres respektive systemer, men en tverrteam-rapport som kombinerer dem ville stille blande tre inkompatible tall.

Den tredje og mest systemiske barrieren er fraværet av dokumentert institusjonell minne. Sporing av proveniens, løsning av inkonsistenser og vedlikehold av kvalitetssignaler over så mange kilder er et uløst problem, selv for menneskelige team. Uten en institusjonell minne om hva som ble prøvd og hvordan godt disse tilnærmingene fungerte, vil noen modellautomatiseringsmekanisme fortsette å gjenopdage samme døde ender, spille tid og ressurser.

Overvei et data science-team i en detaljhandelsbedrift som bygger en etterspørselsprognosemodell. Over tre år har en dusin analytikere hver uavhengig oppdaget at råværmdata forringrer modellens ytelse under ferieuker, at en bestemt leverandørs lagerfeed inneholder en systematisk forsinkelse, og at standardtilnærmingen til å håndtere promoteringer forårsaker mål-lekkasje. Når de opprinnelige analytikerne flyttet til andre team eller forlot bedriften, forsvant kunnskapen med dem. Uten en institusjonell registrering av hva som ble prøvd, hva som feilet og hvorfor, kan en modellautomatiseringsmekanisme ikke bygge på akkumulert erfaring. Den starter bare fra null, gang på gang, unødvendig spillende tid.

Hva en virkelig løsning krever

Historien om ML-automatisering er en historie om delvis løsninger. AutoML adresserte det smale problemet med hyperparameter-justering, men kunne ikke håndtere mål-mismatch eller resonere om organisatorisk intensjon. MLOps gjorde produksjons-pipelines mer robuste og lettere å overvåke, men MLOps-verktøy utfører en strategi i stedet for å definere den. Mer nylige kode-agenter representerer et genuint skritt fremover, men de har arvet samme blindpunkt. De genererer kode godt mens de opererer uten organisatorisk kontekst eller institusjonell minne.

Et system i stand til å virkelig autonom ML-ingeniørarbeid ville trenge kapasiteter som ingen eksisterende verktøy tilbyr i kombinasjon. Det ville trenge å kartlegge forretningsmål til modell-objektiver, som er en oversettelse som ikke kan sluttes fra data alene. Det ville trenge å oppdage relevante data over fragmenterte systemer med inkonsistente skjema, mens det automatisk overholder overholdelse, styring og sikkerhetsbegrensninger, i stedet for å trenge mennesker å håndtere dem som en separat prosess. Det ville trenge institusjonell minne for å fremme eksisterende arbeid, forstå hvorfor tidligere eksperimenter ble forkastet, og bygge på hva kolleger allerede vet.

Strengt revisjons-spor som sporer proveniens over data-versjoner, egenskapsdefinisjoner og kode-kommiter ville trenge å være en kjerne-mekanisme for å grunne systemet i hva som faktisk skjedde. Og et slikt system ville trenge nøye menneske-i-løkken-design. Ikke et binært valg mellom full automatisering og full manuell kontroll, men støtte for varierende nivåer av interaksjon avhengig av oppgaven, innsatsen og systemets tillit ved hver avgjørelse. Automatisering som omgår menneskelig dømmekraft ved kritiske øyeblikk er ikke en funksjon av godt designet AI; snarere er det en feilmodus.

Hva ingen lab ennå har løst er hvordan man kan skape en semantisk forståelse av organisatorisk data som forstår hva data betyr i en spesifikk institusjonell kontekst. MCP løser koblingsproblemet. Den løser ikke meningsproblemet. Det forblir det åpne forskningsfronten.

Hva som blir mulig

De økonomiske implikasjonene av å løse disse problemene er betydelige. Tilpasset ML-utvikling i dag krever spesialist-praktikere og uker med iterasjon, selv for godt avgrensede problemer. Et system som kunne navigere hele arbeidsflyten autonomt fra problemdefinisjon til data-oppdagelse, modellutvikling og modell-evaluering ville endre denne ligningen dramatisk, komprimere tidsrammer og åpne høyverdi- bruksområder som i dag er for ressurskrevende å følge. Prosjekter som tidligere krevde team med dyp ML-ekspertise som arbeidet i uker, kan nå fullføres på dager uten å måtte bruke så mye av sjeldne ML-eksperters tid.

Utfordringene med kontekst-fragmentering, semantisk tvetydighet og manglende institusjonell minne er ikke unike for bedrifts-ML. De manifesterer seg under forskjellige begrensninger i konstruksjonen av grunnmodell-trenings-pipelines, hvor tusener av heterogene datasamlinger må samles, filtreres og iterativt finjusteres. Mens de to settingene skille seg i struktur og objektive, er begge begrensede av samme underliggende flaskehals: fraværet av systemer som kan pålitelig gjenopprette kontekst, spore proveniens og bygge på tidligere arbeid over iterasjoner. Automatisering av modellutvikling i bedriften er derfor et kritisk skritt på veien mot AI-systemer som kan forbedre seg selv.