Patikimas DI pokalbių botų srauto perdavimas: ryšio atkūrimas, daliniai atsakymai ir prieinami būsenos pranešimai

Srauto perdavimas (angl. streaming) suteikia įspūdį, kad DI pokalbių botas veikia greičiau, nes pirmeji žodžiai pasirodo dar prieš apskaičiuojant visą atsakymą. Techniškai dėl to susidaro paskirstytas procesas: serveris, modelio teikėjas, įgaliotasis serveris (proxy), naršyklė ir vartotojo sąsaja kelioms sekundėms ar minutėms kartu palaikoma bendrą būseną. Mobilusis ryšys keičia tinklą, kortelė pereina į foninį režimą, proxy serveris nutraukia pasyvų ryšį arba vartotojas netyčia išsiunčia užklausą dar kartą. Be aiškaus protokolo teksto dalys pradeda dubliuotis, nepilni teiginiai pažymimi kaip užbaigti arba ta pati įrankio veikla iššaukiama dukart.

Todėl patikimas svetainės pokalbių botas srauto perdavimą traktuoja kaip būsenų mašiną, o ne kaip animaciją. Šiame vadove parodoma, kaip tarpusavyje sąveikauja įvykių ID, darbo atnaujinimas, atominis užbaigimas ir nuoseklūs ekrano skaitytuvų pranešimai.

Pranešimui reikalingas nuolatinis identifikatorius

Siunčiant priskirkite kliento pusės užklausos ID, o serverio pusėje – nekintamą pranešimo ID. Kiekviena srauto dalis papildomai gauna eilės sekos numerį. Jei dėl ryšio klaidos ta pati užduotis gaunama vėl, serveris neturi pradėti antro nepriklausomo proceso – jis privalo grąžinti esamą būseną arba saugiai ją tęsti.

Identifikatoriai atlieka skirtingas užduotis: užklausos ID užtikrina rašymo operacijos idempotentiškumą, pranešimo ID apibūdina rezultatą, o sekos numeris sutvarko fragmentus. Vien laiko žymos nepakanka, nes lygiagrečios užklausos gali susidurti arba vėluoti.

Transportavimo ir funkcinės būsenos atskyrimas

Nesvarbu, ar naudojate Server-Sent Events, Fetch srautus, ar WebSockets – funkcinis gyvavimo ciklas nesikeičia. Modeliuokite bent šias būsenas: priimta, vykdoma, užbaigta, atšaukta ir nesėkminga. Tik aiškus užbaigimo įvykis padaro atsakymą galutinį. Tuo tarpu TCP ryšio pabaiga automatiškai nereiškia sėkmės.

Server-Sent Events atveju HTML standartas aprašo pakartotinį prisijungimą ir paskutinio įvykio ID perdavimą. Šis mechanizmas naudingas, tačiau nepakeičia istorijos saugojimo serverio pusėje. Serveris turi žinoti, kurie fragmentai priklauso pranešimui ir ar pakartotinio gavimo metu galima praleisti jau išvestas sekas.

Ryšio atstatymas be teksto dubliavimosi

Išsaugokite ribotą įvykių buferį kiekvienam vykdomam pranešimui. Atkuriant ryšį, klientas siunčia paskutinę patvirtintą seką. Serveris pateikia tik vėlesnius įvykius. Jei buferio laikas pasibaigė, jis atsako ne spėjamais fragmentais, o dabartinio viso teksto momentine nuotrauka (snapshot) ir nauja bazine seka.

Klientas apdoroja įvykius idempotentiškai: sekos, mažesnės arba lygios paskutinei pritaikytai reikšmei, yra ignoruojamos. Didesni tarpai iššaukia snapshot užklausą. Taip vaizdas išlieka teisingas net jei proxy pakartoja duomenis arba naršyklė grįžta po trumpo buvimo neprisijungus.

Daliniai atsakymai neturi iššaukti veiksmų

Srautu perduodamas tekstas yra preliminarus. Nuorodos dar gali būti nepilnos, apribojimas gali pasirodyti tik kitame sakinyje, o struktūrizuoti įrankio argumentai iki pat pabaigos sintaksiškai negalioja. Renderinkite tekstą palaipsniui, tačiau rizikinguosius veiksmus aktyvuokite tik po galutinio užbaigimo ir atskiro patikrinimo.

Tai ypač galioja užsakymams, laiko rezervacijoms, klientų duomenų keitimui ar el. laiškų siuntimui. Įrankio vykdymui reikalingas atskiras idempotentinis veiksmo ID, teisių patikrinimas ir, jei reikia, matomas patvirtinimas. Ryšio atkūrimas niekada neturi iššaukti to paties poveikio iš naujo.

Nutraukimą traktuokite kaip tikrą protokolo įvykį

Sustabdymo mygtukas neturėtų tik sustabdyti vaizdo rodymo. Klientas išsiunčia atšaukimo užklausą su pranešimo ID; serveris pažymi procesą ir, jei įmanoma, nutraukia modelio bei įrankių darbą. Vėliau gauti fragmentai atmetami. Sąsajoje lieka aiškiai matoma, kad atsakymas buvo atšauktas.

Jei atšaukimas nepasiekia serverio, ten darbas gali tęstis toliau. Todėl serveris taip pat reguliariai tikrina būseną. Kaštų ir delsos rodikliuose atšauktus procesus reikėtų skaičiuoti atskirai, kitaip jie atrodys kaip įprastos klaidos arba visiškai dings iš analizės.

Padarykite klaidas suprantamas ir pakartojamas

Askirkite bent tinklo sutrikimą, laiko viršijimą, teikėjo klaidą, saugos blokavimą ir funkcinį patikrinimą. Pranešimas vartotojui neturi atskleisti vidinių techninių detalių, tačiau turėtų nurodyti saugų kitą žingsnį. „Ryšys nutrūko – atsakymas atnaujinamas“ yra kas kita nei „Šis veiksmas nebuvo atliktas“.

Pakartojimo mygtukas perima pradinį užklausos ID tik tada, kai norima tęsti tą patį procesą. Tikram naujam generavimui sukuriamas naujas ID, o sąsaja nerodo abiejų versijų kaip vieno rezultato.

Neperkraukite ekrano skaitytuvo kiekvienu tokenu

Dinaminis turinys turi būti suprantamas pagalbinėms technologijoms. WAI-ARIA tam apibrėžia Live Regions ir skirtingus skubumo lygius. Kiekvienu tokenu atnaujinama sritis su aria-live gali sukelti šimtus pertrūkių. Geresnis sprendimas – vizualus srauto rodinys su atskiru, mandagiu būsenos kanalu.

Pavyzdžiui, praneškite „Atsakymas kuriamas“, tada protarpiais pateikite užbaigtą sakinį ar pastraipą, o pabaigoje – „Atsakymas baigtas“. Naudokite aria-live="polite" įprastai pažangai; assertive tinka tik tikrai skubioms klaidoms. Fokusas lieka įvesties lauke arba vartotojo pasirinktoje vietoje ir nešokinėja su kiekvienu fragmentu.

Nustatykite aria-busy="true" atsakymo srityje, kol turinys nėra pilnas, ir pašalinkite jį ties atominiu užbaigimu. Sustabdymo mygtukui reikalingas aiškus pavadinimas ir jis turi būti pasiekiamas klaviatūra. Taip pat patikrinkite sumažinto judesio režimą, mastelio keitimą ir mažus mobiliuosius ekranus.

Tikslingai išbandykite būsenų mašiną

Sėkmingo scenarijaus (happy-path) testo nepakanka. Automatizuokite bent šiuos atvejus:

• Nutraukti ryšį po kelių fragmentų ir tęsti be teksto dubliavimosi.
• Pateikti tą patį įvykį dukart ir pritaikyti tik vieną kartą.
• Praleisti vieną seką ir pareikalauti snapshot.
• Sustabdyti kortelę, pakeisti tinklą ir po to parodyti teisingą užbaigimą.
• Atšaukti įrankio paruošimo metu ir neatlikti jokio poveikio.
• Laiko viršijimą po matomo dalinio atsakymo pažymėti kaip nebaigtą.
• Patikrinti ekrano skaitytuvo išvesties dažnumą ir fokuso elgseną.

Fiksuokite laiką iki pirmo matomo segmento, laiką iki pilno užbaigimo, ryšio atkūrimo rodiklį, dubliuotus ar atmestus fragmentus bei atšaukimo sėkmę. Laikas iki pirmo tokeno vienas pats gali atrodyti gerai, nors daugelis atsakymų taip ir nebus patikimai užbaigti.

Palaipsnio įdiegimo planas

1. Apibrėžti pranešimų ir įvykių būsenas serverio pusėje.
2. Įdiegti idempotentinius ID ir sekas prieš UI animaciją.
3. Papildyti ryšio atstatymą buferiu ir snapshot atsarginiu variantu.
4. Griežtai atskirti įrankių veiksmus nuo preliminaraus teksto.
5. Patikrinti būsenos pranešimus klaviatūra ir ekrano skaitytuvu.
6. Išbandyti klaidos atvejus lėtame ir besikeičiančiame tinkle.
7. Tik po to palaipsniui įjungti srauto perdavimą gamybiniam srautui.

Išvada: Greitai matoma, aiškiai užbaigta

Geras srauto perdavimas sujungia matomą greitį su aiškiu teisingumo modeliu. Nuolatiniai ID, sutvarkyti įvykiai, atominis užbaigimas ir saugus ryšio atkūrimas apsaugo nuo dubliuotų ar pusinių atsakymų. Nuosekli Live sritis daro procesą prieinamą, neblaškant ekrano skaitytuvų naudotojų ties kiekvienu tokenu.

Toliau išbandykite realų pokalbį nestabiliame mobiliajame tinkle. Jei nutrūkus ir atkūrus ryšį nėra visiškai aišku, kuris pranešimas yra pilnas ir koks veiksmas iš tikrųjų buvo atliktas, pirmiausia reikia sutvarkyti protokolą, o ne krovimo animaciją.

Šaltiniai

• WHATWG HTML standartas: Server-Sent Events
• MDN Web Docs: Streams API
• W3C: WAI-ARIA 1.2
• W3C WAI: Būsenos pranešimai su ARIA Live Regions