Die vorliegende Studie zeigt, dass strukturierte Datenformate und intelligente Chunking-Strategien entscheidend für die Leistungsfähigkeit von RAG-Systemen sind. Unterschiedliche Segmentierungsmethoden wie rekursives, satzbasiertes, semantisches oder agentic Chunking ermöglichen eine passgenaue Aufbereitung für unterschiedliche LLMs – vorausgesetzt, sie basieren auf sauber strukturierten, medienneutralen Ausgangsdaten.

Die Analyse verschiedener Formate zeigt, dass unstrukturierte Quellen wie PDFs deutliche Nachteile aufweisen, insbesondere im Hinblick auf Metadaten, Kontextwahrung und Referenzierbarkeit. Markdown und XML hingegen bieten durch explizite Strukturierung eine solide Grundlage für automatisiertes Chunking und semantische Erschließung.

In der Fallstudie eines Wissenschaftsverlags wird gezeigt, wie ein zentraler XML-Hub kombiniert mit dynamischer Chunk-Generierung und einem Content Delivery Service (CDS) ein nachhaltiges, anpassungsfähiges RAG-Ökosystem ermöglichen kann. Besonders hervorgehoben wird die Trennung von Datenstrukturierung und Datenhaltung als Schlüssel zur technologischen Unabhängigkeit und Zukunftssicherheit.

Die Studie liefert nicht nur theoretische Grundlagen, sondern auch konkrete Umsetzungsempfehlungen, etwa zur Wahl geeigneter Chunk-Größen, zur Gestaltung von Overlapping und Redundanz, zur semantischen Anreicherung durch Metadaten sowie zur Integration von Embedding-Software und Vektordatenbanken.

Im Anschluss an diese Studie folgen zwei weitere Untersuchungen:

1. Automatisiertes Chunking aus allen Formaten:
   Entwicklung einer vollautomatischen Infrastruktur zur Erzeugung beliebiger Chunk-Strategien, unterstützt durch das System Octopus, das auch aus PDFs medienneutrale Strukturen extrahiert.
2. Zusammenarbeit mit dem CDS:
   Untersuchung der Rolle eines Content Delivery Services (CDS) als semantische Vermittlungsschicht zwischen strukturierten Inhalten und RAG-Komponenten – mit RDF, SPARQL und containerbasierten Zugriffskonzepten (z. B. iiRDS).

Diese nächsten Studienabschnitte werden zeigen, wie aus strukturierten Inhalten und intelligenter Systemarchitektur ein leistungsfähiges, modell-agnostisches RAG-System entstehen kann.

Die Grundlage jedes RAG-Systems bildet die effiziente und strukturierte Verarbeitung von Datenquellen. Der Prozess beginnt mit der Auswahl und Aufbereitung geeigneter Dokumente. Dabei spielen sowohl die Formatvielfalt als auch der Strukturierungsgrad der Ausgangsdaten eine zentrale Rolle. Dokumente können in unterschiedlichen Formaten vorliegen – typischerweise als PDF, HTML, Markdown oder XML. Während strukturierte Formate wie XML oder Markdown semantische Informationen wie Überschriften, Absätze, Fußnoten oder Metadaten explizit auszeichnen, sind diese Informationen in PDF-Dokumenten nur implizit vorhanden oder sogar verloren gegangen. Dies erschwert die automatische Verarbeitung erheblich.

Nach der Extraktion der Inhalte erfolgt das sogenannte Chunking. Dabei werden die Textinhalte in kleinere Einheiten unterteilt, um sie für Sprachmodelle besser verarbeitbar zu machen. Die Größe der Chunks kann nach verschiedenen Kriterien gewählt werden – z. B. nach Wortanzahl, Zeichenanzahl oder Tokens. Letzteres ist besonders relevant, da LLMs intern mit Tokens arbeiten und eine maximale Kontextlänge aufweisen. Chunking dient nicht nur der technischen Limitierung, sondern trägt auch zur besseren Kontextualisierung der Daten bei. Überlappende Chunks werden eingesetzt, um Informationsbrüche an den Segmentgrenzen zu vermeiden.

Optional kann semantisches Tagging durchgeführt werden. Dabei werden Chunks mit Metainformationen versehen, etwa zur thematischen Einordnung, Autorenschaft oder Kapitelzugehörigkeit. Dies erleichtert die spätere Suche nach kontextrelevanten Inhalten. Anschließend werden die Chunks durch ein Embedding-Modell in mehrdimensionale Vektoren überführt, welche die semantische Bedeutung der Inhalte abbilden. Diese Vektoren werden in einer Vektordatenbank gespeichert – z. B. FAISS, ChromaDB oder Pinecone – und bilden den Index für das Retrieval-Modul des RAG-Systems.

Die zweite zentrale Komponente eines RAG-Systems ist der Antwortprozess. Ausgangspunkt ist eine Nutzeranfrage, die in natürlicher Sprache formuliert wird. Diese wird im ersten Schritt in einen semantischen Vektor umgewandelt – analog zur Indexierung der Dokumenten-Chunks – mithilfe des identischen oder eines kompatiblen Embedding-Modells.

Im nächsten Schritt erfolgt das sogenannte Retrieval. Dabei wird der Anfragevektor mit den in der Vektordatenbank gespeicherten Chunks verglichen. Ziel ist es, jene Textabschnitte zu identifizieren, deren semantische Nähe zur Anfrage am größten ist. Dies basiert typischerweise auf Metriken wie dem Kosinus-basierten Ähnlichkeitsmaß. Die relevantesten Chunks – meist die Top-N-Retrievals – werden ausgewählt und dem Sprachmodell als Kontext übergeben.

In der abschließenden Phase generiert das LLM eine Antwort unter Berücksichtigung der abgerufenen Chunks. Dieser Vorgang kann als kontextgestützte Generierung bezeichnet werden. Das Modell nutzt die übergebenen Dokumentauszüge als Wissensbasis, formuliert aber die Antwort autonom in natürlicher Sprache. Dadurch entsteht eine Synergie aus datengetriebener Präzision und sprachlicher Flexibilität.

Der Erfolg eines RAG-Systems hängt maßgeblich von der Qualität der Chunks, der Leistungsfähigkeit der Embeddings sowie der Effektivität der Retrieval-Komponente ab. Eine präzise abgestimmte Pipeline zwischen Dokumentaufbereitung, Vektorisierung und Antwortgenerierung ist entscheidend für den praktischen Nutzen.

Ein oft unterschätzter Aspekt bei der Implementierung von RAG-Systemen ist die Formatabhängigkeit in Bezug auf das eingesetzte Large Language Model (LLM). Nicht jedes Modell verarbeitet alle Datenformate gleichermaßen effektiv. Es hat sich gezeigt, dass strukturierte Formate wie Markdown häufig zu besseren Antwortqualitäten führen – insbesondere bei Modellen, die explizite semantische Strukturen aus dem Text extrahieren und kontextuell weiterverarbeiten können. Markdown bietet durch klar definierte Elemente wie Überschriften, Listen, Tabellen und Fußnoten eine zusätzliche semantische Schicht, die von modernen LLMs gut interpretiert werden kann.

Demgegenüber steht die Verwendung von Plain Text, der keinerlei semantische Markierungen aufweist. Während dieser für manche Anwendungsfälle ausreichend sein kann, fehlt ihm häufig die strukturelle Tiefe, um komplexe Kontexte exakt abzubilden. Daher ist es bei der Gestaltung eines RAG-Systems ratsam, je nach LLM-Architektur und Zielanwendung eine geeignete Datenaufbereitung zu wählen. Eine format-adaptive Strategie kann die Antwortqualität signifikant verbessern und sollte als Best Practice etabliert werden.

Chunks sind kleine, logisch zusammenhängende Textsegmente, in die ein großer Text zerlegt wird. Diese Zerlegung ist insbesondere in der Arbeit mit großen Sprachmodellen (Large Language Models, LLMs) wie GPT oder Claude wichtig. Da diese Modelle nur eine begrenzte Menge an Text gleichzeitig verarbeiten können (z. B. 4.000 bis 32.000 Tokens), müssen längere Inhalte in verdaubare Einheiten unterteilt werden.

Ein Chunk kann beispielsweise sein:

• 300 Wörter
• 500 Zeichen
• 200 Tokens (wie von Sprachmodellen genutzt)

Je nach Anwendungsfall und Modell kommen unterschiedliche Strategien zum Einsatz. Manche Systeme chunken nach Absätzen, andere entlang semantischer Einheiten oder nach einer fixen Längenvorgabe.

Es gibt technische, strukturelle und semantische Gründe, Texte in Chunks zu unterteilen:

1. Modellbegrenzungen
   LLMs können nur eine bestimmte Kontextlänge verarbeiten. Ohne Chunking wären längere Texte gar nicht nutzbar.
2. Leichtere Analyse
   Kleinere Einheiten sind einfacher zu durchsuchen, zu analysieren und zu bewerten – etwa im Information Retrieval oder bei der Embedding-Erstellung.
3. Erhalt von Kontext
   Mit intelligentem Chunking (z. B. überlappende Segmente) lassen sich Zusammenhänge über Chunk-Grenzen hinweg bewahren.
4. Effizienteres Prompting
   Chunks können selektiv in Prompts eingebunden werden, sodass das Modell nur relevante Teile erhält – das spart Kosten und erhöht die Präzision.

Originaltext (Auszug Anfangssatz):

„Als Gregor Samsa eines Morgens aus unruhigen Träumen erwachte, fand er sich in seinem Bett zu einem ungeheueren Ungeziefer verwandelt.“

Wortbasiertes Chunking (10-Wörter-Chunks):

• Chunk 1: „Als Gregor Samsa eines Morgens aus unruhigen Träumen erwachte fand“
• Chunk 2: „er sich in seinem Bett zu einem ungeheueren Ungeziefer verwandelt“

Token-basiertes Chunking (Beispiel mit GPT-4 Tokenizer, vereinfacht):

• Chunk 1: ["Als", "Gregor", "Samsa", "eines", "Morgens", "aus", "unruhigen", "Träumen", "erwachte", "fand"]
• Chunk 2: ["er", "sich", "in", "seinem", "Bett", "zu", "einem", "ungeheueren", "Ungeziefer", "verwandelt", "."]

Chunking mit semantischer Annotation in JSON codiert

{
  "content": "Als Gregor Samsa eines Morgens ...",
  "metadata": {
    "person": "Gregor Samsa",
    "motiv": "Verwandlung",
    "werk": "Die Verwandlung"
  }
}

Die Wahl der richtigen Chunk-Größe ist ein zentrales Element beim Aufbau eines performanten RAG-Systems. Sie beeinflusst direkt:

• wie viel Kontext ein Modell verarbeiten kann,
• wie präzise und vollständig Antworten ausfallen,
• wie effizient Speicher- und Rechenressourcen genutzt werden.

Eine zu große Chunk-Größe kann dazu führen, dass relevante Inhalte vom Modell abgeschnitten werden oder unnötiger Kontext eingebettet wird. Eine zu kleine Chunk-Größe wiederum erhöht die Anzahl der Chunks, erschwert das Retrieval und kann den Zusammenhang zerreißen.

Diese Werte sind keine starren Regeln, sondern Richtwerte. Entscheidend ist der Einsatzzweck: Für klassische Frage-Antwort-Szenarien genügen oft 300–500 Tokens. Für semantische Suche mit Kontextaggregation können größere Chunks sinnvoll sein.

Empfehlungen für die Praxis

1. Puffer einplanen
   Mindestens 20–30 % der Kontextlänge sollten für Prompts, Anweisungen und Modellantworten reserviert bleiben.
2. Chunk-Größe dynamisch anpassen
   Anstatt fixer Token-Anzahl kann Chunking entlang semantischer Grenzen erfolgen (Absätze, Zwischenüberschriften), ergänzt durch Token-Limits.
3. Größe mit Overlap kombinieren
   Bei 600 Tokens Chunk-Größe kann z. B. ein Overlap von 100–150 Tokens sinnvoll sein, um Kontextübergänge zu glätten.
4. Analyse- und Antworttyp berücksichtigen
   • Für faktische Antworten: kleinere Chunks, prägnant.
   • Für kreative/analytische Aufgaben: größere Chunks, mehr Kontext.
5. Testen und iterieren
   Ideale Chunk-Größen variieren je nach Textgattung (Belletristik ≠ Forschung ≠ News). A/B-Tests oder Recall/Precision-Messungen helfen bei der Optimierung.

3.3.1 Was ist die Kontextlänge eines LLMs überhaupt?

3.3.2 Warum ein Puffer notwendig ist

3.3.3 Risiken bei zu großen Chunks

Chunking mit fester Größe ist eine der grundlegendsten und technisch einfachsten Methoden zur Segmentierung von Texten für die Weiterverarbeitung in Retrieval-Augmented-Generation-(RAG-)Systemen. Dabei wird der Text unabhängig von seiner inhaltlichen Struktur oder semantischen Kohärenz in gleich große Abschnitte – sogenannte Chunks – aufgeteilt. Die Größe dieser Einheiten kann je nach Anwendungsfall auf Grundlage von Wörtern, Zeichen oder Tokens bestimmt werden. Typische Einstellungen umfassen zum Beispiel 100 Wörter, 500 Zeichen oder 300 Tokens pro Chunk.

Das Ziel dieser Strategie liegt vor allem in ihrer Standardisierbarkeit: Durch die gleichmäßige Zerlegung großer Textmengen lassen sich Daten sehr effizient vorbereiten und verarbeiten, insbesondere in automatisierten Pipelines, bei denen semantische Tiefe zunächst eine untergeordnete Rolle spielt. In Szenarien mit strikten Längenvorgaben – etwa bei API-Schnittstellen oder der Speicheroptimierung in Vektordatenbanken – erweist sich diese Methode als besonders nützlich.

Allerdings geht diese Einfachheit zulasten des Inhaltszusammenhangs. Da die Chunk-Grenzen nicht auf natürliche Sprachelemente wie Sätze oder Absätze Rücksicht nehmen, können bedeutungstragende Einheiten auseinandergerissen werden. Dies kann sich negativ auf das Antwortverhalten von Sprachmodellen auswirken, da wichtige Informationen möglicherweise auf mehrere Chunks verteilt sind und dadurch Kontext verloren geht.

Ein Beispiel aus Franz Kafkas „Die Verwandlung“ verdeutlicht dies: Wird der berühmte Eingangssatz des Werks in 10-Wort Chunks aufgeteilt, ergibt sich folgendes Bild:

{
    "text": "Als Gregor Samsa eines Morgens aus unruhigen Träumen erwachte, fand"
},
{
    "text": "er sich in seinem Bett zu einem ungeheueren Ungeziefer verwandelt."
},
{
    "text": "Er lag auf seinem panzerartig harten Rücken und sah, wenn"
},

Obwohl jeder Chunk formal korrekt segmentiert ist, wird die inhaltliche Einheit des Satzes gebrochen, was den semantischen Zusammenhang erschwert.

Hier mit Tokens und den Text zur besseren Einordnung:

{
     "text": "Als Gregor Samsa eines Morgens aus",
     "token_ids": [
        77968,
        16431,
        269,
        328,
        4214,
        64,
        37208,
        79160,
        729,
        9608
        ]
},
{
      "text": " unruhigen Träumen erwachte,",
      "token_ids": [
        653,
        2739,
        71,

Trotz dieser Schwächen bleibt Chunking mit fester Größe eine weit verbreitete Methode, insbesondere in frühen Phasen der Datenvorverarbeitung oder in Kombination mit überlappenden Chunks und nachgelagerter Kontextrekonstruktion. Ihre Stärke liegt vor allem in der Einfachheit, Berechenbarkeit und Effizienz bei der Handhabung großer Textkorpora – insbesondere bei vollautomatisch erzeugten Chunks, etwa aus PDF-Dateien, in denen feste Längen verwendet werden, da sie sich besonders leicht berechnen lassen. Die potenziellen Nachteile wie semantische Brüche, Zerschneidung grammatischer Einheiten oder Kontextverluste werden dabei in vielen Fällen bewusst in Kauf genommen, um eine möglichst schnelle und skalierbare Verarbeitung zu ermöglichen.

Ein besonders problematischer Aspekt ist der Umgang mit tabellarischen Daten: Tabellen verlieren durch feste Blockierungen häufig ihre logische Struktur – etwa Spaltenüberschriften, Zellbezüge oder Zeilenzusammenhänge – und werden dadurch semantisch „tot“. Sie können vom Modell weder als funktionale Einheit erfasst noch korrekt rekonstruiert werden. Dies betrifft insbesondere komplexe Tabellenlayouts aus wissenschaftlichen Publikationen, Geschäftsberichten oder Normdokumenten, die beim Parsing aus PDF-Quellen ohnehin anfällig für Fragmentierung sind. In der Folge leidet nicht nur die semantische Auswertbarkeit, sondern auch die Antwortqualität bei KI-basierten Retrieval-Systemen erheblich.

Darüber hinaus betrifft das Chunking mit fester Größe auch semantisch bedeutungsvolle Metainformationen, wie etwa Fußnoten, Literaturverweise, Marginalien oder Quellenangaben. Diese erscheinen im Fließtext häufig außerhalb ihres semantischen Kontexts und verlieren dadurch ihre Referenzfunktion. Beispielsweise kann eine Fußnote am Ende eines Absatzes in einen separaten Chunk fallen, ohne dass das zugehörige Zitat erhalten bleibt – was sowohl für Leser:innen als auch für Sprachmodelle zu einem vollständigen Bedeutungsverlust führt. Besonders in wissenschaftlichen oder juristischen Texten ist dies ein kritisches Problem, da Belegstellen und formale Bezüge eine zentrale Rolle für das Textverständnis spielen.

Mehr Informationen zum Thema, welche Strukturen betroffen sind, finden sich in Teil 1 der RAG-Studienreihe „Strukturierte vs. unstrukturierte Daten im RAG-Training: ein Vergleich“.

Das rekursive Chunking stellt eine erweiterte und deutlich flexiblere Form der Textsegmentierung dar. Im Gegensatz zu linearen Methoden mit fester Chunk-Größe basiert diese Strategie auf einer hierarchischen Analyse der Textstruktur. Dabei erfolgt die Zerlegung des Textes nicht unmittelbar in gleich große Einheiten, sondern in mehreren Stufen – stets entlang der nächstkleineren inhaltlichen oder formalen Einheit, sobald ein definierter Grenzwert (z. B. eine maximale Token-Anzahl) überschritten wird.

4.2.1 Prinzip und Zielsetzung

4.2.2 Anwendung und Beispiel

Das dokumentbasierte Chunking ist eine Struktur-orientierte Methode zur Segmentierung von Texten, bei der sich die Zerlegung konsequent an der natürlichen Gliederung des Dokuments orientiert. Im Gegensatz zu rein quantitativen Ansätzen, bei denen Chunks nach Wort-, Zeichen- oder Token-Anzahl geschnitten werden, folgt diese Strategie der inhärenten Aufbauweise des Textes – also an formalen Einheiten wie Kapiteln, Absätzen, Unterüberschriften oder Sektionen. Ziel ist es, semantisch zusammengehörige Abschnitte vollständig zu erhalten und so den inhaltlichen Zusammenhang und die logische Kohärenz im Chunk zu wahren.

4.3.1 Zielsetzung und Anwendungsbereich

4.3.2 Methodik

4.3.3 Beispiel: Dokumentbasiertes Chunking der UN-Menschenrechtscharta (in Markdown, als JSON)

  {
    "chunk_id": "1",
    "struktur": "Präambel",
    "content": "Da die Anerkennung der angeborenen Würde und der gleichen und unveräußerlichen Rechte aller Mitglieder
    der Gemeinschaft der Menschen ...",
    "metadata": {
      "typ": "prambel",
      "abschnitt": "Einleitung"
    }
  },
  {
    "chunk_id": "2",
    "struktur": "Artikel",
    "artikel_nummer": 1,
    "titel": "Artikel 1",
    "content": "Alle Menschen sind frei und gleich an Würde und Rechten geboren. Sie sind mit Vernunft und Gewissen
    begabt und sollen einander im Geist der Brüderlichkeit begegnen.",
    "metadata": {
      "typ": "artikel",
      "quelle": "UN-Charta 1948",
      "rechtstyp": "Menschenrecht"
    }
  },
  {
    "chunk_id": "3",
    "struktur": "Artikel",
    "artikel_nummer": 2,
    "titel": "Artikel 2",
    "content": "Jeder hat Anspruch auf alle in dieser Erklärung verkündeten Rechte und Freiheiten ...",
    "metadata": {
      "typ": "artikel",
      "quelle": "UN-Charta 1948",
      "rechtstyp": "Antidiskriminierung"
    }
  }
]

4.3.4 Vorteile und Herausforderungen

Das semantische Chunking ist eine fortgeschrittene Methode der Textsegmentierung, bei der nicht die äußere Struktur, sondern der inhaltliche Bedeutungszusammenhang die Grundlage für die Chunk-Bildung darstellt. Die Zerlegung erfolgt entlang von thematischen, argumentativen oder narrativen Einheiten wie z. B. Themen, Rollen (Akteure), Absichten, Rechtsbezüge oder Diskursschwerpunkte. Ziel dieser Strategie ist es, kohärente inhaltliche Abschnitte zu extrahieren, die in sich semantisch geschlossen sind – unabhängig von formalen Layout- oder Formatierungsmerkmalen.

4.4.1 Ziel und Anwendungsfelder

4.4.2 Methodik

4.4.3 Beispiel: Semantisches Chunking der UN-Menschenrechtscharta

[
  {
    "chunk_id": 1,
    "article": "1",
    "content": "Alle Menschen sind frei und gleich an Würde und Rechten geboren.",
    "metadata": {
      "rolle": "Mensch",
      "thema": "Menschenwürde",
      "rechtsstatus": "angeboren"
    }
  },
  {
    "chunk_id": 2,
    "article": "1",
    "content": "Sie sind mit Vernunft und Gewissen begabt und sollen einander im Geist der Brüderlichkeit begegnen.",
    "metadata": {
      "rolle": "Mensch",
      "thema": "Verantwortung",
      "norm": "Brüderlichkeit"
    }
  }
]

4.4.4 Vorteile und Herausforderungen

4.4.5 Agentic Chunking

Das Token-basierte Chunking ist eine methodisch präzise Strategie zur Aufteilung von Texten, bei der sich die Segmentierung an der internen Verarbeitungseinheit von Sprachmodellen orientiert: den sogenannten Tokens. Tokens sind nicht identisch mit Wörtern – je nach Sprache und Wortstruktur kann ein einziges Wort aus mehreren Tokens bestehen, während manche kurze Wörter nur ein Token umfassen. So wird beispielsweise „Gregor“ als ein Token, „Samsa“ als ein weiteres Token gezählt.

Diese Form des Chunkings wird vor allem in Zusammenhang mit Large Language Models (LLMs) wie GPT-4, Claude oder LLaMA verwendet, da diese Modelle konkrete Token-Limits pro Eingabe besitzen – typischerweise zwischen 2048 und 8192 Tokens, je nach Modell und Version. Um sicherzustellen, dass ein Input den Kontextbereich eines LLMs nicht überschreitet, wird der Text im Vorfeld in Token-genaue Einheiten zerteilt.

4.5.1 Ziel und Anwendung

Ziel des Token-basierten Chunkings ist eine optimierte Vorbereitung von Texten für LLM-Anfragen, etwa im Rahmen von Retrieval-Augmented Generation, Prompt Engineering oder fein abgestimmten Frage-Antwort-Systemen. Diese Methode bietet eine sehr präzise Steuerung, da der Input exakt auf das technisch erlaubte Maß zugeschnitten werden kann – ideal für Anwendungen mit festen Kontextgrenzen (z. B. 4096 Token bei GPT-3.5).

Ein Beispiel aus Kafkas Die Verwandlung verdeutlicht die Feinheit der Tokenisierung:

4.5.2 Kombination mit anderen Strategien

 {
  "strategy": "semantisch + token-basiert",
  "max_tokens": 400,
  "chunk_id": 12,
  "content": "...",
  "metadata": {
    "thema": "Menschenwürde",
    "quelle": "Artikel 1",
    "rolle": "Mensch"
  }
}

4.5.3 Implikationen für die Praxis

Das satzbasierte Chunking ist eine linguistisch fundierte Strategie zur Segmentierung von Texten, bei der die Chunk-Grenzen entlang vollständiger Sätze verlaufen. Jeder Chunk enthält genau einen oder mehrere abgeschlossene Sätze, wobei Satzgrenzen mithilfe sprachtechnologischer Werkzeuge automatisch erkannt werden. Diese Methode gilt als besonders robust, einfach implementierbar und zugleich semantisch stabil, da der natürliche Fluss der Sprache in der Regel erhalten bleibt.

4.6.1 Ziel und Funktionsweise

4.6.2 Vorteile und Grenzen

Unabhängig von der zugrunde liegenden Chunking-Strategie – ob semantisch, satzbasiert, rekursiv oder dokumentbasiert – gibt es eine Reihe ergänzender Verfahren, welche die Leistungsfähigkeit, Kontexttreue und Flexibilität von Chunks deutlich erhöhen. Zu den wichtigsten gehören:

4.7.1 Overlapping (Überlappung)

4.7.2 Doppelung (Redundanz für Mehrfachverwendung)

4.7.3 Referenzierung (Verknüpfung durch Metadaten)

{
  "chunk_id": 17,
  "article": "Artikel 1",
  "content": "Menschenwürde ist unantastbar.",
  "metadata": {
    "verweist_auf": "chunk_id_4",
    "kontext": "Definition Menschenwürde",
    "quelle": "Grundgesetz"
  }
}

4.7.4 Strategische Erkenntnisse

In Retrieval-Augmented-Generation-(RAG-)Systemen ist Embedding-Software ein zentraler Baustein: Sie wandelt Textdaten in eine maschinenlesbare Form – sogenannte Vektoren – um, die semantische Bedeutung repräsentieren. Diese Transformation ist entscheidend, um externe Inhalte (z. B. literarische Texte) für KI-Systeme durchsuchbar und interpretierbar zu machen. Dieses Kapitel veranschaulicht die Funktionsweise von Embedding-Software in RAG-Systemen anhand eines literarischen Klassikers: „Die Verwandlung“ von Franz Kafka.

5.1.1 Vom literarischen Satz zum semantischen Vektor

[0.023, -0.785, 1.202, ..., -0.091]

5.1.2 Speicherung und semantische Suche in Vektordatenbanken

5.1.3 Integration in RAG-Architekturen

5.1.4 Implikationen für die Praxis

5.2.1 Metadaten als semantische Verstärker

{
  "content": "Als Gregor Samsa eines Morgens ...",
  "metadata": {
    "autor": "Franz Kafka",
    "titel": "Die Verwandlung",
    "kapitel": 1,
    "literaturgattung": "Erzählung",
    "sprache": "de",
    "entstehungsjahr": 1912
  }
}

5.2.2 Wie Metadaten mit Embedding-Software zusammenspielen

5.2.3 Unterschiede zwischen Embedding-Software im Umgang mit Metadaten

db.query(
    query_vector=embedding,
    filter={"autor": "Kafka", "kapitel": {"$gte": 2}},
    top_k=5
)

5.2.4 Zusammenfassung

Der Einsatz von Embedding-Software ist ein zentrales Element in modernen Retrieval-Augmented-Generation-(RAG-)Systemen. Die folgende Abbildung zeigt den typischen Ablauf einer solchen Pipeline – von der Nutzeranfrage bis zur KI-generierten Antwort – und verdeutlicht die Rolle der einzelnen Komponenten in der Verarbeitungskette.

1. Nutzeranfrage (Text)

Am Anfang steht eine natürliche Spracheingabe durch den Nutzer, etwa in Form einer Frage oder Suchanfrage. Diese Eingabe dient als Ausgangspunkt für die nachfolgenden Verarbeitungsschritte.

2. Embedding-Modell (Text → Vektor)

Der eingegebene Text wird mithilfe eines Embedding-Modells in einen mehrdimensionalen Vektor übersetzt. Dieser Vektor repräsentiert die semantische Bedeutung der Anfrage und ist Grundlage für die Ähnlichkeitssuche. Verwendet werden Modelle wie z. B. text-embedding-ada-002 von OpenAI oder BERT-Varianten, die den Text als Zahlenraum (Vektorraum) abbilden.

3. Vektordatenbank (Suche nach Ähnlichkeit)

Die erzeugten Vektoren werden mit den Einträgen in einer Vektordatenbank (z. B. FAISS, Weaviate, Pinecone) verglichen. Hier befinden sich bereits vorab eingebettete Textabschnitte (Chunks), die aus vorhandenen Dokumenten erzeugt wurden. Ziel ist es, jene Chunks zu identifizieren, die inhaltlich ähnlich zur Anfrage sind.

4. Relevante Dokumente

Als Ergebnis des Vektorvergleichs werden die semantisch nächstliegenden Chunks abgerufen. Sie enthalten die für die Nutzerfrage potenziell relevanten Informationen. In diesem Schritt entscheidet sich, wie präzise und vollständig das LLM antworten kann – je nachdem, ob die richtigen Dokumentpassagen gefunden wurden.

5. LLM (Antwortgenerierung)

Die ausgewählten Dokumente werden zusammen mit der ursprünglichen Anfrage an ein Large Language Model (LLM) übergeben. Dieses nutzt den externen Kontext, um eine fundierte Antwort zu formulieren – also nicht aus reinem Training, sondern auf Basis der eingebetteten Informationen. Der RAG-Prozess kombiniert somit Suchmaschine und generative KI.

6. Endgültige Antwort

Am Ende steht die vom LLM generierte endgültige Antwort, die dem Nutzer angezeigt wird. Sie basiert auf einer Mischung aus abrufbarem Wissen (retrieved) und sprachlicher Formulierungskompetenz (generated) – daher der Name Retrieval-Augmented Generation.

Die folgende Tabelle bietet eine systematische Übersicht über zentrale Chunking-Strategien im Kontext von Retrieval-Augmented Generation (RAG). Dabei werden die Verfahren hinsichtlich ihrer Segmentierungslogik, der Fähigkeit zum Kontexterhalt, ihrer Eignung für komplexe Inhalte sowie ihres technischen Aufwands miteinander verglichen. Diese komparative Darstellung soll helfen, geeignete Strategien für spezifische Anwendungsbereiche (z. B. normativer Text, technische Dokumentation, Bildung) gezielt auszuwählen.

Die wichtigste Erkenntnis aus Teil 1 der RAG-Studienreihe mit dem Titel „Strukturierte vs. unstrukturierte Daten für RAG-Training: ein Vergleich“ lässt sich in einem Satz zusammenfassen: Struktur der Daten ist entscheidend für die Qualität eines RAG-Systems. Besonders beim Vergleich strukturierter Formate, wie Markdown oder HTML, mit unstrukturierten PDFs zeigte sich, dass die Modell-Antworten präziser und fundierter ausfallen, wenn die zugrunde liegenden Inhalte klar gegliedert und mit Metadaten angereichert sind.

Statt nun theoretisch eine Systematik über mögliche Problemräume zu entwerfen, wollen wir eine prototypische Fallstudie nutzen, um die bisherigen Inhalte zu strukturieren. Anhand eines konkreten, realitätsnahen Szenarios können wir zeigen, wie die einzelnen Aspekte – Strukturformate, Chunking, Metadaten, Referenzen und Modell-Integration – in einer kohärenten Pipeline zusammenwirken.

Diese Fallstudie wird uns helfen, das "Durcheinander" an technischen Möglichkeiten, Strategien und Abhängigkeiten zu entwirren und in sinnvolle, lösungsorientierte Handlungskomplexe zu überführen.

Ein mittelgroßer Wissenschaftsverlag mit einem Portfolio von über 50 fachspezifischen, KI-gestützten Chatbots steht vor der Aufgabe, eine konsistente und erweiterbare RAG-Infrastruktur aufzubauen. Die Datenlage im Verlag ist historisch gewachsen und stellt verschiedene technische und konzeptionelle Herausforderungen dar.

Ein Großteil der Inhalte liegt im XML-Format vor – insbesondere nach den Standards BITS und JATS. Diese Formate sind reich strukturiert, allerdings existieren viele ältere Titel ausschließlich als unstrukturierte PDF-Dateien. Darüber hinaus wurden Teile des XML-Bestands in verschiedene Ausgabeformate wie PDF und ePub überführt, was zu Mehrdeutigkeiten und Inkonsistenzen führt. Der heterogene Formatmix erschwert die einheitliche Erschließung der Inhalte für RAG-Prozesse erheblich.

Zusätzlich ist der Content-Durchsatz dynamisch: Es erscheinen regelmäßig neue Publikationen, während veraltete Ausgaben entfernt oder durch neue ersetzt werden müssen. Dabei entstehen Anforderungen an eine kontinuierliche Inhaltsaktualisierung, automatisierte Versionierung und Synchronisation der Dokumentbasis – ohne Redundanzen oder Zugriff auf veraltete Inhalte.

Ein zentrales Problem ist die Abhängigkeit von spezifischen LLM-Anbietern. Der Verlag möchte eine Lösung, die langfristig unabhängig bleibt, doch viele bestehende Systeme sind stark an proprietäre Modelle gekoppelt. Der Wunsch nach technischer und wirtschaftlicher Flexibilität kollidiert mit den proprietären Standards einiger Anbieter (z. B. für Tokenisierung oder Kontextlimits).

Ein weiteres Problem betrifft die Zukunftssicherheit: Da sich die Anforderungen neuer LLMs – etwa hinsichtlich Chunk-Größe, Semantik oder Kontextfenster – nicht vorhersagen lassen, ist unklar, wie stabil die heute entwickelten Datenprozesse in zwei oder drei Jahren noch funktionieren werden. Eine starre Architektur könnte später zu kostspieligen Anpassungen führen, falls neue Modelle mit völlig anderen Anforderungen eingeführt werden.

Zudem ist nicht eindeutig geklärt, wie Inhalte so gechunkt werden können, dass sie sowohl für aktuelle LLMs als auch für künftige Modellgenerationen optimal nutzbar bleiben – insbesondere, wenn es um wissenschaftlich komplexe Texte mit Querverweisen, Fußnoten, Tabellen oder mehrsprachigen Abschnitten geht.

Um das sehr komplexe Gesamtproblem rund um Retrieval-Augmented Generation (RAG) besser fassen zu können, hilft es, einen analytischen Schritt zurückzugehen. Aus der Praxis wie auch der Theorie kristallisieren sich dabei zwei fundamentale Problemfelder heraus, die – sauber getrennt – die Basis jeder nachhaltigen RAG-Strategie bilden:

1. Datenstrukturierung
2. Datenhaltung

Diese Trennung ist nicht nur analytisch sinnvoll, sondern auch praktisch notwendig, wenn man technologische Unabhängigkeit und langfristige Wartbarkeit erreichen will.

In der Praxis der automatisierten Medienproduktion ist das Strukturproblem altbekannt. Wer heute Inhalte für Print, ePub, InDesign, PDF, Web oder App aufbereiten muss, weiß: Nur eine medienneutrale Datenstrukturierung macht flexible Wiederverwendung möglich. Genau hier liegt der Kern der Lösung – auch für RAG.

Die Antwort lautet: Chunk-neutrale Strukturierung.

Wir verzichten auf eine Vorstrukturierung in konkrete Chunks (z. B. 300 Tokens oder 500 Zeichen), sondern halten die Inhalte in einem chunk-neutralen Format, das beliebige Chunking-Strategien automatisch generieren kann. Dieses Format erlaubt es, später jederzeit kontextabhängig die passende Chunk-Form zu erzeugen – sei es Token-basiert für GPT, absatzweise für BERT oder mit Overlapping für spezielle Suchanwendungen.

Technologischer Kern:

• XML als etabliertes, medienneutrales Format bleibt auch hier die Basis in Form eines HUB-/Pivot-Formats.
• Hinzu kommen nun Technologien wie:
  • XSLT zur regelbasierten Transformation,
  • Python zur Erzeugung von Tokens, u.v.m.,
  • XProc zur Erstellung einer orchestrierten Verarbeitungspipeline,
  • XQuery zur Verarbeitung sehr großer Datenformate und für Auswertungen,
  • lokale LLMs zur inhaltlichen Anreicherung oder Klassifikation,
  • sowie XML-Datenbanken.

Das Zusammenspiel dieser Werkzeuge ist komplex, aber bekannt und beherrschbar – besonders in Umfeldern, die mit Crossmedia-Publishing oder technischer Dokumentation vertraut sind.

Auch die Frage, wo und wie die strukturierten Inhalte gespeichert werden, ist entscheidend. Die Anforderungen sind hoch:

• Versionierbarkeit,
• semantische Durchsuchbarkeit,
• effiziente Integration in nachgelagerte RAG-Prozesse,
• Automatisierung von Updates (z. B. bei neuen Ausgaben),
• und technologische Offenheit.

Die Lösung liegt in Content Delivery Services (CDS), wie sie sich in der Technischen Dokumentation längst bewährt haben.

Zentrale Konzepte:

• Speicherung strukturierter Inhalte in container-basierten Formaten (z. B. ZIP+XML, METS, iiRDS),
• Anreicherung mit RDF-Metadaten für semantische Erschließung,
• SPARQL-fähige Systeme zur gezielten Abfrage von Inhalten,
• Integration mit Git, CMS oder XML-Datenbanken, je nach Redaktionsumgebung.

Auch hier ist die Trennung von Struktur und Haltung der Daten entscheidend: Die Inhalte bleiben unabhängig von der konkreten Ausgabeform und der konkreten LLM-/Embedding-Kombination. So lässt sich jederzeit wechseln – sei es zu einem neuen Sprachmodell, einer anderen Vektordatenbank oder einer anderen Darstellungsform.

Die erste kommende Studie wird sich ausschließlich der Frage widmen, wie wir Inhalte medienneutral strukturieren und daraus automatisiert alle erdenklichen Chunk-Formate ableiten können – sowohl für bestehende als auch zukünftige LLM-Systeme.

Ziel ist es, eine vollautomatische Infrastruktur zu entwickeln, die beliebige Chunking-Strategien (Tokens, Wörter, Absätze, Kapitel, semantische Einheiten usw.) auf Knopfdruck generieren kann – angepasst an die jeweiligen Anforderungen von Modell, Anwendung oder Nutzeroberfläche.

Ein zentrales Werkzeug in diesem Zusammenhang wird Octopus sein – eine leistungsstarke Lösung zur Konvertierung unterschiedlichster Quellformate (z. B. HTML, ePub, Word, InDesign, PDF) in ein chunk-neutrales, medienneutrales Zwischenformat. Damit wird es erstmals möglich, auch aus schwer verarbeitbaren Formaten wie PDF systematisch strukturierte, RAG-taugliche Inhalte zu extrahieren – automatisiert, skalierbar und standardkonform.

Die abschließende Studie wird sich mit der Frage beschäftigen, welche Rolle ein Content Delivery Service (CDS) in der Gesamtarchitektur eines RAG-Systems spielt – insbesondere in der Schnittstelle zwischen strukturierten Inhalten und den Retrieval- und Generierungskomponenten.

Im Mittelpunkt steht die Kommunikation zwischen CDS und RAG:

• Wie fordern LLMs gezielt Inhalte aus dem CDS an?
• Wie werden RDF-Metadaten, SPARQL-Abfragen und Container-Formate (z. B. iiRDS) zur Inhaltsselektion genutzt?
• Wie lassen sich Updates, Versionierungen und Modellwechsel automatisieren und absichern?

Ziel ist es, ein intelligentes, regelbasiertes System zu schaffen, in dem die Datenhaltung nicht nur ein passiver Speicher, sondern ein aktiver Akteur im RAG-Workflow ist – mit semantischem Verständnis, Rückkanälen zur Bewertung der Modellantworten und Integrationen in bestehende Publishing- und Redaktionssysteme.