FDE Műhely

Bevezetés

Ha nem tudod megnézni, mit csinált, nem fogsz megbízni benne

Az audit trail nem extra funkció, hanem a bevezetés feltétele. Mit kell naplózni egy ágensnél, milyen formában, és mit kezdenek vele a kollégák.

Van egy pont, ahol minden bevezetés eldől, és ez nem a pontossági szám. Az a pont, amikor a szakterületi vezető megkérdezi: „és ezt most miért így döntötte el?”

Ha erre a válasz az, hogy „a modell így gondolta”, a projekt véget ért.

Mit kell naplózni

Minden lépésre, minden esetnél:

A bemenet. Pontosan az, amit a lépés megkapott. Nem összefoglalva: a tényleges tartalom, vagy egy hivatkozás a változatlan forrásra.

A meghozott döntés. Mit adott vissza a lépés.

Amire alapozta. Ez a legfontosabb, és ezt hagyják ki a leggyakrabban. Melyik mezőből vette az összeget, melyik rekordot húzta be a törzsből, melyik szabály illeszkedett.

A bizonytalanság. Mennyire volt biztos, és volt-e olyan alternatíva, ami közel volt.

Technikai kísérők. Melyik modell, melyik verzió, melyik prompt-változat, mennyi ideig tartott, mennyibe került.

Az utolsó blokk üzemeltetési szempontból kritikus: enélkül nem tudsz utólag válaszolni arra, hogy egy múlt heti romlást vajon egy modellfrissítés vagy egy sajátkezű promptváltoztatás okozta.

Kinek szól

Három közönsége van, és mindegyik mást akar látni.

A napi felhasználónak. Neki nem naplófájl kell. Neki a jóváhagyó képernyőn kell látnia, honnan jött az adat: a számla képén kiemelve az a mező, amiből az összeg származik. Egy pillantás, nem keresés.

Az üzemeltetőnek. Neki szűrhető, kereshető felület kell: mutasd az elmúlt hét összes olyan esetét, ahol a bizonytalanság 0,7 alatt volt. Ebből derül ki, merre romlik a rendszer.

Az auditornak vagy a vezetőnek. Neki egy konkrét ügy teljes története kell, időrendben, exportálható formában. Ha ezt nem tudjátok kiadni, az egy könyvvizsgálatnál probléma.

A naplónak emberül kell beszélnie

Ez a leggyakoribb hiba. A napló technikailag teljes, de csak fejlesztő érti.

Rossz:

step=vendor_match status=FAIL code=ERR_VENDOR_404 sim=0.61

Jó:

Szállító azonosítása — nem sikerült
A számlán: "Kovács és Tsa. Kft."
Legközelebbi találat a törzsben: "Kovács és Társa Kft." (61% egyezés)
A küszöb 85%, ezért nem fogadtuk el. Emberi döntésre vár.

A második ugyanannyi információt tartalmaz, de a pénzügyes is meg tudja oldani, és nem kell hozzá fejlesztő. Ez heti több óra különbség.

Amit nem szabad naplózni

A naplózás nem mentesít az adatvédelem alól. Amire figyelni kell:

  • Személyes adat. Csak annyi, amennyi a döntés rekonstruálásához kell. A megőrzési idő ugyanaz, mint a forrásadaté, nem hosszabb.
  • Titkok. API-kulcs, jelszó, token soha nem kerül naplóba. Ez triviálisan hangzik, és mégis ez a leggyakoribb szivárgási pont.
  • Teljes dokumentumok duplikálva. Ha a forrás már tárolva van, elég a hivatkozás — különben megduplázod a tárolást és a törlési kötelezettséget.

Miért ez adja a bizalmat

Az AI körüli félelem nagy része abból jön, hogy a rendszer kiszámíthatatlan és átláthatatlan. A kiszámíthatatlanságon nem lehet teljesen segíteni. Az átláthatatlanságon igen — és ez tisztán szoftvermérnöki feladat.

A gyakorlatban azt látjuk, hogy egy jól naplózott, 85%-os rendszert szívesebben vezetnek be, mint egy átláthatatlan 95%-osat. Mert az elsőnél tudják, mi történik a maradék 15%-kal.


Kapcsolódó: kivételkezelés és árnyékmód.

Kérdések ehhez a témához

Mennyi ideig kell megőrizni a naplókat?

Üzemeltetési célra 90 nap általában elég. Ahol könyvvizsgálat vagy hatósági elszámoltathatóság érintett, ott a vonatkozó megőrzési idő az irányadó — ezt az auditban tisztázzuk, mert utólag drága megoldani.

Nem lassítja le a rendszert a részletes naplózás?

Elhanyagolható mértékben. A naplóírás aszinkron, és nagyságrendekkel olcsóbb, mint egy modellhívás. A tárolási költség is marginális a rendszer többi eleméhez képest.

Ez nálatok hogy néz ki?

Ha ez a probléma ismerős, kezdjük egy folyamattal. Írjátok meg, melyik részleg viszi el a legtöbb kézi munkaórát — visszaírunk egy konkrét javaslattal.

Kapcsolódó cikkek