Chunking je rozdělení delšího textu nebo dokumentu na menší části, se kterými může AI systém lépe pracovat. Místo toho, aby se modelu nebo vyhledávací vrstvě předával celý dlouhý dokument najednou, rozdělí se obsah na kratší úseky – například odstavce, kapitoly, části návodu nebo bloky textu. Tyto menší části se potom dají samostatně vyhledávat, ukládat, převádět na embeddingy a vkládat modelu do kontextu.

Na první pohled může chunking působit jako obyčejné „rozsekání textu“. Ve skutečnosti je to jeden z důležitých kroků při práci s dlouhými dokumenty, RAG systémy, embeddingy a znalostními bázemi. Pokud se dokument rozdělí špatně, model může dostat neúplný kontext, špatnou pasáž nebo příliš obecný úryvek. Pokud se rozdělí dobře, systém snáze najde přesně tu část dokumentu, která odpovídá dotazu uživatele.

Co chunking v praxi znamená

Chunking se používá hlavně ve chvíli, kdy má systém pracovat s delším obsahem. Může jít o PDF dokument, článek, interní návod, smlouvu, produktovou dokumentaci, znalostní bázi, technický manuál, přepis meetingu nebo archiv zákaznické podpory.

Takový dokument se nedá vždy jednoduše poslat celý jazykovému modelu. Může být moc dlouhý, obsahovat více témat nebo mít části, které s dotazem vůbec nesouvisí.

Chunking proto rozdělí obsah na menší úseky.

Příklad:

• dlouhý reklamační řád se rozdělí na části o poškozeném zboží, vrácení zboží, lhůtách, dopravě a penězích,
• produktový manuál se rozdělí podle kapitol, funkcí nebo kroků v návodu,
• článek se rozdělí podle nadpisů a odstavců,
• přepis meetingu se rozdělí podle témat nebo časových bloků,
• smlouva se rozdělí podle jednotlivých ustanovení.

Díky tomu může systém při dotazu najít jen tu část, která je opravdu potřeba.

Proč nestačí pracovat s celým dokumentem

U krátkého textu chunking většinou není potřeba. Pokud má dokument pár vět, lze ho zpracovat jako celek. Problém začíná u dlouhých dokumentů.

Dlouhý dokument může mít několik slabin:

• obsahuje více témat najednou,
• nevejde se celý do kontextového okna modelu,
• obsahuje mnoho balastu, který s dotazem nesouvisí,
• při vyhledávání může být příliš obecný,
• model může dostat moc textu a hůře najít to podstatné.

Představte si například padesátistránkový manuál k e-shopové administraci. Uživatel se zeptá, jak změnit adresu doručení u objednávky. Není potřeba, aby model četl celý manuál včetně kapitol o fakturaci, skladu, exportech a nastavení účtů. Potřebuje jen část, která popisuje úpravu dodacích údajů.

Chunking pomáhá právě v tom, že z velkého dokumentu vytvoří menší části, které se dají vyhledat samostatně.

Co je chunk

Chunk je jedna menší část většího dokumentu.

Nemusí to být vždy odstavec. Podle nastavení systému může být chunk:

• několik vět,
• jeden odstavec,
• část kapitoly,
• celá sekce pod jedním nadpisem,
• část tabulky,
• úsek přepisu rozhovoru,
• část zdrojového kódu,
• blok textu o určitém počtu tokenů.

Důležité je, aby chunk dával smysl sám o sobě. Pokud se dokument rozdělí uprostřed věty, uprostřed odstavce nebo mezi nadpisem a vysvětlením, systém může později najít neúplnou část.

Špatný chunk může vypadat například takto:

„…zákazník je povinen doložit fotografii obalu. Pokud tak neučiní…“

Tady chybí začátek i konec myšlenky. Model nemusí vědět, o jakou situaci jde.

Lepší chunk by zachoval celý významový blok:

„U poškozené zásilky musí zákazník doložit fotografii produktu, vnějšího obalu a přepravního štítku. Reklamaci je nutné nahlásit nejpozději do 48 hodin od převzetí zásilky.“

Takový úsek už dává smysl i samostatně.

Jak chunking funguje krok za krokem

Chunking není jen mechanické dělení textu po určitém počtu znaků. V dobře navrženém systému má několik navazujících kroků.

1. Systém získá text z dokumentu – nejprve je potřeba mít obsah v podobě, se kterou lze pracovat. U běžných textů je to jednoduché. U PDF, skenů nebo obrázků může být potřeba nejprve použít OCR, aby se text z dokumentu vůbec vytěžil.
2. Text se očistí a připraví – odstraní se zbytečné části, které by vyhledávání spíš mátly. Může jít například o opakující se patičky, navigaci, čísla stránek, duplicitní hlavičky nebo technický balast.
3. Systém rozpozná strukturu dokumentu – u kvalitního chunkingu je důležité vědět, kde jsou nadpisy, kapitoly, odstavce, seznamy, tabulky nebo jiné logické části. Dělit dokument bez ohledu na strukturu často vede k horším výsledkům.
4. Obsah se rozdělí na menší části – jednotlivé části by měly být dost krátké na vyhledávání, ale zároveň dost dlouhé na to, aby neztratily význam. Ideálně se nerozdělují uprostřed důležité myšlenky.
5. Ke chunkům se uloží metadata – metadata jsou doplňující informace, například název dokumentu, URL, datum, kapitola, autor, jazyk nebo verze. Díky nim systém později ví, odkud chunk pochází a zda je stále platný.
6. Chunky se uloží do indexu nebo databáze – každý chunk se může uložit do vyhledávacího indexu. Často se k němu vytvoří také embedding, tedy číselná reprezentace obsahu, která pomáhá hledat významově podobné texty.
7. Při dotazu se vyhledají nejvhodnější chunky – když se uživatel zeptá, systém nehledá odpověď v celém dokumentu najednou. Porovná dotaz s uloženými chunky a vybere ty, které s otázkou nejvíce souvisejí.
8. Vybrané chunky se předají modelu jako kontext – model dostane otázku uživatele a několik nalezených částí dokumentu. Z nich potom vytvoří odpověď.

Tento postup je typický hlavně pro RAG systémy, které kombinují vyhledání relevantních informací s generováním odpovědi.

Chunking a RAG

RAG, tedy Retrieval-Augmented Generation, stojí na tom, že systém nejprve vyhledá relevantní informace a teprve potom z nich model vytvoří odpověď.

Chunking v RAG rozhoduje o tom, jaké části dokumentů se budou vůbec vyhledávat.

Pokud jsou chunky příliš velké, systém může najít text, který s dotazem souvisí jen částečně. Model potom dostane zbytečně mnoho informací a může odpovědět nepřesně.

Pokud jsou chunky příliš malé, může se ztratit kontext. Model dostane jednu větu, ale neví, ke kterému nadpisu, pravidlu nebo výjimce patří.

Příklad:

• Příliš velký chunk – celá kapitola o reklamacích, vrácení zboží, dopravě a platbách dohromady.
• Příliš malý chunk – jedna věta „Zákazník musí doložit fotografii obalu.“ bez vysvětlení, kdy a proč.
• Lepší chunk – celý odstavec nebo krátká sekce o reklamaci poškozené zásilky.

Chunking tedy ovlivňuje, co přesně RAG systém najde a co potom model uvidí.

Chunking a retrieval

Retrieval znamená vyhledání a načtení relevantních informací. Chunking určuje, v jakých jednotkách se bude hledat.

Bez chunkingu by systém často hledal v celých dokumentech. To může být problém, protože dokument může obsahovat mnoho různých témat. Pokud se celý dokument převede na jeden vyhledatelný záznam, systém nemusí dobře poznat, která konkrétní část je pro dotaz důležitá.

S chunkingem se vyhledává nad menšími částmi.

Příklad:

• uživatel se ptá na změnu adresy doručení,
• systém nehledá celý manuál e-shopu,
• hledá část manuálu, která popisuje úpravu dodacích údajů,
• tu pak předá modelu jako podklad.

Díky tomu může být odpověď přesnější a rychlejší.

Chunking a embeddingy

Embedding je číselná reprezentace obsahu. V RAG systémech se často vytváří embedding pro každý chunk zvlášť.

To je důležité, protože embedding celého dlouhého dokumentu bývá příliš obecný. Pokud jeden dokument obsahuje deset různých témat, jeden embedding bude tyto významy míchat dohromady.

Lepší je vytvořit embedding pro menší části.

Příklad:

• jeden chunk řeší reklamace,
• druhý chunk řeší platby,
• třetí chunk řeší dopravu,
• čtvrtý chunk řeší odstoupení od smlouvy.

Každý z nich dostane vlastní embedding. Když se uživatel zeptá na reklamaci, systém má větší šanci najít právě část o reklamacích, ne celý obecný dokument.

Chunking a kontextové okno

Kontextové okno určuje, kolik informací může model zpracovat najednou. Do tohoto prostoru se musí vejít dotaz uživatele, nalezené podklady, instrukce systému i odpověď modelu.

Chunking pomáhá rozhodnout, co se do tohoto prostoru vloží.

Pokud systém vloží celý dlouhý dokument, může zaplnit kontextové okno textem, který s otázkou nesouvisí. Pokud vloží jen dobře vybrané chunky, model má větší šanci pracovat s tím, co je opravdu důležité.

To je jeden z hlavních důvodů, proč se chunking používá v AI aplikacích nad dokumenty.

Chunking a tokeny

Tokeny jsou jednotky, ve kterých jazykový model technicky zpracovává text. Velikost chunku se proto často nepočítá podle slov nebo znaků, ale podle tokenů.

To je důležité, protože jeden token není totéž co jedno slovo. Technický text, HTML, JSON, tabulky nebo kód mohou spotřebovat více tokenů, než by člověk podle délky textu čekal.

Při chunkingu se proto řeší:

• kolik tokenů má jeden chunk,
• kolik chunků se má modelu předat,
• kolik prostoru zůstane pro odpověď,
• jestli se kvůli příliš dlouhým chunkům nezaplní kontextové okno.

Příliš dlouhé chunky zvyšují náklady a mohou zhoršit přesnost. Příliš krátké chunky zase mohou přijít o kontext.

Co je velikost chunku

Velikost chunku určuje, jak dlouhá bude jedna část dokumentu.

Může se měřit například:

• počtem znaků,
• počtem slov,
• počtem tokenů,
• počtem vět,
• počtem odstavců,
• strukturou dokumentu, například sekcí pod jedním nadpisem.

Neexistuje jedna univerzální správná velikost. Záleží na tom, jaké dokumenty se zpracovávají a jaké otázky bude uživatel pokládat.

U stručných návodů mohou fungovat kratší chunky. U právních, technických nebo odborných dokumentů může být potřeba delší úsek, aby se neztratil kontext.

Co je chunk overlap

Chunk overlap znamená překryv mezi sousedními chunky.

Příklad bez překryvu:

• chunk 1 obsahuje věty 1-5,
• chunk 2 obsahuje věty 6-10.

Příklad s překryvem:

• chunk 1 obsahuje věty 1-5,
• chunk 2 obsahuje věty 4-8.

Věty 4 a 5 se tedy objeví v obou částech. Smyslem je neztratit souvislost na hranici mezi chunky.

Překryv pomáhá hlavně tehdy, když důležitá informace leží přesně na konci jedné části a pokračuje na začátku další. Bez překryvu by systém mohl najít jen polovinu potřebného kontextu.

Typy chunkingu

Existuje více způsobů, jak text rozdělit. V praxi se často kombinují.

Fixed-size chunking

Fixed-size chunking dělí text na části o předem dané velikosti. Například každých 500 tokenů nebo každých 2 000 znaků.

Výhoda je jednoduchost. Systém se snadno nastaví a výsledek je předvídatelný.

Nevýhoda je, že se text může rozdělit nevhodně. Například uprostřed věty, odstavce nebo vysvětlení.

Hodí se spíše tam, kde dokumenty nemají jasnou strukturu nebo kde je potřeba rychlé základní řešení.

Chunking podle odstavců

Při tomto přístupu se text dělí podle odstavců. Výhodou je, že odstavec často drží jednu myšlenku pohromadě.

Nevýhodou je, že některé odstavce mohou být příliš krátké a jiné příliš dlouhé. U špatně strukturovaných dokumentů nemusí být odstavce dobrým vodítkem.

Chunking podle nadpisů a sekcí

Tento přístup se snaží zachovat logiku dokumentu. Text se dělí podle nadpisů, podnadpisů, kapitol nebo sekcí.

Příklad:

• „Jak změnit adresu doručení“ jako jeden chunk,
• „Jak stornovat objednávku“ jako druhý chunk,
• „Jak vystavit dobropis“ jako třetí chunk.

To bývá vhodné u dokumentace, článků, manuálů a znalostních bází.

Semantic chunking

Semantic chunking se snaží dělit text podle významu. Cílem je, aby jedna část obsahovala myšlenky, které spolu opravdu souvisejí.

Nejde tedy jen o délku textu. Systém se snaží poznat, kde končí jedno téma a začíná jiné.

To může být užitečné u delších textů, které mají složitější strukturu. Zároveň je to náročnější než jednoduché dělení podle velikosti.

Hierarchical chunking

Hierarchical chunking pracuje s více úrovněmi. Dokument se může rozdělit na větší části a ty se potom rozdělí ještě na menší části.

Příklad:

• celý manuál,
• kapitola o objednávkách,
• sekce o změně adresy,
• konkrétní odstavec s postupem.

Tento přístup pomáhá najít konkrétní informaci a zároveň si zachovat odkaz na širší kontext.

Sliding window chunking

Sliding window chunking vytváří překrývající se části textu. Každý další chunk začíná o kus dál, ale část textu se opakuje z předchozího chunku.

Hodí se tam, kde nechcete ztratit kontext na hraně mezi dvěma částmi. Nevýhodou je větší počet chunků a více duplicit.

Chunking podle typu obsahu

Někdy dává smysl dělit obsah podle toho, co obsahuje.

Jinak se dělí:

• běžný článek,
• technická dokumentace,
• smlouva,
• tabulka,
• zdrojový kód,
• přepis meetingu,
• PDF s více sloupci,
• produktový katalog.

Například u zdrojového kódu nechcete rozdělit funkci uprostřed. U smlouvy nechcete oddělit odstavec od nadpisu a výjimek. U tabulky nechcete ztratit hlavičku sloupců.

Dobrý a špatný chunking na příkladu

Představte si nápovědu pro e-shopovou administraci. Uživatel hledá, jak změnit adresu doručení u objednávky.

Špatný chunk může obsahovat jen část postupu:

„…klikněte na tlačítko Upravit. Pokud je objednávka už předaná dopravci…“

Tady chybí, čeho se postup týká. Model může mít problém správně pochopit kontext.

Lepší chunk:

„Změna adresy doručení u objednávky: otevřete detail objednávky, v části Dodací údaje klikněte na Upravit a zadejte novou adresu. Pokud je objednávka už předaná dopravci, změna adresy nemusí být dostupná.“

Takový chunk obsahuje název situace, konkrétní postup i důležitou výjimku.

Proč je důležité zachovat nadpisy

Nadpis často vysvětluje, o čem následující text je. Pokud systém při chunkingu oddělí nadpis od odstavce, může vzniknout úsek, který sám o sobě nedává smysl.

Příklad bez nadpisu:

„Klikněte na Upravit a zadejte novou adresu.“

Není jasné, co se upravuje.

Příklad s nadpisem:

„Změna adresy doručení u objednávky: klikněte na Upravit a zadejte novou adresu.“

Tady už je význam jasný.

Proto se při chunkingu často vyplatí přidávat nadpis nebo cestu dokumentem ke každému chunku.

Například:

• Nápověda > Objednávky > Změna adresy doručení
• Obchodní podmínky > Reklamace > Poškozená zásilka
• Technická dokumentace > API > Autentizace

Chunking a metadata

Metadata jsou doplňující informace o chunku. Pomáhají systému poznat, odkud chunk pochází a jak s ním má pracovat.

Metadata mohou obsahovat například:

• název dokumentu,
• URL adresu,
• nadpis kapitoly,
• datum poslední aktualizace,
• verzi dokumentu,
• jazyk,
• typ dokumentu,
• oddělení, kterému dokument patří,
• oprávnění, kdo dokument smí vidět.

Bez metadat může systém najít správně vypadající text, ale nebude vědět, zda je aktuální, platný nebo dostupný pro daného uživatele.

Chunking u tabulek

Tabulky jsou pro chunking náročné. Nestačí rozdělit text po řádcích. Je potřeba zachovat vztah mezi hodnotami, hlavičkami a vysvětlivkami.

Špatné rozdělení tabulky může vést k tomu, že model dostane číslo, ale neví, k jakému sloupci nebo parametru patří.

Příklad problému:

• chunk obsahuje hodnotu „48 hodin“,
• ale chybí hlavička, že jde o lhůtu pro nahlášení poškozené zásilky.

U tabulek je proto důležité zachovat kontext. Někdy je lepší převést tabulku do strukturovanější textové podoby, kde je u každé hodnoty jasně uvedeno, co znamená.

Chunking u PDF dokumentů

PDF dokumenty mohou být jednoduché, ale také velmi problematické. Některé obsahují skutečný text. Jiné jsou jen skenem. Některé mají vícesloupcovou sazbu, tabulky, poznámky pod čarou, hlavičky, patičky nebo vložené obrázky.

Před chunkingem je proto potřeba zjistit, zda systém správně čte text a pořadí obsahu.

U PDF se často řeší:

• zda je text skutečně text, nebo jen obraz,
• zda se správně čte pořadí sloupců,
• zda se nepletou patičky a hlavičky do obsahu,
• zda se tabulky nerozpadají,
• zda se zachovají nadpisy a kapitoly,
• zda se uloží číslo stránky jako metadata.

Špatně vytěžený text z PDF povede ke špatnému chunkingu.

Chunking u přepisů meetingů

Přepisy meetingů se nedají vždy dobře dělit jen podle počtu znaků nebo minut. Jeden blok může obsahovat více témat, skoky v diskusi nebo neúplné věty.

U přepisů může dávat smysl dělit podle:

• témat,
• mluvčích,
• časových úseků,
• agendy meetingu,
• rozhodnutí a akčních bodů.

Cílem není jen rozdělit přepis mechanicky. Cílem je, aby každá část obsahovala rozumný kus diskuse, který se dá později najít a pochopit.

Chunking u zdrojového kódu

U kódu je chunking specifický. Kód není běžný text. Pokud se rozdělí špatně, může se rozbít logika programu.

U kódu je vhodné zachovat:

• celé funkce,
• celé třídy,
• importy, které s funkcí souvisejí,
• komentáře,
• kontext souboru,
• návaznosti mezi částmi kódu.

Není ideální rozdělit funkci uprostřed jen proto, že chunk dosáhl určitého počtu znaků. U kódu je často lepší dělit podle syntaktické struktury.

Jak vybrat správnou velikost chunku

Správná velikost chunku závisí na tom, co má systém dělat.

U jednoduché znalostní báze s krátkými návody mohou stačit kratší chunky. U právních nebo technických dokumentů může být potřeba delší kontext. U tabulek, smluv a kódu je nutné dávat pozor, aby se nerozbily významové vazby.

Při volbě velikosti chunku je dobré se ptát:

• jak dlouhé jsou dokumenty,
• jak složitá témata obsahují,
• zda mají jasné nadpisy a strukturu,
• jaké otázky budou uživatelé pokládat,
• zda odpověď vyžaduje jednu větu, odstavec nebo celou sekci,
• kolik tokenů se vejde do kontextového okna,
• kolik nalezených chunků se bude předávat modelu,
• zda je důležitější přesnost, nebo širší kontext.

Nejlepší je testovat chunking na reálných dotazech. Neexistuje univerzální číslo, které bude fungovat pro každý dokument a každý případ.

Menší versus větší chunky

Menší chunky mají výhodu v přesnosti. Systém může najít konkrétní odstavec, který odpovídá dotazu. Nevýhoda je, že se může ztratit širší kontext.

Větší chunky zachovají více souvislostí. Nevýhoda je, že mohou obsahovat mnoho textu, který s dotazem nesouvisí.

Zjednodušeně:

• menší chunky – přesnější vyhledávání, ale riziko ztráty kontextu,
• větší chunky – více kontextu, ale více balastu,
• překryv – pomáhá udržet návaznost, ale zvyšuje duplicity.

Dobrý chunking hledá rovnováhu mezi přesností a kontextem.

Chunking a kvalita odpovědi

Chunking přímo ovlivňuje kvalitu odpovědi AI systému. Model totiž odpovídá podle toho, jaké podklady dostane.

Pokud systém najde špatný chunk, model může odpovědět špatně. Pokud najde správný chunk, ale bez důležitého nadpisu nebo výjimky, odpověď může být neúplná. Pokud najde příliš mnoho chunků, model se může ztratit v nepodstatném textu.

Proto chunking není jen technické nastavení. Je to část návrhu informačního systému.

Dobře navržený chunking pomáhá:

• najít přesnější pasáže,
• snížit množství zbytečného textu,
• lépe využít kontextové okno,
• zlepšit odpovědi v RAG systémech,
• snížit riziko, že model bude odpovídat z neúplných podkladů,
• zachovat odkaz na původní dokument.

Časté chyby při chunkingu

Nejčastější chyba je rozdělit text jen mechanicky podle počtu znaků bez ohledu na význam. To může fungovat jako rychlý začátek, ale často to rozbije důležité souvislosti.

Chyby bývají hlavně tyto:

• Oddělení nadpisu od obsahu – chunk obsahuje vysvětlení, ale není jasné, k čemu patří.
• Rozdělení věty nebo odstavce uprostřed – systém najde jen polovinu myšlenky.
• Příliš velké chunky – model dostane moc textu a v něm málo relevantních informací.
• Příliš malé chunky – chybí souvislosti, výjimky nebo vysvětlení.
• Ignorování tabulek – hodnoty se oddělí od hlaviček a ztratí význam.
• Chybějící metadata – systém neví, odkud chunk pochází a zda je aktuální.
• Žádné testování – chunking se nastaví jednou a neověří se na reálných dotazech.

Jak poznat dobrý chunk

Dobrý chunk by měl dávat smysl i bez toho, aby člověk musel číst celý původní dokument.

Měl by ideálně obsahovat:

• jasné téma,
• dostatek kontextu,
• celou důležitou myšlenku,
• nadpis nebo informaci, kam v dokumentu patří,
• případné výjimky nebo podmínky,
• odkaz na původní zdroj,
• metadata o platnosti nebo verzi.

Pokud chunk po vytržení z dokumentu nedává smysl, pravděpodobně nebude dobrý ani pro RAG systém.

Chunking ve firemním prostředí

Ve firmě má chunking největší smysl tam, kde existuje hodně dokumentů a lidé v nich potřebují rychle hledat.

Typické použití:

• interní znalostní báze,
• zákaznická podpora,
• produktová dokumentace,
• obchodní podmínky,
• návody a manuály,
• smlouvy,
• technická dokumentace,
• firemní wiki,
• přepisy schůzek,
• archiv článků.

Chunking ale nezachrání špatné zdroje. Pokud jsou dokumenty zastaralé, duplicitní nebo nepřehledné, systém je jen rozdělí na menší nepřehledné části.

Proto je dobré před chunkingem řešit i kvalitu samotných dokumentů.

Kdy chunking nepomůže

Chunking není řešení na všechno. Nepomůže, pokud systém pracuje se špatnými, neaktuálními nebo rozpornými zdroji. Nepomůže ani tehdy, když dotaz vyžaduje informaci, která v dokumentech vůbec není.

Chunking také není náhrada za pochopení dokumentu. Jen připravuje obsah do menších částí. Odpověď pořád závisí na kvalitě retrievalu, modelu, promptu a zdrojových dat.

Chunking má menší smysl u velmi krátkých dokumentů, které už samy tvoří jeden jasný významový celek.

Kde jsou rizika a neznámé

U chunkingu je důležité počítat s tím, že kvalita výsledku závisí na typu dokumentů, způsobu dělení, velikosti chunků, metadatech a tom, jaké dotazy budou uživatelé skutečně pokládat.

• Příliš malé chunky – systém může najít přesný úsek, ale bez souvislostí. Mitigace: zachovat nadpisy, okolní věty a odkaz na původní část dokumentu.
• Příliš velké chunky – chunk může obsahovat moc témat najednou. Mitigace: dělit dokumenty podle významových celků a testovat výsledky na reálných dotazech.
• Špatné hranice chunků – důležitá informace může být rozdělená mezi dvě části. Mitigace: používat překryv nebo dělit podle odstavců, sekcí a vět.
• Ztráta struktury dokumentu – tabulky, nadpisy nebo seznamy se mohou rozpadnout. Mitigace: zachovat strukturu, metadata a hlavičky tabulek.
• Chybějící metadata – systém neví, odkud chunk pochází nebo zda je aktuální. Mitigace: ukládat název dokumentu, URL, datum, verzi a sekci.
• Duplicitní obsah – při velkém překryvu může index obsahovat mnoho opakovaného textu. Mitigace: nastavit přiměřený overlap a měřit dopad na náklady.
• Univerzální nastavení pro všechny dokumenty – jeden způsob dělení nemusí fungovat pro články, smlouvy, tabulky i kód. Mitigace: volit chunking podle typu obsahu.
• Neotestovaný chunking – systém může vypadat dobře technicky, ale vracet špatné části. Mitigace: testovat na reálných dotazech a kontrolovat, jaké chunky se skutečně vracejí.
• Citlivá data – chunk může obsahovat údaje, které nemá vidět každý uživatel. Mitigace: řešit oprávnění už při vyhledávání, ne až při zobrazení odpovědi.

Související pojmy

• Retrieval – vyhledání a načtení relevantních informací, které se modelu předají jako podklad pro odpověď.
• RAG – architektura, která kombinuje vyhledání relevantních informací s generováním odpovědi.
• Embedding – číselná reprezentace obsahu, která umožňuje porovnávat významovou podobnost textů nebo dokumentů.
• Vektorová databáze – databáze určená k ukládání embeddingů a hledání podobných vektorů.
• Kontextové okno – prostor, do kterého se modelu vejde dotaz, podklady a odpověď v jednom kroku.
• Token – základní jednotka textu nebo vstupu, se kterou jazykový model pracuje.
• Prompt – zadání nebo vstup, který model dostává od uživatele nebo systému.
• Prompt engineering – návrh zadání a instrukcí pro model tak, aby výstup odpovídal požadovanému cíli, formátu a omezením.
• Velký jazykový model (LLM) – model, který zpracovává a generuje text na základě vstupu, kontextu a naučených jazykových vzorů.
• OCR – technologie pro převod textu z obrázků, skenů nebo PDF dokumentů do strojově čitelné podoby.
• Multimodální modely – modely, které dokážou pracovat s více typy vstupů, například textem, obrazem, audiem nebo dokumenty.

Odkazy a zdroje

• Develop a RAG Solution – Chunking Phase – learn.microsoft.com – listopad 2025 – článek ukazuje, jak v RAG řešeních přemýšlet o velikosti chunků, překryvu a testování různých způsobů dělení dokumentů.
• Chunk documents in vector search – learn.microsoft.com – duben 2026 – návod popisuje chunking dokumentů pro vektorové vyhledávání, včetně práce s velikostí chunku, překryvem a zachováním návaznosti mezi částmi textu.
• Text splitter integrations – LangChain – docs.langchain.com – duben 2026 – dokumentace vysvětluje, jak text splittery rozdělují velké dokumenty na menší části, které se dají samostatně vyhledávat a vejdou se do kontextového okna modelu.
• How content chunking works for knowledge bases – docs.aws.amazon.com – duben 2026 – dokumentace Amazon Bedrock popisuje různé strategie chunkingu pro znalostní báze, například fixed-size, hierarchical a semantic chunking.
• Chunking Strategies for LLM Applications – pinecone.io – červen 2025 – praktický článek vysvětluje, proč se dlouhé texty v LLM aplikacích dělí na menší části a jak velikost chunků ovlivňuje vyhledávání a kvalitu odpovědí.
• Chunking for RAG: best practices – unstructured.io – červenec 2024 – článek rozebírá, proč je lepší dělit text podle smysluplných hranic a proč příliš velké chunky mohou zhoršit přesnost vyhledávání.
• Build advanced RAG systems – learn.microsoft.com – leden 2026 – dokumentace popisuje pokročilejší přístupy k RAG, včetně volby velikosti chunků, překryvu, sliding window a práce s okolním kontextem.