LLM v produkci

Prototyp postavíš za odpoledne. Rozdíl mezi ním a něčím, co běží rok bez toho, aby tě to budilo v noci, je v provozních detailech: verzování promptů, měření, řízené nasazování a plán pro chvíli, kdy se poskytovatel odmlčí. Tahle kapitola je shrnutí toho, co musíš mít, než to pustíš na lidi.

Prompty jsou kód

Zacházej s nimi tak:

• Do gitu, ne do databáze bez historie a ne nalepené v kódu na deseti místech.
• Verzuj je (v3) a u každé odpovědi si zapiš, která verze ji vygenerovala. Bez toho nevyšetříš stížnost na starou odpověď.
• Změnu prožeň testovací sadou, stejně jako bys pustil testy u kódu (evaluace).
• Nasazuj postupně: nejdřív na malé procento provozu, porovnej metriky, pak zbytek.

Připni si model

Když to poskytovatel umožňuje, používej konkrétní verzi modelu, ne alias typu „nejnovější“. Jinak se ti chování změní bez varování a ty budeš hledat chybu ve svém kódu.

Postup při upgradu:

1. nová verze do stagingu
2. projeď testovací sadu, porovnej s aktuální verzí
3. zkontroluj cenu a latenci (nová verze bývá jinde)
4. postupné nasazení + sledování metrik

Co měřit

Ke každému volání si loguj: verzi promptu, verzi modelu, tokeny, latenci, důvod ukončení a ID požadavku. Bez toho se incident vyšetřit nedá.

Odolnost

• Retry jen na dočasné chyby, s backoffem a jitterem.
• Fallback model: když hlavní neodpovídá, přepni na jiný (ideálně jiného poskytovatele).
• Cache: ušetří peníze a zároveň funguje jako záchrana při výpadku.
• Fronta pro dávkové úlohy, ať výpadek jen zdrží, nikoli ztratí práci.
• Circuit breaker: když poskytovatel padá, přestaň ho bombardovat a přepni na náhradní režim.

💡 Napiš si tenkou vrstvu nad poskytovatelem (jedno rozhraní, konfigurací se přepíná model i poskytovatel). Ušetří ti to týden práce ve chvíli, kdy budeš muset rychle přepnout.

Co dělat, když poskytovatel spadne

LLM API je externí závislost s dostupností, kterou neovlivníš, a s latencí, která kolísá mnohem víc než u běžného API. Počítej s tím v návrhu, ne až v incidentu.

Tři věci, které v tom schématu stojí za zdůraznění:

• Opakuj s exponenciálním odstupem a jitterem. Bez jitteru se ti všechny paralelní požadavky sejdou ve stejnou sekundu a poskytovatele dorazíš sám.
• Záložní model musí být otestovaný. Fallback, který jsi nikdy nespustil, je jen jiný způsob, jak spadnout. Prompty se mezi modely nechovají stejně.
• Degradovaný režim je součást produktu. Rozhodni dopředu, co uživatel uvidí: často je lepší vrátit výsledky vyhledávání bez shrnutí než točit spinner.

Timeout nastavuj podle p99, ne podle průměru, a u streamovaných odpovědí zvlášť hlídej čas do prvního tokenu. Uživatel pozná zaseknutou odpověď dřív než pomalou.

Postupné nasazení

Prompt se chová jako kód, ale nedá se otestovat jako kód, takže se nasazuje jako infrastruktura: opatrně a s možností couvnout.

1. Stínový provoz. Novou verzi pouštěj vedle staré na reálném provozu, výstup zahazuj a jen porovnávej. Odhalí to případy, které v testovací sadě nejsou.
2. Malý podíl provozu. Pusť na jednotky procent uživatelů a sleduj metriky.
3. Rozšiřuj postupně a měj připravené okamžité vrácení na předchozí verzi promptu.

K tomu patří jedna nepříjemná pravda: couvnout na starou verzi promptu nestačí, když poskytovatel mezitím změnil model. Proto se modely připínají na konkrétní verzi a proto si u každé odpovědi ukládáš, jaká verze promptu a jaký model ji vyrobily. Bez toho incident nevyšetříš.

Náklady pod kontrolou

• Tvrdý limit útraty u poskytovatele. Vždy.
• Rozpočet na uživatele a den ve své aplikaci.
• Alert na skokový nárůst spotřeby tokenů, obvykle znamená chybu ve smyčce nebo zneužití.
• Pravidelná revize promptů: co se do nich za tři měsíce nasypalo a už tam nemusí být?

Než to pustíš na lidi

• Prompty ve verzích, testovací sada projetá
• Model připnutý na konkrétní verzi
• Validace výstupu + opravná smyčka s limitem
• Limity: tokeny, kroky, rozpočet, rate limit na uživatele
• Fallbacky včetně předání člověku
• Logy (bez zbytečných osobních údajů) a metriky
• Ošetřená prompt injection u všeho, co jde zvenku
• Sepsané, co model nesmí rozhodovat sám

Cvičení

1. Poskytovatel tiše aktualizoval model a kvalita odpovědí klesla. Jak zjistíš, že se to stalo, a jak tomu předejdeš?
2. Co si musíš ukládat u každé odpovědi, abys byl schopen vyšetřit stížnost starou tři týdny?

Shrnutí

• Prompty patří do gitu, mají verze a testují se před nasazením.
• Připni verzi modelu a upgraduj řízeně přes testovací sadu.
• Měř latenci p95, cenu, chybovost validací a podíl fallbacků.
• Měj limity, náhradní cestu a jasně určené, co musí schválit člověk.