Chunking splits a long document into small pieces so a retrieval system can find and use the right part. It is step 1 of every RAG pipeline: you cut the text, embed each piece into a vector, and index it — so a question can later pull back only the chunks that matter.

Where you meet it

• RAG over your own docs — PDFs, wikis, support tickets fed to an LLM.
• Vector databases (Pinecone, Weaviate) — every record is one chunk's embedding.
• Framework splitters — LangChain's RecursiveCharacterTextSplitter, LlamaIndex's SentenceSplitter.

What it does

It turns one unmanageable document into many retrievable units. Each chunk becomes a single vector you can store and search. Retrieval quality is capped by your chunks: the model can only ground its answer in the pieces you decided to create.

Your chunks are the ceiling on retrieval: the model can only ground its answer in pieces you cut well — a bad split is invisible until search fails.

How it works

Slide a window of roughly N tokens across the text, advancing by step = size − overlap. Each window is one chunk; it gets embedded and indexed. The window then jumps forward, but a few tokens of overlap carry over so a sentence sitting on a boundary survives in both neighbours.

fixed-size   → cut every N tokens, ignore meaning
recursive    → split on paragraphs → sentences → words,
               keep pieces under the limit
semantic     → embed sentences, cut where the
               topic shifts (similarity drops)

Fixed-size is the simplest baseline. Recursive respects structure — it tries large separators first and only breaks finer when a piece is still too big. Semantic chunking uses embeddings to find natural topic boundaries instead of a fixed length.

Watch out

Go deeper

• LangChain — text splitters & RAG building blocks
• Pinecone — Chunking Strategies for RAG
• LlamaIndex — SentenceSplitter & SemanticSplitter node parsers
• Hugging Face — Advanced RAG cookbook (tokenizer-aware splitting)

Chunking teilt ein langes Dokument in kleine Stücke, damit ein Retrieval-System den richtigen Teil findet und nutzt. Es ist Schritt 1 jeder RAG-Pipeline: Text schneiden, jedes Stück in einen Vektor embedden und indexieren — damit eine Frage später nur die relevanten Chunks zurückholt.

Wo es vorkommt

• RAG über eigene Docs — PDFs, Wikis, Support-Tickets als Kontext für ein LLM.
• Vektordatenbanken (Pinecone, Weaviate) — jeder Eintrag ist das Embedding eines Chunks.
• Framework-Splitter — LangChains RecursiveCharacterTextSplitter, LlamaIndex' SentenceSplitter.

Was es tut

Es macht aus einem unhandlichen Dokument viele abrufbare Einheiten. Jeder Chunk wird ein einzelner Vektor zum Speichern und Suchen. Die Retrieval-Qualität ist durch deine Chunks gedeckelt: Das Modell kann seine Antwort nur in den Stücken verankern, die du angelegt hast.

Deine Chunks sind die Obergrenze des Retrievals: Das Modell verankert seine Antwort nur in gut geschnittenen Stücken — ein schlechter Schnitt fällt erst auf, wenn die Suche scheitert.

Wie es funktioniert

Ein Fenster von etwa N Tokens gleitet über den Text und rückt um step = Größe − Overlap weiter. Jedes Fenster ist ein Chunk; er wird embeddet und indexiert. Dann springt das Fenster vor, aber ein paar Tokens Overlap werden mitgenommen — so überlebt ein Satz auf der Grenze in beiden Nachbarn.

fixed-size  → alle N Tokens schneiden, Bedeutung egal
recursive   → an Absätzen → Sätzen → Wörtern trennen,
              Stücke unter dem Limit halten
semantisch  → Sätze embedden, dort schneiden, wo das
              Thema wechselt (Ähnlichkeit fällt)

Fixed-size ist die einfachste Baseline. Recursive respektiert Struktur — erst große Trenner, feiner nur, wenn ein Stück noch zu groß ist. Semantisches Chunking nutzt Embeddings, um natürliche Themengrenzen statt einer festen Länge zu finden.

Worauf achten

Mehr dazu

• LangChain — Text-Splitter & RAG-Bausteine
• Pinecone — Chunking Strategies for RAG
• LlamaIndex — SentenceSplitter & SemanticSplitter Node Parsers
• Hugging Face — Advanced RAG Cookbook (tokenizer-bewusstes Splitting)