Jak si vybrat jazykový model a uhlídat náklady

První otázka, která padne, bývá „který model je nejlepší?". Je to pochopitelné a je to slepá ulička. Neexistuje nejlepší model, existuje nejlevnější model, který ještě zvládne vaši úlohu.

Proč benchmarky nepomůžou

Tabulky s procenty vypadají přesvědčivě a rozhodovat se podle nich je omyl.

Zaprvé, testují něco jiného, než vy potřebujete. Že model řeší matematické olympiády vám neřekne nic o tom, jestli vytáhne správné IČO z rozmazané faktury.

Zadruhé, rozdíly na vrcholu jsou malé a mění se každé dva měsíce. Model, který byl v březnu nejlepší, je v květnu třetí a v červenci má poloviční cenu. Postavit rozhodnutí na dnešním pořadí znamená předělávat ho každý kvartál.

Jediný benchmark, který má cenu, je váš vlastní: vezměte padesát reálných případů z vaší firmy, přežeňte je přes tři modely a porovnejte výsledky. Zabere to jedno odpoledne a řekne vám to víc než všechny tabulky dohromady.

Co doopravdy rozhoduje

Podle našeho pořadí důležitosti:

• Zvládne to vůbec? Otestujte na svých datech. Když ano i u malého modelu, je diskuse u konce — vezměte malý.
• Jak rychle? Když čeká uživatel, dvě vteřiny jsou něco jiného než dvacet. Když běží dávka v noci, je to jedno.
• Kolik to bude stát při reálném objemu? Ne u dema. Vynásobte to skutečným počtem volání za měsíc.
• Kam jdou data? U citlivých údajů to může rozhodnout za vás dřív než cokoliv jiného.
• Dá se vyměnit? Tohle je nejdůležitější položka na seznamu.

Vyměnitelnost je důležitější než výběr

Trh se mění příliš rychle na to, abyste se zavazovali.

Prakticky to znamená jednu věc: v kódu mějte tenkou vrstvu, přes kterou jdou všechna volání. Ne SDK jednoho providera roztroušené po dvaceti souborech. Když za půl roku přijde model, který je dvakrát levnější, chcete měnit jeden soubor, ne dvacet.

Stejná vrstva vám mimochodem vyřeší i retry, timeout, měření nákladů a fallback na jiného providera, když ten první spadne. Vyplatí se ji napsat hned, dokud je to hodina práce.

Kde vznikají náklady

Platíte za tokeny na vstupu i na výstupu, přičemž výstupní bývají výrazně dražší. To má přímé důsledky:

Dlouhá konverzace je drahá exponenciálně. Model si nic nepamatuje, takže při každém dalším volání posíláte celou historii znovu. Desátá otázka v chatu stojí několikanásobně víc než první — ne proto, že by byla složitější, ale proto, že se s ní posílá devět předchozích.

Systémový prompt se posílá pokaždé. Ty dvě strany instrukcí, na které jste hrdí, platíte při každém jednom volání.

„Vysvětli svůj postup" není zadarmo. Když necháte model uvažovat nahlas, platíte za každé slovo té úvahy.

Co s tím reálně funguje

Seřazeno podle poměru efektu k námaze:

1. Cachujte odpovědi. Nudné a nejúčinnější. Stejné otázky se opakují víc, než si myslíte. Odpověď, kterou vrátíte z cache, stojí nula.
2. Routujte na menší model. Klasifikace a extrakce nepotřebují vlajkovou loď. Rozdíl bývá řádový.
3. Používejte prompt caching. Provideři umí zlevnit opakující se část promptu — dejte stabilní instrukce na začátek a měnící se data na konec.
4. Zkraťte, co posíláte. Neposílejte celý dokument, když stačí tři odstavce. Tohle je mimochodem přesně to, co řeší RAG.
5. Ořežte historii. Starší části konverzace shrňte místo toho, abyste je posílali doslova.
6. Dávkujte, co nespěchá. Provideři mají levnější režim pro úlohy, které můžou počkat.

Měřte to od prvního dne

Tohle je jediná věc z celého článku, kterou když uděláte, zbytek si najdete sami.

Logujte u každého volání: který model, kolik tokenů dovnitř, kolik ven, jak dlouho to trvalo, které funkce se to týkalo. Bez toho nevíte, jestli vás zabíjí jedna funkce, nebo tisíc malých, a optimalizovat budete naslepo.

A nastavte si strop. Nekonečná smyčka v agentovi nebo špatně napsaný cyklus dokáže utratit měsíční rozpočet za noc. Není to hypotetické, stalo se to dost firmám na to, aby to provideři řešili vlastními limity.