Jak může IT podpora nasadit AI pro třídění tiketů a měřit chybovost?

Vycházejte z kategorií, které servisní deska už používá

Vaše servisní deska má pravděpodobně už seznam kategorií, například hardware, přístup, aplikace, síť, žádost o změnu, a stupnici priorit navázanou na závazek doby odezvy. Než napíšete jedinou instrukci pro model, vypište tento seznam přesně tak, jak ho tým používá dnes, včetně kategorií, které se používají zřídka nebo nejednotně. AI krok má tuto strukturu respektovat. Nová, čistší taxonomie sice zní lákavě, ale zavádí rozdíl mezi tím, na co je tým zvyklý, a tím, co model vrací, a ten rozdíl bude potřeba vysvětlovat u každého tiketu zvlášť.

Zůstaňte u tříd požadavků, kde existuje jasné pravidlo přiřazení a kde chybu při přiřazení někdo brzy zjistí, protože tiket skončí u špatného řešitele a ten si o něj řekne zpátky. Bez AI ponechte fronty, kde kategorie sama o sobě spouští další krok bez člověka mezi tím, bezpečnostní frontu popsanou níže, a fronty, kde je vstup dlouhodobě nekonzistentní natolik, že se ani dva zkušení pracovníci desky neshodnou na správné kategorii. Taková nekonzistence mezi lidmi obvykle ukazuje na nejasně napsanou definici kategorie; klasifikační krok ji jen zviditelní, sám ji nevyřeší.

Kam v postupu klasifikační krok patří

AI krok sedí mezi příjmem požadavku a jeho zařazením do fronty; k samotnému vyřešení tiketu už nezasahuje. Model navrhne kategorii, prioritu a stručné zdůvodnění, ale přesunutí tiketu do fronty zůstává krokem, který někdo potvrdí nebo přepíše. V praxi to znamená, že návrh je vidět společně s tiketem, přepsání nevyžaduje zvláštní schvalovací frontu a dá se zpětně dohledat, kdo ho udělal a kdy.

Text tiketu často obsahuje osobní údaje žadatele, interní jména systémů, nebo přímo přístupové údaje, které si žadatel omylem vloží do popisu problému místo do bezpečného pole. Než text tiketu půjde k jakémukoli externímu modelu, potřebujete vědět, co se s ním stane, kde se zpracuje a kdo k němu má přístup; toto posouzení patří pověřenci pro ochranu osobních údajů; autor pracovního postupu ho sám dělat nemá. Pokud model běží mimo vaši infrastrukturu, přístupové údaje a citlivá pole je rozumnější z textu před odesláním odstranit nebo takovou frontu z automatické klasifikace úplně vyjmout. Otázky, co je bezpečné zpracovávat pomocí AI a co vkládat do externích nástrojů, platí pro tiketovou frontu stejně jako pro jinou firemní komunikaci.

Definice špatné klasifikace a jak chybovost změřit

Než začnete cokoli měřit, napište jednu větu, která říká, co počítáte jako chybu. Neúplná definice zní „model se spletl“. Použitelná definice zní: navržená kategorie nebo priorita se liší od zařazení, na kterém se po přezkoumání shodli dva nezávislí pracovníci desky, a rozdíl skutečně změnil, kam nebo jak rychle byl tiket zpracován.

Sestavte vzorek uzavřených tiketů se spolehlivým, ručně přiřazeným štítkem, tedy kategorií a prioritou, na které se shodli dva nezávislí pracovníci; samotné hodnocení toho, kdo tiket zpracoval, nestačí. Model spusťte na stejný vzorek a porovnejte návrh se štítkem. Vzorek musí obsahovat i hraniční případy, které se dřív mezi lidmi rozcházely, protože právě tam bude nesouhlas nejcitelnější.

Ne každé odlišné zařazení má stejnou váhu. Tabulka rozlišuje neškodné přesměrování od chyby, která poruší závazek odezvy:

Text tiketu často míchá češtinu s angličtinou, hlavně u chybových hlášení a názvů systémů, a je to přesně ten typ vstupu, na kterém klasifikace může selhávat jinak než na jednojazyčném textu. Vzorek pro měření proto musí smíšené tikety obsahovat záměrně; spoléhat, že se do něj dostanou samy, nestačí.

Eskalace, přepis a tiket, který se nedá zařadit

Pracovník desky musí mít jednoduchou cestu, jak návrh přepsat, aniž by musel zdůvodňovat proč. Přepsání samo o sobě je užitečná data pro pozdější kontrolu. Není to přestupek, který je potřeba obhajovat, a pokud se tak chová, lidé se ho začnou vyhýbat i tam, kde je namístě.

Pokud model návrh nepodá s dostatečnou jistotou, nebo text neodpovídá žádné existující kategorii, tiket nesmí zůstat viset s náhodným nebo nejčastěji voleným zařazením. Jde do fronty „nelze určit“, kterou pravidelně kontroluje člověk, a platí pro ni stejný časový limit eskalace jako pro jakoukoli jinou frontu podle závazku odezvy.

Zvláštní případ je požadavek, který ve skutečnosti popisuje bezpečnostní incident, kompromitovaný účet, podezřelou přílohu nebo neobvyklý přístup k datům, ale přišel stejným vstupním kanálem jako běžný požadavek na heslo. Takový tiket nesmí čekat na klasifikaci vůbec. Potřebujete jednoduché, konzervativní pravidlo, které rozpozná jasné spouštěče dřív, než text uvidí klasifikační krok; jinak automatická klasifikace jen přidá zpoždění tam, kde záleží na minutách. Raději o jeden falešný poplach navíc, než jeden přehlédnutý incident, protože cena přehlédnutí je nesrovnatelně vyšší.

Provozní pravidla po spuštění

Po spuštění potřebujete opakovanou kontrolu; jednorázové ověření při zavedení nestačí. Spouštěcím signálem pro přeškolení nebo úpravu pravidel je změna seznamu kategorií, nová fronta či služba, nebo rostoucí podíl chyb v konkrétní kategorii zjištěný opakovanou kontrolou; samotný kalendářní interval bez takového signálu důvod k zásahu není.

Nejzáludnější selhání je tiket, který model zařadil s jistotou špatně a nikdo si toho nevšiml, protože se stejně vyřešil, uzavřel a zmizel ze zorného pole. Bez kontroly, která se ptá i na uzavřené tikety, tento typ chyby v datech neexistuje, přestože se skutečně stal. Opakovaná kontrola proto musí čerpat z náhodného vzorku uzavřených tiketů; vzorek postavený jen na stížnostech obraz zkresluje.

Aktualizace nástroje, na kterém klasifikace běží, může chování změnit tiše, beze změny na vaší straně. Po každé aktualizaci znovu spusťte stejný označený vzorek, který jste použili při zavedení, a porovnejte výsledek s předchozím měřením. Dojem, že „to pořád funguje stejně“, jako důkaz nestačí. Rámec NIST AI RMF řadí měření a řízení do samostatných funkcí Map, Measure a Manage vedle funkce Govern, což odpovídá tomu, že definice chyby, měření na vzorku a rozhodnutí o přeškolení patří mezi tři oddělené kroky s vlastním vlastníkem. Přístup testování, evaluace, validace a verifikace, který NIST popisuje pro AI systémy obecně, odpovídá tomu, co potřebujete i tady: označený vzorek, opakované měření a předem daná definice chyby místo jednorázového dojmu, že nástroj funguje. Generativní profil NIST AI 600-1 mezi rizika generativních systémů řadí i konfabulaci a nevhodně nastavenou spolupráci mezi člověkem a AI, což se v třídění tiketů projeví přesně jako jistá, ale špatná klasifikace, kterou bez opakované kontroly nikdo nezachytí.

Než rozšíříte rozsah

Než frontu klasifikace rozšíříte na další kategorie nebo na fronty s citlivějším obsahem, dejte otázku osobních údajů a bezpečnosti přednost před otázkou pohodlí. Popis, jaká data tiket obsahuje, kde se zpracovávají a kdo k nim má přístup, patří na stůl pověřence pro ochranu osobních údajů dřív, než frontu spustíte v širším rozsahu; obecný rámec shrnuje článek o GDPR a umělé inteligenci. Pro nezávislý pohled na to, zda klasifikace stále dělá to, co má, se hodí stejný princip jako u auditu AI systémů: oddělit toho, kdo nástroj provozuje, od toho, kdo ho kontroluje. Širší rozhodnutí, zda a jak AI zavádět mimo tuto jednu frontu, řeší samostatný postup pro zavedení AI ve firmě.

Stav zdrojů a omezení

Zdroje uvedené u tohoto textu popisují obecné rámce řízení rizik AI a testování systémů (NIST) a povinnosti při zpracování osobních údajů (GDPR); žádný z nich nepopisuje tiketovací systém ani klasifikaci provozních požadavků jako takovou. Tabulka typů chyby, hranice mezi neškodným přesměrováním a chybou porušující závazek odezvy i celý postup měření jsou pracovním doporučením CIAD. Nejde o validovanou metodiku s ověřenou přesností. Posouzení, zda konkrétní zpracování textu tiketu odpovídá GDPR, a rozhodnutí, který nástroj smí zpracovávat jaká data, patří pověřenci pro ochranu osobních údajů a interním pravidlům dané firmy; tento text taková rozhodnutí nenahrazuje.