Mākslīgā intelekta tērzēšanas botu ātruma ierobežojumi: Taisnīga izmaksu un slodzes ierobežošana

Publiski pieejams tīmekļa vietnes tērzēšanas bots dažās sekundēs var izraisīt lielāku skaitļošanas slodzi nekā klasiska kontaktu lapa visa apmeklējuma laikā. Viens ziņojums var aktivizēt informācijas ieguvi (retrieval), pārkārtošanu (reranking), vairākus modeļa izsaukumus un papildu pārbaudes. Tāpēc bez skaidriem ierobežojumiem nepietiek tikai ar aizsardzību pret liela mēroga botu uzbrukumiem: arī kļūdains klients, daudzas vienlaikus atvērtas cilnes vai automātisks atkārtotu mēģinājumu cikls var strauji palielināt reakcijas laiku un izmaksas.

MI tērzēšanas botu ātruma ierobežojumus (rate limits) nevajadzētu uztvert kā stingru bloķēšanu. Labi ierobežojumi taisnīgi sadala ierobežotos resursus, aizsargā izmaksu budžetu un saglabā saprotamu pamatpakalpojumu leģitīmajiem lietotājiem. Šajā praktiskajā rokasgrāmatā paskaidrots, kādus apjomus tīmekļa vietņu komandām vajadzētu ierobežot, kā izveidot taisnīgu identifikāciju un kāda atbilde tērzēšanas botam jāsniedz liela noslogojuma gadījumā.

Kāpēc ar vienkāršu pieprasījumu skaita ierobežojumu minūtē nepietiek

Parastajām API divi pieprasījumi bieži vien izmaksā aptuveni vienādi. Turpretim MI tērzēšanas botam īss sveiciens var patērēt tikai dažus žetonus (tokens), savukārt gara dokumenta analīze, plaša informācijas meklēšana vai vairāki modeļa apstrādes soļi patērē daudzkārt vairāk. Pašreizējā OWASP GenAI LLM Top 10 2026 neierobežotu resursu patēriņu klasificē kā Unbounded Consumption. Galvenais cēlonis ir izmaksu asimetrija: uzbrucējs vai bojāts klients ar nelielu savu piepūli var izraisīt neproporcionāli dārgu apstrādi.

Arī OWASP API4:2023 līdzās mijiedarbības ātrumam min citus ierobežojumus, piemēram, izpildes laiku, atmiņu, augšupielādes apjomu, darbības uz vienu pieprasījumu un tēriņus trešo pušu pakalpojumos. No tā tērzēšanas botiem izriet: politikai ir ne tikai jāskaita pieprasījumi, bet arī jāplāno visa apstrādes ceļa budžets.

Septiņi resursi, kuriem nepieciešams atsevišķs budžets

Uzticama koncepcija sākas ar nelielu resursu karti. Katrai dimensijai tiek noteikts, kad pieprasījums tiek pieņemts, saīsināts, aizkavēts vai noraidīts.

• Pieprasījumi: skaits īsā uzplūda (burst) fāzē un ilgākā laika logā.
• Paralelitāte: vienlaikus darbojošās atbildes uz vienu lietotāju, sesiju un klientu (tenant).
• Ievade: rakstzīmes, pielikumi un paredzamie ievades žetoni (input tokens) pirms modeļa izsaukšanas.
• Izvade: maksimālais atbildes budžets, kā arī prātīga pārtraukšana bezgalīgu ciklu gadījumā.
• Informācijas ieguve (Retrieval): meklēšanas variantu, rezultātu, pārkārtošanas kandidātu un papildus ielādēto dokumentu skaits.
• Rinda: atvērtie uzdevumi un maksimālais gaidīšanas laiks, pirms tiek aktivizēts skaidrs rezerves risinājums (fallback).
• Izmaksas: dienas vai mēneša budžets katrai organizācijai, kā arī globālā avārijas bremze.

Atsevišķa pieeja īsiem uzplūdiem un ilgiem laika logiem

Šie ierobežojumi ir savstarpēji saistīti, taču nav aizstājami. Dāsns dienas budžets nenovērš slodzes pīķi vienā sekundē. Savukārt pieprasījumu limits neaizsargā pret vienu ārkārtīgi dārgu pieprasījumu. Tāpēc tehniskajam izpildes laikam ir vērts to apvienot ar eksplicītu vētīto aiztures budžetu, noildzēm (timeouts) un kontrolētiem atkārtotiem mēģinājumiem.

Taisnīga identifikācija, nevis vispārēja IP adrešu bloķēšana

Kāpēc ar IP adresi vien nepietiek

HTTP standarts RFC 6585 apzināti nenorāda, kā serverim būtu jāatpazīst lietotājs vai jāskaita pieprasījumi. Tas ir svarīgi, jo IP adrese pati par sevi nav uzticams lietotāja identifikators. Uzņēmumos, viesnīcās, mobilajos tīklos vai ģimenēs daudzi cilvēki var dalīt vienu un to pašu publisko adresi. Un otrādi – automatizēts klients var viegli mainīt savas IP adreses.

Datu taupīgu signālu kombinēšana

Autorizētās zonās spēcīgākie identifikatori ir organizācija, konts un lietotāja ID. Publiskiem tērzēšanas botiem ieteicama pakāpeniska kombinācija, ko veido īslaicīga, datus taupoša sesija, aptuvens tīkla signāls un pašreizējais riska modelis. Neapstrādāti vaicājumi, ilgstoši ierīču pirkstu nospiedumi (fingerprints) vai nevajadzīgi precīzi IP protokoli šim nolūkam nav nepieciešami. Ja tiek izmantoti personīgie konta dati, autentificēta tērzēšanas bota klientu portālā robežas ir jāplāno atsevišķi.

Politikai būtu arī jāpieļauj leģitīmi atkārtoti pieprasījumi. Lietotājs var nosūtīt ziņojumu atkārtoti nestabila savienojuma dēļ vai arī izmantot palīgtehnoloģijas, kam nepieciešams vairāk mijiedarbību. Tāpēc aizdomīgs reti ir viens atsevišķs signāls, bet gan augstas frekvences, garu ievades datu, daudzu paralēlu sesiju un atkārtotas dārgu ceļu izmantošanas kombinācija.

Ierobežojumu noteikšana, balstoties uz mērījumiem, nevis minējumiem

Laba sākuma vērtība izriet no reālām, veiksmīgām sarunām. Komanda dažas nedēļas mēra ievades un izvades žetonus, informācijas ieguves rezultātus, izpildes laiku, paralelitāti un izmaksas par katru izpildīto uzdevumu. Pēc tam atsevišķi tiek izvērtēta parastā lietošana, pīķi un novirzes. Limits tiek noteikts virs ticama leģitīmā pīķa, bet zem līmeņa, kurā viens dalībnieks var apdraudēt pakalpojumu vai budžetu.

Piemērs: Vairumam sarunu nepieciešamas ne vairāk kā trīs atbildes minūtē, un tās atrodas tālu zem žetonu budžeta. Tādā gadījumā īss uzplūds var pieļaut vairāk ziņojumu, savukārt ilgāks laika logs ierobežo kopējo daudzumu. Dārgiem analīzes ceļiem papildus tiek piešķirts mazāks atsevišķs kontingents. Izšķirošais faktors nav konkrēts skaitlis no citas sistēmas, bet gan dokumentēta saikne ar slodzes testu, izmaksu modeli un lietotāju uzvedību.

Izmaiņas vispirms jāievieš novērošanas režīmā (shadow mode). Sistēma fiksē, kuras leģitīmās sesijas būtu sasniegušas plānoto limitu, tās vēl nebBloķējot. Tādējādi sliekšņi tiek pakāpeniski kalibrēti un kļūst redzami nevajadzīgi bloķējumi.

Daudzlīmeņu aizsardzības ķēde katram pieprasījumam

1. Pārbaude pie ieejas: datu apjoms (payload size), faila tips, sesija un acīmredzami atkārtojumi tiek novērtēti pirms informācijas meklēšanas un modeļa izsaukšanas.
2. Aptuvens izmaksu novērtējums: ievades garums, vēlamā izvade, meklēšanas plašums un modeļa klase dod aptuvenu pieprasījuma svara novērtējumu.
3. Atoma budžeta rezervēšana: sesija, lietotājs, organizācija un globālais pūls tiek pārbaudīti kopā. Vienlaikus ienākošie pieprasījumi nedrīkst vairākkārt izmantot vienu un to pašu atlikušo budžetu.
4. Izpildes laika ierobežošana: noildzes, maksimālie modeļa soļi un ierobežota rinda aptur dārgas iestrēgšanas.
5. Faktiskā patēriņa uzskaite: pēc pabeigšanas faktiskais patēriņš aizstāj tāmi. Pārtraukumi un pakalpojumu sniedzēja kļūdas paliek redzamas kā atsevišķi mērījumi.

Šī ķēde atrodas servera pusē. Pārlūkprogrammā paslēpta nosūtīšanas poga ir noderīga UX detaļa, bet nav drošības robeža. Tas pats attiecas uz uzdevumu norādēm (prompts): tās neaizstāj ne tehnisko ierobežotāju, ne aizsardzību pret uzdevumu injekcijām (prompt injection) tīmekļa vietņu tērzēšanas botos.

429, Retry-After un atkārtotu mēģinājumu viļņa risks

Ja ar lietotāju saistītais kontingents ir izsmelts, HTTP 429 Too Many Requests ir piemērota mašīnlasāma atbilde. RFC 6585 iesaka sniegt paskaidrojumu un atļauj izmantot Retry-After galveni. Klientam šis laiks būtu jāievēro, nesūtot pieprasījumu uzreiz no jauna, un saprotami jāattēlo sūtīšanas statuss. Vairākiem klientiem ideālā gadījumā tiek lietota nejauša laika izkliede, lai tie nesāktu darbu vienlaikus.

Pārslodzes gadījumā piemērotāka var būt HTTP 503 Service Unavailable atbilde. RFC 9110 apraksta, ka Retry-After var nosūtīt kā HTTP datumu vai gaidīšanas laiku sekundēs. Ne-idempotentas darbības nekad nedrīkst aklās atkārtot: vispirms ir skaidri jānoskaidro, vai rezervācija vai nodošana jau ir notikusi.

Tērzēšanas saskarnē tehniskajai atbildei nepieciešams cilvēkam saprotams teksts: kāpēc šobrīd apstrāde netiek turpināta, kad ir lietderīgi mēģināt vēlreiz un kāda ir alternatīva. Ziņojumam jābūt programmatiski atpazīstamam palīgtehnoloģijām. W3C skaidrojumā par WCAG 2.2 statusa ziņojumiem (Status Messages) parādīts, kā paziņot par stāvokļa izmaiņām bez piespiedu fokusa maiņas.

Pakāpeniska funkciju samazināšana (Graceful Degradation) saglabā noderīgu pamatpakalpojumu

Stingra, pilnīga bloķēšana ne vienmēr ir labākā reakcija. Lielas slodzes apstākļos tērzēšanas bots pēc izvēles var sniegt īsākas atbildes, pārbaudīt mazāk meklēšanas kandidātu vai izlaist laika ziņā nekritisku izvērtēšanu. Svarīga ir caurspīdīgums: lietotājam ir jāsaprot, ka pašlaik ir aktīvs ierobežots režīms. Avoti, drošības pārbaudes un autorizācija nedrīkst tikt klusējot atcelti.

Steidzamos gadījumos vajadzētu būt pieejamai vienkāršai kontaktu vai savienošanas ar operatoru (handoff) opcijai. Ja arī šis ceļš ir pārslogots, sistēma parāda uzticamu alternatīvu, nevis izdomātu solījumu. Kritēriji funkciju samazināšanai, izslēgšanai un atkārtotai palaišanai ir jāiekļauj incidentu reakcijas un atjaunošanas (rollback) plānā.

Kuri rādītāji palīdz pārvaldīt aizsardzību

Tīrs 429 atbilžu skaits pasaka maz. Noderīgā informācijas panelī dati tiek sadalīti pēc limita dimensijas un lietotāju klases: pieņemtie un ierobežotie pieprasījumi, paralēlie izpildes procesi, gaidīšanas ilgums, ievades un izvades žetoni, meklēšanas plašums, izmaksas par veiksmīgu sarunu un pakalpojumu sniedzēja kļūdas. Papildus nepieciešams bloķēto sesiju izlases paraugs, lai identificētu kļūdainus trauksmes signālus.

Brīdinājumiem jāreaģē uz izmaiņām: neparasts izmaksu pieaugums minūtē, strauji augoša rinda, daudzas garas ievades no mainīgām sesijām vai liels tūlītēju atkārtotu mēģinājumu īpatsvars par spīti Retry-After. Bieži vien pietiek ar pseidonimizētiem skaitītājiem un tehniskajiem metadatiem; pilnam sarunu saturam nav obligāti jābūt katrā slodzes protokolā. NIST AI RMF Core uzsver, ka MI sistēmas ir jāmēra un jāpārbauda pirms ieviešanas un regulāri ekspluatācijas laikā.

Pārbaudes plāns pirms galīgās aktivizēšanas

• Parastas atsevišķas sarunas un īsi leģitīmi uzplūdi netiek ietekmēti.
• Ļoti garas ievades tiek ierobežotas pirms dārgiem modeļa vai meklēšanas izsaukumiem.
• Daudzas paralēlas cilnes pareizi dala vienu un to pašu sesijas vai konta budžetu.
• Vairāki leģitīmi lietotāji aiz vienas kopīgas IP netiek nepamatoti nobloķēti.
• 429 un 503 satur konsekventu, saprotamu informāciju par gaidīšanas laiku.
• Klienti ievēro Retry-After un nerada atkārtotu mēģinājumu vilni.
• Ierobežotais režīms saglabā avotu, datu aizsardzības un drošības robežas.
• Globālais izmaksu limits aptur dārgo apstrādes ceļu, neietekmējot statusa lapu vai kontaktu iespējas.

Praktisks kontrolsaraksts tīmekļa vietņu komandām

1. Izmērīt resursu izmantošanas ceļu un izmaksas par katru veiksmīgu sarunu.
2. Definēt atsevišķus limitus pieprasījumiem, žetoniem, paralelitātei, meklēšanai, rindai un budžetam.
3. Dot priekšroku autentificētām identitātēm un apvienot anonīmos signālus, taupot datus.
4. Pārbaudīt sliekšņus vispirms novērošanas režīmā (shadow mode) pret reālo lietojumu.
5. Pārbaudīt 429, 503 un Retry-After darbību API un saskarnē.
6. Dokumentēt pakāpenisku funkciju samazināšanu, savienošanu ar operatoru un globālo avārijas bremzi.
7. Regulāri kopīgi izvērtēt kļūdainās bloķēšanas, izmaksas un slodzi.

Secinājums: Labi ātruma ierobežojumi aizsargā pakalpojumu un lietotājus

MI tērzēšanas botu ātruma ierobežojumi (rate limits) ir arhitektūras uzdevums, nevis viens skaitlis CDN uzstādījumos. Tikai daudzuma, žetonu, paralelitātes un izmaksu budžeta kombinācija novērš neierobežotu patēriņu. Taisnīga identifikācija, skaidra atkārtoto mēģinājumu semantika un caurspīdīgs pamatpakalpojums nodrošina, ka aizsardzība nepasliktina lietotāja pieredzi.

Ikvienam, kas vēlas stabili darbināt savas tīmekļa vietnes tērzēšanas botu, vajadzētu sākt ar izmērītu resursu karti un kontrolēti pastiprināt politiku. Pārbaudiet savai ChatReact lietošanai, kuri budžeti atbilst jūsu vietnes trafikam, un pārbaudiet robežas pirms to galīgās aktivizēšanas.

Avoti

• 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