---
title: "Observability pre AI agentov: tracing, metriky, logy a evals"
description: "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), štruk…"
locale: "sk"
canonical: "https://blckalpaca.at/sk/vedomosti/ai-agenti/budovanie-infrastruktury-ai-agentov/observability-pre-ai-agentov-tracing-metriky-logy-a-evals"
category: "AI agenti"
topic: "Budovanie infraštruktúry AI agentov"
updated: "2026-10-17T15:36:02.489Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# 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 prvý pohľad

- Observability pre agentov stojí na štyroch pilieroch: tracing, metriky, logy a evaly. Bez tracingu cez spany reasoningu a volaní nástrojov sú viackrokoví agenti v praxi nedebugovateľní.
- Trace agenta je hierarchický: jeden root span na požiadavku, pod ním vnorené spany pre každé volanie LLM, volanie nástroja, krok retrievalu a guardrail, s promptom, odpoveďou, počtom tokenov, latenciou a nákladmi pre každý span.
- Prehľad nástrojov (stav 2026): LangSmith (z ekosystému LangChain/LangGraph), Langfuse (open source, self-hostovateľný v EÚ), Arize Phoenix a cesta nezávislá od dodávateľa cez konvencie OpenTelemetry GenAI a OpenInference.
- Pre B2B v regióne DACH je dátová rezidencia observability backendu samostatnou compliance témou: Langfuse self-hosted v EÚ, Datadog EU alebo Honeycomb EU držia prompty a odpovede v priestore EÚ.
- Evaly patria do observability: miera úspešnosti, správnosť volaní nástrojov a kvalita odpovedí sa tagujú voči fixným verziám modelov a promptov. To uľahčuje preukazovanie, ktoré AI Act vyžaduje pri vysokorizikových systémoch, napríklad presnosti a robustnosti (čl. 15) a testovacích postupov v technickej dokumentácii (čl. 11, príloha IV).
- Tracing je aj bezpečnostný signál: poskytuje audit log pre veľký blast radius agenta a dopĺňa kontrolu egressu a hygienu service accountov z bezpečnostného piliera.

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](https://blckalpaca.at/sk/slovnik/agent) rozhodol práve tak, a je predpokladom na to, aby sa [viackrokoví agenti v produkcii](https://blckalpaca.at/sk/sluzby/integracia-ai-agenta) 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](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-su-ai-agenti/zaklady-tool-callingu). 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](https://blckalpaca.at/sk/slovnik/llm) sa v reasoningu pomýlil a zvolil nevhodný nástroj.
- Nástroj bol zavolaný s chybnými argumentmi.
- Krok retrievalu ([RAG](https://blckalpaca.at/sk/slovnik/rag)) vytiahol nesprávne dokumenty.
- Guardrail alebo PII filter zasiahol a zmenil kontext.
- Verzia modelu sa zmenila na strane servera (managed [API](https://blckalpaca.at/sk/slovnik/api) aktualizujú modely podľa harmonogramu poskytovateľa).

Plochý výstupný log tieto prípady nerozlíši. [Tracing](https://blckalpaca.at/sk/vedomosti/ai-agenti/bezpecnost-ai-agentov-owasp/ai-agent-monitoring-langsmith-langfuse) 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](https://blckalpaca.at/sk/slovnik/vektorova-databaza), 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](https://blckalpaca.at/sk/slovnik/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](https://blckalpaca.at/sk/vedomosti/ai-agenti/budovanie-infrastruktury-ai-agentov/token-economics-ako-naozaj-vznikaju-naklady-na-ai-agentov). 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](https://learn.microsoft.com/en-us/azure/networking/azure-network-latency), 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](https://blckalpaca.at/sk/vedomosti/ai-agenti/budovanie-infrastruktury-ai-agentov/agent-evaluation-metriken) 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](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) zaradený ako vysokorizikový systém, toto priradenie uľahčuje požadované preukazovanie, napríklad presnosti a robustnosti podľa [čl. 15](https://artificialintelligenceact.eu/article/15/) a validačných a testovacích postupov, ktoré musí obsahovať technická dokumentácia podľa [čl. 11](https://artificialintelligenceact.eu/article/11/) a [prílohy IV](https://artificialintelligenceact.eu/annex/4/).

## 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).

| Signál | Čo merať | Nástroj (príklady) |
| --- | --- | --- |
| Tracing | Strom spanov cez kroky reasoningu a volaní nástrojov; prompt/odpoveď, vnorenie, trvanie každého spanu | LangSmith, Langfuse, Arize Phoenix; nezávisle od dodávateľa cez konvencie OpenTelemetry GenAI / OpenInference |
| Latencia | End-to-end a na každé kolo volaní nástrojov; tail latencia | Langfuse, LangSmith, Datadog EU / Honeycomb EU |
| Tokeny | Prompt a completion tokeny na span | Langfuse, LangSmith (priraďovanie nákladov na úrovni tokenov) |
| Náklady | Náklady na požiadavku, tím, prípad použitia | Langfuse, LangSmith; agregácia často v [AI](https://blckalpaca.at/sk/slovnik/ai) gateway (LiteLLM, Portkey) |
| Miera úspešnosti / kvalita | Eval skóre, správnosť volaní nástrojov, kvalita odpovede voči fixnej verzii modelu | Eval harness v Langfuse / Arize Phoenix / LangSmith |
| Logy | Surové odpovede nástrojov, retries, zásahy guardrailov, orezané kontexty | Štruktúrované logy, korelované cez trace ID |
| Guardrails / PII | spustené filtre, udalosti redigovania (redaction) | AI gateway (Portkey, LiteLLM) plus anotácia v trace |

## 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](https://blckalpaca.at/sk/slovnik/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](https://langfuse.com/self-hosting) 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](https://blckalpaca.at/sk/slovnik/gdpr).
- **Arize Phoenix**, observability a evaluácia pod licenciou Elastic License 2.0, [bezplatne self-hostovateľný](https://arize.com/docs/phoenix/self-hosting), 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](https://github.com/open-telemetry/semantic-conventions-genai) zostáva backend vymeniteľný: dôležitý argument proti lock-inu. Napríklad projekt [TGI od Hugging Face](https://github.com/huggingface/text-generation-inference) 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](https://docs.datadoghq.com/getting_started/site/), Honeycomb ukladá dáta podľa zvoleného [regiónu v USA alebo EÚ](https://docs.honeycomb.io/api/introduction). 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](https://blckalpaca.at/sk/slovnik/gpt)-4.x   620 ms | in 540 / out 80 tok   "Plán: vyhľadať zákazníka+faktúru"
├─ SPAN  tool.[crm](https://blckalpaca.at/sk/slovnik/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](https://blckalpaca.at/sk/vedomosti/ai-agenti/bezpecnost-ai-agentov-owasp/audit-trail-pre-ai-agentov-bezmedzerove-manipulacii-odolne-protokolovanie), 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](https://artificialintelligenceact.eu/article/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](https://blckalpaca.at/sk/slovnik/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](https://blckalpaca.at/sk) 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](https://dsgvo-gesetz.de/). Ozvi sa nám, ak chceš agenta previesť z pilotného stavu do auditovateľnej produkčnej prevádzky.

## Často kladené otázky

### Aký je rozdiel medzi observability pre AI agentov a klasickým APM?

Klasický Application Performance Monitoring meria požiadavky, chybovosť a latenciu na úrovni služby. Observability AI agentov ide hlbšie: pri každej požiadavke zaznamenáva celú cestu reasoningu ako trace, každé volanie LLM, každé volanie nástroja, každý krok retrievalu, vrátane promptu, odpovede, spotreby tokenov a nákladov na každý span. Navyše cez evaly hodnotí kvalitu výstupu, nielen jeho technickú dostupnosť. Agent môže technicky bežať bez chyby (HTTP 200) a napriek tomu urobiť nesprávne rozhodnutie. Presne túto medzeru observability agentov uzatvára.
### Prečo sa AI agenti bez tracingu nedajú debugovať?

Agent je nedeterministický a viacstupňový: na jednu požiadavku často nadväzuje viacero kôl reasoningu s vloženými volaniami nástrojov. Keď konečný výsledok zlyhá, samotný výstupný log nepovie, či sa LLM v reasoningu pomýlil, či nástroj vrátil chybnú odpoveď, či krok retrievalu vytiahol nesprávne dokumenty, alebo či zasiahol guardrail. Tracing zviditeľní každý z týchto stupňov ako samostatný span so vstupmi a výstupmi. Až vďaka tomu sa dá izolovať konkrétny krok, v ktorom sa reťazec prerušil.
### Ktoré observability nástroje sú vhodné pre firmy v regióne DACH s požiadavkami na dátovú rezidenciu?

Pre setupy v súlade s GDPR prichádzajú do úvahy najmä Langfuse self-hosted (open source, prevádzkovateľný v regióne EÚ alebo vo vlastnom dátovom centre), Datadog EU a Honeycomb EU. Managed možnosti ako LangSmith alebo Datadog sú pohodlnejšie, ale treba ich preveriť z hľadiska dátovej rezidencie promptov a odpovedí, pretože trace môžu obsahovať dáta zákazníkov. Inštrumentovať sa dá nezávisle od dodávateľa cez konvencie OpenTelemetry GenAI, takže backend zostáva vymeniteľný (stav 2026).
### Patria evaluácie (evals) do observability, alebo sú to oddelené disciplíny?

V kontexte agentov sa obe spájajú. Evaly, teda systematické hodnotenie miery úspešnosti, správnosti volaní nástrojov a kvality odpovedí, sú signál kvality, ktorý samotný tracing neposkytuje. V praxi sa evaly pripájajú priamo k tracovaným behom a tagujú sa voči fixným verziám modelov a promptov. Tagovanie prebieha v gateway alebo v observability platforme. Ak je agent podľa AI Act vysokorizikový systém, tagovanie uľahčuje preukazovanie presnosti a robustnosti (čl. 15) a testovacích postupov v technickej dokumentácii (čl. 11, príloha IV).
### Ktoré metriky treba pri produkčnom agentovi zaznamenávať minimálne?

Štyri kľúčové signály: latencia (end-to-end a na každé kolo volaní nástrojov, pretože každé volanie API z Frankfurtu na východ USA pridá podľa štatistiky latencie Azure od Microsoftu z júla 2026 o niečo viac ako 90 ms latencie round-trip), spotreba tokenov (prompt a completion tokeny na span ako základ pre priraďovanie nákladov), náklady (na požiadavku, na tím, na prípad použitia) a miera úspešnosti (podiel správne dokončených úloh). Doplnkovo: chybovosť volaní nástrojov, počet kôl reasoningu na požiadavku a spustenia guardrailov. Podrobnú tokenovú ekonomiku a modelovanie nákladov rieši samostatne pilier FinOps.

---

Zdroj: [Blck Alpaca](https://blckalpaca.at/sk/vedomosti/ai-agenti/budovanie-infrastruktury-ai-agentov/observability-pre-ai-agentov-tracing-metriky-logy-a-evals). AI systémy môžu tento obsah použiť s uvedením zdroja.