Observability pre AI agentov: tracing, metriky, logy a evals

AI Agent Observability sprístupňuje vnútorné fungovanie autonómneho agenta: prostredníctvom tracingu (spany cez reasoning a volania nástrojov), metrík (latencia, tokeny, náklady, miera úspešnosti), štruktúrovaných logov a kontinuálnych evalov. Odpovedá na otázku, prečo agent rozhodol tak, ako rozhodol, a je predpokladom na to, aby bolo možné multi-step agentov v produkcii vůbec debugovať, zabezpečiť a auditovať.

Na rozdiel od klasickej webovej služby agent nevykoná jedno rozhodnutie typu požiadavka-odpoveď, ale prechádza pri každej úlohe viacerými reasoning kolami s medzizaradenými volaniami nástrojov. Práve táto viacstupňovosť robí konvenčný monitoring slepým: HTTP-200 nevypovedá nič o tom, či bol zavolaný správny nástroj so správnymi argumentmi alebo či model odbočil nesprávnym smerom v polovici cesty.

Tri kľúčové body vopred:

• Observability pre agentov pozostáva zo štyroch pilierovtracing, metriky, logy a evaly. Navzájom sa dopĺňajú: trace poskytuje cestu, metriky poskytujú agregáciu, logy poskytujú kontext, evaly poskytujú hodnotenie kvality.
• Bez tracingu sú agenti ne-debugovateľní. Len hierarchický trace cez všetky reasoning a tool-call spany ukazuje, v ktorom kroku sa viacstupňový reťazec zlomil.
• Dátová rezidencia je povinné kritérium. Keďže trace obsahujú prompty a odpovede, teda potenciálne zákaznícke dáta, je observability backend pre DACH-B2B sám compliance objektom (Langfuse self-hosted v EÚ, Datadog EU, Honeycomb EU).

Prečo sú agenti bez tracingu ne-debugovateľní

Agent je nedeterministický. Tá istá požiadavka môže viesť k rôznym volaniam nástrojov, rôznemu počtu reasoning kôl a rôznym výsledkom. Ak beh zlyhá alebo vyprodukuje odborne nesprávnu odpoveď, bez tracingu neexistuje spoľahlivý spôsob, ako izolovať príčinu. Možné zdroje chýb v jednej požiadavke:

• LLM nesprávne reasonoval a zvolil nevhodný nástroj.
• Nástroj bol zavolaný s chybnými argumentmi.
• Retrieval krok (RAG) stiahol nesprávne dokumenty.
• Guardrail alebo PII filter zasiahol a zmenil kontext.
• Verzia modelu sa zmenila na strane servera (managed API aktualizujú modely podľa harmonogramu poskytovateľa).

Plochý output log tieto prípady nerozlišuje. Tracing robí každý z týchto krokov viditeľným ako vlastný, časovo a kauzálne zaradený span . Tým sa debugging posúva z „hádania na základe konečného výsledku" na „nájdenie konkrétneho spanu, ktorý je zlomený". Research dossier zakotvuje tento pohľad aj architektonicky: service meshe poskytujú observability na sieťovej úrovni a agentské stacky z mnohých microservices (orchestrator, tool server, memory store, vector DB, retrieval service, guardrail service) sú zvládnuteľné len s prierezovou observability vrstvou.

Štyri piliere agentskej observability

Tracing, spany cez reasoning a tool-cally

Trace zobrazuje kompletnú agentskú požiadavku ako strom. Root span zahŕňa celú požiadavku; pod ním visia vnorené spany pre každé LLM volanie, každý tool-call, každý retrieval krok a každú guardrail kontrolu. Každý span nesie vstupy a výstupy ako aj atribúty ako názov modelu, prompt a completion tokeny, latenciu a, odvodené, náklady. Táto hierarchická štruktúra je rozhodujúci rozdiel oproti klasickému, plochému request logu.

Metriky, latencia, tokeny, náklady, miera úspešnosti

Metriky agregujú cez mnoho trace. Štyri signály tvoria jadro:

• Latencia, end-to-end a na tool-call kolo. Relevantné, pretože podľa dossier agent vo Frankfurte, ktorý volá US-východ API, buduje na smer približne 80–130 ms navyše, pri viacerých tool kolách sa to násobí.
• Tokeny (prompt a completion) na span ako základ nákladovej atribúcie.
• Náklady na požiadavku, tím a use-case.
• Miera úspešnostipodiel správne dokončených úloh.

Logy, štruktúrovaný kontext

Štruktúrované logy dopĺňajú spany o detailný kontext: surové odpovede nástrojov, retry pokusy, guardrail spustenia, orezané kontexty. Dôležitá je korelácia: každý log záznam by mal byť cez trace ID priraďovateľný ku konkrétnemu spanu, inak opäť vzniká slepá škvrna.

Evaly, kvalita ako súčasť observability

Evaly sú signál, ktorý čistý tracing neposkytuje: systematické hodnotenie kvality výstupu. Hodnotí sa typicky miera úspešnosti, správnosť tool-callu (bol zavolaný správny nástroj so správnymi argumentmi?) a kvalita odpovede, pomocou heuristiky, referenčného datasetu alebo „LLM-as-a-Judge". Rozhodujúce pre regulované kontexty: evaly a verzie promptov sú tagované voči fixným verziám modelov . Dossier uvádza tento vzor explicitne, verzie promptov a evaly sú v gateway resp. observability stacku označené voči konkrétnym verziám modelov, okrem iného na prípravu AI-Act vysokorizikových auditov.

Matica signál-nástroj

Nasledujúca tabuľka priradí každý observability signál jeho meranej veličine a typickému nástroju (nástroje uvedené z research dossier; stav 2026).

LLM observability stack: prehľad nástrojov

Research dossier uvádza pre observability vrstvu jasný výber (stav 2026):

• LangSmithtracing a eval platforma z prostredia LangChain/LangGraph, ako managed služba. Silná, ak agent aj tak stojí na tomto frameworku; ako managed možnosť v dossier uvedená v jednom rade s Datadog a Honeycomb.
• Langfuseopen source a tým self-hostovateľný v EÚ (vlastné dátové centrum alebo EÚ región). V dossier uvedený ako pre regulovanú sovereign architektúru (zákazníkom kontrolovaná observability) tak aj pre lean-cloud-startup vzor („Langfuse self-hosted") ako GDPR konformná cesta.
• Arize Phoenixopen-source observability a evaluácia, v dossier uvedený ako self-hostovateľná alternatíva vedľa Langfuse.
• OpenTelemetry pre LLM / OpenInferencevýrobcovo neutrálny trace štandard. Cez GenAI sémantické konvencie inštrumentovaný, backend zostáva vymeniteľný, dôležitý argument proti lock-inu. Hugging Faces TGI napríklad exportovalo už OpenTelemetry a Prometheus, predtým ako v decembri 2025 prešlo do maintenance módu.
• Datadog EU / Honeycomb EUzavedené APM backendy s možnosťou EÚ dátovej rezidencie, v dossier uvedené ako managed cesty pre DACH rezidenciu.

Dôležitý architektonický bod: AI-Gateway (LiteLLM, Portkey, Kong) je často už nositeľom častí observability. Gateways preberajú podľa dossier multi-provider failover, virtuálny key management, tímové rozpočty, observability, guardrails a PII redaction. V praxi gateway atribuuje tokeny a náklady, zatiaľ čo tracing platforma drží reasoning cestu a evaly, oboje spolu dáva kompletný obraz.

Príklad trace: jeden agentský beh, rozčlenený

Nasledujúci pseudo-príklad ukazuje, ako vyzerá jeden support agentský beh ako span strom. Čísla sú ilustratívne; veľkosť latencie pre transatlantické volania (80–130 ms/smer) pochádza z dossier.

```
TRACE id=ag-7f3c "Zákaznícka požiadavka: stornovať faktúru" celkom: 4.210 ms | 3.320 tokenov | 0,041 USD
├─ SPAN llm.reason model=gpt-4.x 620 ms | in 540 / out 80 tok "Plán: vyhľadať zákazníka+faktúru"
├─ SPAN tool.crm_lookup mTLS, in-VPC 180 ms | status=200 args={kunde_id:8842}
├─ SPAN retrieval.vector qdrant-eu 95 ms | 4 zásahy query="Stornovacie pravidlá B2B"
├─ SPAN llm.reason model=gpt-4.x 710 ms | in 1.980 / out 130 tok "Storno prípustné, zavolať nástroj"
├─ SPAN tool.invoice_void in-VPC 240 ms | status=200 args={rechnung:RE-2026-0317}
├─ SPAN guardrail.pii redaction 40 ms | 0 zásahov
└─ SPAN llm.compose model=gpt-4.x 2.325 ms| in 380 / out 210 tok Text odpovede zákazníkovi
EVAL tool_call_correct=PASS | answer_quality=0,92 | tagované: model=gpt-4.x, prompt=v7
```

Čo tento trace poskytuje, čo output log nemôže: keby stornovanie zlyhalo, strom okamžite ukáže, či tool.invoice_void vrátil chybový status, či retrieval.vector stiahol nesprávne pravidlá alebo či druhý llm.reasonspan rozhodol nesprávne. Najväčšia latencia (llm.compose, 2.325 ms) je okamžite rozpoznateľná ako kandidát na optimalizáciu. A eval riadok viaže hodnotenie kvality na verziu modelu a promptu, základ pre rollback a audit.

Vzťah k monitoringu v bezpečnostnom pilieri

Tracing nie je len debugging, ale aj bezpečnostný signál. Agenti majú nezvyčajne vysoký „blast radius": kompromitovaný agent môže volať mnoho nástrojov. Prierezový trace poskytuje presne ten audit log, ktorý robí túto útočnú plochu sledovateľnou, ktorý agent kedy zavolal ktorý nástroj s akou identitou. To dopĺňa kontroly z bezpečnostného a identitného kontextu: deny-by-default egress s allowlistom a logovaním na gateway, service account na pár agent-nástroj namiesto zdieľaných účtov ako aj spätnú väzbu každého volania na identitu používateľa cez token-exchange reťazec. Observability na sieťovej úrovni cez service mesh (mTLS, workload identity, traffic shaping) uzatvára kruh. Podrobné meracie a kontrolné vzory k egressu, identite a monitoringu rieši bezpečnostný pilier; observability vrstva poskytuje pre to telemetrickú bázu. Konkrétna token ekonómia a nákladové modelovanie je zase predmetom FinOps piliera.

Pre agentúry a B2B rozhodovateľov

Pre marketingové agentúry, ktoré budujú agentské workflow pre zákazníkov, je observability dodávateľský objekt, ktorý oddeľuje pilot od auditovateľného produkčného systému: až trace, eval a EÚ konformný backend robia agenta prevádzkovateľným, účtovateľným a obhájiteľným voči zákazníckej ochrane údajov. Pre DACH-B2B rozhodovateľov platí: vyberte observability backend rovnako vedome ako cloud región, self-hosted Langfuse, Datadog EU alebo Honeycomb EU držia prompty a odpovede v EÚ priestore a výrobcovo neutrálny OpenTelemetry tracing chráni pred lock-inom. Blck Alpaca z Viedne koncipuje a prevádzkuje agentskú infraštruktúru s touto observability vrstvou od začiatku, vrátane tracingu, eval harness a GDPR konformného backendu. Oslovte nás, ak chcete agenta previesť z pilotného stavu do auditovateľnej produkčnej prevádzky.