KI-juturoboti päringupiirangud (Rate Limits): kulude ja koormuse õiglane piiramine

Avalikult kättesaadav veebilehe juturobot võib vaid mõne sekundiga tekitada rohkem arvutuskoormust kui tavaline kontaktileht terve külastuse jooksul. Üksainus sõnum võib käivitada otsingu (retrieval), ümberjärjestamise (reranking), mitu mudelikutset ja täiendavad kontrollid. Ilma selgete piirideta ei ole ohuallikaks vaid ulatuslik botiatakk: ka vigane klientrakendus, liiga palju korraga avatud vahekaarte või automaatne korduspäringute tsükkel võivad vastamisaega ja kulusid märkimisväärselt tõsta.

KI-juturoboti päringupiiranguid (Rate Limits) ei tohiks seejuures käsitleda jäiga blokina. Head piirangud jagavad piiratud ressursse õiglaselt, kaitsevad eelarvet ja tagavad tavakasutajatele arusaadaval kujul toimiva teenuse. See praktiline juhend selgitab, milliseid mahte peaksid veebilehtede tiimid piirama, kuidas luua õiglast identiteeti ja milliseid vastuseid peab juturobot suure koormuse korral andma.

Miks ainult päringute arvu piiramine minutis ei ole piisav

Tavaliste API-de puhul on kaks päringut sageli umbes sama kallid. KI-juturoboti puhul võib lühike tervitus kulutada vaid mõne tokeni, samal ajal kui pika dokumendi analüüs, ulatuslik otsing või mitmeastmeline mudelitöötlus kulutavad kordades rohkem. Kehtiv OWASP GenAI LLM Top 10 2026 nimetab piiramatut ressursikulu terminiga Unbounded Consumption. Probleemi tuum on kulude ebavõrdsus: ründaja või vigane klientrakendus saab väga väikese vaevaga käivitada ebaproportsionaalselt kalli töötlemisprotsessi.

Ka OWASP API4:2023 toob lisaks suhtlussagedusele välja sellised piirangud nagu täitmisaeg, mälumaht, üleslaadimise suurus, operatsioonid päringu kohta ja kulud kolmandate osapoolte teenustele. Juturobotite puhul tähendab see, et reeglistik ei tohi lugeda vaid päringuid, vaid peab seadma eelarve kogu töötlemisahelale.

Seitse ressurssi, mis vajavad eraldi eelarvet

Töökindel kontseptsioon algab ressursikaardist. Iga mõõtme puhul määratakse kindlaks, millal päring vastu võetakse, seda lühendatakse, edasi lükatakse või tagasi lükatakse.

• Päringud: kogus lühikese koormuspurske (burst) ja pikema ajaakna jooksul.
• Rööpsus (Parallelism): samal ajal käimasolevad vastused kasutaja, sessiooni ja kliendikonto (tenant) kohta.
• Sisend: tähemärgid, manused ja hinnangulised sisendtokenid enne mudeli kutsumist.
• Väljund: maksimaalne vastuse eelarve ja mõistlik katkestamine lõputute tsüklite korral.
• Otsing (Retrieval): otsinguvariantide, tulemuste, ümberjärjestamise kandidaatide ja täiendavalt laetavate dokumentide arv.
• Ootejärk (Queue): pooleliolevad tööd ja maksimaalne ooteaeg enne selge varulahenduse käivitumist.
• Kulud: päeva- või kuueelarve organisatsiooni kohta ning ülemaailmne hädapidur.

Koormuspurskete ja pikkade ajaakende eraldi käsitlemine

Need piirangud on omavahel seotud, kuid ei asenda üksteist. Suuremeelne päevaeelarve ei hoia ära koormuspiiki ühes sekundis. Päringupiirang ei kaitse omakorda üheainsa äärmiselt kalli päringu eest. Tehnilise tööaja tagamiseks tasub seda kombineerida selge viivitusajavaru, aegumiste (timeouts) ja kontrollitud korduspäringutega.

Õiglane identiteet üldise IP-blokeeringu asemel

Miks ainult IP-aadressist ei piisa

HTTP-standard RFC 6585 ei määra teadlikult ette, kuidas server kasutajat tuvastab või päringuid loendab. See on oluline, sest IP-aadress üksinda ei ole usaldusväärne kasutaja tunnus. Ettevõtetes, hotellides, mobiilsidevõrkudes või peredes võivad paljud inimesed jagada sama avalikku aadressi. Ja vastupidi – automatiseeritud klientrakendus saab oma IP-aadresse hõlpsalt vahetada.

Andmesäästlike signaalide kombineerimine

Sisselogitud alades on organisatsiooni, konto ja kasutaja ID kõige tugevamad võtmed. Avaliku juturoboti puhul on soovitatav kasutada astmelist kombinatsiooni lühiajalisest, andmesäästlikust sessioonist, üldisest võrgusignaalist ja praegusest riskimustrist. Algseid sisendtekste, püsivaid seadme sõrmejälgi või liiga täpseid IP-loge pole selleks vaja. Kui kasutatakse isiklikke kontandmeid, tuleb piirangud seada eraldi vastavalt autenditud juturoboti kliendiportaali reeglitele.

Reeglistik peaks samuti lubama õigustatud kordusi. Kasutaja võib ebastabiilse ühenduse tõttu sõnumi uuesti saata või vajada abitehnoloogiate tõttu rohkem suhtlust. Kahtlane pole seega peaaegu kunagi üksik signaal, vaid kõrge sageduse, pikkade sisendite, paljude paralleelsete sessioonide ja kallite funktsioonide korduva kasutamise kombinatsioon.

Tuleta piirangud mõõtmistest, ära arva

Hea algväärtus saadakse reaalsetest ja edukatest vestlustest. Tiim mõõdab mõne nädala jooksul sisend- ja väljundtokeneid, otsingutulemusi, tööaega, rööpsust ja kulusid lõpetatud ülesande kohta. Seejärel eraldatakse tavakasutus, koormustipud ja erandid. Piirang seatakse kõrgemale kui loogiline tavapärane tipp, kuid allapoole taset, kus üksik kasutaja ohustaks teenust või eelarvet.

Näide: enamik vestlusi vajab minutis maksimaalselt kolme vastust ja jääb kaugele alla tokenieelarve. Sellisel juhul võib lühike koormuspuurse lubada rohkem sõnumeid, samas kui pikem ajaaken piirab kogumahtu. Kallitele analüüsiprotsessidele eraldatakse täiendavalt väiksem eraldi kontingent. Määrav ei ole teise süsteemi konkreetne number, vaid dokumenteeritud seos koormustesti, kulumudeli ja kasutajakäitumisega.

Muudatused tuleks esmalt rakendada jälgivas varjurežiimis (shadow mode). Süsteem logib, milliseid tavapäraseid sessioone plaanitav piirang oleks tabanud, ilma neid tegelikult blokeerimata. Nii kalibreeritakse läved samm-sammult ja tuvastatakse asjatud blokeeringud.

Mitmeastmeline kaitseahel iga päringu jaoks

1. Kontroll sisendis: andmemahtu (payload size), failitüüpi, sessiooni ja ilmseid kordusi hinnatakse enne otsingut ja mudelikutset.
2. Kulude eelhindamine: sisendi pikkus, soovitud väljund, otsingu ulatus ja mudeli klass annavad päringu ligikaudse kaalu.
3. Eelarvete aatomiühendusega broneerimine: sessiooni, kasutajat, organisatsiooni ja üldist reservi kontrollitakse koos. Paralleelselt saabuvad päringud ei tohi sama ülejäänud eelarvet mitu korda ära kulutada.
4. Tööaja piiramine: aegumised (timeouts), mudeli maksimaalsed sammud ja piiratud ootejärjekord peatavad kallid viivitused.
5. Tegeliku kulu registreerimine: pärast lõpetamist asendab tegelik kulu hinnangu. Katkestused ja teenusepakkuja vead jäävad eraldi mõõdikutena nähtavaks.

See ahel asub serveripoolses osas. Veebibrauseris peidetud saatmisnupp on kasulik kasutajakogemus (UX), kuid mitte turvapiir. Sama kehtib ka prompt-juhiste kohta: need ei asenda tehnilist piirajat ega kaitset veebilehe juturobotite prompt-injection rünnakute eest.

429, Retry-After ja korduspäringute laine oht

Kui kasutajapõhine mahupiirang on täis, on sobiv masinloetav vastus HTTP 429 Too Many Requests. RFC 6585 soovitab lisada selgituse ja lubab kasutada Retry-After pärist. Klientrakendus peaks seda aega austama, mitte kohe uuesti saatma ja kuvama saatmisolekut arusaadavalt. Mitme klientrakenduse puhul tasub kasutada juhuslikku viivitust, et need ei käivituks uuesti samal ajal.

Üldise ajutise ülekoormuse korral võib aga sobida HTTP 503 Service Unavailable. RFC 9110 kirjeldab, et Retry-After saab saata HTTP-kuupäevana või ooteajana sekundites. Mitte-idempotentseid toiminguid ei tohi kunagi pimesi korrata: enne tuleb kindlaks teha, kas broneering või üleandmine on juba toimunud.

Juturoboti liideses vajab tehniline vastus inimlikku teksti: miks praegu päringut edasi ei töödelda, millal on mõistlik uuesti proovida ja milline alternatiiv on saadaval. Teade peaks olema abitehnoloogiatele programmiliselt tuvastatav. W3C selgitus WCAG 2.2 Status Messages kohta näitab, kuidas saab olekumuutustest teada anda ilma sundfookuse muutmiseta.

Sujuv kohandumine (Graceful Degradation) säilitab kasuliku teenuse

Range täielik blokeerimine ei ole alati parim reaktsioon. Koormuse all võib juturobot valikuliselt anda lühemaid vastuseid, kontrollida vähem otsingutulemusi või jätta vahele mittekriitilise analüüsi. Oluline on läbipaistvus: kasutaja peab aru saama, et parajasti on aktiivne piiratud režiim. Allikad, turvakontrollid ja autoriseerimine ei tohi seejuures vaikimisi kaduda.

Kiirete pöördumiste jaoks peaks säilima lihtne kontakti- või üleandmisvõimalus. Kui ka see kanal on ülekoormatud, kuvab süsteem usaldusväärse alternatiivi, mitte ei anna väljamõeldud lubadust. Teenuse piiramise, väljalülitamise ja taaskäivitamise kriteeriumid peavad sisalduma intsidentide lahendamise ja taasteplaanis (Incident Response Plan).

Millised mõõdikud aitavad kaitset juhtida

Pelk 429-vastuste arv ütleb vähe. Kasulik töölaud jagab andmed piirangumõõtme ja kasutajaklassi järgi: vastuvõetud ja piiratud päringud, paralleelsed protsessid, ooteaeg, sisend- ja väljundtokenid, otsingu ulatus, kulu edukas vestluses ja teenusepakkuja vead. Lisaks on vaja blokeeritud sessioonide valimit, et tuvastada valehäireid.

Häired peaksid reageerima muudatustele: ebatavaline kulutõus minutis, kiiresti kasvav ootejärk, palju pikki sisendeid vahelduvatelt sessioonidelt või suur koheste korduste osakaal hoolimata Retry-After pärisest. Seejuures piisab sageli pseudonüümsetest loenduritest ja tehnilistest metadata-andmetest; terviklikud vestlussisud ei kuulu automaatselt koormuslogisse. NIST AI RMF Core rõhutab, et KI-süsteeme tuleks enne kasutuselevõttu ja regulaarselt töö käigus mõõta ning testida.

Testplaan enne lõplikku aktiveerimist

• Tavalisi üksikvestlusi ja lühikesi lubatud koormuspurskeid ei piirata.
• Väga pikad sisendid piiratakse enne kalleid mudeli- või otsingukutseid.
• Paljud paralleelsed vahekaardid jagavad õigesti sama sessiooni- või konto eelarvet.
• Mitu tavakasutajat ühe IP-aadressi taga ei saa üldist blokeeringut.
• 429 ja 503 sisaldavad ühtset ning arusaadavat ooteinfot.
• Klientrakendused austavad pärist Retry-After ega tekita korduspäringute lainet.
• Piiratud režiim säilitab allika-, andmekaitse- ja turvapiirid.
• Ülemaailmne kulumäär peatab kalli funktsionaalsuse ilma olekulehte või kontaktikanalit mõjutamata.

Praktiline meeldetuletus veebimeeskondadele

1. Mõõda ressursikulu ja kulu ühe eduka vestluse kohta.
2. Määra eraldi piirangud päringutele, tokenitele, rööpsusele, otsingule, järjekorrale ja eelarvele.
3. Eelista autenditud identiteete ja kombineeri anonüümseid signaale andmesäästlikult.
4. Testi lävesid esmalt varjurežiimis (shadow mode) tegeliku kasutuskoormusega.
5. Testi 429, 503 ja Retry-After toimimist API-s ja liideses.
6. Dokumenteeri sujuv kohandumine, üleandmine ja üldine hädapidur.
7. Analüüsi valeblokeeringuid, kulusid ja koormust regulaarselt meeskonnaga.

Kokkuvõte: head päringupiirangud kaitsevad teenust ja kasutajat

KI-juturoboti päringupiirangud on arhitektuuriline ülesanne, mitte üksik number sisuhaldusvõrgus (CDN). Piiramatut kulumist hoiab ära alles koguse-, tokeni-, rööpsuse- ja kulupõhiste eelarvete kombinatsioon. Õiglane identiteet, selge kordusloogika ja läbipaistev varuteenus tagavad, et kaitse ei muutu halvaks kasutajakogemuseks.

Kes soovib oma veebilehe juturobotit stabiilselt käitada, peaks alustama mõõdetud ressursikaardist ja tugevdama reeglistikku kontrollitult. Kontrolli oma ChatReacti rakenduses, millised eelarved sobivad sinu veebilehe liiklusega, ja testi piire enne nende lõplikku sisselülitamist.

Allikad

• 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