Bygga robust AI-chatbot-streaming: Reconnect, delvisa svar och tillgängliga statusmeddelanden

Streaming gör att en AI-chatbot upplevs snabbare eftersom de första orden visas innan det fullständiga svaret har beräknats. Tekniskt sett skapas dock ett distribuerat förlopp: server, modellleverantör, proxy, webbläsare och användargränssnitt delar tillstånd i sekunder eller minuter. Mobilnätet byter nät, en flik hamnar i bakgrunden, en proxy avslutar en tyst anslutning eller en användare skickar av misstag igen. Utan ett tydligt protokoll visas då textdelar dubbelt, halva påståenden markeras som fullständiga eller så utlöses samma verktygsåtgärd två gånger.

En robust webbplats-chatbot hanterar därför streaming som en tillståndsmaskin, inte som en animation. Den här guiden visar hur händelse-ID:n, återupptagande, atomär avslutning och återhållsamma skärmläsarmeddelanden samverkar.

Ett meddelande behöver en permanent identitet

Tilldela ett förfrågnings-ID på klientsidan vid sändning och ett oföränderligt meddelande-ID på serversidan. Varje stream-avsnitt får dessutom ett fortlöpande sekvensnummer. Om samma uppdrag kommer igen efter ett anslutningsfel får servern inte starta en andra oberoende körning, utan ska returnera det befintliga tillståndet eller fortsätta säkert.

Identiteterna fyller olika funktioner: förfrågnings-ID gör skrivoperationen idempotent, meddelande-ID betecknar resultatet och sekvensnumret sorterar fragmenten. En tidsstämpel ensam räcker inte eftersom parallella förfrågningar kan kollidera eller anlända fördröjt.

Separera transport och domäntillstånd

Om du använder Server-Sent Events, Fetch-streams eller WebSockets ändrar inte den domänspecifika livscykeln. Modellera minst tillstånden mottagen, körs, avslutad, avbruten och misslyckad. Endast en explicit avslutningshändelse gör ett svar bindande. Slutet på en TCP-anslutning innebär däremot inte automatiskt framgång.

För Server-Sent Events beskriver HTML-standarden återanslutningar och överföringen av det senaste händelse-ID:t. Denna mekanik är användbar, men ersätter inte en historik på serversidan. Servern måste veta vilka fragment som hör till ett meddelande och om en ny hämtning får hoppa över redan utmatade sekvenser.

Reconnect utan dubbel text

Spara en begränsad händelsebuffert per pågående meddelande. Vid reconnect skickar klienten den senast bekräftade sekvensen. Servern levererar endast senare händelser. Om bufferten har löpt ut svarar den inte med gissade fragment, utan med en ögonblicksbild av den aktuella fullständiga texten och en ny bassekvens.

Klienten behandlar händelser idempotent: sekvenser som är mindre än eller lika med det senast tillämpade värdet ignoreras. Större luckor utlöser en hämtning av en ögonblicksbild. På så sätt förblir visningen korrekt, även om en proxy upprepar data eller om webbläsaren återvänder efter en kort offline-period.

Delvisa svar får inte utlösa åtgärder

Strömmad text är preliminär. Länkar kan fortfarande vara ofullständiga, en begränsning kanske dyker upp först i nästa mening och strukturerade verktygsargument är syntaktiskt ogiltiga ända till slutet. Rendera text progressivt, men aktivera riskfyllda åtgärder först efter avslutning och efter separat validering.

Detta gäller särskilt för beställningar, tidsbokningar, ändringar av kunddata eller e-postutskick. En verktygskörning behöver ett eget idempotent åtgärds-ID, behörighetskontroll och eventuellt en synlig bekräftelse. En reconnect får aldrig utföra samma effekt igen.

Behandla avbrott som en riktig protokollhändelse

En stoppknapp bör inte bara stoppa visualiseringen. Klienten skickar en avbrytsbegäran med meddelande-ID; servern markerar körningen och avslutar om möjligt modell- och verktygsarbete. Fragment som anländer senare kastas bort. I gränssnittet syns det tydligt att svaret avbröts.

Om avbrottet inte når servern fortsätter arbetet möjligen där. Därför kontrollerar även servern statusen regelbundet. Kostnads- och latensmätvärden bör räkna avbrutna körningar separat, annars framstår de som normala fel eller försvinner helt från analysen.

Gör fel förståeliga och upprepbara

Särskilj minst på nätverksavbrott, tidsöverskridande, leverantörsfel, säkerhetsblockering och domänvalidering. Användarmeddelandet behöver inte avslöja intern teknik, men bör ange ett säkert nästa steg. ”Anslutningen avbröts – svaret återupptas” är något annat än ”Denna åtgärd utfördes inte”.

En försök igen-knapp övertar det ursprungliga förfrågnings-ID:t endast om samma körning ska fortsätta. För en riktig ny generering skapas ett nytt ID och gränssnittet visar inte båda versionerna som ett enda resultat.

Överflöda inte skärmläsaren med varje token

Dynamiskt innehåll måste vara uppfattbart för assisterande teknik. WAI-ARIA definierar Live Regions och olika prioritetsnivåer för detta. En region som uppdateras token för token med aria-live kan dock skapa hundratals avbrott. Bättre är en visuell streamingindikator med en separat, artig statuskanal.

Meddela till exempel ”Svar skapas”, därefter med rimliga intervall en avslutad mening eller avsnitt och i slutet ”Svar fullständigt”. Använd aria-live="polite" för normala framsteg; assertive är endast lämpligt för verkligen brådskande fel. Fokus stannar i inmatningsfältet eller på den plats som användaren valt och hoppar inte med varje fragment.

Sätt aria-busy="true" på svarsområdet så länge innehållet är ofullständigt, och ta bort det vid den atomära avslutningen. Stoppknappen behöver ett tydligt namn och måste kunna nås via tangentbordet. Kontrollera dessutom reducerad rörelse, zoom och små mobila vyportar.

Testa tillståndsmaskinen målinriktat

Ett happy path-test räcker inte. Automatisera minst dessa fall:

• Koppla från anslutningen efter flera fragment och fortsätt utan dubblerad text.
• Leverera samma händelse två gånger och tillämpa den bara en gång.
• Hoppa över en sekvens och begär en ögonblicksbild.
• Pausa fliken, byt nätverk och visa därefter rätt avslutning.
• Avbryt under förberedelse av ett verktyg och utför ingen effekt.
• Markera timeout efter synligt delvis svar som ofullständigt.
• Kontrollera skärmläsarutdata för rimlig frekvens och fokusbeteende.

Mät tid till första synliga avsnitt, tid till fullständigt avslut, reconnect-frekvens, dubblerade eller kastade sekvenser och lyckade avbrott. Tiden till första token kan se bra ut i sig, även om många svar aldrig blir tillförlitligt färdiga.

En stegvis lanseringsplan

1. Definiera meddelande- och händelsetillstånd på serversidan.
2. Implementera idempotenta ID:n och sekvenser före UI-animationen.
3. Komplettera reconnect med buffert och fallback till ögonblicksbild.
4. Separera verktygsåtgärder strikt från den preliminära texten.
5. Kontrollera statusmeddelanden med tangentbord och skärmläsare.
6. Testa felsituationer under begränsat och skiftande nätverk.
7. Aktivera streaming för produktionstrafik först därefter i flera steg.

Slutsats: Snabbt synligt, entydigt avslutat

Bra streaming förenar upplevd hastighet med en tydlig sanningsmodell. Permanenta ID:n, ordnade händelser, en atomär avslutning och en säker reconnect förhindrar dubblerade eller halva svar. En återhållsam live region gör förloppet tillgängligt utan att avbryta skärmläsaranvändare för varje token.

Testa härnäst en riktig chatt under ett instabilt mobilnät. Om det efter avbrott och återanslutning inte är helt klart vilket meddelande som är fullständigt och vilken åtgärd som faktiskt har utförts, behöver protokollet repareras först – inte laddningsanimationen.

Källor

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