Výpadek AI nemusí zastavit proces, pokud úlohy zůstanou ve frontě, mají náhradní cestu a po návratu se nespustí dvakrát.
Jednou jsem nastavil opakování požadavků tak, že při potížích dodavatele systém vytvářel další neúspěšné pokusy. Výpadek to nevyřešilo a zvýšilo to náklady na API.
Od té doby považuji za připravený pouze proces, který umí požadavek bezpečně odložit, dokončit jinou cestou a po obnovení služby pokračovat bez duplicit.
Postup dává smysl, pokud AI rozhoduje o pokračování procesu. Typickým příkladem je klasifikace příchozího e-mailu, vytěžení údajů z dokumentu, vytvoření odpovědi nebo kontrola objednávky. Bez výsledku AI se další krok buď nespustí, nebo může udělat chybu.
Návod je na místě také tehdy, když zpracováváte větší dávky. Deset ručně opravených záznamů je nepříjemnost. Tři tisíce rozpracovaných úloh po dvouhodinovém výpadku už jsou provozní problém.
Naopak bych takové opatření nestavěl kolem nástroje, který jeden člověk použije několikrát týdně pro návrh textu. Tam obvykle stačí počkat nebo práci udělat ručně. Záložní integrace by byla dražší než samotný výpadek.
Než začnu řešit odolnost, potřebuji znát skutečný průběh práce. Pokud proces zatím existuje hlavně v hlavách lidí, vracím se k popisu a měření procesu před nákupem automatizačního nástroje. Výpadkový režim nelze rozumně navrhnout pro proces, který neumím popsat ani za běžného provozu.
Potřebuji vlastníka procesu, seznam vstupů a výstupů, místo pro bezpečné uložení čekajících úloh a člověka, který smí spustit náhradní režim. Musím také vědět, jak dlouhý výpadek firma snese.
U zpracování poptávek může být přijatelných 30 minut. U návrhu interního reportu klidně osm hodin. U odpovědi zákazníkovi do druhého pracovního dne možná automatický záložní model nepotřebuji vůbec.
Připravuji také vzorek reálných vstupů pro test. U malé firmy obvykle stačí 30 až 50 případů, pokud obsahují běžné situace i několik nepříjemných výjimek. Bez testovacího vzorku nelze ověřit, zda náhradní cesta funguje.
Nedostupnost dodavatele je jen jedna možnost. Proces může zastavit vyčerpaný kredit, neplatný klíč, překročený limit, změna modelu, chyba sítě nebo příliš dlouhá odezva.
Pro každý případ potřebuji rozhodnout, zda se má požadavek zopakovat. Dočasné chyby serveru a překročení provozního limitu opakuji. Chybu oprávnění nebo neplatný požadavek neopakuji, protože opakování stejnou chybu neodstraní.
Ověřitelný výsledek: Existuje přehled chyb, u každé je uvedeno, zda se požadavek opakuje, odkládá, nebo předává člověku.
Příchozí požadavek nejdřív uložím. Teprve potom volám AI. Každá úloha dostane vlastní identifikátor, čas přijetí, původní vstup a stav, například čeká, zpracovává se, hotovo nebo vyžaduje kontrolu.
Díky tomu se objednávka nebo e-mail neztratí jen proto, že API deset sekund neodpovídalo. Po obnovení služby lze pokračovat z fronty.
Ukládám původní vstup, ne pouze prompt sestavený pro konkrétní model. Když později změním dodavatele, dokážu požadavek sestavit znovu. Je to jedna z praktických pojistek proti závislosti na jediném dodavateli AI.
Ověřitelný výsledek: Po násilném přerušení spojení zůstane testovací úloha uložená a lze ji znovu spustit bez ručního zadávání.
První další pokus spouštím například po dvou sekundách, další po pěti a poslední po deseti. Přidávám malou náhodnou odchylku, aby všechny úlohy neopakovaly volání ve stejný okamžik.
Po třech neúspěšných pokusech úlohu vrátím do fronty nebo přepnu proces do náhradního režimu. Počet pokusů i časy volím podle procesu. U živého chatu nemá smysl čekat dvě minuty. U nočního zpracování faktur nevadí další pokus za čtvrt hodiny.
Nastavuji také nejdelší přípustnou dobu jednoho volání. Bez ní může připojení zůstat viset a blokovat další práci.
Ověřitelný výsledek: Simulovaný výpadek nevytvoří nekonečnou smyčku. Záznam ukáže nejvýše stanovený počet pokusů a následný přechod do určeného stavu.
Pokud selže například pět volání během jedné minuty, další požadavky už neposílám. Ukládám je do fronty a po pěti minutách zkusím jeden kontrolní požadavek. Když projde, provoz obnovuji postupně.
Tím chráním vlastní systém i dodavatele. Po obnovení služby nepustím najednou všech 2 000 čekajících úloh. Začnu třeba deseti za minutu a sleduji chybovost i dobu odezvy.
Ověřitelný výsledek: Při testu pěti chyb za sebou systém přestane AI volat. Po úspěšném kontrolním požadavku začne frontu vyprazdňovat nastavenou rychlostí.
Náhradou nemusí být další AI. U méně důležitých úloh často použiji jednoduchá pravidla. Poptávky lze dočasně směrovat podle adresy odesílatele a klíčových slov. Text odpovědi lze nahradit schválenou šablonou. Nejasné případy skončí ve frontě pro člověka.
Druhý model nebo dodavatel dává smysl tam, kde zastavení stojí víc než dvojí integrace. Jeho výstup ale musím otestovat na stejném vzorku. Nestačí změnit název modelu v nastavení. Lišit se může formát odpovědi, kvalita, délka kontextu i pravidla pro práci s daty.
U procesů, kde AI sama zapisuje do CRM nebo jiného systému, jsem opatrnější. AI agentovi svěřuji samostatné akce jen tehdy, když umím omezit jeho oprávnění a vrátit chybný krok.
Ověřitelný výsledek: Vypnutí hlavní AI služby nezastaví testovací proces. Úloha skončí přesně v předem určené náhradní cestě.
Po obnovení služby se může stejná úloha spustit podruhé. Proto před zápisem výsledku kontroluji její identifikátor a stav. Odeslaný e-mail, vytvořená objednávka nebo zápis do CRM musí mít jednoznačný klíč.
Nejnebezpečnější není dvojí shrnutí porady. Horší je dvojí odeslání odpovědi nebo dvojí založení objednávky. Zákazník pak může dostat dvě stejné zprávy nebo firma zpracuje jednu objednávku dvakrát.
Ověřitelný výsledek: Dvojí spuštění stejné testovací úlohy vytvoří jen jeden konečný záznam a jednu vnější akci.
Jednou za čtvrt roku odpojím testovací prostředí od hlavní služby. Sleduji čas do rozpoznání chyby, počet ztracených úloh, počet duplicit a dobu návratu do normálního provozu.
Test končí až po vyprázdnění fronty. Nestačí ověřit, že se rozsvítila výstraha. Je potřeba ověřit i zpracování čekajících objednávek a dalších úloh.
Ověřitelný výsledek: Z testu vznikne záznam s časy, počtem čekajících úloh, počtem chyb a jménem člověka, který rozhodl o návratu do běžného režimu.
První problém bývá nejasná odpovědnost. Upozornění přijde, ale nikdo neví, kdo smí automatizaci zastavit. Druhý problém je náhradní proces, který existuje pouze v dokumentu a nikdo ho nikdy nezkusil.
Třetí slabina se ukáže po obnovení služby. Firma vyřeší samotný výpadek, ale ne návrat nahromaděné práce. Fronta pak přetíží API nebo vytvoří duplicity.
Za rozumný cíl proto nepovažuji nepřetržitý provoz za každou cenu. U malé firmy stačí, když se žádný vstup neztratí, důležité případy převezme člověk a zbytek se po obnovení služby zpracuje jednou. Takový postup umožní po výpadku navázat na běžnou práci bez dohledávání ztracených úloh a oprav duplicit.
Firmy na Microsoftu sedí na nástroji pro automatizaci, za který už zaplatily. Power Automate zvládne schvalování, notifikace i přepis dat a většinu postavíte sami. Návod krok za krokem plus férová čára, kde jsou hranice a kdy volat technika.
Pražský Apify postavil firmu na sběru dat z webu. Teď udělal krok dál: jeho nástroje umí výsledek samy zapsat do Notionu, založit úkol na GitHubu nebo poslat zprávu do Slacku. A to bez toho, aby kdokoli viděl vaše hesla. Co přesně Apify postavil a co si z toho odnese česká firma, která chce automati
Hyundai dokoupil poslední podíl v Boston Dynamics a humanoid Atlas přestává být atrakcí z videí. První kusy jdou letos do továren. Co to znamená pro českou firmu, která žádné humanoidy nekupuje? Víc, než to vypadá.
Napište nám, co u vás řešíte. Ozveme se do jednoho pracovního dne.
