Jak orchestrovat jazykové modely: od jednoho promptu k systému

První AI funkce bývá jeden velký prompt. Napíšete do něj všechno, model to nějak zvládne a vy máte pocit, že to bylo snadné.

Druhá verze téhož promptu má tři sta řádků, obsahuje osm „DŮLEŽITÉ:" a pořád jednou za čas vrátí nesmysl. V tu chvíli obvykle přijde otázka, jestli nejde použít lepší model. Většinou ne. Problém není v modelu, ale v tom, že jedna úloha dělá pět věcí naráz.

První krok: rozbít úlohu

Vezměte si zpracování došlé faktury. V jednom promptu to vypadá takhle: „přečti fakturu, ověř dodavatele, zkontroluj částky, zařaď to do správné kategorie a napiš shrnutí".

Rozbité na kroky to vypadá jinak:

1. vytáhni z dokumentu pole (dodavatel, IČO, částka, datum, položky),
2. najdi dodavatele v naší databázi podle IČO — obyčejný SQL dotaz, žádný model,
3. ověř, jestli součet položek sedí s celkovou částkou — aritmetika, žádný model,
4. navrhni kategorii podle historie tohoto dodavatele,
5. když si něčím z toho nejsi jistý, pošli to člověku.

Najednou jsou z toho dvě volání modelu místo jednoho, ale každé má jeden jasný úkol. Krok dva a tři AI vůbec nepotřebují — a to je ta důležitější část. Model, který „ověřuje" součty, je nejdražší způsob, jak udělat chybu ve sčítání.

Jestli si máte z celého článku zapamatovat jednu větu: AI použijte tam, kde pravidla napsat neumíte. Všude jinde napište pravidla.

Řetězení a jeho cena

Když kroky poskládáte za sebe, výstup jednoho jde na vstup dalšího. Funguje to a má to dva háčky.

První: chyby se nesčítají, ale násobí. Devět kroků s devadesátiprocentní spolehlivostí nedává devadesát procent. Dává zhruba třicet osm. Proto se vyplatí mít kroků málo a po každém ověřit, jestli výstup vůbec dává smysl.

Druhý: latence. Každý krok je síťové volání, které trvá vteřiny. Pět kroků za sebou znamená, že uživatel čeká. Kroky, které na sobě nezávisí, spusťte paralelně — a to, co může běžet na pozadí, tam nechte běžet.

Routování: ne každá úloha potřebuje nejsilnější model

Modely se liší cenou i rychlostí, často řádově. Posílat klasifikaci „je tohle reklamace, nebo poptávka?" nejdražšímu modelu je jako jezdit na nákup kamionem.

Rozumné rozdělení vypadá zhruba takhle: jednoduché a objemné úlohy (klasifikace, extrakce, krátké shrnutí) na malý rychlý model. Úlohy, kde je potřeba uvažovat, spojit víc věcí nebo napsat kód, na silný model. A pro jistotu jedno pravidlo navíc: když si malý model není jistý, ať úlohu předá většímu.

Prakticky to znamená mít v kódu jedno místo, které rozhoduje, který model úlohu dostane. Ne deset míst, kde je název modelu natvrdo napsaný v promptu. To druhé vás dožene při první změně ceníku nebo při prvním novém modelu.

Ať model vrací data, ne prózu

Tohle je nejlevnější vylepšení, jaké můžete udělat. Chtějte strukturovaný výstup — JSON se schématem — místo věty, ze které pak regulárním výrazem lovíte číslo.

Důvod není estetika. Strukturovaný výstup se dá ověřit. Chybí pole? Zamítnuto. Částka není číslo? Zamítnuto. Kategorie není z povoleného seznamu? Zamítnuto. Najednou máte mezi modelem a databází bránu, která halucinaci zastaví dřív, než něco pokazí.

A když výstup neprojde, zkuste to znovu. Modely jsou nedeterministické — druhý pokus bývá často v pořádku.

Kde to nejčastěji padne

Pár věcí, které se v produkci ukážou vždycky a v demu nikdy:

• Externí API padají. Nastavte timeouty a mějte plán B. AI funkce, která shodí objednávkový proces, protože provider měl výpadek, je horší než žádná AI funkce.
• Náklady rostou potichu. Tři centy za volání jsou nic, dokud jich nemáte sto tisíc měsíčně. Měřte to od prvního dne.
• Prompt je vstup, ne kód. Když do promptu vkládáte text od uživatele nebo z e-mailu, počítejte s tím, že se vás někdo pokusí přesvědčit, ať ignorujete předchozí instrukce. Oddělujte instrukce od dat a nikdy nedávejte modelu pravomoc, kterou byste nedali cizímu člověku.
• Cachujte. Stejná otázka se opakuje častěji, než čekáte.

Kdy to celé nedělat

Když se dá úloha vyřešit podmínkou v kódu, vyřešte ji podmínkou v kódu. Je to levnější, rychlejší, testovatelné a nesplete se to.

Zní to jako samozřejmost, ale viděli jsme dost projektů, kde jazykový model rozhodoval o věcech, na které stačil if. Orchestrace není o tom, kolik modelů zapojíte. Je o tom, kolik z nich jste nezapojili, protože nebyly potřeba.