Töökindla AI-juturoboti striimimise ehitamine: taasühendus, osavastused ja ligipääsetavad olekuteated

Striimimine paneb AI-juturoboti kiiremini toimima, sest esimesed sõnad ilmuvad enne, kui kogu vastus on valmis arvutatud. Tehniliselt tekib aga nii hajutatud protsess: server, mudelipakkuja, proksi, veebibrauser ja kasutajaliides hoiavad teatud sekundeid või minuteid ühist olekut. Mobiilside vahetab võrku, vahekaart läheb taustale, proksi lõpetab tegevuseta ühenduse või kasutaja saadab päringu kogemata uuesti. Ilma selge protokollita kuvatakse siis tekstriilud topelt, poolikud väited märgitakse täielikuks või käivitatakse sama tööriistatoiming kaks korda.

Töökindel veebisaidi juturobot käsitleb striimimist seetõttu olekumasinana, mitte animatsioonina. See juhend näitab, kuidas sündmuste ID-d, taastamine, atomaarne lõpetamine ja tagasihoidlikud ekraanilugeja teated omavahel kokku sobivad.

Sõnum vajab püsivat identiteeti

Määrake saatmisel kliendipoolne päringu ID ja serveri poolel muutumatu sõnumi ID. Iga striimi lõik saab lisaks järjestikuse jada numbri. Kui sama ülesanne saabub pärast võrgutõrget uuesti, ei tohi server käivitada teist sõltumatut protsessi, vaid peab tagastama olemasoleva oleku või jätkama turvaliselt.

Identiteedid täidavad erinevaid ülesandeid: päringu ID muudab kirjutamistoimingu identselt korduvaks (idempotentseks), sõnumi ID tähistab tulemust ja jada number järjestab fragmente. Pelgalt ajatemplist ei piisa, sest paralleelsed päringud võivad põrkuda või kohale jõuda hilinemisega.

Eraldage transport ja sisuline olek

Sõltumata sellest, kas kasutatakse Server-Sent Eventsi, Fetch-striime või WebSocketeid, ei muuda see äriloogika elutsüklit. Modelleerige vähemalt olekud vastu võetud, käib, lõpetatud, katkestatud ja ebaõnnestunud. Ainult selgesõnaline lõpetamissündmus muudab vastuse siduvaks. TCP-ühenduse lõpp ei tähenda seevastu automaatselt edu.

Server-Sent Eventsi puhul kirjeldab HTML-standard taasühendusi ja viimase sündmuse ID edastamist. See mehhanism on kasulik, kuid ei asenda serveripoolset ajalugu. Server peab teadma, millised fragmendid kuuluvad sõnumi juurde ja kas uus päring tohib juba väljastatud jadasid vahele jätta.

Taasühendus ilma dubleeritud tekstita

Salvestage piiratud sündmuste puhver iga käimasoleva sõnumi kohta. Taasühendusel saadab klient viimase kinnitatud jada. Server tarnib ainult hilisemad sündmused. Kui puhver on aegunud, ei vasta see arvatud fragmentidega, vaid praeguse täieliku teksti hetketõmmise (snapshot) ja uue baasjadaga.

Klient töötleb sündmusi idempotentseks: jadasid, mis on väiksemad või võrdsed viimati rakendatud väärtusega, eiratakse. Suuremad lüngad käivitavad hetketõmmise päringu. Nii jääb kuva õigeks ka siis, kui proksi kordab andmeid või brauser pööreerub tagasi pärast lühikest võrguühenduseta olekut.

Osavastused ei tohi käivitada toiminguid

Striimitav tekst on esialgne. Lingid võivad olla veel puudulikud, täpsustus võib ilmuda alles järgmises lauses ja struktureeritud tööriista argumendid on kuni lõpuni süntaktiliselt vigased. Renderdage teksti järk-järgult, kuid aktiveerige riskantsed toimingud alles pärast lõpetamist ja eraldi valideerimist.

See kehtib eriti tellimuste, aegade broneerimise, kliendiandmete muutmise või e-kirjade saatmise kohta. Tööriista käivitamine vajab oma idempotentset toimingu ID-d, õiguste kontrolli ja vajadusel nähtavat kinnitust. Taasühendus ei tohi kunagi sama mõju uuesti täide viia.

Käsitlege katkestamist tõelise protokolli sündmusena

Stopp-nupp ei peaks peatama ainult kuvamist. Klient saadab sõnumi ID-ga katkestamispäringu; server märgib protsessi ja lõpetab võimalusel mudeli ning tööriista töö. Hiljem saabuvad fragmendid visatakse ära. Kasutajaliideses jääb nähtavaks, et vastus katkestati.

Kui katkestus ei jõua serverini, võib seal töö edasi kesta. Seetõttu kontrollib ka server regulaarselt olekut. Kulu- ja latentsusmõõdikud peaksid katkestatud protsesse loendama eraldi, muidu kuvatakse neid nagu tavalisi vigu või need kaovad analüütikast täielikult.

Tehke vead arusaadavaks ja korduvaks

Eristage vähemalt võrgukatkestust, aegumist, teenusepakkuja viga, turvablokeeringut ja sisulist valideerimist. Kasutajateade ei pea avaldama sisemist tehnikat, kuid peaks nimetama turvalise järgmise sammu. „Ühendus katkestatud – vastuse genereerimist jätkatakse“ on midagi muud kui „Seda toimingut ei teostatud“.

Uuesti proovimise nupp võtab algse päringu ID üle ainult siis, kui soovitakse jätkata sama protsessi. Tõeliseks uueks genereerimiseks luuakse uus ID ja kasutajaliides ei kuva mõlemat versiooni ühe tulemusena.

Ärge ülekoormake ekraanilugejat iga tokeniga

Dünaamiline sisu peab olema abitehnoloogiatele tajutav. WAI-ARIA määratleb selleks Live Regionid ja erinevad kiireloomulisuse tasemed. Tokeni kaupa värskendatav piirkond omadusega aria-live võib aga tekitada sadu katkestusi. Parem on visuaalne striimimise kuva koos eraldiseisva, viisaka olekukanaliga.

Teatage näiteks „Vastust koostatakse“, seejärel mõistlike vaheaegade järel valmis lausest või lõigust ning lõpus „Vastus valmis“. Kasutage aria-live="polite" tavaliste märkide puhul; assertive sobib ainult tõesti kriitiliste vigade jaoks. Fookus jääb sisestusväljale või kasutaja valitud kohta ega hüppa iga fragmendiga.

Määrake aria-busy="true" vastuse alale seni, kuni sisu on puudulik, ja eemaldage see atomaarsel lõpetamisel. Stopp-nupp vajab selget nime ja peab olema kättesaadav klaviatuuriga. Kontrollige lisaks vähendatud liikumist, suumi ja väikeseid mobiilivaateid.

Olekumasina sihipärane testimine

Tavalise edukuse tsükli (happy path) testimisest ei piisa. Automatiseerige vähemalt need juhtumid:

• Katkestage ühendus pärast mitut fragmenti ja jätkake ilma dubleeritud tekstita.
• Tarnige sama sündmus kaks korda ja rakendage seda ainult ühe korra.
• Jätke jada vahele ja küsige hetketõmmist.
• Peatage vahekaart, vahetage võrku ja kuvage pärast seda õige lõpetamine.
• Katkestage tööriista ettevalmistamise ajal ega viige mõju täide.
• Märkige aegumine pärast nähtavat osavastust puudulikuks.
• Kontrollige ekraanilugeja väljundeid mõistliku sageduse ja fookuse käitumise suhtes.

Mõõtke aega esimese nähtava lõiguni, aega täieliku lõpetamiseni, taasühenduste määra, dubleeritud või kõrvale jäetud jadasid ning katkestamise edukust. Aeg esimese tokenini võib üksi hea välja näha, kuigi paljud vastused ei saa kunagi usaldusväärselt valmis.

Järkjärguline juurutusplaan

1. Määratlege sõnumi- ja sündmuseolekud serveri poolel.
2. Rakendage idempotentseid ID-sid ja jadasid enne UI animatsiooni.
3. Lisage taasühendus koos puhvri ja hetketõmmise varulahendusega.
4. Eraldage tööriista toimingud rangelt esialgsest tekstist.
5. Kontrollige olekuteateid klaviatuuri ja ekraanilugejaga.
6. Testige veajuhtumeid piiratud kiirusega ja muutuva võrguga.
7. Alles seejärel aktiveerige striimimine järk-järgult toodangukeskkonna liiklusele.

Kokkuvõte: Kiiresti nähtav, üheselt lõpetatud

Hea striimimine ühendab tajutava kiiruse selge tõemudeliga. Püsivad ID-d, järjestatud sündmused, atomaarne lõpetamine ja turvaline taasühendus hoiavad ära topelt- või poolikud vastused. Tagasihoidlik Live Region muudab protsessi kättesaadavaks, ilma ekraanilugeja kasutajat iga tokeniga segamata.

Testige järgmiseks reaalset vestlust ebastabiilses mobiilvõrgus. Kui pärast katkestust ja taasühendamist pole üheselt selge, milline sõnum on täielik ja milline toiming tegelikult teostati, vajab esmalt parandamist protokoll – mitte laadimisanimatsioon.

Allikad

• WHATWG HTML Standard: Server-Sent Events
• MDN Web Docs: Streams API
• W3C: WAI-ARIA 1.2
• W3C WAI: Olekuteated ARIA Live Regionitega