Egység 9 / 11

Folyamatos megfigyelés, megfigyelhetőség és sodródás

Nyereség:

  • A használat, a biztonság, a minőség és a teljesítmény jeleit figyelő mérőszámok meghatározásának képessége
  • Képes a kimeneti minőség eltolódásának észlelésére alapvonallal és mintavétellel
  • Riasztási és visszacsatolási hurok beállítása anomáliák és jailbreak hullámok esetén

Egy AI-rendszer gyártásba helyezése a kezdet, nem a vég. Még ha a modell változatlan marad is, a világ megváltozik: a felhasználói viselkedés, a bejövő adatok, a támadási technikák és az üzleti környezet folyamatosan változik. A tegnapi helyes válasz ma rossz lehet. A biztonság utolsó pillére tehát a folyamatos megfigyelés és megfigyelhetőség – az a képesség, hogy kívülről is láthatjuk, mi történik a rendszerben. Ebben az egységben megtudjuk, milyen mutatókat kell figyelni, hogyan rögzíthetjük a kimeneti minőség eltolódását, és hogyan figyelmeztethetünk az anomáliákra.

Miért a folyamatos monitorozás?

A klasszikus szoftverekben a "működik-e" bináris kérdés: vagy válaszol, vagy nem. A mesterséges intelligencia esetében, miközben úgy tűnik, hogy a rendszer „működik”, csendben romolhat: a válaszok lassan pontatlanokká válnak, a költségek emelkednek, a jailbreak kísérletek száma nő. Ezek rögzítésének egyetlen módja a megfelelő jelek folyamatos mérése.

Figyelem: A legveszélyesebb meghibásodás a csendes, nem a zajos. A rendszer nem dob hibát, csak romlik a minősége. Ha nem állítja be a felügyeletet, akkor az első személy, aki észreveszi, az Ön ügyfele vagy auditora lesz, nem Ön.

Négy jeladó család

  • Használat és költség: Kérelem mennyiség, token felhasználás, felhasználónkénti költség. Hirtelen ugrás; Ez lehet visszaélés, hurok integráció vagy szivárgó kapcsoló jele.
  • Biztonsági jelzések: Jailbreak/befecskendezési kísérlet, járműhívások elutasítva, engedélyezési hibák. A növekedés aktív támadási kampányt jelezhet.
  • Minőség és eltolódás: A kimeneti minőség időbeli csökkenése (drift). Például az átigazolási arány, az emberi jóváhagyás korrekciós aránya, a felhasználói elégedettség.
  • Teljesítmény: késleltetés, hibaarány, időtúllépés. Ez közvetlenül befolyásolja a felhasználói élményt és a költségeket.

Mi az a Drift és hogyan lehet elkapni?

A sodródás az, amikor a modell bemeneteinek vagy kimeneteinek minősége az idő múlásával észrevétlenül megváltozik. Két típusa van: adatsodródás (a bejövő kérések eloszlása ​​megváltozik – új téma, új nyelv) és minőségi sodródás (ugyanazon feladat kimenete fokozatosan romlik). Alapvonalra van szükség a következők rögzítéséhez: a mérőszámok normál tartományának rögzítése, amikor a rendszer egészséges; Hagyja, hogy az eltérés riasztás legyen.

Lépésről lépésre: A megfigyelés beállítása

  1. Mérje meg az alapvonalat. Rögzítse az egyes jelek normál tartományát, amikor a rendszer egészséges.
  2. Határozza meg a küszöböt és a riasztást. Melyik eltérés fog figyelmeztetni kit és hogyan?
  3. Mintavétel + emberi ellenőrzés. Egy ember rendszeresen nézzen át egy mintát a kimenetekből (a minőségi eltolódás gyakran csak látható).
  4. Telepítsen egy műszerfalat. Négy jelcsalád monitorozása egy képernyőn.
  5. Visszacsatolási hurok. Kösd össze a megfigyelést a gyors/ellenőrzési fejlesztéssel.

Négy másolható sablon

Minőségi mintavételi értékelési felszólítás (drift követés LLM-as-judge segítségével):

Az alábbiakban 20 véletlenszerű nyomtatható példányt láthatunk erről a hétről. Értékelje mindegyiket "jó / elfogadható / rossz"-ra, és írjon egy rövid indoklást. Végül összehasonlítom a rossz árfolyamot a múlt heti árfolyammal; Ha van olyan minta (azonos hiba megismétlődése), amely kiemelkedik ezen a héten, jelölje meg.<outputs>{{ examples }}</outputs>

Anomália összefoglaló prompt:

Vizsgálja meg a következő napi mutatókat: kérelmek száma, tokenek, költség, elutasított eszközhívás, jailbreak kísérletek, átlagos késleltetés. Minden olyan mutatót, amely több mint 30%-kal eltér az alapvonaltól, jelölje meg "ANOMALIT"-ként, és becsülje meg a lehetséges okot (támadás, hiba, visszaélés).<metrics>{{ daily_data }}</metrics>

A riasztási küszöb meghatározására vonatkozó szabály:

Határozzon meg riasztásokat minden jelhez: - Költség: ha meghaladja a napi átlag 2-szeresét -> magas prioritású riasztás - Jailbreak kísérletek: ha meghaladja a 10-et óránként -> értesítse a biztonsági csapatot - Ellenőrzési arány: ha 90% alá esik -> minőségi felülvizsgálat - Késés: ha a p95 meghaladja a célt 2x -> teljesítmény ellenőrzés

Drift-kutatási felszólítás:

Az elmúlt 2 hétben az átigazolási arány 94%-ról 78%-ra csökkent. Segítsen megválaszolni a következő kérdéseket: (1) Új téma/nyelv/formátum jelent meg a beérkező kérelmek között? (2) A hibák egy bizonyos kategóriába koncentrálódnak? (3) Egybeesik-e az időzítés egy felszólítással/modell-/eszközcserével? Nevezze meg mindegyiknél az ellenőrizendő adatokat.

Gyenge felszólítás / Erős felszólítás

rossz megközelítés

Erős megközelítés

"Ha hiba van, meglátjuk"

Alapvonal + küszöb + proaktív riasztás

Csak ellenőrizni kell, hogy a rendszer áll-e.

Négy jelcsalád figyelése (használat, biztonság, minőség, teljesítmény)

Egyáltalán nem mintavételezés a kimeneti minőségben

Rendszeres emberi mintavétel + LLM-mint bíró

Nem gyűjti és nem nézi a mutatókat

Irányítópult + visszacsatoló hurok

Három mini tok

1. eset – A költségriasztás elkapta a szivárgó kulcsot. Egy cég napi tokenköltsége egyik napról a másikra megháromszorozódott. A küszöbérték riasztás riasztotta a biztonsági csoportot; A vizsgálat kimutatta, hogy egy tesztkulcs kiszivárgott, és egy bot használta. A kulcsot 25 perc alatt visszavonták; Ha nem lett volna riasztás, a számlát a hónap végén észrevették volna.

2. eset – Csendes minőségi sodródás. Egy ügyfélszolgálati asszisztens sikeres ellenőrzési aránya csendesen 95%-ról 80%-ra csökkent három hét alatt. A heti mintavétel ezt rögzítette; Ennek oka az volt, hogy a vásárlók elkezdtek érdeklődni egy új termékcsaládról, és a modell tudásbázisa hiányos volt. Az arány a tudásbázis frissítésekor helyreállt.

3. eset – A jailbreak hullám korai volt. Az asszisztenseken végzett injekciók száma óránként 2-ről 40-re nőtt egy nap alatt. Biztonsági riasztó aktiválódott; Látható volt, hogy egy fórumon megosztottak egy "receptet" a rendszer feltörésére. A csapat frissítette a védelmi felszólítást és korlátozta a gyanús fiókokat; A hullám elhalt, mielőtt valódi szivárgássá változott volna.

Tipp: Ne elégedjen meg csak a gépi mérőszámokkal. A minőségi eltolódást gyakran elkapják, ha csak egy ember olvassa el a minta kimeneteit. A heti 15-20 véletlenszerű nyomat áttekintésének kis rutinja korán felismeri a legdrágább csendes hibákat.

Gyakori hibák

  • Nem állítják be a gyártásba és nem állítják be a felügyeletet ("működik, oké").
  • Nem lehet azonosítani az anomáliát az alapvonal mérése nélkül.
  • Hiányzik a minőségi sodródás azáltal, hogy csak azt nézzük, hogy "áll-e fel".
  • Egyáltalán nem emberi szemmel mintavételezve a kimeneti minőséget.
  • Nem riasztás és a probléma kiderítése az ügyféltől/felügyelőtől.
  • Nem kapcsolja össze a megfigyelési eredményeket a fejlesztéssel (nincs visszacsatolási hurok).

Összefoglalva

  • Az AI-rendszerek csendesen romlanak; A legveszélyesebb meghibásodás az, amely nem okoz hibákat, csak rontja a minőséget.
  • Négy jelcsaládot követhet nyomon: használat/költség, biztonság, minőség/eltolódás és teljesítmény.
  • Az eltolódást (a bemeneti vagy kimeneti minőség időbeli eltolódását) a rendszer csak az alapvonalhoz viszonyítva rögzíti.
  • A gépi mérőszámok mellett a rendszeres emberi mintavétel rögzíti a minőségi változást.
  • Csatlakoztassa a felügyeletet a riasztó- és visszacsatoló hurokhoz; Mérni és nem nézni nem figyelni.

Pályázati feladat

Válasszon ki legalább egy mérőszámot a négy jelcsalád közül a saját AI-rendszeréhez, és írja le a jelenlegi (vagy becsült) alapvonalukat. Határozzon meg egy riasztási küszöböt minden metrikához. Ezután vegyen 15-öt az elmúlt félév eredményeiből, és pontozza azokat a fenti mintavételi utasítással; Vegye figyelembe a „rossz” arányt. Legyen ez az első alapállapota, amellyel a jövőben összehasonlíthatja a sodródást.

ellenőrző lista

  • [ ] Négy jelcsaládból határoztam meg metrikákat (használat, biztonság, minőség, teljesítmény).
  • [ ] Minden mérőszámhoz beállítok egy alapvonalat és riasztási küszöböt.
  • [ ] Rendszeresen mintát veszek a kimeneti minőségről emberi szemmel.
  • [ ] A jeleket egyetlen képernyőn, kijelzőpanellel figyelem.
  • [ ] A riasztás a biztonsági csapathoz érkezik anomáliák és jailbreak hullámok miatt.
  • [ ] A monitorozási eredményeket a prompt/kontrolljavításnak tulajdonítom.