Vinster:
- Förmåga att känna igen tysta orsaker till försämring av modellen (datadrift, konceptdrift, uppströmsfel) och upprätta trelagers (operativ, ingång, utdata) övervakning
- Möjlighet att utvärdera LLM-system i flera lager med regelkontroller, LLM-domare och mänsklig utvärdering, och kalibrera med LLM-domare mänskligt ankare
- Möjlighet att designa en eval uppsättning som innehåller kant- och säkerhetsfodral och förvandla varje fångat fel till ett permanent testfall
När en modell väl går i produktion är ditt arbete inte klart; Det verkliga ansvaret börjar bara. För modellen kan tyst gå sönder när ingen tittar. I denna enhet täcker vi två kompletterande discipliner: utvärdering (systematisk mätning av modellens kvalitet) och övervakning (kontinuerlig övervakning av modellen i produktion). Särskilt i LLM-system är eval svårare och kräver mer omsorg än klassisk ML.
Varför produktionsmodellen tyst går sönder
En bugg kraschar, loggen skrivs ut, larmet går. En ML-modell kan å andra sidan ha fel utan att orsaka fel. Tre huvudorsaker till nedbrytning:
- Dataavvikelse: Fördelningen av indata förändras över tiden (nya produkter, ändrat användarbeteende, säsongsvariationer). Modellen förblir densamma men världen förändras.
- Begreppsdrift: Ingångs-utgångsförhållandet ändras. Bedrägeritaktik och spammönster utvecklas; Det som var rätt igår kommer att vara fel idag.
- Uppströms korruption: En datakälla ändrar format, ett område blir fritt; Modellen dreglar tyst med korrupt input.
Spårning gör dessa tysta förvrängningar hörbara.
Vad du ska titta på: tre lager
Bra övervakning täcker tre lager:
- Operativa mätvärden: Latens, felfrekvens, begäranvolym, resursanvändning. "Står systemet?"
- Data/indatamått: Är inmatningsfördelningen liknande den vid träning? Har felvärdet ökat? Har nya kategorier kommit? "Ser modellen bekanta data?"
- Modell/utgångsstatistik: Förutsägelsefördelningslogg? Har självförtroendet sjunkit? Och om möjligt, vad är noggrannheten jämfört med grundsanningen? "Är modellen fortfarande korrekt?"
Det tredje lagret är det mest värdefulla men det svåraste; eftersom det verkliga resultatet oftast kommer med en försening (det blir klart efter månader om ett lån kommer att betalas tillbaka eller inte).
Tips: Om det faktiska resultatet är försenat, övervaka ingången och förutsägelsefördelningen först. Förskjutning av ingångsfördelningen är ett tidigt tecken på försämring av noggrannheten och kan larma utan att vänta på det faktiska resultatet.
Utvärdera LLM-system: den speciella utmaningen
I klassisk ML är "rätt svar" tydligt (klass 0 eller 1). LLM-utfallet är å andra sidan öppet: det kan finnas många korrekta svar på samma fråga, "riktighet" passar inte in i ett enda nummer. LLM eval närmar sig:
- Refererade mätvärden: Jämför utdata med det ideala svaret. Begränsad; eftersom det kan betrakta det korrekta svaret uttryckt annorlunda som "fel".
- Regelbaserade kontroller: Är utgången giltig JSON? Finns det några förbjudna ord? Innehåller den önskade fälten? Billigt, pålitligt, tight.
- LLM-domare (LLM-as-judge): Få inte en modell att fråga "är det här svaret bra enligt detta kriterium?" Den skalar, men själva domaren måste verifieras.
- Mänsklig recension: Guldstandard men dyrt och långsamt. Det används på provet.
I praktiken används dessa tillsammans: billiga regelkontroller på varje utgång, LLM-domare på ett stort urval, mänsklig utvärdering på ett litet men rigoröst urval.
Svagt förhållningssätt / Starkt förhållningssätt
Svag: "LLM-Jag frågade domaren, 92% av våra svar var bra. Systemet är bra."
Güçlü: "Vi märkte först 100 utskrifter som människa. Vi körde LLM-domaren på samma 100 utskrifter och mätte överensstämmelse mellan människa och domare — 85% överensstämmelse, acceptabelt. Vi dokumenterade var domaren systematiskt gick fel (en tendens att hitta långa svar orättvist bra) och fixade hans poäng för att domaren litade på det först då."
Skillnaden: det starka tillvägagångssättet verifierar domaren med ett mänskligt ankare, inte blint. En overifierad LLM-domare ger snyggt men falskt självförtroende.
Observera: LLM-domare är också en förebild; hallucinogen, partisk (gynnar långa/säkra svar), kan vara inkonsekventa. Kalibrera domarpoäng med mänskliga taggar innan du fattar produktionsbeslut.
Utvärderingsset: noggrant utformat
En bra eval-set representerar mångfalden av verklig användning och svåra fall. En eval fylld med bara enkla exempel kommer att lämna dig i falskt förtroende. Var noga med att lägga den i eval-klustret:
- Kantfodral: Tom ingång, mycket lång ingång, ovanligt format.
- Kända svåra fall: Exempel där modellen har gjort misstag tidigare (som ett regressionstest).
- Säkerhetsincidenter: Snabba injektionsförsök, skadliga förfrågningar, fällor för integritetskränkning.
Evalklustret växer med tiden: varje ny bugg du fångar i produktionen blir ett testfall för nästa utvärdering.
Larm och ingripande
Övervakningen förblir ofullständig utan larm. Det bör finnas ett tröskelvärde och en svarsplan för varje viktigt mätvärde: "Meddela ingenjören om inmatningsdriften överstiger X", "Återställ automatiskt om felfrekvensen överstiger Y". Håll larm meningsfulla – för många falska larm gör teamet okänsligt och får dem att missa det riktiga larmet.
tre minifodral
Fall 1 - Tidig varning. Den verkliga noggrannheten i en efterfrågeprognosmodell blev uppenbar först i slutet av veckan. Teamet övervakade distributionen av input och såg den plötsliga ökningen av en ny produktkategori på en tisdag - något som modellen aldrig hade sett. De uppdaterade modellen utan att vänta på noggrannhetsfallet. Ingångsövervakning sparade dagar.
Fall 2 - Overifierad domare. Ett team rapporterade "vår kvalitet är utmärkt" baserat på LLM-granskaren. När kundklagomålen ökade infördes mänsklig övervakning: domaren räknade säkra men felaktiga svar som "bra". När domaren väl kalibrerats med mänskliga taggar avslöjades den verkliga kvaliteten och var mycket lägre. Lektion: lita inte på domaren utan att verifiera det.
Fall 3 - Regressionstestning. En snabb ändring löste ett problem medan ett annat tyst bröts. Men laget höll förbi buggar i eval-hinken; När den nya ändringen testades på detta kluster, fångades det trasiga fallet omedelbart och ändringen fixades. Lektion: varje fixad bugg bör bli ett permanent testfall.
Kopierbara mallar
Ta fram en spårningsplan för denna produktionsmodell. Täck tre lager:1) Operationell (latens, felfrekvens, volym)2) Indata/data (distributionsskifte, saknat värde, ny kategori)3) Modell/output (förutsägelsefördelning, konfidens, noggrannhet om möjligt)Modell: [beskrivning]. Hur lång tid tar det för det faktiska resultatet att komma fram: [duration]Lägg till tröskelvärde och interventionsrekommendation för varje mätvärde.
Föreslå en utvärderingsstrategi för detta LLM-system.Uppgift: [beskrivning]Fastställ lager:- Vilka regelbaserade kontroller ska köras på varje utgång?- Vilka kriterier ska LLM-medlaren utvärdera och hur ska de valideras (mänskligt ankare)?- I vilket prov ska mänsklig utvärdering utföras?List edge och säkerhetsfall ska jag sätta.
Kontrollera den här LLM-domarens uppmaning:- Är utvärderingskriterierna tydliga eller subjektiva?- Är det benäget att påverka längden/förtroendet?- Hur kalibrerar jag domaren med mänskliga taggar?Referee prompt: [prompt]
Skriv en svarsbok för detta övervakningslarm. Alarm: [t.ex. ingångsdrifttröskel överskriden] Måste innehålla: initiala kontrollsteg, möjliga orsaker, återställningskriterier, vem som ska informeras.
Försämring orsaka tabell
förvrängning
symptom
Sätt till tidig upptäckt
datadrift
Ingångsfördelning ändras
Övervakning av ingångsfördelning
begreppsskifte
Rättfärdigheten faller tyst
Förutsägelse + faktisk jämförelse
uppströms fel
Fält blir lediga/formatändringar
Schemavalidering + takt som saknas
Modellinkonsekvens
Output distribution skiftar
Övervakning av produktionens distribution
Vanliga misstag
- Inte etablera övervakning. Modellen går sönder tyst, ingen ser den.
- Spåra endast driftsstatistik. Systemet är igång, men förutsägelser kan vara felaktiga.
- Använder LLM utan att verifiera domaren. Det ger falskt förtroende.
- Eval med enkla exempel. Det tyder inte på verklig svårighet.
- Inkluderar inte tidigare fel i eval. Samma fel kommer tillbaka igen.
- Höga larm. Teamet blir okänsligt och missar det riktiga larmet.
Sammanfattningsvis
Modellen kan vara felaktig utan att orsaka fel i produktionen; så eval och övervakning är lika viktigt som utveckling. Upprätta övervakning på tre lager (operativ, input, output); Använd ingångsdrift som en tidig varning om det faktiska resultatet är försenat. I LLM-system är eval öppen; Använd regelkontroller, LLM-domare och mänsklig utvärdering tillsammans - men se till att validera LLM-domaren med ett mänskligt ankare. Berika ditt Eval-kluster med edge- och säkerhetsfodral och förvandla varje upptäckt fel till ett permanent testfall.
Applikationsuppgift
Skriv en övervakningsplan i tre lager för en produktionsmodell (eller nära-produktion) och definiera tröskelvärde + larm för minst en ingångsfördelningsmetrik. Om du har ett LLM-system: tagga 30 utgångar med människor, kör en LLM-domare på samma utgångar och mät överensstämmelse mellan människor och domare; Notera domarens systematiska partiskhet. Lägg till minst 3 kanter och 2 säkerhetsfodral till ditt eval-kluster.
checklista
- [ ] Övervakning täcker alla tre skikten (operativ, input, output).
- [ ] Jag använder ingångsdrift som en tidig varning om det faktiska resultatet är försenat.
- [ ] Jag kalibrerade LLM-arbitratorn med mänskliga etiketter.
- [ ] Eval-klustret innehåller edge- och säkerhetsfodral.
- [ ] Jag förvandlade varje bugg jag fångade till ett permanent testfall.
- [ ] Varje viktig mätvärde har en tröskel- och svarsplan.