RAG chunking stratégiák 2026 — melyiket válaszd és miért?

Miért kritikus a chunking a RAG minőségéhez?

A RAG pipeline három fő komponensből áll: dokumentum-indexelés, szemantikus visszakeresés és válasz-generálás. A chunking az indexelési fázis kulcslépése — és ez az egyetlen pont, ahol a legtöbb rendszer csendben elcsúszik. A rossz chunking nem dob hibát, nem jelez figyelmeztetést: egyszerűen silányabb kontextust ad a keresőnek, a kereső rosszabb dokumentumrészletet ad az LLM-nek, és az LLM egy meggyőző, de pontatlan választ generál.

A probléma lényege az egybefüggő kontextus szétszakítása. Ha egy 600 tokenes bekezdést a chunker kettévág a 512. tokennél, az egyik chunk elveszíti a konklúziót, a másik elveszíti az előzményt. A vektorkeresés mindkét chunk-ot alacsonyabb pontossággal tudja csak visszahozni, mert egyik sem teljes szemantikai egység.

A saját Corpus V2 rendszeremben (1,48 millió vektorizált szövegtöredék, Qdrant) pontosan ezt tanultam meg: a rendszer első verziójában fix méretű, 512 tokenes chunkolást alkalmaztam. A RAGAS Context Precision 0,61 volt. Parent-child chunking bevezetése után — azonos dokumentumállomány, azonos embedding modell — 0,84-re emelkedett. Az LLM ugyanaz maradt. A különbséget kizárólag a chunking stratégia tette.

A 4 fő chunking stratégia összehasonlítása

Mielőtt belemennénk a részletekbe, a négy stratégia gyors összehasonlítása egy helyen — döntési alapnak:

Fix méretű chunking — paraméterek és implementáció

A fix méretű chunking a legegyszerűbb és leggyakrabban alkalmazott stratégia. A dokumentumot meghatározott token- vagy karakterszámonként darabolja — opcionálisan átfedéssel (overlap), hogy az egységek határán ne vágjon el összefüggő szövegegységeket.

A két kulcsparaméter: chunk_size (hány token kerüljön egy chunk-ba) és chunk_overlap (hány tokennyi átfedés legyen a szomszédos chunk-ok között). Az overlap célja, hogy egy mondat közepén ne szűnjön meg a kontextus: a következő chunk visszanéz az előző végébe.

Ajánlott chunk_size értékek tartalom-típusonként

LangChain RecursiveCharacterTextSplitter — példa

from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.document_loaders import PyPDFLoader

# Dokumentum betöltése
loader = PyPDFLoader("vallalati_kezikonyv.pdf")
documents = loader.load()

# Chunker inicializálása
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,         # token-méret (kb. karakterben: 512 * 4 = ~2048 karakter)
    chunk_overlap=51,       # ~10% overlap
    length_function=len,
    separators=[            # hierarchikus elválasztók — előbb bekezdés, aztán mondat, aztán szó
        "\n\n",           # bekezdéshatár (legjobb vágási pont)
        "\n",              # sorvég
        " ",                # szóhatár
        ""                  # karakter-szintű fallback
    ]
)

# Chunkolás
chunks = text_splitter.split_documents(documents)

print(f"Dokumentumok száma: {len(documents)}")
print(f"Chunk-ok száma:     {len(chunks)}")
print(f"Átlagos chunk méret: {sum(len(c.page_content) for c in chunks) / len(chunks):.0f} karakter")

# Qdrant-ba töltés (feltéve: embedder már inicializálva)
from langchain.vectorstores import Qdrant
vectorstore = Qdrant.from_documents(
    chunks,
    embedding=embedder,
    url="http://localhost:6333",
    collection_name="corpus_fixed"
)

Szemantikus chunking — hogyan működik?

A szemantikus chunking nem token-számon, hanem tartalmi határokon vágja a szöveget. Az NLP-modell mondatonként vektorizálja a szöveget, majd cosine similarity-vel megméri, mennyire hasonlóak az egymást követő mondatok. Ahol az összehasonlítás eredménye egy meghatározott küszöbérték alá esik, ott a chunker éles témaboundary-t jelez — és ott vágja ketté a szöveget.

A folyamat lépései:

1. Mondatokra bontás: A szöveget mondatonként szegmentálják (NLTK sent_tokenize vagy spaCy).
2. Mondatvektorizálás: Minden mondathoz embedding-vektor készül az embedder modellel.
3. Cosine similarity számítás: Minden egymást követő mondatpár hasonlóságát mérik.
4. Küszöb meghatározása: Ahol a similarity-érték egy threshold (pl. 0.75) alá esik, ott témaváltást jelez a rendszer.
5. Vágás: A témaváltás-pontoknál vágja a szöveget — természetes tartalmi határokon.

LangChain SemanticChunker — példa

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings
# vagy helyi modellhez:
# from langchain_community.embeddings import HuggingFaceEmbeddings

# Embedder inicializálása (szemantikus chunkernek is kell)
embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
# helyi alternatíva:
# embeddings = HuggingFaceEmbeddings(model_name="Qwen/Qwen3-Embedding-8B")

# SemanticChunker inicializálása
# breakpoint_threshold_type lehetséges értékei:
#   "percentile"        — az összes similarity-pont X. percentilise alatt vág
#   "standard_deviation" — az átlag mínusz N szórás alatt vág
#   "interquartile"     — IQR-alapú outlier detekció
text_splitter = SemanticChunker(
    embeddings=embeddings,
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=85  # a 85. percentilis alatti hasonlóságnál vág
)

# Szöveg betöltése és chunkolása
with open("kutatasi_riport.txt", "r", encoding="utf-8") as f:
    raw_text = f.read()

chunks = text_splitter.create_documents([raw_text])

print(f"Szemantikus chunk-ok száma: {len(chunks)}")
print(f"Min chunk méret: {min(len(c.page_content) for c in chunks)} karakter")
print(f"Max chunk méret: {max(len(c.page_content) for c in chunks)} karakter")
print(f"Átlag chunk méret: {sum(len(c.page_content) for c in chunks) / len(chunks):.0f} karakter")

A breakpoint_threshold_amount hangolása a legfontosabb lépés: ha túl alacsony, sok apró chunk keletkezik (szétszabdalt kontextus); ha túl magas, kevés nagy chunk (túl tág visszakeresés). Az optimális érték dokumentumtípusonként eltér — ajánlott 30–50 dokumentumon RAGAS Context Precision mérésével kalibrálni.

Parent-child chunking — a hibrid megközelítés

A parent-child chunking a legtöbb vállalati RAG esetben a legjobban teljesítő stratégia, mert egyszerre oldja meg a visszakeresés pontosságát és a kontextus-gazdagságát — amelyek egymással versenyeznek a többi stratégiában.

Az architektúra logikája: small leaf chunk (256 token) → pontos szemantikus visszakeresés; nagy parent chunk (1024–2048 token) → gazdag kontextus az LLM-nek. A retrieval a leaf chunk vektorán keres, de a generáláshoz a teljes parent chunk szövegét adja a modellnek.

Architektúra — hogyan épül fel

A parent chunk nem kerül közvetlenül a vektoradatbázisba — csak a leaf chunk-ok vektorizálódnak. A parent szövegét egy dokumentumtárban (Document Store) tartja a pipeline, és a leaf-match metadata alapján hívja elő. LangChain-ben ez az InMemoryStore vagy RedisDocumentStore; LlamaIndex-ben a SimpleDocumentStore.

LlamaIndex HierarchicalNodeParser — példa

from llama_index.core import SimpleDirectoryReader, VectorStoreIndex
from llama_index.core.node_parser import HierarchicalNodeParser, get_leaf_nodes
from llama_index.core.storage.docstore import SimpleDocumentStore
from llama_index.core import StorageContext

# Dokumentumok betöltése
documents = SimpleDirectoryReader("./docs/").load_data()

# HierarchicalNodeParser: 3 szint
# chunk_sizes: [2048, 512, 128]
#   → 2048 token = root (legfelső szint)
#   → 512 token  = parent
#   → 128 token  = leaf (legalsó szint, ez kerül a vektoradatbázisba)
node_parser = HierarchicalNodeParser.from_defaults(
    chunk_sizes=[2048, 512, 128]
)

# Összes node generálása (mindhárom szint)
nodes = node_parser.get_nodes_from_documents(documents)

# Leaf node-ok kiemelése (ezek kerülnek a vektoradatbázisba)
leaf_nodes = get_leaf_nodes(nodes)

print(f"Összes node:  {len(nodes)}")
print(f"Leaf node-ok: {len(leaf_nodes)}")

# Document store feltöltése (az összes node — parent + leaf — tárolása)
docstore = SimpleDocumentStore()
docstore.add_documents(nodes)

storage_context = StorageContext.from_defaults(docstore=docstore)

# Index létrehozása csak a leaf node-okból (vektorizálás)
index = VectorStoreIndex(
    leaf_nodes,
    storage_context=storage_context,
    show_progress=True
)

# AutoMergingRetriever: leaf visszakeresés, parent kontextus visszaadás
from llama_index.core.retrievers import AutoMergingRetriever
base_retriever = index.as_retriever(similarity_top_k=6)
retriever = AutoMergingRetriever(
    base_retriever,
    storage_context,
    verbose=True,
    simple_ratio_thresh=0.3   # ha a leaf-ek >30%-a ugyanabból a parent-ből, merge-el
)

# Lekérdezés
from llama_index.core.query_engine import RetrieverQueryEngine
query_engine = RetrieverQueryEngine.from_args(retriever)
response = query_engine.query("Milyen dokumentumok szükségesek a szabadság-igényléshez?")
print(response)

Chunk-méret benchmarkok és RAGAS mérés

A chunking stratégia kiválasztása nem lehet csak elméleti — mindig mérni kell a konkrét dokumentumállományon. A RAGAS keretrendszer (ragas.io) a négy legfontosabb retrieval és generálási metrikát automatizáltan méri kérdés-válasz párok alapján.

A mérés menete: (1) összeállítasz 30–50 kérdés-válasz párt a dokumentumokból, (2) lefuttatod a RAG pipeline-t mindhárom chunking stratégiával, (3) a RAGAS kiszámolja a metrikákat, (4) az eredmény alapján döntesz.

Stratégiák összehasonlítása — jellemző benchmark-értékek

A latency-különbség szemantikus és fix méretű között jellemzően az indexelési fázisban keletkezik (az embedding a vágási döntéshez is szükséges), nem a retrieval-nél. A production query latency a legtöbb esetben azonos vagy hasonló.

Implementációs döntési fa

A következő kérdéssorozat segít kiválasztani a megfelelő chunking stratégiát a konkrét felhasználási esethez. Haladj végig sorban — az első egyező feltételnél megvan az ajánlott stratégia.

• 1️⃣

  A dokumentumok rövidek és egységes szerkezetűek? (FAQ, termékleírás, bullet-pont listák, <500 szó)

  → Fix méretű, 256 token, 10% overlap. Gyors, egyszerű, jól teljesít homogén, rövid dokumentumoknál. LangChain RecursiveCharacterTextSplitter.

• 2️⃣

  A dokumentumok hosszú narratív szövegek? (kézikönyv, kutatási riport, esettanulmány, >1000 szó)

  → Szemantikus chunking. A természetes tartalmi határok megőrzése kritikus hosszú szövegeknél. LangChain SemanticChunker, 85. percentilis threshold.

• 3️⃣

  A dokumentumok hierarchikus struktúrájúak? (fejezetek, alszekciók, specifikáció, jogi dokumentum)

  → Parent-child chunking. A leaf chunk pontos visszakeresést ad, a parent chunk gazdag kontextust az LLM-nek. LlamaIndex HierarchicalNodeParser + AutoMergingRetriever.

• 4️⃣

  A dokumentumállomány vegyes típusú? (kód, narrative, táblázat, FAQ egyszerre)

  → Hibrid / adaptív chunking. Dokumentumtípus-detekció (kód → 128 token fix; narrative → szemantikus; hierarchikus → parent-child). Magasabb konfigurációs overhead, de a legjobb RAGAS-pontszám vegyes állományon.

• 5️⃣

  Nem tudod eldönteni, vagy PoC-fázisban vagy?

  → Kezdd fix méretűvel (512 token, 10% overlap), mérd RAGAS-szal, majd iterálj. Az első mérés megmutatja, hol a szűk keresztmetszet — Context Precision vs. Context Recall alapján döntsd el, melyik irányba kell finomítani.

Kérdések és válaszok

Kapcsolódó tartalmak

Varga Zoltán

AI-stratégia tanácsadó és a Corpus V2 RAG rendszer fejlesztője — 1,48 millió vektorizált szövegtöredék, Qdrant vektoradatbázis, Qwen3-Embedding-8B Matryoshka, Qwen3-Reranker-0.6B CUDA pipeline, parent-child chunking (256 leaf / 1024 parent). A chunking stratégiákról azt írom, amit ténylegesen megmértem és összehasonlítottam — RAGAS Context Precision 0.61-ről 0.84-re emelkedett a stratégiaváltással. Nem elméleti — operatív tapasztalat.