Než dokumenty zapojíš do RAG, musíš je rozsekat na kousky (chunky). Zní to jako nudná příprava, ale je to místo, kde se RAG nejčastěji láme: špatně nasekané dokumenty znamenají, že vyhledávání najde půlku odpovědi, model si domyslí zbytek a ty pak marně ladíš prompty.
Proč vůbec sekat
Dva důvody:
- Do kontextu se celý dokument nevejde a i kdyby, platil bys ho celý při každém dotazu.
- Hledání funguje líp na kratších úsecích. Vektor celé stostránkové smlouvy je průměr všeho, takže nesedí na nic konkrétního. Vektor jednoho odstavce má jasné téma.
Jak velký má chunk být
Neexistuje jedno správné číslo, ale existuje rozumné výchozí:
| Typ obsahu | Velikost chunku | Překryv |
|---|---|---|
| FAQ, krátké odpovědi | 200–400 tokenů | malý nebo žádný |
| Dokumentace, články | 400–800 tokenů | 10–15 % |
| Smlouvy, normy | 600–1000 tokenů | 15–20 % |
| Kód | podle funkcí/tříd, ne podle délky | žádný |
Překryv (overlap) znamená, že se konec jednoho chunku zopakuje na začátku dalšího. Zabraňuje tomu, aby se odpověď rozpůlila přesně na hraně:
chunk 1: "...Reklamaci lze uplatnit do 14 dnů od převzetí. Zákazník musí"
chunk 2: "Zákazník musí doložit doklad o koupi a zboží zaslat na adresu..."
↑ překryv drží větu pohromadě
Sekej podle struktury, ne po znacích
Nejhorší (a bohužel nejběžnější) způsob je rozsekat text po 1000 znacích. Rozřízne to věty, tabulky i kód. Lepší postup, odshora dolů:
- Podle nadpisů, kapitola nebo podkapitola je přirozený celek.
- Podle odstavců, když je sekce moc velká.
- Podle vět, až jako poslední záchrana uvnitř dlouhého odstavce.
U markdownu a HTML máš strukturu zadarmo (nadpisy, seznamy). U PDF budeš muset text nejdřív vytáhnout a počítej s tím, že sloupce, hlavičky a patičky ti ho zamotají.
⚠️ Tabulky a kód nesekej doprostřed. Rozpůlená tabulka je pro model horší než žádná, protože v ní nevidí hlavičku a přiřadí čísla ke špatnému sloupci.
Metadata jsou půlka úspěchu
Ke každému chunku ulož kontext, ze kterého pochází:
{
"text": "Reklamaci lze uplatnit do 14 dnů...",
"doc_id": "obchodni-podminky-2026",
"nadpis": "5.2 Reklamace",
"url": "https://…/podminky#reklamace",
"platnost_od": "2026-01-01",
"verze": 3
}
Metadata ti umožní:
- filtrovat (jen platné dokumenty, jen tenhle produkt, jen tenhle jazyk),
- citovat zdroj v odpovědi,
- poznat zastaralé záznamy a promazat je.
Osvědčuje se taky přidat nadpis přímo do textu chunku. Úryvek „lze uplatnit do 14 dnů“ sám o sobě nedává smysl; s prefixem „Obchodní podmínky → 5.2 Reklamace:“ ano a vyhledávání ho pak najde spolehlivěji.
Časté chyby
- Chunk bez kontextu. Úryvek plný zájmen („to platí i pro ně“) je bez okolí nepoužitelný.
- Jeden chunk = jeden dokument. U dlouhých dokumentů zaručeně nefunguje.
- Zapomenuté přegenerování. Když změníš strategii sekání nebo embedding model, musíš znovu vytvořit celý index.
- Duplicity. Tentýž text v deseti verzích dokumentu zaplní výsledky hledání a vytlačí relevantní obsah.
Cvičení
- Máš dokumentaci, kde jsou důležité tabulky s parametry. Co se stane, když ji rozsekáš po pevných 500 znacích?
- Proč se k chunku připojuje nadpis sekce, ze které pochází?
Náčrt řešení: rozbal, až si cvičení zkusíš sám
- Tabulka se rozpadne v půlce a obě části ztratí smysl. Horní kus bude mít hlavičku bez hodnot, dolní hodnoty bez hlavičky, takže ani jeden nebude odpovídat na dotaz typu „jaký je limit u tarifu Standard“. Pevná délka ignoruje strukturu, což u souvislé prózy projde, ale u tabulek, kódu a seznamů je to zaručený způsob, jak si rozbít retrieval. Sekej podle nadpisů a strukturní bloky nech vcelku, i za cenu nerovnoměrné velikosti chunků.
- Protože chunk vytržený z textu často ztratí téma. Věta „Šetří se výpočet, ne paměť“ neobsahuje nic, podle čeho by šla najít, ale s nadpisem „Mixture of Experts“ ano. Nadpis je nejlevnější dostupný kontext a pomůže fulltextu i embeddingu. Vyzkoušené v projektu.
Shrnutí
- Sekej podle struktury (nadpisy, odstavce), ne po pevném počtu znaků.
- Rozumné výchozí: 400–800 tokenů s 10–15 % překryvem.
- Ke každému chunku ulož metadata a nadpis vlož i do textu.
- Změna strategie nebo embedding modelu = přegenerovat celý index.
Proč se používá překryv mezi chunky?
Aby se informace nerozpůlila přesně na hranici dvou kousků. Když se konec jednoho chunku zopakuje na začátku dalšího, zůstane souvislá věta nebo myšlenka v aspoň jednom z nich celá a vyhledávání ji najde.
Vyhledávání vrací úryvky, které samy o sobě nedávají smysl („to platí i na ně“). Co s tím?
Chybí jim kontext. Řeší se to sekáním podle struktury místo po znacích a připojením nadpisu (cesty dokumentem) přímo do textu chunku, případně větším překryvem nebo vrácením sousedních chunků k nalezenému.
Změnil jsi velikost chunků z 300 na 800 tokenů. Stačí naindexovat nové dokumenty?
Ne. Index by pak obsahoval nesourodou směs starých a nových kousků, což zhorší kvalitu hledání. Při změně strategie sekání (stejně jako při změně embedding modelu) se přegeneruje celý index.