Observability of AI agents: dashboard-ul minim pentru a opera un agent în producție

Un agent AI care funcționează în pilot și un agent AI care operează zilnic în producție arată similar pentru utilizator. Pentru echipa care îl întreține, sunt fundamental diferiți. Diferența nu este în cod; este în observability. Fără un set de metrici riguroase, un agent în producție devine o cutie neagră care „uneori funcționează” și asupra căreia nu poți lua decizii informate.

Articolul descrie metrici-le pe care le tracăm pentru fiecare agent AI pe care îl operăm intern și pentru clienți, cu detalii despre cum se calculează, ce praguri sunt rezonabile, și cum interpretăm valorile.

TL;DR

• Cinci familii de metrici sunt obligatorii: cost (tokens), latency, calitate (hallucination, tool-use success), audit completeness, business impact.
• „Hallucination rate” nu se măsoară automat; se măsoară prin sampling manual săptămânal pe 1-2% din răspunsuri.
• Latency trebuie urmărit p50/p95/p99, nu medie. Media maschează cozile lungi care irită utilizatorii.
• Tool-use success este indicator timpuriu de probleme: un drop sub 90% înseamnă că ceva s-a stricat (model schimbat, schema modificată, infrastructură upstream).
• Dashboard-ul ar trebui să se citească în 30 secunde. Mai mult de 8-10 widget-uri devine zgomot.

Cele cinci familii de metrici

1. Cost — tokens consumed

Pentru un agent operațional, costul este metric primary. Componente:

• Tokens input per zi, per model, per agent session
• Tokens output per zi, per model, per agent session
• Cost echivalent în EUR/USD per zi (calculat după pricing-ul providerului)
• Distribuție pe clase de model (premium / mid / local) pentru cost-aware routing

Pragul tipic: dacă vedeți o creștere bruscă peste 30% față de baseline săptămâna anterioară fără o explicație de business (volum mai mare de cereri), investigați. Cauze frecvente: model schimbat la default mai scump, prompt mărit (system prompt accidental dublat), context loop care nu se închide.

2. Latency — p50, p95, p99

Media latenței este înșelătoare. Distribuția este asimetrică: 90% din cereri rapide, 5-10% lente, 1-2% foarte lente. Folosiți percentile:

• p50 (median): cât durează jumătate din cereri. Dacă crește, baseline e degradat.
• p95: 5% din cereri sunt mai lente. Pragul nostru tipic: sub 8 secunde pentru work, sub 30 secunde pentru design.
• p99: 1% din cereri sunt mai lente. Acestea irită utilizatorii direct. Pragul tipic: sub 60 secunde.

Defalcare pe componente: timp în LLM (network plus inferență), timp în tool execution, timp în I/O (file system, DB). Identificarea componenței dominante directionează optimizarea.

3. Calitate — hallucination și tool-use

Hallucination rate. Frecvența cu care agentul produce afirmații false sau invenții care nu sunt în context. Nu se măsoară automat (un model nu poate verifica fiabil dacă alt model halucinează). Procedura noastră:

• Sampling săptămânal: alegem random 1-2% din răspunsurile agentului
• Reviewer uman citește răspunsul și contextul
• Marchează: corect / parțial / halucinat
• Calculăm rate-ul: halucinat / (corect + parțial + halucinat)

Pragul: rate sub 1% pentru sarcini factuale (lookup, status). Pragul sub 3% pentru sarcini de raționament (analiză, recomandare). Peste, agentul nu este production-ready.

Tool-use success rate. Frecvența cu care agentul apelează tool-ul corect cu parametri valizi care produc rezultat util. Calcul automat:

• Total tool calls
• Tool calls eșuate cu eroare structurată (validation, permission, upstream)
• Tool calls eșuate fără să recupereze (agentul nu a re-încercat sau nu a comutat la alt tool)
• Tool calls reușite

Pragul tipic: peste 92% success. Sub 90%, ceva e stricat.

4. Audit completeness

Pentru agenți care fac acțiuni cu impact (în special cu propose-then-act), auditul este obligator. Metrici:

• Procent acțiuni cu plan complet logat (țintă: 100%)
• Procent acțiuni cu aprobare logată (țintă: 100% pentru acțiuni care necesită aprobare)
• Procent acțiuni cu rezultat post-execuție logat (țintă: 100%)
• Procent sesiuni cu trace complet (input → plan → aprobare → execuție → rezultat)

Sub 100% înseamnă risc de litigiu sau de non-conformitate. Singura toleranță acceptabilă este pentru acțiuni cu zero impact (status, info).

5. Business impact

Metrici care arată dacă agentul livrează valoare:

• Cereri serviced per zi
• Cereri eșuate (utilizatorul a abandonat sau a refăcut manual)
• Timp economisit (estimat) per cerere
• Satisfacție utilizator (calitativ, evaluat săptămânal pe sample)
• Volume de proceduri executate (deploys, alerts handled, tickets resolved) — depinde de agent

Aceste metrici sunt mai greu de standardizat dar sunt cele care justifică agentul față de management.

Layout dashboard tipic

Dashboard-ul nostru pentru un agent are 8 widget-uri în această ordine de citire:

[ Cost zilnic 7 zile ]  [ Cost lunar curs ]
[ Latency p50/p95/p99 ]  [ Tool-use success % ]
[ Acțiuni cu impact: plan / approve / execute ]
[ Top 5 erori în ultimele 24h ]
[ Sesiuni active acum ]   [ Cereri nereușite ultimă oră ]

Citire în 30 secunde: cost trend OK, latency în limite, tool-use peste prag, acțiuni cu impact toate auditate, fără erori top, sesiuni active normale, fără spike de eșecuri.

Alerting

Alerting-ul automat trebuie să fie conservator. Un agent în producție are zgomot natural; alarmele false la fiecare oră sunt mai dăunătoare decât niciuna.

Pragurile noastre tipice:

• Latency p95 > 2x baseline pentru 15 minute → alert
• Tool-use success < 85% pentru 30 minute → alert
• Cost zilnic > 1.5x baseline → alert (poate fi spike legitim, dar verificați)
• Audit completeness < 100% timp de o zi → alert critical
• Hallucination rate > 5% în sampling săptămânal → alert critical (cu reviewer uman)
• Erori upstream (LLM provider) > 10% → alert

Toate alertele direcționate la canal de ops cu context. Niciuna nu se rezolvă singură; toate cer triage uman.

Sampling pentru hallucination

Un detaliu critic: hallucination rate fără sampling manual nu este măsurabil. Procedura noastră:

1. Selecție random 50-100 sesiuni pe săptămână
2. Reviewer uman citește răspunsul agentului plus contextul (input utilizator, tool outputs intermediari)
3. Marchează verdict: corect / parțial / halucinat
4. Notează patternul (dacă e halucinat: ce tip — fapte inventate, atribuiri greșite, agregare incorectă)
5. Tracking pe trend săptămânal

Investiția: 2-4 ore reviewer pe săptămână. Pentru un agent care servește operațiuni reale, este mult mai puțin decât costul unui singur incident provocat de halucinație nedetectată.

Greșeli comune

Greșeală 1: monitor doar cost. Multe echipe fac dashboard de tokens / EUR și consideră observability done. Cost este ușor de măsurat, calitatea este greu — și exact asta o face importantă.

Greșeală 2: medii în loc de percentile. Latency medie poate fi 2 secunde cu p95 la 30 secunde. Utilizatorii din p95 sunt cei care abandonează produsul.

Greșeală 3: alerts pe orice. Alarme false dezactivează atenția. Pragurile trebuie reglate empiric, nu setate la valori „rotunde”.

Greșeală 4: lipsa de logs structurate. Loguri text liber nu se queryesc. Folosiți JSON structurat cu fields fixe: timestamp, agent_id, session_id, action_type, model_used, tokens_in, tokens_out, latency_ms, status.

Greșeală 5: lipsa de retention strategy. Logs cresc rapid. Definiți: păstrare 30 zile fine-grained, agregări 12 luni, summary anual. Storage devine cost real altfel.

Tooling

Stack-ul nostru intern este modular:

• Logs structurate scrise în JSON pe disk
• Aggregare cu Loki sau echivalent
• Metrici numerice prin Prometheus
• Vizualizare Grafana
• Sampling halucinații prin script Python care citește logs și deschide UI pentru reviewer
• Alerting prin canal Telegram dedicate ops

Stack-ul exact contează mai puțin decât metrici-le tracate. Începeți cu un dashboard simplu, iterați.

Concluzie

Un agent AI fără observability este un agent care va eșua ceva pe care nu îl veți observa decât după ce un utilizator se plânge. Cele cinci familii de metrici (cost, latency, calitate, audit, business) acoperă aproape toate eșecurile pe care le-am văzut în practică. Investiția este de zile la prima setare și ore pe săptămână la operare. Beneficiul este că agentul devine ceva pe care îl puteți încredința echipei voastre — nu o cutie neagră care „de obicei funcționează”.

Articole conexe

• Arhitectura propose-then-act pentru agenți AI
• Cost-aware LLM routing
• SIEM on-prem cu LLM local pentru triage
• Pillar IRIS — agentul orchestrator CAI Technology

Surse externe

• Google SRE Book — Monitoring Distributed Systems — referință standard pentru SLO și percentile
• OpenTelemetry semantic conventions for AI — emerging standard pentru tracing AI workloads
• Anthropic — usage and metrics — referință pentru tokens reporting
• „Sparks of Artificial General Intelligence” — Bubeck et al., arXiv 2303.12712 — context pentru evaluarea calitativă a LLM-urilor
• Honeycomb on observability for AI — practica industrială recentă

Următorul pas

Dacă echipa dvs. operează un agent AI și vrea să stabilim împreună metricile potrivite pentru workflow-ul vostru, vă oferim o consultație tehnică de 30 minute fără cost.