Vinster:
- Förmåga att känna igen de speciella utmaningarna med ML relaterade till kod-data-modelltrion och paketet och presentera modellen online eller i batch enligt affärsbehov.
- Möjlighet att implementera gradvisa och återställningsmönster (skugga, kanariefågel, A/B, återställning) och lägga till en testad återställningsplan för varje driftsättning
- Möjlighet att hålla data-kod-metrisk länk för modellen som satts i produktion spårbar med utvärderingströskelkontrollerad CI/CD och modellregister
Att få en modell att uppnå 95 % noggrannhet i den bärbara datorn är bara halva historien. Den andra halvan – ofta den svåra delen – är att få den modellen till riktiga användare på ett tillförlitligt, skalbart och underhållbart sätt. MLOps (Machine Learning Operations: disciplinen att sätta, driva och underhålla ML-modeller i produktion) kombinerar DevOps-praxis för programvaruteknik med de unika utmaningarna i ML. I den här enheten tar vi upp stegen för att flytta modellen till produktion och hur artificiell intelligens hjälper till i denna process.
Varför skiljer sig ML från vanlig programvara?
I vanlig mjukvara ligger beteendet i koden; Om koden inte ändras ändras inte beteendet. I ML beror beteendet på både kod, data och modell. Dessa tre dimensioner skapar de extra utmaningarna med MLOps:
- Datadrift: Data i produktionen flyttar sig bort från data under träning över tiden; modellen blir föråldrad.
- Du måste versionera tre saker: kod, data och modell – alla tre.
- Tyst fel: En modell kan misslyckas utan att krascha, utan att ge fel, helt enkelt genom att producera felaktiga förutsägelser. Att fånga detta kräver övervakning.
Det är därför det är stor skillnad på en "arbetsmodell" och en "produktionsfärdig modell".
Modellförpackning och presentation
Det första steget i att sätta modellen i produktion är att paketera den: modellfilen, nödvändiga bibliotek, förbearbetningskod och versionsinformation tillsammans som en reproducerbar helhet. Containerisering (t.ex. Docker: att lägga applikationen i en isolerad låda med alla dess beroenden) är standard här; Det eliminerar problemet "det fungerade på min maskin".
Två grundläggande mönster för att betjäna modellen:
- Online/realtid (online): Modellen sitter bakom ett API och returnerar en omedelbar förutsägelse för varje inkommande förfrågan. Låg latens är kritisk.
- Batch: Modellen bearbetar stora datamängder periodiskt (t.ex. genererar poäng för alla kunder på natten). Latens är irrelevant, effektivitet är viktigt.
Vilken som är rätt beror på företagets behov: omedelbar rekommendation online, månatlig riskpoäng i omgångar.
Tips: "Realtid" är en kostnad, inte standard. Batch är mycket billigare och enklare om resultatet kommer att användas inom några timmar. Behöver du verkligen ett omedelbart svar? Fråga det först.
Säkra distributionsstrategier
Att öppna en ny modell direkt för all trafik är riskabelt; Om det är fel påverkas alla. Säkra distributionsmönster:
- Shadow-distribution: Den nya modellen tar emot produktionstrafik, men dess förutsägelser visas inte för användaren, bara loggas. Den jämförs med den gamla modellen för att se om den är säker i verklig data.
- Kanariefågel-utbyggnad: Den nya modellen rullas först ut till en liten andel av trafiken (t.ex. 5 %); Om det inte är några problem, ökas det gradvis.
- A/B-testning: Två modeller presenteras parallellt för den verkliga användaren och affärsmått (konvertering, klick) jämförs.
- Återställning: Möjlighet att snabbt återgå till den gamla versionen om den nya modellen visar sig vara dålig. Varje distribution bör ha en återställningsplan.
Varning: En distribution utan en återställningsplan är inte komplett. Att kunna återgå till den gamla versionen inom några minuter skyddar användaren när den nya modellen beter sig oväntat i produktionen. Testa detta före implementering.
Svagt förhållningssätt / Starkt förhållningssätt
Svag: "Modellen var bra i testning, vi gick live, vi öppnade den för alla."
Güçlü: "Vi containeriserade modellen, märkte den som en version. Först körde vi den i skuggläge med produktionstrafik i 3 dagar, och jämförde förutsägelserna med den gamla modellen - avvikelsen var acceptabel. Sedan öppnade vi den med 5% kanariefågel, övervakade genomströmningsstatistiken och latensen. När det inte fanns några problem, ökade vi gradvis tillbaka kommandot 0% till 1."
Skillnaden: det starka tillvägagångssättet är gradvis, mätt och reversibelt. Risken är begränsad vid varje steg.
CI/CD och automation
CI/CD (Continuous Integration / Continuous Deployment: pipeline för automatisk testning och frisläppande av kodändringar) i ML täcker inte bara koden utan även data- och modellstegen. En bra ML CI/CD-pipeline: kör tester när koden ändras, utför datavalidering, tränar om modellen (vid behov), kontrollerar utvärderingströsklar och avancerar bara implementeringen om tröskelvärdena håller. Principen om "utbildning är automatisk, driftsättning är tröskelbaserad" förhindrar att den dåliga modellen tyst läcker ut i produktionen.
AI är till stor hjälp när du ställer in dessa pipelines: skriva utkast till konfigurationsfil (YAML), testfall, distributionsskript. Men du bestämmer distributionströskelvärdena (vilket mätvärde som än överskrider det värde som publiceras) och återställningspolicy; dessa är affärsriskbeslut.
Reproducerbarhetsinfrastruktur
För att reproducera beteendet hos en modell i produktionen, modellregister: ett register som håller vilken modell som tränats med vilken data och kod, och vilka mätvärden den fick. För varje produktionsmodell bör följande vara spårbart: träningsdataversion, kodversion (git commit), hyperparametrar, utvärderingspoäng och implementeringsdatum. När ett problem uppstår bör du kunna svara på frågan "vilken modell producerade denna förutsägelse, med vilken data?" inom några minuter. Vi kommer att fördjupa detta i enhet 11.
tre minifodral
Fall 1 - Problem fångat av skuggfördelning. En rekommendationsmodell slog den gamla i testning. Att köra den med produktionstrafik i skuggläge visade sig ge mycket dåliga rekommendationer för ett visst segment av användare (nya användare) – testdatan var underrepresentativ för detta segment. Modellen fixades utan att någonsin visas för användaren. Om den öppnades direkt skulle den nya användarupplevelsen störas.
Fall 2 - Oåterkallelig fördelning. Ett team rullade ut en ny prismodell för all trafik, utan återställningsplaner. Modellen prissatte oväntat vissa produkter mycket billigt. Att återgå till den gamla versionen tog timmar eftersom processen inte var klar. Det var ett allvarligt inkomstbortfall. Efteråt lades obligatoriska återställningstest till varje distribution.
Fall 3 - Tyst datadrift. Ett bedrägerimönster dök upp i månader utan några fel. Men bedragarnas taktik förändrades (datadrift) och modellens återkallelse föll tyst. Ingen märkte det eftersom det inte fanns någon övervakning. När en prognosfördelningsövervakningspanel etablerats, blev avdriften synlig tidigt. Vi kommer att täcka övervakning i enhet 8.
Kopierbara mallar
Skriv ett utkast till implementeringsplan för den här modellen. Modell: [vad det gör], användning: [online eller batch?] Bör inkludera:1) Förpackning (behållare, versionering)2) Inkrementell implementeringsstrategi (skugga/kanariefågel/A-B) och varför3) Mätvärden att spåra (affärsmässigt + tekniskt + latens)4) Återställningsplan och hur man testar5) Implementeringströsklar bör överstiga (vilket värde) mått
Kontrollera denna ML CI/CD-pipeline:1) Finns datavalidering i raden?2) Kan driftsättningen fortsätta utan att hålla utvärderingströskeln (ska det inte)?3) Är återställning automatiskt?4) Spåras data+kod+metrics i modellregistret?Pline-konfiguration: [config]
Hjälp mig att bestämma om online- eller batchpresentation är lämplig för denna modell. Hur länge kommer resultatet att användas: [instant/minut/timme/dag]Förväntad förfrågningsvolym: [antal]Finns det en fördröjningsbegränsning: [ms]Vilken skulle du rekommendera när det gäller kostnad och komplexitet och varför?
Skriv en återställningsprocedur för denna modell.- Vilket mått/tröskel utlöser dålig prestanda?- Vilka är återställningsstegen?- Hur lång tid bör återställningen ta (mål)?- Hur testar jag denna procedur innan produktion?
Presentationsmönster tabell
kriterium
Online (realtid)
Batch
försening
Kritisk (ms)
obetydlig
Användning
Omedelbart svar krävs
Periodisk poäng
Kostnad
hög
låg
komplexitet
hög
låg
exempel
Liverekommendation, bluff
Månatlig riskpoäng
Vanliga misstag
- Dela ut utan en plan för hämtning. Fel modell drabbar hela användaren.
- Öppnar direkt för 100% trafik. Begränsa risken med förskjuten distribution.
- Inte etablera övervakning. Modellen producerar fel tyst, utan fel.
- Redundant presentation i realtid. Även om det räcker med batchning ökar kostnaden och komplexiteten.
- Länkar inte versioner av modell-data-kod. Du kan inte reproducera problemet.
- Automatisk release utan distributionströskel. Den dåliga modellen smyger tyst in.
Sammanfattningsvis
Att flytta modellen till produktion är en annan och ofta svårare ingenjörsuppgift än att träna den. ML kräver extra disciplin eftersom det beror på kod-data-modelltrion: paketering och versionering, leveransmönster (online/batch) som passar affärsbehovet, gradvis och reversibel implementering, tröskelkontrollerad CI/CD och modellregistrering. Artificiell intelligens är ett kraftfullt hjälpmedel för att generera koden och konfigurationen av denna infrastruktur; men distributionströsklar, clawback-policy och riskbeslut är dina. En distribution utan återställningsplan är inte komplett.
Applikationsuppgift
Containerisera (Docker) en modell och märk versionen. Bestäm om du ska erbjuda online eller batch baserat på dina affärsbehov och skriv din motivering. Dokumentera en plan för utbyggnad i etapper (skugga eller kanariefågel) och en testad återställningsprocedur. Se till att registrera dataversionen, kodbekräftelsen och utvärderingspoängen i modellregistret.
checklista
- [ ] Modellen är förpackad och versionerad (behållare + etikett).
- [ ] Presentationsmönster (online/batch) valdes efter affärsbehov.
- [ ] Etappvis utbyggnadsstrategi (skugga/kanariefågel) implementerad.
- [ ] Återställningsprocedur skriven och testad.
- [ ] CI/CD avancerar inte driftsättningen innan utvärderingströskeln uppnås.
- [ ] Modellregistret innehåller länken data+kod+metrisk.