DI pokalbių roboto atsako laiko optimizavimas: vėlavimo biudžetas, srautas ir laiko limitai

Teisingas pokalbių boto atsakymas mažai tepadeda, jei lankytojai laukdami išeina arba tą patį klausimą siunčia kelis kartus. DI pokalbių roboto atsako laikas susideda ne tik kalbos modelyje. Tinklas, sesijos patikrinimas, žinių paieška, išoriniai įrankiai, modelio paleidimas ir išvestis susideda į vieną juntamą vėlavimą.

Todėl svetainės pokalbių botui reikia daugiau nei tik noro „tapti greitesniam“. Prasminga turėti išmatuojamą vėlavimo biudžetą, aiškias nutraukimo taisykles ir sąsają, kuri anksti suteikia suprantamą grįžtamąjį ryšį. Šiame vadove parodyta, kaip produkto, palaikymo ir kūrimo komandos nustato prioritetus siaurosiose vietose, nepaaukodamos atsakymo kokybės ar veikimo saugumo.

Kodėl vidurkis paslepia tikrąjį laukimo laiką

Vidutinė vertė gali atrodyti gerai, nors didelė pokalbių dalis užtrunka gerokai ilgiau. „Google Research“ šią problemą apibūdina kaip „Tail Latency“: paskirstytose paslaugose lėti nukrypimai dažnai lemia patiriamą našumą. Todėl pokalbių botams prasmingi bent jau meidana, P95 ir P99 rodikliai. P95 reiškia: 95 procentai išmatuotų atsakymų yra žemiau šios vertės, penki procentai – virš.

Papildomai komandos turėtų atskirti du laiko momentus. Time to First Token arba bendriau „laikas iki pirmojo naudingo turinio“ apibūdina, kada vartotojas pirmą kartą pamato turinio reakciją. Bendradarbiavimo trukmė baigiasi tik tada, kai atsakymas yra visiškai baigtas. Greitai prasidedantis, tvarkingai transliuojamas atsakymas gali atrodyti gerokai greitesnis nei tokios pat trukmės atsakymas, kuris visas pasirodo tik pabaigoje. Tačiau srautas nepakeičia priežasčių analizės: jei žinių paieška ar įrankių iškvietimai užtrunka per ilgai, pirmasis prasmingas sakinys taip pat pasirodys vėlai.

Vėlavimo biudžetas apima visą atsako grandinę

Vėlavimo biudžetas paskirsto maksimaliai priimtiną laukimo laiką žingsniams, kuriuos praeina atsakymas. Tai nėra visuotinė pramonės vertė, o produkto sprendimas kiekvienam naudojimo atvejui. Trumpas DUK atsakymas gali turėti griežtesnį biudžetą nei patikrinta informacija apie produktą iš kelių duomenų šaltinių.

Atsako grandinės padalijimas į atskiras fazes

Praktinis 4000 milisekundžių vidinio bendrojo biudžeto pavyzdys galėtų rezervuoti 300 milisekundžių naršyklei ir tinklui, 500 milisekundžių sesijos bei taisyklių patikrinimui, 900 milisekundžių žinių paieškai ar įrankių iškvietimams, 1200 milisekundžių iki pirmojo modelio turinio ir 1100 milisekundžių tolesnei išvesčiai arba kontroliuojamam atsarginiam scenarijui. Šios vertės yra skaičiavimo pavyzdys, o ne rekomendacija. Svarbiausia, kad kiekviena fazė turėtų savininką, matavimo tašką ir nutraukimo kelią.

• Frontend ir transportavimas: įkelti valdiklį (widget), perduoti užklausą ir išlaikyti ryšį atvirą.
• Orkestravimas: nustatyti kalbą, leidimus, ketinimą ir saugumo taisykles.
• Žinios ir įrankiai: ieškoti tinkamų šaltinių, teirautis produkto ar susitikimų duomenų.
• Generavimas: apdoroti kontekstą ir sukurti pirmąjį patikimą turinį.
• Išvestis: transliuoti srautu, papildyti šaltinius, rodyti baigiamąją būseną ir galimą perdavimą.

Tas, kas matuoja tik bendrą trukmę, nemato, ar lėtas atsakymas gautas iš didelio konteksto, nuoseklios įrankių grandinės ar perkrautos trečiosios šalies paslaugos. Todėl susiekite kiekvieną pokalbį su anonimizuotu Trace-ID ir išsaugokite kiekvienos fazės trukmę, rezultatą ir nutraukimo priežastį. Čia galioja tos pačios duomenų taupymo taisyklės kaip ir kitiems Chatbot-Analytics.

Srauto perdavimas (streaming) pagerina juntamą reakciją

WHATWG Streams specifikacija apibrėžia žiniatinklio sąsajas palaipsniui skaitomiems ir rašomiems duomenims bei Backpressure. Pokalbių botui tai reiškia: serveris gali pateikti atsakymo dalis, kai tik jos paruoštos, o naršyklei nereikia laukti viso teksto. Tai ypač naudinga, kai ilgesnis paaiškinimas yra neišvengiamas.

Geras srauto perdavimas neprasideda tuščiais žodžiais. Pirmoje matomoje dalyje turėtų būti arba naudingas turinys, arba sąžiningai paaiškintas dabartinis darbo žingsnis, pavyzdžiui, „Tikrinu prieinamumą ir variantus“. Ji negali imituoti saugumo, kol šaltinis dar neatsakė. Jei vėliau įvyksta klaida, sąsajai reikia aiškaus užbaigimo, o ne be galo mirksinčio žymeklio.

Suprantamam grįžtamajam ryšiui pakanka trijų būsenų

1. Gauta: Klausimas gautas ir dar gali būti atšauktas.
2. Tikrinama: Pokalbių botas ieško žinių arba laukia nurodytos sistemos.
3. Atsakoma: Patikrintas turinys pateikiamas žingsnis po žingsnio.

Mobiliuose įrenginiuose dabartinis tekstas turėtų išlikti stabilus. Dažni išdėstymo šuoliai, automatiškai priverstinis slinkimas arba nuolat auganti įvesties sritis greitą techninį atsakymą subjektyviai paverčia lėtu.

Įrankių iškvietimai priklauso kritiniam keliui

Daugelis svetainių pokalbių botų paeiliui iškviečia paiešką, CRM, kalendorių, produkto duomenis arba bilietų sistemą. Kiekvienas papildomas nuoseklus žingsnis padidina galimą bendrą trukmę. Todėl orkestratorius turėtų paleisti tik tuos įrankius, kurie būtini konkrečiam klausimui. Nepriklausomos skaitymo prieigos gali veikti paraleliai; priklausomi iškvietimai sąmoningai lieka nuoseklūs.

Taip pat apibrėžkite įrankių žingsnių ir duomenų kiekio limitą. Klausimui apie produktą gali prireikti kainos ir likučio, bet ne visos kliento istorijos tuo pačiu metu. Siauras, patikrintas kontekstas dažnai yra greitesnis ir lengviau patikrinamas nei didelis kontekstas su netinkamais dokumentais. Kaip saugiai tvarkomos dabartinės produkto vertės, aprašyta straipsnyje apie produkto duomenis DI pokalbių roboto sistemoje.

Lėtoms priklausomybėms tinka „Circuit Breaker“ (grandinės pertraukiklis): po pakartotinių klaidų ar laiko viršijimo nauji iškvietimai kurį laiką nebeperduodami. Tada pokalbių botas pereina į apibrėžtą pakaitinį kelią. Tai apsaugo vartotojus nuo ilgų tų pačių klaidų grandinių ir palengvina jau sutrikusios sistemos apkrovą.

Laiko limitai ir pakartojimai turi derėti tarpusavyje

Laiko limitas (timeout) apriboja, kiek laiko žingsnis gali naudoti resursus ir dėmesį. Jis turėtų būti pagrįstas stebimais vykdymo laikais ir likusiu bendru biudžetu. Išorinė paslauga negali išeikvoti beveik viso biudžeto, jei po to dar seka generavimas ir išvestis.

Pakartojimai (retries) turi prasmę tik esant laikinoms klaidoms ir saugiai pakartojamoms operacijoms. „AWS Builders’ Library“ įspėja, kad nekontroliuojami pakartotiniai bandymai gali padidinti jau perkrautos sistemos (backend) apkrovą. Rekomenduojami apriboti bandymai, atsitraukimas (backoff) ir Jitter; atliekant operacijas su šalutiniu poveikiu, lemiama yra idempotencija. Laiko viršijimas neįrodo, kad pirmoji užduotis liko be poveikio.

Esant HTTP 429 klaidai, paslauga pagal RFC 6585 gali nurodyti Retry-After, kada prasminga bandyti vėl. Pokalbių botas turėtų gerbti šią informaciją. Aklas momentinis pakartojimas pablogina tiek vėlavimą, tiek stabilumą. Rašymo veiksmams, tokiems kaip rezervacijos ar bilietų kūrimas, papildomai reikia idempotencijos rakto ir vienareikšmės būsenos užklausos.

Dalinis atsakymas ir perdavimas žmogui lenkia begalinį laukimo ciklą

Jei pasirinktinė paslauga viršija savo biudžetą, ne kiekvienas atsakymas turi visiškai žlugti. Pokalbių botas gali pateikti patvirtintą dalinę informaciją, matomai įvardyti trūkstamus duomenis ir pasiūlyti kitą veiksmą. Pavyzdys: „Produkto aprašymas yra prieinamas; dabartinio likučio šiuo metu negalėjau patvirtinti.“ Tai geriau nei sugalvotas skaičius arba neapibrėžtas „Prašome palaukti“.

Dėl pirkimo sprendimams svarbių, asmeninių ar laiko atžvilgiu jautrių duomenų po laiko limito viršijimo turėtų būti siūlomas žmogaus kanalas. Perduodami tik būtini pokalbio duomenys ir konkreti klaidos būsena. Suplanuotas Human Handoff yra našumo architektūros dalis, o ne tik avarinis sprendimas.

Tinkami rodikliai sujungia technologiją ir vartotojo patirtį

Patikima stebėsena segmentuoja pagal klausimo tipą, kalbą/regioną (locale), įrenginį, modelio maršrutą ir naudojamus įrankius. Priešingu atveju paprasti DUK atsakymai susimaišo su sudėtingomis transakcijomis ir rodiklis praranda savo naudingumą. Kartu turėtų būti vertinami bent šie matavimai:

• Laikas iki pirmojo naudingo turinio, atitinkamai kaip mediana, P95 ir P99;
• Bendra trukmė iki atsakymo užbaigimo;
• Kiekvienos paieškos ir įrankio žingsnio trukmė bei laukimo laikas tarp srauto blokų;
• Laiko limitų, pakartotinimų, Circuit Breaker atvejų ir nutrauktų pokalbių dalis;
• Dalinio atsakymo ir perdavimo žmonėms dalis;
• Tų pačių testo atvejų atsakymo kokybė ir šaltinių padengimas.

Greitis negali būti optimizuojamas izoliuotai. Jei trumpesnis kontekstas sutaupo vėlavimo laiko, tačiau sumažina atitikimo kokybę, problema tik pasislenka. Todėl naudokite fiksuotą „Golden Set“ ir paralelia patikrinkite Chatbot-Antwortqualität.

Apkrovos testams reikia realių pokalbių modelių

Vienas greitas testas nedaug ką įrodo. Išbandykite tipiškus DUK klausimus, dviprasmiškus klausimus, ilgus dialogus, įrankių iškvietimus, klaidingas priklausomybes ir kelias kalbas. Šaltus ir šiltus kelius matuokite atskirai, nes podėlis (cache), ryšiai ir modelio kontekstas gali veikti skirtingai. Taip pat simuliuokite piko apkrovą neapkraudami nekontroliuojamų gamybinių trečiųjų šalių sistemų.

Kiekvienai pagrindinei kelionei priėmimo kriterijus turėtų nustatyti, koks P95 tikslas galioja, kada turi pasirodyti būsenos pranešimas ir koks atsarginis scenarijus yra priimtinas. Dirbtinai uždelstas įrankio stub padeda patikrinti, ar laiko limitas, dalinis atsakymas ir perdavimas tikrai veikia. Taip diagrama tampa patikrinama eksploatavimo sutartimi.

Praktinis įgyvendinimo kontrolinis sąrašas

1. Dokumentuoti visą atsako grandinę nuo naršyklės iki paskutinio šaltinio.
2. Atskirai matuoti „Time to First Token“ ir bendrą trukmę.
3. Nustatyti biudžetus pagal klausimo tipą ir techninį žingsnį.
4. Paralelizuoti nepriklausomas skaitymo prieigas ir apriboti įrankių žingsnius.
5. Suprojektuoti srauto perdavimą su stabiliomis būsenomis, nutraukimu ir klaidų užbaigimu.
6. Išvesti laiko limitus iš matavimo duomenų ir įterpti į bendrą biudžetą.
7. Pakartotinius bandymus naudoti tik ribotai, su „backoff“, „jitter“ ir idempotencija.
8. Išbandyti dalinį atsakymą, „Circuit Breaker“ ir perdavimą žmogui.
9. Stebėti P95 ir P99 pagal kalbą/regioną, įrenginį ir klausimo tipą.
10. Kiekvieną greičio pokytį patikrinti pagal atsakymo kokybę ir šaltinius.

Išvada: Greiti atsakymai yra produkto pažadas

Geras DI pokalbių roboto atsako laikas atsiranda dėl daugelio mažų, išmatuojamų sprendimų: realistinio biudžeto, trumpos kritinės įrankių grandinės, ankstyvo prasmingo srauto perdavimo, saugių laiko limitų ir sąžiningo atsarginio scenarijaus. Kas žiūri tik į modelį, nepastebi didelės laukimo laiko dalies.

Naudodamos ChatReact, svetainių komandos gali planuoti patikimus pokalbių botų atsakymus kaip savo palaikymo ir informavimo procesų dalį. Pradėkite nuo centrinės vartotojo kelionės, išmatuokite jos P95 vertę ir pirmiausia pašalinkite lėčiausią kontroliuojamą žingsnį.

Šaltiniai

• Google Research: The Tail at Scale
• AWS Builders’ Library: Timeouts, pakartotiniai bandymai ir „Backoff with Jitter“
• RFC 6585: Additional HTTP Status Codes
• WHATWG Streams Standard