AI observability: Jak sledovat chování systémů AI

Systémy umělé inteligence mohou měnit své výstupy podle vstupních dat, kontextu, použitého modelu i způsobu nasazení. Proto nestačí ověřit jejich funkčnost před spuštěním. Organizace potřebují průběžně zjišťovat, jak se systém chová v reálném provozu, zda poskytuje užitečné a bezpečné výsledky a kolik prostředků jeho provoz spotřebovává. Tento přístup se označuje jako AI observability neboli pozorovatelnost systémů umělé inteligence.

Observability není pouhý přehled o dostupnosti aplikace nebo počtu chyb. Propojuje technická provozní data s informacemi o kvalitě modelových výstupů, použitých datech, uživatelské zkušenosti a nákladech. Díky tomu může organizace odhalit nejen to, že se systém zhoršil, ale také proč k tomu došlo a jaký to má dopad na jeho uživatele i provozovatele.

Co znamená pozorovatelnost systémů AI

V tradičním softwaru se provoz často sleduje prostřednictvím dostupnosti, latence, chybovosti a vytížení infrastruktury. U systémů AI jsou tyto ukazatele stále důležité, samy o sobě však nevypovídají o správnosti či vhodnosti výsledků. Služba může být technicky dostupná a odpovídat rychle, přesto může produkovat zavádějící, nerelevantní nebo nekonzistentní výstupy.

AI observability proto rozšiřuje běžné provozní monitorování o údaje související s chováním modelu a celého procesu, který výstup vytváří. U generativní AI může jít například o záznam zadání, kontextu poskytnutého modelu, verze modelu, použitých nástrojů a výsledné odpovědi. U predikčního modelu může být důležité sledovat vstupní proměnné, predikci, později zjištěný skutečný výsledek a případné změny v rozložení dat.

Rozdíl mezi monitorováním a observability spočívá především v rozsahu pohledu. Monitorování upozorňuje na předem definované odchylky, například na překročení limitu latence. Observability umožňuje spojovat více typů signálů a zpětně zkoumat příčiny neobvyklého chování, včetně situací, které nebylo možné přesně předvídat při návrhu systému.

Co je potřeba sledovat

Rozsah sledování závisí na účelu systému, míře jeho autonomie i možných důsledcích chyb. U interního nástroje pro shrnování dokumentů budou priority jiné než u modelu, který podporuje rozhodování o úvěrovém riziku nebo třídí požadavky zákazníků. Obvykle se vyplatí rozdělit observability do několika oblastí.

Technický provoz: dostupnost, latence, chybovost, kapacita, vytížení výpočetních prostředků a stabilita jednotlivých komponent.
Kvalita výstupů: přesnost, relevance, úplnost, konzistence a míra odpovědí, které neodpovídají zamýšlenému použití.
Vstupní data: změny jejich struktury, rozložení, úplnosti a kvality, stejně jako odchylky od dat, na kterých byl systém ověřen.
Bezpečnost a dodržování pravidel: výskyt nevhodných výstupů, úniků citlivých informací, pokusů o zneužití nebo porušení nastavených omezení.
Náklady: spotřeba výpočetního výkonu, počet volání modelu, využití externích služeb a náklady na kontrolu či opravu výstupů.
Uživatelský dopad: využívání systému, míra přijetí doporučení, počet eskalací k člověku a zpětná vazba uživatelů.

Jednotlivé ukazatele je třeba vykládat v kontextu. Například pokles počtu uživatelských stížností nemusí automaticky znamenat vyšší kvalitu, pokud uživatelé systém přestali používat. Stejně tak změna průměrné délky odpovědi může být žádoucí u jednoho scénáře a nežádoucí u jiného.

Od vstupu k výsledku: sledování celého řetězce

Výstup systému AI často nevzniká jediným krokem. Vstup může projít předzpracováním, vyhledáním relevantních informací, voláním jednoho či více modelů, použitím externích nástrojů a následnou kontrolou. Pokud se sleduje pouze konečná odpověď, bývá obtížné určit, ve které části procesu vznikla chyba nebo zpoždění.

Užitečným základem je proto trasování jednotlivých požadavků. Záznam může spojit původní vstup s verzí modelu, parametry volání, nalezenými dokumenty, výstupy pomocných komponent a konečnou odpovědí. Díky tomu lze například rozlišit, zda nepřesnost způsobil nevhodný dotaz, zastaralý zdrojový dokument, chybný výsledek vyhledávání, nebo samotné generování.

Trasování však nesmí znamenat bezvýhradné ukládání veškerého obsahu. Zadání a odpovědi mohou obsahovat osobní údaje, obchodní tajemství či jiné citlivé informace. Organizace by proto měla stanovit, jaká data se zaznamenávají, kdo k nim má přístup, jak dlouho se uchovávají a zda se před uložením anonymizují nebo jinak omezují.

Kvalita výstupů a její průběžné vyhodnocování

Pro kvalitu modelu neexistuje jediný ukazatel vhodný pro všechny úlohy. U klasifikačního systému lze sledovat například chybovost nebo poměr falešně pozitivních a falešně negativních výsledků. U generativního nástroje může být důležitá věcná správnost, relevance vůči zadání, opora v dostupných zdrojích a schopnost přiznat nejistotu.

Automatické metriky mohou pomoci při porovnávání verzí a zachycování výrazných změn, neměly by však být jediným podkladem pro hodnocení. U otevřených úloh nemusí skóre dobře vystihovat, zda je odpověď pro uživatele skutečně užitečná. Vhodné je proto kombinovat automatické testy s pravidelným odborným posouzením vzorku výstupů a se zpětnou vazbou z reálného používání.

Hodnocení by mělo vycházet z konkrétního účelu systému. Organizace si může pro jednotlivé scénáře stanovit přijatelné limity a určit, co se stane při jejich překročení. U rizikovějších aplikací může být nutné předat případ člověku, omezit automatické rozhodování nebo systém dočasně stáhnout z provozu.

Datový a modelový drift

Chování systému se může zhoršit, i když se nezmění jeho software. Proměnit se mohou vstupní data, způsob, jakým uživatelé službu používají, nebo podmínky, na které model reaguje. Odchylka v datech se často označuje jako datový drift. Pokud se změní vztah mezi vstupy a výsledkem, může jít o změnu, která přímo ovlivní kvalitu predikcí.

Drift neznamená automaticky, že je model nepoužitelný. Jde o signál k prověření. Systém může například obsluhovat novou skupinu uživatelů nebo pracovat s jiným typem dokumentů než při původním testování. Organizace by měla změnu porovnat s očekávaným provozem a zjistit, zda se promítá do kvality a dopadů rozhodnutí.

U predikčních modelů bývá možné zpětně porovnat předpovědi se skutečnými výsledky, jakmile jsou dostupné. U generativních systémů je takové vyhodnocení složitější, protože správnost odpovědi nemusí mít jednoznačný automaticky ověřitelný štítek. Pomoci může vzorkování výstupů, kontrola zdrojů, testovací sady odpovídající reálným úlohám a cílená analýza případů, na které upozorní uživatelé.

Bezpečnost, soukromí a odpovědnost

Observability přináší cenná data pro kontrolu systému, současně však vytváří další úložiště citlivých informací. Návrh sledování proto musí zohlednit minimalizaci údajů, řízení přístupů, dobu uchování a zabezpečení záznamů. Podrobné logy mohou být užitečné při vyšetřování incidentu, ale neměly by se shromažďovat bez jasného účelu a odpovídajících pravidel.

Důležité je také určit odpovědnost za reakci na zjištěné problémy. Upozornění samo o sobě riziko nesnižuje. Provozní tým, vlastníci produktu, odborníci na data a odpovědné osoby by měli vědět, kdo vyhodnocuje varování, kdo může změnit konfiguraci a za jakých podmínek se nasazení pozastaví.

U systémů s významným dopadem na jednotlivce nebo podniková rozhodnutí je vhodné uchovávat dostatek informací pro zpětnou kontrolu. Záznamy by měly umožnit rekonstruovat, jaké verze komponent pracovaly, z jakých podkladů systém vycházel a jaký výstup vytvořil. Rozsah této dokumentace se odvíjí od povahy použití a souvisejících povinností organizace.

Náklady a provozní efektivita

Výkonnost systému AI se neposuzuje jen podle kvality odpovědi. Důležitá je také cena jejího vytvoření a celková náročnost provozu. Náklady mohou vznikat při použití modelu, zpracování dat, vyhledávání, ukládání záznamů i následné lidské kontrole. Pokud se jednotlivé části nesledují odděleně, může být obtížné zjistit, co náklady skutečně zvyšuje.

Organizace může porovnávat spotřebu podle typu úlohy, verze modelu, objemu vstupu nebo výsledku. To umožňuje odlišit neobvykle náročné scénáře od běžného provozu a posoudit, zda dražší varianta přináší odpovídající přínos. Úspora na výpočetním výkonu ale nemusí být výhodná, pokud vede k častějším chybám, reklamací nebo ručním opravám.

Rozhodování o provozní efektivitě proto zahrnuje celkové náklady a přínosy. Pro některé úlohy může být vhodnější menší či specializovaný model, pro jiné kombinace automatického zpracování s lidskou kontrolou. Observability poskytuje podklady, na jejichž základě lze tyto varianty porovnat v reálných podmínkách.

Jak observability zavést v praxi

Úspěšné zavedení začíná vymezením účelu systému a rizik, která jeho provoz přináší. Bez této fáze hrozí, že organizace bude sbírat velké množství technických údajů, aniž by věděla, jaké rozhodnutí mají podpořit. Praktický postup může zahrnovat několik navazujících kroků:

Popište zamýšlené použití. Určete uživatele, typy úloh, hranice automatizace a situace, v nichž musí zasáhnout člověk.
Stanovte ukazatele a limity. Zvolte technické, kvalitativní, bezpečnostní a nákladové metriky odpovídající danému použití.
Zaveďte trasování. Propojte záznamy jednotlivých kroků tak, aby bylo možné vyšetřit příčinu selhání, a současně omezte ukládání citlivých údajů.
Ověřujte výstupy. Kombinujte automatické kontroly s odborným posouzením a zpětnou vazbou z provozu.
Nastavte reakční postupy. Určete vlastníky upozornění, eskalační pravidla a možnosti omezení či vypnutí systému.
Pravidelně revidujte nastavení. S tím, jak se mění data, uživatelé a účel systému, upravujte metriky i kontrolní postupy.

Observability je nejpřínosnější, když je součástí životního cyklu systému od návrhu přes testování až po běžný provoz. Neměla by se doplňovat až ve chvíli, kdy se objeví problém. Průběžné sledování poskytuje organizaci lepší přehled o tom, co systém dělá, za jakých podmínek a s jakými důsledky.

Dobře nastavená pozorovatelnost nezaručí, že systém AI nikdy neselže. Umožní však chyby a nežádoucí změny dříve rozpoznat, dohledat jejich příčiny a rozhodnout o přiměřené reakci. Tím se zlepšuje nejen technická stabilita, ale také kvalita rozhodování o dalším vývoji, rozsahu automatizace a ekonomické smysluplnosti celého řešení.