RAG von Grund auf – Teil 2: Dokumente, Parsing und Chunking
Im ersten Teil ging es um die Grundidee von Retrieval-Augmented Generation:
Retrieval
↓
Augmentation
↓
Generation
Damit ein System überhaupt sinnvoll retrieven kann, muss Wissen zuerst in eine Form gebracht werden, die sich durchsuchen lässt.
Genau hier beginnt die Ingestion.
Dieser Teil behandelt deshalb die Seite von RAG, die häufig unterschätzt wird: Dokumente einlesen, strukturieren, zerlegen und so vorbereiten, dass später gute Suchergebnisse möglich werden.
Denn ein RAG-System kann nur finden, was vorher sinnvoll aufbereitet wurde.
1. Ingestion: Wissen für Retrieval vorbereiten
Unter Ingestion versteht man den Prozess, bei dem Rohdaten in einen durchsuchbaren Wissensbestand überführt werden.
Typischer Ablauf:
Datei
↓
Parsing
↓
strukturierter Text
↓
Chunking
↓
indexierbare Einheiten
↓
Index
Je nach System kommen weitere Schritte hinzu:
Datei
↓
Parsing
↓
Normalisierung
↓
Strukturerkennung
↓
Chunking
↓
Metadaten
↓
Embedding / Sparse-Repräsentation
↓
Indexierung
Die Ingestion entscheidet damit wesentlich darüber, welche Informationen später überhaupt auffindbar sind.
2. Dokumente sind nicht einfach Textdateien
Ein häufiger Denkfehler lautet:
Ein Dokument enthält Text, also lese ich den Text aus und speichere ihn.
In der Praxis ist ein Dokument wesentlich mehr als eine lineare Folge von Zeichen.
Ein PDF kann enthalten:
- Überschriften,
- Absätze,
- Tabellen,
- Fussnoten,
- Kopfzeilen,
- Seitenzahlen,
- Bilder,
- Diagramme,
- mehrspaltige Layouts,
- eingebettete Schriftarten,
- gescannte Seiten.
Ein Word-Dokument kann enthalten:
- Formatvorlagen,
- Kapitelhierarchien,
- Tabellen,
- Kommentare,
- Textfelder,
- Listen,
- Fussnoten.
Eine Webseite besitzt wiederum:
- Navigation,
- Hauptinhalt,
- Footer,
- Seitenelemente,
- versteckte Bereiche,
- dynamisch geladenen Inhalt.
Die zentrale Aufgabe der Ingestion lautet deshalb nicht:
Wie bekomme ich Zeichen aus einer Datei?
Sondern:
Wie rekonstruiere ich die inhaltliche Struktur so gut, dass Retrieval später noch versteht, was zusammengehört?
3. Parsing
Parsing bezeichnet das Einlesen und strukturierte Interpretieren eines Dokuments oder Datenformats.
Ein Parser versucht, aus einer Rohquelle verwertbare Inhalte zu erzeugen.
Beispiel:
Personalreglement.pdf
↓
Parser
↓
Titel
Kapitel
Absätze
Tabellen
Seiteninformationen
Bei einem einfachen Textdokument ist Parsing trivial.
Bei komplexen Formaten kann es sehr schwierig werden.
4. Text Extraction und Parsing sind nicht dasselbe
Text Extraction bedeutet lediglich, Text aus einer Quelle herauszuholen.
Parsing versucht zusätzlich, Struktur zu erhalten.
Beispiel:
Original:
3. Probezeit
3.1 Dauer
Die Probezeit dauert drei Monate.
3.2 Kündigung
Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Eine schlechte Extraktion könnte daraus machen:
3 Probezeit 3.1 Dauer Die Probezeit dauert drei Monate 3.2 Kündigung
Während der Probezeit beträgt die Kündigungsfrist sieben Tage
Der reine Text ist vorhanden.
Die Struktur ist aber verloren.
Ein besserer Parser erhält:
Heading: Probezeit
Subheading: Dauer
Text: Die Probezeit dauert drei Monate.
Subheading: Kündigung
Text: Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Für Retrieval ist die zweite Variante wesentlich wertvoller.
5. Warum Struktur wichtig ist
Dokumentstruktur transportiert Bedeutung.
Diese beiden Sätze:
Die Frist beträgt sieben Tage.
und:
Während der Probezeit beträgt die Frist sieben Tage.
sind nicht gleich informativ.
Wenn Überschriften oder vorherige Absätze verloren gehen, verliert ein späterer Chunk möglicherweise seinen semantischen Kontext.
Ein Abschnitt mit der Überschrift:
Kündigung während der Probezeit
kann für Retrieval hochrelevant sein, selbst wenn der eigentliche Absatz das Wort „Probezeit“ nicht wiederholt.
Deshalb sollte Dokumentstruktur möglichst früh erhalten bleiben.
6. Layout Parsing
Bei komplexen Dokumenten reicht einfache Textextraktion häufig nicht.
Dann kommt Layout Parsing ins Spiel.
Dabei wird versucht, die visuelle Struktur eines Dokuments zu erkennen.
Beispiele:
- Überschrift,
- Absatz,
- Tabelle,
- Bild,
- Fussnote,
- Spalte,
- Seitenkopf.
Besonders PDFs benötigen häufig Layout-Erkennung, weil PDF intern nicht zwingend als logisch strukturierter Text gespeichert ist.
Ein PDF beschreibt primär, wo etwas dargestellt wird.
Nicht zwingend, welche semantische Rolle es besitzt.
7. Warum PDFs schwierig sind
PDF ist für Darstellung optimiert, nicht für semantische Verarbeitung.
Eine Seite kann intern beispielsweise enthalten:
Textblock A bei x=50, y=100
Textblock B bei x=300, y=100
Textblock C bei x=50, y=140
Ein Parser muss daraus rekonstruieren:
Spalte 1:
A
C
Spalte 2:
B
Ein schlechter Parser könnte daraus machen:
A B C
Dadurch können Sätze vermischt werden.
Für RAG ist das problematisch, weil falsche Reihenfolge zu falschen Chunks führt.
8. Born-Digital PDF versus Scan
Bei PDFs muss man zwischen zwei grundlegend unterschiedlichen Fällen unterscheiden.
Born-Digital PDF
Der Text liegt bereits digital vor.
Beispielsweise:
Word
↓
PDF Export
Der Text kann meistens direkt extrahiert werden.
Gescanntes PDF
Die Seite besteht primär aus einem Bild.
Beispielsweise:
Papierdokument
↓
Scanner
↓
PDF mit Seitenbildern
Hier existiert kein direkt nutzbarer Textlayer.
Dann benötigt man OCR.
9. OCR
OCR steht für Optical Character Recognition.
OCR versucht, Text aus Bildern zu erkennen.
Beispiel:
Bild einer Seite
↓
OCR
↓
"Die Kündigungsfrist beträgt sieben Tage."
OCR ist für RAG besonders relevant bei:
- eingescannten Verträgen,
- Archivdokumenten,
- alten Handbüchern,
- Formularen,
- Bild-PDFs,
- fotografierten Dokumenten.
10. OCR ist fehlerbehaftet
OCR liefert nicht garantiert korrekten Text.
Typische Fehler:
0 ↔ O
1 ↔ l
rn ↔ m
5 ↔ S
Aus:
CHF 1'500
könnte beispielsweise werden:
CHF l'5OO
Bei normalen Sätzen ist das oft tolerierbar.
Bei:
- Beträgen,
- Seriennummern,
- Paragraphen,
- Produktcodes,
- IDs,
- Namen
kann ein einzelner OCR-Fehler jedoch entscheidend sein.
Deshalb ist Dokumentqualität Teil der Retrieval-Qualität.
11. OCR und Layout zusammen betrachten
Bei komplexen Scans reicht reine OCR ebenfalls nicht.
Angenommen, eine Seite enthält:
| Produkt | Preis |
| A | 100 |
| B | 200 |
Eine reine OCR könnte liefern:
Produkt Preis A 100 B 200
Der Text ist erkannt.
Die Tabellenstruktur ist verloren.
Damit wird später schwer erkennbar, welcher Preis zu welchem Produkt gehört.
Moderne Document-AI-Systeme versuchen deshalb häufig gleichzeitig zu erkennen:
- Text,
- Bounding Boxes,
- Tabellen,
- Überschriften,
- Listen,
- Lesereihenfolge.
12. Normalisierung
Nach dem Parsing folgt häufig eine Normalisierung.
Ziel ist, technische oder visuelle Artefakte zu entfernen, ohne den eigentlichen Inhalt zu zerstören.
Beispiele:
- mehrfache Leerzeichen reduzieren,
- falsche Zeilenumbrüche zusammenführen,
- wiederkehrende Kopfzeilen entfernen,
- Seitenzahlen aus dem Fliesstext lösen,
- Zeichenkodierung vereinheitlichen,
- Bulletpoints konsistent darstellen.
Beispiel:
Vorher:
Die Kündigungs-
frist beträgt sieben
Tage.
Nachher:
Die Kündigungsfrist beträgt sieben Tage.
Eine gute Normalisierung verbessert Retrieval.
Eine aggressive Normalisierung kann Information zerstören.
13. Boilerplate
Als Boilerplate bezeichnet man wiederkehrenden Inhalt, der für die eigentliche Wissenssuche häufig wenig relevant ist.
Beispiele:
© 2026 Beispiel AG
Vertraulich
Seite 17 von 83
www.example.com
Wenn solche Texte auf jeder Seite vorkommen, können sie:
- unnötige Tokens erzeugen,
- Embeddings beeinflussen,
- Keyword-Suche verfälschen,
- Duplicate-Chunks erzeugen.
Deshalb werden wiederkehrende Header und Footer häufig entfernt oder separat behandelt.
14. Dokumentmetadaten
Ein Dokument besteht nicht nur aus Inhalt.
Es besitzt häufig Metadaten.
Beispiele:
Titel
Dateiname
Autor
Erstellungsdatum
Änderungsdatum
Dokumenttyp
Sprache
Quelle
Version
Seitenzahl
Metadaten können später beim Retrieval wichtig werden.
Eine Frage wie:
Was steht im Personalreglement von 2026?
enthält Informationen, die nicht zwingend im eigentlichen Absatz vorkommen:
Dokumenttyp = Personalreglement
Jahr = 2026
Metadaten können deshalb als zusätzliches Retrieval-Signal dienen.
15. Strukturmetadaten
Neben klassischen Dokumentmetadaten existieren Strukturmetadaten.
Beispielsweise:
Kapitel: Arbeitsverhältnis
Abschnitt: Probezeit
Unterabschnitt: Kündigung
Seite: 7
Ein Chunk könnte damit intern ungefähr so beschrieben werden:
Document: Personalreglement.pdf
Page: 7
Heading: Arbeitsverhältnis
Subheading: Probezeit
Section: Kündigung
Text: Während der Probezeit beträgt ...
Diese Struktur kann sowohl Retrieval als auch Quellenanzeige verbessern.
16. Was ist Chunking?
Chunking bezeichnet das Zerlegen grösserer Inhalte in kleinere Einheiten.
Diese Einheiten werden Chunks genannt.
Beispiel:
Dokument mit 50'000 Wörtern
↓
Chunking
↓
Chunk 1
Chunk 2
Chunk 3
...
Chunk 180
Warum überhaupt zerlegen?
Weil Retrieval meist auf kleineren Einheiten besser funktioniert als auf kompletten Dokumenten.
17. Warum nicht ganze Dokumente indexieren?
Angenommen, ein Personalhandbuch enthält:
- Arbeitszeiten,
- Spesen,
- Ferien,
- Kündigung,
- Versicherungen,
- IT-Richtlinien.
Die Benutzerfrage lautet:
Wie lange dauert die Probezeit?
Wenn das gesamte Handbuch eine einzige Retrieval-Einheit wäre, müsste ein Embedding die Bedeutung des gesamten Dokuments repräsentieren.
Die spezifische Passage über die Probezeit wäre nur ein kleiner Teil davon.
Mit Chunks kann stattdessen genau der relevante Abschnitt gefunden werden.
18. Chunking ist eine Form der Informationskompression
Beim Chunking trifft man implizit eine Entscheidung:
Welche Informationen müssen gemeinsam bleiben, damit ihre Bedeutung erhalten bleibt?
Das ist mehr als ein technisches Splitten.
Ein Chunk definiert eine semantische Einheit.
Beispielsweise:
Heading:
Kündigung während der Probezeit
Text:
Während der Probezeit kann das Arbeitsverhältnis
mit einer Frist von sieben Tagen gekündigt werden.
Das ist eine sinnvolle Einheit.
Wenn wir dagegen trennen:
Chunk 1:
Während der Probezeit kann das Arbeitsverhältnis
Chunk 2:
mit einer Frist von sieben Tagen gekündigt werden.
wird Information zerstört.
19. Chunk Size
Die Chunk Size beschreibt, wie gross ein Chunk sein darf.
Sie kann gemessen werden in:
- Zeichen,
- Wörtern,
- Tokens,
- Sätzen,
- Absätzen.
Es existiert keine universell optimale Chunk-Grösse.
Die geeignete Grösse hängt ab von:
- Dokumenttyp,
- Sprache,
- Retrieval-Modell,
- Embedding-Modell,
- Fragen,
- gewünschter Granularität.
20. Kleine Chunks
Kleine Chunks besitzen Vorteile.
Sie sind meist:
- thematisch präziser,
- leichter zu ranken,
- günstiger im Prompt,
- weniger verrauscht.
Beispiel:
Die Kündigungsfrist während der Probezeit beträgt sieben Tage.
Das ist extrem fokussiert.
Aber kleine Chunks besitzen Nachteile.
Der Satz könnte ohne Kontext unklar sein.
Beispielsweise:
Sie beträgt sieben Tage.
Was beträgt sieben Tage?
Der notwendige Kontext lag vielleicht im vorherigen Satz.
21. Grosse Chunks
Grosse Chunks enthalten mehr Kontext.
Beispiel:
3. Probezeit
Die Probezeit dauert drei Monate.
Während der Probezeit kann das Arbeitsverhältnis
mit einer Frist von sieben Tagen gekündigt werden.
Nach Ablauf der Probezeit gelten die ordentlichen
Kündigungsfristen.
Das Modell erhält mehr Zusammenhang.
Der Nachteil:
Wenn der Chunk zusätzlich noch zehn andere Themen enthält, sinkt seine semantische Präzision.
22. Der Chunking-Trade-off
Das Grundproblem lässt sich so darstellen:
kleine Chunks
↓
hohe Präzision
aber weniger Kontext
grosse Chunks
↓
mehr Kontext
aber mehr Rauschen
Chunking optimiert deshalb einen Trade-off zwischen:
Granularität und Kontext.
23. Chunk Overlap
Overlap bedeutet, dass benachbarte Chunks einen gemeinsamen Textbereich besitzen.
Beispiel:
Original:
A B C D E F G H I J
Ohne Overlap:
Chunk 1: A B C D E
Chunk 2: F G H I J
Mit Overlap:
Chunk 1: A B C D E F
Chunk 2: E F G H I J
Dadurch gehen Informationen an Chunk-Grenzen weniger leicht verloren.
24. Warum Overlap hilft
Angenommen:
Satz 1:
Während der Probezeit gelten besondere Kündigungsregeln.
Satz 2:
Die Kündigungsfrist beträgt sieben Tage.
Wenn die Grenze zwischen den Sätzen liegt, könnte Chunk 2 nur enthalten:
Die Kündigungsfrist beträgt sieben Tage.
Mit Overlap kann der vorherige Satz mitgenommen werden:
Während der Probezeit gelten besondere Kündigungsregeln.
Die Kündigungsfrist beträgt sieben Tage.
Damit bleibt die Bedeutung klar.
25. Zu viel Overlap ist ebenfalls problematisch
Overlap erzeugt Duplikate.
Bei sehr grossem Overlap entstehen beispielsweise:
Chunk 1: A B C D E F
Chunk 2: C D E F G H
Chunk 3: E F G H I J
Das kann dazu führen, dass Retrieval mehrere fast identische Chunks findet.
Dann erhält das Modell vielleicht fünf Treffer, die inhaltlich fast dasselbe sagen.
Das verschwendet Kontextbudget.
Overlap ist daher eine Optimierung, kein kostenloser Qualitätsgewinn.
26. Fixed-Size Chunking
Die einfachste Strategie ist Fixed-Size Chunking.
Beispielsweise:
alle 500 Tokens
oder:
alle 2'000 Zeichen
Das ist technisch einfach.
Beispiel:
Text
↓
500 Tokens
↓
500 Tokens
↓
500 Tokens
Problem:
Semantische Grenzen werden ignoriert.
Ein Absatz oder Satz kann mitten inhaltlich getrennt werden.
27. Sliding Window
Ein Sliding Window kombiniert fixe Grösse mit Overlap.
Beispielsweise:
Chunk-Grösse: 500 Tokens
Overlap: 100 Tokens
Dann entstehen Fenster wie:
Tokens 1–500
Tokens 401–900
Tokens 801–1300
Das reduziert Randprobleme.
Die grundlegende Schwäche bleibt:
Die Dokumentstruktur wird nicht berücksichtigt.
28. Sentence-Based Chunking
Beim Sentence-Based Chunking werden Satzgrenzen verwendet.
Beispiel:
Satz 1
Satz 2
Satz 3
Satz 4
Chunks könnten dann sein:
Chunk 1:
Satz 1
Satz 2
Chunk 2:
Satz 3
Satz 4
Damit werden Sätze nicht mitten im Text getrennt.
Allerdings bilden Sätze nicht immer sinnvolle thematische Einheiten.
29. Paragraph-Based Chunking
Beim Paragraph-Based Chunking werden Absätze als natürliche Grenzen verwendet.
Das ist häufig sinnvoll, weil ein Absatz typischerweise einen zusammenhängenden Gedanken enthält.
Problematisch wird es bei sehr langen Absätzen.
Ein Absatz kann mehrere hundert oder tausend Wörter besitzen.
Dann benötigt man zusätzliche Split-Regeln.
30. Recursive Chunking
Recursive Character Splitting beziehungsweise Recursive Chunking ist eine sehr verbreitete Strategie.
Dabei wird versucht, zunächst an starken semantischen Grenzen zu teilen.
Beispielsweise:
1. Kapitel
2. Absätze
3. Zeilen
4. Sätze
5. Wörter
6. Zeichen
Das System versucht also zunächst:
\n\n
Dann:
\n
Dann Satzgrenzen.
Erst zuletzt werden harte Zeichen- oder Token-Grenzen verwendet.
Damit wird die Dokumentstruktur besser erhalten als bei reinem Fixed-Size Chunking.
31. Structured Chunking
Beim Structured Chunking wird die logische Dokumentstruktur aktiv berücksichtigt.
Beispielsweise:
1. Arbeitsverhältnis
1.1 Probezeit
1.1.1 Dauer
1.1.2 Kündigung
2. Ferien
2.1 Anspruch
2.2 Bezug
Chunks werden entlang dieser Struktur gebildet.
Ein Chunk kann dann enthalten:
Arbeitsverhältnis
> Probezeit
> Kündigung
Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Damit bleibt die semantische Einordnung erhalten.
32. Heading Path
Der Begriff Heading Path bezeichnet den Pfad durch die Überschriftenhierarchie.
Beispiel:
Personalreglement
↓
Arbeitsverhältnis
↓
Probezeit
↓
Kündigung
Als Metadatum:
[
"Arbeitsverhältnis",
"Probezeit",
"Kündigung"
]
Heading Paths sind besonders wertvoll, weil sie Kontext liefern, ohne grosse Textmengen wiederholen zu müssen.
33. Semantic Chunking
Beim Semantic Chunking wird nicht primär anhand formaler Dokumentgrenzen geteilt.
Stattdessen versucht man, semantische Themenwechsel zu erkennen.
Vereinfacht:
Satz 1 ─┐
Satz 2 │ Thema A
Satz 3 ─┘
Satz 4 ─┐
Satz 5 │ Thema B
Satz 6 ─┘
Ein möglicher Ansatz besteht darin, Embeddings benachbarter Sätze zu vergleichen.
Wenn sich deren Bedeutung stark verändert, wird eine Grenze gesetzt.
34. Vorteile von Semantic Chunking
Semantic Chunking kann sinnvoll sein bei:
- langen Fliesstexten,
- schwacher Formatierung,
- automatisch generierten Dokumenten,
- Transkripten.
Es kann thematisch kohärentere Chunks erzeugen als starre Fenster.
35. Nachteile von Semantic Chunking
Semantic Chunking bringt zusätzliche Komplexität.
Es kann:
- mehr Rechenaufwand verursachen,
- abhängig vom Embedding-Modell sein,
- instabile Grenzen erzeugen,
- schwerer reproduzierbar sein.
Ein Dokument mit guter Struktur benötigt nicht automatisch semantisches Chunking.
Oft ist vorhandene Struktur das stärkere Signal.
36. Page-Based Chunking
Bei Page-Based Chunking entspricht eine Seite einem Chunk.
Das ist einfach und praktisch für manche Dokumentarten.
Beispielsweise Präsentationen:
Slide 1 = Chunk 1
Slide 2 = Chunk 2
Slide 3 = Chunk 3
Bei technischen PDFs kann eine Seite ebenfalls eine brauchbare Einheit sein.
Bei langen Fliesstexten ist eine Seite jedoch eine rein visuelle Grenze.
Ein Satz oder Abschnitt kann über zwei Seiten gehen.
37. Section-Based Chunking
Beim Section-Based Chunking bildet ein Abschnitt die Grundeinheit.
Beispiel:
3.2 Kündigung während der Probezeit
wird als Einheit verarbeitet.
Ist der Abschnitt klein genug, bleibt er vollständig.
Ist er zu gross, wird er intern weiter zerlegt.
Dieses Verfahren verbindet logische Struktur mit Grössenlimits.
38. Hybrid Chunking
In realen Systemen werden Chunking-Strategien häufig kombiniert.
Beispielsweise:
Dokumentstruktur erkennen
↓
pro Abschnitt chunking
↓
bei Übergrösse Satzgrenzen
↓
bei Übergrösse Tokenlimit
Das könnte schematisch aussehen:
Section
│
├─ klein genug
│ ↓
│ Chunk
│
└─ zu gross
↓
Paragraph
↓
Sentence
↓
Token Split
Das ist typischerweise robuster als eine einzige starre Regel.
39. Parent-Child Chunking
Ein fortgeschrittenes Konzept ist Parent-Child Retrieval.
Die Grundidee:
Man verwendet kleine Chunks für die Suche, liefert dem LLM aber einen grösseren übergeordneten Kontext.
Beispiel:
Section: Probezeit
│
├── Child Chunk 1: Dauer
├── Child Chunk 2: Kündigung
└── Child Chunk 3: Ferien
Die Suche findet:
Child Chunk 2
Für die Antwort kann jedoch der Parent bereitgestellt werden:
Section: Probezeit
Damit verbindet man:
- präzises Retrieval,
- reichhaltigen Kontext.
40. Small-to-Big Retrieval
Small-to-Big Retrieval bezeichnet denselben Grundgedanken in allgemeiner Form.
Man sucht mit einer kleinen Einheit:
kleiner Chunk
und gibt anschliessend eine grössere Einheit an das Modell:
Abschnitt
oder:
Nachbar-Chunks
Schematisch:
klein suchen
↓
relevanten Treffer finden
↓
Kontext erweitern
↓
gross an LLM geben
41. Warum Small-to-Big sinnvoll ist
Dense Retrieval funktioniert häufig besser auf fokussierten Texten.
Ein kleines Segment besitzt einen klaren semantischen Schwerpunkt.
Für die Generierung benötigt das Modell aber manchmal mehr Kontext.
Small-to-Big trennt deshalb zwei Anforderungen:
Retrieval-Einheit
≠
Prompt-Einheit
Diese Trennung ist konzeptionell sehr wichtig.
42. Neighbor Expansion
Eine einfache Variante von Small-to-Big ist Neighbor Expansion.
Die Suche findet:
Chunk 12
Dann werden zusätzlich geladen:
Chunk 11
Chunk 12
Chunk 13
Dadurch erhält das Modell den lokalen Kontext.
Das funktioniert gut, wenn Dokumente linear strukturiert sind.
Bei Tabellen, stark verschachtelten Dokumenten oder Webseiten kann die unmittelbare Nachbarschaft weniger sinnvoll sein.
43. Parent Document Retriever
Ein Parent Document Retriever speichert eine Beziehung zwischen kleinen Retrieval-Chunks und grösseren Parent-Einheiten.
Beispiel:
Parent: Abschnitt 3
Child 3.1
Child 3.2
Child 3.3
Die Suchmaschine arbeitet auf Child-Chunks.
Nach einem Treffer wird der Parent geladen.
Das Verfahren ist besonders hilfreich bei langen Abschnitten.
44. Hierarchical Chunking
Beim Hierarchical Chunking existieren mehrere Ebenen.
Beispielsweise:
Dokument
↓
Kapitel
↓
Abschnitt
↓
Absatz
↓
Chunk
Jede Ebene kann unterschiedliche Aufgaben erfüllen.
Ein Retrieval-System könnte zunächst Kapitel identifizieren und danach innerhalb des Kapitels feinere Chunks suchen.
Das führt bereits in Richtung hierarchischer Retrieval-Architekturen.
45. Late Chunking
Late Chunking verfolgt einen anderen Ansatz.
Bei klassischem Chunking gilt:
Text
↓
Chunking
↓
Embedding pro Chunk
Bei Late Chunking wird zunächst ein grösserer Kontext gemeinsam durch ein Embedding-Modell verarbeitet.
Danach werden Repräsentationen für kleinere Bereiche abgeleitet.
Vereinfacht:
langer Text
↓
gemeinsame Modellverarbeitung
↓
lokale Chunk-Repräsentationen
Die Idee:
Ein einzelner Chunk soll bereits bei seiner Vektorrepräsentation Informationen aus dem grösseren Dokumentkontext mitbekommen.
46. Warum Late Chunking interessant ist
Betrachten wir den Satz:
Sie beträgt sieben Tage.
Allein ist er schlecht verständlich.
Im Kontext:
Kündigungsfrist während der Probezeit.
Sie beträgt sieben Tage.
ist die Bedeutung klar.
Klassisches Embedding des einzelnen Satzes verliert möglicherweise diese Information.
Late Chunking versucht, Kontext bereits in die Chunk-Repräsentation einzubauen.
47. Chunk Enrichment
Eine weitere Strategie ist Chunk Enrichment.
Dabei wird einem Chunk zusätzliche Information mitgegeben.
Beispielsweise:
Original:
Sie beträgt sieben Tage.
Angereichert:
Dokument: Personalreglement
Kapitel: Probezeit
Abschnitt: Kündigung
Sie beträgt sieben Tage.
Dadurch wird der Chunk für Retrieval verständlicher.
Enrichment kann stammen aus:
- Überschriften,
- Dokumenttitel,
- Zusammenfassungen,
- Metadaten,
- Parent-Kontext.
48. Contextual Retrieval
Ein verwandtes Konzept ist Contextual Retrieval.
Dabei wird einem Chunk explizit erklärt, wo er im Dokument einzuordnen ist.
Beispiel:
Original:
Die Frist beträgt sieben Tage.
Kontextualisiert:
Dieser Abschnitt stammt aus dem Kapitel über die Kündigung
während der Probezeit eines Personalreglements.
Die Frist beträgt sieben Tage.
Damit kann sowohl lexikalisches als auch semantisches Retrieval verbessert werden.
49. Chunk Summary
Statt vollständigen Parent-Kontext hinzuzufügen, kann man eine Chunk Summary erzeugen.
Beispiel:
Summary:
Regelung zur Kündigungsfrist während der Probezeit.
Original:
Die Frist beträgt sieben Tage.
Das kann hilfreich sein, erhöht aber den Ingestion-Aufwand.
Ausserdem können automatisch generierte Zusammenfassungen selbst Fehler enthalten.
50. Chunk Title
Eine einfachere Form des Enrichments ist ein Chunk Title.
Beispiel:
Kündigung während der Probezeit
Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Titel oder Heading Paths sind häufig hochwertige Kontextsignale, weil sie aus der ursprünglichen Dokumentstruktur stammen und nicht generiert werden müssen.
51. Chunk ID
Jeder Chunk benötigt typischerweise eine eindeutige Identität.
Beispielsweise:
document_123_chunk_42
oder eine UUID.
Die Chunk-ID ermöglicht:
- Retrieval,
- Updates,
- Löschen,
- Quellenreferenzen,
- Debugging,
- Nachvollziehbarkeit.
52. Document ID
Zusätzlich sollte die Beziehung zum Ursprungsdokument erhalten bleiben.
Beispiel:
chunk_id: chunk_42
document_id: document_123
Damit lässt sich nachvollziehen:
Chunk
↓
Dokument
↓
Originalquelle
Ohne diese Beziehung wären gute Citations schwierig.
53. Position im Dokument
Auch die Position eines Chunks kann wichtig sein.
Beispielsweise:
page: 12
section: 3.2
chunk_index: 42
Diese Daten ermöglichen:
- Quellenanzeige,
- Neighbor Expansion,
- Parent Retrieval,
- Dokumentnavigation.
54. Versionierung
Dokumente verändern sich.
Beispiel:
Personalreglement 2025
Personalreglement 2026
Oder dieselbe Datei wird ersetzt.
Ein RAG-System sollte deshalb wissen:
Welcher Chunk gehört zu welcher Dokumentversion?
Sonst können alte und neue Aussagen gleichzeitig im Index vorhanden sein.
55. Duplicate Detection
Ein Korpus enthält häufig Duplikate.
Beispielsweise:
Personalreglement.pdf
Personalreglement_Kopie.pdf
Personalreglement_final.pdf
Personalreglement_final_final.pdf
Werden alle unabhängig indexiert, kann Retrieval dieselbe Passage mehrfach zurückgeben.
Das erzeugt scheinbar mehrere Quellen, obwohl nur eine Information mehrfach vorhanden ist.
56. Near-Duplicates
Noch schwieriger sind Near-Duplicates.
Beispiel:
Dokument A:
Die Kündigungsfrist beträgt sieben Tage.
Dokument B:
Die Kündigungsfrist beträgt 7 Tage.
Semantisch ist das praktisch identisch.
Near-Duplicate-Erkennung kann später verhindern, dass der Prompt mit Wiederholungen gefüllt wird.
57. Tabellen
Tabellen benötigen besondere Behandlung.
Beispiel:
| Vertragsart | Kündigungsfrist |
|---|---|
| Probezeit | 7 Tage |
| unbefristet | 3 Monate |
Eine lineare Extraktion:
Vertragsart Kündigungsfrist Probezeit 7 Tage unbefristet 3 Monate
ist schlechter als eine strukturierte Darstellung:
Vertragsart: Probezeit
Kündigungsfrist: 7 Tage
Vertragsart: unbefristet
Kündigungsfrist: 3 Monate
Die zweite Variante erhält die Beziehung zwischen Spalten.
58. Tabellen als Markdown
Eine verbreitete Strategie ist, Tabellen in Markdown umzuwandeln.
| Vertragsart | Kündigungsfrist |
|---|---|
| Probezeit | 7 Tage |
| unbefristet | 3 Monate |
Das erhält Struktur relativ kompakt.
Ob das für Retrieval optimal ist, hängt vom Modell und vom Tabelleninhalt ab.
59. Tabellen zeilenweise chunking
Bei grossen Tabellen kann es sinnvoll sein, jede Zeile als eigene Einheit zu behandeln.
Beispiel:
Vertragsart: Probezeit
Kündigungsfrist: 7 Tage
Dadurch lassen sich konkrete Datensätze besser finden.
Für Fragen über die gesamte Tabelle benötigt man dagegen möglicherweise wieder Aggregate oder grössere Kontexte.
60. Listen
Listen sollten ebenfalls nicht blind in Fliesstext verwandelt werden.
Original:
Mitarbeiter erhalten:
- 25 Ferientage
- Homeoffice
- Weiterbildung
Schlecht:
Mitarbeiter erhalten 25 Ferientage Homeoffice Weiterbildung
Besser:
Mitarbeiter erhalten:
- 25 Ferientage
- Homeoffice
- Weiterbildung
Listenstruktur trägt semantische Information.
61. Code
Technische Dokumentationen enthalten häufig Quellcode.
Code sollte möglichst als zusammenhängender Block erhalten bleiben.
Beispiel:
if (user == null)
{
throw new ArgumentNullException(nameof(user));
}
Ein Split mitten im Code kann:
- Syntax zerstören,
- Bedeutung verlieren,
- Retrieval verschlechtern.
Code-Dokumentation benötigt daher oft andere Chunking-Regeln als Prosa.
62. JSON und strukturierte Daten
JSON ist kein klassischer Fliesstext.
Beispiel:
{
"name": "Max Muster",
"department": "IT",
"status": "active"
}
Man könnte daraus Text erzeugen:
Name: Max Muster
Department: IT
Status: active
Bei grossen Arrays stellt sich aber die Frage:
Ein Chunk pro Record?
Mehrere Records pro Chunk?
Aggregate?
Strukturierte Daten benötigen häufig eine andere Ingestion-Strategie als PDFs.
63. CSV
Auch CSV besteht aus Records.
Beispiel:
name,department,status
Max Muster,IT,active
Anna Beispiel,HR,active
Für Entity-Suche ist oft ein Record pro Chunk sinnvoll.
Für Fragen wie:
Wie viele aktive Mitarbeiter gibt es?
ist reines Chunk-Retrieval dagegen problematisch.
Hier benötigt man eher strukturierte Abfragen oder vorberechnete Aggregate.
Das zeigt:
Nicht jede Wissensfrage ist ideal für Chunk-RAG.
64. HTML
Webseiten enthalten oft viel nicht relevanten Inhalt.
Beispiel:
Header
Navigation
Cookie Banner
Sidebar
Artikel
Footer
Related Posts
Für RAG interessiert meistens:
Artikel
HTML-Ingestion sollte deshalb versuchen, Hauptinhalt von Navigation und Boilerplate zu trennen.
65. Markdown
Markdown besitzt explizite Struktur.
Beispiel:
# Personalreglement
## Probezeit
### Kündigung
Diese Struktur sollte nicht verworfen werden.
Markdown eignet sich deshalb besonders gut für strukturiertes Chunking.
66. E-Mails
E-Mails bringen eigene Probleme mit.
Eine Nachricht kann enthalten:
aktuelle Antwort
--- ursprüngliche Nachricht ---
ältere Antwort
--- ursprüngliche Nachricht ---
noch ältere Nachricht
Wenn der komplette Thread blind indexiert wird, entstehen massive Duplikate.
E-Mail-Ingestion sollte deshalb zwischen:
- Nachricht,
- Thread,
- Zitat,
- Signatur,
- Anhängen
unterscheiden.
67. Chatverläufe
Auch Chats bestehen aus strukturierter Kommunikation.
Beispiel:
User A: Wann wird deployed?
User B: Freitag.
User A: Welcher Build?
User B: 1.4.7.
Einzelne Nachrichten allein können unverständlich sein.
Freitag.
ist ohne Kontext wertlos.
Chats benötigen deshalb häufig konversationsbezogenes Chunking.
68. Transkripte
Meeting- oder Video-Transkripte sind lange lineare Texte.
Nützliche Metadaten können sein:
Sprecher
Zeitstempel
Kapitel
Thema
Chunking nur nach fester Länge kann mitten in einem Sprecherwechsel oder Thema schneiden.
69. Dokumentqualität vor Retrieval-Qualität
Ein wichtiger Grundsatz lautet:
schlechte Extraktion
↓
schlechte Chunks
↓
schlechter Index
↓
schlechtes Retrieval
Das LLM kann diese Fehler am Ende nicht zuverlässig reparieren.
Wenn aus:
Kündigungsfrist: sieben Tage
durch OCR wird:
Kündigungsfrist: sieben lage
existiert bereits ein Datenqualitätsproblem vor dem Retrieval.
70. Garbage In, Garbage Out
Der bekannte Grundsatz:
Garbage In, Garbage Out
gilt für RAG besonders stark.
Eine hochwertige Embedding-Suche kann keine Information finden, die beim Parsing verloren gegangen ist.
Ein Cross-Encoder kann keinen kaputten Tabellenzusammenhang rekonstruieren, wenn die Zuordnung bereits zerstört wurde.
Ein LLM kann fehlende Dokumentstruktur höchstens erraten.
Deshalb beginnt RAG-Qualität bei der Ingestion.
71. Chunking und Retrieval sind gekoppelt
Chunking darf nicht isoliert betrachtet werden.
Eine Chunking-Strategie beeinflusst:
- Dense Retrieval,
- Sparse Retrieval,
- Reranking,
- Promptgrösse,
- Citation-Granularität,
- Antwortqualität.
Beispiel:
Sehr kleine Chunks können Dense Retrieval verbessern.
Aber ein Cross-Encoder benötigt möglicherweise mehr Kontext.
Sehr grosse Chunks können BM25-Treffer verwässern.
Chunking muss deshalb gegen das gesamte Retrieval-System evaluiert werden.
72. Chunking und Embeddings
Embeddings werden häufig pro Chunk berechnet.
Chunk
↓
Embedding Model
↓
Vector
Die Chunk-Grösse beeinflusst damit unmittelbar die Bedeutung des Vektors.
Ein Embedding von:
Kündigungsfrist während der Probezeit: sieben Tage.
ist stark fokussiert.
Ein Embedding von zwanzig Seiten Personalreglement repräsentiert viele Themen gleichzeitig.
Dadurch sinkt die lokale semantische Präzision.
73. Chunking und Sparse Retrieval
Auch lexikalische Verfahren wie BM25 reagieren auf Chunk-Grösse.
Ein kurzer Chunk:
Probezeit Kündigungsfrist sieben Tage
hat eine hohe Konzentration relevanter Terme.
Ein grosser Chunk könnte zusätzlich enthalten:
Ferien
Lohn
Spesen
Versicherungen
Arbeitszeit
Weiterbildung
Damit wird die Relevanz eines einzelnen Begriffs relativ schwächer.
74. Chunking und Reranking
Reranker bewerten typischerweise:
Frage + Passage
Ist die Passage extrem lang, enthält sie möglicherweise viel irrelevanten Text.
Ist sie zu kurz, fehlt Kontext.
Auch hier existiert ein optimaler Bereich, der vom Modell abhängt.
75. Chunking und Citations
Chunk-Grösse beeinflusst auch Quellenangaben.
Ein kleiner Chunk erlaubt eine präzise Citation.
Beispiel:
Seite 7, Absatz Kündigung
Ein riesiger Chunk kann als Quelle mehrere Seiten umfassen.
Dann wird die Citation weniger hilfreich.
76. Chunk Boundaries
Als Chunk Boundary bezeichnet man die Grenze zwischen zwei Chunks.
Gute Grenzen liegen bevorzugt an:
- Kapitelwechseln,
- Abschnittswechseln,
- Absatzgrenzen,
- Satzgrenzen.
Schlechte Grenzen liegen:
- mitten im Satz,
- mitten in einer Tabelle,
- zwischen Frage und Antwort,
- zwischen Überschrift und Absatz,
- zwischen Codezeilen eines Blocks.
77. Boundary Preservation
Boundary Preservation bedeutet, semantische oder strukturelle Grenzen möglichst zu respektieren.
Ein guter Chunker versucht beispielsweise:
Section
↓
Paragraph
↓
Sentence
und splittet erst hart, wenn Grössenlimits sonst überschritten werden.
78. Chunk Context
Ein Chunk sollte genügend Chunk Context besitzen, um sinnvoll interpretiert werden zu können.
Beispiel:
Schlecht:
Sie beträgt sieben Tage.
Besser:
Kündigung während der Probezeit
Die Kündigungsfrist beträgt sieben Tage.
Chunk Context kann aus:
- Überschrift,
- Parent Section,
- vorherigem Satz,
- Metadaten
kommen.
79. Chunk Cohesion
Cohesion beschreibt, wie stark die Inhalte eines Chunks thematisch zusammengehören.
Ein guter Chunk besitzt hohe Kohäsion:
Probezeit
Kündigungsfrist
sieben Tage
Ein schlechter Chunk mischt:
Probezeit
Kantinenmenu
VPN-Konfiguration
Kündigungsfrist
Hohe Kohäsion verbessert meist semantisches Retrieval.
80. Chunk Completeness
Ein Chunk sollte möglichst eine vollständige inhaltliche Aussage enthalten.
Beispiel:
Unvollständig:
Die Kündigungsfrist beträgt
Vollständig:
Die Kündigungsfrist beträgt sieben Tage.
Completeness ist besonders wichtig bei:
- Regeln,
- Definitionen,
- Zahlen,
- Bedingungen.
81. Conditional Statements
Regelwerke enthalten häufig Bedingungen.
Beispiel:
Wenn die Probezeit verlängert wurde,
beträgt die Kündigungsfrist weiterhin sieben Tage.
Ein Chunk, der nur enthält:
beträgt die Kündigungsfrist weiterhin sieben Tage
verliert die Bedingung.
Dadurch kann das RAG-System später falsche allgemeine Aussagen erzeugen.
82. Negationen
Negationen müssen ebenfalls im Chunk erhalten bleiben.
Original:
Während der Probezeit besteht kein Anspruch auf Homeoffice.
Wenn durch schlechtes Parsing oder Chunking nur verbleibt:
Anspruch auf Homeoffice.
ändert sich die Bedeutung vollständig.
83. Zahlen und Einheiten
Zahlen sollten zusammen mit ihrer Einheit und ihrem Bezug bleiben.
Schlecht:
CHF 500
Besser:
Die maximale Spesenpauschale beträgt CHF 500 pro Monat.
Das ist sowohl für Retrieval als auch für spätere Grounding-Prüfungen relevant.
84. Tabellenköpfe wiederholen
Bei grossen Tabellen kann ein Chunk sonst nur enthalten:
A | 500 | aktiv
B | 700 | inaktiv
Ohne Header ist die Bedeutung unklar.
Deshalb werden Tabellenköpfe häufig in jeden Teilchunk übernommen:
Name | Betrag | Status
A | 500 | aktiv
85. Dokumenttitel wiederholen
Ähnlich kann ein Dokumenttitel als Metadatum oder Kontext jedem Chunk hinzugefügt werden.
Beispiel:
Dokument: Personalreglement 2026
Abschnitt: Probezeit
Die Kündigungsfrist beträgt sieben Tage.
Das kann helfen, ähnlich klingende Dokumente zu unterscheiden.
86. Kontextanreicherung versus Duplikation
Zusätzlicher Kontext hilft.
Aber zu viel Wiederholung verursacht:
- grössere Embedding-Texte,
- mehr Speicher,
- lexikalische Verzerrung,
- Duplikate im Prompt.
Daher sollte Kontextanreicherung gezielt erfolgen.
87. Chunking nach Dokumenttyp
Es gibt keinen Grund, für alle Dokumenttypen dieselbe Strategie zu verwenden.
Beispiel:
| Dokumenttyp | mögliche Strategie |
|---|---|
| Gesetz | Artikel / Absatz |
| Handbuch | Kapitel / Abschnitt |
| Präsentation | Folie |
| Chat | Gesprächssegment |
| Tabelle | Zeile oder Gruppe |
| JSON | Record |
| Code | Funktion / Klasse |
| Markdown | Heading-Hierarchie |
| Nachricht / Threadsegment |
Das Format selbst gibt oft gute natürliche Grenzen vor.
88. Code Chunking
Bei Source Code sind syntaktische Strukturen gute Grenzen.
Beispiel:
Namespace
↓
Class
↓
Method
Statt:
alle 500 Tokens
kann man chunking entlang von:
- Klassen,
- Methoden,
- Funktionen,
- Modulen
verwenden.
Das erhält semantische Einheiten.
89. AST-basiertes Chunking
Bei Programmiersprachen kann ein Abstract Syntax Tree, kurz AST, genutzt werden.
Beispiel:
ClassDeclaration
├── MethodDeclaration
├── MethodDeclaration
└── PropertyDeclaration
AST-basiertes Chunking ist präziser als reine Textgrenzen, weil es die Sprachsyntax versteht.
90. Chunking von Dokumentationen
Technische Dokumentation besitzt häufig natürliche Hierarchien:
Produkt
↓
Komponente
↓
Feature
↓
API
↓
Beispiel
Diese Struktur sollte möglichst erhalten bleiben.
Eine API-Dokumentation mitten zwischen Parameterliste und Return-Wert zu splitten wäre ungünstig.
91. Multimodale Dokumente
Manche Dokumente enthalten relevante Information nicht nur als Text.
Beispiele:
- Diagramme,
- Screenshots,
- Architekturzeichnungen,
- Charts,
- Formulare.
Ein reiner Textparser verliert diese Information.
Multimodale RAG-Systeme können zusätzlich:
- Bilder beschreiben,
- Bild-Embeddings erzeugen,
- Layout interpretieren,
- Visual Question Answering verwenden.
Das erweitert die Ingestion über klassischen Text hinaus.
92. Image Captioning
Eine Möglichkeit ist, Bilder automatisch beschreiben zu lassen.
Beispiel:
Bild
↓
Vision Model
↓
"Diagramm zeigt einen Client, der über eine API
mit drei Backend-Services kommuniziert."
Diese Beschreibung kann anschliessend indexiert werden.
Problem:
Eine generierte Beschreibung ist bereits eine Interpretation.
Sie kann Details auslassen oder falsch beschreiben.
93. Multimodal Embeddings
Statt ein Bild zuerst in Text umzuwandeln, können Systeme multimodale Embeddings verwenden.
Dabei werden Text und Bilder in einen gemeinsamen oder vergleichbaren Vektorraum überführt.
Dann kann eine Textfrage direkt relevante Bilder finden.
Das ist konzeptionell eine Erweiterung klassischer Dense Retrieval-Verfahren.
94. Ingestion Pipeline
Eine typische allgemeine Ingestion-Pipeline kann deshalb deutlich umfangreicher aussehen:
Quelle
↓
Dateityp erkennen
↓
Parser auswählen
↓
Text / Layout / Tabellen extrahieren
↓
OCR falls nötig
↓
Normalisieren
↓
Struktur erkennen
↓
Metadaten erfassen
↓
Chunking
↓
Chunk Enrichment
↓
Embedding / Sparse Representation
↓
Indexierung
Nicht jedes System benötigt alle Schritte.
Die Pipeline zeigt aber, wie viel vor dem eigentlichen Retrieval passiert.
95. Deterministische versus LLM-basierte Ingestion
Ingestion kann mit klassischen Algorithmen oder LLMs durchgeführt werden.
Deterministisch
Beispiele:
- Regex,
- HTML Parser,
- PDF Parser,
- AST,
- Heading-Erkennung,
- Tabellenparser.
Vorteile:
- reproduzierbar,
- günstig,
- schnell,
- nachvollziehbar.
LLM-basiert
Beispiele:
- Überschriften rekonstruieren,
- Tabellen interpretieren,
- Kontextbeschreibung erzeugen,
- Dokument klassifizieren,
- Chunk Summary erstellen.
Vorteile:
- flexibler bei unstrukturierten Daten.
Nachteile:
- teurer,
- langsamer,
- nicht vollständig deterministisch,
- potenziell halluzinierend.
96. Reprocessing
Wenn sich eine wichtige Ingestion-Entscheidung ändert, müssen Dokumente häufig erneut verarbeitet werden.
Beispiele:
anderer Parser
anderes Chunking
anderes Embedding-Modell
andere Metadaten
Dann spricht man häufig von:
Reprocessing oder Re-Indexing.
Das ist ein wichtiger Unterschied zu Änderungen, die nur die spätere Suche betreffen.
97. Re-Indexing
Re-Indexing bedeutet, den Suchindex neu aufzubauen.
Beispiel:
alte Chunks
↓
löschen
Dokumente
↓
neue Chunking-Regel
↓
neue Chunks
↓
neuer Index
Bei grossen Korpora kann Re-Indexing erheblichen Aufwand verursachen.
Deshalb sind Ingestion-Entscheidungen langfristig relevant.
98. Index Drift
Wenn Dokumente mit unterschiedlichen Einstellungen verarbeitet wurden, kann Index Drift entstehen.
Beispielsweise:
alte Dokumente:
Embedding Model A
Chunk Size 500
neue Dokumente:
Embedding Model B
Chunk Size 1'000
Der Index ist dann nicht mehr homogen.
Das kann Retrieval unvorhersehbar machen.
99. Embedding-Versionen
Besonders kritisch ist der Wechsel eines Embedding-Modells.
Vektoren verschiedener Modelle sind normalerweise nicht direkt vergleichbar.
Wenn Dokumente mit Modell A eingebettet wurden und die Query mit Modell B, funktioniert semantische Ähnlichkeit nicht sinnvoll.
Deshalb müssen Modellversionen sauber verwaltet werden.
100. Chunking-Versionen
Auch Chunking-Regeln können versioniert werden.
Beispiel:
chunking_version: 3
Damit lässt sich nachvollziehen, mit welcher Strategie ein Chunk erzeugt wurde.
Das ist hilfreich für:
- Reprocessing,
- Debugging,
- Evaluation,
- Migrationen.
101. Evaluation von Chunking
Chunking sollte nicht nur nach Bauchgefühl gewählt werden.
Man kann verschiedene Strategien testen.
Beispielsweise:
Strategie A:
500 Tokens, 50 Overlap
Strategie B:
strukturierte Abschnitte
Strategie C:
Parent-Child
Danach misst man:
Findet das Retrieval die richtigen Passagen?
Chunking-Evaluation ist deshalb letztlich Retrieval-Evaluation.
102. Gold Questions
Für Tests benötigt man Fragen mit bekannten relevanten Quellen.
Beispiel:
Frage:
Wie lange ist die Kündigungsfrist während der Probezeit?
Relevant:
Dokument A, Abschnitt 3.2
Dann kann man messen, ob unterschiedliche Chunking-Strategien den relevanten Abschnitt in die Top-k bringen.
103. Retrieval Granularity
Retrieval Granularity beschreibt die Grösse der Einheit, auf der gesucht wird.
Mögliche Ebenen:
Dokument
Kapitel
Abschnitt
Chunk
Satz
Record
Feine Granularität bietet hohe Präzision.
Grobe Granularität liefert mehr Kontext.
Parent-Child Retrieval versucht genau diesen Konflikt zu entschärfen.
104. Storage Granularity
Die Storage Granularity muss nicht mit der Retrieval Granularity identisch sein.
Ein System könnte beispielsweise speichern:
Dokument
Section
Chunk
aber nur auf Chunk-Ebene suchen.
Die anderen Ebenen dienen später der Kontextrekonstruktion.
105. Retrieval Unit versus Context Unit
Eine der wichtigsten Begriffsunterscheidungen dieses Teils:
Retrieval Unit
Die Einheit, die gesucht und gerankt wird.
Context Unit
Die Einheit, die dem LLM tatsächlich gegeben wird.
Beispiel:
Retrieval Unit:
2 Sätze
Context Unit:
ganzer Abschnitt
Das ist die Grundlage für Parent-Child und Small-to-Big Retrieval.
106. Source of Truth
Bei Chunk-basierten Systemen sollte der Chunk nicht zwingend die einzige gespeicherte Wahrheit sein.
Ideal ist häufig:
Originaldokument
↓
strukturierte Repräsentation
↓
Chunks
Das Original bleibt die Source of Truth.
Chunks sind abgeleitete Retrieval-Artefakte.
Das erleichtert später:
- Reprocessing,
- neue Chunking-Verfahren,
- neue Embeddings,
- bessere Parser.
107. Lossy versus Lossless Processing
Lossless Processing versucht, Information vollständig zu erhalten.
Lossy Processing verwirft oder verdichtet bewusst Information.
Beispiel:
Originaldokument:
10 Seiten
Zusammenfassung:
1 Seite
Die Zusammenfassung ist lossy.
Das kann für Retrieval hilfreich sein, darf aber nicht mit dem Original verwechselt werden.
108. Summaries sind keine Originalquellen
Automatisch erzeugte Dokument- oder Chunk-Zusammenfassungen können nützlich sein.
Sie sollten aber als abgeleitete Information betrachtet werden.
Denn ein Summary-Modell kann:
- Details auslassen,
- Zahlen verändern,
- Nuancen verlieren,
- falsche Schlüsse ziehen.
Für quellengebundene Antworten sollte möglichst weiterhin auf Originalpassagen zurückgegriffen werden.
109. Metadata Filtering
Metadaten können später beim Retrieval als Filter dienen.
Beispielsweise:
year = 2026
language = de
document_type = policy
Das ist effizienter, als jede Information nur über semantische Ähnlichkeit zu lösen.
Dafür müssen die Metadaten bereits während der Ingestion sauber vorhanden sein.
110. Metadata Enrichment
Metadaten können aus verschiedenen Quellen stammen.
Direkt aus der Datei
Dateiname
Author
Creation Date
Aus dem Inhalt
Titel
Kapitel
Sprache
Datum
Extern
SharePoint Site
Folder
Owner
Permission
Generiert
Thema
Zusammenfassung
Klassifikation
Generierte Metadaten sind nützlich, aber weniger verlässlich als direkt vorhandene.
111. Permissions als Metadaten
In Unternehmenssystemen kann auch die Zugriffsberechtigung mit Dokumenten oder Chunks verbunden sein.
Beispielsweise:
allowed_group = HR
Dann darf Retrieval diese Inhalte nur für entsprechende Benutzer berücksichtigen.
Das ist kein klassisches Chunking-Thema, gehört aber zur korrekten Ingestion von Unternehmenswissen.
Denn Berechtigungen müssen spätestens beim Indexieren oder Retrieval erhalten bleiben.
112. Chunk Provenance
Provenance bedeutet Herkunft und Nachvollziehbarkeit.
Für einen Chunk sollte idealerweise klar sein:
aus welchem Dokument?
welche Version?
welche Seite?
welcher Abschnitt?
welcher Parser?
welcher Chunker?
Diese Informationen sind besonders wertvoll für Debugging.
113. Warum Provenance wichtig ist
Angenommen, ein System liefert eine falsche Antwort.
Im Trace erscheint:
Chunk 5832
Ohne weitere Metadaten ist das kaum hilfreich.
Mit Provenance:
Document: Personalreglement 2026
Page: 7
Heading: Probezeit > Kündigung
Chunk Index: 12
lässt sich sofort nachvollziehen, woher der Treffer stammt.
114. Ingestion Observability
Auch die Ingestion selbst sollte beobachtbar sein.
Nützliche Kennzahlen können sein:
Dokumente verarbeitet
Dokumente fehlgeschlagen
OCR verwendet
Textlänge
Chunk-Anzahl
durchschnittliche Chunk-Grösse
Duplikate
leere Dokumente
Ein Dokument mit:
0 Chunks
ist zwar möglicherweise technisch „verarbeitet“, für Retrieval aber wertlos.
115. Empty Documents
Manche Dateien liefern nach Parsing keinen verwertbaren Text.
Gründe:
- Scan ohne OCR,
- beschädigte Datei,
- DRM,
- ungewöhnliche Codierung,
- parserseitiger Fehler.
Solche Dokumente sollten nicht stillschweigend als erfolgreich indexiert gelten.
116. Very Short Documents
Sehr kurze Dokumente benötigen häufig kein klassisches Chunking.
Beispiel:
Passwort muss mindestens 14 Zeichen besitzen.
Dieser gesamte Text kann ein Chunk sein.
Ein fixer Chunker sollte nicht künstlich versuchen, jeden Inhalt gleich zu behandeln.
117. Very Large Documents
Sehr grosse Dokumente benötigen dagegen möglicherweise mehrere Hierarchiestufen.
Beispiel:
2'000 Seiten
Ein rein flaches Chunking kann zehntausende Chunks erzeugen.
Dann werden Dokument-Level- oder Section-Level-Repräsentationen interessant.
118. Chunk Explosion
Als Chunk Explosion kann man informell das Problem bezeichnen, dass aggressive Split-Regeln sehr viele kleine Chunks erzeugen.
Beispiel:
1'000 Dokumente
→ 300'000 Chunks
Das erhöht:
- Indexgrösse,
- Embedding-Kosten,
- Retrieval-Kandidaten,
- Speicherbedarf.
Mehr Chunks bedeuten nicht automatisch bessere Qualität.
119. Chunk Compression
Umgekehrt können Chunks nachträglich komprimiert oder gefiltert werden.
Eine Form ist Contextual Compression.
Dabei wird aus einem gefundenen Chunk nur der für die Frage relevante Teil übernommen.
Beispiel:
Chunk:
Probezeit dauert drei Monate.
Kündigungsfrist beträgt sieben Tage.
Ferienanspruch besteht anteilig.
Frage:
Wie lange ist die Kündigungsfrist?
Komprimierter Kontext:
Kündigungsfrist beträgt sieben Tage.
Contextual Compression gehört technisch eher in den Query-Pfad, steht aber in engem Zusammenhang mit Chunk-Grösse.
120. Chunking ist keine einmalige Wahrheit
Es existiert keine allgemeingültige Regel:
512 Tokens sind optimal.
oder:
20 % Overlap sind optimal.
Solche Werte sind Startpunkte.
Die richtige Chunking-Strategie hängt vom Korpus und den tatsächlichen Fragen ab.
Ein Gesetz, ein Code-Repository und ein Meeting-Transkript benötigen unterschiedliche Ansätze.
121. Der richtige Denkansatz
Die bessere Frage lautet nicht:
Welche Chunk Size sollte ich verwenden?
Sondern:
Welche Informationseinheiten müssen in meinem Korpus gemeinsam erhalten bleiben, damit die typischen Benutzerfragen beantwortbar bleiben?
Erst danach kommen technische Parameter.
122. Beispiel: Reglement
Original:
3. Probezeit
3.1 Dauer
Die Probezeit beträgt drei Monate.
3.2 Kündigung
Während der Probezeit kann das Arbeitsverhältnis
mit einer Frist von sieben Tagen gekündigt werden.
Eine sinnvolle Repräsentation könnte sein:
Chunk 1
Heading Path:
Probezeit > Dauer
Text:
Die Probezeit beträgt drei Monate.
Chunk 2
Heading Path:
Probezeit > Kündigung
Text:
Während der Probezeit kann das Arbeitsverhältnis
mit einer Frist von sieben Tagen gekündigt werden.
Damit sind beide Regeln getrennt auffindbar, behalten aber ihren Kontext.
123. Beispiel: Schlechte Variante
Chunk 1:
3. Probezeit 3.1 Dauer Die Probezeit beträgt drei Monate.
3.2 Kündigung Während
Chunk 2:
der Probezeit kann das Arbeitsverhältnis mit einer Frist
von sieben Tagen gekündigt werden.
Die Chunk-Grenze liegt mitten in einer Aussage.
Das Retrieval muss nun trotz künstlicher Trennung korrekt funktionieren.
Das ist vermeidbar.
124. Beispiel: Zu grosse Variante
Chunk 1:
gesamtes Personalreglement,
18'000 Wörter
Die Information ist vollständig vorhanden.
Aber das Retrieval erhält eine sehr unspezifische Repräsentation.
Die relevante Passage ist semantisch nur ein kleiner Anteil des Chunks.
125. Beispiel: Parent-Child
Retrieval-Chunks:
Child A:
Die Probezeit beträgt drei Monate.
Child B:
Die Kündigungsfrist beträgt sieben Tage.
Parent:
Probezeit
Die Probezeit beträgt drei Monate.
Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Nach Ablauf gelten die ordentlichen Fristen.
Suche:
Wie lang ist die Kündigungsfrist während der Probezeit?
Retriever findet:
Child B
Prompt erhält:
Parent
Das ist das Kernprinzip von Small-to-Big Retrieval.
126. Typische Chunking-Fehler
Zu den häufigsten Fehlern gehören:
- starre Chunk-Grösse für alle Dokumenttypen,
- Überschriften werden vom Inhalt getrennt,
- Tabellen werden linearisiert und zerstört,
- Seitenköpfe werden mehrfach indexiert,
- zu grosser Overlap,
- zu kleine Chunks,
- zu grosse Chunks,
- Dokumenttitel gehen verloren,
- Parent-Beziehungen fehlen,
- Quellenpositionen werden nicht gespeichert,
- OCR-Fehler werden ignoriert,
- alte Dokumentversionen bleiben im Index.
127. Was Chunking nicht lösen kann
Chunking ist wichtig, aber kein Allheilmittel.
Es kann nicht automatisch lösen:
- falsche Dokumente,
- veraltete Informationen,
- fehlende Berechtigungen,
- schlechte OCR,
- widersprüchliche Quellen,
- ungeeignete Retrieval-Verfahren,
- Halluzinationen des LLM.
Chunking ist eine Stufe in der gesamten Pipeline.
128. Parsing, Chunking und Retrieval sauber trennen
Diese drei Begriffe werden häufig vermischt.
Parsing
Datei → Inhalt
Chunking
Inhalt → Einheiten
Retrieval
Frage → relevante Einheiten
Schematisch:
PDF
↓
Parsing
↓
strukturierter Text
↓
Chunking
↓
Chunks
↓
Index
↓
Retrieval
↓
relevante Chunks
Diese Trennung ist zentral.
129. Chunking versus Indexing
Chunking erzeugt Retrieval-Einheiten.
Indexing macht diese Einheiten effizient durchsuchbar.
Beispielsweise:
Chunk
↓
Embedding
↓
Vector Index
oder:
Chunk
↓
Tokenisierung
↓
BM25 Index
Dieselbe Chunking-Struktur kann theoretisch mit unterschiedlichen Indizes verwendet werden.
130. Chunking versus Embedding
Auch diese Begriffe sind getrennt.
Text
↓
Chunking
↓
Chunk
↓
Embedding
↓
Vector
Chunking entscheidet, welcher Text zusammengehört.
Embedding entscheidet, wie dieser Text numerisch repräsentiert wird.
Teil 3 behandelt genau diesen nächsten Schritt.
131. Begriffsübersicht
| Begriff | Bedeutung |
|---|---|
| Ingestion | Aufnahme und Aufbereitung von Wissen für Retrieval |
| Parsing | strukturierte Interpretation eines Datenformats |
| Text Extraction | Extraktion von Text ohne zwingenden Strukturerhalt |
| Layout Parsing | Erkennung visueller Dokumentstruktur |
| OCR | Texterkennung aus Bildern oder Scans |
| Normalisierung | Bereinigung technischer Textartefakte |
| Boilerplate | wiederkehrender, meist irrelevanter Dokumentinhalt |
| Metadaten | zusätzliche Informationen über Dokument oder Chunk |
| Chunk | kleinere Retrieval-Einheit eines grösseren Dokuments |
| Chunk Size | maximale beziehungsweise angestrebte Chunk-Grösse |
| Overlap | überlappender Inhalt benachbarter Chunks |
| Fixed-Size Chunking | Zerlegung nach fixer Länge |
| Sliding Window | fixe Fenster mit Overlap |
| Sentence Chunking | Zerlegung entlang von Satzgrenzen |
| Paragraph Chunking | Zerlegung entlang von Absätzen |
| Recursive Chunking | schrittweise Nutzung verschiedener Trennzeichen |
| Structured Chunking | Chunking anhand logischer Dokumentstruktur |
| Semantic Chunking | Chunk-Grenzen anhand semantischer Themenwechsel |
| Page Chunking | eine Seite als Retrieval-Einheit |
| Section Chunking | Abschnitte als Grundeinheit |
| Heading Path | hierarchischer Überschriftenpfad eines Chunks |
| Parent-Child Retrieval | kleine Chunks suchen, grösseren Parent liefern |
| Small-to-Big | kleine Retrieval-Einheit, grössere Prompt-Einheit |
| Neighbor Expansion | benachbarte Chunks zusätzlich laden |
| Hierarchical Chunking | mehrere Dokumentebenen als Retrievalstruktur |
| Late Chunking | Kontext vor der finalen Chunk-Repräsentation berücksichtigen |
| Chunk Enrichment | Chunks um zusätzlichen Kontext erweitern |
| Contextual Retrieval | Chunks mit Dokumentkontext für Suche anreichern |
| Provenance | Herkunft und Nachvollziehbarkeit eines Chunks |
| Reprocessing | Dokumente erneut durch die Ingestion schicken |
| Re-Indexing | Suchindex neu erzeugen |
| Index Drift | inkonsistente Indexierung über verschiedene Versionen |
| Retrieval Unit | Einheit, auf der gesucht wird |
| Context Unit | Einheit, die dem LLM bereitgestellt wird |
132. Die wichtigste Erkenntnis aus Teil 2
Die Qualität eines RAG-Systems beginnt nicht beim LLM.
Sie beginnt beim Dokument.
Original
↓
Parsing
↓
Struktur
↓
Chunking
↓
Repräsentation
↓
Index
↓
Retrieval
Wenn in den ersten Stufen Information verloren geht, kann keine spätere Stufe sie zuverlässig zurückholen.
Deshalb lautet eine der wichtigsten Regeln beim Aufbau von RAG-Systemen:
Chunking ist kein Split-Parameter. Chunking ist Informationsmodellierung.
Man entscheidet damit, welche Einheiten später als Wissen betrachtet werden.
Ein guter Chunk ist nicht einfach „ungefähr 500 Tokens lang“.
Er ist:
- semantisch zusammenhängend,
- ausreichend vollständig,
- nachvollziehbar,
- mit seinem Ursprung verbunden,
- für Retrieval präzise genug,
- für die spätere Antwort kontextreich genug.
Und genau nach dem Chunking beginnt die nächste grosse Frage:
Wie verwandelt man Text in eine mathematische Repräsentation, mit der semantische Ähnlichkeit berechnet werden kann?
Das führt direkt zu Embeddings und Vektorsuche.
RAG von Grund auf
Teil 1 – RAG verstehen
LLM, parametrisches Wissen, Kontext, Retrieval, Augmentation, Generation und Grounding.
Teil 2 – Dokumente, Parsing und Chunking
Ingestion, Parser, OCR, Dokumentstruktur, Chunks, Overlap, Structured Chunking, Parent-Child und Small-to-Big.
Teil 3 – Embeddings und Vektorsuche
Embeddings, Dense Vectors, Ähnlichkeitsmasse, Vector Stores, ANN und HNSW.
Teil 4 – Information Retrieval und Hybrid Search
TF, IDF, TF-IDF, BM25, Sparse Search, Dense Search, Hybrid Retrieval und RRF.
Teil 5 – Reranking und Retrieval-Strategien
Bi-Encoder, Cross-Encoder, Top-k, MMR, Query Rewrite, Multi-Query und HyDE.
Teil 6 – Kontext, Grounding und Antworten
Token-Budget, Kontextfenster, Lost in the Middle, Faithfulness, Citations und Answerability.
Teil 7 – Advanced RAG
Naive RAG, Modular RAG, Multi-Hop, Self-RAG, CRAG, RAPTOR, GraphRAG, ColBERT und Agentic RAG.
Teil 8 – Evaluation, Sicherheit und Abgrenzung
Recall, Precision, Hit@k, MRR, nDCG, RAG-Evaluation, Prompt Injection, RAG Poisoning, Fine-Tuning und Tool Calling.