Byg robust AI-chatbot-streaming: Reconnect, delsvar og tilgængelige statusmeddelelser

Streaming får en AI-chatbot til at virke hurtigere, fordi de første ord vises, før det fuldstændige svar er beregnet. Teknisk set skaber det dog et distributed forløb: Server, modeludbyder, proxy, browser og brugerflade deler tilstand i sekunder eller minutter. Mobilnetværk skifter, en fane går i baggrunden, en proxy lukker en inaktiv forbindelse, eller en bruger sender ved et uheld igen. Uden en klar protokol bliver tekstdele vist dobbelt, halvfærdige udsagn markeret som fuldstændige, eller den samme værktøjshandling udløst to gange.

En robust website-chatbot behandler derfor streaming som en tilstandsmaskine og ikke som en animation. Denne guide viser, hvordan hændelses-ID'er, genoptagelse, atomar afslutning og afdæmpede skærmoplæser-meddelelser spiller sammen.

En besked har brug for en permanent identitet

Tildel et klientside-anmodnings-ID ved afsendelse og et uforanderligt besked-ID på serversiden. Hver stream-sektion modtager desuden et fortløbende sekvensnummer. Modtages den samme opgave igen efter en forbindelsesfejl, må serveren ikke starte kørsel nummer to, men skal returnere den eksisterende tilstand eller fortsætte den sikkert.

Identiteterne opfylder forskellige opgaver: Anmodnings-ID'et gør skrivehandlingen idempotent, besked-ID'et betegner resultatet, og sekvensnummeret sorterer fragmenterne. Et tidsstempel alene er ikke nok, da parallelle anmodninger kan kollidere eller ankomme forsinket.

Adskil transport og faglig tilstand

Om der anvendes Server-Sent Events, Fetch-streams eller WebSockets, ændrer ikke den faglige livscyklus. Modellér mindst tilstandene modtaget, kører, afsluttet, afbrudt og fejlet. Kun en eksplicit afslutningshændelse gør et svar bindende. Slutningen på en TCP-forbindelse betyder derimod ikke automatisk succes.

For Server-Sent Events beskriver HTML-standarden genforbindelser og overførsel af det seneste event-ID. Denne mekanik er nyttig, men erstatter ikke en historik på serversiden. Serveren skal vide, hvilke fragmenter der hører til en besked, og om en ny hentning må springe allerede udsendte sekvenser over.

Genforbindelse uden dobbelt tekst

Gem en begrænset hændelsesbuffer pr. igangværende besked. Ved reconnect sender klienten den senest bekræftede sekvens. Serveren leverer kun efterfølgende hændelser. Er bufferen udløbet, svarer den ikke med gættede fragmenter, men med et snapshot af den nuværende fuldstændige tekst og en ny basissekvens.

Klienten behandler hændelser idempotent: Sekvenser mindre end eller lig med den senest anvendte værdi ignoreres. Større huller udløser en snapshot-hentning. På den måde forbliver visningen korrekt, selvom en proxy gentager data, eller browseren vender tilbage efter en kort offline-periode.

Delsvar må ikke udløse handlinger

Streamet tekst er midlertidig. Links kan stadig være ufuldstændige, en forbehold kan først dukke op i næste sætning, og strukturerede værktøjsargumenter er syntaktisk ugyldige indtil slutningen. Render tekst progressivt, men aktiver først risikable handlinger efter afslutningen og efter separat validering.

Dette gælder især for bestillinger, tidsbestillinger, ændringer i kundedata eller e-mail-afsendelse. En værktøjsudførelse kræver sit eget idempotente handlings-ID, rettighedskontrol og eventuelt en synlig bekræftelse. En genforbindelse må aldrig udføre den samme virkning igen.

Behandl afbrydelse som en ægte protokolhændelse

En stop-knap bør ikke kun stoppe visningen. Klienten sender en afbrydelsesanmodning med besked-ID; serveren markerer kørslen og stopper om muligt model- og værktøjsarbejdet. Fragmenter, der ankommer bagefter, kasseres. I brugerfladen forbliver det synligt, at svaret blev afbrudt.

Hvis afbrydelsen ikke når serveren, fortsætter arbejdet muligvis dér. Derfor tjekker serveren også status regelmæssigt. Økonomi- og latenstal bør tælle afbrudte kørsler separat, da de ellers fremstår som normale fejl eller forsvinder helt fra analysen.

Gør fejl forståelige og gentagelige

Skeln mindst mellem netværksafbrydelse, timeout, udbyderfejl, sikkerhedsblokering og faglig validering. Brugerbeskeden behøver ikke at afsløre intern teknik, men bør angive det sikre næste skridt. "Forbindelse afbrudt – svaret genoptages" er noget andet end "Denne handling blev ikke udført".

En prøv-igen-knap genbruger kun det oprindelige anmodnings-ID, hvis den samme kørsel skal fortsættes. Ved en reel nyopprettelse genereres et nyt ID, og brugerfladen viser ikke de to versioner som ét enkelt resultat.

Oversvøm ikke skærmoplæseren med hvert token

Dynamisk indhold skal være opfatteligt for kompenserende teknologier. WAI-ARIA definerer live regions og forskellige hastighedsniveauer til dette formål. En region, der opdateres token for token med aria-live kan dog skabe hundredvis af afbrydelser. En visuel streaming-visning med en separat, afdæmpet statuskanal er bedre.

Meld for eksempel "Svar oprettes", derefter med rimelige intervaller en afsluttet sætning eller sektion og til sidst "Svar fuldført". Brug aria-live="polite" til normal fremdrift; assertive er kun egnet til virkelig kritiske fejl. Fokus forbliver på inputfeltet eller det sted, brugeren har valgt, og hopper ikke med hvert fragment.

Anvend aria-busy="true" på svarområdet, så længe indholdet er ufuldstændigt, og fjern det ved den atomare afslutning. Stop-knappen skal have et klart navn og kunne nås via tastaturet. Tjek desuden for reduceret bevægelse, zoom og små mobilvisninger.

Målrettet test af tilstandsmaskinen

En happy-path-test er ikke nok. Automatiser mindst følgende tilfælde:

• Afbryd forbindelsen efter flere fragmenter og fortsæt uden dobbelt tekst.
• Levér den samme hændelse to gange og anvend den kun én gang.
• Udelad en sekvens og anmod om et snapshot.
• Sæt fane på pause, skift netværk og vis bagefter den korrekte afslutning.
• Afbryd under en værktøjsforberedelse og udfør ingen virkning.
• Marker timeout efter et synligt delsvar som ufuldstændigt.
• Tjek skærmoplæser-output for en hensigtsmæssig frekvens og fokusadfærd.

Registrer tid indtil første synlige sektion, tid indtil fuldstændig afslutning, reconnect-rate, dobbelte eller kasserede sekvenser samt afbrydelsessucces. Tiden til det første token alene kan se fin ud, selvom mange svar aldrig bliver færdige på en pålidelig måde.

En gradvis implementeringsplan

1. Definer besked- og hændelsestilstande på serversiden.
2. Implementer idempotente ID'er og sekvenser før UI-animationen.
3. Tilføj reconnect med buffer og snapshot-fallback.
4. Adskil værktøjshandlinger strengt fra den midlertidige tekst.
5. Tjek statusmeddelelser med tastatur og skærmoplæser.
6. Test fejltilfælde under begrænset og skiftende netværk.
7. Aktivér først derefter streaming gradvist for produktionstrafik.

Konklusion: Hurtigt synlig, entydigt afsluttet

God streaming forener oplevet hastighed med en klar sandhedsmodel. Permanente ID'er, sorterede hændelser, en atomar afslutning og en sikker genforbindelse forhindrer dobbelte eller halvfærdige svar. En afdæmpet live region gør forløbet tilgængeligt uden at afbryde skærmoplæser-brugere ved hvert token.

Test som det næste en reel chat under ustabilt mobilnet. Hvis det efter afbrydelse og genforbindelse ikke står helt klart, hvilken besked der er fuldstændig, og hvilken handling der reelt blev udført, skal protokollen repareres først – ikke indlæsningsanimationen.

Kilder

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