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

Egy nyilvánosan elérhető weboldal-chatbot másodpercek alatt több számítási kapacitást igényelhet, mint egy klasszikus kapcsolati oldal egy teljes látogatás során. Egyetlen üzenet elindíthatja a keresést (retrieval), a rangsorolást (reranking), több modellhívást és egyéb ellenőrzéseket. Egyértelmű korlátok nélkül ezért nemcsak egy nagy bot-támadás jelent veszélyt: egy hibás kliens, a párhuzamosan nyitva hagyott böngészőlapok vagy egy automatikus újrapróbálkozási hurok is egekbe emelheti a válaszidőket és a költségeket.

A KI-Chatbot-Rate-Limits megoldásokra nem merev tiltásként kell tekinteni. A jó korlátozások igazságosan osztják el a szűkös erőforrásokat, védik a költségkeretet, és a legitim felhasználók számára is érthető, elérhető szolgáltatást tartanak fenn. Ez a gyakorlati útmutató megmutatja, milyen mennyiségeket érdemes korlátozniuk a weboldal-csapatoknak, hogyan hozható létre az igazságos azonosítás, és milyen választ kell adnia a chatbotnak nagy terhelés esetén.

Miért nem elég a puszta percenkénti kérésszám korlátozása?

A normál API-k esetében két kérés gyakran nagyjából ugyanannyiba kerül. Egy AI-chatbotnál azonban egy rövid üdvözléshez csupán néhány token szükséges, míg egy hosszú dokumentumelemzés, egy széles körű keresés vagy több modell lépés ennek többszörösét fogyasztja. A jelenlegi OWASP GenAI LLM Top 10 2026 a korlátlan erőforrás-fogyasztást Unbounded Consumption néven tartja számon. A lényeg a költség-aszimmetria: egy támadó vagy egy hibás kliens minimális saját ráfordítással aránytalanul drága feldolgozást indíthat el.

Az OWASP API4:2023 is megemlít az interakciós rátán kívül más korlátokat, például a végrehajtási időt, a memóriát, a feltöltési méretet, a kérésenkénti műveleteket és a harmadik féltől származó szolgáltatások kiadásait. A chatbotok esetében ebből az következik: a szabályzatnak nemcsak a kéréseket kell számolnia, hanem a teljes feldolgozási útvonalat kell büdzsélnie.

Hét erőforrás, amely külön büdzsét igényel

Egy megbízható koncepció egy kis erőforrás-térképpel kezdődik. Minden dimenzióra meghatározzák, mikor fogadnak el, rövidítenek le, késleltetnek vagy utasítanak vissza egy kérést.

• Kérések: Mennyiség a rövid terhelési tüskék (burst) alatt és a hosszabb időablakokban.
• Párhuzamosság: Egyidejűleg futó válaszok felhasználónként, munkamenetenként és bérlőnként.
• Bemenet: Karakterek, csatolt fájlok és a becsült bemeneti tokenek a modell meghívása előtt.
• Kimenet: Maximális válaszbüdzsé, valamint a végtelen ciklusok ésszerű megszakítása.
• Retrieval: A keresési variációk, találatok, reranking-jelöltek és utólag betöltött dokumentumok száma.
• Várakozási sor: Nyitott feladatok és a maximális várakozási idő, mielőtt egy egyértelmű tartalék mechanizmus lépne életbe.
• Költségek: Napi vagy havi költségkeret szervezetenként, valamint egy globális vészfék.

A kiugró terheléseket (burst) és a hosszú időablakokat kezelje külön

Ezek a korlátok összefüggenek, de nem helyettesíthetők egymással. Egy nagyvonalú napi büdzsé nem akadályoz meg egy egymásodperces terhelési csúcsot. A kérésalapú limit pedig nem véd meg egyetlen, rendkívül drága kéréstől. A technikai futásidő érdekében érdemes kombinálni a megoldást egy explicit latencia-büdzsével, időtúllépésekkel (timeouts) és ellenőrzött újrapróbálkozásokkal.

Igazságos azonosítás az általános IP-blokkolás helyett

Miért nem elég önmagában egy IP-cím?

A HTTP-szabvány RFC 6585 szándékosan nem írja elő, hogyan ismerjen fel a szerver egy felhasználót, vagy hogyan számolja a kéréseket. Ez azért fontos, mert az IP-cím önmagában nem megbízható azonosító. Vállalatoknál, szállodákban, mobilhálózatokon vagy családoknál sokan osztozhatnak ugyanazon a nyilvános címen. És fordítva: egy automatizált kliens könnyedén váltogathatja az IP-címeit.

Adattakarékos jelek kombinálása

Bejelentkezett felületeken a szervezet, a fiók és a felhasználói azonosító (User ID) jelenti a legbiztosabb kulcsot. Nyilvános chatbot esetén a rövid életű, adattakarékos munkamenet, a durva hálózati jel és a mindenkori kockázati mintázat lépcsőzetes kombinációja ajánlott. Nyers promptok, tartós eszköz-ujjlenyomatok (device fingerprinting) vagy szükségtelenül pontos IP-naplózás nem szükségesek hozzá. Ahol személyes fiókadatokat használnak, ott a hitelkerettel rendelkező, hitelesített ügyfélportál-chatbotok korlátait külön kell megtervezni.

A szabályzatnak emellett engedélyeznie kell a jogos újrapróbálkozásokat. Egy felhasználó az instabil kapcsolat miatt újra elküldheti az üzenetet, vagy a kisegítő technológiák miatt több interakcióra lehet szüksége. Ezért ritkán gyanús egyetlen jel, sokkal inkább a magas frekvencia, a hosszú bemenetek, a sok párhuzamos munkamenet és a drága útvonalak ismételt kimerítésének kombinációja.

Mérési adatokból vezesse le a limiteket, ne találgasson

A jó kiindulási érték a valódi, sikeres beszélgetésekből származik. A csapat néhány hétig méri a bemeneti és kimeneti tokeneket, a retrieval-találatokat, a futásidőt, a párhuzamosságot és a befejezett feladatonkénti költségeket. Ezt követően a normál használatot, a csúcsokat és a kiugró értékeket külön vizsgálják. A limit a reális, legitim csúcsérték felett van, de az alatt a tartomány alatt, ahol egyetlen szereplő veszélyeztetné a szolgáltatást vagy a büdzsét.

Példa: A legtöbb beszélgetéshez legfeljebb három válaszra van szükség egy percen belül, és jóval a token-büdzsé alatt marad. Ebben az esetben egy rövid terhelési tüske több üzenetet fogadhat be, míg egy hosszabb időablak korlátozza a teljes mennyiséget. A drága elemzési útvonalak ezen felül kisebb, külön kontingenst kapnak. A döntő nem egy idegen rendszerből vett konkrét szám, hanem a terhelési teszthez, a költségmodellhez és a felhasználói viselkedéshez való dokumentált illeszkedés.

A módosításokat először megfigyelő árnyékmódban (Shadow Mode) kell alkalmazni. A rendszer rögzíti, hogy mely legitim munkameneteket érintett volna a tervezett limit, anélkül hogy ténylegesen blokkolná azokat. Így a küszöbértékek lépésről lépésre kalibrálhatók, és a felesleges tiltások láthatóvá válnak.

Többszintű védelmi lánc minden egyes kéréshez

1. Ellenőrzés a belépésnél: A hasznos teher (payload) mérete, a fájltípus, a munkamenet és a nyilvánvaló ismétlődések értékelése a retrieval és a modellhívás előtt történik.
2. Költségek előzetes becslése: A bemeneti hossz, a kívánt kimenet, a retrieval szélessége és a modellosztály kiad egy durva súlyozást a kérésre.
3. Büdzsék atomi lefoglalása: A munkamenet, a felhasználó, a szervezet és a globális pool ellenőrzése együtt történik. A párhuzamosan érkező kérések nem fogyaszthatják el többszörösen ugyanazot a maradék büdzsét.
4. Futásidő korlátozása: Az időtúllépések (timeouts), a maximális modell-lépések és a korlátozott várakozási sor leállítják a drága lefagyásokat.
5. Tényleges fogyasztás elkönyvelése: A befejezés után a reális fogyasztás felváltja a becslést. A megszakítások és a szolgáltatói hibák külön mérési értékként láthatók maradnak.

Ez a lánc a szerveroldalon található. A böngészőben elrejtett küldés gomb hasznos UX, de nem biztonsági korlát. Ugyanez vonatkozik a prompt-utasításokra is: nem helyettesítik sem a technikai limitert, sem a weboldal-chatbotok prompt injection védelmét.

429, Retry-After és az újrapróbálkozási hullám veszélye

Ha a felhasználóhoz kötött kontingens kimerült, a géppel olvasható megfelelő válasz a HTTP 429 Too Many Requests. Az RFC 6585 magyarázatot javasol, és engedélyezi a Retry-After fejléces használatát. A kliensnek tiszteletben kell tartania ezt az időpontot, nem szabad azonnal újra elküldenie a kérést, és a küldési állapotot érthetően meg kell jelenítenie. Több kliens esetén ideális esetben némi véletlenszerű szórást (jitter) alkalmaznak, hogy ne egyszerre induljanak újra.

Általános, átmeneti túlterheltség esetén viszont a HTTP 503 Service Unavailable válasz lehet megfelelő. Az RFC 9110 leírja, hogy a Retry-After HTTP-dátumként vagy másodpercben megadott várakozási időként küldhető el. Nem idempotens műveleteket soha nem szabad vakon megismételni: először egyértelműen tisztázni kell, hogy a foglalás vagy az átadás megtörtént-e már.

A chat-felületen a technikai válasznak emberi szövegre van szüksége: miért nem dolgozható fel éppen a kérés, mikor van értelme az újabb próbálkozásnak, és milyen alternatíva marad. Az üzenetnek a segítő technológiák számára programozottan felismerhetőnek kell lennie. A W3C útmutatója a WCAG 2.2 Status Messages témában megmutatja, hogyan jelenthetők be az állapotváltozások kikényszerített fókuszváltás nélkül.

A Graceful Degradation hasznos maradék szolgáltatást biztosít

A teljes, drasztikus tiltás nem mindig a legjobb reakció. Terhelés alatt a chatbot opcióként adhat rövidebb válaszokat, ellenőrizhet kevesebb retrieval-jelöltet, vagy kihagyhat egy nem időkritikus kiértékelést. A legfontosabb a transzparencia: a felhasználónak látnia kell, hogy éppen korlátozott mód van érvényben. A források, a biztonsági ellenőrzések és az autorizáció nem maradhatnak el meggondolatlanul.

Sürgős ügyekben biztosítani kell egy egyszerű kapcsolati vagy átadási (handoff) lehetőséget. Ha ez az útvonal is túlterhelt, a rendszer egy megbízható alternatívát mutat a kitalált ígéret helyett. A visszasorolás, a leállítás és az újraindulás kritériumait rögzíteni kell a működési hiba elhárítási és rollback tervben.

Milyen mutatók teszik vezérelhetővé a védelmet?

A 429-es válaszok tiszta száma keveset mond el. Egy használható műszerfal dimenzió és felhasználói osztály szerint bontja az adatokat: elfogadott és korlátozott kérések, párhuzamos futások, várakozási idő, bemeneti és kimeneti tokenek, retrieval-szélesség, sikeres beszélgetésenkénti költségek és szolgáltatói hibák. Ezen kívül mintavételre van szükség a blokkolt munkamenetekből a téves riasztások felismeréséhez.

A riasztásoknak a változásokra kell reagálniuk: szokatlan percenkénti költségnövekedés, meredeken növekvő várakozási sor, sok hosszú bemenet váltakozó munkamenetekből, vagy az azonnali újrapróbálkozások magas aránya a Retry-After ellenére. Ehhez a pszeudonimizált számlálók és a technikai metaadatok gyakran elegendőek; a teljes beszélgetéstartalom nem tartozik automatikusan minden terhelési naplóhoz. A NIST AI RMF Core kiemeli, hogy az AI-rendszereket a bevezetés előtt és rendszeresen a működés során is mérni és tesztelni kell.

Tesztterv az élesítés előtt

• A normál egyéni beszélgetések és a rövid, legitim terhelési tüskék zavartalanok maradnak.
• A nagyon hosszú bemeneteket a drága modell- vagy retrieval-hívások előtt korlátozzák.
• A sok párhuzamos fül megfelelően osztozik ugyanazon a munkamenet- vagy fiókbüdzsén.
• A közös IP mögött lévő több legitim felhasználót nem zárják ki általánosságban.
• A 429 és 503 válaszok konzisztens, érthető várakozási információkat tartalmaznak.
• A kliensek tiszteletben tartják a Retry-After fejléces értéket, és nem hoznak létre újrapróbálkozási hullámot.
• A korlátozott mód megőrzi a forrás-, adatvédelmi és biztonsági korlátokat.
• Egy globális költséglimit leállítja a drága útvonalat anélkül, hogy lerántaná a státuszoldalt vagy a kapcsolattartási módot.

Gyakorlati ellenőrzőlista weboldal-csapatoknak

1. Mérje fel az erőforrás-útvonalat és a sikeres beszélgetésenkénti költségeket.
2. Határozzon meg külön korlátokat a kérésekre, tokenekre, párhuzamosságra, retrievalra, várakozási sorra és büdzsére.
3. Részegítse előnyben a bejelentkezett azonosítókat, és kombinálja az névtelen jeleket adattakarékos módon.
4. A küszöbértékeket először árnyékmódban (Shadow Mode) tesztelje a valós használattal szemben.
5. Tesztelje a 429-, 503- és Retry-After viselkedést az API-ban és a felületen.
6. Dokumentálja a Graceful Degradation-t, a handoffot és a globális vészféket.
7. Rendszeresen értékelje közösen a téves tiltásokat, a költségeket és a terhelést.

Összegzés: A jó Rate Limit szabályok védik a szolgáltatást és a felhasználót

A KI-Chatbot-Rate-Limits nem egyetlen szám beállítása a CDN-en, hanem architekturális feladat. A mennyiség-, token-, párhuzamosság- és költségalapú büdzsék kombinációja előzi meg a korlátlan fogyasztást. Az igazságos azonosítás, az egyértelmű újrapróbálkozási szemantika és az átlátható maradék szolgáltatás biztosítja, hogy a védelem ne váljon rossz felhasználói élménnyé.

Aki stabilan szeretné üzemeltetni weboldal-chatbotját, annak érdemes egy felmért erőforrás-térképpel kezdenie, és a szabályzatot ellenőrzötten szigorítania. Ellenőrizze a ChatReact használata során, hogy mely büdzsék illeszkednek a weboldal forgalmához, és tesztelje a korlátokat az élesítés előtt.

Források

• 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