Gevinster:
- Evne til å gjenkjenne de spesielle utfordringene til ML knyttet til kode-data-modell trioen og pakken og presentere modellen online eller i batch i henhold til forretningsbehov.
- Evne til å implementere gradvise og tilbakerullings-distribusjonsmønstre (skygge, kanarifugl, A/B, rollback) og legge til en testet tilbakerullingsplan for hver distribusjon
- Evne til å holde data-kode-metriske koblingen til modellen satt i produksjon sporbar med evalueringsterskelkontrollert CI/CD og modellregister
Å få en modell til å oppnå 95 % nøyaktighet i den bærbare datamaskinen er bare halve historien. Den andre halvparten – ofte den vanskelige delen – er å få den modellen til ekte brukere på en pålitelig, skalerbar og vedlikeholdbar måte. MLOps (Machine Learning Operations: disiplinen med å sette, betjene og vedlikeholde ML-modeller i produksjon) kombinerer DevOps-praksisene for programvareutvikling med de unike utfordringene til ML. I denne enheten dekker vi trinnene for å flytte modellen til produksjon og hvordan kunstig intelligens hjelper i denne prosessen.
Hvorfor er ML forskjellig fra vanlig programvare?
I vanlig programvare ligger oppførselen i koden; Hvis koden ikke endres, endres ikke atferden. I ML avhenger oppførsel av både kode, data og modell. Disse tre dimensjonene skaper de ekstra utfordringene til MLOps:
- Datadrift: Dataene i produksjonen beveger seg bort fra dataene i trening over tid; modellen blir foreldet.
- Du må versjonere tre ting: Kode, data og modell – alle tre.
- Stille feil: En modell kan feile uten å krasje, uten å gi feil, bare ved å produsere feil spådommer. Å fange dette krever overvåking.
Derfor er det stor forskjell på en «arbeidsmodell» og en «produksjonsklar modell».
Modellpakking og presentasjon
Det første trinnet i å sette modellen i produksjon er å pakke den: modellfilen, nødvendige biblioteker, forbehandlingskode og versjonsinformasjon sammen som en reproduserbar helhet. Containerisering (f.eks. Docker: å legge applikasjonen i en isolert boks med alle dens avhengigheter) er standard her; Det eliminerer problemet med "det fungerte på maskinen min".
To grunnleggende mønstre for å betjene modellen:
- Online/sanntid (online): Modellen sitter bak et API, og returnerer en umiddelbar prediksjon for hver innkommende forespørsel. Lav ventetid er kritisk.
- Batch: Modellen behandler store datasett med jevne mellomrom (genererer for eksempel score for alle kunder om natten). Latency er irrelevant, effektivitet er viktig.
Hvilken som er riktig avhenger av forretningsbehovet: øyeblikkelig anbefaling på nettet, månedlig risikoscore i batch.
Tips: "Sanntid" er en kostnad, ikke standard. Batch er mye billigere og enklere hvis resultatet skal brukes innen timer. Trenger du virkelig et øyeblikkelig svar? Spør det først.
Sikre distribusjonsstrategier
Å åpne en ny modell direkte for all trafikk er risikabelt; Hvis det er feil, er alle berørt. Trygge distribusjonsmønstre:
- Shadow-distribusjon: Den nye modellen mottar produksjonstrafikk, men dens spådommer vises ikke til brukeren, bare logges. Den sammenlignes med den gamle modellen for å se om den er trygg i ekte data.
- Kanariøy-distribusjon: Den nye modellen rulles først ut til en liten prosentandel av trafikken (f.eks. 5 %); Hvis det ikke er noe problem, økes det gradvis.
- A/B-testing: To modeller presenteres for den virkelige brukeren parallelt og forretningsberegninger (konvertering, klikk) sammenlignes.
- Tilbakerulling: Mulighet for raskt å gå tilbake til den gamle versjonen hvis den nye modellen viser seg å være dårlig. Hver distribusjon bør ha en tilbakeføringsplan.
Forsiktig: En distribusjon uten en tilbakestillingsplan er ikke fullført. Å kunne gå tilbake til den gamle versjonen i løpet av minutter beskytter brukeren når den nye modellen oppfører seg uventet i produksjonen. Test dette før distribusjon.
Svak tilnærming / Sterk tilnærming
Svak: "Modellen var god i testing, vi gikk live, vi åpnet den for alle."
Güçlü: "Vi containeriserte modellen, merket den som en versjon. Først kjørte vi den i skyggemodus med produksjonstrafikk i 3 dager, og sammenlignet spådommene med den gamle modellen – avviket var akseptabelt. Deretter åpnet vi den med 5 % kanarifugl, overvåket gjennomstrømningsmålingene og latens. Når det ikke var noen problemer, økte vi gradvis tilbakerullingskommandoen til 1. ".
Forskjellen: den sterke tilnærmingen er gradvis, målt og reversibel. Risikoen er begrenset på hvert trinn.
CI/CD og automatisering
CI/CD (Continuous Integration / Continuous Deployment: pipeline for automatisk testing og frigjøring av kodeendringer) i ML dekker ikke bare koden, men også data- og modelltrinnene. En god ML CI/CD-pipeline: kjører tester når koden endres, utfører datavalidering, trener modellen på nytt (hvis nødvendig), sjekker evalueringsterskler og fremmer distribusjonen bare hvis terskelverdiene holder. Prinsippet om "trening er automatisk, utrulling er terskelbasert" hindrer den dårlige modellen fra å stille ut i produksjonen.
AI er veldig nyttig når du setter opp disse pipelines: skriving av konfigurasjonsfil (YAML) utkast, testsaker, distribusjonsskript. Men du bestemmer distribusjonsgrensene (uansett hvilken beregning som overstiger verdien som publiseres) og tilbakeføringspolicy; dette er forretningsrisikobeslutninger.
Reproduserbarhetsinfrastruktur
For å reprodusere oppførselen til en modell i produksjon, modellregister: en registrering som holder hvilken modell som ble trent med hvilke data og kode, og hvilke beregninger den mottok. For hver produksjonsmodell bør følgende være sporbare: treningsdataversjon, kodeversjon (git commit), hyperparametre, evalueringspoeng og utrullingsdato. Når et problem oppstår, bør du kunne svare på spørsmålet "hvilken modell produserte denne prediksjonen, med hvilke data?" innen minutter. Vi vil utdype dette i enhet 11.
tre minisaker
Tilfelle 1 - Problem fanget av skyggefordeling. En anbefalingsmodell slo den gamle i testing. Å kjøre den med produksjonstrafikk i skyggemodus viste seg å gi svært dårlige anbefalinger for et bestemt segment av brukere (nye brukere) – testdataene var underrepresentative for dette segmentet. Modellen ble fikset uten noen gang å bli vist til brukeren. Hvis den ble åpnet direkte, ville den nye brukeropplevelsen bli forstyrret.
Sak 2 - Ugjenkallelig fordeling. Et team rullet ut en ny prismodell for all trafikk, uten tilbakerullingsplaner. Modellen priset uventet noen produkter veldig billig. Å gå tilbake til den gamle versjonen tok timer fordi prosessen ikke var klar. Det var et alvorlig inntektstap. Etterpå ble obligatorisk tilbakeføringstesting lagt til hver distribusjon.
Tilfelle 3 - Stille datadrift. Et svindelmønster dukket opp i flere måneder uten noen feil. Men svindlernes taktikk endret seg (datadrift) og modellens tilbakekalling falt stille. Ingen la merke til det fordi det ikke var noen overvåking. Når et overvåkingspanel for prognosefordeling ble etablert, ble avdriften tidlig synlig. Vi vil dekke overvåking i enhet 8.
Kopierbare maler
Skriv et utkast til distribusjonsplan for denne modellen. Modell: [hva det gjør], bruk: [online eller batch?] Bør inkludere:1) Emballasje (beholder, versjonering)2) Inkrementell distribusjonsstrategi (skygge/kanarifugl/A-B) og hvorfor3) Beregninger å spore (forretningsmessig + teknisk + ventetid)4) Tilbakeføringsplan og hvordan testes5) Implementeringsterskler bør overstige (hvilken verdi)
Sjekk denne ML CI/CD-pipelinen:1) Er datavalidering i linjen?2) Kan distribusjonen fortsette uten å holde evalueringsterskelen (bør den ikke)?3) Er tilbakerulling automatisk?4) Spores data+kode+metrikker i modellregisteret?Pline-konfigurasjon: [config]
Hjelp meg med å avgjøre om online- eller batchpresentasjon passer for denne modellen. Hvor lenge vil resultatet bli brukt: [øyeblikkelig / minutt / time / dag]Forventet forespørselsvolum: [antall]Er det en forsinkelsesbegrensning: [ms]Hvilken vil du anbefale med tanke på kostnad og kompleksitet og hvorfor?
Skriv en tilbakerullingsprosedyre for denne modellen.- Hvilken metrikk/terskel utløser dårlig ytelse?- Hva er tilbakerullingstrinnene?- Hvor lang tid bør tilbakerullingen ta (mål)?- Hvordan tester jeg denne prosedyren før produksjon?
Presentasjonsmønstertabell
kriterium
Online (sanntid)
Batch
forsinkelse
Kritisk (ms)
ubetydelig
Bruk
Øyeblikkelig respons kreves
Periodisk poengsum
Kostnad
høy
lav
kompleksitet
høy
lav
eksempel
Live anbefaling, svindel
Månedlig risikoscore
Vanlige feil
- Distribuer uten en plan for henting. Feil modell treffer hele brukeren.
- Åpner direkte for 100 % trafikk. Begrens risiko med forskjøvet fordeling.
- Ikke etablere overvåking. Modellen produserer feil lydløst, uten feil.
- Redundant sanntidspresentasjon. Mens batching er tilstrekkelig, øker kostnadene og kompleksiteten.
- Ikke kobler modell-data-kode-versjoner. Du kan ikke reprodusere problemet.
- Automatisk utgivelse uten distribusjonsterskel. Den dårlige modellen sniker seg lydløst inn.
Oppsummert
Å flytte modellen til produksjon er en annen og ofte vanskeligere ingeniøroppgave enn å trene den. ML krever ekstra disiplin fordi det avhenger av kode-data-modell-trioen: pakking og versjonering, leveringsmønster (online/batch) som passer forretningsbehovet, gradvis og reversibel distribusjon, terskelkontrollert CI/CD og modellregistrering. Kunstig intelligens er et kraftig hjelpemiddel for å generere koden og konfigurasjonen til denne infrastrukturen; men distribusjonsterskler, clawback-policy og risikobeslutninger er dine. En distribusjon uten tilbakeføringsplan er ikke fullført.
Søknadsoppgave
Containeriser (Docker) en modell og merk den versjonen. Bestem om du vil tilby online eller batch basert på forretningsbehovene dine, og skriv begrunnelsen din. Dokumenter en trinnvis distribusjonsplan (skygge eller kanarifugl) og en testet tilbakeføringsprosedyre. Sørg for å registrere dataversjonen, kodebekreftelsen og evalueringsskårene i modellregisteret.
sjekkliste
- [ ] Modellen er pakket og versjonert (beholder + etikett).
- [ ] Presentasjonsmønster (online/batch) ble valgt i henhold til virksomhetens behov.
- [ ] Etappevis distribusjonsstrategi (skygge/kanarifugl) implementert.
- [ ] Tilbakeføringsprosedyre skrevet og testet.
- [ ] CI/CD fremmer ikke distribusjon før evalueringsterskelen er nådd.
- [ ] Modellregisteret inneholder lenken data+kode+metrisk.