Dostali sme hovor od klienta z logistiky: agent, ktorý mal automatizovať rezervácie prepravy, začal opakovane vyberať drahšieho dopravcu namiesto lacnejšieho. Rozdiel v cene bol viditeľný — príčina nie. Logy ukazovali vstupy a výstupy. Neukazovali, prečo agent v konkrétnom kroku zavolal nástroj s parametrami, ktoré zavolal. Trvalo nám štyri hodiny, kým sme zrekonštruovali sekvenciu rozhodnutí zo surovýchých logov. Problém sa dal opraviť za pätnásť minút — ale iba vtedy, keď sme vedeli, kde hľadať.
Toto je problém, ktorý sa opakuje vo väčšine prvých produkčných nasadení agentov. Tímy vedia postaviť agenta, vedia ho spustiť, ale nevedia ho debugovať. Observability — schopnosť porozumieť internému stavu systému z jeho externých výstupov — nie je pre agentov luxus. Je to podmienka toho, aby ste mohli systém udržiavať a zlepšovať.
Eval vs. observability: dve odlišné veci
Skôr než sa dostaneme k nástrojom a prístupu, je dôležité rozlíšiť dve veci, ktoré sa často zamieňajú.
Eval (evaluácia) odpovedá na otázku: *je kvalita výstupu agenta dostatočná?* Meria sa offline alebo na historických dátach — napríklad: mal agent pravdu v 87 % prípadov? Generoval správny formát? Zodpovedal správne otázky?
Observability odpovedá na otázku: *čo sa presne stalo počas jedného behu?* Meria sa za runtime — keď agent beží alebo keď beh dobehnul — a zachytáva sekvenciu rozhodnutí, volaní nástrojov, medzistav a chyby.
Eval je retrospektívna štatistika. Observability je chirurgický nástroj na konkrétny incident. Obe sú potrebné — navzájom sa neduplikujú.
Väčšina tímov začína s eval a observability ignoruje. V praxi to funguje do prvého produkčného incidentu. Po ňom sa priority obrátia.
Čo musíte zachytávať
Agent nie je jedna funkcia. Je to sieť krokov — každý krok má vstup, výstup, LLM prompt, rozhodnutie, prípadne chybu. Pre každý beh agenta potrebujete vidieť:
- Trace: úplný strom volaní od vstupného promptu po finálnu odpoveď, vrátane všetkých podstromov
- Spans: jednotlivé kroky v rámci trace — každý LLM call, každé volanie nástroja, každý retrieval
- State diff: čo sa zmenilo v internom stave agenta medzi krokmi (kľúčové pri
LangGraph) - Tool calls: presné parametre každého volania nástroja a presný výstup, ktorý nástroj vrátil
- LLM prompts: aký bol skutočný prompt poslaný modelu (nie šablóna — finálny text po interpolácii)
- Tokeny a latencia: počet tokenov per span, čas per span — identifikácia bottleneckov
- Chyby a retry: kde agent zlyhal, koľkokrát opakoval, s akým výsledkom
Každý tento prvok je nevyhnutný. Ak zachytíte len výstup posledného kroku, máte log aplikácie — nie observability agenta.
Prečo klasické logovanie nestačí
Keď vývojári po prvýkrát počujú "observability", väčšinou odpovedajú: "ale veď logujeme". Logujú — ale nie správne pre agentov.
Klasický log je sekvenčný. Záznam po zázname, timestamp, správa. Pre jednoduchú API to stačí. Pre agenta, kde jeden používateľský vstup spustí desiatky LLM volaní, volaní nástrojov a retrieval krokov — v strome, nie v sekvencii — je flat log nepoužiteľný. Nemáte kontext, nemáte hierarchiu, nemáte state v čase.
Ďalší problém: agentné frameworky ako LangGraph internalizujú veľa rozhodnutí. Ktorý node bol vybraný, prečo sa aktivoval konkrétny edge, aký bol state v checkpointe — toto nie je viditeľné z bežného stdout logu. Potrebujete integráciu priamo s frameworkom, nie wrapper okolo neho.
Tretí problém je sampling a cost. Produkčný agent môže spustiť tisíce behov denne. Logovať *všetko* do štruktúrovaného trace je drahé na storage. Potrebujete sampling stratégiu — napríklad 100 % zachytiť chyby a dlhé behy, 10–20 % náhodne vzorkovaných úspešných behov.
Trace: základ observability agenta
Trace je koreňový kontajner jedného behu agenta. Zodpovedá jednej úlohe — napríklad jednej používateľskej požiadavke alebo jednej naplánovanej operácii. Vo vnútri trace sú spans — každý span je jeden krok s metadátami.
Hierarchia vyzerá takto:
- Trace: "Rezervuj prepravu pre objednávku #4821"
- - Span: LLM call — porozumenie požiadavke
- - Span: Tool call —
search_carriers(origin, destination, date) - - Span: Tool call —
get_price(carrier_id=12) - - Span: Tool call —
get_price(carrier_id=17) - - Span: LLM call — rozhodnutie a zdôvodnenie
- - Span: Tool call —
book_shipment(carrier_id, price, ...)
Každý span má: čas začiatku a konca, vstup, výstup, prípadnú chybu, ID rodiča. Z toho vieme rekonštruovať celý priebeh rozhodnutia bez dohadovania.
Vo LangGraph sa tento strom mapuje prirodzene na grafy — každý node v grafe je span. Nástroje ako LangSmith zachytávajú state diff na každom prechode hrany grafu, čo dáva detailný pohľad na vývoj stavu.
ReAct tracing: reason-act-observe v logoch
Keď agent používa ReAct architektúru — Reason, Act, Observe slučku — observability by mala zachytávať každý z týchto krokov explicitne.
Reason krok: čo agent "premýšľal" — chain-of-thought výstup modelu pred volaním nástroja. Toto je najcennejší krok pre debugging. Keď agent zavolá nesprávny nástroj, odpoveď je takmer vždy viditeľná v reason kroku — model sa "rozhodol" nesprávne z dôvodu, ktorý je v texte.
Act krok: presné volanie nástroja s parametrami. Nie šablóna — skutočné hodnoty po interpolácii. Chyby v tool callingu — malformované parametre, nesprávny typ — sú viditeľné tu.
Observe krok: čo nástroj vrátil. Dôležité: raw výstup nástroja pred tým, než ho model spracuje. Keď nástroj vráti neočakávaný formát alebo chybovú hlášku, toto je miesto, kde to uvidíte.
Bez explicitného logovania týchto troch krokov per iterácia máte len finálny výstup. A finálny výstup vám nepovie, prečo agent po tretej iterácii zmenil rozhodnutie.
Metriky, ktoré treba sledovať
Okrem trace per beh potrebujete agregované metriky pre monitoring:
- Latencia p50/p95/p99 — nielen celková latencia behu, ale per-node latencia. Kde trávi agent čas?
- Token consumption per beh — trend, outliers (behy s 10× väčším počtom tokenov = chybový vzor)
- Tool error rate — percento behov kde aspoň jeden tool call zlyhal
- Retry rate — koľko percent behov vyžadovalo retry. Retry rate 12 % a viac zvyčajne signalizuje problém v schema validácii alebo v prompt-e
- Abandonment rate — behy, kde agent nedosiahol cieľ a vrátil fallback odpoveď
- Human escalation rate — pri HITL (human-in-the-loop) systémoch: percento behov eskalovaných na človeka
Každá z týchto metrík má symptomatický charakter. Vysoký retry rate ukazuje na nestabilný tool calling. Vysoká p99 latencia pri nízkej p50 latencii ukazuje na outlier scenáre — pravdepodobne dlhé kontexty alebo retry slučky. Vysoký abandonment rate ukazuje na hraničné prípady, ktoré agent nevie spracovať.
Nástroje: LangSmith, Langfuse, Arize Phoenix
Pre produkčné nasadenie dnes existujú tri hlavné platformy:
`LangSmith` — najhlbšia integrácia s LangGraph a LangChain. Automaticky zachytáva trace, state diff, tokeny, latenciu. Má playground pre replay behov — môžete zobrať konkrétny trace a spustiť ho znova s modifikovaným promptom. Cloud-hosted, s pricing podľa objemu traces. Ak váš stack je LangGraph, LangSmith je prirodzená voľba.
`Langfuse` — framework-agnostický, self-hostable (Postgres + ClickHouse). SDK pre Python, TypeScript, REST. Funguje aj keď nepíšete cez LangGraph — zavoláte SDK priamo pri každom LLM call a tool call. Vhodné pre tímy, ktoré chcú plnú kontrolu nad dátami (regulované odvetvia, on-prem požiadavky). Self-hosting pridáva ops overhead — ClickHouse cluster treba udržiavať.
`Arize Phoenix` — OpenTelemetry-based. Zachytáva traces cez štandardný OTel protokol, čo znamená integráciu s existujúcim monitoring stackom (Prometheus, Grafana, Jaeger). Navyše: 50+ eval metrík priamo v platforme — faithfulness, hallucination detection, relevance. Pre tímy, kde agent observability má byť súčasťou širšieho APM riešenia.
Výber: ak ste na LangGraph v cloude — LangSmith. Ak potrebujete self-hosting alebo máte heterogénny stack — Langfuse. Ak chcete observability aj eval v jednom a máte OTel infraštruktúru — Arize Phoenix.
Pre menšie projekty v ranej fáze: Langfuse self-hosted na jednoduchom Docker Compose stačí a ušetrí náklady.
Replay a debugging konkrétneho incidentu
Observability má najväčšiu hodnotu pri konkrétnom incidente. Postup, ktorý funguje v praxi:
- 1.Identifikujte trace podľa trace ID alebo podľa filtra (napríklad: všetky behy s tool error rate > 0 za posledných 24 hodín)
- 2.Otvorte state diff — pozrite sa, ako sa menil stav agenta krok po kroku. Kde nastala zmena, ktorú ste nečakali?
- 3.Prečítajte reason text v každom LLM call — hľadajte logiku, ktorá odpovedá na "prečo agent urobil toto rozhodnutie"
- 4.Skontrolujte tool výstupy — mohol byť problém v tom, čo nástroj vrátil, nie v tom, čo agent spravil s výstupom?
- 5.Spustite replay s modifikovaným promptom alebo parametrami — overenie hypotézy bez potreby reálneho prostredia
Tento postup skracuje MTTR (mean time to resolution) z hodín na minúty. Zo skúsenosti: väčšina agentných bugov nie je v LLM reasoning — je v tool calling, v neočakávanom formáte výstupu nástroja alebo v state management-e. Observability toto odlíšenie umožní za sekundy.
Alerty a proaktívne sledovanie
Reaktívny debugging je len jedna vrstva. Produkčný systém potrebuje aj proaktívne alerty.
Základné pravidlá pre alerting:
- Tool error rate > 5 % za hodinové okno → alert, pravdepodobná zmena v downstream systéme alebo v schéme nástroja
- Priemerná latencia behu > 2× baseline → alert, outlier scenár alebo upstream spomalenie
- Abandonment rate > 10 % za deň → alert, nové hraničné prípady v produkcii
- Token cost per deň > X EUR — cost alert, nevyhnutný pri agentoch kde looping môže bez limitu generovať volania. Agent bez cost alertu môže cez noc vygenerovať tisíce volaní a účet rádovo v tisícoch eur — riziko, ktoré v praxi vídame
Alerty by mali ísť na trace, nie len na číslo. Keď dostanem alert "tool error rate 8 %", chcem priamo link na trace, kde k tomu došlo — nie číslo bez kontextu.
Observability a náklady agenta
Observability sama osebe generuje náklady — storage pre traces, compute pre analytics. Pre produkčné systémy s veľkým objemom je dôležité nastaviť sampling stratégiu.
Odporúčaný prístup:
- 100 % sampling pre chybové behy (tool error, abandonment, timeout)
- 100 % sampling pre behy s neobvyklou latenciou (p99 outliers)
- 10–20 % sampling pre úspešné behy v rámci normy
- 100 % sampling počas nasadenia novej verzie agenta (prvých 24–48 hodín)
Toto znižuje storage náklady 5–10× pri zachovaní úplnej viditeľnosti pre diagnostiku. Platformy ako Langfuse podporujú sampling rate konfiguráciu natívne.
Súvislosť s nákladmi agenta v produkcii: observability vám umožní identifikovať, ktoré behy sú neefektívne — napríklad behy, kde agent opakovane volá ten istý nástroj kvôli nejasnej odpovedi. Toto je typicky problém v tool calling spoľahlivosti, ktorý observability exponuje skôr, než stihne signifikantne navýšiť náklady.
Bezpečnostná dimenzia tracingu
Traces obsahujú citlivé dáta — prompty, výstupy nástrojov, interný stav agenta. V regulovaných odvetviach (financie, zdravotníctvo, právne) toto vyžaduje:
- Šifrovanie traces at rest a in transit
- Prístupové riadenie — kto môže čítať trace záznamy?
- Retenčná politika — ako dlho uchovávate traces?
- PII scrubbing — osobné údaje v promptoch alebo výstupoch nástrojov nesmú byť uložené v plain text
Self-hosted Langfuse dáva plnú kontrolu nad týmito aspektmi. Cloud platformy musia byť hodnotené voči vašim GDPR/data residency požiadavkám — zvlášť ak traces obsahujú firemné alebo zákaznícke dáta.
Pre on-prem LLM nasadenia je self-hosted observability takmer vždy požiadavka, nie voľba.
Časté otázky
Musím mať observability pred prvým nasadením agenta?
Nie nevyhnutne pred prvým testovacím nasadením — ale áno pred nasadením do produkcie s reálnymi používateľmi alebo reálnymi dátami. Bez observability nemáte spôsob identifikovať, kde agent zlyháva, ani prečo. Prvý produkčný incident, ktorý si vyžaduje debugging bez tracingu, typicky presvedčí tím rýchlejšie ako akýkoľvek argument.
Aký je rozdiel medzi tracingom a štandardným logovaním?
Klasický log je plochá sekvencia záznamov. Tracing zachytáva hierarchický strom — trace obsahuje spans, spans obsahujú child spans. Pre agenta, kde jeden vstup spustí desiatky volaní v strome, je hierarchická štruktúra nevyhnutná. Navyše tracing zachytáva state diff medzi krokmi, čo plochý log neumožňuje.
Funguje observability aj pre agentov nie na LangGraph?
Áno. Langfuse a Arize Phoenix sú framework-agnostické — stačí zavolať SDK pri každom LLM call a tool call. Ak píšete vlastného agenta bez frameworku, môžete pridať OpenTelemetry spans manuálne. LangSmith má najhlbšiu integráciu s LangGraph, ale aj pre iné frameworky existujú integrácie.
Koľko to stojí?
Langfuse self-hosted je zdarma (len ops náklady na infraštruktúru — jednoduchý Docker Compose s Postgres + ClickHouse). LangSmith a Arize Phoenix majú free tier pre nízke objemy, platené plány začínajú rádovo od desiatok eur mesačne. Hlavný náklad nie je platforma — je to storage pre traces, zvlášť pri vysokom objeme behov.
Mám logovať celé LLM prompty?
Áno — s jednou podmienkou: ak prompty obsahujú osobné alebo firemné dáta, musíte riešiť PII scrubbing pred uložením. Logovanie len metadát (token count, latencia, tool name) bez obsahu promptu je lacnejšie, ale výrazne obmedzuje debugovateľnosť. Odporúčame logovať plné prompty s retenčnou politikou a prístupovým riadením.
Záver
*Observability AI agentov nie je o nástrojoch — je o kultúre zodpovednosti za to, čo systém robí v produkcii. Keď agent zlyhá, otázka "prečo" musí mať odpoveď do minút, nie hodín. V MP Industrial Solutions pomáhame tímom nastaviť observability ako súčasť architektúry agentov — nie ako dodatočnú vrstvu. Ak zvažujete nasadenie agenta alebo riešite incident v existujúcom systéme, radi sa pozrieme na váš konkrétny prípad.*