Encoder, nebo LLM? Rozcestník klasifikace textu v roce 2026 (a co mi ukázalo 6 encoderů na jedné RTX 4060)

Skoro pokaždé, když dneska s někým řeším úlohu typu "roztřiď mi tyhle texty do kategorií" nebo "označkuj mi každý dokument podle pár vlastností", padne stejná věta: "no tak to hodíme na GPT nebo Clauda a je to". A ono to většinou i nějak funguje - demo za hodinu, prompt, JSON na výstupu, hotovo.

Problém je, že "nějak funguje" a "dává to smysl v produkci" jsou dvě různé věci. Když ten samý úkol pustíte přes malý encoder (model z rodiny BERT), který na klasifikaci přímo trénujete, dostanete typicky stejnou nebo lepší přesnost na stejném datovém rozpočtu, nižší latenci a řádově menší náklady (klidně 50x). A není to jen můj dojem. Natrénoval jsem si na jednom 8GB notebooku (obyčejná herní RTX 4060) šest encoderů proti generativnímu LLM a naměřil přesně tohle. Stejný výsledek má i čerstvý produkční výzkum, na který se dole odkazuju.

Tohle je rozcestník. Po přečtení budete vědět, kdy na text sáhnout po malém encoderu, kdy po malém generativním LLM, kdy po frontier modelu a kdy vůbec ne po modelu, ale po obyčejném pravidle. A hlavně proč - abyste to uměli obhájit před sebou i před dodavatelem.

Mýty okolo klasifikace textu

Než se pustím do přístupů, potřebuju odmáznout pár věcí, co slyším skoro na každé schůzce. Pět karet, klikněte na rozbalení.

Encoder vs generativní LLM v jedné minutě

Než se vrhneme do tabulek, jeden odstavec pro ty, kdo přicházejí čerstvě. Rozdíl mezi encoderem a generativním (decoder) modelem není velikost, ale jak čtou text.

Encoder (BERT, RoBERTa, ModernBERT, XLM-R) čte celý text najednou, oběma směry zároveň (proto "bidirectional"), a vytvoří z něj jedno bohaté číselné vyjádření významu. Na to nasadíte klasifikační hlavu, která "zaškrtne políčka". Jeden průchod, výstup je strukturálně omezený na povolené hodnoty. Model doslova nemůže vrátit jinou kategorii, než jaké jste ho naučili.

Decoder (GPT, Claude, Qwen, Llama) píše odpověď token po tokenu zleva doprava. Aby vám řekl "kategorie: debugging", musí to slovo po slově vygenerovat. To je skvělé, když má vzniknout volný text. Na zaškrtnutí formuláře je to zbytečná okružní jízda.

Přirovnání, které používám u klientů: encoder přečte dotazník a zaškrtne odpovědi. Decoder napíše k dotazníku slohovku. Když chcete zaškrtnutá políčka, encoder je rychlejší, levnější a míň se splete.

Tohle není detail - je to důvod, proč encoder na klasifikaci často poráží mnohonásobně větší LLM. A nezní to jako marketing menšího modelu, je to prostě vlastnost architektury: encoder-only modely jsou na klasifikaci a retrieval lepší než decodery stejné velikosti a často porazí i decoder o řád větší (mmBERT paper).

4 přístupy a kdy se který hodí

Tohle je jádro článku. Čtyři nástroje, každý s jiným sweet spotem. Nejsou to konkurenti "buď - anebo" - nejlepší produkční systémy je kombinují. Klikněte na kartu pro detail.

Nejlepší architektura tyhle čtyři nemíchá náhodně, ale rozděluje práci: frontier model (nebo subagenti) vyrobí data -> destiluje se do malého encoderu -> encoder jede v produkci na význam -> pravidla řeší to, co jde spolehlivěji kódem. Tohle rozdělení práce je nejdůležitější věc v celém článku - vrátím se k němu v Lekci 3.

Reálná čísla z RTX 4060

Teď to konkrétní. Postavil jsem si malý framework na fine-tuning malých modelů (0.5-3B) a na jedné RTX 4060 (8 GB VRAM) v Ubuntu ve WSL2 jsem si vyzkoušel to, o čem výš teoretizuju. Úloha: privacy-first prompt classifier, který z každého promptu vyrobí jen uzavřená metadata (kategorie, flagy, skóre) a obsah zahodí - abyste mohli vidět, jak lidé ve firmě pracují s AI, aniž byste jim četli prompty.

Metodická poznámka: deterministická pole (klasifikátor vs gold) jsem měřil přes macro-F1, ale generativní srovnání (kde neexistuje jedna správná odpověď) jsem hodnotil jako LLM-as-judge v Langfuse-kompatibilním setupu - silný model (Opus) oskóroval výstupy podle rubriky. Trasy a skóre tak jde poslat rovnou do Langfuse a porovnávat systémy vedle sebe.

Lekce 1: na mém datovém rozpočtu encoder LLM porazil (ale férově o tom mluvme)

Na stejné úloze (klasifikace promptu do ~15 uzavřených polí) a stejném rozpočtu 600-800 příkladů jsem porovnal encoder a generativní LLM:

Vypadá to jako 330x rychlejší a přesnější encoder. Ale buďme féroví, protože ten LLM baseline je zatížený hned třemi handicapy najednou:

1. Latence 7 248 ms je artefakt mého setupu, ne vlastnost LLM. Qwen3-1.7B generující krátký JSON přes obyčejné .generate() v Hugging Face, bez dávkování a bez servingu (vLLM/TGI), je patologicky pomalý. Fér naservírovaný přes vLLM s constrained decodingem by tenhle výstup zvládl v řádu nižších stovek ms. Reálný latenční rozdíl je tedy spíš 5-20x, ne 330x - a to "330x" z perexů a social postů beru zpět jako číslo, co nesnese fér srovnání.
2. QLoRA 4-bit je tady brzda, ne výhoda. 4-bit dequantizace na Ada GPU bývá pomalejší než fp16, takže "malý = rychlý" tady neplatí.
3. 0.44 F1 z velké části měří, že se generativní model z 600 příkladů nenaučil plnit 15-polní JSON (a rozbitý JSON padal jako chybná predikce). Encoder s klasifikační hlavou je na uzavřenou klasifikaci řádově sample-efficientnější. Takže korektní závěr je "na tomhle datovém rozpočtu vyhrál encoder", ne "LLM je na klasifikaci principiálně míň přesný".

Co obstojí i po férovém srovnání: na uzavřenou klasifikaci je encoder levnější, rychlejší a z málo dat se ji naučí líp. To "330x" ale beru zpět.

Lekce 2: syntetický test lže, realita se ukáže až na reálných datech

Na syntetickém test splitu měl encoder u citlivých polí micro-F1 0.95. Vypadalo to skvěle - jenže to číslo skoro nic neznamenalo. Credential je vzácná pozitivní třída a micro-F1 přes silně nevyvážená data je dominované negativní majoritou. 0.95 tedy měřilo hlavně "model správně říká, že tady heslo není" - což je většina případů. (Poučení pro každého: na vzácnou pozitivní třídu micro-F1 nepatří, chce to per-class recall a precision-recall pro tu pozitivní třídu.) Pak jsem model pustil na 57 reálných promptů ze session logů - a detekce "obsahuje credential" byla 0 z 57. Panika?

Ne. Když jsem se do toho zakousl:

1. Reálné prompty skoro nikdy neobsahují vložené tajemství. Vývojáři píšou "heslo je v .env", ne password=Tajne123. Zmínka není vložený secret. Takže "0 flagů" bylo z velké části správně - jen jsem měl špatně definovaný label. Po zpřesnění definice to sedělo.
2. Tam, kde tajemství reálně vložené je, je spolehlivější regex/entropy pravidlo než naučený model.

Ponaučení: evaluujte na reálných datech co nejdřív. Syntetický test měří, jak dobře model reprodukuje vaše vlastní syntetické vzory - ne jak obstojí v provozu.

Lekce 3: rozděl práci - encoder na význam, pravidla na zbytek

Z toho vzešel klíčový architektonický řez. Produkční klasifikátor má dvě vrstvy:

• Naučený encoder řeší sémantická pole (doména, typ úlohy, vyspělost uživatele, kvalita promptu, styl delegace).
• Deterministický skript (regex/pravidla) řeší, co jde spolehlivěji kódem (vložené secrets/PII a rozlišení inline vs. zmínka, tech stack, použití gitu, odkazy na soubory).

Pravidlo na credential je 100% transparentní a nikdy "nezapomene", model se soustředí na to, v čem je nenahraditelný - význam.

Lekce 4: vyspělost a "množství práce" se NEsoudí z jednoho promptu

Nejzajímavější moment. Krátký follow-up "hoď to do MR" vypadá v izolaci jako triviální příkaz od nováčka - dvě slova, žádná práce. Ale v kontextu té konverzace byl výstupem sofistikovaného agentického plánu se subagenty a testy, a udělat z toho merge request byl poslední krok velkého úkolu, ne malá věc. Encoder, který kontext dostal, dal správně vysokou vyspělost i velké "množství práce". LLM, který kontext podhodnotil, dal skóre nováčka. Chyboval model, který kontext ignoroval - ne ten, co ho použil.

Potvrzuje to i výzkum: Anthropic v analýze zhruba 400 000 Claude Code sessions (říjen 2025 - duben 2026, cca 235 000 lidí) ukazuje, že signál nese session, ne jednotlivý prompt. Vyspělost a odvedenou práci je potřeba agregovat přes session a uživatele (s robustní statistikou - medián, trimmed mean), ne soudit z jedné krátké zprávy. Mimochodem ze stejné studie: lidé si drží 70 % plánovacích rozhodnutí, model dělá 80 % exekuce - další argument, proč "kolik práce" číst z celé session, ne z jedné hlášky.

A samotné "množství práce"? Výzkum odhadu effortu z textu je jednoznačný: absolutní odhad sotva porazí medián (i frontier LLM zero-shot jen kolem Spearman 0.4). Proto jsem work_weight udělal jako relativní ordinální škálu 0-10, ne přesné číslo. A vypadá to, že to jde: na mém malém test setu se model trefil s MAE kolem 0.6 na škále 0-10, tedy v průměru do necelého bodu. Bez pořádného confidence intervalu na 59 vzorcích to ale berte jako orientační signál, ne jako změřenou vlastnost.

Lekce 5: srovnal jsem 6 encoderů, dva selhaly. To je taky výsledek.

Abych měl obhajitelný benchmark, natrénoval jsem na stejných datech 6 encoderů napříč 4 architekturami a 3 velikostmi (plus monolingvní kontrast). Pozor na jednu věc: tahle tabulka měří mean per-pole accuracy, kdežto Lekce 1 měřila macro-F1 - jsou to dvě různé metriky, proto u mmBERT-base vidíte jednou 0.58 a podruhé 0.681. Neporovnávejte je napřímo.

Co z toho plyne:

• Rozdíl mezi nejlepšími je v šumu (59 vzorků, jeden tréninkový běh, jeden seed). XLM-R, mmBERT a mmBERT-small jsou prakticky na roví - a protože jsem netrénoval přes víc seedů, i to pořadí berte jako orientační. Kdo na 60 vzorcích tvrdí "X je jasně nejlepší", přehání.
• RobeCzech (jednojazyčný český) skončil níž než multilingvní modely. Nechci na tak malém vzorku přeceňovat konkrétní čísla, ale směr sedí s tím, co čekáte a priori: na dvojjazyčná data (cs+en) patří multilingvní model (mmBERT, XLM-R), ne monolingvní.
• mDeBERTa-v3 je na benchmarcích per-param přeborník - a to, že u mě skončila na 0.42, není chyba modelu, ale moje. DeBERTa-v3 má známou nestabilitu v fp16 (disentangled attention přetéká), chce bf16 nebo fp32, a RTX 4060 bf16 nativně umí. Nedoladil jsem to. Nechávám to v tabulce jako připomínku, že "model selhal" často znamená "nenakonfiguroval jsem ho správně".
• gte-multilingual spadl na CUDA assert v custom kódu přes trust_remote_code - zase spíš problém mého pipeline než kvality modelu.

Poctivě zdokumentovaný neúspěch (i když je to můj vlastní) je pro důvěryhodnost cennější než vyleštěná tabulka jen s vítězi.

Lekce 6: běží to na CPU, a rychle. Ale pozor na počet vláken.

Klíčová výhoda encoderu: nepotřebuje GPU. Na CPU:

Léčka, na kterou jsem sám naletěl: s 22 vlákny to bylo ~1 200 ms, tedy dramaticky pomalejší, kdežto s 8 vlákny je to 44 ms. Na malých tenzorech (jeden krátký prompt) totiž režie koordinace vláken přebije samotný výpočet - řeší se to nastavením torch.set_num_threads / OMP_NUM_THREADS na počet fyzických jader, ne logických. Malé modely chtějí málo vláken. S ONNX + INT8 kvantizací se to typicky srazí ještě 2-4x dolů (~20 ms, ~300 MB RAM).

Nejsem v tom sám: co říká literatura

Aby to nevypadalo, že jsem si šest encoderů natrénoval a vytáhl z toho, co se mi hodí - stejný závěr má i čerstvý produkční výzkum. Studie Cost-Aware Model Selection for Text Classification (2026) porovnala fine-tuned encodery proti LLM promptingu na čtyřech klasifikačních datasetech a došla k tomuhle:

• Přesnost: encodery přesnost LLM dorovnaly nebo překonaly. RoBERTa na AG News (4 třídy) měla 94.63 % F1 vs. 91.35 % u Claude zero-shot. Na binárním sentimentu byl rozdíl v desetinách bodu.
• Latence: LLM byl 5-14x pomalejší (encoder p50 pod 700 ms, LLM konzistentně přes 1 s, p95 až 2-5 s).
• Cena: encoder byl 25-400x levnější na milion požadavků. Few-shot prompting cenu zvedl o 50-300 % za minimální zisk přesnosti - autoři to nazvali "nevýhodná výměna cena/přesnost".
• Verdikt: DistilBERT skončil #1 v jejich utility funkci (přesnost / cena / latence) napříč všemi datasety, s hodnotou 50-250x vyšší než LLM.

Jinými slovy: co jsem viděl na 59 vzorcích na notebooku, sedí s tím, co jiní naměřili na pořádných datasetech. Encoder je na uzavřenou klasifikaci robustní a levný rozhodovací engine, LLM je do téhle role dražší, pomalejší náhrada. Když vám tedy někdo prodává "LLM klasifikátor" za API peníze na úloze s pevnou sadou kategorií, neplatíte za přesnost. Platíte za pohodlí toho, kdo to staví.

A že by encodery byly zastaralé? ModernBERT přinesl 8K kontext, rotary embeddings a střídání lokální/globální attention, mmBERT to rozšířil na 1800+ jazyků a na MTEB v2 se dotahuje na ModernBERT. Rodina, kterou lidé odepisují, je aktivně jedna z nejlepších voleb roku 2026.

Kvíz: encoder, malý LLM, nebo frontier?

Začněte u úlohy, ne u technologie. Dvě až tři otázky a dostanete konkrétní doporučení.

Rozhodovací rámec: kdy co

Rychlá tabulka na závěr. Klikněte na řádek a skočíte na příslušnou sekci.

Co se v dalších měsících bude měnit

Pár věcí, které mám v hledáčku:

• Constrained decoding jako default. "LLM vrací rozbitý JSON" mizí jako argument. Validita výstupu přestává být rozdíl mezi encoderem a LLM - zůstává cena a latence.
• Malé generativní modely dorovnávají. Pod-3B segment na úrovni GPT-3.5 na 16GB grafice je novinka roku 2026. Hranice, kdy sáhnout po malém LLM místo frontieru, se posouvá dolů.
• ModernBERT deriváty všude. Doménové a jazykové varianty (clinical, japonský, multilingvní mmBERT) ukazují, že moderní encoder je platforma, ne jeden model.
• Moje produkční verze. Tenhle článek stojí na testech na jednom notebooku. Teď to stavím do produkce s řádově víc daty - o výsledcích a o tom, co se změní na větším měřítku, napíšu zvlášť.

Závěr

Tři věci, které si odneste:

1. Na uzavřenou klasifikaci sáhněte po encoderu, ne po LLM. Levnější (desítky až stovky x), rychlejší, a z málo dat se klasifikaci naučí líp. Můj notebook i produkční literatura říkají to samé.
2. Rozdělte práci. Frontier model (nebo subagenti) vyrobí data -> destiluje se do encoderu -> encoder jede na význam -> pravidla řeší, co jde spolehlivěji kódem. Nesnažte se jedním nástrojem vyřešit všechno.
3. Evaluujte na reálných datech brzy a agregujte správně. Syntetický test lže. Vyspělost a množství práce čtěte ze session, ne z jedné hlášky.

Většina lidí dneska sáhne po LLM ze zvyku, ne z rozhodnutí. Přitom nejlevnější a nejrychlejší nástroj na "roztřiď mi tenhle text do pevných kategorií" je 10-100x menší encoder, který doběhne na notebooku za 20 milisekund a z pár set příkladů se to naučí líp než generativní model. LLM není špatná volba - je to jen zřídkakdy ta správná na tuhle konkrétní úlohu.

A bonusově: velký kus téhle práce (generování dat, evaly, rešerše, srovnání) oddřeli subagenti v Claude Code. Malý tým + frontier model jako škálovatelný "junior" = reálná produkční pipeline na jednom notebooku.

Pokud vás zajímá vektorová strana téhle mince (embeddingy, reranking, RAG), mám k tomu samostatný rozcestník: Vyhledávání pomocí vektorů v roce 2026. Najdete mě na LinkedIn nebo na emailu.