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

AI Agent Observability zviditeľňuje vnútorné fungovanie autonómneho agenta: prostredníctvom tracingu (spany cez reasoning- a tool-cally), metrík (latencia, tokeny, náklady, miera úspešnosti), štruktúrovaných logov a kontinuálnych evals. Odpovedá na otázku, prečo sa agent takto rozhodol – a je predpokladom toho, aby sa multi-step agenti v produkcii vôbec dali debugovať, zabezpečiť a auditovať.

Na rozdiel od klasickej webovej služby agent nerobí jedno rozhodnutie typu požiadavka-odpoveď, ale na každú úlohu prechádza viacerými reasoning-kolami s medzitým vsunutými volaniami nástrojov. Práve táto viacstupňovosť robí bežný monitoring slepým: HTTP-200 nehovorí nič o tom, či bol zavolaný správny tool so správnymi argumentmi alebo či model na polceste odbočil nesprávne.

Tri kľúčové body vopred:

• Observability pre agentov pozostáva zo štyroch pilierov – tracing, metriky, logy a evals. Vzájomne do seba zapadajú: trace dodáva cestu, metriky dodávajú agregáciu, logy dodávajú kontext, evals dodávajú kvalitatívny posudok.
• Bez tracingu sú agenti nedebugovateľní. Len hierarchický trace cez všetky reasoning- a tool-call-spany ukáže, na ktorom kroku sa viacstupňový reťazec prelomil.
• Dátová rezidencia je povinné kritérium. Keďže trace obsahuje 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 EU, Datadog EU, Honeycomb EU).

Prečo sú agenti bez tracingu nedebugovateľní

Agent je nedeterministický. Tá istá požiadavka môže viesť k odlišným volaniam nástrojov, odlišnému počtu reasoning-kôl a odlišným výsledkom. Keď beh zlyhá alebo vyprodukuje vecne nesprávnu odpoveď, bez tracingu neexistuje spoľahlivá možnosť izolovať príčinu. Možné zdroje chýb v jedinej požiadavke:

• LLM reasonoval nesprávne a vybral nevhodný tool.
• Tool bol zavolaný s chybnými argumentmi.
• Retrieval-krok (RAG) vytiahol 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 zviditeľňuje každý z týchto krokov ako vlastný, časovo a kauzálne zaradený span. Tým sa debugovanie posúva od „hádania na základe konečného výsledku" k „nájdeniu konkrétneho spanu, ktorý sa prelomil". Research-dosier túto perspektívu ukotvuje aj architektonicky: service-meshe dodávajú observability na sieťovej úrovni a agentí-stacky z mnohých microservíc (orchestrátor, tool-server, memory-store, vector-DB, retrieval-service, guardrail-service) sú zvládnuteľné len s priebežnou observability-vrstvou.

Štyri piliere observability agentov

Tracing – spany cez reasoning a tool-cally

Trace zobrazuje kompletnú požiadavku agenta ako strom. Root-span zahŕňa celú požiadavku; pod ním visia vnorené spany pre každé volanie LLM, 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 – odvodene – náklady. Táto hierarchická štruktúra je rozhodujúcim rozdielom oproti klasickému, plochému request-logu.

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

Metriky agregujú naprieč mnohými trace. Jadro tvoria štyri signály:

• Latencia, end-to-end a na každé tool-call-kolo. Relevantná preto, lebo podľa dosiera agent vo Frankfurte, ktorý volá US-East-API, na každú smeru pridáva približne 80–130 ms navyše – pri viacerých tool-kolách sa to násobí.
• Tokeny (prompt a completion) na každý span ako základ atribúcie nákladov.
• Náklady na požiadavku, na tím a na use-case.
• Miera úspešnosti – podiel korektne dokončených úloh.

Logy – štruktúrovaný kontext

Štruktúrované logy dopĺňajú spany o detailný kontext: surové odpovede toolov, retry-pokusy, spustenia guardrailov, oseknuté kontexty. Dôležitá je korelácia: každý log-záznam by mal byť cez trace-ID priraditeľný konkrétnemu spanu, inak opäť vzniká slepé miesto.

Evals – kvalita ako súčasť observability

Evals sú signál, ktorý čistý tracing neposkytuje: systematické hodnotenie kvality výstupu. Hodnotí sa typicky miera úspešnosti, korektnosť tool-callov (bol zavolaný správny tool so správnymi argumentmi?) a kvalita odpovede – heuristikou, referenčným dátovým súborom alebo „LLM-as-a-Judge". Rozhodujúce pre regulované kontexty: evals a prompt-verzie sa tagujú voči fixovaným verziám modelov. Dosier tento vzor menuje explicitne – prompt-verzie a evals sa v gateway- resp. observability-stacku označujú voči konkrétnym verziám modelov, okrem iného na prípravu na vysokorizikové AI-Act-audity.

Matica signál-k-nástroju

Nasledujúca tabuľka priraďuje každý observability-signál jeho meranej veličine a typickému nástroju (uvedenia nástrojov z research-dosiera; stav 2026).

LLM-observability-stack: prehľad nástrojov

Research-dosier pomenúva pre observability-layer jasný výber (stav 2026):

• LangSmith – tracing- a eval-platforma z prostredia LangChain/LangGraph, ako managed-service. Silná, keď agent aj tak stavia na tomto frameworku; ako managed-možnosť je v dosieri uvedená v jednom rade s Datadog a Honeycomb.
• Langfuse – open source a tým self-hostovateľný v EU (vlastné dátové centrum alebo EU-región). V dosieri uvedený jednak pre regulovanú sovereign-architektúru (zákazníkom kontrolovaná observability), jednak pre lean-cloud-startup-vzor („Langfuse self-hosted") ako GDPR-konformná cesta.
• Arize Phoenix – open-source observability a evaluácia, v dosieri uvedená ako self-hostovateľná alternatíva popri Langfuse.
• OpenTelemetry pre LLM / OpenInference – výrobcovsky neutrálny trace-štandard. Inštrumentovaný cez GenAI-sémantické konvencie, backend zostáva vymeniteľný – dôležitý argument proti lock-inu. Napríklad TGI od Hugging Face už exportoval OpenTelemetry a Prometheus, ešte predtým ako v decembri 2025 prešiel do maintenance-módu.
• Datadog EU / Honeycomb EU – etablované APM-backendy s možnosťou EU-dátovej rezidencie, v dosieri uvedené ako managed-cesty pre DACH-rezidenciu.

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

Príklad-trace: jeden beh agenta, rozpísaný

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

```
TRACE id=ag-7f3c "Kundenanfrage: Rechnung stornieren" gesamt: 4.210 ms | 3.320 Tokens | 0,041 USD
├─ SPAN llm.reason model=gpt-4.x 620 ms | in 540 / out 80 Tok "Plan: Kunde+Rechnung nachschlagen"
├─ SPAN tool.crm_lookup mTLS, in-VPC 180 ms | status=200 args={kunde_id:8842}
├─ SPAN retrieval.vector qdrant-eu 95 ms | 4 Treffer query="Stornorichtlinie B2B"
├─ SPAN llm.reason model=gpt-4.x 710 ms | in 1.980 / out 130 Tok "Storno zulässig, Tool aufrufen"
├─ SPAN tool.invoice_void in-VPC 240 ms | status=200 args={rechnung:RE-2026-0317}
├─ SPAN guardrail.pii redaction 40 ms | 0 Treffer
└─ SPAN llm.compose model=gpt-4.x 2.325 ms| in 380 / out 210 Tok Antworttext an Kunde
EVAL tool_call_correct=PASS | answer_quality=0,92 | getaggt: model=gpt-4.x, prompt=v7
```

Čo tento trace dokáže, čo output-log nedokáže: keby stornovanie zlyhalo, strom okamžite ukáže, či tool.invoice_void dodal chybový status, či retrieval.vector vytiahol nesprávnu smernicu alebo či druhý llm.reason-span rozhodol nesprávne. Najväčšia latenčná položka (llm.compose, 2.325 ms) je bezprostredne rozpoznateľná ako kandidát na optimalizáciu. A eval-riadok viaže kvalitatívny posudok na verziu modelu a promptu – základ pre rollback a audit.

Vzťah k monitoringu v bezpečnostnom pilieri

Tracing nie je len debugovací, ale aj bezpečnostný signál. Agenti majú nezvyčajne vysoký „blast radius": kompromitovaný agent môže volať mnoho nástrojov. Priebežný trace dodáva presne ten audit-log, ktorý túto plochu útoku robí dohľadateľnou – ktorý agent kedy volal 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 gatewayi, jeden service-account na pár agent-tool namiesto zdieľaných accountov, ako aj naviazanie 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. Detailné meracie a kontrolné vzory k egressu, identite a monitoringu rieši bezpečnostný pilier; observability-vrstva preň dodáva telemetrický základ. Konkrétna token-ekonómia a modelovanie nákladov sú zase predmetom FinOps-piliera.

Pre agentúry a B2B-rozhodovateľov

Pre marketingové agentúry, ktoré budujú agentí-workflowy pre zákazníkov, je observability ten dodávaný objekt, ktorý oddeľuje pilot od auditovateľného produkčného systému: až trace, eval a EU-konformný backend robia agenta prevádzkovateľným, zúčtovateľným a obhájiteľným voči ochrane zákazníckych dát. Pre DACH-B2B-rozhodovateľov platí: vyberte observability-backend rovnako uvedomelo ako cloud-región – self-hosted Langfuse, Datadog EU alebo Honeycomb EU udržiavajú prompty a odpovede v priestore EU a výrobcovsky neutrálny OpenTelemetry-tracing chráni pred lock-inom. Blck Alpaca z Viedne koncipuje a prevádzkuje agentí-infraštruktúru s touto observability-vrstvou od začiatku – vrátane tracingu, eval-harnessu a GDPR-konformného backendu. Ozvite sa nám, ak chcete agenta z pilotného statusu previesť do auditovateľnej produkčnej prevádzky.