KI-Chatbot-Rate-Limits: Kosten und Last fair begrenzen

Viešai pasiekiamas svetainės pokalbių botas per kelias sekundes gali sukelti daugiau skaičiavimo apkrovos nei įprastas kontaktų puslapis per visą lankytojo seansą. Viena žinutė gali inicijuoti informacijos paiešką (Retrieval), rezultatų perskirstymą (Reranking), kelis modelio šaukimus ir kitus patikrinimus. Be aiškių ribų pakanka ne tik didelės botų atakos: klaidingai veikianti kliento programa, daug vienu metu atvertų kortelių ar automatinė pakartotinių užklausų kilpa gali staiga padidinti atsako trukmę ir išlaidas.

DI pokalbių botų užklausų ribojimai (Rate Limits) neturėtų būti suprantami kaip griežtas blokavimas. Tinkami limitai teisingai paskirsto ribotus išteklius, apsaugo biudžetą ir išlaiko aiškų bei prieinamą paslaugos likutį teisėtiems vartotojams. Šis praktinis gidas parodo, kokius kiekius svetainių komandos turėtų riboti, kaip teisingai nustatyti vartotojo tapatybę ir kokį atsaką pokalbių botas turi pateikti esant didelei apkrovai.

Kodėl neužtenka vien tik užklausų per minutę limito

Naudojant įprastus API, dvi užklausos dažniausiai reikalauja panašių išteklių. Tačiau DI pokalbių bote trumpam pasisveikinimui gali prireikti tik kelių žetonų (Tokens), o ilgai dokumentų analizei, plačiai paieškai ar keliems modelio žingsniams – kartais keliasdešimt kartų daugiau. Naujausias OWASP GenAI LLM Top 10 2026 neapribotą išteklių naudojimą įvardija kaip Unbounded Consumption. Esminė problema yra išlaidų asimetrija: užpuolikas arba sugedusi kliento programa, įdėdama nedaug pastangų, gali sukelti neproporcingai brangų apdorojimą.

Taip pat ir OWASP API4:2023 šalia sąveikų dažnumo mini kitus limitus, tokius kaip vykdymo laikas, atmintis, įkeliamo failo dydis, operacijos per užklausą ir trečiųjų šalių paslaugų išlaidos. Pokalbių botams iš to išplaukia: politika turi ne tik skaičiuoti užklausas, bet ir numatyti biudžetą visam apdorojimo keliui.

Septyni ištekliai, kuriems reikia atskirų biudžetų

Patikima koncepcija prasideda nuo nedidelio išteklių žemėlapio. Kiekvienai dimensijai nustatoma, kada užklausa priimama, sutrumpinama, atidedama ar atmetama.

• Užklausos: skaičius per trumpą piko (Burst) etapą ir per ilgesnį laiko tarpą.
• Lygiagretumas: vienu metu vykdomi atsakymai vienam vartotojui, seansui ar organizacijai.
• Įvestis: simboliai, priedai ir numatomas įvesties žetonų skaičius prieš iškviečiant modelį.
• Išvestis: maksimalus atsako biudžetas bei protingas nutraukimas begalinių kilpų atveju.
• Informacijos paieška (Retrieval): paieškos variantų, atitikmenų, Reranking kandidatų ir papildomai įkeliamų dokumentų skaičius.
• Eilė: atviri darbai ir maksimalus laukimo laikas prieš pritaikant aiškų atsarginį scenarijų.
• Išlaidos: dienos ar mėnesio biudžetas organizacijai bei visuotinis avarinis stabdys.

Piko etapų ir ilgų laiko tarpų valdymas atskirai

Šie limitai yra susiję, tačiau nepakeičia vienas kito. Didingas dienos biudžetas neapsaugos nuo apkrovos piko per vieną sekundę. Savo ruožtu užklausų limitas neapsaugo nuo vienos itin brangios užklausos. Todėl techniniam išpildymui verta suderinti sistemą su aiškiu vėlinimo biudžetu, laukimo limitais (Timeouts) ir kontroliuojamais pakartojimais.

Sąžiningas tapatybės nustatymas vietoje bendro IP blokavimo

Kodėl neužtenka vien tik IP adreso

HTTP standartas RFC 6585 sąmoningai nenurodo, kaip serveris turi atpažinti vartotoją ar skaičiuoti užklausas. Tai svarbu, nes vien IP adresas nėra patikimas vartotojo rodiklis. Įmonėse, viešbučiuose, mobiliojo ryšio tinkluose ar šeimose daug žmonių gali dalintis tuo pačiu viešuoju adresu. Ir priešingai – automatizuota kliento programa gali lengvai keisti savo IP adresus.

Duomenis taupančių signalų derinimas

Autorizuotose srityse organizacijos, paskyros ir vartotojo ID yra stipriausi raktai. Viešam pokalbių botui rekomenduojamas pakopinis derinys iš trumpalaikio, duomenis taupančio seanso, bendro tinklo signalo ir esamo rizikos šablono. Neapdoroti užklausų tekstai (Prompts), nuolatiniai įrenginio atspaudai ar pernelyg tikslūs IP žurnalai tam nėra būtini. Kai naudojami asmeniniai paskyros duomenys, ribos turi būti planuojamos atskirai, atsižvelgiant į autorizuoto pokalbių boto klientų portale reikalavimus.

Politika taip pat turėtų leisti teisėtus pakartojimus. Vartotojas dėl nestabilaus ryšio gali išsiųsti žinutę dar kartą arba jam gali prireikti daugiau sąveikų dėl pagalbinių technologijų naudojimo. Todėl įtartinas retai būna pavienis signalas – dažniau tai didelio dažnio, ilgų įvesčių, daugybės lygiagrečių seansų ir pakartotinio brangių kelių naudojimo derinys.

Limitų nustatymas remiantis matavimais, o ne spėlionėmis

Gera pradinė vertė sukuriama iš realių, sėkmingų pokalbių. Komanda kelias savaites matuoja įvesties ir išvesties žetonus, paieškos rezultatus, vykdymo trukmę, lygiagretumą ir išlaidas vienai atliktai užduočiai. Po to atskirai išanalizuojamas įprastas naudojimas, pikai ir nukrypimai. Limitas nustatomas virš tikėtino teisėto piko, bet žemiau tos ribos, kurioje pavienis veikėjas galėtų sukelti grėsmę paslaugai ar biudžetui.

Pavyzdys: daugeliui pokalbių reikia ne daugiau kaip trijų atsakymų per minutę ir jie neviršija žetonų biudžeto. Tokiu atveju trumpas pikas gali priimti daugiau žinučių, o ilgesnio laiko langas riboja bendrą kiekį. Brangiems analizės keliams papildomai skiriamas mažesnis atskiras kontingentas. Svarbu ne konkreti kitos sistemos figūra, o dokumentuotas ryšys su apkrovos testu, išlaidų modeliu ir vartotojų elgsena.

Pakeitimai iš pradžių turėtų būti atliekami stebėjimo („Shadow Mode“) režimu. Sistema registruoja, kuriuos teisėtus seansus būtų paveikęs planuojamas limitas, tačiau jų dar neblokuoja. Taip ribos laipsniškai kalibruojamos ir matomi nereikalingi blokavimai.

Daugiasluoksnė apsaugos grandinė kiekvienai užklausai

1. Patikrinimas įvestyje: duomenų dydis, failo tipas, seansas ir akivaizdūs pakartojimai įvertinami dar prieš informacijos paiešką ir modelio iškvietimą.
2. Išankstinis išlaidų įvertinimas: įvesties ilgis, pageidaujama išvestis, paieškos plotis ir modelio klasė suformuoja preliminarų užklausos „svorį“.
3. Atominis biudžeto rezervavimas: seansas, vartotojas, organizacija ir bendras fondas tikrinami kartu. Vienu metu gaunamos užklausos neturi kelis kartus panaudoti to paties likusio biudžeto.
4. Vykdymo laiko ribojimas: laukimo limitai (Timeouts), maksimalūs modelio žingsniai ir apribota eilė sustabdo brangius pakibimus.
5. Faktinio suvartojimo užregistravimas: užbaigus darbą, faktinis suvartojimas pakeičia įvertinimą. Nutraukimai ir tiekėjo klaidos lieka matomi kaip atskiri matavimai.

Ši grandinė veikia serverio pusėje. Naršyklėje paslėptas siuntimo mygtukas yra naudingas UX elementas, bet ne saugumo riba. Tai galioja ir Prompt nurodymams: jie nepakeičia nei techninio ribotuvo, nei apsaugos nuo Prompt Injection svetainių pokalbių botuose.

429, Retry-After ir pakartotinių užklausų bangos pavojus

Jei vartotojo kontingentas išnaudotas, HTTP 429 Too Many Requests yra tinkamas mašininio skaitymo atsakas. RFC 6585 rekomenduoja pateikti paaiškinimą ir leidžia naudoti Retry-After antraštę. Kliento programa turėtų gerbti šį laiką, nesiųsti užklausos iškart iš naujo ir aiškiai parodyti siuntimo būseną. Keliems klientams idealu pritaikyti šiek tiek atsitiktinį laiko išbarstymą, kad jie nepradėtų užklausų vienu metu.

Priešingai, esant bendrai laikinai perkrovai, gali tikti HTTP 503 Service Unavailable. RFC 9110 aprašo, kad Retry-After gali būti siunčiamas kaip HTTP data arba laukimo laikas sekundėmis. Neidempotentiniai veiksmai niekada neturėtų būti aklai kartojami: ar užsakymas arba duomenų perdavimas jau įvyko, pirmiausia turi būti vienareikšmiškai išaiškinta.

Pokalbių sąsajoje techniniam atsakui reikalingas žmogui suprantamas tekstas: kodėl šiuo metu užklausa neapdorojama, kada prasminga bandyti vėl ir kokia alternatyva lieka. Pranešimas turėtų būti programuojamai atpažįstamas pagalbinėms technologijoms. W3C paaiškinimas dėl WCAG 2.2 Status Messages parodo, kaip apie būsenos pokyčius galima pranešti nepriverčiant pakeisti fokuso.

Graceful Degradation išlaiko naudingą paslaugos likutį

Griežtas visiškas blokavimas ne visada yra geriausia reakcija. Esant dideliai apkrovai, pokalbių botas pasirinktinai gali pateikti trumpesnius atsakymus, tikrinti mažiau paieškos kandidatų arba praleisti laiko atžvilgiu nekritišką įvertinimą. Svarbiausia yra skaidrumas: vartotojas turi suprasti, kad šiuo metu veikia apribotas režimas. Šaltiniai, saugumo patikrinimai ir autorizacija dėl to neturi tyliai pranykti.

Skubiems klausimams turėtų būti numatyta paprasta kontakto arba perdavimo žmogui (Handoff) galimybė. Jei ir šis kelias yra apkrautas, sistema rodo patikimą alternatyvą, o ne išgalvotą pažadą. Apribojimo, išjungimo ir pakartotinio paleidimo kriterijai turi būti įtraukti į reagavimo į incidentus ir sistemų atkūrimo (Rollback) planą.

Kokie rodikliai leidžia valdyti apsaugą

Vien tik 429 atsakymų skaičius sako nedaug. Naudingas skydelis (Dashboard) išskiria duomenis pagal limitų dimensiją ir vartotojų klasę: priimtos ir apribotos užklausos, lygiagrečiai vykdomi procesai, laukimo trukmė, įvesties ir išvesties žetonai, paieškos plotis, išlaidos vienam sėkmingam pokalbiui ir tiekėjo klaidos. Papildomai reikia užblokuotų seansų imties, kad būtų galima atpažinti klaidingus pavojaus signalus.

Įspėjimai turėtų reaguoti į pokyčius: neįprastą išlaidų augimą per minutę, straujai didėjančią eilę, daug ilgų įvesčių iš kintančių seansų arba didelę momentinių pakartojimų dalį, nepaisant Retry-After. Tam dažnai pakanka pseudoniminių skaitiklių ir techninių metaduomenų; visas pokalbio turinys neprivalo patekti į kiekvieną apkrovos žurnalą. NIST AI RMF Core pabrėžia, kad DI sistemos prieš įdiegimą ir reguliariai eksploatacijos metu turėtų būti matuojamos bei tikrinamos.

Testavimo planas prieš galutinį aktyvavimą

• Įprasti pavieniai pokalbiai ir trumpi teisėti pikai lieka nepaveikti.
• Itin ilgos įvestys apribojamos prieš brangius modelio ar paieškos iškvietimus.
• Daug lygiagrečių kortelių teisingai dalijasi tą patį seanso ar paskyros biudžetą.
• Keli teisėti vartotojai už bendro IP nėra bendrai blokuojami.
• 429 ir 503 kodai pateikia nuoseklią, suprantamą laukimo informaciją.
• Kliento programos gerbia Retry-After ir nesukuria pakartotinių užklausų bangos.
• Apribotas režimas išlaiko šaltinių, duomenų apsaugos ir saugumo ribas.
• Visuotinis išlaidų limitas sustabdo brangų kelią, nusinešdamas nei būsenos puslapio, nei kontakto kelio.

Praktinis kontrolinis sąrašas svetainių komandoms

1. Išmatuoti išteklių kelią ir išlaidas vienam sėkmingam pokalbiui.
2. Apibrėžti atskirus limitus užklausoms, žetonams, lygiagretumui, paieškai, eilei ir biudžetui.
3. Teikti pirmenybę registruotoms tapatybėms ir taupiai derinti anoniminius signalus.
4. Pirmiausia patikrinti ribas „Shadow Mode“ režimu pagal realų naudojimą.
5. Išbandyti 429, 503 ir Retry-After elgseną API bei sąsajoje.
6. Dokumentuoti „Graceful Degradation“, perdavimą žmogui ir visuotinį avarinį stabdį.
7. Reguliariai kartu vertinti klaidingus blokavimus, išlaidas ir apkrovą.

Išvada: geri užklausų limitai apsaugo paslaugą ir vartotoją

DI pokalbių botų užklausų limitai yra architektūrinė užduotis, o ne vienas skaičius CDN nustatymuose. Tik kiekio, žetonų, lygiagretumo ir išlaidų biudžetų derinys užkerta kelią nevaldomam vartojimui. Sąžininga tapatybė, aiški pakartojimų semantika ir skaidrus paslaugos likutis užtikrina, kad apsauga netaptu bloga vartotojo patirtimi.

Norintieji stabiliai valdyti savo svetainės pokalbių botą turėtų pradėti nuo išmatuoto išteklių žemėlapio ir kontroliuojamai griežtinti politiką. Patikrinkite savo ChatReact naudojimui, kokie biudžetai tinka jūsų svetainės srautui, ir išbandykite ribas prieš galutinį aktyvavimą.

Šaltiniai

• OWASP GenAI LLM Top 10 2026
• OWASP API4:2023 – Unrestricted Resource Consumption
• RFC 6585 – 429 Too Many Requests
• RFC 9110 – Retry-After
• W3C WCAG 2.2 – Status Messages
• NIST AI Risk Management Framework Core