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 pasáž obsahuje dostatok kontextu pre správnu, zdrojmi podloženú odpoveď. Chunking je tak 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 a patrí medzi hlavné príčiny halucinácií.
• Najlepšia univerzálna voľba 2026: Hierarchický parent-child chunking, voliteľne v kombinácii s Contextual Retrieval (Anthropic: až -67 % chýb retrievalu s hybridným vyhľadávaním a re-rankingom).

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

V RAG pipeline sa každý zdrojový dokument rozdelí, každý chunk sa prevedie na vektor (embedding) a uloží do vektorovej databázy. Za behu systém vyhľadá chunky, ktoré sú najpodobnejšie otázke používateľa, a vloží ich jazykovému modelu do promptu. To znamená: čo nebolo správne rozdelené na chunky, sa vôbec nedá nájsť. A to, čo sa síce nájde, ale bolo vyrezané bez kontextu, uvedie model do omylu.

V praxi dominujú dva typy 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 neopraví ani ten najlepší re-ranking.

Prehľad šiestich stratégií chunkingu

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

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

Sentence-window je jeho variantom: embedduje sa a vyhľadáva na úrovni viet, do LLM sa však odovzdá okno z okolitých viet. Ide o jednoduchšieho predchodcu princípu parent-child.

Semantic chunking meria kosínusovú vzdialenosť medzi po sebe nasledujúcimi vetami a rez umiestni tam, kde sa obsahová súvislosť preruší (kosínusový drift). Pri obsahovo heterogénnych dokumentoch tak vznikajú koherentné chunky, indexovanie je však výpočtovo náročnejšie, pretože každú vetu treba 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 dostane generátor ako kontext. Pre dlhé reporty a technické manuály je táto stratégia často najlepšou voľbou.

Late chunking je novší prístup, ktorý obracia poradie: namiesto toho, aby sa text rozrezal pred embeddingom, najprv celý (dlhý) dokument spracuje long-context embedding model a až výsledné token embeddingy sa následne spoja (pooling) do vektorov chunkov. Každý vektor chunku tak v sebe nesie kontext celého dokumentu. Prístup sleduje rovnaký cieľ ako Contextual Retrieval, teda vyriešiť problém lost-in-the-chunks, no nepotrebuje ďalšie volanie LLM na každý chunk. Je však pomerne mladý, menej široko overený a vyžaduje embedding model schopný spracovať dlhý kontext. Podporovanú dĺžku kontextu a správanie poolingu si pred nasadením do produkcie over v aktuálnej dokumentácii poskytovateľa zvoleného modelu.

Okrem toho sa oplatí poznať dva ďalšie postupy: Propositional chunking rozkladá text na atomické výroky a hodí sa na veľmi presnú extrakciu faktov. Contextual chunking (pozri nižšie) vloží pred každý chunk vysvetľujúcu kontextovú hlavičku.

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

Kompromisy: 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 výsledky pri bodových faktografických otázkach, riskujú však 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é množiny top-k odovzdané modelu to ešte zhoršujú. Preto sa odporúča po retrievale zúžiť výsledky pomocou re-rankera na top_k = 5-10.

Overlap (prekrývajúce sa tokeny medzi susednými chunkmi) zabraňuje tomu, aby sa myšlienka pretrhla práve na hranici rezu. Osvedčenou orientačnou hodnotou je 10-20 % veľkosti chunku. Väčší overlap zvyšuje redundanciu, nároky na úložisko a náklady na indexovanie bez toho, aby úmerne zvyšoval kvalitu.

Faktor, ktorý sa pri korpusoch z regiónu DACH často podceňuje: nemecké kompozitá ako „Datenschutz-Folgenabschätzung“ vytvárajú podľa tokenizera (BPE/SentencePiece) výrazne viac tokenov ako ich anglický ekvivalent. Ako orientačné 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 prenesie menej vecného obsahu ako v angličtine.

Konkrétny príklad s číslami

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

1. Parsing: layout-aware parserom, napríklad Docling alebo Unstructured, aby sa zachovali tabuľky, zoznamy a nadpisy.
2. Chunking: parent-child. Parent chunky s približne 1 500 tokenmi (celé oddiely), child chunky s približne 300 tokenmi a 15 % overlapom.
3. Cieľ embeddingu: child chunky; do LLM ide príslušný parent.
4. Voliteľná kontextová hlavička: pre každý chunk krátka kontextová veta vygenerovaná LLM pred embeddingom. Podľa spoločnosti Anthropic (september 2024) klesá chybovosť top-20 retrievalu so samotnými contextual embeddingmi z 5,7 % na 3,7 % (-35 %). V kombinácii s Contextual BM25 (hybridné vyhľadávanie) klesá na 2,9 % (-49 %), s dodatočným re-rankingom na 1,9 % (-67 %). Jednorazové náklady na kontextové vety Anthropic vyčísľuje na približne 1,02 USD na 1 mil. dokumentových tokenov (Claude 3 Haiku s prompt cachingom, 800-tokenové chunky, 8 000-tokenové dokumenty, ceny zo septembra 2024). Pri 300-tokenových chunkoch ako v tomto príklade je hodnota vyššia, pretože na milión tokenov pripadá viac chunkov, ktoré potrebujú kontextovú vetu.

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("Stručne zaraď tento chunk do kontextu celého dokumentu.", document=document, chunk=c.text) # voliteľné
index.upsert(embed(c.context + c.text), parent_ref=p.id)
```

Ako otestovať správnu stratégiu

O chunkingu sa nerozhoduje odhadom, ale meraním. Postup:

• Vytvor goldset: 50-200 reálnych otázok používateľov, každú s anotovanou správnou zdrojovou pasážou. Bez goldsetu pomôže LLM-as-judge (RAGAS reference-free) alebo synteticky vygenerovaná testovacia sada.
• Naindexuj varianty: ten istý korpus rozdeľ na chunky viackrát, napríklad Fixed-512, Recursive-300, Semantic a Parent-Child, pri inak identickej pipeline.
• Meraj pomocou RAGAS: ústrednými metrikami evaluácie RAG pomocou RAGAS sú Context Precision a Context Recall (trafí retrieval správne pasáže?), ako aj Faithfulness a Answer Relevancy (opiera sa odpoveď naozaj o kontext?).
• A/B v produkcii: variant, ktorý v offline teste vyšiel najlepšie, nasaď paralelne s existujúcim a sleduj reálne signály (kliky, spätnú väzbu používateľov).

Dôležité: ak sa zmení embedding model, je potrebná úplná reindexácia, pretože embeddingy rôznych modelov nie sú porovnateľné. Indexy preto označ reťazcom verzie.

Pre agentúry a B2B rozhodovateľov

Chunking nie je detail nastavenia, ktorý raz nakonfiguruješ a zabudneš, ale parameter s najväčším vplyvom na kvalitu odpovedí tvojho RAG systému, a tým aj na dôveru, ktorú mu prejavujú zákazníci a zamestnanci. Kto tu začne s naivným fixed-size chunkingom, zaplatí neskôr halucináciami, eskaláciami na podpore a drahými dodatočnými úpravami. Ako agentúra Blck Alpaca (Viedeň) navrhujeme a vyhodnocujeme RAG pipeline pre firmy v regióne DACH merateľne podľa metrík RAGAS, vrátane tokenizácie nemčiny, hostingu v EÚ podľa požiadaviek GDPR a stratégie chunkingu, ktorá zodpovedá tvojim dokumentom a otázkam. Ozvi sa nám skôr, než pôjdeš do produkcie, a nie až vtedy, keď treba opravovať.