Den kritiske veien til automatisering av modellutvikling

Neste viktige milepæl for AI-forskning er å automatisere modellutvikling. Hver fremgang i resonnering, språk og persepsjon er, i noen måte, 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 hevder at ML er en forgjenger-teknologi til moderne AI og at foundation-modeller har erstattet den. Dette misforstår forholdet. Som en akademisk disiplin omfatter ML alle aspekter av modelltrening, inkludert trening av foundation-modeller i sentrum av den nåværende AI-økten. Det er imidlertid en meningsfull forskjell i skala og datakompleksitet.

Tradisjonelle ML-modeller er vanligvis trenet på nøye kurerte, domenespesifikke datasett som inneholder tusener eller millioner av eksempler. Foundation-modeller, på den andre siden, er trenet på tusener av datasett samtidig, hentet fra svært forskjellige kilder med inkonsistente formater, proveniens og kvalitet. Denne forskjellen i data-skala og heterogenitet er en grunnleggende årsak til at dataforståelse blir en sentral flaskehalstapning 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 det trenes, strømmer forbedringene nedover til hvert domene hvor AI brukes.

Tre barrierer som står i veien

Den første barrieren er kontekstfragmentering. I nesten hver organisasjon er signalene, eksperimentene, funksjonsdefinisjonene og institusjonelle kunnskapen relevante for et gitt modellproblematikk spredt over datahus, notebooker og pipelines som aldri var designet til å kommunisere med hverandre. Vurdér 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 felt-navn i to forskjellige databaser kan referere til subtilt forskjellige ting. Konsepter som inntekt, aktiv bruker og avhopping har ofte flere gyldige definisjoner innen en enkelt bedrift. Selv et konsept som “inntekt” kan forårsake problemer. En salgsavdeling kan definere inntekt som totalverdien av kontrakter signert denne kvartalen, mens finansavdelingen definerer det som kontant faktisk mottatt. Produktavdelingen har enda en annen forståelse, da den definerer begrepet som anerkjent inntekt fordelt over en abonnementsperiode. Alle tre trekker fra felt som bokstavelig talt er navngitt “inntekt” i deres respektive systemer, men en tverrteam-rapport som kombinerer dem ville stille mixe tre inkonsistente tall.

Den tredje og mest systemiske barrieren er fraværet av dokumentert institusjonell minne. Å spore proveniens, løse inkonsistenser og vedlikeholde kvalitetsignaler 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 modellautomatiseringsmekanismer bare gjenopdage samme døde ender, ødelegge tid og ressurser.

Vurdér et data-vitenskapelig team i en detaljhandelsbedrift som bygger en etterspørselsprognosemodell. Over tre år har en dusin analytikere hver uavhengig oppdaget at rå værdata forringrer modell-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-lækasje. Når de opprinnelige analytikerne flyttet til andre team eller forlot bedriften, forlot kunnskapen dem. Uten en institusjonell rekord av hva som ble prøvd, hva feilet og hvorfor, kan en modellautomatiseringsmekanisme ikke bygge på akkumulert erfaring. Den starter bare fra null, igjen og igjen, unødvendig å ødelegge 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-uoverensstemmelser eller resonnere 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 evner 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 kompatibilitets-, styrings- og sikkerhetsbegrensninger, i stedet for å kreve at mennesker håndterer dem som en separat prosess. Det ville trenge institusjonell minne for å fremme eksisterende arbeid, forstå hvorfor tidligere eksperimenter ble forlatt og bygge på hva kolleger allerede vet.

Strengt audit-spor som sporer proveniens over data-versjoner, funksjonsdefinisjoner og kode-kommiter ville trenge å være en kjerne-mekanisme for å grunne systemet i hva som faktisk skjedde. Og et slikt system ville trenge tankefull menneske-i-løkken-design. Ikke en binær 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 i 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. Det 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 definerte problemer. Et system som kunne navigere hele arbeidsflyten autonomt fra problem-definisjon gjennom data-oppdagelse, modellutvikling og modell-evaluering ville endre denne ligningen dramatisk, komprimere tidsrammer og åpne høyverdiige bruksområder som i dag er for ressurskrevende å følge.

Utfordringene med kontekstfragmentering, semantisk tvetydighet og manglende institusjonell minne er ikke unike for bedrifts-ML. De manifesterer seg under forskjellige begrensninger i konstruksjonen av foundation-modell-trenings-pipelines, hvor tusener av heterogene datasett må samles, filtreres og iterativt forbedres. Mens de to settingene skiller seg i struktur og objekt, er begge begrensede av samme underliggende flaskehalstapning: 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 i stand til å forbedre seg selv.