Monitorizarea AI nu funcționează ca restul aplicațiilor tale

Hai să fim sinceri: dacă monitorizezi aplicația ta bazată pe LLM la fel ca pe endpoint-urile API clasice, nu vezi de fapt ce se întâmplă.

Văd asta tot timpul. Echipele își configurează serviciul AI, îl conectează la stack-ul de observability existent, privesc becurile verzi și apoi sunt luate prin surprindere când utilizatorii se plâng de calitatea răspunsurilor sau când factura lunară e de trei ori mai mare decât se așteptau. Instrumentele le spun că totul e în regulă. Nu e.

Problema nu e doar alegerea altor metrici. E că sistemele AI sparg din temelii presupunerile pe care a fost construită infrastructura de monitorizare.

Modelul clasic web nu se potrivește

Monitorizarea tradițională presupune un semnal simplu: vine o cerere, se face treaba, iese un răspuns. Succes sau eșec, binary. Latency e latency. Percentila 99 îți spune ceva relevant.

LLM-urile sparg fiecare dintre aceste presupuneri.

Un răspuns nu vine dintr-o bucată — se generează token cu token, ceea ce înseamnă că "latency" e de fapt cel puțin trei numere diferite, în funcție de momentul în care te uiți. Un răspuns 200 OK nu spune nimic despre calitatea output-ului. Costul crește cu token-ii, nu cu cererile. Și cele mai grave eșecuri sunt complet silenciose: modelul returnează aiureli cu încredere maximă și un cod HTTP perfect.

Time to First Token: Numărul pe care utilizatorii îl simt

Când cineva trimite un prompt la funcția ta AI, prima experiență e așteptarea. Mai exact, așteaptă să apară primul token pe ecran. Asta e Time to First Token (TTFT) — și e cea mai apropiată variantă de "latency perceput" din lumea LLM.

Problema cu TTFT: crește cu lungimea promptului. Dacă construiești un sistem RAG care înghesuie context uriaș în fiecare cerere pentru acuratețe mai bună, în același timp îți sabotezi performanța percepută. E un tradeoff fundamental pe care monitorizarea tradițională nu îl va scoate la suprafață.

Inter-Token Latency: Factorul flux

După ce streaming-ul începe, utilizatorii dezvoltă așteptări despre viteza de citire. Inter-Token Latency (ITL) — gap-ul dintre token-ii consecutive — determină dacă output-ul se simte smooth sau sacadat.

Utilizatorii sunt surprinzător de toleranți cu un flux lent dar constant. Urăsc un flux mai rapid care îngheață și se oprește întrerupt. Monitorizarea ta ar trebui să facă diferența între aceste experiențe, chiar când throughput-ul brut arată OK.

Latency end-to-end: Contextul e totul

Metrica p99 care funcționează perfect pentru API-ul tău REST te va induce complet în eroare pentru cererile AI. De ce? Pentru că o sarcină de clasificare de 50 de token-i și o generare de raport de 2.000 de token-i au profile de latență complet diferite, iar dacă le faci medie obții un număr care nu reprezintă nimic.

Urmărește latența per caz de utilizare. Fiecare metrică ar trebui să corespundă unui singur workload cu caracteristici consistente. Altfel optimizezi pentru o abstracțiune care nu există.

Problema eșecurilor silent

Partea cea mai înfricoșătoare: cele mai grave probleme de producție cu sisteme AI adesea nu generează niciun alert.

Modelul tău începe să genereze halucinații cu încredere. Prompt drift-ul introduce bias subtil. Contextul recuperat e ignorat în favoarea memoriei din antrenament. Toate astea returnează HTTP 200, se termină în timp acceptabil și arată perfect sănătos în dashboard.

Nu vei prinde asta cu uptime checks. Ai nevoie de output quality monitoring, și asta e mai greu de instrumentat, dar absolut esențial.

Ce contează de fapt

Grupează metricile AI în jurul întrebărilor la care răspund:

• E rapid? TTFT, ITL, percentile de latență per use case
• Se scalează? Throughput de token-i, queue depths, context utilization
• E corect? Task completion rates, pattern-uri de erori în output
• Se menține? Cost per task, token efficiency, consistența modelului
• Cum se comportă? (Pentru agenți) Task completion, step counts, loop detection

Unele dintre aceste numere le vei primi gratuit din infrastructură. Cele mai multe, nu. Building custom instrumentation pentru workloads AI nu e opțional — e singura modalitate să vezi ce se întâmplă de fapt.

Echipele care reușesc asta nu folosesc dashboards mai bune. Pun întrebări mai bune.