From PDF to RAG-Ready: Evaluating Document Conversion Frameworks for Domain-Specific Question Answering

Diese Studie zeigt, dass bei der Entwicklung von RAG-Systemen die Qualität der Datenaufbereitung, insbesondere durch hierarchisches Chunking und Metadatenanreicherung, einen größeren Einfluss auf die Antwortgenauigkeit hat als die Wahl des PDF-Konvertierungsframeworks selbst.

Das Wesentliche

📚 Vom staubigen Aktenkoffer zum klugen Assistenten: Was diese Studie über KI und Dokumente sagt

Stellen Sie sich vor, Sie möchten einen extrem klugen, aber etwas vergesslichen Assistenten (eine KI) einstellen, der Ihnen Fragen zu alten, staubigen Akten aus dem Keller beantworten soll. Diese Akten sind als PDFs gespeichert – also wie eingewickelte Bilder von Papier, die man nicht einfach durchsuchen kann.

Die Forscher haben untersucht: Wie gut muss man diese Akten vorbereiten, damit der Assistent wirklich gute Antworten gibt?

1. Das Problem: Der "Müll-in, Müll-out"-Effekt

Viele Leute denken, das Geheimnis einer guten KI liegt darin, den besten Assistenten zu kaufen (das Modell) oder die beste Suchmaschine zu bauen.
Aber diese Studie sagt: Nein! Das Wichtigste ist, was Sie dem Assistenten geben.

• Die Analogie: Stellen Sie sich vor, Sie geben einem Koch (der KI) Zutaten. Wenn Sie ihm verrottetes Gemüse und Schmutz geben (schlecht vorbereitete PDFs), wird er auch mit dem besten Kochbuch der Welt keinen leckeren Salat daraus machen. Wenn Sie ihm frische, gewaschene und geschnittene Zutaten geben (gut vorbereitete Daten), wird das Essen fantastisch schmecken.
• Das Ergebnis: Die Art und Weise, wie die PDFs in Text umgewandelt werden, ist viel wichtiger als die KI selbst. Ein schlechter Umwandlungsprozess kann die KI um fast 23 % schlechter machen!

2. Die vier "Kochhelfer" (Die Werkzeuge)

Die Forscher haben vier verschiedene Werkzeuge getestet, die PDFs in lesbaren Text verwandeln (wie einen Übersetzer, der aus einem Bild Text macht):

1. Docling: Ein sehr ordentlicher, strukturierter Helfer.
2. MinerU: Ein starker Helfer, der aber manchmal die Reihenfolge durcheinanderbringt.
3. DeepSeek OCR: Ein sehr genauer Helfer für Text, aber er vergisst oft, wo die Abschnitte beginnen und enden.
4. PDFLoader (Der "Faule"): Ein einfaches Werkzeug, das einfach nur den Text rauszieht, ohne sich um Struktur oder Tabellen zu kümmern.

Das Überraschende: Der "faule" Helfer (PDFLoader) war gar nicht so schlecht (86,9 % Erfolg). Aber der Docling-Helfer, der sich besonders um die Struktur kümmerte, war mit 94,1 % der Gewinner. Er lag nur knapp hinter einem menschlichen Experten, der die Akten von Hand perfekt sortiert hatte (97,1 %).

3. Die drei Geheimtipps für den Erfolg

Was hat den Docling-Helfer so erfolgreich gemacht? Nicht nur das Werkzeug, sondern drei Dinge, die man damit macht:

• Der "Brotkrumen-Pfad" (Metadaten):
  • Vergleich: Wenn Sie in einem riesigen Wald sind und jemand fragt: "Wo ist der Baum?", ist es besser zu sagen: "Der Baum steht im Wald, im Bereich 'Norden', auf dem Weg 'Hauptallee'."
  • Die Studie zeigte: Wenn man dem KI-Assistenten sagt, in welchem Kapitel und Abschnitt ein Text steht (durch "Brotkrumen"), findet er die Antwort viel besser. Das war sogar wichtiger als das Werkzeug selbst!
• Die richtige Zerteilung (Chunking):
  • Vergleich: Wenn Sie ein Buch in zufällige Buchstaben-Schnipsel schneiden, kann man den Sinn nicht mehr verstehen. Wenn man es aber in sinnvolle Sätze und Absätze schneidet, versteht man es sofort.
  • Die besten Ergebnisse kamen, wenn die Texte so geschnitten wurden, dass sie die natürliche Struktur des Dokuments (Überschriften, Abschnitte) bewahrten.
• Die Bilder-Beschreibung:
  • Die PDFs hatten viele Bilder und Diagramme. Der beste Helfer hat diese Bilder nicht ignoriert, sondern sie mit Text beschrieben ("Hier ist ein Diagramm über die Personalstärke"). Das half der KI enorm.

4. Der große Flop: Der "Wissens-Graph" (GraphRAG)

Es gab eine Idee, die sehr modern klingt: Statt nur Text zu suchen, baut man eine riesige Landkarte (einen Graphen) aus allen Zusammenhängen in den Dokumenten. Man nennt das GraphRAG.

• Die Erwartung: "Das wird super sein! Die KI versteht dann alle Zusammenhänge wie ein Mensch."
• Die Realität: Es funktionierte schlecht (nur 82 %).
• Warum? Man hat versucht, die Landkarte mit einem Automaten zu bauen, ohne vorher genau zu wissen, was wichtig ist (wie ein Architekt, der ohne Plan ein Haus baut). Die Landkarte war voller Fehler und verwirrte den Assistenten mehr, als dass sie half.
• Die Lehre: Ein gut vorbereiteter, einfacher Text ist oft besser als eine komplizierte, schlecht gebaute Landkarte.

5. Ein spezielles Problem: Die deutschen Buchstaben (und portugiesische "Ç")

Da die Dokumente auf Portugiesisch waren, gab es ein kleines, aber tückisches Problem: Das Zeichen "ç" (C mit Häkchen).

• Manche Werkzeuge haben aus "Caça" (Wild) plötzlich "Caca" (Kot) gemacht.
• Das ist wie wenn Sie in einer deutschen Küche "Müller" (der Bäcker) plötzlich in "Müller" (der Müll) verwandeln würden. Die KI sucht dann nach Müll und findet keine Antwort.
• Das beste Werkzeug (Docling) hat diese Buchstaben korrekt behalten, die anderen nicht.

🏁 Das Fazit für den Alltag

Wenn Sie eine KI bauen wollen, die Ihre Dokumente verstehen soll:

1. Hören Sie auf, nur über die KI nachzudenken. (Welches Modell? Welche Suchmaschine?)
2. Fangen Sie bei den Daten an. (Wie reinige ich die PDFs? Wie strukturiere ich sie?)
3. Investieren Sie in die Vorbereitung. Ein guter "Koch" (Werkzeug wie Docling) mit frischen Zutaten (saubere Daten) und einer guten Anleitung (Struktur/Metadaten) ist besser als ein Genie-Koch mit verdorbenen Zutaten.

Kurz gesagt: Der Müll im Computer kommt vom Müll in den Akten, nicht vom Computer selbst.

Technische Zusammenfassung

1. Problemstellung

Retrieval-Augmented Generation (RAG) Systeme sind derzeit der dominante Ansatz, um Large Language Models (LLMs) mit domänenspezifischem Wissen zu versorgen und Halluzinationen zu reduzieren. Ein kritischer, jedoch oft unterschätzter Engpass in der RAG-Pipeline ist die Vorverarbeitung von PDF-Dokumenten.

PDFs sind für den visuellen Druck und nicht für die maschinelle Textverarbeitung konzipiert. Die Extraktion von strukturiertem, semantisch sinnvollem Text (inkl. Tabellen, Hierarchien, Formeln und Bildern) ist fehleranfällig. Fehler in diesem Schritt (z. B. falsche Zeichenerkennung bei Umlauten wie „ç" im Portugiesischen, zerstörte Tabellenstrukturen oder verlorene Dokumentenhierarchie) propagieren sich durch die gesamte Pipeline und verschlechtern die Genauigkeit der nachfolgenden Suche und Generierung drastisch. Bisherige Studien bewerten PDF-Konverter meist nur anhand von Parsing-Metriken (z. B. Edit-Distance), nicht jedoch anhand ihres tatsächlichen Einflusses auf die Fragebeantwortungsqualität (QA-Accuracy) in einem RAG-System.

2. Methodik

Datenkorpus:

• Quelle: 36 öffentlich zugängliche administrative Dokumente des Personalstabs der portugiesischen Armee.
• Umfang: 1.706 Seiten, ca. 492.000 Wörter, 100 % Portugiesisch.
• Herausforderungen: Hoher Anteil an Tabellen (94,4 %), gemischte Layouts, Formulare, Bilder und komplexe Typografie.

Experimentelles Setup:
Die Autoren entwickelten eine modulare Pipeline, inspiriert von der Medallion-Architektur (Bronze/Silver/Gold Layer), die es ermöglicht, verschiedene Konvertierungsframeworks und Transformationen austauschbar zu testen.

• Getestete Frameworks: Docling, MinerU (Pipeline und HTTP-VLM), DeepSeek OCR und als Baseline LangChain's PDFLoader. (Marker wurde aufgrund von Datenschutzbedenken bei der Cloud-Version und schlechteren lokalen Ergebnissen ausgeschlossen).
• Variablen: 19 verschiedene Pipeline-Konfigurationen wurden getestet, variierend in:
  • Konvertierungs-Tool.
  • Transformationen (HTML-Bereinigung, LaTeX-Bereinigung, Hierarchie-Rekonstruktion).
  • Chunking-Strategien (Recursive, Markdown Recursive, Hierarchical Recursive).
  • Metadaten-Anreicherung (Breadcrumb-Kontext).
  • Bildbeschreibungen (via VLM).
• Evaluation: Ein manuell erstellter Benchmark mit 50 Fragen, die spezifische Szenarien abdecken (Tabellen, Hierarchie, Bilder). Die Bewertung erfolgte durch ein „LLM-as-a-Judge"-Verfahren (gpt-4o-mini) über 10 Durchläufe pro Konfiguration.
• Baselines:
  • Untere Grenze: Naiver PDFLoader ohne Vorverarbeitung (86,9 %).
  • Obere Grenze: Manuell korrigierte Markdown-Dokumente (97,1 %).

GraphRAG-Exploration:
Parallel wurde ein GraphRAG-Ansatz getestet, bei dem mittels LLM Entitäten und Beziehungen extrahiert und in Neo4j gespeichert wurden, um die Retrieval-Leistung zu verbessern.

3. Wichtige Beiträge und Erkenntnisse

A. Datenqualität dominiert die Leistung
Der wichtigste Befund ist, dass die Qualität der Datenvorbereitung den größten Einfluss auf die RAG-Genauigkeit hat.

• Die Lücke zwischen der schlechtesten automatisierten Konfiguration (DeepSeek OCR: 71,2 %) und der besten (Docling: 94,1 %) beträgt fast 23 Prozentpunkte.
• Selbst die naive PDFLoader-Baseline (86,9 %) wurde von schlecht konfigurierten Frameworks (z. B. MinerU ohne Bereinigung: 74,7 %) unterboten.

B. Chunking und Metadaten sind wichtiger als das Konvertierungs-Tool
Die Wahl des Konvertierungsframeworks war weniger entscheidend als die Art der Textaufteilung (Splitting) und die Metadaten:

• Hierarchisches Splitting: Die Strategie „Hierarchical Recursive" (die den Dokumentenbaum respektiert und Pfad-Kontexte zu jedem Chunk hinzufügt) erzielte signifikant bessere Ergebnisse als einfaches rekursives Splitting.
• Metadaten: Das Hinzufügen von Breadcrumb-Metadaten (Strukturinformationen) erhöhte die Genauigkeit um ca. 3,8 Punkte.
• Fazit: Ein gut strukturierter Text mit Kontext ist wertvoller als ein perfekter Text ohne Struktur.

C. Font-basierte vs. LLM-basierte Hierarchie-Rekonstruktion
Überraschenderweise schnitt die font-basierte Rekonstruktion (Analyse der Schriftgrößen im PDF) bei den formalen Verwaltungsdokumenten konsistent besser ab als die LLM-basierte Rekonstruktion. Die LLMs führten hier häufiger zu Fehlern bei der Zuordnung von Überschriften, während die deterministische Font-Analyse robuster war.

D. GraphRAG unterlag dem einfachen RAG
Der explorative GraphRAG-Ansatz erzielte nur 82 % Genauigkeit, deutlich schlechter als das optimierte einfache RAG (94,1 %).

• Ursachen: Der Graph war zu flach und dünn besetzt; die automatische Entitätenextraktion ohne domänenspezifische Ontologie erzeugte Rauschen; die semantische Deduplizierung (85 % Ähnlichkeit) führte zu Fehlern, indem unterschiedliche Konzepte fälschlich zusammengeführt wurden.
• Implikation: Ein einfaches, gut vorbereitetes RAG-System ist derzeit effektiver als ein komplexer GraphRAG-Ansatz ohne sorgfältiges Ontologie-Design.

E. Herausforderungen bei nicht-englischen Sprachen
Das Papier hebt spezifische Probleme bei der Verarbeitung von Portugiesisch hervor, insbesondere die falsche Erkennung von Sonderzeichen (z. B. „ç" wird zu „c" oder „ç" zu „caca"), was die semantische Suche zerstört. Docling schnitt hier aufgrund seiner OCR-Komponenten (EasyOCR) am besten ab.

4. Ergebnisse im Detail

Konfiguration	Genauigkeit (%)	Anmerkung
Manuelle Markdowns (Upper Baseline)	97,1	Optimaler Referenzwert
Docling + Hier. Splitting + Bild-Desk.	94,1	Beste automatisierte Lösung
PDFLoader (Lower Baseline)	86,9	Naiver Ansatz
MinerU (ohne Bereinigung)	74,7	Schlechter als naiver Loader
DeepSeek OCR	71,2	Schlechteste Konfiguration
GraphRAG (ohne Ontologie)	82,0	Unterperformt einfaches RAG

5. Bedeutung und Fazit

Die Studie liefert einen klaren Leitfaden für Praktiker, die RAG-Systeme für komplexe Dokumentensammlungen (insbesondere rechtliche oder administrative PDFs) entwickeln:

1. Investition in die Vorverarbeitung: Bevor man Retrieval-Algorithmen oder LLMs optimiert, muss die Datenaufbereitung (PDF zu strukturiertem Markdown) priorisiert werden.
2. Struktur ist entscheidend: Die Wiedergewinnung der Dokumentenhierarchie und das Chunking basierend auf dieser Struktur sind kritischer als die reine Textextraktionsgenauigkeit.
3. Vorsicht bei GraphRAG: Der bloße Aufbau eines Wissensgraphen ohne domänenspezifische Ontologie und sorgfältige Graph-Dichtungsstrategien lohnt sich aktuell nicht und kann die Leistung sogar verschlechtern.
4. Sprachspezifität: Bei nicht-englischen Dokumenten müssen Konverter ausgewählt werden, die für die spezifischen Zeichensätze (Diacritics) trainiert sind.

Die Autoren betonen, dass „Garbage In, Garbage Out" auch für LLMs gilt: Die Qualität der Eingabedaten bestimmt maßgeblich die Qualität der Ausgabe, unabhängig von der Leistungsfähigkeit des zugrunde liegenden Modells.