Diese Studie zeigt, wie unstrukturierte PDF-Dokumente automatisiert für die Nutzung in Retrieval-Augmented-Generation-(RAG-)Systemen aufbereitet werden können. Der Prozess beginnt mit einer feingranularen Layout-Analyse, bei der jedes Zeichen hinsichtlich Position, Schriftart und Format extrahiert wird. Daraus entsteht ein detailliertes Low-Level-Format, ergänzt durch eingebettete XMP-Metadaten (z. B. Autor, Titel, Schlagworte).

Im nächsten Schritt werden die PDFs in verschiedene Ausgabeformate transformiert:

• PDF-Einzelseiten für wissenschaftliche Zitation
• SVG (Pfad & Text) für visuelle und interaktive Anwendungen
• Octpmlx-Format für zeilenbasierte Volltextsuche mit Positionsangaben
• Match-Format für exakte Verortung von Treffern im Text

Diese Formate ermöglichen die positionsgenaue Rückverfolgbarkeit von Informationen und bilden die Grundlage für eine präzise semantische Verarbeitung.
Das Ziel ist die vollautomatische Erzeugung eines semantisch strukturierten Pivot-Formats (exHTML), das als Basis für weitere Transformationen dient – etwa Chunking, Metadaten-Anreicherung oder multimediale Ausleitungen.

Im Zentrum der gesamten RAG-Pipeline steht ein zweistufiges Strukturmodell, das aus dem semantisch strukturierten Pivot-Format exHTML und dem darauf aufbauenden ChunkML-Format besteht. Diese Formate bilden gemeinsam die Grundlage für eine modulare, medienneutrale und zukunftsfähige Inhaltsverarbeitung – unabhängig vom Ausgangsformat, von der Zielplattform oder dem verwendeten Large Language Model (LLM).

exHTML: Das semantisch angereicherte Pivot-Format

ChunkML: Strukturierte Vorbereitung für das Chunking

Das Hub-System: Steuerzentrale und Orchestrierungskern

Zukunftssicherheit und Flexibilität

Der nächste Teil der RAG-Studienreihe widmet sich der Implementierung eines Content Delivery Services (CDS), der als intelligente Vermittlungsschicht zwischen den strukturierten Formaten der RAG-Pipeline (z. B. ChunkML, RDF) und den nachgelagerten Komponenten wie LLMs, Embedding-Systemen oder Chatbots fungiert.

Der CDS soll eine regelbasierte Bereitstellung von Inhalten ermöglichen, die exakt auf die Anforderungen der jeweiligen Anwendung zugeschnitten ist – granular, kontextbewusst und formatneutral. Dabei wird er sowohl als technische Zugriffsschicht als auch als semantisches Filtersystem eingesetzt:

• Über RDF-Metadaten (z. B. dc:title, schema:about) können Inhalte gezielt ausgewählt, kombiniert und gewichtet werden.
• SPARQL-Endpunkte erlauben komplexe Anfragen auf semantischer Ebene – z. B. für themenspezifische Antwortkontexte, Quellenverweise oder Zitierketten.
• Inhalte werden bei Bedarf in Containern verpackt (z. B. iiRDS, OCF), um Metadaten, Originaldaten und strukturierte Chunks gebündelt auszuliefern.

Ein besonderes Augenmerk gilt der Entkopplung der Architektur: Der CDS verwaltet Inhalte unabhängig von ihrer konkreten Nutzung – sei es im Retrieval, im Prompting oder in der Web-Ausgabe. Dies schafft die Voraussetzung für skalierbare, modulare Systeme, in denen mehrere Bots, Interfaces oder LLMs gleichzeitig auf eine konsistente Wissensbasis zugreifen können.

Die nächste Studie wird untersuchen, wie ein solcher CDS technisch umgesetzt, in bestehende XML-Hub-Systeme integriert und in verschiedenen Anwendungsszenarien – etwa Fachportale, Publikationssysteme oder Multi-Agent-Umgebungen – produktiv eingesetzt werden kann.

Ein typisches Ergebnis einer solchen Analyse ist das sogenannte „Primärformat“ oder „Low-Level-Layout-Format“, wie es beispielsweise durch OCR- oder Parsing-Engines wie Octopus erzeugt wird. Dieses Format bildet die Ausgangsschicht für alle weiteren Verarbeitungs- und Chunking-Schritte und lässt sich exemplarisch an folgendem Originalfragment illustrieren:

<block bbox="70.944 76.489978 156.5 97.14498">
  <line bbox="70.944 76.489978 156.5 97.14498" wmode="0" dir="1 0">
    <font name="BundesSansOffice-Bold" size="15">
      <char quad="70.944 78.24498 78.444 78.24498 70.944 96.24498 78.444 96.24498"
            x="70.944" y="92.53998" color="#000000" c="2"/>
    </font>
    <font name="Arial-BoldMT" size="15">
      <char quad="78.504 76.489978 82.674 76.489978 78.504 97.14498 82.674 97.14498"
            x="78.504" y="92.53998" color="#000000" c=" "/>
    </font>
    <font name="BundesSansOffice-Bold" size="15">
      <char quad="92.544 78.24498 105.264 78.24498 92.544 96.24498 105.264 96.24498"
            x="92.544" y="92.53998" color="#000000" c="M"/>
      <char quad="105.264 78.24498 112.449 78.24498 105.264 96.24498 112.449 96.24498"
            x="105.264" y="92.53998" color="#000000" c="e"/>
      <char quad="112.449 78.24498 117.909 78.24498 112.449 96.24498 117.909 96.24498"
            x="112.449" y="92.53998" color="#000000" c="t"/>
      <char quad="117.969 78.24498 126.114 78.24498 117.969 96.24498 126.114 96.24498"
            x="117.969" y="92.53998" color="#000000" c="h"/>
      <char quad="126.114 78.24498 134.019 78.24498 126.114 96.24498 134.019 96.24498"
            x="126.114" y="92.53998" color="#000000" c="o"/>
      <char quad="134.019 78.24498 142.119 78.24498 134.019 96.24498 142.119 96.24498"
            x="134.019" y="92.53998" color="#000000" c="d"/>
      <char quad="142.119 78.24498 145.929 78.24498 142.119 96.24498 145.929 96.24498"
            x="142.119" y="92.53998" color="#000000" c="i"/>
      <char quad="145.929 78.24498 153.474 78.24498 145.929 96.24498 153.474 96.24498"
            x="145.929" y="92.53998" color="#000000" c="k"/>
      <char quad="153.38 78.24498 156.5 78.24498 153.38 96.24498 156.5 96.24498"
            x="153.38" y="92.53998" color="#000000" c=" "/>
    </font>
  </line>
</block>

Code-Ausschnitt aus: PDF2ChunkML\02_PDF_Raw\EingangsBeispiel_char.xml.

Dieser Datenblock stammt aus Seite 9 des analysierten Dokuments. Die enthaltenen Informationen lassen sich wie folgt interpretieren:

• <block>: Repräsentiert einen Layout-Block mit einer Bounding Box (bbox) – hier konkret ein rechteckiger Bereich auf der Seite (Koordinaten x0, y0, x1, y1).
• <line>: Beschreibt eine Textzeile innerhalb des Blocks mit Textrichtung (dir="1 0") und Schreibmodus (wmode="0", d.h. horizontal).
• <font>: Definiert einen Schriftbereich mit Namen und Schriftgröße. Innerhalb desselben Fonts werden Zeichen (<char>) gruppiert.
• <char>: Jedes Zeichen wird einzeln mit folgenden Merkmalen beschrieben:
  • quad: Vier Koordinatenpunkte für das Zeichenquadrat (Polygon),
  • x, y: Referenzposition des Zeichens (oft baseline links unten),
  • color: Farbinformation im hexadezimalen RGB-Format,
  • c: Der eigentliche Zeichencode (z. B. "M" oder "e").

Das Resultat dieser detaillierten Zeichenkette ist die visuelle Darstellung des Textstrings „2 Methodik“ – allerdings nicht als Wort oder semantische Einheit, sondern als Zusammenfügung einzelner Glyphen mit präziser Positionierung.

Das Layout-Modell stellt für unsere Arbeit an Octopus lediglich ein technisches Rohformat dar – eine niedrigschwellige Repräsentation der PDF-Inhalte auf Zeichen- und Layout-Ebene. Es enthält sämtliche für die maschinelle Rekonstruktion von Struktur und Kontext potenziell relevanten Informationen, darunter:

• Seitennummer und exakte Position (→ Rekonstruktion von Lesereihenfolge)
• Font-Typen und -Größen (→ Unterscheidung von Überschriften, Fließtext, Fußnoten)
• Textausrichtung und Bounding Boxes (→ Layout-Analyse, z. B. Spalten, Tabellen)
• Zeichenbasierte Interpunktion, Abstände und Zeichenketten (→ Formel-Erkennung, Trennung von Wörtern/Sätzen)

Trotz dieser inhaltlichen Dichte erfolgt in der Praxis der meisten KI-basierten Systeme ein drastischer Reduktionsschritt: Die Extraktion des sogenannten „Plaintext“.

Beispielhaft wird aus dem vorher dargestellten Code-Block:

<font name="BundesSansOffice-Bold" size="15">
  <char ... c="2"/>
</font>
...
<char ... c="M"/>
<char ... c="e"/>
...
<char ... c="k"/>

lediglich der String:

2 Methodik

extrahiert. Während dieser Text aus menschlicher Sicht problemlos lesbar ist, fehlt dem maschinellen System jegliche Kontextualisierung:

• Wo auf der Seite befand sich dieser Text?
• War es eine Überschrift, ein Listenpunkt oder ein Absatzbeginn?
• Wie lautet der Zusammenhang zur vorherigen/nächsten Seite?
• Gibt es visuelle Hinweise auf semantische Zugehörigkeit (z. B. Fettung, Einrückung, Hervorhebung)?

Diese Reduktion stellt insbesondere im Bereich der Retrieval-Augmented Generation (RAG) ein gravierendes Problem dar, da für die gezielte Generierung kontextbezogener Antworten strukturelle Hinweise von zentraler Bedeutung sind. Die rein textuelle Repräsentation ist häufig nicht ausreichend, um komplexe Relationen wie Verweise, Gliederungen oder Argumentationslinien zu rekonstruieren.

Trotz der Betonung des strukturerhaltenden Layout-Modells bietet das von uns eingesetzte Framework Octopus selbstverständlich auch eine Möglichkeit zur Plaintext-Extraktion. Diese kann – je nach Anwendung – ergänzend eingesetzt werden, etwa zur einfachen Preview oder zum Vergleich mit strukturverlustbehafteten Standardverfahren.

Ein konkreter Anwendungsfall ist in der Datei PDF2ChunkML\02_PDF_Raw\EingangsBeispiel_char.xml dokumentiert.

Diese Mehrformat-Strategie ist zentral für verschiedene Nutzungsziele im Kontext von Retrieval-Augmented Generation (RAG):

Der Zugriff auf diese Formate erfolgt regelbasiert innerhalb der RAG-Pipeline – je nach Zielsystem (z. B. Fachportal, Verlagssystem, Chatbot mit Antwortbelegen) werden die entsprechenden Ausgabeformate referenziert oder ausgeliefert.

Durch diese Strategie wird jede Antwort, die das RAG-System liefert, auf Wunsch mit einer visuell identifizierbaren Belegseite verknüpft. Diese Referenzierbarkeit ist ein zentraler Baustein für Transparenz, Revisionssicherheit und wissenschaftliche Anschlussfähigkeit. Gleichzeitig ermöglichen die SVG-Formate eine präzise Einbindung in Webinterfaces, z. B. durch semantische Verlinkung einzelner Textsegmente mit Chunk-IDs, Retrieval-Hits oder Annotationen.

Die wesentlichen Strukturmerkmale lassen sich wie folgt beschreiben:

Das Octpmlx-Format erfüllt zwei zentrale Funktionen:

1. Volltextindexierung
   Alle Zeilen eines Dokuments sind sequenziell und durchsuchbar gespeichert – unabhängig von Seitenumbrüchen, Spalten oder Absatzgrenzen. Dadurch lassen sich Textfragmente zuverlässig in großen PDF-Korpora auffinden.
2. Positionsrückverfolgung
   Durch die Koordinaten (x, y) kann jede Fundstelle in der Originalseite oder einem dazugehörigen SVG-Rendering genau lokalisiert werden. Dies erlaubt z. B. das visuelle Hervorheben von Suchtreffern in Browser-Interfaces oder die Generierung von Deep Links zu bestimmten Textpassagen.

Beispielanalyse: Das Wort „Methodik“

Das Wort „Methodik“ befindet sich in der oben gezeigten Zeile lnr="150":

<inline ...>Methodik </inline>

Die Inline-Darstellung gibt nicht nur das Wort selbst wieder, sondern zeigt auch, dass es:

• in fetter Schrift (bold) und mit Schriftgröße 15 pt ausgezeichnet ist,
• in der Nähe des Zeichens „2“ steht – ebenfalls fett, was auf eine Überschrift oder Abschnittsmarkierung schließen lässt,
• sich auf Position x=7094.4, y=80808 innerhalb von Seite 9 befindet.

Das Octpmlx-Format bildet die textuelle Infrastruktur für die Suche in PDF-basierten RAG-Systemen. Es ermöglicht:

• präzises Retrieval von Wörtern oder Phrasen,
• Highlighting der Fundstellen in SVG-Dokumenten,
• Verlinkung der Suchergebnisse mit Originalpositionen (z. B. zur Generierung von Belegseiten oder automatisierten Zitaten)
• und die Definition sinnvoller Chunk-Grenzen basierend auf Zeilenverlauf und Position.

Damit schafft das Format die Brücke zwischen inhaltsgetriebener Suche und visuell orientierter Rückverankerung, ein essenzieller Bestandteil transparenter, belegbarer KI-Ausgaben.

Durch diese feingranulare Positionsinformation lassen sich in der RAG-Pipeline u. a.:

• SVG-Dokumente mit hervorgehobenen Treffern erzeugen (über Koordinaten-Referenzierung),
• Chunk-Bewertungen gewichten, je nachdem ob ein Treffer z. B. in einer Überschrift, Tabelle oder Fußnote vorkommt,
• Verlinkungen zu Originalstellen im PDF erzeugen (z. B. Deep Links in einem Viewer).

Zudem lässt sich dieses Format programmatisch mit den HTML-/XML-Strukturen aus Octopus abgleichen, was eine semantische Kontextualisierung des Fundortes erlaubt. So kann ein Treffer, der in einem <h1>-Tag vorkommt, höher gewichtet oder als „strukturell wichtig“ markiert werden.

Die im Folgenden beschriebene Suchfunktionalität basiert nicht auf klassischen String-Durchläufen oder externen Indizes, sondern wird direkt aus einer nativ XML-basierten Datenbank generiert. Diese Datenbank wird dynamisch mit den zeilenbasierten Octpmlx-Dokumenten befüllt. Mithilfe von XQuery-Abfragen erfolgt die Suche hoch performant, da:

• jede Zeile eines jeden Dokuments strukturiert vorliegt,
• Suchoperationen vollständig innerhalb der Datenbank durchgeführt werden (keine Datei-Zugriffe),
• und Trefferdaten direkt in einem präzisen Match-XML-Format ausgegeben werden.

Dieser Ansatz erlaubt es, in Echtzeit über sehr große Korpora hinweg zu suchen – inklusive Rückverweis auf exakte Positionen innerhalb der Originaldokumente (PDF, SVG, HTML). Dabei sind dokumentübergreifende Volltextsuchen ebenso möglich wie semantisch fokussierte Teilmengen-Suchen (z. B. nur Überschriften, Fußnoten, Tabellen, etc.).

exHTML ist ein eigens entwickeltes, HTML5-kompatibles Austauschformat der Octopus-Plattform, das als semantisch angereicherte Strukturquelle für die Weiterverarbeitung dient. Es standardisiert Inhalte aus unterschiedlichsten Quellformaten (z. B. PDF, DOCX, EPUB, XLSX, HTML) und bereitet sie einheitlich, logisch gegliedert und medienneutral auf.

Durch seine Nähe zu HTML5 bietet exHTML maximale Anschlussfähigkeit an Webtechnologien und semantische XML-Standards. Es ermöglicht:

• die strukturelle Erkennung von Textbereichen (z. B. Überschriften, Absätze, Tabellen),
• die semantische Annotation durch Klassen, IDs oder data-*-Attribute,
• die Aggregation komplexer Inhaltsbereiche (z. B. Listen, Verweise, Layout-Zonen).

Neben seiner Rolle als strukturierte Quelle für das spätere Chunking (→ ChunkML), übernimmt exHTML im Octopus-Framework noch eine weitere Schlüsselrolle: Es ist zugleich das Eingangsformat für die medienneutrale Generierung zahlreicher Ausgabeformate – insbesondere PDF, DOCX, EPUB oder HTML5-Module.

Diese Doppelfunktion – als semantischer Vorverarbeitungskern und Ausgabeschnittstelle – macht exHTML zu einem Pivot-Format im klassischen Crossmedia-Sinn: Es ist einmal erzeugt, mehrfach verwendbar, und kann je nach Anwendungsszenario zielgerichtet konfiguriert werden.

Use Case: Ausleitung kapitelweiser Inhalte

Ein typischer Anwendungsfall ergibt sich z. B. im wissenschaftlichen Verlagswesen:

Ein RAG-System soll mit dem gesamten Back-Katalog eines Verlages gespeist werden. Die Zielgruppe sind Wissenschaftler, die kapitelweise Inhalte referenzieren, zitieren oder weiterverarbeiten möchten.

In diesem Szenario lassen sich aus dem exHTML-Format folgende zielgruppengerechte Ausleitungen erzeugen:

Da exHTML bereits die logischen und semantischen Struktur-Elemente enthält (z. B. <section>, <h1>, <table>), können diese in den Zielmedien gezielt gerendert oder ausgeblendet werden. Kapitelmarken, Metadaten oder Chunk-Grenzen lassen sich bei der Ausleitung programmgesteuert berücksichtigen.

Die Nutzung von exHTML als Ausleitungskern bringt folgende strategische Vorteile mit sich:

• Einheitlichkeit: Alle Ausleitungen (PDF, DOCX, etc.) basieren auf einem gemeinsamen semantischen Ausgangspunkt – unabhängig vom Ursprungsformat (z. B. PDF, DOCX, EPUB).
• Zielgruppenorientierung: Inhalte können rollenbasiert ausgegeben werden – z. B. kapitelweise DOCX für Wissenschaftler, kompaktes PDF für Reviews.
• Automatisierung: Die Ausleitung erfolgt regelbasiert und lässt sich vollständig automatisieren – etwa bei Neuerscheinungen oder Updates.
• Design-Kohärenz: Besonders bei PDF-Ausleitungen kann ein verlags-eigenes Layout (z. B. Templates, Farben, Schriften) global durchgesetzt werden – unabhängig von der ursprünglichen Gestaltung der Quellformate.

Während andere Formate (PDF-Rohdaten, Octpmlx, Match-Format) vor allem auf Layout, Zeichenfolge oder Position fokussiert waren, stellt exHTML eine semantisch strukturierte Repräsentation dar, in der:

• logische Gliederungseinheiten (z. B. <section>, <article>, <figure>, <table>) klar ausgewiesen sind,
• hierarchische Überschriften (<h1> bis <h6>) eine semantische Gewichtung ermöglichen,
• und strukturgebende HTML-Elemente (z. B. <ul>, <div>, <blockquote>, <aside>) eine Grundlage für regelbasiertes Chunking bieten.

Diese Elemente dienen als Ansatzpunkte für die spätere Transformation in ChunkML – dem Format, das explizit für das spätere Chunking dient.

Der Elementkatalog ist stark reduziert, aber vollständig ausreichend für typisierte Inhalte. Die erlaubten Elemente lassen sich funktional wie folgt gliedern:

1. Strukturelle Container

• <html>, <head>, <body>, <section>, <div>, <page>

2. Textgliederung

• Überschriften: <h1>, <h2>, <h3>, <h4>, <h5>, <h6>
• Absatzgliederung: <p>, <br>

3. Textauszeichnung

• <b> (fett), <i> (kursiv), <u> (unterstrichen), <span>, <a>

4. Listenelemente

• Ungeordnet: <ul>, <li>
• Geordnet: <ol>, <li>

5. Tabellenstruktur

• <table>, <thead>, <tbody>, <tr>, <td>, <th>, <colgroup>, <col>

6. Medien-Elemente

• <img>

7. Metainformation

• <meta>

Diese Auswahl orientiert sich am Ziel, lesbare, strukturierte und regelbasiert wandelbare Dokumente zu erzeugen, die ohne Konvertierungsfehler von XML- und HTML-Engines verarbeitet werden können.

ChunkML ist kein Container für statisch geschnittene Inhalte (z. B. 300 Token). Stattdessen basiert es auf dem Konzept der chunk-neutralen Strukturierung: Die Inhalte werden strukturgetreu, aber nicht vorsegmentiert gespeichert. Dies ermöglicht die spätere Anwendung diverser Chunking-Strategien, ohne das Ausgangsformat zu verändern.

Beispiele:

• Ein GPT-Modell erhält ChunkML in Token-basierten Fragmenten mit konfigurierbarer Überlappung.
• Ein eLearning-System erzeugt aus denselben Daten kapitelweise Lerneinheiten.
• Ein semantisches Retrieval-System identifiziert Chunks anhand von semantischen Trennmarkern wie <h2> oder <table>.

ChunkML ist eingebettet in ein modulares Verarbeitungssystem, das auf etablierten und leistungsfähigen XML-Technologien basiert. Dazu zählen:

• XSLT – zur regelbasierten Chunk-Extraktion, HTML-Konvertierung und Format-Transformation
• XProc – zur orchestrierten Abarbeitung ganzer Dokument-Pipelines
• XQuery – für performante, präzise Volltextsuche und Chunk-Bildung über große Korpora hinweg
• Python – für Tokenisierung, semantisches Chunking, Preprocessing
• lokale LLMs – zur Inhaltsklassifikation, semantischen Labeling und Chunk-Priorisierung
• XML-Datenbanken – für persistente, strukturierte Ablage und Massenverarbeitung

Dieses bewusst modulare Setup ist in Umgebungen wie technische Dokumentation, Crossmedia-Publishing oder akademisches Wissensmanagement etabliert und erlaubt höchste Kontrolle, Flexibilität und Automatisierung.

ChunkML ist das Pivot-Format für alle Chunking-Strategien: Es strukturiert Inhalte medienneutral und chunk-neutral – und erlaubt, auf dieser Basis beliebige Chunks zu erzeugen. Es bildet den strategischen Kern der Datenstrukturierung in unserer RAG-Architektur, weil es:

• semantisch ausdrucksstark,
• technologisch anschlussfähig (XML, HTML, Web, Print),
• fehlertolerant und robust ist,
• und automatisiert wandelbar in alle Zielmedien und Modelle.

Damit stellt ChunkML sicher, dass Inhalte nicht an ein konkretes Zielsystem gebunden sind, sondern dynamisch – gemäß Nutzungsanforderung – in die jeweils benötigte Form gebracht werden können.

Zur Veranschaulichung der im vorherigen Abschnitt beschriebenen Strukturprinzipien sowie der praktischen Anwendung von ChunkML in konkreten Ausleitungsszenarien, verwenden wir im Folgenden ein speziell konstruiertes Beispieldokument: PDF2ChunkML\01_ChunkML\sampleChunkML.html.

Dieses Dokument dient als strukturierte Demonstrationsgrundlage für verschiedene Verarbeitungsschritte in unserer Pipeline. Es enthält:

• mehrere logisch getrennte Inhaltsblöcke, wie sie typisch für Fachtexte, Lehrmaterialien oder wissenschaftliche Artikel sind,
• zahlreiche semantische Strukturmarker (z. B. <section>, <h1>, <table>, <ul>),
• exemplarische Metastrukturen und Inline-Auszeichnungen (z. B. <b>, <a>, <i>),
• sowie erweiterte Inhaltskomponenten wie:
  • Fußnoten und Endnoten
  • Tabellen mit mehrspaltigem Aufbau und Überspannungen
  • Literaturverweise und Quellennachweise
  • allgemeine Metadaten zu Autorenschaft, Publikationsdatum, Fachdomäne u. a.

Zweck und Rolle des Beispieldokuments:

Das sampleChunkML-Dokument wurde gezielt so gestaltet, dass es die zentralen Verarbeitungslogiken unseres Systems unter realitätsnahen Bedingungen abbildet. Es erfüllt dabei mehrere Rollen:

1. Referenzstruktur für Chunking-Strategien (regelbasiert oder dynamisch),
2. Testumgebung für Transformationen in verschiedene Ausgabeformate (PDF, DOCX, HTML, Markdown),
3. Evaluationsbasis für Annotation, Metadatenverknüpfung und Retrieval-Mapping.

Die Konfiguration erlaubt die Auswahl einer oder mehrerer Strategien, abhängig vom Dokumenttyp, der gewünschten Genauigkeit und der Verwendungsform der Chunks. Jede Strategie bringt spezifische Stärken und Schwächen mit sich:

In der gegebenen Konfiguration ist derzeit Hierarchical aktiv. Diese Strategie ist besonders nützlich für strukturierte Inhalte, wie wissenschaftliche Artikel, Handbücher oder technische Dokumentationen. Sie erlaubt eine flexible Zerlegung auf mehreren Ebenen, z. B. von Kapitelüberschriften bis zu Unterabschnitten und Absätzen.

<ChunkingStrategy> 
    <Strategy type="Hierarchical" />
    ...
</ChunkingStrategy>

Der Block <Additional> erlaubt eine feingranulare Steuerung des Chunking-Verhaltens:

<Additional>
    <Duplicate enabled="true" />
    <AllowOverlap enabled="true" />
    <Referencing enabled="true" /> 
    <Superchunks enabled="true" /> 
    <Counting>
        <Type>Word</Type>
        <Type>Character</Type>
    </Counting> 
</Additional>

4.7.2.1 <Duplicate enabled="true"/>

4.7.2.2 <AllowOverlap enabled="true"/>

4.7.2.3 <Referencing enabled="true"/>

4.7.2.4 <Superchunks enabled="true"/>

4.7.2.5 <Counting>

• txt: Reiner Text ohne Markup – minimalistisch, aber informationsarm
• markdown: Leichtgewichtiges Markup – besonders gut geeignet für GPT-Modelle
• html: Strukturierter, web-orientierter Output – nützlich bei visuellen Layouts oder verlinkten Inhalten
• rtf: Rich Text Format – z. B. für Desktop-Export oder Word-Verarbeitung

Die Pipeline erlaubt es, verschiedene Ausgabeformate bereitzustellen, weil LLMs unterschiedlich auf strukturelle Formate reagieren. Manche Modelle (z. B. GPT-4) sind mit Markdown besonders effektiv, andere tun sich mit HTML oder verschachtelten XML-Formaten schwer oder interpretieren sie unvollständig. Durch die Bereitstellung mehrerer Strukturvarianten können systematische Tests durchgeführt werden, um:

• Modellreaktionen auf Formatunterschiede zu evaluieren
• Fehlerquellen wie Missinterpretation von Tags zu identifizieren
• die optimale Kombination aus Chunk-Struktur und LLM-Typ zu bestimmen

Wenn diese Option aktiviert ist, werden zielgerichtete Transformations- und Reinigungsmaßnahmen angewendet, um das Format für LLMs lesbarer und robuster zu machen. Dazu gehören insbesondere:

• Vereinfachung verschachtelter Strukturen (z. B. bei HTML-Listen oder XML-Nesting)
• Reduktion auf lineare Lesbarkeit – z. B. durch die Umwandlung komplexer Tabellen in Fließtext und die Auflösung von Spalten- und Zeilenüberspannungen (colspan/rowspan)

Diese Maßnahmen dienen dazu, typische Parsing-Probleme bei LLMs zu reduzieren und die Lesbarkeit auch in längeren Kontexten zu verbessern.

Ziel dieser Optimierung:

Die strukturelle Optimierung des Formats dient mehreren Zwecken:

• Verbesserte Eingabeklarheit für das LLM
• Geringeres Risiko für „Halluzinationen“ oder fehlerhafte Modellinterpretationen
• Höhere Genauigkeit bei Retrieval und Antwortgenerierung
• Kompaktere, effizientere Embeddings bei Verwendung vektorisierter Chunks

Hintergrund

Beim Einsatz großer Sprachmodelle (LLMs) wie GPT-4 oder text-ada-001 ist die Verarbeitungseinheit nicht primär ein Wort oder Satz, sondern ein sogenannter Token. Tokens sind minimale Bedeutungseinheiten, die vom jeweiligen Modell-Tokenizer erzeugt werden – je nach Sprachstruktur und Modellarchitektur. Das Verständnis und die Steuerung der Tokenisierung ist daher ein zentraler Bestandteil effizienter LLM-Nutzung.

Gründe für die Speicherung von Tokens im Chunk

Die explizite Aufbewahrung der Tokens in den Chunks – also als Teil der strukturierten Ausgabedaten – bringt eine Reihe analytischer und praktischer Vorteile:

1. Nachvollziehbarkeit und Debugging
   Bei Fehlverhalten (z. B. Halluzination, unerwünschte Kürzungen) hilft die Token-Liste zu verstehen, wie das Modell den Input interpretiert hat.
2. Vergleichbarkeit zwischen Modellen
   Verschiedene Modelle verwenden unterschiedliche Tokenizer. Die Token-Informationen erlauben es, das Verhalten unterschiedlicher Modelle nachvollziehbar zu vergleichen.
3. Optimierung der Kontextfensternutzung
   Viele LLMs arbeiten mit festen Token-Grenzen (z. B. 4096 oder 8192 Tokens). Die Kenntnis der Token-Anzahl pro Chunk ermöglicht es, diese Grenzen gezielt zu nutzen, ohne Trunkierungen zu riskieren.
4. Modellgerechte Chunk-Steuerung
   Die Token-Anzahl kann zur präzisen Steuerung von:
   • Chunk-Längen
   • semantischer Überlappung
   • inhaltlicher Kohärenz

   genutzt werden.

5. Integration in nachgelagerte Systeme
   RAG-Architekturen und Suchsysteme profitieren von Token-Listen, z. B. für:
   • Maskierung
   • semantische Repräsentation
   • granularen Re-Ranking-Prozesse

Beispiel: Zielformat eines Chunks

Die Ausgabe eines Chunks im Hub-System folgt einer standardisierten JSON-Struktur. Beispiel:

{
  "id": "2",
  "content": "Die digitale und ökologisch nachhaltige Transformation...",
  "tokens": ["Die", " digit", "ale", " und", " ök", "..."],
  "token_ids": [32423, 16839, 1000, 3318, 928, "..."],
  "count_tokens": 270,
  "count_words": 92,
  "count_characters": 777
}

• tokens: Die dekodierten Token-Segmente (Strings)
• token_ids: Die numerischen IDs, wie vom Modell verwendet
• count_tokens: Anzahl Tokens in diesem Chunk (wichtig für Steuerung)
• count_words / count_characters: Klassische Referenzgrößen

Das Hub-System bietet eine standardisierte, modulare XML-Konfiguration, mit der sich für jeden Verarbeitungsschritt gezielt festlegen lässt, welcher Tokenizer verwendet werden soll. Die Auswahl erfolgt entweder über ein bekanntes Modell (LLM) oder direkt über einen spezifischen Encoding-Namen.

Konfigurationsstruktur:

Die Konfiguration erfolgt über ein <Token>-Element mit folgenden Optionen:

• <Llm>
  Definiert den Modellnamen (z. B. gpt-4, meta-llama/Meta-Llama-3-8B).
  Der passende Tokenizer wird automatisch über ein internes Mapping gewählt.
• <EncodingName>
  Erlaubt die manuelle Angabe eines Encodings (z. B. cl100k_base, p50k_base).
  Dies bietet maximale Kontrolle für gezielte Einsätze.

Regeln:

• Entweder <Llm> oder <EncodingName> muss angegeben werden.
• Wenn beide vorhanden sind, hat <Llm> Vorrang.
• Bei ungültigen Werten liefert das System strukturierte Hinweise zur Korrektur.

Beispiele:

Modellreferenziert:

<Token>
  <Llm>gpt-4</Llm>
</Token>

Encoding-explizit:

<Token>
  <EncodingName>cl100k_base</EncodingName>
</Token>

Vorteile:

• Einfache Steuerung: Modell- oder Encoding-basiert
• Flexibilität: Für manuelle oder automatisierte Workflows
• Robustheit: Mit Fallback-Logik und Fehlerbehandlung

Die Speicherung von Tokens pro Chunk und die modulare Steuerung der Tokenizer-Strategie im Hub-System sind zentrale Bestandteile für eine transparente, kontrollierte und leistungsfähige LLM-Integration. Sie ermöglichen datengetriebene Chunk-Steuerung, Cross-Modell-Analysen und eine fein abgestimmte Kontrolle über den gesamten Token-Fluss – von der Quelle bis zum Modellkontext.

• json: Strukturiertes Schlüssel-Wert-Format; weit verbreitet, LLM-freundlich, ideal für APIs und semantische Workflows
• xml: Hierarchisches Markup; hervorragend geeignet für semantisch reichhaltige Inhalte mit klarer Struktur
• txt: Reiner Text ohne Struktur oder Markup; maximale Einfachheit, aber Verlust jeglicher Metadaten
• csv: Komma-getrenntes Format
• yaml: Menschlich gut lesbare, strukturierte Auszeichnung; Alternative zu JSON

Die Wahl des Serialisierungsformats wirkt sich auf mehrere Ebenen aus:

• Speicherung: Die Datenbank oder der Dateispeicher muss das Format unterstützen (z. B. JSON für NoSQL, XML für XQuery-basierte Systeme).
• Übertragung: APIs, Webhooks oder Bus-Systeme bevorzugen oft JSON oder YAML.
• Verarbeitung durch LLMs: Während Plaintext und Markdown direkt interpretiert werden, müssen strukturierte Formate wie XML oder JSON für LLMs ggf. vorab normalisiert oder vereinfacht werden.
• Nachvollziehbarkeit & Debugging: YAML und JSON sind gut lesbar, während XML sich besser für Validierung und maschinelle Analyse eignet.

• zip: Standardformat mit breiter Unterstützung in Betriebssystemen, Tools und APIs
• rar: Proprietäres Format mit hoher Kompression – erfordert spezielle Software (z. B. WinRAR)
• 7z: Offenes Format mit hoher Kompressionsrate und Unterstützung für Verschlüsselung sowie „solid archiving“

• type: Gibt den gewünschten Archivtyp an
• passwordProtected: Steuert, ob das Archiv passwortgeschützt ist
• password: Optionales Passwort für verschlüsselte Archive (nicht erforderlich bei passwordProtected=“false“)
• enabled: Aktiviert oder deaktiviert die Archivierung als Funktion

Das Archiv enthält nicht nur die Chunks, sondern kann zusätzlich auch weitere datei-basierte Ergebnisse der Pipeline enthalten. Typische Beispiele:

• Original-PDFs, etwa auf Einzeldateien je Seite aufgeteilt (wenn split="true" gesetzt ist)
• Word-Dateien, z. B. generierte .docx-Versionen des Inhalts
• Excel-Tabellen oder strukturierte .csv-Dateien
• exHTML- oder Markdown-Fassungen für Web- oder LLM-Einsatz
• ggf. MP3-Dateien oder andere Medienformate, wenn entsprechende TTS-Module verwendet werden

Diese gebündelte Ablage macht das Archiv zu einem vollständigen Content-Paket, das für menschliche Nutzer ebenso wie für Maschinen lesbar ist. Besonders bei Übergabe an Drittanbieter, Archivierung oder Offline-Verarbeitung ist das ZIP-Format ideal geeignet.

Zentrale Container-Beschreibung, die alle enthaltenen Bestandteile verlinkt und klassifiziert. Dient als Einstiegspunkt für maschinelle Systeme.

Dokumentiert die Verarbeitungsparameter, Versionen und eingesetzten Module der RAG-Pipeline. Diese Datei ist wichtig für Auditierung und Debugging.

Hier befinden sich sämtliche Verarbeitungsartefakte des Dokuments:

• source/: Enthält das Originaldokument (z. B. PDF).
• raw/: Layout-Daten im Zeichenformat (siehe EingangsBeispiel_char.xml), notwendig für präzises Parsing.
• plain/: Reiner Fließtext, z. B. für Previews oder Vergleich mit OCR.
• meta/: XMP-Metadaten im RDF-/XML-Format, maschinenlesbar und anreicherbar.
• split/: Einzelseiten in mehreren Formaten – ideal für seitenbasiertes Retrieval.
• svg_path/ und svg_text/: Layout-exakte bzw. DOM-interaktive SVG-Varianten.
• octpmlx/: Format für positionsgenaue, zeilenbasierte Volltextsuche.
• chunkML/: HTML-basierte, chunk-neutrale Pivot-Struktur für strukturierte Ausleitungen.
• exHTML/: Medienneutrale HTML-Ausgabe mit CSS und Assets (Bilder, etc.).
• chunkstrategy/HubConfiguration.xml: Steuerdatei für die Chunking-Logik.
• displayGeneratedFormats/: Endformate für Nutzer oder Zielsysteme (PDF, DOCX, etc.).