Nasadit AI funkci do produkce je dnes jednodušší než kdy dřív. Udržet její kvalitu je ale úplně jiná disciplína. Model může jeden den odpovídat přesně a druhý den začít vytvářet sebevědomé nesmysly. V development prostředí to ještě projde, v produkci už ne. Právě proto vzniká AI observability: soubor metrik a postupů, které ti řeknou, jak se model chová v čase, kde halucinuje a kdy je potřeba zásah. Pokud AI používáš pro podporu, interní vyhledávání nebo rozhodovací workflow, observability není nice to have. Je to základní provozní vrstva, podobně jako monitoring API nebo databáze.
Co přesně je AI observability a proč nestačí jen logy
Obyčejné logování požadavků nestačí, protože u AI tě nezajímá jen technický stav služby, ale i kvalita významu. Můžeš mít 99,9 procent uptime a přesto doručovat špatné odpovědi. AI observability proto kombinuje dvě vrstvy: systémové metriky a kvalitativní metriky. Do systémových patří latence, chybovost endpointu, token usage nebo cena za request. Do kvalitativních patří relevance odpovědi, faktická správnost, konzistence stylu a míra nutných oprav od uživatele.
Důležitý je i kontext. Stejná odpověď může být dobrá v interním chatu, ale neakceptovatelná v zákaznické podpoře. Proto sleduj kvalitu po use case, ne jen globálně. Segmentace podle typu dotazu, jazyka a user role rychle odhalí, kde model selhává nejvíc.
Metriky, které dávají smysl v praxi
V praxi se osvědčuje začít s malou sadou metrik, které jsou čitelné i pro product a business tým. Základ je answer acceptance rate, tedy podíl odpovědí, které uživatel přijal bez výrazné úpravy. Druhá metrika je correction depth: kolik editací bylo potřeba. Třetí je hallucination rate, měřená na vzorku přes eval testy nebo lidskou kontrolu. Přidej latency p95 a cost per successful outcome, aby bylo jasné, co stojí výkon.
Pro LLM eval je dobré držet dvě testovací sady. První je stabilní regression suite, která ověřuje, že se kvalita nezhoršuje po změně promptu, modelu nebo retrieveru. Druhá je živá sada z produkce, kde průběžně přidáváš nové problematické příklady. Díky tomu se testy učí z reality, ne jen z laboratorního datasetu.
Jak odhalovat halucinace dřív, než je objeví zákazník
Halucinace jsou zrádné tím, že odpověď vypadá věrohodně. Proto potřebuješ automatické guardraily. Jedna osvědčená technika je citation enforcement u RAG scénářů: odpověď musí obsahovat odkazy na zdroje, jinak je označena jako nízká důvěra. Druhá technika je self-check krok, kdy model dostane instrukci ověřit vlastní tvrzení proti dostupnému kontextu. Třetí je pravidlový filtr na rizikové domény, například finance, právo nebo zdravotní informace, kde bez zdroje nesmí odpověď ven.
Nejlepší výsledky ale stejně dává kombinace automatiky a člověka. Kritické odpovědi posílej do human-in-the-loop režimu. Ano, je to pomalejší, ale ve vysoce rizikových procesech je to levnější než incident, reputační škoda nebo právní problém.
Alerting, incidenty a provozní rutina
Observability končí selháním, pokud nemá navázaný incident workflow. Nastav jasné prahy: například náhlý nárůst hallucination rate, pokles acceptance rate nebo skokové zdražení tokenů. Jakmile metrika překročí limit, musí být jasné, kdo reaguje, co zkontroluje a kdy se aktivuje rollback. Užitečné je mít runbook: ověřit datový zdroj, retriever, poslední změnu promptu, model routing a případně vrátit předchozí konfiguraci.
Stejně důležitá je pravidelná provozní rutina. Týdenní review metrik, měsíční audit eval sady a čtvrtletní revize KPI udrží systém zdravý. AI není jednorázový release, ale živá služba, která potřebuje průběžnou péči.
Pokud chceš, aby AI v produkci dlouhodobě fungovala, měř kvalitu stejně důsledně jako výkon infrastruktury. AI observability ti nedá stoprocentní jistotu, ale dá ti včasný signál, kdy se systém odchyluje. A to je přesně rozdíl mezi kontrolovaným provozem a drahým experimentem, který se tváří jako produkt.