Robusno izvođenje streamiga AI chatbota: Ponovno povezivanje, djelomični odgovori i pristupčne statusne poruke

Pretakanje čini da AI chatbot djeluje brže jer se prve riječi pojavljuju prije nego što je potpuni odgovor izračunat. Tehnički gledano, to stvara distribuirani proces: poslužitelj, pružatelj modela, proxy, preglednik i korisničko sučelje zajedno održavaju stanje nekoliko sekundi ili minuta. Mobilna mreža mijenja vezu, kartica odlazi u pozadinu, proxy prekida mirnu vezu ili korisnik slučajno ponovno pošalje zahtjev. Bez jasnog protokola dijelovi teksta prikazuju se dvostruko, polovične izjave označavaju se kao potpune ili se ista radnja alata pokreće dva puta.

Robusni web chatbot stoga tretira pretakanje kao stroj stanja, a ne kao animaciju. Ovaj vodič pokazuje kako identifikatori događaja, nastavak, atomarno dovršavanje i suzdržane poruke čitača zaslona rade zajedno.

Poruka treba trajni identitet

Dodijelite ID zahtjeva na strani klijenta prilikom slanja te nepromjenjivi ID poruke na strani poslužitelja. Svaki segment pretakanja dodatno dobiva redni broj sekvence. Ako isti zadatak stigne ponovno nakon mrežne pogreške, poslužitelj ne smije pokrenuti drugi neovisni proces, već mora vratiti postojeće stanje ili sigurno nastaviti.

Identiteti ispunjavaju različite zadatke: ID zahtjeva čini operaciju pisanja idempotentnom, ID poruke označava rezultat, a redni broj sekvence razvrstava fragmente. Sam vremenski pečat nije dovoljan jer paralelni zahtjevi mogu kolidirati ili stići sa zakašnjenjem.

Odvojite transport od poslovnog stanja

Bilo da se koriste Server-Sent Events, Fetch streamovi ili WebSockets, to ne mijenja poslovni životni ciklus. Modelirajte najmanje stanja: prihvaćeno, u tijeku, dovršeno, prekinuto i neuspješno. Samo eksplicitni događaj dovršetka čini odgovor obvezujućim. Prekid TCP veze, s druge strane, ne znači automatski uspjeh.

Za Server-Sent Events, HTML standard opisuje ponovno povezivanje i prosljeđivanje posljednjeg ID-a događaja. Ta je mehanika korisna, ali ne zamjenjuje povijest na strani poslužitelja. Poslužitelj mora znati koji fragmenti pripadaju poruci i smije li ponovni dohvat preskočiti već emitirane sekvence.

Ponovno povezivanje bez dvostrukog teksta

Spremite ograničeni spremnik događaja po aktivnoj poruci. Prilikom ponovnog povezivanja klijent šalje posljednju potvrđenu sekvencu. Poslužitelj isporučuje samo kasnije događaje. Ako je spremnik istekao, ne odgovara pretpostavljenim fragmentima, već snimkom trenutnog potpunog teksta i novom osnovnom sekvencom.

Klijent obrađuje događaje idempotentno: sekvence manje ili jednake posljednjoj primijenjenoj vrijednosti se zanemaruju. Veće praznine pokreću dohvat snimke stanja. Time prikaz ostaje točan, čak i ako proxy ponavlja podatke ili se preglednik vrati nakon kratkog izvanmrežnog razdoblja.

Djelomični odgovori ne smiju pokretati akcije

Pretočeni tekst je privremen. Poveznice mogu i dalje biti nepotpune, ograničenje se može pojaviti tek u sljedećoj rečenici, a strukturirani argumenti alata sintaktički su nevaljani do samog kraja. Prikazujte tekst progresivno, ali aktivirajte rizične radnje tek nakon dovršetka i nakon zasebne provjere valjanosti.

To se posebno odnosi na narudžbe, rezervacije termina, promjene podataka o kupcima ili slanje e-pošte. Izvršavanje alata zahtijeva vlastiti idempotentni ID akcije, provjeru ovlaštenja i po potrebi vidljivu potvrdu. Ponovno povezivanje nikada ne smije ponovno izvršiti isti učinak.

Tretirajte prekid kao pravi protokolarni događaj

Gumb za zaustavljanje ne bi trebao samo pauzirati prikaz. Klijent šalje zahtjev za prekid s ID-om poruke; poslužitelj označava proces i po mogućnosti prekida rad modela i alata. Kasnije prispjeli fragmenti se odbacuju. U sučelju ostaje prepoznatljivo da je odgovor prekinut.

Ako prekid ne stigne do poslužitelja, tamo se rad može nastaviti. Stoga poslužitelj također redovito provjerava status. Metrike troškova i latencije trebale bi odvojeno brojati prekinute procese, inače se pojavljuju kao uobičajene pogreške ili potpuno nestaju iz analize.

Učinite pogreške razumljivim i ponovljivim

Razlikujte barem prekid mreže, isteak vremena, pogrešku pružatelja usluge, sigurnosnu blokadu i poslovnu validaciju. Poruka korisniku ne mora otkrivati unutarnju tehnologiju, ali bi trebala navesti siguran sljedeći korak. „Veza je prekinuta – odgovor se nastavlja“ razlikuje se od „Ova radnja nije izvršena“.

Gumb za ponovno pokretanje preuzima izvorni ID zahtjeva samo ako se isti proces treba nastaviti. Za stvarno novo generiranje stvara se novi ID, a sučelje ne prikazuje obje verzije kao jedan rezultat.

Ne preplavljujte čitače zaslona svakim tokenom

Dinamični sadržaj mora biti primjetan za asistivne tehnologije. WAI-ARIA za to definira Live Regions i različite razine hitnosti. Regija koja se ažurira token po token s aria-live može međutim uzrokovati stotine prekida. Bolji je vizualni prikaz pretakanja s odvojenim, obzirnim statusnim kanalom.

Na primjer, javite „Odgovor se izrađuje“, zatim u razumnim intervalima dovršenu rečenicu ili odlomak i na kraju „Odgovor je potpun“. Upotrijebite aria-live="polite" za uobičajeni napredak; assertive prikladan je samo za zaista hitne pogreške. Fokus ostaje na polju za unos ili na mjestu koje je korisnik odabrao i ne skače sa svakim fragmentom.

Postavite aria-busy="true" na područje odgovora dok je sadržaj nepotpun i uklonite ga pri atomarnom završetku. Gumb za zaustavljanje treba jasno ime i mora biti dostupan putem tipkovnice. Također provjerite smanjeno kretanje, zumiranje i male mobilne prikaze.

Ciljano testiranje stroja stanja

Test uobičajenog prolaza (Happy Path) nije dovoljan. Automatizirajte barem ove slučajeve:

• Prekinite vezu nakon nekoliko fragmenata i nastavite bez dvostrukog teksta.
• Isporučite isti događaj dvaput i primijenite ga samo jednom.
• Preskočite sekvencu i zatražite snimku stanja.
• Pauzirajte karticu, promijenite mrežu i nakon toga prikažite točan završetak.
• Prekinite tijekom pripreme alata i nemojte izvršiti nikakav učinak.
• Označite istek vremena nakon vidljivog djelomičnog odgovora kao nepotpun.
• Provjerite izlaze čitača zaslona na razumnu učestalost i ponašanje fokusa.

Zabilježite vrijeme do prvog vidljivog odlomka, vrijeme do potpunog dovršetka, stopu ponovnog povezivanja, dvostruke ili odbačene sekvence i uspješnost prekida. Samo vrijeme do prvog tokena može izgledati dobro, iako se mnogi odgovori nikada pouzdano ne dovrše.

Plan uvođenja korak po korak

1. Definirajte stanja poruka i događaja na strani poslužitelja.
2. Implementirajte idempotentne ID-ove i sekvence prije animacije korisničkog sučelja.
3. Dodajte ponovno povezivanje sa spremnikom i zamjenskim mehanizmom snimke stanja.
4. Strogo odvojite radnje alata od privremenog teksta.
5. Provjerite statusne poruke pomoću tipkovnice i čitača zaslona.
6. Testirajte slučajeve pogrešaka pod ograničenom i promjenjivom mrežom.
7. Tek nakon toga postupno aktivirajte pretakanje za produkcijski promet.

Zaključak: Brzo vidljivo, nedvosmisleno dovršeno

Dobro pretakanje spaja doživljenu brzinu s jasnim modelom točnosti. Trajni ID-ovi, poređani događaji, atomarno dovršavanje i sigurno ponovno povezivanje sprječavaju dvostruke ili polovične odgovore. Obzirna uživo regija (Live Region) čini proces pristupačnim bez prekidanja korisnika čitača zaslona sa svakim tokenom.

Sljedeće testirajte stvarni chat pod nestabilnom mobilnom mrežom. Ako nakon prekida i ponovnog povezivanja nije sasvim jasno koja je poruka potpuna i koja je radnja stvarno izvršena, prvo treba popraviti protokol – a ne animaciju učitavanja.

Izvori

• WHATWG HTML Standard: Server-Sent Events
• MDN Web Docs: Streams API
• W3C: WAI-ARIA 1.2
• W3C WAI: Statusne poruke s ARIA Live Regions