Observability pentru 9 agenți AI concurenți: metricele care contează
Marți dimineață, 08:15. Tabloul de bord arată p95 latency 1.4s — verde peste tot. Trei agenți dau răspunsuri greșite. Latency nu vede asta.
Observability pentru 9 agenți AI concurenți: metricele care contează
Marți dimineață, 08:15. Tabloul de bord arată p95 latency 1.4s — verde peste tot. Trei agenți dau răspunsuri greșite. Latency nu vede asta.
Când rulezi nouă agenți LLM în paralel — un router, un supervisor, șase workeri specializați, un critic — observability-ul clasic (latency, error rate, throughput) rămâne condiția minimă. Dacă vrei să prinzi eșecurile care contează, măsori altceva. Pentru context arhitectural, vezi cum stabilim când merită un orchestrator.
Cele patru metrice care lipsesc din dashboardul default
Task success rate per rol. Nu „HTTP 200 din tool”, ci „a livrat agentul rezultatul cerut de supervisor?”. Se măsoară cu un judge (LLM secundar sau reguli deterministe) și se agregă pe rol. Un worker de extracție cu 78% success e ok; același worker cu 78% după un update de prompt e regresie. NIST AI Risk Management Framework 1.0 cere explicit funcția „Measure” pentru sisteme cu impact operațional.
Tool call correctness. Agentul a ales tool-ul potrivit? Câmpurile sunt bine populate? Ordinea apelurilor respectă dependențele? OpenTelemetry a standardizat semantic conventions pentru GenAI (gen_ai.tool.name, gen_ai.tool.call.id), propagate prin lanț cu W3C Trace Context.
Handoff loss. Când agent A trimite spre agent B, cât din contextul relevant supraviețuiește? Se măsoară comparând ce a scris A cu ce a citit B — embedding similarity plus câmpuri obligatorii prezente. Aici se pierde cel mai mult și nu vede nimeni.
Reasoning drift. Agentul rămâne pe task sau derivă spre o interpretare tangențială? Verificare periodică: „ce problemă rezolvi acum?” comparată cu prompt-ul inițial. ENISA AI threat landscape plasează drift-ul între riscurile operaționale majore la sisteme agentice.
Cum arată telemetria când o legi ca lumea
Regulamentul (UE) 2024/1689 (AI Act), Art. 12 impune logging automat al evenimentelor pentru sisteme high-risk pe toată durata de viață. Un trace concret arată așa:
2026-09-16T08:03:41Z trace_id=7f2a run_id=r-4491 agent=router
event=handoff.out target=worker.extract span_ms=612
fields_required=[doc_id,schema_v] fields_present=[doc_id,schema_v,priority]
handoff_loss=0.02
2026-09-16T08:03:42Z trace_id=7f2a run_id=r-4491 agent=worker.extract
event=tool.call name=pdf_parse args_valid=true attempt=1
tokens_in=3120 tokens_out=847 cost_usd=0.0091
2026-09-16T08:03:44Z trace_id=7f2a run_id=r-4491 agent=critic
event=judge score=0.71 threshold=0.80 verdict=retry
reason="missing_line_items[3]"Cu nouă agenți, un trace poate depăși 60 de span-uri. Fără run_id stabil pentru corelare și fără sampling inteligent (100% pentru run-uri eșuate, 5% pentru cele reușite), factura pe backend-ul de traces urcă mai repede decât cea de tokeni — logica de trade-off e aceeași cu cea din rutarea LLM pe cost.
Poziția noastră
La CAI, dashboardul default pentru fiecare deploy multi-agent are șase panouri: success rate per rol, handoff loss între perechi, tool correctness, drift score, cost per run distribuit pe agent și „silent failures” (răspuns livrat, judge-ul îl respinge). Latency e al șaptelea, nu primul. Când auditezi propriul stack agentic, începe cu handoff loss — e metrica ignorată aproape universal și rupe cel mai des output-ul. Scrie-ne dacă vrei o revizuire de instrumentare pe pipeline-ul tău.