Guardrails jsou mantinely kolem modelu, kontroly na vstupu i výstupu, limity a záložní plány. Model je nedeterministický a ovlivnitelný, takže se s ním nedá zacházet jako s funkcí, která vrátí správný výsledek. Zachází se s ním jako s externí službou, které nevěříš.
Kontroly na vstupu
Než prompt vůbec odešleš:
- Délka. Odmítni nesmyslně dlouhý vstup dřív, než za něj zaplatíš.
- Jazyk a formát. Když aplikace očekává český text a přijde binární balast, nemá cenu volat model.
- Rate limit na uživatele. Bez něj ti jeden skript vygeneruje měsíční účet za odpoledne.
- Zjevný nesmysl a útoky. Jednoduchá detekce (příliš mnoho instrukcí, pokusy o „ignoruj“) nezachytí všechno, ale odfiltruje ty líné pokusy.
Kontroly na výstupu
Tady se rozhoduje, jestli aplikace obstojí:
- Formát. JSON zvaliduj proti schématu; při chybě nech opravit (max jednou dvakrát).
- Rozsahy a číselníky. Kategorie musí být z povoleného seznamu, částka v rozumném rozmezí, datum existující.
- Existence. ID objednávky, odkaz, kód produktu, ověř proti databázi, ne proti dojmu.
- Zdroje. U RAG kontroluj, že citované úryvky opravdu existují a odpověď z nich vychází.
- Citlivý obsah. Nesmí odpověď obsahovat data jiného zákazníka, interní poznámky, systémový prompt?
⚠️ Zásada: model nikdy nesmí být poslední instancí u něčeho, co má následky. Buď to ověří kód, nebo člověk.
Limity a rozpočty
- Tokeny na volání (
max_tokens) i na uživatele za den. - Peníze na běh (hlavně u agentů), tvrdý strop, po kterém se to zastaví.
- Počet kroků agenta.
- Timeout na celý požadavek.
Limity zapiš do kódu, ne do promptu. Prompt se dá obejít, if ne.
Fallbacky
Co se stane, když to nevyjde? Odpověď „spadne to“ je špatná. Připrav si žebříček:
1. zkus znovu (dočasná chyba)
2. zkus jiný / menší model
3. vrať odpověď z cache
4. vrať předpřipravenou odpověď ("teď to nejde, zkuste za chvíli")
5. předej člověku
U zákaznické podpory je nejlepší fallback vždycky člověk a model by měl umět sám poznat, že úlohu nezvládá, a předat ji.
Kdy musí rozhodnout člověk
Nastav si to explicitně, ne od oka:
| Situace | Kdo rozhoduje |
|---|---|
| Návrh textu, shrnutí | model sám |
| Odpověď zákazníkovi u běžného dotazu | model, náhodná kontrola |
| Reklamace, storno, sleva | člověk schvaluje |
| Cokoli s penězi nebo mazáním dat | vždy člověk |
Sledování
Guardrail, o kterém nevíš, že se spouští, je k ničemu. Měř:
- kolik odpovědí neprošlo validací (a proč),
- jak často se sahá po fallbacku,
- kolik požadavků narazilo na limit,
- kolik případů skončilo u člověka.
Když ti podíl fallbacků skočí nahoru, něco se změnilo, typicky verze modelu nebo charakter vstupů.
Kam dál
Guardrails jsou obrana proti tomu, co popisují prompt injection, halucinace a co LLM neumí. Vynucení formátu odpovědi řeší strukturovaný výstup, pravidla pro nevratné akce agenti.
Cvičení
- Rozděl tyhle akce na „model může sám“, „potvrzení člověkem“ a „nikdy přes model“: vyhledat v dokumentaci, vrátit peníze zákazníkovi, poslat shrnutí e-mailem, změnit heslo účtu, vytvořit koncept odpovědi.
- Aplikace má tvrdý limit 10 volání na uživatele za minutu. Proč to nestačí jako ochrana rozpočtu?
Náčrt řešení: rozbal, až si cvičení zkusíš sám
- Sám: vyhledat v dokumentaci, vytvořit koncept. Potvrzení: vrátit peníze, poslat e-mail. Nikdy: změnit heslo. Dělicí čáry jsou dvě. První je vratnost: koncept se zahodí, odeslaný e-mail ne. Druhá je bezpečnostní citlivost: změna hesla je změna přístupu k účtu, a ta patří výhradně do ověřeného toku s druhým faktorem, ne za rozhodnutí modelu. Všimni si, že „poslat shrnutí e-mailem“ vypadá neškodně, ale je to odchozí kanál, tedy i cesta, kterou z tvého systému můžou odtéct data.
- Protože limit počtu volání není limit ceny. Deset volání s kontextem 200 tisíc tokenů je něco úplně jiného než deset volání po tisíci. Rozpočet se hlídá v tokenech a penězích za časové okno, a to zvlášť na uživatele a zvlášť na celou aplikaci. K tomu patří alarm na neobvyklý nárůst, protože nejdražší incidenty bývají smyčky, ne útoky.
Shrnutí
- Ke modelu se chovej jako k nedůvěryhodné externí službě.
- Kontroluj vstup (délka, limity) i výstup (formát, rozsahy, existence, citlivost).
- Limity a autorizaci piš do kódu, ne do promptu.
- Měj připravený žebříček fallbacků a jasně určené, co musí schválit člověk.
Model vrátí validní JSON s ID objednávky, které v databázi neexistuje. Kde selhala ochrana?
Chybí kontrola existence. Schéma ověří tvar, ne pravdivost. ID se musí ověřit dotazem do databáze a při neshodě se odpověď nesmí použít. Model není zdroj pravdy o datech.
Proč nestačí napsat limity (např. „nikdy nenabízej slevu nad 10 %“) do systémového promptu?
Protože prompt je jen doporučení, které se dá obejít, nedeterminismem i cílenou manipulací. Tvrdá pravidla patří do kódu, který výstup zkontroluje, případně do procesu se schválením člověkem.
Co je dobrý fallback pro zákaznického chatbota, když model neodpoví nebo odpověď neprojde kontrolou?
Odstupňovaný: opakování při dočasné chybě, případně jiný model nebo odpověď z cache, a jako poslední (a u citlivých témat první) předání živému člověku spolu s kontextem konverzace.