Jak vybrat jazykový model pro firemního AI agenta

Otázka „jaký model použijeme" přijde v projektu s AI agentem obvykle už v prvním týdnu — a téměř vždy dostane víc pozornosti, než si zaslouží. Rozhoduje se podle toho, co bylo naposledy vidět v médiích, případně podle tabulky veřejných benchmarků, která s vaší agendou nemá společného téměř nic. V reálném provozu přitom o úspěchu rozhodují úplně jiné věci: jestli model spolehlivě volá nástroje, jestli zvládá odbornou češtinu, kolik stojí při desetitisících běhů měsíčně a jestli ho za půl roku dokážete vyměnit bez přepisování systému.

Dobrá zpráva je, že výběr jazykového modelu patří mezi snáze vratná rozhodnutí — pokud ho od začátku berete jako výběr komponenty, ne jako výběr platformy. Špatná zpráva je, že většina týmů si tu vratnost zabetonuje v prvních dvou sprintech: prompty psané na styl jednoho modelu, formát nástrojů navázaný na jedno SDK, žádná evaluační sada. Tento článek je o kritériích, která skutečně rozhodují, o rozdílu mezi hostovaným API a vlastním nasazením a o tom, jak výběr ověřit na vlastních datech. Záměrně v něm nenajdete konkrétní názvy modelů ani ceny — ty se mění rychleji, než stihnete článek dočíst. Kritéria vydrží.

Pokud si máte z celého textu odnést jednu věc, tak tuhle: model nevybíráte „obecně", vybíráte ho pro konkrétní krok konkrétního procesu. Agent, který řeší firemní úlohy, má uvnitř typicky pět až patnáct různých kroků a každý má jiný profil nároků.

Typ úlohy

Klasifikace příchozího e-mailu do jedné z osmi kategorií a napsání právně citlivé odpovědi zákazníkovi jsou dvě naprosto odlišné úlohy. První potřebuje konzistenci a rychlost, druhá jazykový cit a schopnost pracovat s nuancí. Rozdělte si proces na kroky a ke každému si napište, jestli jde o třídění, extrakci, sumarizaci, generování textu nebo plánování posloupnosti akcí. Teprve pak vybírejte.

Kontextové okno a jak s ním nakládáte

Velké kontextové okno je pohodlné, ale není náhrada za dobrý výběr dat. Pokud agentovi do každého běhu nasypete celou interní směrnici, zaplatíte za to latencí i cenou a kvalita odpovědi se často zhorší — relevantní věta se ztratí mezi tisíci nerelevantních. V praxi je levnější a přesnější postavit pořádné vyhledávání nad dokumenty, tedy RAG nad firemní dokumentací, a modelu podat jen to podstatné. Velký kontext berte jako pojistku pro výjimečné případy, ne jako výchozí režim.

Latence

Latence se neměří v milisekundách, ale v tom, jak působí na uživatele. Agent v chatu na webu musí začít odpovídat do sekundy, jinak návštěvník odchází. Agent, který v noci zpracuje 4 000 dokumentů, může mít odezvu i deset sekund na kus a nikomu to nevadí. U vícekrokových agentů se navíc latence sčítá: pět volání po dvou sekundách je deset sekund čekání.

Cena při reálném objemu

Cena za jedno volání je zavádějící údaj. Zajímavá je cena za dokončenou úlohu — včetně opakovaných pokusů, volání nástrojů, případných oprav a kontrolního kroku. Model, který je na jednotku dražší, ale dokončí úlohu napoprvé, bývá v součtu levnější než levný model, který se potřebuje třikrát opravit. Přesně tohle je jeden z faktorů, které ovlivňují cenu a náročnost AI agenta na míru.

Spolehlivost volání nástrojů

Toto kritérium podceňuje téměř každý, kdo model vybírá podle benchmarků. Firemní agent obvykle nic „neví" sám — čte z CRM, zapisuje do ERP, zakládá tikety. Klíčové je, jestli model konzistentně trefí správný nástroj, dodrží schéma parametrů, nevymyslí si pole, které neexistuje, a umí se zastavit, když mu chybí vstup. Rozdíly mezi modely jsou tady větší a praktičtější než rozdíly v „inteligenci".

Kvalita češtiny a slovenštiny

Modely, které působí výborně v angličtině, dokážou v češtině tvořit neobratné věty, chybně skloňovat jména nebo míchat slovakismy. Pokud agent píše zákazníkům nebo generuje texty pro interní dokumenty, otestujte to na reálných vzorcích — včetně odborného slovníku vašeho oboru, který bývá nejslabším místem.

Druhé velké rozhodnutí není o kvalitě, ale o tom, kde končí vaše data a kolik provozu si berete na sebe. Modely s otevřenými váhami dnes zvládnou většinu běžných firemních úloh; otázka je, jestli je chcete provozovat.

Rozhodování je jednodušší, než se zdá. Pokud zpracováváte běžnou firemní agendu a poskytovatel umí garantovat zpracování v EU a nepoužívání vašich dat k trénování, hostované API je pro většinu firem rozumná volba — pravidla a povinnosti jsme rozepsali v textu o tom, na co si dát pozor u AI agentů a GDPR. Vlastní nasazení dává smysl ve třech situacích: máte regulatorní nebo interní požadavek, který třetí stranu nepřipouští; máte takový objem, že fixní náklady na infrastrukturu vyjdou lépe; nebo potřebujete model doladit na vlastních datech způsobem, který hostovaná služba nenabízí.

Typický první návrh vypadá tak, že celý agent běží na nejsilnějším dostupném modelu. Funguje to a na demo je to nejrychlejší cesta. Při přechodu do provozu se ukáže, že 80 % volání jsou triviální kroky — rozhodnutí, do které větve proces pokračuje, extrakce tří polí z formuláře, kontrola, jestli přišla odpověď zákazníka — a na ty platíte prémiovou sazbu i prémiovou latenci.

Praktičtější vzor je odstupňování. Levný a rychlý model dělá směrování, klasifikaci a jednoduché extrakce. Silný model nastupuje jen na kroky, kde se opravdu uvažuje: syntéza z více zdrojů, formulace citlivé odpovědi, plánování posloupnosti akcí. Mezi nimi stojí explicitní rozhodovací pravidlo, ne náhoda.

Větší model není strategie. Strategie je vědět, které kroky si ho zaslouží.

Tento přístup má i vedlejší efekt: nutí vás proces pořádně rozepsat. Když umíte pojmenovat, který krok je „těžký" a proč, obvykle zjistíte, že polovina těžkých kroků jde zjednodušit lepším promptem nebo lepším nástrojem. A pokud se vám kroky začnou přirozeně dělit do více rolí, stojí za zvážení i to, jestli nejde o případ pro multiagentní systém místo jednoho agenta.

Trh se mění v měsících. Model, který je dnes nejlepší poměr ceny a kvality pro vaši úlohu, jím za dva kvartály být nemusí. Proto je důležitější než samotný výběr to, aby výměna byla levná.

V praxi to znamená čtyři věci. Za prvé, volání modelu má být za vlastní vrstvou abstrakce — jedno místo v kódu, kde se mění dodavatel, ne stovky míst. Za druhé, definice nástrojů si držte ve vlastním formátu a mapujte je na formát konkrétního poskytovatele až na hranici. Za třetí, prompty pište spíš strukturovaně a explicitně než „vyladěné na zvláštnosti jednoho modelu" — čím víc triků, tím bolestivější migrace. A za čtvrté, mějte evaluační sadu, kterou nového kandidáta proženete za jedno odpoledne.

Tak stavíme AI agenty a automatizace i my: model je konfigurace, ne základ architektury.

Veřejné benchmarky měří něco jiného, než potřebujete vy. Měří průměr napříč úlohami, které jsou většinou anglické, akademické a nezávislé na vašich systémech. Vaše otázka zní jinak: zvládne tenhle model třídit naše reklamace a volat naše API?

Postup, který se osvědčil, je nenáročný a dá se zvládnout za pár dní:

1. Posbírejte 50 až 200 reálných případů z produkce nebo archivu. Vyberte je tak, aby odpovídaly rozložení běžného provozu, a přidejte ty nepříjemné — nejasná zadání, překlepy, přílohy ve špatném formátu.
2. Definujte, co je správná odpověď. U klasifikace je to jednoduché. U generování textu potřebujete kritéria, která posoudí člověk, nebo alespoň kontrolní seznam typu „obsahuje číslo objednávky, neuvádí cenu, oslovuje formálně".
3. Pouštějte kandidáty přes stejný prompt a stejné nástroje. Měňte jen model, nic jiného, jinak nevíte, co rozdíl způsobilo.
4. Vyhodnoťte tři věci najednou: kvalitu, cenu za dokončenou úlohu a procento běhů, kde model porušil schéma nástroje nebo se zacyklil.
5. Otestujte i to, co se má stát při neúspěchu. Model, který řekne „na tohle nemám podklad", je v podpoře užitečnější než model, který sebevědomě vymyslí odpověď.

Kdy tento postup nedává smysl

Pokud řešíte jednorázovou interní pomůcku pro pět lidí, budování evaluační sady je zbytečná režie — vezměte rozumný model, otestujte to ručně a hotovo. Formální evaluace se vyplatí až tam, kde agent běží v objemu, dotýká se zákazníka nebo peněz, nebo kde chyba něco stojí.

Výběr jazykového modelu pro firemního AI agenta není otázka „který je nejlepší", ale „který je dost dobrý na tenhle konkrétní krok při této ceně a latenci". Rozepište proces na kroky, posuďte typ úlohy, práci s kontextem, latenci, cenu za dokončenou úlohu, spolehlivost volání nástrojů a kvalitu češtiny. Mezi hostovaným API a vlastním nasazením rozhodujte podle regulace a objemu, ne podle pocitu. Nedávejte nejsilnější model na všechno — odstupňujte. A hlavně: postavte systém tak, aby výměna modelu byla konfigurační změna, protože za rok ji téměř jistě dělat budete.

Pokud zvažujete nasazení agenta a chcete si výběr modelu ověřit na vlastních datech ještě před vývojem, ozvěte se nám a projdeme si váš případ.