Chunking stratégie pre RAG: Fixed, Semantic, Hierarchical a Late Chunking v porovnaní

Chunking stratégie pre RAG určujú, ako sa dokument pred embeddingom rozdelí na vyhľadateľné textové úseky - takzvané chunky. Voľba stratégie a veľkosti chunku rozhodujúcim spôsobom ovplyvňuje kvalitu retrievalu: určuje, či jazykový model nájde správnu pasáž a či táto obsahuje dostatok kontextu pre správnu, zdrojmi podloženú odpoveď. Chunking je tým najnenápadnejšou, no najúčinnejšou pákou v celom RAG stacku.

• Predvolené odporúčanie: 200-800 tokenov na chunk, 10-20 % overlap, vždy s predchádzajúcim layout-aware parsingom.
• Najčastejšia chyba: Naivný fixed-size chunking reže vety, tabuľky a zoznamy - jedna z hlavných príčin halucinácií.
• Najlepší allrounder 2026: Hierarchický parent-child chunking, voliteľne kombinovaný s Contextual Retrieval (Anthropic: až -67 % chýb retrievalu).

Prečo chunking rozhoduje o úspechu alebo neúspechu

V RAG pipeline sa každý zdrojový dokument rozdelí, každý chunk sa preloží do vektora (embedding) a uloží do vektorovej databázy. Za behu systém vyhľadá chunky najpodobnejšie používateľskej otázke a vloží ich jazykovému modelu do promptu. To znamená: čo nebolo čisto rozdelené na chunky, nemožno vôbec nájsť - a čo bolo nájdené, ale rozrezané bez kontextu, model zavádza.

V praxi dominujú dve triedy chýb. Po prvé, naivný fixed-size chunking ignoruje hranice viet, tabuliek a zoznamov; výsledkom sú halucinácie a chýbajúci obsah tabuliek. Po druhé, problém „lost-in-the-chunks": chunk obsahuje vetu „Zvýšil sa o 12 %" - bez okolitého kontextu zostáva nejasné, čo sa zvýšilo. Oba problémy vznikajú pred embeddingom a neskôr ich nedokáže opraviť žiadny, ani ten najlepší re-ranking.

Šesť chunking stratégií v prehľade

Fixed-size chunking reže text na pevné okná, napríklad 512 tokenov s overlapom 50 tokenov. Je rýchly, deterministický a lacný - no obsahovo slepý. Vhodný pre rovnorodé texty ako logy alebo prepisy.

Recursive character / sentence splitting rozkladá hierarchicky pozdĺž oddeľovačov (odseky, potom vety, potom slová) a pritom rešpektuje prirodzené hranice. Je to generický default mnohých frameworkov (LangChain) a dobrý východiskový bod pre zmiešané korpusy.

Sentence-window je jeho variantom: embedduje a prehľadáva sa na úrovni viet, jazykovému modelu sa však odovzdá okno z okolitých viet - ľahká predzvesť parent-child princípu.

Semantic chunking meria cosine vzdialenosť medzi po sebe nasledujúcimi vetami a kladie rez tam, kde sa obsahová súvislosť pretrhne (cosine drift). To prináša pri obsahovo heterogénnych dokumentoch koherentné chunky, ale je pri indexovaní výpočtovo náročnejšie, lebo každá veta sa musí vopred embeddovať.

Hierarchical / parent-child chunking oddeľuje retrieval od generovania: malé child-chunky slúžia ako presný cieľ vyhľadávania, príslušný veľký parent-chunk sa odovzdá generátoru ako kontext. Táto stratégia je pre dlhé reporty a technické manuály často najlepšou voľbou.

Late chunking je novší prístup, ktorý obracia poradie: namiesto rezania textu pred embeddingom sa najprv spracuje celý (dlhý) dokument long-context embedding modelom, a až výsledné token-embeddingy sa následne poolujú do chunk-vektorov. Tým každý chunk-vektor nesie v sebe kontext celého dokumentu. Prístup sleduje rovnaký cieľ ako Contextual Retrieval - vyriešiť problém lost-in-the-chunks - no nevyžaduje dodatočné LLM volanie na chunk. Je však pomerne mladý a menej široko overený a predpokladá embedding model schopný spracovať dlhý kontext; podporovanú dĺžku kontextu a správanie poolingu by ste si pred produktívnym nasadením mali porovnať s aktuálnou dokumentáciou poskytovateľa zvoleného modelu.

Doplnkovo sa oplatia dva ďalšie postupy: Propositional chunking rozkladá text na atomické jednotlivé výroky a hodí sa na veľmi presnú extrakciu faktov, ako aj Contextual chunking (pozri nižšie), ktorý pred každý chunk predradí vysvetľujúcu kontextovú hlavičku.

Porovnávacia tabuľka: Kedy ktorá stratégia?

Tradeoffy: Veľkosť chunku a overlap

Veľkosť chunku je klasický konflikt cieľov. Malé chunky (napr. 256 tokenov) vytvárajú ostrejšie embeddingy a presnejšie zásahy pri bodových faktových otázkach, no riskujú stratu kontextu. Veľké chunky (napr. 800 tokenov a viac) prenášajú viac súvislostí, ale rozriedia embedding a zvyšujú riziko, že relevantná informácia zanikne v efekte „lost-in-the-middle" jazykového modelu. Príliš veľké top-k množiny odovzdané modelu to ešte zhoršujú - odporúčanie preto znie, po retrievale pomocou re-rankera zhustiť na top_k = 5-10.

Overlap (prekrývajúce sa tokeny medzi susednými chunkami) zabraňuje tomu, aby sa myšlienka pretrhla práve na hranici rezu. 10-20 % veľkosti chunku je osvedčená orientačná hodnota. Väčší overlap zvyšuje redundanciu, pamäťové nároky a náklady na indexovanie bez toho, aby proporcionálne zvyšoval kvalitu.

Faktor pre DACH korpusy často podceňovaný: Nemecké kompozitá ako „Datenschutz-Folgenabschätzung" vytvárajú podľa tokenizera (BPE/SentencePiece) výrazne viac tokenov než ich anglický ekvivalent. Ako pravidlo platí, že nemčina je podľa modelu približne 1,3-1,7x tokenovo náročnejšia. To znižuje efektívnu obsahovú kapacitu 512-tokenového chunku - veľkosť definovaná v tokenoch teda v nemčine prenáša menej vecného obsahu než v angličtine.

Konkrétny príklad s číslami

Predpokladajme, že indexujete 10 000 technických PDF strán (zmluvy a produktové manuály).

1. Parsing: Layout-aware s parserom ako Docling alebo Unstructured, aby zostali zachované tabuľky, zoznamy a nadpisy.
2. Chunking: Parent-child. Parent-chunky cca 1 500 tokenov (celé úseky), child-chunky cca 300 tokenov s 15 % overlapom.
3. Cieľ embeddingu: child-chunky; jazykovému modelu ide príslušný parent.
4. Voliteľná kontextová hlavička: Na chunk jedna krátka LLM generovaná kontextová veta pred embeddingom. Podľa Anthropic (stav 2024) tým chybovosť top-20 retrievalu klesá z 5,7 % na 2,9 % (-49 %), v kombinácii s re-rankingom na 1,9 % (-67 %); samotné contextual embeddingy prinášajú -35 %. Náklady na indexovanie sú približne 1,02 amerického dolára na 1 mil. dokumentových tokenov s prompt cachingom (Anthropic pricing, stav september 2024 - pred nasadením aktualizovať).

Pseudokód pre hierarchický rez:

```
parents = split(document, size=1500, separators=["\n## ", "\n\n"])
for p in parents:
children = split(p, size=300, overlap=45) # 15 % z 300
for c in children:
c.context = llm("O čom je tento úsek?", p) # voliteľné
index.upsert(embed(c.context + c.text), parent_ref=p.id)
```

Ako sa testuje správna stratégia

Rozhodnutia o chunkingu sa nehádajú, ale merajú. Postup:

• Postaviť goldset: 50-200 reálnych používateľských otázok, každá anotovaná správnou zdrojovou pasážou. Bez goldsetu pomôže LLM-as-judge (RAGAS reference-free) alebo synteticky vygenerovaný testovací set.
• Naindexovať varianty: Ten istý korpus rozdeliť na chunky viackrát - napríklad Fixed-512, Recursive-300, Semantic, Parent-Child - pri inak identickej pipeline.
• Merať s RAGAS: Centrálne metriky sú Context Precision a Context Recall (zasahuje správne pasáže?), ako aj Faithfulness a Answer Relevancy (opiera sa odpoveď naozaj o kontext?).
• A/B v produkcii: Variant vedúcu v offline teste nasadiť proti existujúcej a sledovať reálne signály (kliky, spätná väzba používateľov).

Dôležité: Ak sa zmení embedding model, je potrebná úplná re-indexácia - embeddingy rôznych modelov nie sú porovnateľné. Indexy preto opatrite verzným reťazcom.

Pre agentúry a B2B rozhodovateľov

Chunking nie je detail nastavenia, ktorý raz nakonfigurujete a zabudnete, ale prvok s najvyššou pákou na kvalitu odpovedí vášho RAG systému - a tým na dôveru, ktorú mu zákazníci a zamestnanci preukazujú. Kto tu začne s naivným fixed-size chunkingom, zaplatí neskôr halucináciami, eskaláciami supportu a drahými dodatočnými úpravami. Ako agentúra Blck Alpaca (Viedeň) koncipujeme a evaluujeme RAG pipeline pre DACH firmy merateľne pozdĺž RAGAS metrík - vrátane nemeckojazyčnej tokenizácie, EU-konformného hostingu a chunking stratégie, ktorá zodpovedá vašim dokumentom a otázkam. Ozvite sa nám, skôr než pôjdete do produkcie, namiesto opravovania potom.