Robustas AI tērzēšanas botu straumēšanas izstrāde: atkārtota savienošanās, daļējas atbildes un pieejami statusa ziņojumi

Straumēšana liek AI čatbotam darboties ātrāk, jo pirmie vārdi parādās vēl pirms pilnīgas atbildes aprēķināšanas. Tomēr no tehniskā viedokļa tas rada izkliedētu procesu: serveris, modeļa nodrošinātājs, starpniekserveris, pārlūkprogramma un lietotāja saskarne uz sekundēm vai minūtēm kopīgi uztur stāvokli. Mobilais tīkls mainās, cilne pāriet fonā, starpniekserveris pārtrauc klusu savienojumu vai lietotājs nejauši nosūta pieprasījumu no jauna. Bez skaidra protokola teksta daļas tiek attēlotas dubultā, nepilnīgi paziņojumi tiek atzīmēti kā pilnīgi, vai arī viena un tā pati rīka darbība tiek izsaukta divreiz.

Tāpēc uzticams tīmekļa vietnes čatbots straumēšanu apstrādā kā stāvokļu mašīnu, nevis kā animāciju. Šajā rokasgrāmatā paskaidrots, kā mijiedarbojas notikumu ID, darbības atsākšana, atomāra pabeigšana un savaldīgi ekrāna lasītāja paziņojumi.

Ziņojumam ir nepieciešama pastāvīga identitāte

Nosūtot pieprasījumu, piešķiriet klienta puses pieprasījuma ID, bet servera pusē — nemaināmu ziņojuma ID. Katrs straumes posms papildus saņem secīgu kārtas numuru. Ja pēc tīkla kļūdas tas pats uzdevums tiek saņemts atkārtoti, serveris nedrīkst sākt otru neatkarīgu izpildi, bet tam jāatgriež esošais stāvoklis vai droši jāturpina process.

Identitātēm ir atšķirīgi uzdevumi: pieprasījuma ID padara rakstīšanas operāciju idempotentu, ziņojuma ID apzīmē rezultātu, bet kārtas numurs sakārto fragmentus. Ar laika zīmogu vien nepietiek, jo paralēli pieprasījumi var sadurties vai tikt saņemti ar kavēšanos.

Transporta un biznesa stāvokļa nošķiršana

Neatkarīgi no tā, vai tiek izmantoti Server-Sent Events, Fetch straumes vai WebSockets, biznesa loģikas dzīves cikls nemainās. Modelējiet vismaz šādus stāvokļus: pieņemts, darbojas, pabeigts, atcelts un neizdevies. Tikai skaidri izteikts pabeigšanas notikums padara atbildi saistošu. Savukārt TCP savienojuma beigas automātiski nenozīmē veiksmīgu izpildi.

Server-Sent Events gadījumā HTML standarts apraksta atkārtotu savienošanos un pēdējā notikuma ID nodošanu. Šis mehānisms ir noderīgs, taču tas neaizstāj servera puses vēsturi. Serverim ir jāzina, kuri fragmenti pieder pie ziņojuma un vai atkārtota pieprasījuma gadījumā drīkst izlaist jau izvadītās secības.

Atkārtota savienošanās bez teksta dublēšanās

Saglabājiet ierobežotu notikumu buferi katram aktīvajam ziņojumam. Atkārtoti savienojoties, klients nosūta pēdējo apstiprināto secību. Serveris piegādā tikai vēlākos notikumus. Ja bufera derīguma termiņš ir beidzies, tas neatbild ar minētiem fragmentiem, bet gan ar pašreizējā pilnā teksta momentuzņēmumu (snapshot) un jaunu bāzes secību.

Klients apstrādā notikumus idempotenti: secības, kas ir mazākas vai vienādas ar pēdējo lietoto vērtību, tiek ignorētas. Lielāki robi izraisa momentuzņēmuma pieprasījumu. Tādējādi attēlojums paliek precīzs pat tad, ja starpniekserveris atkārto datus vai pārlūkprogramma atgriežas tiešsaistē pēc īsa bezsaistes perioda.

Daļējas atbildes nedrīkst izsaukt darbības

Straumētais teksts ir provizorisks. Saites vēl var būt nepilnīgas, ierobežojums var parādīties tikai nākamajā teikumā, un strukturētie rīku argumenti līdz beigām ir sintaktiski nederīgi. Renderējiet tekstu pakāpeniski, taču aktivizējiet riskantas darbības tikai pēc pabeigšanas un atsevišķas validācijas.

Tas īpaši attiecas uz pasūtījumiem, tikšanās reģistrāciju, klientu datu izmaiņām vai e-pastu sūtīšanu. Rīka izpildei ir nepieciešams savs idempotents darbības ID, tiesību pārbaude un, ja nepieciešams, redzams apstiprinājums. Atkārtota savienošanās nekādā gadījumā nedrīkst no jauna izpildīt to pašu darbību.

Pārtraukšanas kā īsta protokola notikuma apstrāde

Apturēšanas pogai vajadzētu darīt vairāk nekā tikai pauzēt vizuālo attēlojumu. Klients nosūta atcelšanas pieprasījumu ar ziņojuma ID; serveris atzīmē izpildi un pēc iespējas pārtrauc modeļa un rīku darbu. Vēlāk saņemtie fragmenti tiek atmesti. Saskarnē paliek skaidri redzams, ka atbilde tika pārtraukta.

Ja atcelšana nesasniedz serveri, darbs tur var turpināties. Tāpēc arī serveris regulāri pārbauda stāvokli. Izmaksu un latentuma metrikās pārtrauktie procesi būtu jāuzskaita atsevišķi, citādi tie parādīsies kā parastas kļūdas vai pilnībā pazudīs no analīzes.

Padariet kļūdas saprotamas un atkārtojamas

Nošķiriet vismaz tīkla pārtraukumu, noildzi, nodrošinātāja kļūdu, drošības bloku un biznesa loģikas validāciju. Lietotājam paredzētajam ziņojumam nav jāatklāj iekšējās tehniskās detaļas, taču tajā jānorāda drošs nākamais solis. „Savienojums pārtraukts — atbildes saņemšana tiks atsākta“ ir kas cits nekā „Šī darbība netika izpildīta“.

Atkārtošanas poga pārņem sākotnējo pieprasījuma ID tikai tad, ja ir jāturpina tas pats process. Pilnīgi jaunai ģenerēšanai tiek izveidots jauns ID, un saskarne neattēlo abas versijas kā vienu rezultātu.

Nepārslogojiet ekrāna lasītājus ar katru žetonu (token)

Dinamiskajam saturam jābūt uztveramam palīgtehnoloģijām. WAI-ARIA šim nolūkam definē Live Regions un dažādus steidzamības līmeņus. Reģions, kas tiek atjaunināts ar katru žetonu un izmanto aria-live var radīt simtiem pārtraukumu. Labāks risinājums ir vizuāls straumēšanas indikators ar atsevišķu, pieklājīgu (polite) statusa kanālu.

Piemēram, paziņojiet „Atbilde tiek veidota“, pēc tam saprātīgos intervālos paziņojiet par pabeigtu teikumu vai rindkopu, un beigās — „Atbilde ir pilnīga“. Izmantojiet aria-live="polite" parastam progresam; assertive ir piemērots tikai patiešām steidzamām kļūdām. Fokuss paliek ievades laukā vai lietotāja izvēlētajā vietā un nelēkā līdzi katram fragmentam.

Iestatiet aria-busy="true" atbildes apgabalā, kamēr saturs ir nepilnīgs, un noņemiet to pie atomārās pabeigšanas. Apturēšanas pogai ir nepieciešams skaidrs nosaukums, un tai jābūt pieejamai ar tastatūru. Pārbaudiet arī pielāgojumus samazinātai kustībai, tālummaiņai un maziem mobilajiem ekrāniem.

Mērķtiecīga stāvokļu mašīnas testēšana

Ar „veiksmīgā ceļa“ (Happy Path) testu nepietiek. Automatizējiet vismaz šos gadījumus:

• Pārtraukt savienojumu pēc vairākiem fragmentiem un turpināt bez teksta dublēšanās.
• Piegādāt vienu un to pašu notikumu divreiz un lietot to tikai vienreiz.
• Izlaist vienu secību un pieprasīt momentuzņēmumu.
• Apturēt cilni, nomainīt tīklu un pēc tam parādīt pareizo pabeigšanas stāvokli.
• Atcelt procesu rīka sagatavošanas laikā un neizpildīt nekādas darbības.
• Atzīmēt noildzi kā nepilnīgu pēc redzamas daļējas atbildes.
• Pārbaudīt ekrāna lasītāja paziņojumu biežumu un fokusa uzvedību.

Mēriet laiku līdz pirmajam redzamajam posmam, laiku līdz pilnīgai pabeigšanai, atkārtotas savienošanās īpatsvaru, dublētās vai atmestās secības un atcelšanas veiksmi. Laiks līdz pirmajam žetonam pats par sevi var izskatīties labs, lai gan daudzas atbildes nekad netiek uzticami pabeigtas.

Pakāpenisks ieviešanas plāns

1. Definēt ziņojumu un notikumu stāvokļus servera pusē.
2. Ieviest idempotentus ID un secības pirms UI animācijas.
3. Papildināt ar atkārtotu savienošanos, buferi un momentuzņēmumu rezerves opciju.
4. Stingri nošķirt rīku darbības no provizriskā teksta.
5. Pārbaudīt statusa ziņojumus ar tastatūru un ekrāna lasītāju.
6. Testēt kļūmju gadījumus ierobežotā un mainīgā tīklā.
7. Tikai pēc tam pakāpeniski aktivizēt straumēšanu reālajai lietotāju plūsmai.

Secinājums: Ātri redzams, viennozīmīgi pabeigts

Laba straumēšana apvieno uztveramo ātrumu ar skaidru patiesuma modeli. Pastāvīgi ID, sakārtoti notikumi, atomāra pabeigšana un droša atkārtota savienošanās novērš dubultas vai pusmācītas atbildes. Savaldīgs Live Region padara procesu pieejamu, nepārtraucot ekrāna lasītāja lietotājus ar katru žetonu.

Nākamajā solī pārbaudiet reālu tērzēšanu nestabilā mobilajā tīklā. Ja pēc pārtraukuma un atkārtotas savienošanās nav skaidri zināms, kurš ziņojums ir pilnīgs un kura darbība faktiski tika izpildīta, vispirms ir jāsalabo protokols — nevis ielādes animācija.

Avoti

• WHATWG HTML standarts: Server-Sent Events
• MDN Web Docs: Streams API
• W3C: WAI-ARIA 1.2
• W3C WAI: Statusa ziņojumi ar ARIA Live Regions