Kdy má AI říct, že neví, a předat případ člověku

Zákazník napíše, že chce změnit termín instalace. Jeho zpráva neobsahuje číslo zakázky a v systému jsou pod stejným příjmením dvě rezervace. Asistent může rychle najít pravděpodobnou shodu a navrhnout datum. Pro zákazníka je v tu chvíli užitečnější přesná otázka na číslo zakázky. Pokud by už došlo ke změně v kalendáři, vrácení může zasáhnout další lidi. Pravidlo pro nejistotu proto musí říct nejen co odpovědět, ale i kdy přestat jednat.

Začněte tím, že určíte konkrétní chybějící podmínky. U jednoduché otázky může stačit jedno doplnění. U rozporného zdroje je potřeba předat rozpor člověku. U zásahu s významným dopadem čeká nástroj na schválení, i když jsou podklady úplné. Níže si projdeme všechny tři situace od první odpovědi až po předání práce.

Nejistota se dá poznat podle chybějícího podkladu

Člověk může větu „jsem si jistý na 92 procent“ chápat jako výsledek měření. Pokud tuto hodnotu model sám napsal do textu, nevíte, jak ji získal a zda odpovídá skutečné četnosti chyb. Opřete se o věci, které lze zkontrolovat mimo odpověď. U termínu instalace je možné ověřit číslo zakázky, dostupnost kapacity a skutečný stav rezervace. U popisu staré směrnice lze ověřit datum účinnosti a zdrojový dokument.

Pojmenujte potřebný důkaz pro každou významnou informaci. Když asistent odpovídá na otázku o stavu zásilky, může mít dost informací ke sdělení, že ji dopravce převzal. Pokud dokument uvádí jen tento stav, ještě neposkytuje přesný den doručení. Částečná odpověď je v tomto případě užitečná, pokud jasně oddělí potvrzenou skutečnost od toho, co z podkladů nejde určit.

Způsob hodnocení mění chování, které si v týmu vyberete. Pokud pracovník zaznamená bod jen za konkrétní odpověď, každý vyřešený odhad vypadá v tabulce lépe než poctivě vyžádaný údaj. Podobný problém popisuje výzkum OpenAI o hádání u modelů. V pracovním nasazení lze hodnotit, zda systém při chybějícím podkladu správně položil otázku nebo přestal navrhovat akci. V testovací sadě pro změny AI takový případ předem označte a ověřte i běžný případ, který má asistent dokončit.

Rozhodněte, co se stane ve čtyřech různých situacích

Nejistota nemusí vést vždy ke stejnému oznámení. Pokud je podklad čitelný a oprávnění dostatečné, má asistent pokračovat podle běžného postupu. Pokud chybí jednoznačný údaj, může požádat o doplnění. Rozpor mezi podklady často vyžaduje odpovědného člověka. A některé akce vyžadují lidské schválení bez ohledu na to, jak jednoznačné jsou vstupy.

Čtyři možné reakce při práci s rezervací Na mobilu lze tabulku posouvat do stran.

Podmínku pro každý výsledek napište způsobem, který lze vyzkoušet. „Při nízké jistotě se ptej“ má široký výklad. „Při více nalezených rezervacích bez jednoznačného čísla zakázky nabídni doplnění identifikátoru a neotevírej termíny jiných osob“ se dá ověřit na modelovém případu. Další podmínka může říct, že termín se potvrdí až po ověření dostupnosti a po souhlasu klienta. Oprávnění systému nastavte tak, aby blokující podmínky skutečně vynucoval. Důvod podrobněji vysvětluje návod k přístupům AI agenta.

Není nutné vždy začínat dotazem. Když uživatel žádá jen obecný přehled o tom, jak termíny fungují, můžete mu popsat proces a uvést, co bude potřebovat při samotné změně. Otázka je vhodná tehdy, když doplnění skutečně změní konkrétní výsledek. Tím snížíte počet zbytečných přerušení a ponecháte jasnou hranici pro akce.

Zeptejte se na nejmenší údaj, který pomůže

Při chybějícím identifikátoru požádejte o ten identifikátor. Nežádejte uživatele znovu o celé hlášení ani o přílohu, když stačí jeden údaj. Ještě předtím ověřte, zda jej systém už má k dispozici z důvěryhodného zdroje. Pokud je člověk přihlášený a v rozhraní má otevřenou konkrétní rezervaci, může asistent pracovat s tímto kontextem v mezích svého přístupu. Ve veřejném formuláři žádá bezpečný identifikátor podle pravidel služby.

• Položte jednu otázku, pokud odpověď rozhodne mezi dvěma jasnými možnostmi. U rozvrhu se například zeptejte, zda uživatel myslí návštěvu v Brně nebo online konzultaci, pokud jsou obě už viditelné v jeho přihlášeném účtu.
• U více chybějících údajů seřaďte požadavky podle významu. Když zatím nevíte, o kterou zakázku jde, nový čas může být předčasná otázka.
• U citlivého údaje vysvětlete, kde jej má člověk bezpečně doplnit. Do nepřihlášeného chatu nepotřebujete přenášet celý doklad jen kvůli spárování požadavku.
• Sdělte, co už je možné potvrdit a co čeká na ověření. „Termín jsme zatím nezměnili“ vyřeší důležitou nejistotu uživatele.
• Nabídněte cestu k člověku, pokud uživatel údaj nezná nebo se k němu nedostane. Předejdete opakovanému dotazování bez posunu.

Ověřujte také, zda se v dotazu neskrývá chybný předpoklad. Když zákazník chce nový termín „místo zítřka“, ale systém žádný zítřejší termín neukazuje, je potřeba rozpor pojmenovat. Nežádá-li uživatel o změnu údajů, může asistent nabídnout, že pomůže dohledat potvrzení. Když má změnu skutečně provést, potřebuje nejdřív platnou rezervaci a ověřený kontext.

Předejte člověku připravený případ

Nejhorší předání bývá „nerozumím, kontaktujte podporu“ v situaci, kdy další pracovník dostane prázdný formulář a uživatel vysvětluje všechno od začátku. Předání má obsahovat cíl, identifikátor a krátké vysvětlení, proč automatizace skončila. Uveďte, které podklady byly potvrzené, co si odporuje a jaký krok ještě čeká. Přikládejte údaje v rozsahu potřebném pro práci oprávněného příjemce.

1. Sepište požadovanou změnu slovy, kterým rozumí pracovník i zákazník.
2. Připojte schválené odkazy nebo identifikátory zdrojů. Pokud se podklady liší, uveďte obě tvrzení a jejich původ.
3. Rozlište provedenou akci od návrhu. Napište, zda se upravil záznam, založil koncept nebo dosud neproběhl žádný zápis.
4. Určete skupinu, která případ převezme, a uveďte, co má rozhodnout. Předání bez vlastníka se snadno změní v čekání.
5. Uživateli vysvětlete, jak pozná pokračování. Pokud služba termín reakce nezná, může alespoň potvrdit přijetí a uvést, jak případ dohledat.

Uvažujme modelovou situaci, kdy asistent připravil návrh změny instalace. Našel jednu rezervaci, ale ověřil jen dostupnost v interním plánu. Dodavatel má vlastní kalendář, který ukazuje blokaci. Předání může stručně popsat, že klient žádá o přesun na středu dopoledne, interní plán čas nabízí a kalendář dodavatele jej má blokovaný. Dále se zaznamená, že rezervace nebyla přepsána. Pracovník ví, že má ověřit dostupnost u dodavatele, místo aby opakoval celý rozhovor.

Otestujte chování na obou stranách hranice

Přísné předávání může zbytečně přerušovat jednoduché úlohy. Příliš volné pravidlo naopak dovolí riskantní odhady. Připravte dvojice podobných scénářů, v nichž se změní jediná rozhodující podmínka. V prvním je číslo případu dostupné a sedí ke klientovi. Ve druhém chybí a evidence najde více kandidátů. Tým může zkontrolovat, jestli první případ projde a druhý skončí cíleným dotazem.

Zkuste i vstup, který naléhá na výjimku. Uživatel například napíše „pospíchám, vezměte prostě první volný termín“. Má smysl rozhodnout, zda tento souhlas stačí pro výběr času, a oddělit to od identifikace rezervace. Pokyn spěchat neposkytuje chybějící důkaz o tom, která zakázka patří zákazníkovi. Takové případy učí posuzovat příčinu předání, ne jen náladu ve zprávě.

Rozbor ověřování odpovědí AI doporučuje rozdělit text na tvrzení podle následků. Stejný postup použijte ve zkušební sadě. U části odpovědi, která jen popisuje obvyklý proces, může stačit správná formulace. U konkrétního času a slibu zákazníkovi ověřte podklad, oprávnění i výsledný stav. Pokud AI vytvořila souhrn ke schválení, zkontrolujte, zda člověk vidí stejný stav jako systém, který má akci vykonat.

Změřte dokončené úlohy i zbytečná přerušení

Představte si modelových sto požadavků. Sedmdesát má úplný podklad a třicet potřebuje doplnění. Systém správně obslouží šedesát z první skupiny. Deset zbytečně přeruší. Z druhé skupiny správně předá nebo doplní dvacet pět a v pěti se pokusí pokračovat bez podkladu. Celkové číslo osmdesát pět správně zpracovaných požadavků je užitečné pro souhrn. Pro opravu ale potřebujete odděleně vidět deset přerušení a pět rizikových průchodů.

Když do zprávy doplníte podrobnější instrukci a zbytečné přerušení klesne, ověřte zároveň druhou stranu. Pokud se počet rizikových průchodů zvýší, ušetřený čas může být vykoupen vážnějšími chybami. Vedle součtů uchovejte popis reprezentativních případů. Ukážou, jestli je potřeba zpřesnit otázku, zlepšit zdroj dat nebo upravit hranici pravomoci.

Měřte, co se s předaným případem stalo. Pracovník může dostat užitečný souhrn, ale kvůli chybějící příloze jej nedokončí. Nebo zjistí, že požadavek mohl vyřešit asistent, kdyby načetl podklad z přihlášené evidence. Samotný počet předání neříká, zda se lidem zjednodušila práce. U krátkého pilotu pomůže poznámka o tom, co přesně člověk musel zjistit po převzetí a jak dlouho to trvalo.

Jak o nejistotě mluvit bez falešných slibů

Dobrá odpověď uvede konkrétní chybějící informaci. Místo obecného „výsledek může být nepřesný“ napište, že systém nenašel potvrzení dostupnosti technika ve středu. Uživatel tak rozumí, proč ještě nemá definitivní termín. Pokud můžete doložit část výsledku, uveďte ji. „Rezervaci jsem dohledal. Středeční termín zatím nemám potvrzený“ je srozumitelnější než dlouhá zpráva o tom, že asistent může dělat chyby.

V rozhraní rozlišujte požadavek na doplnění od odmítnutí akce. Uživatel, který neví číslo případu, nemusí přijít o možnost změnit termín. Může ověřit identitu jiným schváleným způsobem nebo požádat o pomoc. U akce, která přesahuje možnosti daného kanálu, může asistent vysvětlit správný postup. Pro stručnost pomáhá na závěr konkrétní další krok, třeba otevření přihlášeného přehledu a potvrzení jedné rezervace.

Kdy pomůže potvrzení ještě před akcí

Potvrzení se hodí, když je správná práce vratná jen obtížně nebo má vliv na někoho dalšího. U přesunu termínu nejprve ukažte starý a nový čas i rezervaci, které se změna týká. Uživatel tak má šanci zachytit nesoulad. Při skutečném zápisu opět ověřte, že termín mezitím nezabral někdo jiný. Souhlas s navrženým stavem sám o sobě dostupnost do budoucna nezaručuje.

Potvrzení má být úměrné rozhodnutí. U úpravy interního konceptu může stačit, že jej pracovník přirozeně zkontroluje před odesláním. U živého kalendáře nebo odeslání závazné zprávy má být zřejmé, kdy se akce provede a jaký je její skutečný výsledek. Když nejde stav po pokusu určit, další krok je ověření v evidenci. Slib, že je hotovo, v takové situaci nepomůže uživateli ani dalšímu pracovníkovi.

Připravte se na chvíli, kdy člověk není k dispozici

Podpora nemusí fungovat nepřetržitě. Představte si večerní žádost o přesun instalace, která je naplánovaná hned na další ráno. Asistent narazí na rozpor a ve frontě právě nikdo není. Pokud může přijmout žádost, měl by oddělit její převzetí od schválení změny. Uživatel potřebuje vědět, zda platí původní termín a kde najde potvrzení, až se stav změní. Očekávanou dobu reakce smí systém uvést podle skutečných pravidel služby, nikoli ji odhadnout podle tónu rozhovoru.

Nastavte si také hranici čekání. Když se v uživatelově účtu objeví tlačítko potvrzení až po ověření kolegou, může starý návrh mezitím pozbýt platnosti. Ranní změna termínu už nemusí být možná, pokud byl technik vyslán na cestu. Pracovník má před potvrzením znovu ověřit stav, zákazník má dostat informaci o skutečném výsledku. Dobře nastavený proces eviduje, že dřívější návrh vypršel, místo aby jej po návratu automaticky použil.

U rušných služeb je užitečné rozdělit předání podle důvodu. Žádost o další podklad zvládne běžná podpora, zatímco nesoulad kalendářů může potřebovat dispečink. V evidenci použijte tak stručný důvod, aby člověk věděl, kde začít. Uživatel nemusí znát vnitřní názvy týmů, ale měl by vidět, jak případ dohledat a zda od něj služba ještě něco očekává.

Jednou za čas nechte pracovníka převzít modelový případ přes stejné rozhraní jako ve skutečné práci. Zjistí třeba, že asistent odkazuje na přílohu, kterou příjemce nemůže otevřít, nebo že původní termín uvádí bez časového pásma. Tyto nedostatky při samotném hodnocení odpovědi snadno přehlédnete. Jejich oprava zrychlí práci i v situacích, kde se model správně zastavil hned napoprvé.

Projděte i opačnou cestu. Po uzavření případu se podívejte, zda uživatel obdržel nové potvrzení a jestli se stav shoduje v zákaznickém účtu, kalendáři i interní evidenci. Předání má pokračovat až ke sdělení výsledku.

Časté otázky

Stačí požádat model, aby si nevymýšlel?

Taková instrukce může pomoci, ale nastavte i ověřitelné podmínky. Určete, který zdroj má použít, co má udělat při absenci údaje a co nedovolí zapsat vlastní aplikace.

Kdy má asistent odpovědět jen částečně?

Když část odpovědi má ověřenou oporu a sama o sobě uživateli pomůže. Uveďte i chybějící údaj a další krok, pokud jeho doplnění rozhodne o výsledku.

Má se předávat celý rozhovor?

Rozsah přizpůsobte účelu a přístupovým pravidlům. Obvykle pomůže souhrn s ověřenými zdroji a možností otevřít potřebnou část. Plošná kopie může přidat údaje, které nový příjemce k práci nepotřebuje.

Jak zabránit smyčce opakovaných otázek?

Zaznamenejte, co už uživatel doplnil a které pokusy nepřinesly jednoznačný výsledek. Po předem nastaveném počtu neúspěšných doplnění nabídněte jinou cestu nebo předání.

Co když jsou oba zdroje důvěryhodné a liší se?

Ověřte jejich datum, rozsah a roli. Pokud nemáte doložené pravidlo přednosti, předejte rozpor odpovědnému člověku. Do té doby lze sdělit jen to, co spolehlivě vyplývá z podkladů.

Může stejná podmínka platit pro všechny agenty?

Některé zásady sdílet můžete, například požadavek na schválení zápisu s velkým dopadem. Konkrétní důkazy a možné následky se ale liší podle zdroje, oprávnění a typu práce.