5 Auswahl der Konvertierungstools

ChatGPT von OpenAI zählt zu den großen, multimodalen Sprachmodellen. Für diese Studie wurde ein prompt-gesteuerter Konvertierungsansatz mit dem Modell GPT-5.3 in der Bezahlversion „Business“ gewählt. Das Modell übernimmt in diesem Setting nicht nur einfache Texterkennung, sondern trifft fortlaufend strukturelle Entscheidungen. Das Testdokument wird auf Basis sichtbarer Merkmale und der im Prompt festgelegten Regeln rekonstruiert.

Für die Markdown- und XML-Konvertierungen wurden unterschiedliche Einstellungen bei der „Denkzeit“ genutzt. Während für die Konvertierungsstrecke „PDF-zu-Markdown“ der Reasoning-Modus mit der höchsten Denkzeit zum Einsatz kam, wurde für die Konvertierungsstrecke „PDF-zu-XML“ die Standardeinstellung genutzt. In diesem Modus gibt das Modell Antworten ohne ausführliche, im Hintergrund sichtbare Rechenschritte.

Die Verarbeitung beginnt mit dem Bereitstellen des PDFs und eines ausführlichen Prompts. Der Prompt definiert die Anforderungen an die Konvertierung und legt fest, wie das Dokument interpretiert, strukturiert, bereinigt und ausgegeben werden soll. Da der interne Ablauf der Dokumentenverarbeitung für ChatGPT nicht öffentlich dokumentiert ist, beruhen die im Folgenden skizzierten Verarbeitungsschritte lediglich auf Annahmen.

Im ersten Verarbeitungsschritt erfasst ChatGPT die Inhalte des Dokuments, anschließend werden die Struktur und das Layout analysiert. Dabei werden die Positionen und Beziehungen einzelner Elemente auf der Seite berücksichtigt. Das Modell identifiziert unter anderem Überschriften, Absätze, Listen, Tabellen, Bildunterschriften sowie Fuß- und Kopfzeilen. Gleichzeitig wird die Lesereihenfolge der Inhalte bestimmt. Dies ist insbesondere bei mehrspaltigen Layouts, eingebetteten Grafiken oder komplexen Seitenstrukturen von Bedeutung.

Im nächsten Schritt erfolgt die Rekonstruktion der logischen Dokumentstruktur. Dabei werden die zuvor erkannten Elemente nicht lediglich übernommen, sondern in einen inhaltlichen Zusammenhang gebracht. Das Modell bewertet beispielsweise die Hierarchie von Überschriften, ordnet Absätze den entsprechenden Abschnitten zu und rekonstruiert die Struktur von Tabellen anhand ihrer Zeilen- und Spaltenbeziehungen. Ziel dieses Schrittes ist die Erstellung eines kohärenten, logisch aufgebauten Dokumentmodells.

Auf Grundlage dieses internen Dokumentmodells wird das Dokument anschließend in das gewünschte Zielformat überführt. Hierbei werden die identifizierten Strukturelemente in die entsprechenden Formatierungsregeln von XML oder Markdown übersetzt. Überschriften werden beispielsweise als hierarchische Elemente abgebildet, Listen als strukturierte Aufzählungen ausgegeben und Tabellen in die jeweilige Zielsyntax übertragen.

Gemini von Google zählt ebenfalls zu den großen, multimodalen Sprachmodellen. Auch hier steuert ein detaillierter Prompt die Verarbeitung. Der Fokus liegt auf einer möglichst strukturtreuen Rekonstruktion des PDFs in Markdown oder XML. Für diese Studie wurde das Modell „Gemini 3 Flash“ im Thinking-Modus genutzt, der sich besonders für komplexe Layout- und Strukturentscheidungen eignet.

Die Verarbeitung beginnt mit dem Bereitstellen des PDFs und eines ausführlichen Prompts. Auch für Gemini ist der interne Ablauf der Dokumentenverarbeitung nicht öffentlich dokumentiert, die im Folgenden skizzierten Verarbeitungsschritte beruhen ebenfalls lediglich auf Annahmen.

Zunächst wird das Dokument vollständig eingelesen und in einzelne Seiten sowie visuelle und inhaltliche Segmente zerlegt. Anschließend beginnt die eigentliche multimodale Analyse. Gemini arbeitet dabei nicht als klassisches OCR-Tool, sondern als multimodales bzw. dokumentverstehendes KI-System. Es analysiert Text, Layout und visuelle Hinweise gemeinsam. Der Thinking-Modus dient dazu, komplexe Entscheidungen nicht nur oberflächlich zu treffen, sondern die Struktur eines Dokuments schrittweise zu erschließen. Besonders wichtig ist das bei mehrspaltigen Seiten, verschachtelten Listen, Formeln, Tabellen oder mehrsprachigen Passagen.

Ein typischer erster Arbeitsschritt ist die detaillierte Strukturanalyse. Das Modell erkennt dabei Überschriften, Nummerierungen, typografische Unterschiede, Abstände und Positionen im Seitenlayout. Daraus wird eine hierarchische Struktur des Dokuments abgeleitet. Parallel werden OCR-Ergebnisse mit visuellen Layout-Informationen abgeglichen, um mögliche Erkennungsfehler zu korrigieren oder zu kontextualisieren. Darauf folgt die Rekonstruktion der Lesereihenfolge.

Im letzten Schritt erfolgt die Überführung in das Zielformat (Markdown oder XML). Hierbei werden die zuvor ermittelten Strukturen in semantische Elemente überführt, beispielsweise Überschriften, Absätze, Listen oder Tabellen. Gleichzeitig werden OCR-basierte Unsicherheiten durch kontextuelle Modellentscheidungen ausgeglichen, um eine möglichst konsistente und strukturtreue Ausgabe zu erzeugen.

In dieser Studie lässt sich die Mistral Document AI als moderner Vertreter einer neuen Generation von OCR-Systemen einordnen, die optische Zeichenerkennung mit modellbasierter Dokumentinterpretation kombinieren. Im Unterschied zu einer klassischen PDF-Konvertierung wird das Dokument nicht nur technisch ausgelesen, sondern visuell und sprachlich analysiert.

Zum Einsatz kamen der Mistral Playground und die dort integrierte „Document AI“, die das neueste (Stand 26.03.2026) verfügbare OCR-Modell „Mistral OCR 3“ (Modell-ID: mistral-ocr-2512) nutzt.

Der Verarbeitungsprozess beginnt mit dem Upload des PDFs in den Mistral Playground. Die Plattform stellt hierfür eine cloudbasierte Umgebung bereit, in der Dokumente direkt verarbeitet werden können, ohne dass lokale Installationen oder zusätzliche Infrastruktur erforderlich sind. Die Cloud-Verarbeitung wurde auch in dieser Studie genutzt. Nach dem Upload übernimmt die integrierte Document AI automatisch die Analyse der Dokumente. Dabei wird das OCR-Modell seitenweise auf das PDF-Dokument angewendet.

Im Unterschied zu klassischen OCR-Systemen basiert Mistral OCR nicht ausschließlich auf der Erkennung einzelner Zeichen oder Wörter. Stattdessen kombiniert das System visuelle Dokumentanalyse mit sprachmodellbasierter Interpretation. Dadurch können neben reinem Text auch strukturelle und semantische Zusammenhänge besser rekonstruiert werden. Beispielsweise lassen sich Überschriften, Absätze, einfache Tabellenstrukturen oder Layoutbeziehungen häufig zuverlässiger identifizieren als bei traditionellen OCR-Ansätzen.

Ein zentraler Vorteil dieses Ansatzes liegt in der Verbindung von OCR-Technologie mit großen Sprachmodellen. Während klassische OCR-Systeme häufig nur eine linearisierte Textausgabe erzeugen, versucht Mistral OCR zusätzlich, die logische Struktur des Dokuments zu erfassen.

In diesem Testszenario arbeitet Mistral bei der PDF-Konvertierung stärker automatisiert als ChatGPT oder Gemini, da viele Verarbeitungsschritte bereits in der Document-AI-Umgebung vorgegeben sind. Das macht das Verfahren einfacher und schneller, reduziert aber die direkte Steuerbarkeit. Während bei prompt-gesteuerten Sprachmodellen genau festgelegt werden kann, wie die verschiedenen Inhaltselemente eines Dokuments verarbeitet werden sollen, arbeitet Mistral stärker nach den systeminternen Regeln des Modells.

Im praktischen Ablauf entstanden aus dem PDF zwei Ausgaben: Das Testdokument wurde sowohl als Gesamt-Datei als auch als Einzelseiten ins Markdown-Format überführt.

OpenDataLoader der Firma Hancom Inc. ist ein Open-Source-Werkzeug und zählt zu den klassischen Toolchains für die strukturierte Extraktion aus PDF-Dokumenten. Im Unterschied zu einfachen PDF-Parsern ist es auf moderne KI-Anwendungen ausgerichtet. Es versucht, aus einem PDF nicht nur Text zu extrahieren, sondern eine strukturierte, semantisch nutzbare Ausgabe zu erzeugen.

Die Arbeitsweise von OpenDataLoader beginnt mit der Analyse der PDF-Seiten. Das Tool betrachtet die Seite nicht nur als Textquelle, sondern als Layout-Fläche. Es identifiziert Textblöcke, Überschriften, Absätze, Listen, Tabellen, Bilder und andere Dokumentelemente. Ein besonders wichtiger Bestandteil sind Positionsinformationen. Elemente werden mit „Bounding Boxes“ versehen, also mit Koordinaten, die ihre genaue Position auf der Seite beschreiben. Diese Positionsinformationen sind methodisch sehr wichtig. Sie ermöglichen, ein extrahiertes Textelement später wieder auf seine ursprüngliche Stelle im PDF zurückzuführen.

Im Standardmodus arbeitet das Tool regelbasiert. Ein zentrales Prinzip ist die Layout-Analyse, unter anderem auf Basis eines erweiterten XY-Cut-Verfahrens. Dabei wird eine Seite rekursiv in Blöcke unterteilt. Das System erkennt, welche Bereiche zusammengehören, welche Blöcke nebeneinanderstehen und in welcher Reihenfolge sie gelesen werden sollten. Nach der Blockerkennung werden die einzelnen Elemente klassifiziert. Überschriften werden als solche markiert, Absätze zusammengeführt, Listenstrukturen erkannt und Tabellen analysiert.

Beim OpenDataLoader kann ein zusätzlicher Hybridmodus aktiviert werden. In diesem Modus wird die regelbasierte Verarbeitung durch KI- oder OCR-Komponenten ergänzt. Dies ist vor allem bei „schwierigen“ Dokumenten relevant, z.B. bei eingescannten PDFs oder Dokumenten mit komplexen Tabellen ohne Rahmenlinien. Hier kommt OCR zum Einsatz, unterstützt durch Modelle, die mehr als 80 Sprachen verarbeiten können.

In dieser Studie kam ausschließlich der Standardmodus des OpenDataLoader zum Einsatz. Der Hybridmodus wurde nicht genutzt, da er den Einsatz eines Sprachmodells erforderlich macht, wodurch wiederum Aspekte wie z.B. Datenhoheit und Datenschutz komplizierter werden.

Poppler und Pandoc gelten als eine klassische, technisch gut nachvollziehbare Konvertierungskette. Die Verarbeitung erfolgt in zwei Schritten: Das PDF wird zunächst technisch ausgelesen und anschließend in ein anderes Dokumentformat überführt.

Poppler ist eine Open-Source-Bibliothek von freedesktop.org zur Verarbeitung von PDF-Dateien. In der eingesetzten Pipeline wird vor allem das Werkzeug „pdftohtml“ verwendet. Dieses Tool analysiert die PDF-Datei auf der Ebene ihrer internen Seitenbeschreibung. Poppler liest diese Bestandteile aus und versucht, sie in eine HTML-Struktur zu übertragen. Dabei werden Textpositionen, Seitenbereiche, Schriftinformationen und teilweise auch Layout-Merkmale berücksichtigt. Poppler extrahiert den Text nicht wie ein Sprachmodell interpretierend, sondern folgt der technischen Struktur des PDFs.

Im zweiten Schritt wird Pandoc eingesetzt. Das von John MacFarlane entwickelte Pandoc ist ein universeller Dokumentenkonverter, der viele Formate ineinander überführen kann. In dieser Pipeline nimmt Pandoc die von Poppler erzeugte HTML-Datei als Eingabe und wandelt sie in Markdown um. Dabei interpretiert Pandoc HTML-Elemente wie Überschriften, Absätze, Listen oder Tabellen und erzeugt daraus eine Markdown-Syntax.

Die Orchestrierung dieser beiden Werkzeuge erfolgt über ein leichtgewichtiges Python-Skript, das die einzelnen Verarbeitungsschritte sequenziell ausführt. Python übernimmt dabei keine inhaltliche Verarbeitung der Dokumente, sondern dient ausschließlich der Steuerung der Pipeline sowie der Automatisierung von Einzel- und Batch-Verarbeitungen.

Die Besonderheit dieses technischen Ansatzes liegt in der Kombination zweier spezialisierter Werkzeuge. Poppler extrahiert und visualisiert die PDF-Struktur in HTML, Pandoc überführt diese HTML-Struktur in Markdown.

Unser hauseigener Octopus Service kann im Rahmen dieser Studie als traditionelle Toolchain angesehen werden, die nur in spezifischen Fällen OCR nutzt. Die Konvertierung von PDF zu EXHTML ist jedoch nur eine von zahlreichen Konvertierungsstrecken und Funktionen der Plattform. Da es sich bei Octopus um das Ergebnis jahrelanger eigener Entwicklungsarbeit handelt, kann dessen Funktionsweise (im Vergleich zu den anderen eingesetzten Tools) deutlich detaillierter beschrieben werden.

Die Verarbeitung beginnt auf der niedrigsten Ebene des PDF-Dokuments: den einzelnen Zeichen. Bereits zu Beginn stehen für jedes Zeichen umfangreiche Informationen zur Verfügung. Dazu gehören unter anderem die exakten Koordinaten auf der Seite, die geometrische Ausdehnung, Schriftart, Schriftgröße, Farbe und weitere PDF-spezifische Eigenschaften. Die Konvertierung beginnt somit nicht mit Wörtern, Zeilen oder Absätzen, sondern mit den tatsächlichen grafischen Objekten des PDF-Dokuments. Zu diesem Zeitpunkt ist bereits bekannt, welches Zeichen sich an welcher Position auf welcher Seite befindet.

Im nächsten Schritt werden benachbarte Zeichen analysiert und zu größeren Einheiten zusammengeführt. Dabei entstehen zunächst Wörter und anschließend Zeilen. Zeichen mit identischen typografischen Eigenschaften werden dabei zu sogenannten „Spans“ aggregiert. Während auf der unteren Ebene noch jedes einzelne Zeichen sichtbar ist, repräsentiert die Zeile bereits logisch zusammengehörige Textsegmente. Die ursprünglichen Zeicheninformationen bleiben dabei erhalten und können jederzeit nachvollzogen werden.

Die Analyse erfolgt zunächst vollständig auf Seitenebene. Für jede Seite werden die erkannten Zeilen zu größeren Strukturen zusammengeführt. Dabei entstehen beispielsweise Überschriften, Absätze, Listen, Tabellenbereiche oder Bildcontainer. Jede dieser Strukturen basiert auf den zuvor erkannten Zeilen und deren geometrischen Beziehungen. Die Entscheidung, ob eine Zeile beispielsweise zu einer Überschrift, einem Absatz oder einer Tabelle gehört, erfolgt anhand definierter Strukturierungsregeln.

Nachdem die einzelnen Seiten aufgebaut wurden, beginnt die dokumentweite Analyse. Erst in diesem Schritt werden Zusammenhänge erkannt, die über Seiten hinweg reichen. Typische Beispiele sind unter anderem Tabellen, die durch einen Seitenumbruch getrennt wurden, mehrseitige Listen, fortlaufende Kapitel oder Kopf- und Fußzeilen. Eine Tabelle kann beispielsweise auf zwei oder mehr Seiten verteilt sein. Obwohl sie zunächst als separate Seitenstrukturen erkannt wird, werden die Fragmente später zu einer gemeinsamen Tabellenstruktur zusammengeführt.

Das Ergebnis der Analyse ist EXHTML, ein XML-basiertes Zwischenformat, welches die vollständige Dokumentstruktur beschreibt. EXHTML dient als zentrale Repräsentation innerhalb der Konvertierungspipeline. Es enthält deutlich mehr Informationen als reine Textformate und bewahrt sowohl strukturelle als auch typografische Eigenschaften des Ursprungsdokuments.

Da EXHTML sämtliche erkannten Strukturen enthält, eignet es sich als Ausgangspunkt für unterschiedlichste Ausgabeformate, wie z.B. Markdown, HTML, DOCX, XML-Formate, EPUB, PDF, SCORM-Inhalte, etc. Markdown stellt dabei lediglich eine vereinfachte Sicht auf die Dokumentstruktur dar. Viele Informationen, die in EXHTML enthalten sind, können in Markdown nicht vollständig dargestellt werden. EXHTML bleibt daher die informationsreichste Repräsentation des Dokuments.

Bilder werden unabhängig von der eigentlichen Dokumentstruktur verarbeitet. Enthält ein PDF eingebettete Bilder, kann optional eine OCR-Komponente eingesetzt werden. Diese analysiert die Bildinhalte, extrahiert vorhandene Texte und erzeugt zusätzlich beschreibende Informationen zum Bildinhalt. Die gewonnenen Informationen werden anschließend in die bestehende Dokumentstruktur integriert. Dieser Schritt wird ausschließlich bei Bedarf ausgeführt. Für textbasierte PDF-Dokumente ist keine OCR-Verarbeitung erforderlich.

Die Octopus-PDF-Konvertierung arbeitet vollständig deterministisch und regelbasiert. Die Analyse basiert ausschließlich auf den im PDF vorhandenen Informationen sowie auf definierten Strukturierungs- und Aggregationsregeln. Verfahren der generativen KI oder des maschinellen Lernens sind nicht Bestandteil der PDF-Konvertierung. Die erzeugten Dokumentstrukturen entstehen ausschließlich durch die systematische Auswertung der PDF-Inhalte und die schrittweise Aggregation von Zeichen zu immer größeren und semantisch aussagekräftigeren Strukturen.

Durch diese mehrstufige Pipeline entsteht aus den elementaren PDF-Objekten schrittweise eine hochwertige strukturierte Dokumentrepräsentation, deren Entstehung jederzeit nachvollziehbar bleibt. Ein zentrales Merkmal der Octopus-Architektur ist die vollständige Rückverfolgbarkeit aller erzeugten Inhalte. Während der Verarbeitung werden nicht nur die erkannten Dokumentstrukturen gespeichert, sondern auch die Beziehungen zu den ursprünglichen PDF-Objekten erhalten.

Hierfür verwendet Octopus ein spezielles Containerformat auf Basis eines ZIP-Archivs. Dieses Containerformat bündelt sämtliche während der Verarbeitung entstehenden Artefakte. Dazu gehören die verschiedenen Zwischenrepräsentationen, das erzeugte EXHTML, Metadaten zur Dokumentanalyse sowie die Verknüpfungen zwischen den erzeugten Strukturen und den ursprünglichen PDF-Koordinaten. Dadurch bleibt für jeden erzeugten Inhalt nachvollziehbar, aus welchem Bereich des Ursprungsdokuments er stammt. Dies ist insbesondere für Retrieval-Systeme von Bedeutung. Wird ein Chunk im Rahmen einer Suche oder eines RAG-Systems als Quelle verwendet, kann nicht nur die Ursprungsseite angegeben werden, sondern auch die exakte Fundstelle innerhalb des Dokuments. Dadurch entstehen zitierfähige und überprüfbare Referenzen.

Zusätzlich stellt Octopus Visualisierungskomponenten bereit, die diese Herkunftsinformationen grafisch darstellen können. Anwender können sich anzeigen lassen, aus welchem Bereich eines Dokuments ein bestimmter Chunk oder eine bestimmte Antwort stammt. Die zugrunde liegenden Textstellen werden dabei direkt im Dokument hervorgehoben und können bis auf die ursprünglichen PDF-Positionen zurückverfolgt werden.