2 Einordnung der Studie

Die möglichen Zielformate einer Dokumentenkonvertierung unterscheiden sich erheblich in ihrem Zweck und in ihrer strukturellen Ausdrucksfähigkeit. Inhalte können beispielsweise in Markdown, HTML, XML, DOCX, EPUB, JSON, LaTeX oder in anwendungsspezifische Zwischenformate überführt werden. Welches Zielformat geeignet ist, hängt davon ab, ob ein Dokument anschließend publiziert, redaktionell bearbeitet, archiviert, durchsucht, analysiert oder innerhalb eines RAG-Systems verarbeitet werden soll.

In dieser Studie wurden insbesondere Markdown, DocBook XML und EXHTML betrachtet. Diese Formate sind nicht gleichwertig und verfolgen unterschiedliche Ziele. Markdown ist in erster Linie eine leicht lesbare und einfach zu erzeugende Auszeichnungssprache. XML-basierte Formate können dagegen wesentlich detailliertere semantische, hierarchische und referenzielle Strukturen ausdrücken. EXHTML dient innerhalb der Octopus-Pipeline als informationsreiches Zwischenformat und enthält zusätzliche Struktur-, Layout- und Herkunftsinformationen. Ein unmittelbarer Vergleich der ausgegebenen Dateien ist daher nur eingeschränkt möglich.

Viele Anbieter und KI-Systeme verwenden Markdown standardmäßig als Zielformat für die Dokumentenkonvertierung. Dafür gibt es nachvollziehbare Gründe: Markdown ist menschenlesbar, vergleichsweise leicht zu erzeugen, technisch unkompliziert weiterzuverarbeiten und wird von zahlreichen Entwicklungs-, Such- und RAG-Werkzeugen unterstützt. Für einfache Dokumentstrukturen wie Überschriften, Absätze, Listen, Links, Hervorhebungen und Bildverweise kann Markdown deshalb ein sehr praktikables Arbeitsformat sein.

Gleichzeitig ist Markdown kein einheitliches und semantisch vollständiges Dokumentformat. Bereits zwischen verschiedenen Markdown-Varianten bestehen erhebliche Unterschiede. Der CommonMark-Grundumfang enthält beispielsweise Überschriften, Absätze, Listen, Links, Bilder, Hervorhebungen und Codeblöcke, aber keine native Syntax für zahlreiche weiterführende Dokumentstrukturen. GitHub Flavored Markdown ergänzt unter anderem einfache Tabellen, durchgestrichenen Text und Aufgabenlisten. Pandoc Markdown führt wiederum weitere Erweiterungen für Fußnoten, komplexere Tabellen, Mathematik, Hoch- und Tiefstellungen, Definitionen und andere Strukturen ein. Ohne Angabe des verwendeten Dialekts beschreibt die Bezeichnung „Markdown“ daher kein eindeutig festgelegtes Zielformat.

Besonders bei komplex aufgebauten Dokumenten stößt Markdown an grundsätzliche Grenzen. Dazu gehören beispielsweise:

• Tabellen mit Zeilen- und Spaltenüberspannungen oder mehrstufigen Tabellenköpfen,
• eindeutig typisierte Dokumenttitel, Kapitel und Unterkapitel,
• Fußnoten, Endnoten und ihre Referenzbeziehungen,
• strukturierte Literaturangaben mit getrennten Feldern für Autor, Titel, Jahr und Verlag,
• Verknüpfungen zwischen Literaturverweisen und Literaturverzeichnis,
• Indexeinträge mit auflösbaren Zielstellen,
• semantisch ausgezeichnete Textboxen, Warnhinweise oder Definitionen,
• Sprach- und Schreibrichtungsinformationen,
• Seitenkoordinaten, Pagina, PDF-Seitenindex und genaue Fundstellen,
• komplexe mathematische Strukturen,
• Barrierefreiheitsinformationen und PDF-Tags,
• die Unterscheidung zwischen vorhandenem Alternativtext und automatisch erzeugter Bildbeschreibung.

Einige dieser Informationen können in bestimmten Markdown-Varianten über Erweiterungen, eingebettetes HTML, YAML-Metadaten, Kommentare oder eigene Konventionen ergänzt werden. Dadurch entsteht jedoch häufig kein allgemein portables Markdown mehr. Eine Anwendung kann eine solche Erweiterung korrekt interpretieren, während eine andere sie ignoriert, als Text darstellt oder bei einer weiteren Konvertierung entfernt.

Für die Bewertung ist deshalb entscheidend, zwischen zwei unterschiedlichen Fehlerarten zu unterscheiden:

• Ein Werkzeug erkennt eine Struktur im PDF nicht.
• Ein Werkzeug erkennt die Struktur, kann sie im vorgegebenen Zielformat aber nicht vollständig ausdrücken.

Diese beiden Fälle dürfen methodisch nicht gleichgesetzt werden. Erkennt ein Konverter beispielsweise eine Tabellenüberspannung, gibt die Tabelle aufgrund der Begrenzungen einer einfachen Markdown-Syntax jedoch nur als flache Tabelle aus, liegt eine andere Art von Informationsverlust vor als bei einem System, das die Tabelle überhaupt nicht erkennt. Gleiches gilt für Fußnotenverknüpfungen, bibliografische Metadaten, Textboxen, Seitenkoordinaten oder Index-Ziele.

Die vorliegende Studie macht damit auch ein grundsätzliches Problem vieler heutiger Konvertierungsworkflows sichtbar: Bereits die frühe Festlegung auf Markdown kann zu einem strukturellen Informationsverlust führen, bevor Chunking, Retrieval oder RAG überhaupt beginnen. Eine fehlerhafte oder unvollständige RAG-Datenbasis entsteht dann nicht zwingend nur durch eine schlechte PDF-Erkennung, sondern möglicherweise schon durch ein zu ausdrucksarmes Zwischenformat.

Für einfache RAG-Szenarien kann Markdown dennoch vollkommen ausreichend sein. Überschriften, Absätze, Listen, einfache Tabellen und Bildverweise lassen sich damit gut verarbeiten. Sobald jedoch Zitierfähigkeit, genaue Quellenrückverfolgung, komplexe Tabellen, Verweissysteme, Barrierefreiheit, erneute Publikation oder eine spätere Transformation in mehrere Ausgabeformate erforderlich sind, kann ein semantisch reicheres Zwischenformat geeigneter sein. Denkbar ist beispielsweise, zunächst eine informationsreiche XML-, JSON- oder anwendungsspezifische Dokumentrepräsentation zu erzeugen und daraus anschließend eine vereinfachte Markdown-Fassung für das Chunking oder die Anzeige abzuleiten.

Das Gesamtranking dieser Studie sollte daher nicht als isolierte Bewertung der Konverter verstanden werden. Bewertet wird jeweils eine vollständige Konvertierungsstrecke:

PDF-Eingangsdatei → Werkzeug beziehungsweise Modell → Konfiguration und Prompt → Zielformat → erzeugte Datei

Ein gutes Markdown-Ergebnis zeigt, dass ein Werkzeug für den untersuchten Markdown-Workflow eine gut nutzbare Ausgabe erzeugt hat. Es beweist jedoch nicht automatisch, dass sämtliche Informationen des Ursprungsdokuments vollständig und verlustfrei erhalten wurden. Umgekehrt kann eine informationsreiche XML- oder EXHTML-Ausgabe komplexer und technisch anspruchsvoller sein, obwohl sie für eine einfache RAG-Pipeline nicht unmittelbar benötigt wird.