Van egy pillanat, ami minden AI-automatizációt üzemeltető embernek eljön előbb-utóbb: felépítesz egy szép, önműködő ellenőrző folyamatot, ami minden héten megmondja, mi ment rosszul a rendszeredben — és aztán rájössz, hogy maga a riport hazudik. Nem az AI hibázott a mögöttes folyamatokban. A mérőkód hibázott, amikor megpróbálta megítélni, mi számít hibának.
Ez pontosan megtörtént nálam. Egy adott időszakban a heti önellenőrző folyamat 67 anomáliát jelzett. Amikor sorra végignéztem mindet, 64 bizonyult hamis riasztásnak — 96%. Csak 3 volt tényleges, valós probléma. Ha ezt a számot elfogadtam volna kritika nélkül, két hét alatt kikapcsoltam volna a riasztásokat, mert „úgyis mindig hamisak” — és pont akkor vesztem volna el a képességet, hogy a valódi 3-at időben elkapjam.
A három konkrét ok, ami a hamis riasztásokat okozta
Amikor visszakövettem, miért volt ilyen magas a hamis riasztási arány, három különálló hiba rajzolódott ki a mérőkódban — mindhárom ugyanabból a mintából fakadt: a mérőkód túl sokat bízott a felszínre, és túl keveset a determinisztikus tényekre.
1. LLM-próza-parse-olás. A mérő megpróbálta egy szöveges, szabad AI-választ regex-szel vagy kulcsszó-kereséssel értelmezni — például azt kereste, hogy a válaszban szerepel-e a „hiba” vagy „sikertelen” szó. A probléma: egy AI-modell ugyanazt a tényt tucatféleképpen tudja megfogalmazni, és apró, jelentés szempontjából semleges fogalmazásbeli eltérések (pl. „nem sikerült teljesen” vs. „részben sikertelen”) más-más találatot adtak, holott a mögöttes tény ugyanaz volt.
2. Hardkódolt metrika-küszöbök. Néhány szabály fix számhoz volt kötve — például „ha egy futás X másodpercnél tovább tart, az anomália”. Csakhogy a valós szórás a rendszerben ennél sokkal szélesebb volt: egyes feladatok természetükből adódóan hosszabbak, és a fix küszöb nem igazodott ehhez a valós mintázathoz, így rendszeresen jelzett olyat, ami valójában teljesen normális volt az adott feladattípusnál.
3. Exit-kód maszkolás. Ez volt a legalattomosabb. Egy hibakezelő ág csendben elnyelt egy kivételt, és a folyamat ettől függetlenül „sikeresként” zárult le kifelé — miközben belül valójában elszállt valami. A mérőkód ebben az esetben nem talált hibát ott, ahol volt, miközben máshol, ahol minden rendben volt, hamis riasztást generált egy félreértett szövegrészlet miatt. A két hiba iránya ellentétes, de a gyökér ugyanaz: a mérőkód nem determinisztikus jelre épített, hanem valami puhára — szövegre vagy elnyelt állapotra.
A szabály, amit levontam
A tanulság egyszerűen megfogalmazható, de a gyakorlatban könnyű elszúrni: a mérőkód determinisztikus rétege soha ne parse-oljon szabad-szöveges AI-választ mint egyetlen igazságforrást, ne hardkódoljon metrika-küszöböt anélkül, hogy a valós szórást megnézted volna, és soha ne maszkolja el az exit-kódot egy csendes hibakezeléssel.
Az AI-t ítéletalkotásra és összefoglalásra érdemes használni — arra, hogy egy csomó adatból egy olvasható mondatot fogalmazzon meg. De arra, hogy eldöntse, történt-e hiba, ne az AI szöveges kimenetére támaszkodj — támaszkodj arra, amit a rendszer maga, explicit módon jelentett: egy számláló, egy exit-kód, egy strukturált JSON-mező, ami vagy true, vagy false, nincs középút, nincs értelmezési tér.
Három gyakorlati szabály, amit érdemes bevezetni
Ha építesz saját önellenőrző vagy anomália-detektáló réteget, három konkrét dolgot vezess be, mielőtt hinni kezdesz a saját riportodnak:
- A determinisztikus réteg sose függjön AI-kimenet szöveges formájától. Ha a döntésed „történt-e hiba” az azon múlik, hogy egy szabadszöveges válaszban benne van-e egy adott szó, az nem mérés — az tipp.
- Minden hibakezelő ág explicit logolja a hibát, sose nyelje el csendben. Egy
try/except, ami elkapja a kivételt és utána úgy tesz, mintha semmi nem történt volna, pont azt a réteget teszi tönkre, amiért egyáltalán mérsz. - Minden anomália-riasztásnál legyen egy „miért” mező, ami visszavezethető konkrét, ellenőrizhető adatra — nem elég, hogy a riasztás azt mondja „szokatlan viselkedés”, mondja meg pontosan, melyik szám, melyik küszöb, melyik esemény váltotta ki. Ha ezt nem tudod egy mondatban visszakövetni, a riasztás maga is gyanús.
A kapcsolódás egy másik, hasonló tanulsághoz
Érdemes megjegyezni, hogy ez a probléma rokon azzal, amit egy másik cikkemben az audit-napló szabadszöveges mezőjéről írtam: ott 38 különböző szöveges érték jelentette ugyanazt a néhány fogalmat, itt a mérőkód szöveges AI-válaszokra próbált szigorú döntést építeni. A gyökér ugyanaz: valahányszor egy determinisztikus döntést szabad szövegre próbálsz alapozni, előbb-utóbb szét fog csúszni. A javítás iránya is hasonló volt: szigorúan zárt, véges, gépileg ellenőrzött jelekre építeni a döntést, és a szabad szöveget (legyen az AI-válasz vagy emberi bejegyzés) csak kiegészítő magyarázatként megtartani, sosem elsődleges forrásként.
A legjobb monitoring az, amit te magad is auditálsz
A legmélyebb tanulság ebben az egészben nem technikai, hanem attitűdbeli: a mérőréteg maga is hibázhat, és ha vakon hiszel neki, az rosszabb, mintha egyáltalán nem mérnél semmit. Ha nem mérsz, legalább tudod, hogy nem tudsz semmit. Ha rosszul mérsz, és elhiszed, azt hiszed, tudsz valamit, ami nem igaz — és ez a hamis biztonságérzet drágább, mint a tudatlanság.
Amikor legközelebb egy AI-alapú riportot kapsz — akár a sajátodtól, akár egy vásárolt eszköztől —, tedd fel a kérdést: a döntő ítélet honnan jött? Egy determinisztikus tényből, vagy egy szöveg értelmezéséből? Ha az utóbbi, ne dobd ki a riportot, de nézz rá időnként gyanakodva — pont úgy, ahogy én is rákényszerültem, amikor 67-ből 64 hamisnak bizonyult.
Ha érdekel, hogyan néz ki egy anomália-detektáló réteg, ami tudatosan épít determinisztikus jelekre és AI-t csak összefoglalásra használ, ezt a technikai vázat is megtalálod a Blueprint-ek között.