Token je základní jednotka textu nebo jiného vstupu, se kterou pracuje jazykový model. Nejde přesně o slovo, větu ani znak. Token může být celé krátké slovo, část delšího slova, interpunkční znaménko, mezera, číslo, symbol nebo jiný úsek textu podle toho, jak konkrétní model text rozděluje.

Na první pohled může token působit jako drobný technický detail. Ve skutečnosti jde o jeden z nejdůležitějších pojmů u umělé inteligence. Tokeny určují, kolik textu se modelu vejde do kontextového okna, kolik bude stát zpracování dotazu v API, jak dlouhou odpověď může model vytvořit a proč se stejný text v různých jazycích může počítat odlišně.

Co token v praxi skutečně znamená

Když člověk čte větu, přirozeně ji vnímá jako slova a význam. Jazykový model ji ale před zpracováním nejprve rozdělí na menší části. Těmto částem se říká tokeny.

Například krátká věta může mít jen několik tokenů. Delší technický text, kód, tabulka, URL adresa nebo text s neobvyklými výrazy může mít tokenů výrazně více. Tokeny tedy nejsou totéž co slova. Jedno slovo může být jeden token, ale také dva, tři nebo více tokenů.

Typicky platí:

• krátká běžná slova mohou být jeden token,
• delší slova se mohou rozdělit na více tokenů,
• interpunkce se může počítat jako samostatný token,
• mezery mohou být součástí tokenizace,
• čísla se mohou dělit jinak než běžná slova,
• kód, URL adresy nebo neobvyklé výrazy mohou spotřebovat více tokenů, než by člověk čekal.

Právě proto se u AI nepočítá jen počet slov nebo počet znaků, ale počet tokenů.

Proč token není totéž co slovo

Častá chyba je představit si token jako jedno slovo. Někdy to tak přibližně vyjde, ale není to pravidlo.

Jednoduché slovo může být jeden token. Delší nebo méně obvyklé slovo se ale může rozdělit na více částí. Model totiž nepracuje s lidským slovníkem, ale s vlastním systémem rozdělování textu, kterému se říká tokenizer.

Příklad zjednodušeně:

• slovo „pes“ může být jeden token,
• slovo „fotovoltaika“ může být jeden nebo více tokenů podle konkrétního tokenizeru,
• výraz „nejneobhospodařovávatelnější“ se pravděpodobně rozdělí na více částí,
• adresa „https://www.example.com/produkt?id=123“ může zabrat mnohem více tokenů než běžná krátká věta.

To je důležité hlavně u dlouhých dokumentů, promptů, tabulek, zdrojového kódu a API požadavků.

Co je tokenizace

Tokenizace je proces, při kterém se vstupní text rozdělí na tokeny. Než model začne odpovídat, musí se text převést do podoby, se kterou dokáže pracovat výpočetně.

Člověk vidí větu:

„Model odpoví na otázku.“

Model ji nejprve rozdělí na menší jednotky. Ty se potom převedou na číselné reprezentace, protože model ve skutečnosti nepracuje přímo se slovy, ale s čísly.

Tokenizace tedy funguje jako překladová vrstva mezi lidským textem a matematickým světem modelu.

Co je tokenizer

Tokenizer je nástroj nebo část systému, která rozhoduje, jak se text rozdělí na tokeny. Každý model nebo rodina modelů může používat trochu jiný tokenizer. Proto se stejný text může u různých modelů rozdělit odlišně a mít jiný počet tokenů.

Tokenizer řeší například:

• kde se text rozdělí,
• zda se slovo ponechá celé,
• zda se delší slovo rozdělí na části,
• jak se započítají mezery a interpunkce,
• jak se zpracují čísla, emoji, URL adresy, kód nebo znaky mimo běžnou abecedu.

Proto nelze univerzálně říct, že jeden token je vždy jedno slovo nebo přesný počet znaků. Vždy záleží na konkrétním modelu a tokenizeru.

Proč modely vůbec používají tokeny

Modely potřebují text převést do podoby, nad kterou lze počítat. Počítač nepracuje s významem slov tak, jak ho chápe člověk. Potřebuje číselné reprezentace.

Tokeny jsou praktický kompromis. Kdyby model pracoval pouze s jednotlivými znaky, text by byl velmi dlouhý a méně efektivní. Kdyby pracoval pouze s celými slovy, měl by problém s neznámými slovy, různými tvary, překlepy, novými názvy nebo složenými výrazy.

Tokenizace proto často používá části slov. Díky tomu může model pracovat s běžnými slovy efektivně a zároveň si poradit i s méně obvyklými výrazy.

Token a kontextové okno

Tokeny jsou zásadní pro pochopení kontextového okna. Kontextové okno určuje, kolik tokenů může model zpracovat najednou. Do tohoto limitu se počítá vstup od uživatele, systémové instrukce, přiložený kontext, historie konverzace i odpověď, kterou model generuje.

Pokud má model například určité maximální kontextové okno, neznamená to určitý počet slov, ale počet tokenů. A protože tokeny nejsou totéž co slova, skutečná délka textu se může lišit podle jazyka, stylu, formátu a obsahu.

Do kontextového okna se počítá například:

• aktuální dotaz uživatele,
• předchozí části konverzace,
• instrukce pro model,
• vložené dokumenty nebo jejich úryvky,
• výsledky retrievalu,
• tabulky, kód nebo JSON,
• odpověď, kterou model vytváří.

To vysvětluje, proč model nemůže donekonečna držet celou dlouhou konverzaci nebo obrovské dokumenty v aktivní paměti. V určitém okamžiku se narazí na limit tokenů.

Input tokeny a output tokeny

U AI modelů se často rozlišují vstupní a výstupní tokeny.

• Input tokeny – tokeny, které model dostane na vstupu. Patří sem prompt, instrukce, historie konverzace, vložené dokumenty nebo kontext.
• Output tokeny – tokeny, které model vygeneruje v odpovědi.

Toto rozlišení je důležité hlavně u API, protože vstupní a výstupní tokeny mohou být účtované jinak. Výstupní tokeny bývají často výpočetně náročnější, protože model je generuje postupně.

Příklad:

• uživatel pošle dlouhý dokument – spotřebuje hodně input tokenů,
• model vytvoří krátké shrnutí – spotřebuje méně output tokenů,
• u dlouhé odpovědi roste počet output tokenů,
• u opakovaného posílání celé historie konverzace roste počet input tokenů.

Tokeny a cena AI služeb

Tokeny jsou důležité i pro cenu. Mnoho AI služeb účtuje používání podle počtu tokenů, případně podle objemu zpracovaného vstupu a výstupu. Čím více tokenů systém zpracuje, tím vyšší může být cena.

To je důležité hlavně u API a firemních aplikací. Uživatel v běžném chatu cenu tokenů většinou přímo neřeší, ale u automatizace, chatbotů, RAG systémů nebo analýzy dokumentů už tokeny rozhodují o provozních nákladech.

Náklady zvyšuje hlavně:

• dlouhý prompt,
• dlouhá historie konverzace,
• velké množství vložených dokumentů,
• neefektivní retrieval, který modelu předává příliš mnoho textu,
• dlouhé odpovědi,
• opakované zpracování stejných podkladů,
• zdrojový kód, tabulky, JSON a technické výstupy.

Proto se u dobře navržených AI aplikací neřeší jen kvalita modelu, ale také efektivita práce s tokeny.

Kolik znaků nebo slov je jeden token

Přesný převod neexistuje. Orientačně se často uvádí, že v angličtině jeden token odpovídá přibližně čtyřem znakům nebo zhruba třem čtvrtinám slova. Google u Gemini uvádí podobné orientační pravidlo, že jeden token je přibližně čtyři znaky a 100 tokenů odpovídá zhruba 60-80 anglickým slovům.

U češtiny ale může být poměr jiný. Čeština má delší tvary slov, diakritiku, skloňování a složitější morfologii. Proto stejný počet slov v češtině a angličtině nemusí znamenat stejný počet tokenů.

Prakticky je nejlepší brát podobné převody jen jako odhad. Pokud záleží na přesnosti, je potřeba použít konkrétní token counter pro konkrétní model.

Tokeny v češtině

Čeština může být z pohledu tokenizace náročnější než angličtina. Důvodem jsou delší slova, diakritika, skloňování, časování a mnoho tvarů jednoho výrazu.

Například slova jako „nejpravděpodobnější“, „zpracovatelnost“, „fotovoltaickými“ nebo „neobhospodařovatelný“ se mohou rozdělit na více tokenů. U angličtiny bývá mnoho běžných slov v tokenizeru zastoupeno efektivněji, protože většina tokenizerů byla historicky optimalizovaná na velké objemy anglického textu.

To neznamená, že model neumí česky. Znamená to jen, že český text může v některých případech spotřebovat více tokenů než podobně dlouhý anglický text.

Tokeny a dlouhé dokumenty

Tokeny jsou zásadní při práci s dlouhými dokumenty. Pokud uživatel nahraje dlouhý text, knihu, smlouvu, technickou dokumentaci nebo export z databáze, model nemusí být schopný celý obsah zpracovat najednou.

Proto se používají různé strategie:

• rozdělení dokumentu na části,
• shrnutí po kapitolách,
• retrieval relevantních pasáží,
• chunking,
• práce jen s vybranými částmi,
• postupná analýza,
• komprese kontextu.

U dlouhých dokumentů tedy nejde jen o to, zda model „umí číst“. Jde také o to, kolik tokenů se vejde do kontextu a jak chytře se s tímto prostorem pracuje.

Tokeny a RAG

RAG, tedy Retrieval-Augmented Generation, pracuje s tokeny velmi výrazně. Retrieval systém najde relevantní části dokumentů a ty potom vloží do kontextu modelu.

Pokud retrieval najde příliš mnoho textu, spotřebuje mnoho tokenů a může odpověď zhoršit. Pokud najde příliš málo textu, model nemusí mít dost informací. Dobře navržený RAG systém proto hledá rovnováhu mezi dostatkem kontextu a úsporným využitím tokenů.

Příklad:

• špatný retrieval předá modelu 20 dlouhých pasáží, z nichž většina nesouvisí s dotazem,
• dobrý retrieval předá modelu 3-5 přesných pasáží, které odpovídají otázce,
• model má potom větší šanci odpovědět přesně a levněji.

Tokeny tedy nejsou jen technický detail. Ovlivňují i kvalitu znalostních asistentů a firemních chatbotů.

Tokeny a paměť modelu

Tokeny souvisejí i s tím, co si model v dané konverzaci „pamatuje“. Model neudržuje nekonečnou paměť celé konverzace v aktivním kontextu. Pracuje s tím, co se vejde do jeho kontextového okna.

Pokud je konverzace dlouhá, starší části se mohou z aktivního kontextu postupně ztrácet nebo se musí shrnout. To je důvod, proč může být u velmi dlouhých konverzací užitečné připomenout důležité body, nebo pracovat s jasně strukturovaným zadáním.

Tokeny a generování odpovědi

Model generuje odpověď postupně po tokenech. Nevytvoří celou větu najednou jako hotový blok. V každém kroku odhaduje, jaký další token má následovat podle předchozího kontextu.

Zjednodušeně:

• model dostane vstupní tokeny,
• vyhodnotí kontext,
• vygeneruje první výstupní token,
• potom druhý, třetí a další,
• pokračuje, dokud odpověď neskončí nebo nenarazí na limit.

To vysvětluje, proč se odpověď modelu v chatu zobrazuje postupně. Model ji skutečně postupně skládá.

Tokeny a limit délky odpovědi

Model nemůže generovat neomezeně dlouhou odpověď. Výstup má svůj limit, který se také počítá v tokenech. Pokud je požadovaná odpověď příliš dlouhá, může se zkrátit, přerušit nebo musí být rozdělena na více částí.

To je důležité například u dlouhých článků, rozsáhlých analýz, právních textů, technických dokumentací nebo exportů do HTML. Pokud uživatel chce velmi dlouhý výstup, je lepší zadání dobře strukturovat a rozdělit obsah na logické části.

Tokeny a multimodální modely

U multimodálních modelů se pojem token nepoužívá jen pro text. Modely, které pracují s obrázky, audiem nebo videem, často převádějí i tyto vstupy na interní reprezentace, které se při účtování a práci s kontextem mohou také počítat jako tokeny nebo tokenům podobné jednotky.

Například obrázek může zabrat určitý počet vstupních tokenů podle velikosti, rozlišení nebo způsobu zpracování. Audio a video mohou být ještě náročnější, protože obsahují časový průběh a větší množství dat.

Prakticky to znamená, že do limitů a ceny nemusí vstupovat jen text. U multimodálních systémů může být důležité i to, kolik obrázků, stránek PDF, minut audia nebo videa se zpracovává.

Tokeny a kód

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

Proto může krátký kus kódu spotřebovat více tokenů, než by člověk čekal. Zvlášť náročné mohou být:

• minifikovaný JavaScript,
• dlouhé JSON soubory,
• HTML s mnoha atributy,
• SQL dotazy,
• logy,
• stack trace,
• konfigurační soubory,
• exporty z nástrojů nebo API.

Při práci s kódem je proto vhodné posílat jen relevantní části, ne celé repozitáře bez výběru.

Tokeny a tabulky

Tabulky mohou být tokenově náročné. Obsahují mnoho oddělovačů, buněk, čísel, hlaviček, opakujících se hodnot a strukturálních znaků. Pokud se tabulka převede do CSV, HTML nebo Markdownu, může počet tokenů rychle narůst.

To je důležité při analýze dat. Model může dobře pracovat s menší tabulkou, ale velký export je lepší nejprve zpracovat analytickým nástrojem a modelu poslat jen agregované výsledky nebo vybraný vzorek.

Tokeny a prompt engineering

Prompt engineering není jen o tom, jak napsat chytré zadání. Je také o tom, jak efektivně pracovat s tokeny. Dobrý prompt má obsahovat dost informací, ale neměl by být zbytečně nafouknutý.

Špatný prompt může být dlouhý, opakující se a nepřesný. Spotřebuje mnoho tokenů, ale modelu nepomůže. Dobrý prompt je jasný, strukturovaný a říká modelu, co má udělat, s jakými omezeními a v jakém formátu.

Příklad zbytečně náročného zadání:

• dlouhá historie bez shrnutí,
• opakované instrukce,
• nepotřebné části dokumentu,
• balastní text,
• nejasný požadavek na výstup.

Příklad efektivního zadání:

• jasný cíl,
• relevantní podklady,
• omezení,
• požadovaný formát,
• instrukce, co nedělat.

Proč se tokeny počítají různě u různých modelů

Různé modely mohou používat různé tokenizery. To znamená, že stejný text může mít u jednoho modelu jiný počet tokenů než u druhého.

Rozdíl může být způsoben například:

• jiným slovníkem tokenizeru,
• jiným způsobem dělení slov,
• jinou podporou jazyků,
• jiným zacházením s interpunkcí a mezerami,
• jiným zpracováním kódu,
• jiným zpracováním obrázků, dokumentů nebo multimodálních vstupů.

Proto není dobré spoléhat na univerzální ruční odhad. U přesných výpočtů je potřeba použít token counter odpovídající konkrétnímu modelu nebo poskytovateli.

Co je token counter

Token counter je nástroj, který spočítá, kolik tokenů má konkrétní vstup. Používá se hlavně před odesláním požadavku do API, aby bylo možné odhadnout cenu, ověřit limit kontextového okna a předejít chybám.

Token counter pomáhá zjistit:

• kolik tokenů má prompt,
• zda se vstup vejde do limitu modelu,
• jaká může být přibližná cena požadavku,
• zda je nutné text zkrátit,
• kolik prostoru zbývá pro odpověď,
• zda retrieval neposílá modelu příliš mnoho kontextu.

U produkčních aplikací je token counting důležitou součástí návrhu systému.

Časté chyby při práci s tokeny

Nejčastější chybou je počítat slova a předpokládat, že výsledek odpovídá tokenům. To neplatí. Počet tokenů může být výrazně jiný.

Další častou chybou je posílat modelu příliš mnoho kontextu. Uživatel nebo aplikace přidá celé dokumenty, dlouhou historii, mnoho příkladů a rozsáhlé instrukce. Výsledkem je dražší požadavek, pomalejší odpověď a někdy i horší kvalita, protože model dostane příliš mnoho balastu.

Problémem je také ignorování výstupních tokenů. Nestačí řešit jen délku promptu. Je potřeba počítat i s tím, kolik tokenů má model vygenerovat v odpovědi.

Jak šetřit tokeny

Šetření tokenů neznamená, že má být prompt co nejkratší za každou cenu. Znamená to, že má být účelný.

Pomoci může:

• odstranit opakující se instrukce,
• posílat jen relevantní části dokumentů,
• dlouhé dokumenty předem rozdělit,
• používat retrieval místo vkládání celé znalostní báze,
• shrnovat starší historii konverzace,
• omezit délku požadované odpovědi,
• neposílat zbytečně celé tabulky, pokud stačí agregace,
• u kódu posílat jen soubory nebo funkce, které souvisí s problémem,
• používat strukturovaný, ale ne přehnaně dlouhý prompt.

Kdy naopak tokeny nešetřit příliš

Příliš krátký prompt může být stejně špatný jako příliš dlouhý. Pokud model nedostane dost kontextu, může odpovědět obecně nebo špatně.

Tokeny se vyplatí použít tam, kde nesou důležitou informaci:

• konkrétní zadání,
• definice cíle,
• kritéria kvality,
• ukázkový styl výstupu,
• relevantní podklady,
• omezení a zakázané postupy,
• přesný formát odpovědi.

Smyslem není mít prompt nejkratší. Smyslem je mít prompt dostatečně přesný a bez zbytečného balastu.

Tokeny a halucinace

Tokeny samy o sobě nezpůsobují halucinace, ale práce s nimi může ovlivnit kvalitu odpovědi. Pokud se do kontextu nevejdou důležité informace, model může začít doplňovat chybějící části podle pravděpodobnosti. Pokud je kontext přeplněný nesouvisejícím textem, model se může opřít o špatnou část vstupu.

Dobrá práce s tokeny tedy pomáhá modelu držet se relevantních informací. U RAG systémů je proto důležité, aby retrieval posílal modelu přesné a krátké pasáže, ne velké množství náhodně podobného textu.

Tokeny a rychlost odpovědi

Počet tokenů ovlivňuje také rychlost. Čím více tokenů model zpracovává a generuje, tím déle může odpověď trvat. Velmi dlouhý vstup nebo výstup může být pomalejší než krátký dotaz a stručná odpověď.

To je důležité hlavně u aplikací, kde záleží na odezvě – například zákaznická podpora, asistenti v rozhraní aplikace, hlasové systémy nebo interní nástroje používané v reálném čase.

Tokeny a bezpečnost

Tokeny mají význam i z hlediska bezpečnosti. Do kontextu modelu se někdy vkládají instrukce, dokumenty, historie komunikace nebo data z nástrojů. Pokud se do promptu dostane příliš mnoho nekontrolovaného obsahu, může to zvýšit riziko prompt injection nebo nechtěného úniku citlivých informací.

Bezpečný návrh AI aplikace proto řeší nejen to, kolik tokenů se vejde do kontextu, ale také jaké tokeny se tam vůbec dostanou.

Jak poznat, že je problém v tokenech

Problém s tokeny se může projevit různě. Někdy model odmítne zpracovat příliš dlouhý vstup. Jindy odpověď zkrátí. V dlouhé konverzaci může přehlédnout starší informace. U API může požadavek zdražit nebo překročit limit modelu.

Typické příznaky:

• vstup je příliš dlouhý a nevejde se do modelu,
• odpověď se usekne,
• model zapomene starší část konverzace,
• aplikace má vysoké náklady na API,
• RAG systém posílá příliš mnoho kontextu,
• model odpovídá zmateně kvůli přetíženému promptu,
• dlouhé tabulky nebo kód zabírají víc prostoru, než se čekalo.

Kde jsou limity tokenů

Tokeny jsou praktická výpočetní jednotka, ale nejsou dokonalým měřítkem významu. Jeden token může nést důležitou informaci, jiný může být jen interpunkce nebo část formátování. Dlouhý text s mnoha tokeny nemusí být informačně bohatší než krátký, dobře napsaný odstavec.

Stejně tak větší kontextové okno neznamená automaticky lepší odpověď. Model sice může zpracovat více tokenů, ale pořád záleží na kvalitě vstupu, relevanci informací a schopnosti modelu najít v dlouhém kontextu to podstatné.

Token ve firemním prostředí

Ve firemních AI aplikacích je práce s tokeny důležitá pro náklady, rychlost i kvalitu. Pokud firma staví AI asistenta nad interní dokumentací, zákaznickou podporou, technickými návody nebo produktovou databází, musí řešit, kolik textu se modelu posílá.

Dobře navržená aplikace obvykle:

• neposílá modelu celou databázi,
• používá retrieval pro výběr relevantních pasáží,
• omezuje zbytečnou historii konverzace,
• počítá vstupní i výstupní tokeny,
• hlídá cenu API,
• testuje délku odpovědí,
• pracuje s limity kontextového okna,
• odděluje nutný kontext od zbytečného balastu.

Tokeny tedy nejsou jen věc pro vývojáře. Ovlivňují i ekonomiku a použitelnost celého AI řešení.

Token a běžný uživatel

Běžný uživatel nemusí tokeny počítat přesně. Měl by ale chápat základní princip: model má omezenou pracovní paměť a každá část zadání z ní něco ukrajuje.

Proto je lepší:

• neposílat zbytečně obrovské množství nesouvisejícího textu,
• u dlouhých dokumentů jasně říct, co má model hledat,
• u dlouhých konverzací připomenout důležité body,
• u rozsáhlých úkolů pracovat po částech,
• u výstupů říct, zda má být odpověď stručná, nebo podrobná.

Časté otázky k tokenům

Je jeden token jedno slovo?

Ne. Jeden token může být celé slovo, část slova, interpunkce, mezera, číslo nebo jiný úsek textu. Přesné dělení záleží na tokenizeru konkrétního modelu.

Počítají se do tokenů i mezery?

Ano, mezery a interpunkce mohou být součástí tokenizace. Ne vždy jako samostatný token, ale do výsledného počtu tokenů se způsob zápisu promítá.

Počítá se do tokenů i odpověď modelu?

Ano. U modelů se obvykle rozlišují vstupní tokeny a výstupní tokeny. Vstup jsou tokeny v promptu a kontextu. Výstup jsou tokeny, které model vygeneruje.

Proč má stejný text u různých modelů jiný počet tokenů?

Protože různé modely mohou používat různé tokenizery. Stejný text se tedy může rozdělit jinak.

Proč se tokeny řeší u ceny API?

Protože zpracování tokenů představuje výpočetní náklad. Čím více tokenů model přijme a vygeneruje, tím vyšší může být cena požadavku.

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 – stejný text může mít u různých modelů jiný počet tokenů. Mitigace: nepočítat univerzálně, ale podle konkrétního poskytovatele a modelu.
• Přetížení kontextu – příliš mnoho nerelevantního textu může zhoršit odpověď. Mitigace: posílat jen relevantní podklady a používat retrieval.
• Nedostatek kontextu – příliš krátké zadání může vést k obecné nebo nepřesné odpovědi. Mitigace: dodat modelu jasný cíl, omezení a potřebná data.
• Vyšší náklady v API – dlouhé vstupy a výstupy zvyšují spotřebu tokenů. Mitigace: sledovat input a output tokeny, optimalizovat prompty a omezit zbytečný kontext.
• Tokenově náročné formáty – kód, JSON, HTML, tabulky a URL adresy mohou spotřebovat více tokenů než běžný text. Mitigace: posílat jen relevantní části nebo data předem agregovat.
• Multimodální vstupy – obrázky, audio, video nebo PDF mohou mít vlastní způsob započítání do limitů a ceny. Mitigace: kontrolovat dokumentaci konkrétního modelu a používat odhady jen orientačně.
• Změny u poskytovatelů – limity, tokenizery a účtování se mohou u AI služeb měnit. Mitigace: pravidelně kontrolovat aktuální dokumentaci a ceníky.

Související pojmy

• Tokenizace – proces rozdělení textu na tokeny.
• Tokenizer – nástroj nebo část modelu, která určuje, jak se text rozdělí na tokeny.
• Kontextové okno – maximální množství tokenů, které model dokáže najednou zpracovat.
• Input tokeny – tokeny obsažené ve vstupu, promptu, dokumentech nebo historii konverzace.
• Output tokeny – tokeny, které model vygeneruje jako odpověď.
• Prompt – zadání nebo instrukce, které uživatel předává modelu.
• Embedding – číselná reprezentace obsahu, která umožňuje porovnávat významovou podobnost.
• RAG – architektura, která kombinuje retrieval relevantních informací s generováním odpovědi.
• Chunking – rozdělení většího dokumentu na menší části pro snazší vyhledávání a práci s kontextem.

Odkazy a zdroje

• What are tokens and how to count them? – help.openai.com – duben 2026 – článek vysvětluje, co OpenAI myslí tokenem, proč se text nepočítá jednoduše po slovech a jak se tokeny promítají do vstupu, výstupu i ceny používání modelů.
• Tokenizer – OpenAI API – platform.openai.com – duben 2026 – stránka umožňuje vložit vlastní text a přímo si zobrazit, na kolik tokenů se rozdělí a jak jednotlivé tokeny vypadají.
• Understand and count tokens – Gemini API – ai.google.dev – březen 2026 – dokumentace popisuje, jak Gemini počítá tokeny, jaký je orientační vztah mezi tokeny, znaky a slovy a jak si počet tokenů ověřit před voláním API.
• Token counting – Claude API Docs – platform.claude.com – duben 2026 – dokumentace ukazuje, jak u Claude modelů počítat tokeny a proč je to důležité pro délku promptu, kontextové limity, náklady a výběr vhodného modelu.
• Tokenizers – Hugging Face LLM Course – huggingface.co – duben 2026 – výuková část kurzu vysvětluje, co dělá tokenizer, proč je potřeba před samotným modelem a jak převádí text do podoby, se kterou může neuronová síť pracovat.
• Tokenization algorithms – huggingface.co – duben 2026 – stránka rozebírá různé přístupy k tokenizaci, hlavně dělení slov na menší části pomocí algoritmů jako BPE, WordPiece nebo Unigram.