KI-Chatbot Rate Limits: Pravedno ograničavanje troškova i opterećenja

Javno dostupan web chatbot može u nekoliko sekundi pokrenuti više računalnog rada nego klasična kontakt stranica u cijelom posjetu. Jedna jedina poruka potencijalno pokreće dohvaćanje (Retrieval), ponovno rangiranje (Reranking), više poziva modela i dodatne provjere. Bez jasnih granica stoga nije dovoljan samo veliki bot napad: i neispravan klijent, više istovremeno otvorenih kartica ili automatska petlja ponovnih pokušaja mogu drastično povećati vrijeme odziva i troškove.

KI-Chatbot Rate Limits pri tome ne bi trebalo shvaćati ako krutu blokadu. Dobra ograničenja pravedno raspoređuju oskudne resurse, štite proračun troškova i održavaju razumljivu preostalu uslugu za legitimne korisnike. Ovaj praktični vodič pokazuje koje količine web timovi trebaju ograničiti, kako nastaje pravedna identifikacija i kakav odgovor chatbot mora dati pri visokom opterećenju.

Zašto samo ograničenje broja zahtjeva po minuti nije dovoljno

Kod normalnih API-ja, dva zahtjeva su često podjednako skupa. Kod AI chatbota, međutim, kratak pozdrav može potrošiti samo nekoliko tokena, dok duga analiza dokumenta, opsežno dohvaćanje ili više koraka modela troše višestruko više. Aktualni OWASP GenAI LLM Top 10 2026 navodi nekontroliranu potrošnju resursa kao Unbounded Consumption. Suština je asimetrija troškova: napadač ili neispravan klijent s malim vlastitim trudom može pokrenuti razmjerno skupu obradu.

I OWASP API4:2023 uz stopu interakcije navodi i druge granice kao što su vrijeme izvršavanja, memorija, veličina prijenosa, operacije po zahtjevu i izdatci kod usluga trećih strana. Za chatbotove iz toga slijedi: politika mora ne samo brojati zahtjeve, već i usmjeravati proračun za cijeli put obrade.

Sedam resursa koji trebaju zasebne proračune

Pouzdan koncept počinje s malom kartom resursa. Za svaku dimenziju utvrđuje se kada se zahtjev prihvaća, skraćuje, odgađa ili odbija.

• Zahtjevi: Broj po kratkoj burst fazi i po duljem vremenskom prozoru.
• Paralelizam: Istovremeno pokrenuti odgovori po korisniku, sesiji i klijentu (tenant).
• Unos: Znakovi, privitci i procijenjeni ulazni tokeni prije nego što se pozove model.
• Izlaz: Maksimalni proračun odgovora te smisleni prekid u slučaju beskonačnih petlji.
• Dohvaćanje (Retrieval): Broj varijanti pretraživanja, pogodaka, kandidata za ponovno rangiranje i naknadno učitanih dokumenata.
• Red čekanja (Queue): Otvoreni zadaci i maksimalno vrijeme čekanja prije nego što stupi na snagu jasan fallback.
• Troškovi: Dnevni ili mjesečni proračun po organizaciji te globalna kočnica za nuždu.

Zasebno tretiranje kratkih vršnih opterećenja (bursts) i dugih vremenskih prozora

Ove granice su međusobno povezane, ali nisu zamjenjive. Velikodušan dnevni proračun ne sprečava vršno opterećenje u jednoj sekundi. Ograničenje zahtjeva opet ne štiti od jednog iznimno skupog zahtjeva. Za tehničko vrijeme izvršavanja stoga se isplati kombinacija s eksplicitnim proračunom latencije, timeoutima i kontroliranim ponovnim pokušajima.

Pravedna identifikacija umjesto paušalne blokade IP adrese

Zašto sama IP adresa nije dovoljna

HTTP standard RFC 6585 namjerno ne propisuje kako poslužitelj prepoznaje korisnika ili broji zahtjeve. To je važno jer sama IP adresa nije pouzdan pojam korisnika. U tvrtkama, hotelima, mobilnim mrežama ili obiteljima, mnogi ljudi mogu dijeliti istu javnu adresu. Obrnuto, automatizirani klijent može mijenjati svoje IP adrese.

Kombiniranje signala štedljivih po pitanju podataka

Za prijavljena područja, najjači ključevi su organizacija, račun i korisnički ID. Kod javnog chatbota preporučuje se stupnjevana kombinacija kratkotrajne sesije štedljive po pitanju podataka, grubog mrežnog signala i trenutnog uzorka rizika. Sirovi promptovi, trajni otisci prstiju uređaja ili nepotrebno precizni IP dnevnici za to nisu potrebni. Gdje se koriste osobni podaci računa, granice autentificiranog chatbota na korisničkom portalu moraju se planirati odvojeno.

Politika bi također trebala dopustiti legitimna ponavljanja. Korisnik može ponovno poslati poruku zbog nestabilne veze ili trebati više interakcija s asistivnim tehnologijama. Stoga je rijetko sumnjiv pojedinačni signal, već kombinacija visoke frekvencije, dugih unosa, mnogih paralelnih sesija i učestalog iskorištavanja skupih putanja.

Izvođenje ograničenja iz mjernih vrijednosti, a ne nagađanjem

Dobra početna vrijednost proizlazi iz stvarnih, uspješnih razgovora. Tim nekoliko tjedana mjeri ulazne i izlazne tokene, pogotke dohvaćanja, vrijeme izvršavanja, paralelizam i troškove po završenom zadatku. Nakon toga se zasebno promatraju normalno korištenje, vršna opterećenja i odstupanja. Limit se postavlja iznad uvjerljivog legitimnog vrha, ali ispod područja u kojem pojedinačni akter ugrožava uslugu ili proračun.

Primjer: Većina razgovora zahtijeva najviše tri odgovora u minuti i ostaje daleko ispod proračuna tokena. Tada kratki burst može prihvatiti više poruka, dok dulji prozor ograničava ukupnu količinu. Skupi putevi analize dodatno dobivaju manji zasebni kontingent. Ključna nije konkretna brojka iz tuđeg sustava, već dokumentirana povezanost s testom opterećenja, modelom troškova i ponašanjem korisnika.

Promjene najprije spadaju u promatrački promatrački način (Shadow Mode). Sustav bilježi koje bi legitimne sesije pogodile planirani limit, bez da ih već blokira. Tako se pragovi postupno kalibriraju i uočavaju nepotrebne blokade.

Višerazinski zaštitni lanac za svaki zahtjev

1. Provjera na ulazu: Veličina payload-a, vrsta datoteke, sesija i očita ponavljanja procjenjuju se prije dohvaćanja i poziva modela.
2. Unaprijed procijeniti troškove: Duljina unosa, željeni izlaz, širina dohvaćanja i klasa modela daju grubu težinu zahtjeva.
3. Atomski rezervirati proračune: Sesija, korisnik, organizacija i globalni bazen provjeravaju se zajedno. Zahtjevi koji pristižu paralelno ne smiju više puta potrošiti isti preostali proračun.
4. Ograničiti vrijeme izvršavanja: Timeout-i, maksimalni koraci modela i ograničeni red čekanja zaustavljaju skupa zastajkivanja.
5. Proknjižiti stvarnu potrošnju: Po završetku, stvarna potrošnja zamjenjuje procjenu. Prekidi i pogreške pružatelja usluga ostaju vidljivi kao zasebne mjerne vrijednosti.

Ovaj lanac nalazi se na poslužiteljskoj strani. Gumb za slanje skriven u pregledniku je koristan UX, ali nije sigurnosna granica. Isto vrijedi za upute u promptu: one ne zamjenjuju niti tehnički limiter niti zaštitu od Prompt Injection-a kod web chatbotova.

429, Retry-After i opasnost od vala ponovnih pokušaja

Ako je kontingent vezan uz korisnika iscrpljen, HTTP 429 Too Many Requests je odgovarajući strojno čitljiv odgovor. RFC 6585 preporučuje objašnjenje i dopušta Retry-After zaglavlje. Klijent bi trebao poštivati taj trenutak, ne slati odmah ponovno i prikazati status slanja na razumljiv način. Više klijenata idealno dobiva malo nasumičnog raspršenja kako ne bi počeli ponovno u isto vrijeme.

Kod općeg privremenog preopterećenja, s druge strane, može odgovarati HTTP 503 Service Unavailable. RFC 9110 opisuje da se Retry-After može poslati kao HTTP datum ili vrijeme čekanja u sekundama. Neidempotentne radnje ne smiju se nikada slijepo ponavljati: prvo se mora jasno utvrditi je li rezervacija ili primopredaja već izvršena.

U sučelju chata tehnički odgovor treba ljudski tekst: zašto se trenutno ne obrađuje dalje, kada je novi pokušaj smislen i koja alternativa preostaje. Poruka bi trebala biti programski prepoznatljiva za asistivnu tehnologiju. W3C objašnjenje za WCAG 2.2 Status Messages pokazuje kako se promjene stanja mogu najaviti bez prisilnog promjena fokusa.

Graceful Degradation održava korisnu preostalu uslugu

Kuta kompletna blokada nije uvijek najbolja reakcija. Pod opterećenjem chatbot opcionalno može pružiti kraće odgovore, provjeriti manje kandidata za dohvaćanje ili izostaviti analizu koja nije vremenski kritična. Važna je transparentnost: korisnik mora prepoznati da je trenutno aktivan ograničeni način rada. Izvori, sigurnosne provjere i autorizacija pri tome ne smiju tiho izostati.

Za hitne upite trebala bi postojati jednostavna opcija kontakta ili prijenosa na čovijeka (handoff). Ako je i taj put preopterećen, sustav prikazuje pouzdanu alternativu umjesto izmišljenog obećanja. Kriteriji za smanjenje razine usluge, isključivanje i ponovno pokretanje spadaju u plan za odgovor na incidente i rollback.

Koje ključne brojke čine zaštitu upravljivom

Sam broj 429 odgovora govori malo. Korisna nadzorna ploča razdvaja po dimenziji limita i klasi korisnika: prihvaćeni i ograničeni zahtjevi, paralelna pokretanja, trajanje čekanja, ulazni i izlazni tokeni, širina dohvaćanja, troškovi po uspješnom razgovoru i pogreške pružatelja usluga. Dodatno je potreban uzorak blokiranih sesija kako bi se prepoznali lažni alarmi.

Alarmi bi trebali reagirati na promjene: neuobičajeni porast troškova po minuti, naglo rastući red čekanja, mnogi dugi unosi iz izmjenjivih sesija ili visok udio trenutnih ponavljanja unatoč Retry-After. Pri tome su često dovoljni pseudonimizirani brojači i tehnički metapodaci; cjeloviti sadržaji razgovora ne spadaju automatski u svaki zapisnik opterećenja. NIST AI RMF Core naglašava da bi se AI sustavi trebali mjeriti i testirati prije uporabe i redovito u radu.

Plan testiranja prije službenog aktiviranja

• Normalni pojedinačni razgovori i kratki legitimni burst-ovi ostaju neometani.
• Vrlodugi unosi ograničavaju se prije skupih poziva modela ili dohvaćanja.
• Mnoge paralelne kartice ispravno dijele isti proračun sesije ili računa.
• Više legitimnih korisnika iza zajedničke IP adrese ne blokira se paušalno.
• 429 i 503 sadrže dosljedne, razumljive informacije o čekanju.
• Klijenti poštuju Retry-After i ne stvaraju val ponovnih pokušaja.
• Ograničeni način rada čuva granice izvora, zaštite podataka i sigurnosti.
• Globalni limit troškova zaustavlja skupi put bez da povuče za sobom stranicu statusa ili kontaktni put.

Praktičan kontrolni popis za web timove

1. Izmjeriti put resursa i troškove po uspješnom razgovoru.
2. Definirati zasebna ograničenja za zahtjeve, tokene, paralelizam, dohvaćanje, red čekanja i proračun.
3. Dati prednost prijavljenim identitetima i kombinirati anonimne signale štedljivo po pitanju podataka.
4. Pragove najprije provjeriti u Shadow Modeu naspram stvarne upotrebe.
5. Testirati ponašanje 429, 503 i Retry-After u API-ju i sučelju.
6. Dokumentirati Graceful Degradation, handoff i globalnu kočnicu za nuždu.
7. Redovito zajedno procjenjivati pogrešne blokade, troškove i opterećenje.

Zaključak: Dobri Rate Limits štite uslugu i korisnike

Rate limits za AI chatbotove su arhitektonski zadatak, a ne pojedinačni broj na CDN-u. Tek kombinacija proračuna vezanih uz količinu, tokene, paralelizam i troškove sprečava nekontroliranu potrošnju. Pravedna identifikacija, jasna semantika ponovnih pokušaja i transparentna preostala usluga osiguravaju da zaštita ne postane loše korisničko iskustvo.

Tko želi stabilno upravljati svojim web chatbotom, trebao bi započeti s izmjerenom kartom resursa i kontrolirano poostravati politiku. Provjerite za svoju upotrebu ChatReact-a koji proračuni odgovaraju vašem web prometu i testirajte granice prije službenog aktiviranja.

Izvori

• 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