Rate limits pro AI chatboty: FÉR spravedlivé omezení nákladů a zátěže

Veřejně přístupný webový chatbot může během několika sekund vyvolat více výpočetní práce než klasická kontaktní stránka za celou návštěvu. Jediná zpráva může spustit retrieval, reranking, několik volání modelu a další kontroly. Bez jasných limitů tak nestačí jen velký botový útok: i chybný klient, mnoho otevřených záložek najednou nebo automatická smyčka opakování (retry loop) mohou vyhnat doby odezvy a náklady do výšin.

Rate limits pro AI chatboty by přitom neměly být chápány jako pevná blokáda. Dobré limity spravedlivě rozdělují vzácné zdroje, chránějí rozpočet nákladů a zachovávají pro legitimní uživatele srozumitelnou zbytkovou službu. Tento praktický průvodce ukazuje, jaká množství by měly webové týmy omezovat, jak vytvořit spravedlivou identitu a jakou odpověď musí chatbot při vysoké zátěži poskytnout.

Proč nestačí pouhý limit požadavků za minutu

U běžných API jsou dva požadavky často přibližně stejně drahé. U AI chatbota však může krátké přivítání spotřebovat jen několik tokenů, zatímco dlouhá analýza dokumentu, široký retrieval nebo více kroků modelu spotřebují mnohonásobně více. Aktuální OWASP GenAI LLM Top 10 2026 uvádí nekontrolovanou spotřebu zdrojů jako Unbounded Consumption. Podstatou je nákladová asymetrie: útočník nebo vadný klient může s malým vlastním úsilím vyvolat nepřiměřeně drahé zpracování.

Také OWASP API4:2023 uvádí vedle frekvence interakcí další limity, jako je doba provádění, paměť, velikost uploadu, operace na požadavek a výdaje u služeb třetích stran. Pro chatboty z toho vyplývá: pravidla (policy) musejí nejen počítat požadavky, ale plánovat rozpočet pro celou cestu zpracování.

Sedm zdrojů, které potřebují samostatné rozpočty

Odolný koncept začíná malou mapou zdrojů. Pro každou dimenzi se stanoví, kdy je požadavek přijat, zkrácen, zpožděn nebo odmítnut.

• Požadavky: počet za krátkou fázi špičky (burst) a za delší časové okno.
• Paralelita: současně běžící odpovědi na uživatele, relaci a tenanta.
• Vstup: znaky, přílohy a odhadované vstupní tokeny před voláním modelu.
• Výstup: maximální rozpočet odpovědi a smysluplné přerušení při nekonečných smyčkách.
• Retrieval: počet variant vyhledávání, výsledků, kandidátů pro reranking a dodatečně načtených dokumentů.
• Fronta: otevřené úlohy a maximální doba čekání, než se uplatní jasný fallback.
• Náklady: denní nebo měsíční rozpočet na organizaci a globální nouzová brzda.

Špičky (bursts) a dlouhá časová okna ošetřujte odděleně

Tyto limity jsou propojené, ale nejsou vzájemně zastupitelné. Velkorysý denní rozpočet nezabrání špičkové zátěži v jedné sekundě. Limit požadavků zase nechrání před jediným extrémně drahým dotazem. Pro technický provoz se proto vyplatí kombinace s explicitním rozpočtem latence, time-outy a kontrolovanými opakováními.

Spravedlivá identita místo plošného blokování IP

Proč samotná IP adresa nestačí

HTTP standard RFC 6585 záměrně nepředepisuje, jak má server rozpoznat uživatele nebo počítat požadavky. To je důležité, protože samotná IP adresa není spolehlivým pojmem pro uživatele. V firmách, hotelech, mobilních sítích nebo rodinách může mnoho lidí sdílet stejnou veřejnou adresu. A naopak, automatizovaný klient může své IP adresy měnit.

Kombinujte signály šetrné k datům

Pro přihlášené oblasti jsou nejsilnějšími klíči organizace, účet a ID uživatele. U veřejného chatbota se doporučuje odstupňovaná kombinace krátkodobé relace šetrné k datům, hrubého síťového signálu a aktuálního vzorce rizika. Surové prompty, trvalé otisky zařízení (fingerprints) nebo zbytečně přesné protokoly IP k tomu nejsou potřeba. Kde se používají osobní údaje účtu, musejí být hranice autentizovaného chatbota v zákaznickém portálu plánovány odděleně.

Pravidla by navíc měla umožňovat legitimitní opakování. Uživatel může zprávu poslat znovu kvůli nestabilnímu připojení nebo potřebovat více interakcí kvůli asistivním technologiím. Podezřelý je proto zřídkakdy jediný signál, ale kombinace vysoké frekvence, dlouhých vstupů, mnoha paralelních relací a opakovaného vyčerpávání drahých cest.

Odvozujte limity z naměřených hodnot, nehdefinitionte je odhadem

Dobrá výchozí hodnota vzniká z reálných, úspěšných konverzací. Tým několik týdnů měří vstupní a výstupní tokeny, výsledky retrievalu, dobu běhu, paralelitu a náklady na dokončený úkol. Poté se odděleně posuzuje běžné použití, špičky a odlehlé hodnoty. Limit se nachází nad nejvyšší pravděpodobnou legitimní špičkou, ale pod hranicí, kde by jediný aktér mohl ohrozit službu nebo rozpočet.

Příklad: Většina rozhovorů vyžaduje nejvýše tři odpovědi za minutu a zůstává hluboko pod tokenovým rozpočtem. Krátká špička tak může pojmout více zpráv, zatímco déle běžící okno omezuje celkové množství. Drahým analytickým cestám je navíc přidělen menší samostatný kontingent. Rozhodující není konkrétní číslo z cizího systému, ale zdokumentovaný vztah k zátěžovému testu, nákladovému modelu a chování uživatelů.

Změny patří nejprve do pozorovacího režimu (Shadow Mode). Systém protokoluje, které legitimní relace by plánovaný limit zasáhl, aniž by je již blokoval. Prahové hodnoty se tak postupně kalibrují a zviditelní se zbytečné blokace.

Víceúrovňový ochranný řetězec pro každý požadavek

1. Kontrola na vstupu: velikost payloadu, typ souboru, relace a zjevná opakování se vyhodnocují ještě před retrievalem a voláním modelu.
2. Předběžný odhad nákladů: délka vstupu, požadovaný výstup, šíře retrievalu a třída modelu dají hrubou „váhu“ požadavku.
3. Atomická rezervace rozpočtu: relace, uživatel, organizace a globální fond se kontrolují společně. Současně přicházející požadavky nesmějí stejný zbývající rozpočet spotřebovat víckrát.
4. Omezení doby běhu: time-outy, maximální kroky modelu a zastropovaná fronta zastaví drahé zaseknutí.
5. Zúčtování skutečné spotřeby: po dokončení nahradí reálná spotřeba odhad. Přerušení a chyby poskytovatele zůstávají viditelné jako samostatné metriky.

Tento řetězec leží na straně serveru. Tlačítko odeslání skryté v prohlížeči je užitečné UX, ale ne bezpečnostní hranice. Totéž platí pro instrukce v promptu: nenahrazují ani technický limiter, ani ochranu proti prompt injection u webových chatbotů.

429, Retry-After a nebezpečí vlny opakovaných dotazů

Pokud je kontingent spojený s uživatelem vyčerpán, vhodnou strojově čitelnou odpovědí je HTTP 429 Too Many Requests. RFC 6585 doporučuje vysvětlení a umožňuje hlavičku Retry-After. Klient by měl tento časový údaj respektovat, neodesílat dotaz znovu okamžitě a srozumitelně zobrazit stav odeslání. Více klientů by ideálně mělo dostat mírně náhodné rozptýlení, aby nezačali všichni znovu ve stejný okamžik.

Při obecném dočasném přetížení může naopak vyhovovat HTTP 503 Service Unavailable. RFC 9110 popisuje, že Retry-After může být odeslán jako HTTP datum nebo doba čekání v sekundách. Neidempotentní akce se nesmějí nikdy opakovat slepě: nejprve musí být jednoznačně vyjasněno, zda již rezervace nebo předání proběhly.

V rozhraní chatu potřebuje technická odpověď lidsky srozumitelný text: proč se právě nezpracovává, kdy má smysl nový pokus a jaká alternativa zůstává. Zpráva by měla být programově rozpoznatelná pro asistivní technologie. Vysvětlení W3C k WCAG 2.2 Status Messages ukazuje, jak lze oznamovat změny stavu bez vynucené změny zaměření (fokusu).

Graceful degradation zachovává užitečnou zbytkovou službu

Tvrdé kompletní zablokování není vždy tou nejlepší reakcí. Při zátěži může chatbot volitelně poskytovat kratší odpovědi, kontrolovat méně kandidátů retrievalu nebo vynechat časově nekritické vyhodnocení. Důležitá je transparentnost: uživatel musí poznat, že je právě aktivní omezený režim. Zdroje, bezpečnostní kontroly a autorizace přitom nesmějí tichou cestou odpadnout.

Pro naléhavé záležitosti by měla existovat jednoduchá možnost kontaktu nebo předání operátorovi (handoff). Pokud je i tato cesta vytížená, systém zobrazí spolehlivou alternativu místo vymysleného příslibu. Kritéria pro degradaci, vypnutí a opětovný náběh patří do plánu reakce na incidenty a rollbacku.

Které metriky činí ochranu řiditelnou

Samotný počet odpovědí 429 toho moc neříká. Použitelný přehledový panel (dashboard) rozlišuje podle dimenze limitu a třídy uživatelů: přijaté a omezené požadavky, paralelní běhy, doba čekání, vstupní a výstupní tokeny, šíře retrievalu, náklady na úspěšný rozhovor a chyby poskytovatele. Navíc je potřeba vzorek zablokovaných relací k odhalení falešných poplachů.

Alerting by měl reagovat na změny: neobvyklý nárůst nákladů za minutu, prudce rostoucí fronta, mnoho dlouhých vstupů z měnících se relací nebo vysoký podíl okamžitých opakování navzdory Retry-After. Přitom často stačí pseudonymní čítače a technická metadata; úplné obsahy konverzací nepatří automaticky do každého protokolu zátěže. NIST AI RMF Core zdůrazňuje, že systémy AI by měly být měřeny a testovány před nasazením a pravidelně i během provozu.

Plán testování před ostrým aktivováním

• Běžné jednotlivé konverzace a krátké legitimní špičky zůstávají nedotčeny.
• Velmi dlouhé vstupy jsou omezeny ještě před drahými voláními modelu nebo retrievalu.
• Mnohé paralelní záložky správně sdílejí stejný rozpočet relace nebo účtu.
• Více legitimních uživatelů za společnou IP adresou není plošně zablokováno.
• Odpovědi 429 a 503 obsahují konzistentní, srozumitelné informace o čekání.
• Klienti respektují Retry-After a nezpůsobují vlnu opakovaných dotazů.
• Omezený režim zachovává hranice zdrojů, ochrany dat a bezpečnosti.
• Globální limit nákladů zastaví drahou cestu, aniž by strhl stavovou stránku nebo kontaktní cestu.

Praktický kontrolní seznam pro webové týmy

1. Změřte cestu zdrojů a náklady na úspěšný rozhovor.
2. Definujte samostatné limity pro požadavky, tokeny, paralelitu, retrieval, frontu a rozpočet.
3. Upřednostňujte přihlášené identity a anonymní signály kombinujte šetrně k datům.
4. Prahové hodnoty nejprve otestujte v režimu Shadow Mode oproti reálnému provozu.
5. Otestujte chování 429, 503 a Retry-After v API i v uživatelském rozhraní.
6. Zdokumentujte graceful degradation, handoff a globální nouzovou brzdu.
7. Pravidelně společně vyhodnocujte chybné blokace, náklady a zátěž.

Závěr: Dobré rate limits chránějí službu i uživatele

Rate limits pro AI chatboty jsou architektonickým úkolem, nikoli jediným číslem na CDN. Teprve kombinace rozpočtů zaměřených na množství, tokeny, paralelitu a náklady zabrání nekontrolované spotřebě. Spravedlivá identita, jasná sémantika opakování a transparentní zbytková služba zajišťují, že se ochrana nepromění ve špatnou uživatelskou zkušenost.

Kdo chce svého webového chatbota provozovat stabilně, měl by začít naměřenou mapou zdrojů a pravidla kontrolovaně zpřísňovat. Proberte pro nasazení nástroje ChatReact, které rozpočty odpovídají vaší návštěvnosti webu, a otestujte hranice před ostrým spuštěním.

Zdroje

• 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