Jak robustně vybudovat streaming AI chatbota: Reconnect, částečné odpovědi a bezbariérová stavová hlášení

Díky streamování působí AI chatbot rychleji, protože se první slova zobrazí ještě předtím, než je vypočítána celá odpověď. Technicky však vzniká distribuovaný proces: server, poskytovatel modelu, proxy, prohlížeč a uživatelské rozhraní společně udržují stav po dobu několika sekund nebo minut. Mobilní síť mění připojení, karta se přesune do pozadí, proxy ukončí neaktivní spojení nebo uživatel omylem odešle požadavek znovu. Bez jasného protokolu se pak části textu zobrazují dvakrát, poloviční výpovědi se označí jako dokončené nebo se dvakrát spustí stejná akce nástroje.

Robustní webový chatbot proto přistupuje ke streamování jako ke stavovému stroji, nikoli jako k animaci. Tento průvodce ukazuje, jak vzájemně fungují ID událostí, obnovení spojení, atomické dokončení a uvážlivá hlášení pro čtečky obrazovky.

Zpráva potřebuje trvalou identitu

Při odeslání přiřaďte ID požadavku na straně klienta a neměnné ID zprávy na straně serveru. Každý úsek streamu navíc získejte posloupné sekvenční číslo. Pokud po chybě připojení dorazí stejný požadavek znovu, server nesmí spustit druhý nezávislý běh, ale musí vrátit stávající stav nebo v něm bezpečně pokračovat.

Tyto identity plní různé úlohy: ID požadavku zajišťuje idempotentnost operace zápisu, ID zprávy označuje výsledek a sekvenční číslo řadí fragmenty. Samotné časové razítko nestačí, protože paralelní požadavky mohou kolidovat nebo dorazit se zpožděním.

Oddělení transportu a věcného stavu

Ať už se použijí Server-Sent Events, Fetch-Streams nebo WebSockets, věcný životní cyklus se tím nemění. Modelujte minimálně stavy přijato, běží, dokončeno, zrušeno a selhalo. Pouze explicitní událost dokončení činí odpověď závaznou. Konec TCP spojení naopak neznamená automaticky úspěch.

Pro Server-Sent Events popisuje standard HTML opětovné připojení a předání posledního event ID. Tento mechanismus je užitečný, ale nenahrazuje historii na straně serveru. Server musí vědět, které fragmenty patří ke zprávě a zda při novém načtení může přeskočit již vydané sekvence.

Obnovení připojení bez duplicitního textu

Ukládejte omezenou vyrovnávací paměť událostí pro každou probíhající zprávu. Při obnovení připojení (reconnect) odesílá klient poslední potvrzenou sekvenci. Server doručuje pouze pozdější události. Pokud vyrovnávací paměť vypršela, neodpovídá odhadovanými fragmenty, ale snímkem (snapshotem) aktuálního kompletního textu a novou základní sekvencí.

Klient zpracovává události idempotentně: sekvence menší nebo rovné naposledy použité hodnotě se ignorují. Větší mezery vyvolají načtení snímku. Zobrazení tak zůstává správné, i když proxy opakuje data nebo se prohlížeč vrátí po krátkém výpadku.

Částečné odpovědi nesmí spouštět akce

Streamovaný text je předběžný. Odkazy mohou být ještě neúplné, upřesnění se může objevit až v další větě a strukturované argumenty nástrojů jsou až do konce syntakticky neplatné. Vykreslujte text progresivně, ale rizikové akce aktivujte až po dokončení a po samostatném ověření.

To platí zejména pro objednávky, rezervace termínů, změny zákaznických údajů nebo odesílání e-mailů. Provedení nástroje vyžaduje vlastní idempotentní ID akce, kontrolu oprávnění a případně viditelné potvrzení. Opětovné připojení nesmí nikdy provést stejnou akci znovu.

Zrušení zpracovávat jako skutečnou protokolovou událost

Tlačítko stop by nemělo pouze pozastavit vykreslování. Klient odesílá požadavek na zrušení s ID zprávy; server označí běh a podle možností ukončí práci modelu i nástroje. Později doručené fragmenty jsou zahrazeny. V uživatelském rozhraní zůstává patrné, že odpověď byla zrušena.

Pokud se požadavek na zrušení nedostane na server, práce tam může dále pokračovat. Proto i server pravidelně kontroluje stav. Metriky nákladů a latence by měly zrušené běhy počítat odděleně, jinak se zobrazí jako běžné chyby nebo z analýzy zcela zmizí.

Srozumitelnost a opakovatelnost chyb

Rozlišujte minimálně výpadek sítě, překročení časového limitu, chybu poskytovatele, bezpečnostní blokaci a věcnou validaci. Zpráva pro uživatele nemusí odhalovat interní technické detaily, ale měla by uvádět bezpečný další krok. „Připojení přerušeno – v odpovědi se bude pokračovat“ znamená něco jiného než „Tato akce nebyla provedena“.

Tlačítko pro opakování přebírá původní ID požadavku pouze tehdy, pokud má pokračovat stejný běh. Pro zcela nové vygenerování vzniká nové ID a rozhraní nezobrazuje obě verze jako jediný výsledek.

Nezahlcujte čtečku obrazovky každým tokenem

Dynamický obsah musí být vnímatelný pro asistenční technologie. WAI-ARIA pro tento účel definuje živé oblasti (Live Regions) a různé úrovně naléhavosti. Oblast aktualizovaná po jednotlivých tokenech s aria-live však může vyvolat stovky přerušení. Lepší je vizuální ukazatel streamování s odděleným, ohleduplným stavovým kanálem.

Hlašte například „Odpověď se připravuje“, následně v rozumných intervalech dokončenou větu nebo odstavec a na konci „Odpověď je kompletní“. Používejte aria-live="polite" pro běžný průběh; assertive je vhodné pouze pro skutečně naléhavé chyby. Zaměření (fokus) zůstává na vstupním poli nebo na místě zvoleném uživatelem a neposouvá se s každým fragmentem.

Nastavte aria-busy="true" v oblasti odpovědi, dokud je obsah neúplný, a odstraňte jej při atomickém dokončení. Tlačítko stop vyžaduje jasný název a musí být dostupné z klávesnice. Zkontrolujte také podporu omezení pohybu (reduced motion), přiblížení a malá zobrazení na mobilních zařízeních.

Cílené testování stavového stroje

Test ideálního průběhu (happy path) nestačí. Automatizujte minimálně tyto případy:

• Odpojení sítě po několika fragmentech a pokračování bez duplicitního textu.
• Doručení stejné události dvakrát a její zpracování pouze jednou.
• Vynechání sekvence a vyžádání snímku (snapshotu).
• Pozastavení karty, změna sítě a následné zobrazení správného dokončení.
• Zrušení během přípravy nástroje bez provedení jakékoli akce.
• Označení jako neúplné při vypršení časového limitu po viditelné částečné odpovědi.
• KONTROLA výstupů pro čtečky obrazovky ohledně rozumné frekvence a chování fokusu.

Měřte čas do prvního viditelného úseku, čas do úplného dokončení, míru opětovného připojení, duplicitní nebo zahrazené sekvence a úspěšnost zrušení. Čas do prvního tokenu může sám o sobě vypadat dobře, i když se mnoho odpovědí nikdy spolehlivě nedokončí.

Plán postupného zavedení

1. Definovat stavy zpráv a událostí na straně serveru.
2. Implementovat idempotentní ID a sekvence před animací v UI.
3. Doplnit reconnect s vyrovnávací pamětí a záložním snapshotem.
4. Striktně oddělit akce nástrojů od předběžného textu.
5. Zkontrolovat stavová hlášení pomocí klávesnice a čtečky obrazovky.
6. Otestovat chybové stavy při omezené a měnící se síti.
7. Teprve poté postupně aktivovat streaming pro produkční provoz.

Závěr: Rychle viditelný, jednoznačně dokončený

Dobrý streaming spojuje vnímanou rychlost s jasným modelem pravdivosti. Trvalá ID, uspořádané události, atomické dokončení a bezpečný reconnect zabraňují duplicitním nebo polovičním odpovědím. Uvážlivá živá oblast (live region) činí průběh přístupným, aniž by rušila uživatele čteček obrazovky s každým tokenem.

Jako další krok otestujte reálný chat v nestabilní mobilní síti. Pokud po zrušení a opětovném připojení není jednoznačně jasné, která zpráva je kompletní a která akce byla skutečně provedena, potřebuje opravu nejprve protokol – ne načítací animace.

Zdroje

• WHATWG HTML Standard: Server-Sent Events
• MDN Web Docs: Streams API
• W3C: WAI-ARIA 1.2
• W3C WAI: Stavová hlášení s ARIA Live Regions