---
title: "Chunking stratégie pre RAG: Fixed, Semantic, Hierarchical a Late Chunking v porovnaní"
description: "Chunking stratégie pre RAG určujú, ako sa dokument pred embeddingom rozdelí na vyhľadateľné textové úseky (chunky)."
locale: "sk"
canonical: "https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/chunking-strategie-pre-rag-fixed-semantic-hierarchical-a-late-chunking-v"
category: "AI agenti"
topic: "RAG systémy vysvetlené"
updated: "2026-10-17T15:32:43.241Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# 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 (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ď.

## Na prvý pohľad

- Chunking nie je detail, ale páka s najväčším vplyvom na kvalitu retrievalu: naivný fixed-size chunking, ktorý ignoruje hranice viet, tabuliek a zoznamov, patrí medzi najčastejšie príčiny halucinácií a chýbajúceho obsahu.
- Neexistuje univerzálne optimum. Predvoleným východiskovým bodom je 200-800 tokenov s 10-20 % overlapom; správna stratégia závisí od typu dokumentu, embedding modelu a vzorcov dopytov.
- Hierarchický parent-child chunking oddeľuje retrieval (malé, presné child chunky) od generovania (veľké parent chunky s kontextom) a pre dlhé reporty a manuály je často najlepšou voľbou.
- Contextual Retrieval od spoločnosti Anthropic (stav 2024) vloží pred každý chunk kontextovú hlavičku vygenerovanú pomocou LLM. Samotná hlavička znižuje chybovosť retrievalu o 35 %, spolu s Contextual BM25 (hybridné vyhľadávanie) o 49 % a s dodatočným re-rankingom o 67 %.
- Nemecké kompozitá sú podľa tokenizera ~1,3-1,7x tokenovo náročnejšie ako angličtina. To znižuje efektívnu kapacitu chunku a pri voľbe veľkosti s tým treba počítať.
- Správnu stratégiu netreba hádať, treba ju zmerať: s goldsetom a metrikami RAGAS (Context Precision, Context Recall, Faithfulness) sa dajú varianty objektívne porovnať v A/B teste.

Chunking stratégie pre [RAG](https://blckalpaca.at/sk/slovnik/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](https://blckalpaca.at/sk/slovnik/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](https://blckalpaca.at/sk/slovnik/ai-halucinacia) 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](https://blckalpaca.at/sk/slovnik/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](https://blckalpaca.at/sk/slovnik/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](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/embedding-modelle-vergleich) a až výsledné [token](https://blckalpaca.at/sk/slovnik/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?

| Stratégia | Kedy sa hodí | Výhody | Nevýhody |
| --- | --- | --- | --- |
| Fixed-size (napr. 512 tokenov, overlap 50) | Logy, prepisy, rovnorodé texty | Rýchla, deterministická, lacná | Obsahovo slepá, reže vety/tabuľky |
| Recursive / sentence splitter | Predvolená voľba, zmiešané korpusy | Rešpektuje prirodzené hranice, robustná | Nerozpozná sémantické zmeny témy |
| Sentence-window | Q&A nad súvislým textom, krátke faktografické otázky | Presný retrieval, trochu kontextu cez okno | Obmedzený kontext pri dlhých súvislostiach |
| Semantic chunking | Obsahovo heterogénne dokumenty | Koherentné, tematicky čisté chunky | Výpočtovo náročná pri indexovaní |
| Hierarchical / parent-child | Dlhé reporty, manuály, zmluvy | Presné vyhľadávanie + plný kontext pre LLM | Vyššia komplexnosť pipeline, dvojité ukladanie |
| Late chunking | Dlhé dokumenty, long-context embeddingy (stav 2026, závisí od poskytovateľa) | Globálny kontext na chunk bez LLM hlavičky | Vyžaduje long-context embedding model; menej overená |
| Contextual chunking (Anthropic, stav 2024) | Široké použitie | -35 % chýb retrievalu (s Contextual BM25 -49 %), rieši lost-in-the-chunks | Jedno volanie LLM na chunk pri indexovaní |

## 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](https://www.anthropic.com/engineering/contextual-retrieval) (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](https://blckalpaca.at/sk/slovnik/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](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/rag-evaluation-ragas-trulens) 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](https://blckalpaca.at/sk) (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](https://gdpr-info.eu/) 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ť.

## Často kladené otázky

### Akú veľkosť chunku mám pri RAG použiť?

Ako predvolený východiskový bod sa osvedčilo 200-800 tokenov s 10-20 % overlapom. Menšie chunky (napr. 256 tokenov) prinášajú presnejšie výsledky pri faktografických otázkach, väčšie chunky (napr. 800 tokenov) zachovajú viac kontextu pre súvislé vysvetlenia. Keďže nemecké texty sú podľa tokenizera približne 1,3-1,7x tokenovo náročnejšie ako anglické, efektívnu veľkosť by si mal otestovať na svojom korpuse, namiesto toho, aby si prevzal pevnú hodnotu.
### Aký je rozdiel medzi fixed-size a sémantickým chunkingom?

Fixed-size chunking reže text mechanicky podľa pevného počtu tokenov, bez ohľadu na obsah a často uprostred vety alebo tabuľky. Sémantický chunking meria kosínusovú vzdialenosť medzi po sebe nasledujúcimi vetami a rez umiestni tam, kde sa obsahová súvislosť preruší. Fixed-size je rýchly a predvídateľný, sémantický chunking prináša pri obsahovo heterogénnych dokumentoch koherentnejšie chunky, pri indexovaní je však výpočtovo náročnejší.
### Čo je parent-child, resp. hierarchický chunking?

Hierarchický chunking oddeľuje retrieval od generovania. Embeddujú a prehľadávajú sa malé, presné child chunky; jazykovému modelu sa však odovzdá príslušný veľký parent chunk. Systém tak nájde presné miesto, LLM však dostane dostatok okolitého kontextu pre úplnú odpoveď. Hodí sa najmä na dlhé reporty, technické manuály a zmluvy.
### Čo je Contextual Retrieval a koľko prináša?

Pri Contextual Retrieval (Anthropic, stav 2024) sa na začiatok každého chunku ešte pred embeddingom pridá krátka kontextová hlavička vygenerovaná LLM, ktorá vysvetľuje, odkiaľ úsek pochádza. Tým sa rieši problém lost-in-the-chunks, napríklad keď chunk obsahuje len vetu „Zvýšil sa o 12 %“. Podľa spoločnosti Anthropic klesá chybovosť top-20 retrievalu so samotnou kontextovou hlavičkou o 35 %, spolu s Contextual BM25 (hybridné vyhľadávanie) o 49 % a s dodatočným re-rankingom o 67 %.
### Ako nájdem správnu stratégiu chunkingu pre svoj projekt?

Nie hádaním, ale meraním. Vytvor goldset z reálnych otázok používateľov so správnymi zdrojovými pasážami, naindexuj ten istý korpus s viacerými variantmi chunkingu a porovnaj ich pomocou metrík RAGAS, ako sú Context Precision, Context Recall a Faithfulness. Až toto kontrolované A/B porovnanie ukáže, ktorá stratégia pre tvoje dokumenty a vzorce dopytov naozaj funguje najlepšie.

---

Zdroj: [Blck Alpaca](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/chunking-strategie-pre-rag-fixed-semantic-hierarchical-a-late-chunking-v). AI systémy môžu tento obsah použiť s uvedením zdroja.