Zum Inhalt springen
GraphRAG Compass
  • Grundlagen
  • Architekturen
  • Praxis
  • Business Cases
  • Lernpfad
  • Simulation
  • Landkarte
GraphRAG Compass

Öffentlicher Field Guide für GraphRAG, Knowledge Graphs, AI-Architekturen und bessere Entscheidungen in komplexen Wissenssystemen.

Erkunden

  • Grundlagen
  • Architekturen
  • Praxis
  • Business Cases
  • Simulation
  • Landkarte

Lernen

  • Lernpfad
  • Mini-Use-Case
  • GraphRAG Poster
  • Glossar

Über

  • About
  • LinkedIn

Discovery

  • llms.txt
  • llms-full.txt
  • sitemap.xml

Rechtliches

  • Impressum
  • Datenschutz

© 2026 Meierhoff Systems · GraphRAG Compass

Orientierung für Entscheidungen in Wissenssystemen

Zurück zu Praxis

Praxis · Daten vorbereiten

Chunking & Document Processing

Chunking und Document Processing machen aus PDFs, Webseiten, Tabellen und Wikis suchbare, zitierbare Wissenseinheiten.

Daten vorbereiten
Chunking
Querschnittsthema

Wie werden Dokumente so vorbereitet, dass Retrieval stabil wird?

2 Min LesezeitDaten vorbereiten

Warum es wichtig ist

Viele RAG-Probleme entstehen vor dem Retrieval: Tabellen gehen verloren, Überschriften werden getrennt, Versionen fehlen oder Chunks schneiden genau an der falschen Stelle.

Kernideen

Die wichtigsten Prinzipien dieses Themas auf einen Blick.

1

Dokumentstruktur erhalten: Überschriften, Tabellen, Listen, Fußnoten und Anhänge haben semantische Bedeutung.

2

Chunkgröße ist eine Produktentscheidung: Der Chunk muss auffindbar sein und genug Bedeutung für die Antwort tragen.

3

Parent/Child-Chunks verbinden präzise Suche mit genügend Kontext.

4

Metadaten wie Quelle, Datum, Version, Sprache, Abschnitt und Berechtigung gehören zum Vektorindex- und Retrieval-Design.

Startfragen

Diese Fragen machen das Thema praktisch prüfbar. Hak sie ab – sie eignen sich als Einstieg für Workshops, Pilotvorhaben oder Architekturreviews.

0/4 geprüft

Die Grundidee

Chunking bedeutet nicht einfach: Text in gleich große Stücke schneiden. Für RAG ist ein Chunk die kleinste sinnvolle Wissenseinheit, die gefunden, zitiert und in eine Antwort eingebaut werden kann. Document Processing ist die Vorarbeit dafür: Dokumente werden so gelesen, bereinigt, strukturiert und mit Metadaten versehen, dass Retrieval später nicht gegen kaputte Textfragmente arbeitet.

Vom Dokument zum suchbaren Kontext

Eine stabile RAG-Pipeline entsteht meistens in diesen Schritten. Jeder Schritt kann Retrievalqualität verbessern oder beschädigen.

  1. 1

    Dokument laden: PDF, HTML, Markdown, Office-Datei, Ticket oder Wiki-Seite.

  2. 2

    Struktur erkennen: Titel, Überschriften, Tabellen, Listen, Seiten, Anhänge und Fußnoten.

  3. 3

    Text bereinigen: Navigation, doppelte Header, kaputte Zeilenumbrüche und irrelevante Boilerplate entfernen.

  4. 4

    Chunks schneiden: entlang semantischer Grenzen und mit passender Länge.

  5. 5

    Metadaten ergänzen: Quelle, Version, Datum, Berechtigung, Dokumenttyp und Abschnitt.

  6. 6

    Qualität prüfen: echte Fragen gegen erwartete Quellen testen.

Praktische Muster

Es gibt nicht die eine perfekte Chunkgröße. Gute Verarbeitung orientiert sich an Dokumenttyp, Frageform und späterem Antwortformat.

Abschnitts-Chunking

Dokumente haben klare Überschriften, Kapitel oder FAQ-Fragen.

Der Chunk folgt der natürlichen Dokumentstruktur. Das ist oft besser als starre Tokenlängen.

Parent/Child-Chunking

Kleine Textstücke lassen sich gut finden, brauchen aber mehr Umfeld für die Antwort.

Gesucht wird im kleinen Child-Chunk, geantwortet wird mit dem größeren Parent-Abschnitt.

Tabellen separat behandeln

PDFs enthalten Tabellen, Spalten, Fußnoten oder Werte, die beim normalen Textauszug zerfallen.

Tabellen brauchen eigene Extraktion und Metadaten, sonst findet Retrieval zwar Text, aber nicht die Bedeutung.

Metadaten als Filter

Version, Datum, Dokumenttyp, Abteilung oder Berechtigung entscheiden, ob ein Treffer überhaupt zählen darf.

Gute Metadaten verhindern, dass semantisch ähnliche, aber fachlich falsche Quellen in den Kontext kommen.

Beispiele

Diese Beispiele zeigen, warum Chunking eine fachliche und technische Parameter.

HR-Policy

Schlecht

Alle 1.000 Zeichen schneiden. Dadurch landet die Überschrift in einem Chunk und die Ausnahme im nächsten.

Besser

Nach Überschriften und Unterabschnitten schneiden. Ausnahme, Regel und Quelle bleiben zusammen.

Vertrag

Schlecht

Klauseln, Anhänge und Definitionen als flachen Text behandeln.

Besser

Klauselnummer, Abschnitt, Vertragspartner, Version und Gültigkeitsdatum als Metadaten speichern.

Technische Dokumentation

Schlecht

Codeblöcke, Warnhinweise und Tabellen in denselben Fließtext pressen.

Besser

Code, Warnungen und Tabellen separat extrahieren und mit Überschrift und Produktversion verbinden.

Metadaten, die wirklich helfen

Metadaten sind nicht Beiwerk. Sie entscheiden, welche Treffer überhaupt zulässig sind und welche Quellen in einer Antwort genannt werden können.

Quelle
Dokumenttyp
Version
Datum
Abschnitt
Sprache
Berechtigung
Owner

Typische Fehler

Viele Retrieval-Probleme sehen wie Modellprobleme aus, entstehen aber in Wahrheit beim Dokumentimport.

  • Nur nach Zeichen oder Tokens schneiden: Das ist einfach, zerstört aber oft Sinnzusammenhänge.
  • Tabellen ignorieren: Viele wichtige Antworten stecken in Tabellen, nicht im Fließtext.
  • Keine Versionen speichern: Alte Policies können sonst aktueller wirken als neue.
  • Zu große Chunks: Sie enthalten viel Kontext, aber schlechte Trefferpräzision.
  • Zu kleine Chunks: Sie sind präzise auffindbar, beantworten aber die Frage nicht vollständig.
  • Keine Berechtigungsmetadaten: Retrieval darf nicht mehr zeigen, nur weil der Text semantisch passt.

Verwandte Konzepte

RAGVektorindexHybrid Retrieval
Nächstes ThemaEntity Resolution & IdentityDaten vorbereiten