Back to glossary

Term

Chunking

Chunking is the splitting of longer texts into smaller, self-contained pieces — the first step of any RAG pipeline because embeddings and retrieval work at the chunk level.

Chunking — explained

An embedding model compresses a passage of text into a single vector. If the passage is too long, the model averages across too many topics and the semantic signal blurs. Too short, and context is missing — relevant matches get torn apart. Typical sizes land at 200–800 tokens per chunk, with a 10–20 % overlap so sentences sitting on the boundary keep their context. The chosen strategy — fixed token count, sentence/paragraph boundaries, semantic chunking, hierarchical chunking — has a strong effect on retrieval quality.

Example / Practical context

When indexing technical documentation, you might split by H2 section with a fixed-token-count fallback. Each chunk carries metadata (source, heading path, date) and is stored as an embedding in the vector database. At query time, typically 4–10 chunks are returned and merged by the LLM. Tools like LangChain and LlamaIndex ship standard splitters (RecursiveCharacterTextSplitter, MarkdownTextSplitter, and so on).

Chunking is not tokenization — that splits individual words into sub-token units for the model. Chunking works one level up and splits whole documents into retrieval-friendly pieces. Contextual Retrieval adds an LLM-generated context sentence to each chunk so isolated chunks become more understandable on their own.

Entdecke mehr

Themenuebersicht