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

Observability AI agentov zviditeľňuje vnútorné fungovanie autonómneho agenta: pomocou tracingu (spany pre reasoning a volania nástrojov), metrík (latencia, tokeny, náklady, miera úspešnosti), štruktúrovaných logov a priebežných evalov. Odpovedá na otázku, prečo sa agent rozhodol práve tak, a je predpokladom na to, aby sa viackrokoví 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 pri každej úlohe prechádza viacerými kolami reasoningu s vloženými volaniami nástrojov. Práve táto viacstupňovosť robí bežný monitoring slepým: HTTP 200 nič nehovorí o tom, či bol zavolaný správny nástroj so správnymi argumentmi, alebo či model v polovici cesty nesprávne odbočil.

Tri kľúčové body vopred:

• Observability pre agentov pozostáva zo štyroch pilierov. Tracing, metriky, logy a evaly. Navzájom do seba zapadajú: trace poskytuje cestu, metriky agregáciu, logy kontext a evaly hodnotenie kvality.
• Bez tracingu sú agenti nedebugovateľní. Len hierarchický trace cez všetky spany reasoningu a volaní nástrojov ukáže, v ktorom kroku sa viacstupňový reťazec prerušil.
• Dátová rezidencia je povinné kritérium. Keďže trace obsahujú prompty a odpovede, teda potenciálne dáta zákazníkov, je observability backend pre B2B v regióne DACH sám osebe predmetom compliance (Langfuse self-hosted v EÚ, Datadog EU, Honeycomb EU).

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

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

• LLM sa v reasoningu pomýlil a zvolil nevhodný nástroj.
• Nástroj bol zavolaný s chybnými argumentmi.
• Krok retrievalu (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ý výstupný log tieto prípady nerozlíši. Tracing zviditeľní každý z týchto krokov ako samostatný, časovo a kauzálne zaradený span. Debugging sa tým presúva od „hádania podľa konečného výsledku“ k „nájdeniu konkrétneho spanu, ktorý zlyhal“. Architektonicky platí to isté: service meshe poskytujú observability na úrovni siete a agentské stacky z mnohých mikroslužieb (orchestrátor, tool server, memory store, vektorová databáza, retrieval služba, guardrail služba) sa dajú zvládnuť len s ucelenou observability vrstvou.

Štyri piliere observability agentov

Tracing: spany pre reasoning a volania nástrojov

Trace zobrazuje celú požiadavku agenta ako strom. Root span pokrýva celú požiadavku; pod ním visia vnorené spany pre každé volanie LLM, každé volanie nástroja, každý krok retrievalu a každú kontrolu guardrailu. Každý span nesie vstupy a výstupy a atribúty ako názov modelu, prompt a completion tokeny, latenciu a z nich odvodené náklady. Práve 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ú údaje naprieč mnohými trace záznamami. Jadro tvoria štyri signály:

• Latencia, end-to-end a na každé kolo volaní nástrojov. Medzi regiónmi Azure Germany West Central (Frankfurt) a East US meria Microsoft medián 94 ms round-trip (štatistika latencie Azure, stav júl 2026). Agent vo Frankfurte, ktorý volá API na východe USA, zaplatí tento čas pri každom volaní. Pri viacerých kolách volaní nástrojov sa sčítava.
• Tokeny (prompt a completion) na každý span ako základ pre priraďovanie nákladov.
• Náklady na požiadavku, na tím a na prípad použitia.
• Miera úspešnosti, teda podiel správne dokončených úloh.

Logy: štruktúrovaný kontext

Štruktúrované logy dopĺňajú spany o podrobný kontext: surové odpovede nástrojov, opakované pokusy (retries), spustenia guardrailov, orezané kontexty. Dôležitá je korelácia: každý záznam v logu by sa mal dať cez trace ID priradiť ku konkrétnemu spanu, inak opäť vzniká slepé miesto.

Evaly: kvalita ako súčasť observability

Evaly sú signál, ktorý samotný tracing neposkytuje: systematické hodnotenie kvality výstupu. Typicky sa hodnotí miera úspešnosti, správnosť volaní nástrojov (bol zavolaný správny nástroj so správnymi argumentmi?) a kvalita odpovede, a to heuristikou, referenčným datasetom alebo metódou „LLM-as-a-Judge“. Rozhodujúce pre regulované prostredia: evaly a verzie promptov sa v gateway alebo v observability platforme tagujú voči fixným verziám modelov. Každé hodnotenie kvality sa tak dá priradiť ku konkrétnej verzii modelu a promptu. Ak je agent podľa AI Act zaradený ako vysokorizikový systém, toto priradenie uľahčuje požadované preukazovanie, napríklad presnosti a robustnosti podľa čl. 15 a validačných a testovacích postupov, ktoré musí obsahovať technická dokumentácia podľa čl. 11 a prílohy IV.

Matica signálov a nástrojov

Nasledujúca tabuľka priraďuje každému observability signálu meranú veličinu a typický nástroj (stav 2026).

LLM observability stack: prehľad nástrojov

Pre observability vrstvu prichádzajú do úvahy najmä tieto nástroje (stav 2026):

• LangSmith, platforma na tracing a evaly z prostredia LangChain/LangGraph, ako managed služba. Silná, ak agent aj tak stojí na tomto frameworku. Pri managed službe si vopred over, kde sa trace ukladajú.
• Langfuse, open source a podľa dokumentácie k self-hostingu prevádzkovateľný na vlastnej infraštruktúre, teda self-hostovateľný v EÚ (vlastné dátové centrum alebo región EÚ). Hodí sa do regulovaných architektúr s observability pod kontrolou zákazníka rovnako ako do štíhlych cloudových setupov, ktoré držia trace v EÚ v súlade s GDPR.
• Arize Phoenix, observability a evaluácia pod licenciou Elastic License 2.0, bezplatne self-hostovateľný, a teda alternatíva k Langfuse.
• OpenTelemetry pre LLM / OpenInference, štandard pre trace nezávislý od dodávateľa. Pri inštrumentácii cez GenAI Semantic Conventions zostáva backend vymeniteľný: dôležitý argument proti lock-inu. Napríklad projekt TGI od Hugging Face exportoval OpenTelemetry trace a metriky pre Prometheus ešte predtým, ako prešiel do režimu údržby.
• Datadog EU / Honeycomb EU, zavedené APM backendy s regiónom v EÚ: Datadog prevádzkuje site EU1 v Nemecku, Honeycomb ukladá dáta podľa zvoleného regiónu v USA alebo EÚ. Obe sú managed cestou, ak majú dáta zostať v EÚ.

Dôležitý architektonický bod: AI gateway (LiteLLM, Portkey, Kong) často už nesie časť observability. Gateway typicky zabezpečuje failover medzi viacerými poskytovateľmi, správu virtuálnych kľúčov, tímové rozpočty, observability, guardrails a redigovanie PII. V praxi gateway priraďuje tokeny a náklady, zatiaľ čo tracing platforma uchováva cestu reasoningu a evaly: až spolu dávajú úplný obraz.

Príklad trace: rozpis jedného behu agenta

Nasledujúci pseudopríklad ukazuje, ako vyzerá jeden beh support agenta ako strom spanov. Čísla sú ilustračné.

```
TRACE id=ag-7f3c "Požiadavka zákazníka: 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={customer_id:8842}
├─ SPAN retrieval.vector qdrant-eu 95 ms | 4 výsledky query="Pravidlá storna 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={invoice: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 | otagované: model=gpt-4.x, prompt=v7
```

Čo tento trace dokáže a výstupný log nie: keby stornovanie zlyhalo, strom okamžite ukáže, či tool.invoice_void vrátil chybový status, či retrieval.vector vytiahol nesprávne pravidlo, alebo či druhý span llm.reason rozhodol nesprávne. Najväčšia položka latencie (llm.compose, 2 325 ms) je hneď viditeľná ako kandidát na optimalizáciu. A riadok EVAL viaže hodnotenie kvality na verziu modelu a promptu: to je základ pre rollback a audit.

Vzťah k monitoringu v bezpečnostnom pilieri

Tracing je signálom pre debugging a zároveň bezpečnostným signálom. Agenti majú nezvyčajne veľký „blast radius“: kompromitovaný agent môže volať mnoho nástrojov. Ucelený trace poskytuje presne ten audit log, vďaka ktorému je táto útočná plocha sledovateľná: ktorý agent kedy zavolal ktorý nástroj s akou identitou. Ak je agent podľa AI Act vysokorizikový systém, tento trace zároveň tvorí technický základ pre automatické zaznamenávanie udalostí, ktoré vyžaduje čl. 12. Trace dopĺňa kontroly z bezpečnostného a identitného kontextu: egress podľa princípu deny-by-default s allowlistom a logovaním na gateway, jeden service account pre každú dvojicu agenta a nástroja namiesto zdieľaných účtov a spätné naviazanie každého volania na identitu používateľa cez token-exchange reťazec. Observability na úrovni siete 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 mu na to poskytuje telemetrický základ. Konkrétnej tokenovej ekonomike a modelovaniu nákladov sa zase venuje pilier FinOps.

Pre agentúry a B2B rozhodovateľov

Pre marketingové agentúry, ktoré stavajú agentské workflowy pre klientov, je observability tou súčasťou dodávky, ktorá oddeľuje pilot od auditovateľného produkčného systému: až trace, evaly a backend v súlade s pravidlami EÚ robia agenta prevádzkovateľným, fakturovateľným a obhájiteľným z hľadiska ochrany údajov klienta. Pre B2B rozhodovateľov v regióne DACH platí: vyber observability backend rovnako vedome ako cloudový región. Self-hosted Langfuse, Datadog EU alebo Honeycomb EU držia prompty a odpovede v priestore EÚ a tracing cez OpenTelemetry nezávislý od dodávateľa chráni pred lock-inom. Blck Alpaca z Viedne navrhuje a prevádzkuje agentskú infraštruktúru s touto observability vrstvou od začiatku: vrátane tracingu, eval harness a backendu v súlade s GDPR. Ozvi sa nám, ak chceš agenta previesť z pilotného stavu do auditovateľnej produkčnej prevádzky.