MI čatbota atbildes laika optimizēšana: latences budžets, straumēšana un noildzes

Pareiza čatbota atbilde maz palīdz, ja apmeklētāji gaidīšanas laikā pamet vietni vai nosūta to pašu jautājumu vairākas reizes. MI čatbota atbildes laiks neveidojas tikai valodas modelī. Tīkls, sesijas pārbaude, zināšanu meklēšana, ārējie rīki, modeļa palaišana un izvade summējas vienā uztvertajā aizkavē ar.

Tāpēc tīmekļa vietnes čatbotam ir nepieciešams kas vairāk par vēlmi "kļūt ātrākam". Lietderīgs ir mērāms latences budžets, skaidri pārtraukšanas noteikumi un saskarne, kas jau agri sniedz saprotamu atgriezenisko saiti. Šajā rokasgrāmatā parādīts, kā produktu, atbalsta un izstrādes komandas nosaka prioritātes šaurajām vietām, nezaudējot atbilžu kvalitāti vai darbības drošību.

Kāpēc vidējais rādītājs apslēpj faktisko gaidīšanas laiku

Vidējā vērtība var izskatīties labi, lai gan būtiska sarunu daļa ilgst ievērojami ilgāk. Google Research šo problēmu raksturo kā "Tail Latency": izplatītos pakalpojumos lēni izņēmuma gadījumi bieži vien nosaka faktiski pieredzēto veiktspēju. Tāpēc čatbotiem vismaz mediāna, P95 un P99 ir būtiski rādītāji. P95 nozīmē: 95 procenti no mērītajām atbildēm ir zem šīs vērtības, bet pieci procenti virs tās.

Papildus komandām vajadzētu nošķirt divus laika punktus. Time to First Token jeb vispārīgāk "laiks līdz pirmajam derīgajam saturam" raksturo brīdi, kad lietotājs pirmo reizi ierauga satura reakciju. Kopējais ilgums beidzas tikai tad, kad atbilde ir pilnīga. Ātri sākta, tīri straumēta atbilde var šķist daudz atsaucīgāka nekā tikpat ilga atbilde, kas parādās pilnībā tikai beigās. Taču straumēšana neaizstāj cēloņu analīzi: ja zināšanu meklēšana vai rīku izsaukumi aizņem pārāk ilgu laiku, arī pirmais jēgpilnais teikums parādīsies vēlu.

Latences budžets atspoguļo visu atbildes ķēdi

Latences budžets sadala maksimālo pieņemamo gaidīšanas laiku pa posmiem, kurus atbilde iziet. Tas nav universāls nozares rādītājs, bet gan produkta lēmums par katru lietošanas gadījumu. Īsai BJU (FAQ) atbildei var būt stingrāks budžets nekā pārbaudītai produkta informācijai ar vairākiem datu avotiem.

Atbildes maršruta sadalīšana atsevišķās fāzēs

Praktisks piemērs iekšējam kopējam budžetam 4000 milisekundes varētu rezervēt 300 milisekundes pārlūkam un tīklam, 500 milisekundes sesijas un politiku pārbaudei, 900 milisekundes zināšanu meklēšanai vai rīku izsaukumiem, 1200 milisekundes līdz pirmajam modeļa saturam un 1100 milisekundes turpmākajai izvadei vai kontrolētai rezerves opcijai (fallback). Šīs vērtības ir aprēķina piemērs, nevis ieteikums. Izšķiroši ir tas, ka katrai fāzei ir savs atbildīgais, mērījumu punkts un pārtraukšanas ceļš.

• Frontend un transports: logrīka ielāde, pieprasījuma pārsūtīšana un savienojuma uzturēšana atvērtā stāvoklī.
• Orķestrēšana: valodas, tiesību, nodoma un drošības noteikumu noteikšana.
• Zināšanas un rīki: piemērotu avotu meklēšana, produktu vai tikšanās datu pieprasīšana.
• Ģenerēšana: konteksta apstrāde un pirmā drošā satura izveide.
• Izvade: straumēšana, avotu pievienošana, pabeigšanas statusa un iespējamās nodošanas uzrādīšana.

Ja mēra tikai kopējo ilgumu, nav redzams, vai lēna atbilde rodas liela konteksta, seriālas rīku ķēdes vai pārslogota trešās puses pakalpojuma dēļ. Tāpēc saistiet katru sarunu ar anonimizētu izsekošanas ID (trace ID) un saglabājiet katras fāzes ilgumu, rezultātu un pārtraukšanas iemeslu. Šeit spēkā ir tie paši datu minimizēšanas noteikumi, kas citai čatbota analītikai.

Straumēšana uzlabo uztverto atsaucību

WHATWG Streams Specification definē tīmekļa saskarnes pakāpeniski lasāmiem un rakstāmiem datiem, kā arī pretspiedienam (backpressure). Čatbotam tas nozīmē: serveris var piegādāt atbildes daļas, tiklīdz tās ir gatavas, un pārlūkam nav jāgaida viss teksts. Tas ir īpaši noderīgi, ja ilgāks paskaidrojums ir neizbēgams.

Laba straumēšana nesākas ar tukšiem vārdiem. Pirmajā redzamajā daļā ir jābūt vai nu noderīgam saturam, vai godīgi jāpaskaidro pašreizējais darba posms, piemēram, "Es pārbaudu pieejamību un variantus". Tā nedrīkst tēlot drošību, pirms avots ir atbildējis. Ja vēlāk rodas kļūda, saskarnei ir nepieciešams skaidrs nobeigums, nevis bezgalīgi mirgojošs kursors.

Pietiek ar trim stāvokļiem saprotamai atgriezeniskajai saitei

1. Saņemts: jautājums ir saņemts un to vēl var atcelt.
2. Pārbauda: čatbots meklē zināšanas vai gaida nosaukto sistēmu.
3. Atbild: verificēts saturs tiek pakāpeniski izvadīts.

Mobilajās ierīcēs pašreizējam tekstam vajadzētu palikt stabilam. Bieži izkārtojuma lēcieni, automātiska piespiedu ritināšana vai pastāvīgi augoša ievades zona padara ātru meklēšanas tehnisko atbildi subjektīvi lēnu.

Rīku izsaukumi pieder kritiskajam ceļam

Daudzi tīmekļa vietņu čatboti secīgi izsauc meklēšanu, CRM, kalendāru, produkta datus vai biļešu sistēmu. Katrs papildu seriālais solis palielina iespējamo kopējo ilgumu. Tāpēc orķestratoram vajadzētu palaist tikai tos rīkus, kas ir nepieciešami konkrētajam jautājumam. Neatkarīgas lasīšanas piekļuves var darboties paralēli; atkarīgie izsaukumi apzināti paliek seriāli.

Definējiet arī rīku darbību un datu apjoma ierobežojumu. Produkta jautājumam var būt nepieciešama cena un krājumi, bet ne vienlaikus visa klienta vēsture. Šaurs, verificēts konteksts bieži ir ātrāks un vieglāk pārbaudāms nekā liels konteksts ar irrelevantiem dokumentiem. Par to, kā droši apstrādāt pašreizējās produktu vērtības, aprakstīts rakstā par produktu datiem MI čatbotā.

Lēnām atkarībām ir piemērots ķēdes pārtraucējs (Circuit Breaker): pēc atkārtotām kļūdām vai noildzēm jauni izsaukumi uz laiku vairs netiek pārsūtīti. Tad čatbots pārslēdzas uz definētu rezerves ceļu. Tas aizsargā lietotājus no ilgām vienādu kļūdu ķēdēm un atslogo jau tā ietekmēto sistēmu.

Noildzēm un atkārtotiem mēģinājumiem ir jāsaskan

Noildze (timeout) ierobežo, cik ilgi kāds posms drīkst patērēt resursus un uzmanību. Tās pamatā jābūt novērotajam izpildes laikam un atlikušajam kopējam budžetam. Ārējais pakalpojums nedrīkst patērēt gandrīz visu budžetu, ja pēc tam vēl jāseko ģenerēšanai un izvadei.

Atkārtoti mēģinājumi ir lietderīgi tikai īslaicīgu kļūdu un droši atkārtojamu operāciju gadījumā. AWS Builders’ Library brīdina, ka nekontrolēti atkārtoti mēģinājumi (retries) var pastiprināt jau tā pārslogota aizmugursistēmas (backend) slodzi. Ieteicami ir ierobežoti mēģinājumi, atpakaļatkāpšanās (backoff) un neprecizitāte (jitter); operācijām ar blakusparādībām izšķiroša nozīme ir idempotencei. Laika pārsniegums nepierāda, ka pirmais uzdevums palicis bez ietekmes.

HTTP 429 gadījumā pakalpojums saskaņā ar RFC 6585 ar Retry-After var norādīt, kad ir lietderīgs atkārtots mēģinājums. Čatbotam šī informācija būtu jāņem vērā. Akla, tūlītēja atkārtošana pasliktina gan latenci, gan stabilitāti. Rakstīšanas darbībām, piemēram, rezervācijām vai biļešu izveidei, papildus nepieciešama idempotences atslēga un skaidrs statusa pieprasījums.

Daļēja atbilde un nodošana cilvēkam ir labāka par bezgalīgu gaidīšanas cilpu

Ja izvēles pakalpojums pārsniedz savu budžetu, katrai atbildei nav pilnībā jāneizdodas. Čatbots var sniegt pārbaudītu daļēju informāciju, redzami nosaukt trūkstošos datus un piedāvāt nākamo darbību. Piemēram: "Produkta apraksts ir pieejams; pašreizējos krājumus šobrīd nevarēju apstiprināt." Tas ir labāk nekā izdomāts skaitlis vai nenoteikts "Lūdzu, uzgaidiet".

Lēmumu pieņemšanai par pirkumu, personu datiem vai laika ziņā kritiskām norādēm pēc noildzes jāpiedāvā cilvēka kanāls. Tiek nodoti tikai nepieciešamie sarunas dati un konkrētais kļūdas statuss. Plānota nodošana cilvēkam (Human Handoff) ir daļa no veiktspējas arhitektūras, nevis tikai ārkārtas risinājums.

Pareizie rādītāji savieno tehnoloģiju un lietotāja pieredzi

Uzticama pārraudzība segmentē pēc jautājuma veida, lokāles, ierīces, modeļa maršruta un izmantotajiem rīkiem. Pretējā gadījumā vienkāršas BJU atbildes sajaucas ar sarežģītām darījumu darbībām, un rādītājs zaudē savu nozīmi. Vismaz šie mērījumi būtu jāskata kopā:

• laiks līdz pirmajam derīgajam saturam (Time to First Token), attiecīgi kā mediāna, P95 un P99;
• kopējais ilgums līdz atbildes pabeigšanai;
• katra meklēšanas un rīka posma ilgums, kā arī gaidīšanas laiks starp straumes blokiem;
• noildžu, atkārtoto mēģinājumu, ķēdes pārtraucēja gadījumu un pārtraukto sarunu īpatsvars;
• daļēju atbilžu un cilvēkam nodoto gadījumu īpatsvars;
• atbilžu kvalitāte un avotu pārklājums tiem pašiem testa gadījumiem.

Ātrumu nedrīkst optimizēt izolēti. Ja īsāks konteksts ietaupa latenci, bet samazina trāpījumu kvalitāti, problēma tikai pārvietojas. Tāpēc izmantojiet fiksētu Golden Set un paralēli pārbaudiet čatbota atbilžu kvalitāti.

Slodzes testiem nepieciešami reāli sarunu paraugi

Viens ātrs tests maz ko pierāda. Testējiet tipiskus BJU jautājumus, divdomīgus jautājumus, garus dialogus, rīku izsaukumus, kļūdainas atkarības un vairākas valodas. Mēriet aukstos un siltos ceļus atsevišķi, jo kešatmiņa, savienojumi un modeļa konteksts var darboties atšķirīgi. Turklāt simulējiet pīķa slodzi, nekontrolēti nepārslogojot reālās trešo pušu sistēmas.

Katram galvenajam lietotāja ceļam pieņemšanas kritērijā būtu jānosaka, kurš P95 mērķis ir spēkā, kad jāparādās statusa norādei un kāda rezerves opcija ir pieņemama. Mākslīgi aizkavēts rīka aizstājējs (stub) palīdz pārbaudīt, vai noildze, daļēja atbilde un nodošana cilvēkam tiešām darbojas. Tādējādi diagramma kļūst par pārbaudāmu darbības līgumu.

Praktisks kontrolsaraksts ieviešanai

1. Dokumentējiet pilnu atbildes maršrutu no pārlūka līdz pēdējam avotam.
2. Mēriet Time to First Token un kopējo ilgumu atsevišķi.
3. Definējiet budžetus katram jautājuma veidam un katram tehniskajam posmam.
4. Paralelizējiet neatkarīgas lasīšanas piekļuves un ierobežojiet rīku posmus.
5. Veidojiet straumēšanu ar stabilliem stāvokļiem, pārtraukšanu un kļūdu nobeigumu.
6. Iegūstiet noildzes no mērījumu datiem un ievietojiet tās kopējā budžetā.
7. Izmantojiet atkārtotus mēģinājumus tikai ierobežoti, ar atpakaļatkāpšanos, neprecizitāti (jitter) un idempotenci.
8. Testējiet daļēju atbildi, ķēdes pārtraucēju un nodošanu cilvēkam.
9. Novērojiet P95 un P99 pēc lokāles, ierīces un jautājuma veida.
10. Pārbaudiet katru ātruma izmaiņu pret atbilžu kvalitāti un avotiem.

Secinājums: ātras atbildes ir produkta solījums

Labs MI čatbota atbildes laiks rodas no daudziem maziem, mērāmiem lēmumiem: reālistiska budžeta, īsas kritiskās rīku ķēdes, agras lietderīgas straumēšanas, drošām noildzēm un godīgas rezerves opcijas. Kurš skatās tikai uz modeli, palaiž garām lielu gaidīšanas laika daļu.

Ar ChatReact tīmekļa vietņu komandas var plānot uzticamas čatbota atbildes kā daļu no saviem atbalsta un informācijas procesiem. Sāciet ar centrālo lietotāja ceļu, izmēriet tā P95 vērtību un vispirms novērsiet lēnāko kontrolējamo posmu.

Avoti

• Google Research: The Tail at Scale
• AWS Builders’ Library: Timeouts, Wiederholungsversuche und Backoff mit Jitter
• RFC 6585: Additional HTTP Status Codes
• WHATWG Streams Standard