Zákazník nahlásí problém, který už někdo ve firmě řešil. Možná si říkáte: „Bezva, takže víme, jak to spravit!” Záhy ale zjistíte, že postup se skrývá ve staré konverzaci a technické podrobnosti zná jen kolega, který právě není k dispozici. Hledání a propojování informací tak může zabrat více času než samotné řešení problému. Podobné situace představují příležitost pro agentní systémy. Dokážou projít dostupné zdroje, připravit podklady nebo navrhnout řešení. Celý proces se tím může zrychlit a člověku zbývá více času na práci, ve které využije vlastní zkušenosti a přináší přidanou hodnotu.
Právě možnost předat agentům část podobné práce byla tématem posledního tučňáčího webináře Data a agentní systémy. Co k tomu potřebují znát, jak jim zpřístupnit firemní nástroje a kde ponechat rozhodnutí na člověku?
Co jsou to agentní systémy?
Agentní systém můžeme chápat jako systém, který s využitím jazykového modelu vykonává složitější činnosti, přičemž má určitou volnost při volbě postupu. Míra samostatnosti přitom může být různá. Asistent někdy pouze připravuje podklady nebo naopak přímo provádí změny v předem určeném rozsahu. Stejně tak nemusí být vždy spuštěn přímým zadáním uživatele. Podnětem může být například i vznik incidentu v jiném systému. Už při návrhu je proto potřeba si ujasnit, jaké informace a nástroje k práci agent potřebuje, o čem smí rozhodovat samostatně a které kroky naopak vyžadují schválení člověka.
Jak na to? Od firemních dat k fungujícímu agentovi
Při navrhování systému, tedy od přípravy dat až po kontrolu oprávnění, se vyplatí držet se jednoduché zásady: pokud daný krok dokážeme spolehlivě vyřešit programaticky, upřednostníme tento postup před rozhodováním modelu. Jednoznačné kontroly a výpočty můžeme svěřit kódu s předem definovanými pravidly, zatímco model pomáhá s činnostmi, při nichž je potřeba pracovat s kontextem a volit další postup.
Současně je užitečné už od začátku počítat s jednotlivými komponentami, které lze samostatně upravovat a využívat v dalších agentech. Společný základ pro práci s nástroji a přístupy pak usnadní pozdější rozšiřování. Nejdříve ale potřebujeme vyřešit, z čeho bude agent čerpat a jak se k těmto informacím dostane.
Firemní znalosti a jejich důvěryhodnost
První krok vede k firemnímu know-how. Kde jsou informace o produktu a kdo zná souvislosti zákaznických problémů? A co se opakovaně řeší na poradách, ale nikdy se to nedostane do dokumentace?
Firemní know-how bývá rozprostřené mezi dokumentací, komunikačními nástroji, zápisy z porad a samotnými daty o provozu či zákaznících. Část navíc není zaznamenaná vůbec a zůstává pouze v paměti zaměstnanců. Příprava podkladů pro agenta tak může zahrnovat i vytváření chybějící dokumentace, třeba prostřednictvím rozhovorů s lidmi, kteří mají danou oblast na starost. Dalším zdrojem bývá například i kód produktu, který pomáhá vysvětlit, jak je určitá funkce implementovaná. Zde je ale potřeba si uvědomit, že kód popisuje současný stav, zatímco pro zjištění plánovaných změn potřebujeme jiné podklady, například produktový plán nebo zápis z porady týmu.
Tím se dostáváme k problému autority dat, tedy k otázce, kterému zdroji přisoudit v konkrétní situaci rozhodující význam. Stejná věc může být odlišně popsaná v dokumentaci, ve zprávě v interním chatu nebo v zápisu z porady. Platnost informace ale nelze posuzovat jen podle jejího stáří, protože novější záznam může zachycovat pouze návrh nebo průběžnou diskusi.
Nápomocné je pečlivé shromažďování podkladů a následné rozporování výsledků, při němž se hledají nepodložená tvrzení a nesrovnalosti. Takový postup může odhalit část chyb, ale nezaručuje, že agent vždy správně rozhodne mezi konfliktními zdroji. Pravidla pro jejich posuzování tak patří mezi otázky, které firma musí při práci se svými znalostmi dále řešit.
Zpřístupnění dat
Vedle důvěryhodnosti zdrojů je třeba rozhodnout, jak k nim bude agent přistupovat. Dokumentaci, přepisy porad nebo historii komunikace lze zpracovat do znalostní báze neboli knowledge base a připravit pro vyhledávání. Aktuální informace naopak může agent potřebovat přímo z živého systému. Ne všechny zdroje proto musí být uložené na jednom místě, důležité je zvolit vhodný přístup podle úkolu.
Pokud například hledáme, jak firma určitý problém řešila v minulosti, může pomoci vyhledávání v připravené znalostní bázi. Jestliže ale potřebujeme navázat na konkrétní zprávu odeslanou před chvílí, může být efektivnější přímý přístup do komunikačního nástroje. Oba způsoby se tedy doplňují.
Znalostní báze zároveň vyžaduje průběžné aktualizace. Pokud se změní produkt nebo firemní postup, musí se změna promítnout i do podkladů pro agenta. Nestačí tak pouze shromáždit dostupné informace, potřebujeme také určit, kdo je udržuje a jak poznáme jejich platnou verzi.
Konektory a skilly
Konektor umožňuje agentovi komunikovat s konkrétním nástrojem, například vyhledávat ve znalostní bázi nebo číst data z dalšího systému. Samotné napojení však ještě nezaručuje, že agent dokáže nástroj efektivně používat.
Můžeme si představit například situaci, kdy je nutné prohledat provozní logy. Agent se v nich může pokoušet hledat i bez podrobnějších instrukcí, ale jejich množství a různorodost práci komplikují. Hledání pak může být pomalé a nákladné, případně skončit překročením časového limitu.
Pro práci s takovým zdrojem pomáhají skilly, tedy instrukce a postupy, které agentovi vysvětlují, kdy nástroj použít a jak se správně ptát. Mohou být obecné, ale také zachycovat specifické firemní postupy. Právě zde se do systému promítá zkušenost lidí, kteří dobře znají produkt a zákazníky. Kvalitu asistenta tak ovlivňuje i to, jak dobře tyto znalosti dokážeme popsat a udržovat.
Přístupy a bezpečnost
Způsob, jakým lidé s agentem komunikují, ovlivňuje jeho dostupnost i řešení přístupových práv. Zapojení asistenta do interního chatu má jednu praktickou výhodu: lidé v něm už pracují.
Do řešení problému mohou ve stejném vlákně zapojit kolegy i agenta a navazovat na dosavadní zjištění. Záznam pak může posloužit při řešení podobného problému v budoucnu.
Z hlediska oprávnění je ale potřeba dořešit, pod čí identitou agent přistupuje k navazujícím systémům. Identita uživatele v komunikačním nástroji totiž nemusí být automaticky propojená s účtem, podle kterého se řídí oprávnění v dalších nástrojích. Pokud agent používá společný účet, je nutné zachovat omezení konkrétního uživatele, aby nezískal širší přístup, než kterým běžně disponuje. Právě ověřování oprávnění je příkladem kontroly, kterou potřebujeme opřít o jednoznačná pravidla.
Lokální varianta, kterou člověk spustí na svém počítači, může využívání jeho identity usnadnit. I tam ale záleží na konkrétních konektorech a cílových systémech. Samotné spuštění na počítači navíc neznamená, že se všechny informace zpracovávají pouze na něm.
Vedle přístupu ke zdrojům je třeba řešit i místo, kam agent odpověď vrací. Informace dostupná jednomu člověku nemusí patřit do kanálu přístupného celému týmu. Odpovídající omezení je potřeba zachovat také při kopírování dat do znalostní báze.
Observability a vyhodnocování
Když agent vrátí nesprávnou odpověď, potřebujeme zjistit, ve které části postupu problém vznikl. Použil nevhodný zdroj? Vynechal důležitý krok? Zavolal nástroj, který skončil chybou, a přesto pokračoval? K posouzení těchto situací slouží observability, tedy nástroje, které umožňují sledovat provoz a porozumět chování systému.
Základem je end-to-end tracing, tedy propojený záznam celého požadavku od zadání až po skutečný výsledek napříč komponentami systému. Zachycuje, jakou akci agent plánoval, jaké nástroje skutečně zavolal, jaké výsledky získal a k jakému výstupu dospěl. Důležitý je také kontext konkrétního běhu, tedy použitý model a skilly. Přitom je třeba rozlišovat mezi skilly, které měl agent k dispozici, a těmi, které během své práce spustil. Bez těchto informací obtížně zjistíme, proč po změně modelu nebo instrukcí začal stejný typ úkolu dopadat jinak.
Záznamy umožňují sledovat také náklady a délku jednotlivých kroků. Spolu se zpětnou vazbou uživatelů pak pomáhají určit, co je potřeba upravit. Pokud například opakovaně selhává hledání v jednom zdroji, můžeme podle průběhu požadavků zkoumat, zda je problém v nástroji, nebo v samotných podkladech.
Jak systém dál rozvíjet
Z používání systému postupně zjistíme, které úkoly se opakují a kde lidé potřebují více pomoci. Tyto zkušenosti nám umožní řešit tři odlišné otázky: jak úzce má být agent zaměřený, jak samostatně může jednat a co jeho práci spouští.
Obecnost a specializace
Začít obecnějším asistentem může být užitečné zejména tehdy, když teprve zjišťujeme potřeby lidí napříč firmou. Poté na základě jeho skutečného používání můžeme přistoupit k tvorbě samostatných agentů pro konkrétní úkoly.
Klíčová je přitom komunikace. Potřebujeme vysvětlit možnosti i omezení první nasazené verze a vyzvat lidi k ověřování odpovědí a poskytování zpětné vazby. Mohou tak ovlivnit další vývoj a upozornit na úkoly, u kterých by jim asistent pomohl. Rostoucí důvěra ovšem nemusí být vždy čistě pozitivním jevem, jelikož s častějším používáním může klesat ochota výsledky kontrolovat.
S rozšiřováním přibývají obecnému agentovi nástroje a úkoly, které má zvládat. Postupně proto přirozeně vzniká potřeba oddělit specializované činnosti do samostatných agentů s užším zadáním. A právě tady se uplatní společná architektura, protože další agent může využít již připravené komponenty a dostat vlastní instrukce. Obecný asistent přitom může zůstat dostupný pro otázky, které přesahují jednu specializaci.
Míra autonomie
U každé činnosti potřebujeme určit, kde má agent skončit a předat výsledek člověku. Dohledání či analýza informací, příprava návrhu a provedení změny vyžadují odlišné pravomoci. S každým z těchto kroků se zároveň mění i důsledky případné chyby.
U zákaznického problému z úvodu článku může například agent nejprve dohledat předchozí řešení a připravit návrh odpovědi. Její odeslání zákazníkovi už ale může vyžadovat schválení pracovníkem podpory. Hranice samostatnosti a ochranné mechanismy je potřeba určit předem a zajistit jejich zapojení do systému. Pravomoci pak lze rozšiřovat podle výsledků z nasazení a podle toho, co jsme schopní spolehlivě kontrolovat.
Reaktivní a proaktivní fungování
Kromě toho, o čem agent rozhoduje, můžeme měnit i to, co jeho práci spouští. Reaktivní asistent čeká na zadání člověka, zatímco při proaktivním fungování může začít pracovat na základě události v jiném systému a člověka oslovit až s připravenými zjištěními.
Vznik incidentu tak může automaticky spustit i jeho analýzu. Výsledek se objeví ve vlákně interního chatu, kde lidé mohou položit další otázky a společně s agentem v analýze i řešení pokračovat. Odpadá tak nutnost nejprve asistenta oslovit a ručně mu zadat úvodní prověření.
Další možností je pravidelný plánovaný běh. Ať už však práci zahájí konkrétní událost, pevně stanovený plán nebo přímo člověk, stále platí dříve nastavené hranice oprávnění. Automaticky spuštěná analýza může končit u podkladů pro rozhodnutí. Díky tomu lze předat agentovi opakovanou přípravu a lidskou pozornost soustředit na posouzení výsledků a další postup.
Co si z toho odnést?
Zpřístupněním firemních znalostí a nástrojů si připravujeme půdu na to, aby agent nejen odpovídal na naše otázky, ale mohl také sám připravovat změny. Začít můžeme u jedné opakované činnosti, která lidem bere čas. Rozsah jeho pravomocí a autonomie pak můžeme rozšiřovat podle průběžného vyhodnocování výsledků a zkušeností lidí, kteří systém používají.