Gevinster:
- Evne til at genkende tavse årsager til nedbrydning af modellen (datadrift, konceptdrift, opstrømsfejl) og etablere tre-lags (operationel, input, output) overvågning
- Evne til at evaluere LLM-systemer i flere lag med regelkontrol, LLM-dommer og menneskelig evaluering og kalibrere med LLM-dommer menneskelig anker
- Evne til at designe et eval-sæt, der indeholder kant- og sikkerhedstilfælde og omdanne hver fanget fejl til en permanent testcase
Når først en model går i produktion, er dit arbejde ikke færdigt; Det virkelige ansvar begynder bare. For modellen kan lydløst gå i stykker, når ingen kigger. I denne enhed dækker vi to komplementære discipliner: evaluering (systematisk måling af modellens kvalitet) og overvågning (konstant overvågning af modellen i produktionen). Især i LLM-systemer er eval vanskeligere og kræver mere pleje end klassisk ML.
Hvorfor produktionsmodellen stille og roligt går i stykker
En fejl går ned, loggen udskrives, alarmen går. En ML-model kan derimod være forkert uden at forårsage fejl. Tre hovedårsager til nedbrydning:
- Datadrift: Fordelingen af inputdata ændrer sig over tid (nye produkter, ændret brugeradfærd, sæsonbestemt). Modellen forbliver den samme, men verden ændrer sig.
- Begrebsdrift: Input-output forholdet ændres. Svindeltaktik og spammønstre udvikler sig; Det, der var rigtigt i går, vil være forkert i dag.
- Upstream korruption: En datakilde ændrer format, et område bliver frit; Modellen savler lydløst med korrupte input.
Sporing gør disse tavse forvrængninger hørbare.
Hvad skal man se: tre lag
God overvågning dækker tre lag:
- Operationelle målinger: Latency, fejlrate, anmodningsvolumen, ressourceforbrug. "Står systemet?"
- Data/input-metrics: Er inputfordelingen den samme som i træning? Er den manglende værdi steget? Er der kommet nye kategorier? "Ser modellen velkendte data?"
- Model/output-metrics: Forudsigelsesfordelingslog? Er tillidsscore faldet? Og hvis det er muligt, hvad er nøjagtigheden i forhold til grundsandheden? "Er modellen stadig nøjagtig?"
Det tredje lag er det mest værdifulde, men det sværeste; fordi det reelle resultat som regel kommer med en forsinkelse (det står klart efter måneder om et lån bliver tilbagebetalt eller ej).
Tip: Hvis det faktiske resultat er forsinket, skal du først overvåge input- og forudsigelsesfordelingen. Skift af inputfordelingen er et tidligt tegn på forringelse af nøjagtigheden og kan udløse en alarm uden at vente på det faktiske resultat.
Evaluering af LLM-systemer: den særlige udfordring
I klassisk ML er det "rigtige svar" klart (klasse 0 eller 1). LLM-resultatet er derimod åbent: der kan være mange rigtige svar på det samme spørgsmål, "korrekthed" passer ikke ind i et enkelt tal. LLM eval nærmer sig:
- Refererede målinger: Sammenligning af output med det ideelle svar. Begrænset; fordi det kan betragte det korrekte svar udtrykt anderledes som "forkert".
- Regelbaserede kontroller: Er outputtet gyldigt JSON? Er der nogle forbudte ord? Indeholder den de ønskede felter? Billig, pålidelig, stram.
- LLM-dommer (LLM-as-judge): Lad ikke en model spørge "er dette svar godt i henhold til dette kriterium?" Den skalerer, men selve dommeren skal verificeres.
- Menneskelig anmeldelse: Guldstandard, men dyr og langsom. Det bruges på prøven.
I praksis bruges disse sammen: billige regeltjek på hvert output, LLM-dommer på en stor prøve, menneskelig evaluering på en lille, men streng prøve.
Svag tilgang / Stærk tilgang
Svag: "LLM-Jeg spurgte dommeren, 92% af vores svar var gode. Systemet er fantastisk."
Güçlü: "Vi har først menneskemærket 100 udskrifter. Vi kørte LLM-dommeren på de samme 100 udskrifter og målte menneske-dommer-enigheden - 85% enighed, acceptabelt. Vi dokumenterede, hvor dommeren systematisk gik galt (en tendens til at finde lange svar uretfærdigt gode) og fikserede hans bedømmelse af dommeren, og først derefter fik vi tillid til dommeren."
Forskellen: den stærke tilgang verificerer dommeren med et menneskeligt anker, ikke blindt. En ubekræftet LLM-dommer giver flot, men falsk selvtillid.
Bemærk: LLM-dommeren er også en model; hallucinogen, forudindtaget (begunstiger lange/sikre svar), kan være inkonsekvente. Kalibrer dommerscores med menneskelige tags, før du træffer produktionsbeslutninger.
Evalueringssæt: omhyggeligt designet
Et godt eval-sæt repræsenterer mangfoldigheden af reel brug og vanskelige sager. En eval fyldt med bare nemme eksempler vil efterlade dig i falsk tillid. Sørg for at lægge den i eval-klyngen:
- Kantsager: Tom input, meget lang input, usædvanligt format.
- Kendte hårde cases: Eksempler hvor modellen har lavet fejl tidligere (som en regressionstest).
- Sikkerhedshændelser: Hurtige injektionsforsøg, ondsindede anmodninger, fælder for krænkelse af privatlivets fred.
Eval-klyngen vokser over tid: Hver ny fejl, du fanger i produktionen, bliver en testcase for den næste evaluering.
Alarm og indgreb
Overvågning forbliver ufuldstændig uden en alarm. Der bør være en tærskel og en responsplan for hver vigtig metrik: "Giv ingeniøren besked, hvis inputdriften overstiger X", "Automatisk tilbagerulning, hvis fejlraten overstiger Y". Hold alarmer meningsfulde - for mange falske alarmer desensibiliserer holdet og får dem til at gå glip af den rigtige alarm.
tre minisager
Case 1 - Tidlig varsling. Den sande nøjagtighed af en efterspørgselsprognosemodel blev først synlig i slutningen af ugen. Holdet overvågede inputdistribution og så den pludselige stigning i en ny produktkategori på en tirsdag - noget modellen aldrig havde set. De opdaterede modellen uden at vente på nøjagtighedsfaldet. Inputovervågning sparede dage.
Case 2 - Ubekræftet dommer. Et hold rapporterede "vores kvalitet er fremragende" baseret på LLM-reviewer. Da kundernes klager steg, blev der indført menneskelig overvågning: dommeren regnede selvsikre, men forkerte svar som "gode". Da først dommeren blev kalibreret med menneskelige mærker, blev den sande kvalitet afsløret og var meget lavere. Lektion: stol ikke på dommeren uden at have bekræftet det.
Case 3 - Regressionstest. En hurtig ændring løste et problem, mens et andet lydløst brød. Men holdet holdt forbi bugs i eval-spanden; Da den nye ændring blev testet på denne klynge, blev den ødelagte sag straks fanget, og ændringen blev rettet. Lektion: hver rettet fejl bør blive en permanent testsag.
Kopierbare skabeloner
Lav en sporingsplan for denne produktionsmodel. Dæk tre lag:1) Operationel (latens, fejlrate, volumen)2) Input/data (distributionsforskydning, manglende værdi, ny kategori)3) Model/output (forudsigelsesfordeling, konfidens, nøjagtighed hvis muligt)Model: [beskrivelse]. Hvor lang tid tager det for det faktiske resultat at nå frem: [varighed]Tilføj tærskelværdi og interventionsanbefaling for hver metrik.
Foreslå en evalueringsstrategi for dette LLM-system.Opgave: [beskrivelse]Bestem lag:- Hvilke regelbaserede kontroller skal køre på hvert output?- Hvilke kriterier skal LLM-voldgiftsdommeren evaluere, og hvordan skal de valideres (menneskeligt anker)?- I hvilken prøve skal menneskelig evaluering udføres?List kant og sikkerhedstilfælde skal jeg sætte i.
Tjek denne LLM-dommerprompt:- Er evalueringskriterierne klare eller subjektive?- Er den tilbøjelig til længde-/tillidsbias?- Hvordan kalibrerer jeg dommeren med menneskelige tags?Dommerprompt: [prompt]
Skriv en svar-runbog for denne overvågningsalarm.Alarm: [f.eks. input-drift-tærskel overskredet] Skal indeholde: indledende kontroltrin, mulige årsager, rollback-kriterier, hvem der skal informeres.
Forringelse årsag tabel
forvrængning
symptom
Vejen til tidlig opdagelse
datadrift
Ændringer i inputfordelingen
Overvågning af input distribution
konceptskifte
Retfærdighed falder stille
Forudsigelse + faktisk sammenligning
opstrøms fejl
Felter bliver ledige/formatændringer
Skemavalidering + manglende rate
Model inkonsistens
Outputfordeling skifter
Overvågning af outputfordeling
Almindelige fejl
- Der etableres ikke overvågning. Modellen bryder lydløst sammen, ingen ser den.
- Spor kun operationelle metrics. Systemet er oppe, men forudsigelser kan være forkerte.
- Brug af LLM uden at verificere dommeren. Det giver falsk selvtillid.
- Eval med nemme eksempler. Det indikerer ikke reel vanskelighed.
- Ikke inklusive tidligere fejl i eval. Den samme fejl vender tilbage igen.
- Høje alarmer. Holdet bliver desensibiliseret og savner den rigtige alarm.
Sammenfattende
Modellen kan være unøjagtig uden at forårsage fejl i produktionen; så eval og overvågning er lige så vigtigt som udvikling. Etablere overvågning på tre lag (operationel, input, output); Brug inputdrift som en tidlig advarsel, hvis det faktiske resultat er forsinket. I LLM-systemer er eval åben; Brug regeltjek, LLM-dommer og menneskelig evaluering sammen - men sørg for at validere LLM-dommeren med et menneskeligt anker. Berig din Eval-klynge med edge- og sikkerhedsetuier, og forvandl hver fanget fejl til en permanent testcase.
Ansøgningsopgave
Skriv en tre-lags overvågningsplan for en produktionsmodel (eller nær-produktion) og definer tærskelværdi + alarm for mindst én input-distributionsmetrik. Hvis du har et LLM-system: tag 30 outputs med mennesker, kør en LLM-dommer på de samme output, og mål menneske-dommer-enigheden; Bemærk dommerens systematiske bias. Tilføj mindst 3 kanter og 2 sikkerhedsetuier til din eval-klynge.
tjekliste
- [ ] Overvågning dækker alle tre lag (operationel, input, output).
- [ ] Jeg bruger inputdrift som en tidlig advarsel, hvis det faktiske resultat er forsinket.
- [ ] Jeg kalibrerede LLM-arbitratoren med menneskelige etiketter.
- [ ] Eval-klyngen indeholder edge- og sikkerhedsetuier.
- [ ] Jeg forvandlede hver fejl, jeg fangede, til en permanent testcase.
- [ ] Hver vigtig metrik har en tærskelværdi og en responsplan.