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.