Tokenizer je část jazykového modelu nebo samostatný nástroj, který převádí text na menší jednotky zvané tokeny. Právě díky tokenizeru může model pracovat s běžným lidským textem, protože ho nejprve rozdělí na části a převede do číselné podoby, se kterou už dokáže počítat.

Na první pohled může tokenizer působit jako technický detail, který běžný uživatel nemusí řešit. Ve skutečnosti ale výrazně ovlivňuje to, jak velký jazykový model zpracuje prompt, kolik se mu toho vejde do kontextového okna, jak přesně dokáže pracovat s češtinou, kolik tokenů spotřebuje dlouhý dokument a proč se stejný text může u různých modelů počítat odlišně.

Co tokenizer v praxi skutečně dělá

Tokenizer řeší zdánlivě jednoduchou otázku: jak převést běžný text do podoby, se kterou může pracovat model?

Když člověk napíše větu, model ji nečte stejně jako člověk. Nepracuje přímo se slovy, větami ani významem v lidském smyslu. Nejprve musí text rozdělit na menší části. Těm se říká tokeny.

Token může být celé slovo, část slova, číslo, interpunkční znaménko, mezera nebo jiný úsek textu. Tokenizer tedy rozhoduje, jak se vstupní text rozpadne na tyto části.

Například krátké běžné slovo může být jeden token. Delší nebo méně obvyklé slovo se může rozdělit na více tokenů. URL adresa, HTML kód, JSON nebo tabulka mohou spotřebovat mnohem více tokenů, než by člověk podle počtu slov čekal.

Proč model nemůže pracovat přímo se slovy

Počítač neumí zpracovávat text tak, jak ho vnímá člověk. Model potřebuje číselná data. Tokenizer proto funguje jako převodní vrstva mezi lidským jazykem a matematickou reprezentací modelu.

Kdyby model pracoval jen s celými slovy, narazil by na problém. Jazyk obsahuje obrovské množství tvarů, nových výrazů, překlepů, odborných termínů, cizích slov, značek, URL adres a složených pojmů. Slovník všech možných slov by byl neprakticky velký a stále by v něm něco chybělo.

Kdyby model naopak pracoval jen s jednotlivými znaky, text by byl příliš dlouhý a zpracování méně efektivní.

Tokenizer proto často používá kompromis: text dělí na menší významově nebo statisticky užitečné části. Často jde o části slov, kterým se říká subword jednotky.

Tokenizer versus tokenizace

Pojmy tokenizer a tokenizace spolu úzce souvisejí, ale neznamenají totéž.

• Tokenizace je proces rozdělení textu na tokeny.
• Tokenizer je nástroj nebo součást systému, která tokenizaci provádí.

Jednoduše řečeno: tokenizace je činnost, tokenizer je mechanismus, který ji vykonává.

Příklad:

• uživatel napíše text,
• tokenizer ho rozdělí na tokeny,
• každému tokenu se přiřadí číselné ID,
• model s těmito čísly dál počítá,
• při generování odpovědi se výstupní tokeny zase převádějí zpět na text.

Jak tokenizer funguje krok za krokem

Tokenizer není část modelu, která by textu sama rozuměla jako člověk. Je to technická převodní vrstva. Jejím hlavním úkolem je vzít vstupní text, rozdělit ho na tokeny a převést je do podoby, se kterou už může pracovat samotný model.

Celý proces lze zjednodušeně popsat takto:

• 1. Text se nejprve načte jako vstup – uživatel napíše prompt, nahraje dokument nebo systém vloží do modelu text z jiné aplikace. Vstupem může být běžná věta, článek, e-mail, zdrojový kód, HTML, JSON, tabulka, výpis z databáze nebo třeba část dokumentace. V této fázi model ještě nepracuje s významem textu. Systém má zatím jen surový vstup, který je potřeba technicky připravit.
• 2. Tokenizer text rozdělí na menší části – tokenizer vezme vstupní text a rozdělí ho podle pravidel konkrétního modelu. Někdy může být jeden token celé krátké slovo, jindy jen část slova, číslo, interpunkce, mezera, symbol nebo část kódu. U moderních jazykových modelů se často používá takzvaná subword tokenizace. To znamená, že běžná slova mohou zůstat jako jeden token, zatímco delší, méně častá nebo nová slova se rozdělí na menší známé části.
• 3. Tokenizer nehledá význam, ale známé jednotky – v této fázi tokenizer slovu nepřiděluje významový rating ani nerozhoduje, jestli je slovo důležité. Jeho práce je techničtější. Porovnává text se svým slovníkem tokenů a hledá způsob, jak ho rozdělit na jednotky, které zná. Pokud celé slovo ve slovníku existuje, může z něj vzniknout jeden token. Pokud ne, tokenizer ho rozloží na menší části, které ve slovníku má.
• 4. Tokeny se převedou na číselná ID – každý token má ve slovníku modelu přiřazené své číselné ID. Model tedy nedostane přímo slovo „fotovoltaika“ nebo větu „Model odpoví na otázku“. Dostane posloupnost čísel, která odpovídají jednotlivým tokenům. Teprve s těmito čísly může dál pracovat neuronová síť.
• 5. Model tokeny převede na vnitřní reprezentace – číselné ID tokenu samo o sobě ještě nestačí. Model ho převede na vektorovou reprezentaci, tedy na soubor čísel, který zachycuje, jak se daný token chová v různých kontextech. Tady už se začíná řešit význam, vztahy mezi tokeny a jejich role ve větě. Samotný tokenizer tedy význam nevyhodnocuje – připraví vstup a samotný model potom zpracovává vztahy mezi tokeny.
• 6. Model sleduje kontext mezi tokeny – jazykový model nepracuje s každým tokenem izolovaně. Vyhodnocuje, jak token souvisí s ostatními tokeny ve vstupu. Právě zde vstupují do hry mechanismy jako attention, které pomáhají modelu určit, které části vstupu jsou pro danou odpověď důležité. Nejde o jednoduchý „rating slova“, ale o výpočet vztahů mezi tokeny v konkrétním kontextu.
• 7. Model generuje odpověď postupně po tokenech – když model odpovídá, nevytvoří celou větu najednou. Postupně odhaduje další token podle toho, jaké tokeny už má v kontextu a co už sám vygeneroval. U autoregresivních modelů se výstup skládá token po tokenu. Model tedy nejprve vytvoří první token odpovědi, potom další, potom další, dokud odpověď neskončí nebo nenarazí na nastavený limit.
• 8. Výstupní tokeny se převedou zpět na text – uživatel nechce vidět číselná ID tokenů ani interní reprezentace modelu. Proto se vygenerované tokeny na konci dekódují zpět do běžného textu. Výsledkem je odpověď, kterou člověk čte jako věty, odstavce, seznam nebo kód. Ve skutečnosti ale tato odpověď vznikla jako posloupnost tokenů, které byly postupně generované modelem.

Proč token není totéž co slovo

Nejčastější omyl je představa, že jeden token znamená jedno slovo. Někdy to přibližně platí, ale obecně ne.

Token může být:

• celé krátké slovo,
• část delšího slova,
• předpona nebo přípona,
• interpunkce,
• mezera nebo její součást,
• číslo nebo jeho část,
• emoji,
• část URL adresy,
• část kódu nebo značkovací syntaxe.

To je důležité hlavně při odhadu délky textu. Krátký odstavec v běžném jazyce může mít relativně málo tokenů. Ale odstavec plný čísel, URL adres, HTML značek, kódu nebo odborných výrazů může spotřebovat tokenů výrazně více.

Tokenizer a slovník modelu

Každý tokenizer pracuje se slovníkem. Slovník v tomto kontextu neznamená běžný jazykový slovník, ale seznam tokenů, které tokenizer zná.

Tento slovník může obsahovat celá slova, části slov, znaky, interpunkci nebo speciální tokeny. Speciální tokeny se mohou používat například pro označení začátku textu, konce textu, oddělení částí vstupu nebo jiných technických instrukcí.

Velikost a složení slovníku mají vliv na to, jak efektivně tokenizer pracuje s různými jazyky a typy textu.

Pokud tokenizer dobře pokrývá běžné výrazy daného jazyka, text se rozdělí úsporněji. Pokud jazyk nebo odborná oblast ve slovníku zastoupené nejsou dobře, stejný text se může rozpadnout na více menších tokenů.

Tokenizer a čeština

Čeština může být pro tokenizaci náročnější než angličtina. Má bohaté skloňování, časování, předpony, přípony, diakritiku a mnoho tvarů téhož slova. To znamená, že český text může v některých případech spotřebovat více tokenů než podobně dlouhý anglický text.

Například slova jako „nejpravděpodobnější“, „fotovoltaickými“, „zpracovatelnost“, „neobhospodařovatelný“ nebo „přesměrovávání“ se mohou rozdělit na více částí.

To neznamená, že model neumí česky. Znamená to, že tokenizer může český text dělit jinak a někdy méně úsporně než angličtinu.

Typy tokenizace

Existuje více způsobů, jak text rozdělit na tokeny. Každý má jiné výhody a limity.

Word-based tokenizace

Word-based tokenizace dělí text podle slov. Na první pohled je jednoduchá a srozumitelná. Problém je v tom, že vede k obrovskému slovníku a špatně si poradí s neznámými slovy, překlepy nebo tvary, které v datech nebyly.

Příklad:

• „pes“ může být samostatný token,
• „psovi“ může být jiný token,
• „psem“ opět jiný token,
• nový nebo neznámý tvar může být problém.

U jazyků s bohatým skloňováním je tento přístup méně praktický.

Character-based tokenizace

Character-based tokenizace dělí text po jednotlivých znacích. Výhodou je, že si poradí prakticky s jakýmkoliv textem. Nevýhodou je, že výsledná sekvence tokenů je velmi dlouhá a model se musí význam slov učit z mnohem drobnějších jednotek.

Tento přístup je flexibilní, ale pro velké jazykové modely často méně efektivní.

Subword tokenizace

Subword tokenizace dělí text na části slov. Je to kompromis mezi slovní a znakovou tokenizací. Častá slova mohou zůstat jako jeden token, méně častá nebo dlouhá slova se rozdělí na menší části.

Právě subword tokenizace je důležitá pro moderní NLP a velké jazykové modely. Umožňuje pracovat s velkým množstvím slovních tvarů, aniž by bylo nutné mít ve slovníku každé možné slovo.

BPE, WordPiece a Unigram

U moderních modelů se často mluví o algoritmech jako BPE, WordPiece nebo Unigram. Nejde o názvy modelů, ale o přístupy k tokenizaci.

BPE

BPE, tedy Byte Pair Encoding, postupně spojuje často se vyskytující dvojice znaků nebo částí textu. Díky tomu se učí vytvářet slovník tokenů podle toho, jaké kombinace se v trénovacích datech objevují často.

WordPiece

WordPiece je podobný přístup, ale při výběru částí slov pracuje s jiným kritériem. Používá se například u některých modelů z rodiny BERT. Jeho cílem je najít takové části slov, které dobře reprezentují text v daném trénovacím korpusu.

Unigram

Unigram pracuje s pravděpodobnostním výběrem tokenizace. Začíná s větším množstvím možných tokenů a postupně slovník zmenšuje podle toho, které jednotky jsou pro reprezentaci textu užitečné.

Pro běžného uživatele není nutné znát matematické detaily těchto algoritmů. Důležité je vědět, že různé modely mohou používat různé tokenizery, a proto se stejný text může rozdělit jinak.

Tokenizer a kontextové okno

Tokenizer přímo souvisí s kontextovým oknem modelu. Kontextové okno určuje, kolik tokenů může model zpracovat najednou. Do tohoto limitu se počítá prompt, historie konverzace, vložený kontext, systémové instrukce, dokumenty i odpověď modelu.

Proto není přesné říkat, že se modelu vejde určitý počet stran nebo slov. Správně se bavíme o počtu tokenů.

To je důležité například u:

• dlouhých článků,
• PDF dokumentů,
• technických specifikací,
• zdrojového kódu,
• HTML šablon,
• exportů z databáze,
• RAG systémů,
• dlouhých konverzací.

Pokud text spotřebuje příliš mnoho tokenů, nemusí se celý vejít do kontextu. Model pak musí pracovat jen s částí textu, nebo je potřeba použít chunking, retrieval či jiné zkrácení vstupu.

Tokenizer a cena AI služeb

U API služeb se používání modelů často účtuje podle počtu tokenů. Rozlišují se hlavně vstupní tokeny a výstupní tokeny.

• Vstupní tokeny jsou tokeny v promptu, dokumentech, historii konverzace nebo jiném kontextu.
• Výstupní tokeny jsou tokeny, které model vygeneruje jako odpověď.

Tokenizer tedy nepřímo ovlivňuje cenu. Když stejný text u jednoho modelu zabere více tokenů než u jiného, může to mít dopad na náklady, limity i rychlost odpovědi.

To je důležité hlavně u firemních aplikací, kde se model volá automaticky a často. Například zákaznický chatbot, AI nad dokumenty nebo interní asistent může denně zpracovat velké množství textu. I malé rozdíly v počtu tokenů se pak mohou projevit v ceně.

Tokenizer a dlouhé dokumenty

Při práci s dlouhými dokumenty tokenizer rozhoduje o tom, jak se dokument rozpadne na jednotky, které může model zpracovat. Pokud je dokument dlouhý, nestačí ho jednoduše vložit celý do promptu.

Často je potřeba:

• rozdělit dokument na menší části,
• zachovat logické celky,
• neoddělit nadpis od odstavce, který k němu patří,
• nepřerušit tabulku uprostřed,
• neposílat modelu zbytečný balast,
• použít retrieval pro nalezení relevantních pasáží.

Tokenizer sám o sobě neřeší význam dokumentu. Jen ho převádí na tokeny. O tom, které části dokumentu se mají použít, rozhoduje až další vrstva systému – například chunking, retrieval nebo aplikační logika.

Tokenizer a RAG

U RAG systémů je tokenizer důležitý hned několikrát. RAG, tedy Retrieval-Augmented Generation, pracuje tak, že systém nejprve najde relevantní části dokumentů a pak je předá modelu jako kontext.

Tokenizer zde ovlivňuje:

• kolik tokenů má dotaz uživatele,
• kolik tokenů mají nalezené pasáže,
• kolik kontextu lze modelu předat,
• kolik prostoru zbývá pro odpověď,
• jak drahé bude zpracování požadavku.

Špatně navržený RAG systém může modelu posílat příliš dlouhé a málo relevantní pasáže. Tím se spotřebují tokeny, odpověď se prodraží a zároveň může být horší. Dobře navržený RAG systém posílá jen ty části, které jsou pro dotaz skutečně důležité.

Tokenizer a embeddingy

Tokenizer souvisí i s embeddingy. Embedding je číselná reprezentace obsahu, která umožňuje porovnávat významovou podobnost textů, dokumentů nebo dotazů.

Než se text převede na embedding, musí se obvykle také projít určitou formou tokenizace nebo předzpracování. Model pak nepracuje s původním textem jako člověk, ale s jeho číselnou reprezentací.

To je důležité například u sémantického vyhledávání, kde systém nehledá jen přesná klíčová slova, ale významově podobné pasáže.

Tokenizer a zdrojový kód

Zdrojový kód se tokenizuje jinak než běžný text. Obsahuje závorky, odsazení, proměnné, operátory, speciální znaky, uvozovky, lomítka a často dlouhé řetězce.

Proto může krátký kus kódu spotřebovat více tokenů než běžný odstavec.

Tokenově náročné bývají například:

• HTML s mnoha atributy,
• JSON exporty,
• minifikovaný JavaScript,
• dlouhé SQL dotazy,
• logy,
• stack trace,
• konfigurační soubory,
• URL adresy s parametry.

Při práci s kódem proto dává smysl posílat modelu jen relevantní části, ne celé soubory nebo exporty bez výběru.

Tokenizer a speciální tokeny

Některé tokeny nejsou běžná slova ani části slov. Říká se jim speciální tokeny. Používají se k technickému označení určitých částí vstupu nebo výstupu.

Mohou označovat například:

• začátek textu,
• konec textu,
• oddělení částí vstupu,
• neznámý token,
• vyplnění kratších sekvencí,
• role v konverzaci,
• speciální instrukce modelu.

Běžný uživatel je většinou nevidí. Pro vývojáře a návrh modelů jsou ale důležité, protože pomáhají modelu pochopit strukturu vstupu.

Proč různé modely používají různé tokenizery

Různé modely mohou používat různé tokenizery, protože byly trénované na různých datech, pro různé účely a s různými technickými omezeními.

Tokenizer bývá úzce spojený s konkrétním modelem. Pokud model při trénování pracoval s určitým způsobem tokenizace, měl by se stejný nebo kompatibilní tokenizer používat i při jeho nasazení.

Jinak by model dostával vstupy v podobě, na kterou nebyl trénovaný. To by mohlo zhoršit kvalitu výsledků.

Co se stane, když tokenizer narazí na neznámý text

Moderní tokenizery se snaží minimalizovat problém neznámých slov. Díky subword tokenizaci nebo byte-level přístupům dokážou rozdělit i výraz, který jako celek ve slovníku neznají.

Příklad:

• model nemusí znát celé nové slovo,
• tokenizer ho rozdělí na menší části,
• model může s těmito částmi dál pracovat,
• výsledek nemusí být dokonalý, ale systém se nezastaví jen proto, že narazil na nový výraz.

To je důležité u značek, jmen, technických termínů, domén, nových produktů nebo překlepů.

Tokenizer a počítání tokenů

Počítání tokenů je praktická disciplína hlavně pro vývojáře a firmy. Nestačí vědět, kolik má text znaků nebo slov. Je potřeba vědět, kolik tokenů z něj udělá konkrétní tokenizer konkrétního modelu.

Token counting pomáhá zjistit:

• zda se vstup vejde do kontextového okna,
• kolik bude stát API požadavek,
• kolik prostoru zbývá pro odpověď,
• zda prompt není zbytečně dlouhý,
• zda retrieval neposílá modelu moc textu,
• zda je potřeba dokument rozdělit na části.

U produkčních AI aplikací je počítání tokenů důležité pro kontrolu nákladů, výkonu i stability systému.

Tokenizer a prompt engineering

Tokenizer je důležitý i pro prompt engineering. Když je prompt dlouhý, nepřehledný a plný opakování, spotřebuje mnoho tokenů a nemusí modelu pomoct.

Dobrý prompt by měl být dostatečně konkrétní, ale ne zbytečně nafouknutý.

Špatný prompt často obsahuje:

• opakující se instrukce,
• dlouhé nepodstatné pozadí,
• zbytečné příklady,
• celé dokumenty bez výběru relevantních částí,
• nejasný požadavek na výstup.

Lepší prompt obsahuje:

• jasný cíl,
• relevantní podklady,
• omezení,
• požadovaný formát výstupu,
• informaci, co model dělat nemá.

Smyslem není šetřit tokeny za každou cenu. Smyslem je nepálit je na textu, který modelu nepomáhá.

Tokenizer a multimodální modely

U multimodálních modelů se pojem token používá i mimo čistý text. Obrázky, audio, video nebo PDF dokumenty se také musí převést do interní reprezentace, se kterou model dokáže pracovat.

Neznamená to vždy stejný typ tokenu jako u textu. Prakticky ale platí, že i multimodální vstupy zabírají určitou část kapacity modelu a mohou se promítat do limitů i ceny.

Proto u modelů, které pracují s obrázky, soubory nebo videem, nestačí počítat jen slova. Je potřeba sledovat i to, jak poskytovatel počítá netextové vstupy.

Jak poznat dobrý tokenizer

Dobrý tokenizer není ten, který vždy vytvoří nejméně tokenů. Důležité je, aby text rozděloval tak, že s ním model dokáže dobře pracovat.

Dobrý tokenizer by měl:

• efektivně pracovat s běžným jazykem,
• zvládat méně častá slova,
• rozumně dělit dlouhé výrazy,
• neprodukovat zbytečně dlouhé sekvence,
• dobře pokrývat jazyky, pro které se model používá,
• umět pracovat s čísly, interpunkcí a speciálními znaky,
• být kompatibilní s modelem, pro který je určený.

U běžného uživatele není potřeba tokenizer vybírat ručně. U vývoje vlastních modelů nebo specializovaných NLP systémů je ale volba tokenizeru důležitá.

Časté chyby při chápání tokenizeru

Nejčastější chybou je představa, že tokenizer jen „rozseká text na slova“. Ve skutečnosti může text dělit mnohem jemněji a podle pravidel, která nejsou na první pohled intuitivní.

Další častou chybou je počítat délku promptu podle slov. U AI modelů rozhodují tokeny, ne slova. Proto se může stát, že text, který vypadá krátce, je pro model tokenově náročný.

Problém je také v tom, že lidé někdy předpokládají, že všechny modely tokenizují stejně. To neplatí. Stejný text může mít u různých modelů jiný počet tokenů.

Kde jsou limity tokenizeru

Tokenizer je nutná technická vrstva, ale sám o sobě nerozumí významu textu. Nerozhoduje, jestli je odpověď pravdivá, jestli je dokument relevantní nebo jestli model správně pochopil kontext.

Tokenizer jen připraví vstup pro model.

Jeho limity se projeví hlavně tehdy, když:

• jazyk není dobře pokrytý slovníkem,
• text obsahuje mnoho neobvyklých výrazů,
• vstup obsahuje velké množství kódu nebo symbolů,
• text je v málo zastoupeném jazyce,
• model používá tokenizer nevhodný pro danou doménu,
• se pracuje s velmi dlouhými dokumenty.

Proč má smysl tokenizeru rozumět i mimo vývoj

Tokenizer není pojem jen pro vývojáře modelů. Hodí se mu rozumět i při běžné práci s AI.

Pomáhá vysvětlit, proč:

• dlouhý dokument nejde vždy zpracovat celý najednou,
• český text může spotřebovat jiný počet tokenů než anglický,
• HTML, tabulky nebo kód rychle zaplní kontextové okno,
• AI API účtuje vstup i výstup podle tokenů,
• stejný prompt může být u různých modelů různě náročný,
• je někdy lepší poslat modelu kratší a přesnější kontext než obrovský blok textu.

Kdo chápe tokenizer, lépe chápe i praktické limity jazykových modelů. Nejde jen o to, „jak chytrý“ model je, ale také o to, jak se k němu text technicky dostane.

Kde jsou rizika a neznámé

Rizika a neznámé uvádíme kvůli transparentnosti – ukazují, kde má analýza limity a co může změnit závěry.

• Záměna tokenů za slova – uživatel může špatně odhadnout délku vstupu. Mitigace: u přesných výpočtů používat token counter pro konkrétní model.
• Různé tokenizery u různých modelů – stejný text se může rozdělit jinak. Mitigace: nepočítat univerzálně, ale podle dokumentace konkrétního poskytovatele.
• Horší efektivita u některých jazyků – méně zastoupené nebo morfologicky složitější jazyky mohou spotřebovat více tokenů. Mitigace: testovat reálné texty v daném jazyce.
• Tokenově náročné formáty – HTML, JSON, tabulky, kód a URL adresy mohou rychle zaplnit kontext. Mitigace: posílat jen relevantní části nebo data předem zjednodušit.
• Nevhodné dělení dlouhých dokumentů – pokud se text rozdělí špatně, může se ztratit kontext. Mitigace: kombinovat token counting s logickým chunkingem podle nadpisů a obsahu.
• Změny u poskytovatelů – tokenizace, limity i účtování se mohou měnit. Mitigace: pravidelně kontrolovat aktuální dokumentaci modelu a API.
• Přehnané šetření tokenů – příliš krátký prompt může vést k horším odpovědím. Mitigace: škrtat balast, ne důležité instrukce a relevantní kontext.
• Multimodální vstupy – obrázky, audio, video a soubory se mohou počítat jinak než text. Mitigace: u multimodálních modelů sledovat dokumentaci k token countingu a účtování zvlášť.

Související pojmy

• Token – základní jednotka textu nebo vstupu, se kterou jazykový model pracuje po tokenizaci.
• Tokenizace – proces rozdělení textu na tokeny.
• Velký jazykový model (LLM) – model, který zpracovává a generuje text na základě tokenů a jejich vztahů.
• Kontextové okno – maximální množství tokenů, které model dokáže zpracovat najednou.
• Vocabulary – slovník tokenů, které tokenizer používá. Tím se myslí seznam všech tokenů, které daný tokenizer zná a umí používat. U jazykových modelů totiž text obvykle nejde do modelu jako celá slova, ale nejdřív se rozloží na menší jednotky – tokeny.
• Embedding – číselná reprezentace obsahu, která umožňuje pracovat s významovou podobností textů nebo dokumentů.
• RAG – architektura, která kombinuje vyhledání relevantních informací s generováním odpovědi.
• Chunking – rozdělení většího dokumentu na menší části pro efektivnější práci s modelem.
• BPE – tokenizační algoritmus Byte Pair Encoding, který se používá pro dělení textu na časté části.
• WordPiece – subword tokenizační metoda známá například z modelů založených na BERT architektuře.
• SentencePiece – tokenizační přístup, který pracuje s textem jako se surovým vstupem a používá se u některých modelů pro vícejazyčné zpracování.
• Strojové učení – širší oblast AI, do které spadají modely učící se vzory z dat.
• Deep learning – podmnožina strojového učení založená na vícevrstvých neuronových sítích.

Odkazy a zdroje

• Tokenizer – OpenAI API – platform.openai.com – duben 2026 – interaktivní nástroj, ve kterém lze vložit vlastní text a vidět, jak se rozdělí na tokeny a jaký bude jejich celkový počet.
• What are tokens and how to count them? – help.openai.com – duben 2026 – článek vysvětluje, co OpenAI myslí tokenem, proč token není totéž co slovo a jak se tokeny promítají do vstupu, výstupu i ceny modelu.
• Counting tokens – OpenAI API – developers.openai.com – duben 2026 – dokumentace ukazuje, jak přesně počítat vstupní tokeny u požadavků pro OpenAI API, včetně textu, souborů, nástrojů a multimodálních vstupů.
• Understand and count tokens – Gemini API – ai.google.dev – březen 2026 – dokumentace popisuje, jak Gemini pracuje s tokeny, jaký je orientační vztah mezi tokeny, znaky a slovy a proč je token counting důležitý pro limity i náklady.
• Tokenizers – Hugging Face LLM Course – huggingface.co – duben 2026 – výuková část kurzu vysvětluje, co tokenizer dělá v NLP pipeline a proč musí text převést na číselná data, aby ho mohl model zpracovat.
• Summary of the tokenizers – huggingface.co – duben 2026 – přehled různých tokenizačních přístupů včetně subword tokenizace, Byte Pair Encoding, WordPiece, Unigram a SentencePiece.