Njësia 9 / 11

Monitorimi i vazhdueshëm, Vëzhgueshmëria dhe Drift

Fitimet:

  • Aftësia për të përcaktuar metrikat që monitorojnë përdorimin, sigurinë, cilësinë dhe sinjalet e performancës
  • Aftësia për të zbuluar ndryshimin e cilësisë së prodhimit me bazën dhe marrjen e mostrave
  • Aftësia për të vendosur alarmin dhe ciklin e reagimit për anomali dhe valë jailbreak

Vënia në prodhim e një sistemi AI është fillimi, jo fundi. Edhe nëse modeli mbetet i njëjtë, bota ndryshon: sjellja e përdoruesit, të dhënat hyrëse, teknikat e sulmit dhe konteksti i biznesit po ndryshojnë vazhdimisht. Përgjigja e saktë e djeshme mund të jetë e gabuar sot. Pra, shtylla e fundit e sigurisë është monitorimi dhe vëzhgimi i vazhdueshëm - aftësia për të parë nga jashtë se çfarë po ndodh brenda sistemit. Në këtë njësi, ne do të mësojmë se cilat metrika duhet të monitorojmë, si të kapim ndryshimin e cilësisë së prodhimit dhe si të sinjalizojmë për anomali.

Pse monitorim i vazhdueshëm?

Në softuerin klasik, "a funksionon" është një pyetje binare: ose përgjigjet ose jo. Në AI, ndërsa sistemi duket se "funksionon", ai mund të përkeqësohet në heshtje: përgjigjet ngadalë bëhen të pasakta, kostot rriten, përpjekjet për jailbreak rriten. Mënyra e vetme për t'i kapur këto është matja e vazhdueshme e sinjaleve të duhura.

Kujdes: Mosfunksionimi më i rrezikshëm është ai i heshtur, jo ai i zhurmshëm. Sistemi nuk hedh gabime, cilësia e tij thjesht zvogëlohet. Nëse nuk konfiguroni monitorimin, personi i parë që do të vini re do të jetë klienti ose auditori juaj, jo ju.

Katër familje sinjalizuese për t'u parë

  • Përdorimi dhe kostoja: Vëllimi i kërkesës, konsumi i tokenit, kostoja për përdorues. Kërcim i papritur; Mund të jetë një shenjë abuzimi, një integrim i paqartë ose një ndërprerës që rrjedh.
  • Sinjalet e sigurisë: Përpjekjet për jailbreak/injeksion, thirrjet e automjeteve të refuzuara, gabimet e autorizimit. Një rritje mund të tregojë një fushatë sulmi aktive.
  • Cilësia dhe zhvendosja: Ulja e cilësisë së prodhimit me kalimin e kohës (drift). Për shembull, shkalla e kalimit të verifikimit, shkalla e korrigjimit në miratimin njerëzor, kënaqësia e përdoruesit.
  • Performanca: Vonesa, shkalla e gabimit, afati kohor. Ajo ndikon drejtpërdrejt në përvojën dhe koston e përdoruesit.

Çfarë është Drift dhe si ta kapni atë?

Drift është kur cilësia e hyrjeve ose daljeve të modelit ndryshon pa u vënë re me kalimin e kohës. Ka dy lloje: zhvendosja e të dhënave (shpërndarja e kërkesave hyrëse ndryshon - temë e re, gjuhë e re) dhe zhvendosje e cilësisë (dalja për të njëjtën punë gradualisht përkeqësohet). Kërkohet një bazë bazë për të kapur: regjistroni gamën normale të metrikës kur sistemi është i shëndetshëm; Lëreni devijimin të bëhet alarm.

Hap pas hapi: Vendosja e monitorimit

  1. Matni bazën. Regjistroni diapazonin normal të çdo sinjali kur sistemi është i shëndetshëm.
  2. Përcaktoni pragun dhe alarmin. Cili devijim do të paralajmërojë kë dhe si?
  3. Marrja e mostrave + inspektimi njerëzor. Rishikoni rregullisht një mostër të rezultateve nga një person (zhvendosja e cilësisë shpesh është e dukshme vetëm).
  4. Instaloni një pult. Monitoroni katër familje sinjalesh në një ekran.
  5. Cikli i reagimit. Lidhni gjetjet nga monitorimi me përmirësimin e shpejtë/kontrollit.

Katër modele të kopjueshme

Kërkesa për vlerësimin e mostrës së cilësisë (ndjekja e lëvizjes me LLM-as-judge):

Më poshtë janë 20 printime të rastësishme nga kjo javë. Vlerësojeni secilën si "mirë / e pranueshme / e keqe" dhe shkruani një justifikim të shkurtër. Së fundi do të krahasoj normën e keqe me normën e javës së kaluar; Nëse ka një model (përsëritje të të njëjtit lloj gabimi) që bie në sy këtë javë, shënojeni atë.<outputs>{{ shembuj }}</outputs>

Kërkesa përmbledhëse e anomalive:

Ekzaminoni matjet e mëposhtme ditore: numrin e kërkesave, argumentet, koston, thirrjen e mjetit të refuzuar, përpjekjet për jailbreak, vonesa mesatare. Shënoni çdo metrikë që devijon më shumë se 30% nga baza si "ANOMALIT" dhe vlerësoni shkakun e mundshëm (sulm, defekt, abuzim).<metrics>{{ daily_data }}</metrics>

Rregulli i përcaktimit të pragut të alarmit:

Përcaktoni alarmet për çdo sinjal: - Kostoja: nëse tejkalon mesataren ditore 2x -> alarm me prioritet të lartë - Përpjekje për jailbreak: nëse kalon 10 në orë -> njoftoni ekipin e sigurisë - Shkalla e kalimit të verifikimit: nëse bie nën 90% -> rishikimi i cilësisë - Latenca: nëse p95 tejkalon objektivin me 2x -> rishikim i performancës

Drift kërkesa për kërkime:

Shkalla e kalimit të verifikimit ka rënë nga 94% në 78% në 2 javët e fundit. Më ndihmo t'u përgjigjem këtyre pyetjeve: (1) A është shfaqur një temë/gjuhë/format i ri në kërkesat hyrëse? (2) A janë gabimet të përqendruara në një kategori të caktuar? (3) A përkon koha me një ndryshim të shpejtë/model/vegla? Emërtoni të dhënat që do të kontrollohen për secilën.

Prompt i dobët / Prompt i fortë

qasje e dobët

Qasje e fortë

"Nëse ka një gabim, ne do të shohim"

Vija bazë + pragu + alarmi proaktiv

Thjesht kontrolloni për të parë nëse sistemi është në këmbë.

Monitorimi i katër familjeve të sinjaleve (përdorimi, siguria, cilësia, performanca)

Nuk ka marrë fare cilësinë e prodhimit

Kampionimi i rregullt njerëzor + LLM-si-gjyqtar

Jo duke mbledhur dhe shikuar metrikat

Paneli + cikli i komenteve

Tre Mini Rastet

Rasti 1 - Alarmi i kostos kapi çelësin që rrjedh. Kostoja ditore token e një kompanie u trefishua brenda natës. Alarmi i pragut sinjalizoi ekipin e sigurisë; hetimi tregoi se një çelës testimi kishte rrjedhur dhe përdorur nga një robot. Çelësi u revokua në 25 minuta; Nëse nuk do të kishte alarm, fatura do të vihej re në fund të muajit.

Rasti 2 - Zhvendosja e heshtur e cilësisë. Norma e verifikimit të një asistenti mbështetës ra në heshtje nga 95% në 80% në tre javë. Kampionimi javor e kapi këtë; Arsyeja ishte se klientët filluan të pyesnin për një linjë të re produkti dhe baza e njohurive të modelit mbi të ishte e paplotë. Norma u rikuperua kur u përditësua baza e njohurive.

Rasti 3 - Vala e jailbreak-it ishte e hershme. Përpjekjet për injeksione të bëra tek një asistent u rritën nga 2 në 40 në orë në një ditë. Alarmi i sigurisë u aktivizua; U pa se në një forum u shpërnda një "recetë" për plasaritjen e sistemit. Ekipi përditësoi kërkesat e mbrojtjes dhe llogaritë të dyshimta të kufizuara; Vala u shua para se të shndërrohej në një rrjedhje të vërtetë.

Këshillë: Mos u mjaftoni vetëm me matjet e makinerive. Zhvendosja e cilësisë shpesh kapet duke kërkuar vetëm një njeri të lexojë rezultatet e mostrës. Një rutinë e vogël e rishikimit të 15-20 printimeve të rastësishme në javë do të kapë herët dështimet më të shtrenjta të heshtura.

Gabimet e zakonshme

  • Mos vendosja e tij në prodhim dhe vendosja e monitorimit ("po funksionon, në rregull").
  • Pamundësia për të identifikuar anomalinë pa matur bazën.
  • Mungon ndryshimi i cilësisë duke parë vetëm "a qëndron në këmbë".
  • Duke mos marrë fare cilësinë e prodhimit përmes syve të njeriut.
  • Mos ngritja e alarmit dhe zbulimi i problemit nga klienti/mbikëqyrësi.
  • Moslidhja e gjetjeve të monitorimit me përmirësimin (pa ciklin e reagimit).

Në përmbledhje

  • Sistemet e AI mund të përkeqësohen në heshtje; Mosfunksionimi më i rrezikshëm është ai që nuk hedh gabime, por vetëm ul cilësinë.
  • Gjurmo katër familje sinjalesh: përdorim/kosto, siguri, cilësi/drift dhe performancë.
  • Drift (zhvendosja e cilësisë së hyrjes ose daljes me kalimin e kohës) kapet vetëm në krahasim me një bazë.
  • Marrja e rregullt e mostrave nga njerëzit, përveç metrikës së makinës, kap ndryshimin e cilësisë.
  • Lidhni monitorimin me alarmin dhe ciklin e reagimit; Të matësh dhe të mos shikosh nuk është monitorim.

Detyra e aplikimit

Zgjidhni të paktën një metrikë nga secila prej katër familjeve të sinjaleve për sistemin tuaj të AI dhe shkruani linjat bazë të tyre aktuale (ose të vlerësuara). Përcaktoni një prag alarmi për çdo metrikë. Pastaj merrni 15 nga rezultatet e semestrit tuaj të fundit dhe shënojini ato me kërkesën e kampionimit të mësipërm; Vini re shkallën "e keqe". Lëreni që kjo të jetë baza juaj e parë me të cilën do të krahasoni lëvizjen në të ardhmen.

listë kontrolli

  • [ ] Përcaktova metrikë nga katër familje sinjalesh (përdorimi, siguria, cilësia, performanca).
  • [ ] Kam vendosur një bazë dhe prag alarmi për çdo metrikë.
  • [ ] Provoj rregullisht cilësinë e prodhimit përmes syve të njeriut.
  • [ ] Unë monitoroj sinjalet në një ekran të vetëm me një panel ekrani.
  • [ ] Alarmi shkon në ekipin e sigurisë për anomali dhe valë jailbreak.
  • [ ] Unë ia atribuoj gjetjet e monitorimit përmirësimit të shpejtë/kontrollit.