Monitoring a logování

Co zapisovat u každého volání AI, jak to skloubit s ochranou osobních údajů, jak sledovat vícekrokové agenty, které signály hlídat, jak vybírat odpovědi k lidské kontrole a co dělat, když se k zákazníkovi dostane špatná odpověď. A proč se AI může změnit, i když jsi na nic nesáhl.

Pondělí ráno, volá rozčílený zákazník. Váš chatbot mu v sobotu napsal, že objednávku může vrátit do šedesáti dnů, ale ve skutečnosti je lhůta třicet dní. Teď se zeptá: „Tak jak to tedy je?“ A ty potřebuješ vědět, co přesně chatbot napsal, proč to napsal a jestli to samé neřekl dalším stovkám lidí. Bez záznamů na to nemáš odpověď. Máš jen jeho slovo proti „systému, který většinou funguje“.

V předchozích lekcích ses naučil měřit kvalitu odpovědí a sestavit testovací sadu. To je kontrola před spuštěním. Tahle lekce je o tom, co se děje po něm: co si zapisovat, co sledovat, jak poznat, že se něco zhoršuje, a co dělat, když se něco pokazí.

Proč AI potřebuje jiný dohled než běžný software

Běžný software selhává většinou hlasitě. Spadne, vypíše chybu, stránka se nenačte. Správci serverů proto odedávna sledují pár základních veličin. Inženýři z Googlu je v knize o provozu velkých systémů nazvali „čtyři zlaté signály“: jak dlouho trvá odpověď, kolik je požadavků, kolik z nich skončí chybou a jak moc je systém vytížený.

Tohle všechno platí i pro AI. Jenže AI má navíc nepříjemnou vlastnost: nejčastěji selhává potichu. Model vrátí plynulou, zdvořilou odpověď, technicky je všechno v pořádku, a přesto je obsah špatně. Z pohledu serveru proběhl úspěšný požadavek. Z pohledu zákazníka dostal chybnou informaci. Proto k technickým signálům musíš přidat ještě jednu vrstvu: sledování kvality obsahu.

Druhý rozdíl: běžný program na stejný vstup odpoví vždy stejně. Model ne (proč, vysvětluje lekce Předpověď dalšího slova a teplota). Když chceš chybu později pochopit, nestačí si zapsat, na co se uživatel ptal. Musíš si zapsat i to, co přesně model dostal a co odpověděl.

Monitoring(monitoring): Průběžné sledování toho, jak systém v provozu funguje: technické ukazatele (chyby, rychlost, náklady) i kvalita výstupů. Cílem je všimnout si problému dřív, než ho nahlásí zákazník.

Log(log): Záznam o jedné události v systému, například o jednom volání modelu: kdy proběhlo, co do něj vstoupilo, co z něj vyšlo a kolik to stálo. Souhrn logů je surovina, ze které se monitoring počítá.

Co zapisovat u každého volání AI

Představ si, že se za tři týdny vracíš k jedné konkrétní odpovědi a chceš ji přesně zrekonstruovat. Co k tomu potřebuješ? Tahle tabulka je dobrý výchozí seznam:

Co zapsat	Proč to potřebuješ
Vstup uživatele	Bez něj nevíš, na co model odpovídal.
Dohledaný kontext (u RAG: které dokumenty a pasáže model dostal)	Většina „špatných odpovědí“ v RAG systému vzniká tím, že model dostal špatný nebo zastaralý dokument. Bez tohoto záznamu nepoznáš, jestli chyboval model, nebo vyhledávání.
Výstup modelu	Přesně to, co odešlo uživateli, ne jen „odpověď proběhla“.
Model a jeho verze	Abys poznal, jestli se problém objevil po výměně modelu.
Verze promptu (systémových pokynů)	Prompty se upravují často. Bez čísla verze nezjistíš, která úprava co rozbila.
Tokeny vstupu a výstupu	Z nich se počítá cena a dají se z nich vyčíst anomálie (náhle obří kontext).
Doba odezvy	Pomalé odpovědi uživatelé opouštějí.
Cena volání	Aby se náklady daly sečíst po funkcích, zákaznících nebo dnech.
Volání nástrojů (co model spustil, s jakými parametry, co se vrátilo)	U systémů, které jednají, je tohle to nejdůležitější: ne co model řekl, ale co udělal.
Zpětná vazba uživatele (palec nahoru/dolů, komentář, předání člověku)	Nejlevnější signál kvality, jaký máš.
Identifikátor konverzace a času	Aby šlo jednotlivé záznamy poskládat do celého rozhovoru.

O RAG a volání nástrojů jsi četl v kurzu o stavbě AI aplikací (RAG v praxi, Volání nástrojů). Tady stačí jedna věc: čím víc kroků systém má, tím víc míst, kde se může pokazit, a tím víc potřebuješ vidět každý z nich.

Logy a osobní údaje: dobře zapsat, ale ne všechno navždy

Tady narážíš na skutečný střet. Pro ladění bys chtěl mít uložené všechno, doslova. Jenže lidé do chatbotů píšou jména, adresy, čísla smluv, zdravotní potíže, stížnosti na kolegy. Každý log s takovým obsahem je zpracování osobních údajů, se všemi povinnostmi, které z toho plynou. A databáze plná doslovných konverzací je přesně ten typ souboru, jehož únik by byl velmi nepříjemný.

Podrobně se právní stránce věnuje lekce Osobní údaje a AI. Pro provoz z ní plynou čtyři praktické zásady:

Minimalizace. Zapisuj jen to, co opravdu k něčemu použiješ. Technické údaje (tokeny, doba, cena, verze) obvykle osobní údaje neobsahují, a ty klidně ukládej dlouho. Plné texty konverzací potřebuješ výrazně kratší dobu.
Doba uchování. Stanov ji předem a dodržuj ji automaticky (například: plné texty X dní, pak se smažou nebo anonymizují; souhrnné statistiky déle). Konkrétní lhůtu urči s pověřencem pro ochranu osobních údajů nebo právníkem, žádné univerzální číslo neexistuje.
Maskování. Před uložením můžeš nechat automaticky nahradit zjevné osobní údaje zástupnými značkami ([JMÉNO], [TELEFON], [RODNÉ_ČÍSLO]). Nástroje na to existují, ale žádný není dokonalý. Ber to jako snížení rizika, ne jako jeho odstranění.
Přístup. Ne každý, kdo potřebuje vidět graf nákladů, potřebuje číst konverzace zákazníků. Odděl technické přehledy od plných textů a přístup k textům omez na pár lidí.

Agenti: od jednotlivých záznamů k trasování

U jednoduchého chatbota je jedna otázka rovna jednomu volání modelu. U agenta je to jinak. Na jeden pokyn („vyřiď reklamaci“) může proběhnout deset kroků: model si rozmyslí postup, vyhledá objednávku, přečte podmínky, zeptá se jiného systému na stav zásilky, napíše návrh odpovědi, zkontroluje ho. Když je výsledek špatně, potřebuješ zjistit, ve kterém kroku se to zvrtlo.

Trasování(tracing): Způsob záznamu, kdy se všechny kroky jednoho úkolu (volání modelu, volání nástrojů, vyhledávání) zapisují jako propojený strom s časovou osou. Celý úkol je jedna stopa (trace), každý krok v ní je úsek (span).

Z trasování vyčteš i věci, které v jednotlivých logech zapadnou. Typicky smyčky: agent opakovaně volá tentýž nástroj, protože nerozumí odpovědi, a každé kolo stojí peníze. Nebo pomalý krok: celý úkol trvá dvacet vteřin, ale osmnáct z nich čeká na jeden pomalý interní systém, za který model nemůže.

Do hloubkyStandard pro záznam AI volání: OpenTelemetry

Ve světě běžného softwaru se pro logy, metriky a trasování prosadil otevřený standard OpenTelemetry. Pro generativní AI v jeho rámci vzniká sada takzvaných sémantických konvencí: dohoda, jak pojmenovat údaje jako použitý model, počty tokenů vstupu a výstupu nebo kroky agenta, aby jim rozuměly různé nástroje. Konvence pokrývají volání modelů, kroky agentů, metriky, události i protokol MCP a mají samostatné části pro jednotlivé dodavatele.

Pro tebe z toho plyne praktická rada: při výběru nástroje na sledování AI se zeptej, jestli podporuje OpenTelemetry. Když ano, nejsi zamčený u jednoho dodavatele a záznamy můžeš později poslat jinam. Konvence se v době psaní stále vyvíjejí, takže aktuální stav ověř v jejich repozitáři (odkaz je v Zdrojích).

Které signály sledovat

Logy jsou surovina. Monitoring z nich dělá přehled, na který se díváš denně nebo týdně, a upozornění, která tě vzbudí, když se něco děje. Tady jsou signály, které se u AI systémů osvědčují:

Signál	Co ti říká
Míra technických chyb (vypršení času, chyby API, překročené limity)	Jestli systém vůbec funguje. Výpadek dodavatele se projeví tady.
Míra odmítnutí (model odpoví „s tím vám nemohu pomoci“)	Náhlý nárůst často znamená změnu modelu nebo promptu, která ho udělala přehnaně opatrným. Náhlý pokles může znamenat opak.
Doba odezvy (průměr i ty nejpomalejší odpovědi)	Průměr skrývá problémy. Sleduj i nejpomalejších pár procent, tam se ztrácejí uživatelé.
Cena za požadavek a za den	Nejrychlejší detektor smyček, obřího kontextu a zneužití.
Palce dolů a negativní komentáře	Přímý hlas uživatelů. Málokdo hlasuje, takže jde o malý vzorek, ale jeho změna v čase je cenná.
Předání člověku (eskalace na operátora)	Kolikrát AI nezvládla úkol. Rostoucí podíl je varování.
Změny v chování uživatelů (nová témata, delší dotazy, jiný jazyk)	Svět se mění. Testovací sada z jara nemusí pokrývat podzimní otázky.

U každého signálu je důležitější změna než absolutní hodnota. Neexistuje správná „míra palců dolů“. Existuje ale tvůj normál a odchylka od něj. Nastav si upozornění na výrazný skok proti běžnému týdnu, ne na číslo, které sis vymyslel.

Posun(drift): Postupná změna podmínek, ve kterých AI pracuje: lidé se ptají na jiné věci, jinými slovy, s jinými očekáváními. Model a prompt zůstaly stejné, ale svět kolem nich se posunul, a kvalita proto může klesat.

Vzorkování: lidské oči na náhodný výběr

Signály ti řeknou, že se něco děje. Co se děje, ti řekne až člověk, který si odpovědi přečte. Číst všechny nejde, a tak se čte vzorek. Osvědčuje se kombinace dvou druhů:

Náhodný vzorek. Třeba několik desítek konverzací týdně, vybraných opravdu náhodně. Jen tak uvidíš problémy, o kterých nevíš, že je máš. Uživatel, který dostal chybnou odpověď a uvěřil jí, palec dolů nedá.
Cílený vzorek. Konverzace s palcem dolů, s předáním člověku, nezvykle dlouhé, nezvykle drahé, s odmítnutím. Tady najdeš nejvíc chyb na hodinu práce.

Hodnoť podle stejných kritérií (rubriky), jaká sis nastavil při měření kvality, aby čísla z provozu byla srovnatelná s čísly z testů. Část práce může udělat i hodnoticí model, ale lidský vzorek bys neměl vypustit: je to kalibrace, podle které poznáš, jestli hodnoticímu modelu můžeš dál věřit.

A nejdůležitější krok: každá zajímavá chyba z provozu se stává novým testem. Přidej ji do testovací sady i se správnou odpovědí. Testovací sada tak roste z reálných případů, a ne z toho, co sis kdysi u stolu představoval.

Když se špatná odpověď dostane k zákazníkovi

Dřív nebo později se to stane. Pomáhá mít postup připravený předem, protože pod tlakem se špatně vymýšlí. Vrať se k pondělnímu příkladu ze začátku:

Incident: chatbot slíbil 60 dní na vrácení místo 30

Zastav škody. Odpověz zákazníkovi a rozhodni, jak se zachováte (firma za odpovědi svého chatbota odpovídá, viz případ Air Canada v lekci Jak výstupy ověřovat). Pokud chyba může pokračovat, dočasně omez téma: chatbot u dotazů na vrácení odkáže na stránku s podmínkami nebo na člověka.
Zjisti rozsah. V logech vyhledej všechny odpovědi, které zmiňují lhůtu vrácení. Kolik jich bylo? Od kdy? Tady se ukáže, jestli máš logy v pořádku.
Najdi příčinu. Podívej se do záznamu dohledaného kontextu. Dostal model starou verzi obchodních podmínek, kde opravdu stálo 60 dní? Pak je chyba ve správě dokumentů, ne v modelu. Nebo dostal správný dokument a číslo si vymyslel? Pak jde o prompt nebo model.
Oprav a ověř. Oprav příčinu (vyřaď starý dokument, uprav prompt) a spusť testovací sadu, ať oprava nerozbila něco jiného.
Přidej test. Otázka na lhůtu vrácení i se správnou odpovědí patří od teď do testovací sady.
Informuj dotčené. Pokud stejnou chybnou informaci dostali další zákazníci, rozhodněte, jestli je oslovit. To je obchodní a někdy i právní rozhodnutí, ne technické.
Krátký rozbor bez hledání viníka. Co se stalo, proč to nikdo nezachytil dřív, co změníte. Cílem je opravit systém, ne potrestat člověka.

Všimni si, kolik z těchto kroků stojí na logech. Bez záznamu dohledaného kontextu by ses v kroku 3 jen dohadoval. Bez záznamů výstupů bys v kroku 2 nevěděl, jestli jde o jednoho zákazníka, nebo o tisíc.

Tichá změna: když se AI změní, i když jsi na nic nesáhl

Tohle je specifická past AI v provozu. Používáš model od dodavatele a ten ho může vyměnit, upravit nebo ukončit. Tvůj systém pak začne odpovídat jinak, i když jsi ve svém kódu nezměnil ani čárku.

Že nejde o teorii, ukázala v roce 2023 studie výzkumníků ze Stanfordu a Berkeley. Porovnali březnovou a červnovou verzi GPT-3.5 a GPT-4 na několika typech úloh. U některých se výkon výrazně zhoršil (u úlohy poznat, jestli je číslo prvočíslo, klesla úspěšnost GPT-4 z 84 % na 51 %), u jiných zlepšil. Závěr autorů: chování „stejného“ modelu se může během pár měsíců podstatně změnit, a proto je potřeba ho průběžně sledovat.

Jak se proti tomu bránit:

Připni si verzi, kde to jde. Dodavatelé přes API obvykle nabízejí konkrétní, neměnné verze modelu (snapshoty) a vedle nich přezdívky, které se mohou časem přesunout na novější verzi. Pro ostrý provoz chceš konkrétní verzi. Jak přesně to konkrétní dodavatel dělá, ověř v jeho dokumentaci, liší se to. Pozor: v chatovacích aplikacích typu ChatGPT nebo Claude.ai verzi obvykle připnout nejde, tam se model mění podle dodavatele.
Sleduj oznámení o ukončení. Každá verze má omezenou životnost. Dodavatelé zveřejňují plán ukončení a s předstihem upozorňují e-mailem. V době psaní například Anthropic slibuje u veřejně vydaných modelů nejméně 60 dní předem a OpenAI u běžně dostupných modelů nejméně šest měsíců. Lhůty se mohou změnit, takže je ověř na stránkách dodavatelů. Datum ukončení si zapiš do kalendáře hned, jak model nasadíš.
Každá výměna modelu je změna jako každá jiná. Než přejdeš na novou verzi, spusť na ní testovací sadu a porovnej výsledky se starou. Po přechodu sleduj signály z předchozí kapitoly pozorněji než obvykle.
Pozor i na náklady. Nová verze může stejný text rozdělit na jiný počet tokenů. Anthropic například v době psaní uvádí, že tokenizér jeho novějších modelů vytvoří ze stejného textu zhruba o 30 % víc tokenů. Při stejné ceně za token tedy zaplatíš víc. Proto patří do monitoringu i cena za požadavek.

Kdo to má na starosti

Monitoring, který nikdo nesleduje, je jen drahé úložiště. U každého AI systému v provozu by mělo být jasné, kdo se dívá na přehled (třeba jednou týdně), kdo čte vzorek odpovědí, kdo dostává upozornění a kdo smí v případě incidentu systém omezit nebo vypnout. Často to nejsou titíž lidé: technické signály hlídá vývojář, obsah odpovědí člověk, který rozumí oboru. Jak tyhle role zapadají do řízení AI v celé firmě, probírá lekce Škálování a governance. Bezpečnostní stránku (co když se někdo pokusí systém zneužít) najdeš v lekcích Prompt injection a únik dat a Oprávnění a lidská kontrola.

Co si odnést

AI selhává hlavně potichu: technicky v pořádku, obsahově špatně. K běžným signálům (chyby, rychlost, vytížení) proto přidej sledování kvality obsahu.
U každého volání zapisuj vstup, dohledaný kontext, výstup, model a verzi, verzi promptu, tokeny, dobu, cenu, volání nástrojů a zpětnou vazbu. U agentů používej trasování, abys viděl každý krok.
Logy s texty konverzací jsou osobní údaje: zapisuj jen potřebné, stanov dobu uchování, maskuj, omez přístup. Technické údaje můžeš držet déle než plné texty.
Sleduj změny proti svému normálu, ne absolutní čísla. Čti náhodný i cílený vzorek odpovědí a každou zajímavou chybu přidej do testovací sady.
Na incident měj postup předem: zastav škody, zjisti rozsah z logů, najdi příčinu, oprav, přidej test, rozhodni o informování dotčených.
Model se může změnit bez tvého zásahu. Připni verzi, kde to jde, hlídej data ukončení a každou výměnu modelu pusť přes testovací sadu.

Zdroje a další čtení

Google SRE Book: Monitoring Distributed Systems – kapitola o čtyřech zlatých signálech, základ monitoringu běžného softwaru.
Chen, Zaharia, Zou: How is ChatGPT's behavior changing over time? (arXiv, 2023) – studie, která ukázala, jak se chování „stejného“ modelu změnilo během tří měsíců.
OpenTelemetry: Semantic Conventions for Generative AI (GitHub) – vznikající standard pro záznam volání modelů a kroků agentů.
Anthropic: Model deprecations – příklad, jak dodavatel popisuje životní cyklus modelů a lhůty před jejich ukončením.
OpenAI: Deprecations – plán ukončení modelů a minimální lhůty upozornění u OpenAI.