En model, der virker i en notebook, er et lovende resultat. En model, der virker i produktion, er et system. Afstanden mellem de to er større, end den ser ud, og det er her, de fleste machine learning-projekter går i stå: modellen er god nok, men den kan ikke drives, gentages eller stoles på, når data ændrer sig.
Dette indlæg samler de ting, der skal være på plads, før en model kan bære en del af et virkeligt system. Som eksempel bruger vi den fiktive virksomhed Space Travel, der vil forudsige efterspørgslen på sine rejser for at planlægge kapacitet.
Kløften mellem notebook og produktion
I en notebook er alt under kontrol: et udtræk af data, der ikke ændrer sig, kode, der køres i en bestemt rækkefølge, og en person, der kigger på resultatet. I produktion er intet af det sandt. Data kommer løbende og ser lidt anderledes ud hver måned, koden kører uden opsyn, og resultatet bruges af andre systemer, som ikke kan se, om det er fornuftigt.
Derfor er spørgsmålet ikke kun "hvor præcis er modellen?", men også:
- Kan vi træne præcis den samme model igen?
- Beregnes input på samme måde under træning og i produktion?
- Opdager vi det, når modellen bliver dårligere?
- Hvad sker der, når modellen ikke kan svare?
Reproducerbarhed og dataversionering
En model er resultatet af kode, data, parametre og miljø. Ændres én af dem, får man en anden model. For at kunne genskabe en model, forklare en forudsigelse eller rulle tilbage til den forrige version skal alle fire kunne findes igen:
- Kode i git, som al anden kode.
- Data versioneret, så man ved præcis hvilket udtræk en model er trænet på. Det kan være et værktøj som DVC, et versioneret datalager eller blot uforanderlige, daterede udtræk med en checksum.
- Parametre og resultater registreret for hver træning, så man kan sammenligne kørsler.
- Miljø låst: biblioteksversioner, og gerne et container-image, så træningen kører ens på enhver maskine.
Hver model, der udgives, får en version, og versionen følger med hvert svar, modellen giver. Så kan man altid se, hvilken model der stod bag en bestemt forudsigelse.
Samme features under træning og i drift
En af de mest almindelige fejl er, at input beregnes på én måde under træning og på en anden måde i produktion, f.eks. fordi træningen bruger et færdigt udtræk, mens produktionen beregner de samme værdier live i et andet sprog. Forskellene er ofte små og usynlige, men modellen mærker dem. Den bedste beskyttelse er at have én implementering af feature-beregningen, som både træning og drift bruger, og en test, der sammenligner de to på de samme rådata.
Overvågning af drift
En model bliver ikke dårligere, fordi koden ændrer sig. Den bliver dårligere, fordi verden gør. Der er tre ting at holde øje med:
- Data-drift: fordelingen af input ændrer sig, f.eks. fordi nye kundegrupper kommer til eller en kilde ændrer format.
- Forudsigelses-drift: fordelingen af modellens svar ændrer sig, selvom input ser ens ud.
- Koncept-drift: sammenhængen mellem input og det rigtige svar ændrer sig. Den kan kun måles, når de rigtige svar kendes, ofte uger senere.
Overvågningen skal ikke kun vise grafer, men udløse handling: en alarm, når en fordeling har flyttet sig mere end aftalt, og en plan for, hvem der vurderer, om modellen skal trænes igen.
Fallback-strategier
En model vil før eller siden ikke kunne svare: tjenesten er nede, input er ugyldigt, eller svaret er så usikkert, at det ikke bør bruges. Systemet omkring modellen skal vide, hvad det så gør. Typiske strategier er:
- En enkel regel, f.eks. sidste års efterspørgsel for samme rejse og uge.
- Den forrige model, hvis den nye opfører sig uventet.
- En sikker standardværdi og en markering af, at svaret ikke kommer fra modellen.
Det vigtigste er, at fallback er et bevidst valg, som er testet, og at det fremgår af svaret, når det bruges. Ellers opdager ingen, at modellen i en uge ikke har svaret på noget.
Integration via et API
Den sikreste måde at koble en model på resten af systemet er at sætte den bag et API med en klar kontrakt, ligesom enhver anden tjeneste: valideret input, en tidsgrænse, versioneret output og fejl i et fast format. Svaret bør fortælle, hvilken model der svarede, hvor sikker den var, og om der blev brugt fallback:
{
"tripId": "MARS-2031-07",
"week": "2031-W27",
"predictedBookings": 184,
"interval": {
"low": 151,
"high": 219
},
"model": {
"name": "demand-forecast",
"version": "2031.06.2"
},
"fallback": false
}{
"tripId": "MARS-2031-07",
"week": "2031-W27",
"predictedBookings": 170,
"interval": null,
"model": null,
"fallback": true,
"fallbackReason": "model-timeout",
"fallbackRule": "same-week-last-year"
}Med en sådan kontrakt kan resten af systemet behandle modellen som en almindelig afhængighed: det kan sætte tidsgrænser, logge versionen, falde tilbage, når det er nødvendigt, og skifte model uden at ændre klienterne.
Udgiv forsigtigt
En ny model bør ikke gå direkte fra test til alle brugere. To enkle teknikker mindsker risikoen:
- Skyggedrift: den nye model får de samme forespørgsler som den gamle, men dens svar bruges ikke. Man sammenligner bare.
- Gradvis udrulning: den nye model svarer først for en lille andel af forespørgslerne, og andelen øges, når tallene ser fornuftige ud.
Begge kræver, at modelversionen logges med hvert svar, og at det er let at skifte tilbage. Det er den samme disciplin som ved enhver anden udgivelse; machine learning gør den bare mere nødvendig.
Kort sagt
- En model i produktion er et system: kode, data, parametre og miljø skal kunne genskabes.
- Versionér data, og lad modelversionen følge med hvert svar.
- Beregn features ét sted, så træning og drift ser de samme input.
- Overvåg data-, forudsigelses- og koncept-drift, og knyt alarmer til en plan.
- Hav en testet fallback, og vis i svaret, når den bruges.
- Sæt modellen bag et API med en klar kontrakt, og udgiv nye modeller i skyggedrift eller gradvist.
Skal jeres model fra notebook til drift?
Vi hjælper gerne med reproducerbar træning, integration via et API, overvågning og fallback, så modellen kan bære en del af et rigtigt system. Tag en uforpligtende snak.
- machine-learning
- mlops
- drift
