Kontinuerlig overvågning, observerbarhed og drift

Gevinster:

• Evne til at definere målinger, der overvåger brug, sikkerhed, kvalitet og ydeevnesignaler
• Evne til at detektere outputkvalitetsdrift med baseline og sampling
• Mulighed for at indstille alarm og feedback loop for uregelmæssigheder og jailbreak-bølger

At sætte et AI-system i produktion er begyndelsen, ikke slutningen. Selvom modellen forbliver den samme, ændrer verden sig: brugeradfærd, indgående data, angrebsteknikker og forretningskontekst ændrer sig konstant. Gårsdagens rigtige svar kan være forkert i dag. Så den sidste søjle af sikkerhed er kontinuerlig overvågning og observerbarhed - evnen til at se udefra, hvad der foregår inde i systemet. I denne enhed lærer vi, hvilke målinger der skal overvåges, hvordan man fanger outputkvalitetsdrift, og hvordan man advarer om uregelmæssigheder.

Hvorfor kontinuerlig overvågning?

I klassisk software er "virker det" et binært spørgsmål: enten svarer det, eller også gør det ikke. I AI, mens systemet ser ud til at "fungere", kan det lydløst forværres: svar bliver langsomt unøjagtige, omkostningerne eskalerer, jailbreak-forsøg stiger. Den eneste måde at fange disse på er konstant at måle de rigtige signaler.

Bemærk: Den farligste funktionsfejl er den lydløse, ikke den støjende. Systemet kaster ikke fejl, dets kvalitet falder bare. Hvis du ikke opretter overvågning, vil den første person, der bemærker, være din kunde eller revisor, ikke dig.

Fire signalfamilier at se

• Anvendelse og pris: Anmodningsvolumen, tokenforbrug, pris pr. bruger. Pludselig spring; Det kan være et tegn på misbrug, en sløj integration eller en utæt kontakt.
• Sikkerhedssignaler: Jailbreak/indsprøjtningsforsøg, køretøjsopkald afvist, autorisationsfejl. En stigning kan indikere en aktiv angrebskampagne.
• Kvalitet og drift: Fald i outputkvalitet over tid (drift). For eksempel verifikationsbeståelsesprocent, korrektionsrate i menneskelig godkendelse, brugertilfredshed.
• Ydelse: Latency, fejlrate, timeout. Det påvirker brugeroplevelsen og omkostningerne direkte.

Hvad er drift, og hvordan fanger man det?

Drift er, når kvaliteten af ​​modellens input eller output skifter ubemærket over tid. Der er to typer: datadrift (fordelingen af ​​indgående anmodninger ændres — nyt emne, nyt sprog) og kvalitetsdrift (output for det samme job bliver gradvist værre). Der kræves en baseline for at opfange: registrere det normale område af metrikker, når systemet er sundt; Lad afvigelsen blive en alarm.

Trin for trin: Opsætning af overvågning

1. Mål basislinjen. Registrer normalområdet for hvert signal, når systemet er sundt.
2. Definer tærskel og alarm. Hvilken afvigelse vil advare hvem og hvordan?
3. Prøveudtagning + menneskelig inspektion. Få et menneske til at gennemgå en prøve af output regelmæssigt (kvalitetsdrift er ofte kun synlig).
4. Installer et dashboard. Overvåg fire signalfamilier på én skærm.
5. Feedback loop. Knyt resultater fra overvågning til prompt/kontrol forbedring.

Fire kopierbare skabeloner

Kvalitetsprøvetagningsevalueringsprompt (driftsporing med LLM-as-judge):

Nedenfor er 20 tilfældige printables fra denne uge. Vurder hver som "god / acceptabel / dårlig" og skriv en kort begrundelse. Til sidst vil jeg sammenligne den dårlige kurs med sidste uges kurs; Hvis der er et mønster (gentagelse af samme type fejl), der skiller sig ud i denne uge, skal du markere det.<output>{{ eksempler }}</outputs>

Anomali oversigt prompt:

Undersøg følgende daglige metrics: antal anmodninger, tokens, omkostninger, værktøjsopkald afvist, jailbreak-forsøg, gennemsnitlig latenstid. Markér enhver metrik, der afviger mere end 30 % fra basislinjen som "ANOMALIT", og estimer den mulige årsag (angreb, fejl, misbrug).<metrics>{{ daily_data }}</metrics>

Regel for definition af alarmtærskel:

Definer alarmer for hvert signal:- Pris: hvis overstiger 2x dagligt gennemsnit -> høj prioritet alarm- Jailbreak-forsøg: hvis overstiger 10 i timen -> underret sikkerhedsteamet- Bekræftelsesbeståelsesrate: hvis falder til under 90 % -> kvalitetsgennemgang - Latency: hvis p95 overskrider målet med 2x -> præstationsgennemgang

Driftsforskningsprompt:

Beståelsesraten for verifikation er faldet fra 94 % til 78 % i de sidste 2 uger. Hjælp mig med at besvare disse spørgsmål: (1) Er der dukket et nyt emne/sprog/format op i de indkommende anmodninger? (2) Er fejl koncentreret i en bestemt kategori? (3) Falder timingen sammen med en prompt/model/værktøjsændring? Navngiv de data, der skal kontrolleres for hver.

Svag prompt / stærk prompt

dårlig tilgang

Stærk tilgang

"Hvis der er en fejl, vil vi se"

Baseline + tærskel + proaktiv alarm

Tjekker lige om systemet står.

Overvågning af fire familier af signaler (brug, sikkerhed, kvalitet, ydeevne)

Sampler slet ikke outputkvaliteten

Regelmæssig menneskelig prøvetagning + LLM-som-dommer

Ikke at indsamle og se på metrics

Dashboard + feedback loop

Tre mini etuier

Tilfælde 1 — Omkostningsalarm fangede den utætte nøgle. En virksomheds daglige token-omkostning blev tredoblet over natten. Tærskelalarmen advarede sikkerhedsteamet; undersøgelse viste, at en testnøgle var blevet lækket og brugt af en bot. Nøglen blev tilbagekaldt på 25 minutter; Hvis der ikke havde været alarm, ville regningen være blevet bemærket i slutningen af ​​måneden.

Tilfælde 2 — Lydløs kvalitetsdrift. En supportassistents verifikationsbeståelsesrate faldt stille og roligt fra 95 % til 80 % på tre uger. Ugentlig prøvetagning fangede dette; Årsagen var, at kunderne begyndte at spørge om en ny produktlinje, og modellens videnbase om den var ufuldstændig. Satsen genvandt, da videnbasen blev opdateret.

Case 3 - Jailbreak-bølgen var tidlig. Indsprøjtningsforsøg på en assistent steg fra 2 til 40 i timen på én dag. Sikkerhedsalarm udløst; Det blev set, at en "opskrift" på at knække systemet blev delt i et forum. Holdet opdaterede forsvarsprompten og hastighedsbegrænsede mistænkelige konti; Bølgen stilnede, inden den blev til en reel lækage.

Tip: Lad være med at nøjes med kun maskinmålinger. Kvalitetsdrift fanges ofte ved blot at lade et menneske læse prøveudgangene. En lille rutine med at gennemgå 15-20 tilfældige udskrifter om ugen vil fange de dyreste stille fejl tidligt.

Almindelige fejl

• Ikke at sætte det i produktion og opsætte overvågning ("det virker, okay").
• Ikke at kunne identificere anomalien uden at måle baseline.
• Savner kvalitetsdriften ved kun at se på "står den op".
• Ikke at prøve outputkvaliteten gennem menneskelige øjne overhovedet.
• Ikke at slå alarm og finde ud af problemet hos kunden/supervisor.
• Forbinder ikke overvågningsresultater til forbedring (ingen feedback-loop).

Sammenfattende

• AI-systemer kan stille og roligt forringes; Den farligste fejl er den, der ikke kaster fejl, men kun reducerer kvaliteten.
• Spor fire familier af signaler: forbrug/omkostninger, sikkerhed, kvalitet/drift og ydeevne.
• Drift (drift af input- eller outputkvalitet over tid) fanges kun sammenlignet med en basislinje.
• Regelmæssig menneskelig prøvetagning ud over maskinmetrik fanger kvalitetsdrift.
• Tilslut overvågning til alarm- og feedbacksløjfen; At måle og ikke kigge er ikke overvågning.

Ansøgningsopgave

Vælg mindst én metrik fra hver af de fire signalfamilier til dit eget AI-system, og skriv deres nuværende (eller estimerede) basislinjer ned. Definer en alarmtærskel for hver metrik. Tag derefter 15 af dine sidste semesters output og score dem med prøveudtagningsprompten ovenfor; Bemærk den "dårlige" rate. Lad dette være din første baseline, som du kan sammenligne drift med i fremtiden.

tjekliste

• [ ] Jeg definerede målinger fra fire signalfamilier (brug, sikkerhed, kvalitet, ydeevne).
• [ ] Jeg indstiller en basislinje og alarmtærskelværdi for hver metrik.
• [ ] Jeg prøver jævnligt outputkvaliteten gennem menneskelige øjne.
• [ ] Jeg overvåger signalerne på en enkelt skærm med et displaypanel.
• [ ] Alarmen går til sikkerhedsteamet for uregelmæssigheder og jailbreak-bølger.
• [ ] Jeg tilskriver overvågningsresultaterne prompten/kontrolforbedringen.