Miért nem működik a hagyományos monitoring az AI-alkalmazásoknál?

Ha az LLM-ekkel működő alkalmazásodat ugyanúgan monitorozod, mint a hagyományos API endpointjaidat, akkor valójában vakon repülsz.

Évek óta látom ezt a problémát. A csapatok beüzemelik az AI szolgáltatást, bedugják a meglévő monitoring rendszerükbe, nézik a zöld lámpákat – aztán szembesülnek azzal, hogy a felhasználók panaszkodnak a válaszok minőségére, vagy a számla háromszor akkora, mint várták. A dashboard azt mutatja, minden rendben van. De nem az.

A probléma mélyebb, mint néhány más metrika kiválasztása. Az AI rendszerek alapvetően máshogy működnek, mint amire a meglévő monitoring infrastruktúrát építettük.

A webes megközelítés nem passzol ide

A hagyományos webes monitoring egy tiszta jelzéssel dolgozik: jön egy kérés, történik valami, visszajön a válasz. Siker vagy hiba, fekete vagy fehér. A latency az latency.

Az LLM-ek ezt mind felülírják.

Egy válasz nem egyszerre érkezik meg – tokenenként generálódik. Ez azt jelenti, hogy a "latency" valójában legalább három különböző szám attól függően, hol tartasz a generálás folyamatában. Az, hogy a válasz 200 OK, nem mond semmit a kimenet minőségéről. A költség tokenekben mérhető, nem kérésekben. És a legijesztőbb hibák teljesen csendesek: a modell magabiztosan hazudozik, miközben tökéletes HTTP státuszkódot ad vissza.

Time to First Token: amit a felhasználó ténylegesen érez

Amikor valaki beküld egy promptot az AI funkcióba, az első pillanat a várakozás. Konkrétan az első token megjelenéséig tartó idő. Ez a Time to First Token (TTFT), és ez áll a legközelebb ahhoz, amit a felhasználók "észrevehető késedelemnek" hívnak.

A TTFT trükkje: nő a prompt hosszával. Ha építesz egy RAG rendszert, ami óriási context window-okat tölt minden kérésbe a pontosság növeléséhez, egyúttal rombolod a sebességet. Ez egy alapvető tradeoff, amit a hagyományos monitoring nem fog megmutatni.

Inter-Token Latency: a folyamatosság tényezője

Amint elindul a streaming, a felhasználók olvasási sebességre számítanak. Az Inter-Token Latency (ITL) – a tokenek közötti rés – dönti el, hogy a kimenet gördülékenynek vagy akadósnak érződik.

A felhasználók meglepően türelmesek egy lassú, de következetes streammel szemben. Utálják a gyorsabb, de akadozó kimenetet. A monitoringodnak különbséget kell tennie e között a két élmény között – még akkor is, ha a nyers átviteli sebesség elfogadhatónak tűnik.

End-to-End Latency: a kontextus számít

Az a p99 metrika, ami szépen működik a REST API-jainknál, teljesen félrevezető lesz az AI kérésekhez. Miért? Mert egy 50 tokenes osztályozási feladat és egy 2000 tokenes jelentésgenerálás gyökeresen eltérő latency profillal rendelkezik. Ha összeátlagolod őket, egy értelmetlen számot kapsz.

Kövesd nyomon a latency-t felhasználási esetenként. Minden metrikának egy konzisztens karakterisztikájú workloadhoz kell tartoznia. Különben egy olyan absztrakcióra optimalizálsz, ami nem létezik.

A csendes hiba problémája

Ez a legijesztőbb rész: a legrosszabb éles problémák AI rendszerekkel gyakran nullalertet generálnak.

A modell magabiztosan kezd hülyeségeket generálni. A prompt drift finom torzításokat visz be. A visszakapott kontextust figyelmen kívül hagyja a modell, és a betanított emlékekre támaszkodik. Mindez HTTP 200-zal tér vissza, elfogadható idő alatt, és a dashboardon tökéletesen egészségesnek tűnik.

Uptime ellenőrzéssel ezeket nem fogod elkapni. Output minőség monitoringra van szükség – ez nehezebb instrumentálni, de teljesen elengedhetetlen.

Ami tényleg számít

Csoportosítsd az AI metrikákat aszerint, milyen kérdésekre adnak választ:

• Gyors? TTFT, ITL, felhasználási eset szerinti latency percentilisek
• Skálázható? Token throughput, queue mélységek, context kihasználtság
• Helyes? Feladat teljesítési arányok, outputokban megjelenő hibaminták
• Fenntartható? Költség per feladat, token hatékonyság, modell konzisztencia
• Hogyan viselkedik? (Agenseknél) Task completion, lépésszám, loop detektálás

Ezek közül néhány metrikát ingyen megkapod az infrastruktúrától. A legtöbbet nem. Egyedi instrumentáció építése AI workloadokra nem opcionális – ez az egyetlen módja, hogy lásd, mi történik valójában.

A csapatok, akik ezt jól csinálják, nem jobb dashboardokat használnak. Jobb kérdéseket tesznek fel.