Docling im Test: Was IBMs Dokument-zu-Markdown-Konverter mit Ihren PDFs tatsächlich macht

Docling wird immer wieder in dieselbe Ecke wie ein Web Scraper gestellt, ist aber keiner. Es ist ein Dokumentenkonvertierungs-Toolkit von IBM Research — inzwischen ein Projekt der LF AI & Data Foundation — das Dateien, die Sie schon besitzen (PDF, DOCX, PPTX, XLSX, HTML, Bilder), in Markdown oder JSON umwandelt. Der eigene Slogan sagt sinngemäß: „Machen Sie Ihre Dokumente fit für generative KI.“

Hier geht es also um einen praxisnahen Test eines Konverters, nicht eines Crawlers. Alles unten wurde auf einem CPU-only-Rechner gemessen (macOS arm64, Python 3.14.2, Docling 2.111.0), per Skripte ausgewertet, und Fehler wurden auch als Fehler erfasst. Das Repository ist riesig und entwickelt sich täglich weiter — 63.069 Sterne, 4.449 Forks und ein Commit am selben Tag, an dem ich die Metadaten gezogen habe — deshalb sollten Sie jede Versions- oder Fehlerzahl hier als Momentaufnahme sehen, nicht als feste Größe.

Was Docling eigentlich ist — und was nicht

Die zentrale Einheit in Docling ist das DoclingDocument: Zuerst wird eine Datei in diese Struktur geparst, danach kann sie als Markdown, HTML, DocTags oder verlustfreies JSON exportiert werden. Der Code steht unter MIT-Lizenz (einzelne Modelllizenzen können abweichen), stammt ursprünglich aus dem IBM Research Zurich, und zum Zeitpunkt dieses Textes ist die neueste Version v2.112.0, veröffentlicht zwei Tage vor meinem Test.

Die wichtigste Stärke ist der PDF- und Bildpfad. Der basiert nicht auf simplen String-Operationen, sondern auf einem ganzen Stack an ML-Modellen: einem RT-DETR-Layoutmodell, dem TableFormer-Modell für Tabellenstrukturen, einem optionalen Vision-Language-Modell und RapidOCR für Scans. Diese Modelle rekonstruieren Seitenlayout, Lesereihenfolge und Tabellenstruktur. Genau das lohnt sich zu prüfen — und genau das würde ein reiner HTML-Test nie abdecken.

Eine Unterscheidung spart Ihnen eine Woche Verwirrung: Docling holt nichts aus dem Netz. Es rendert kein JavaScript, umgeht keine Anti-Bot-Sperren und crawlt nicht. Sie bringen die Datei mit, Docling versteht sie. Crawling ist die Aufgabe eines anderen Tools — und das wird später wichtig, wenn die Frage auftaucht, ob Docling Firecrawl ersetzt (tut es nicht; die Tools ergänzen sich, und ich erkläre gleich warum).

Der erste Lauf, vor dem niemand Sie warnt

pip install docling läuft unter Python 3.14.2 sauber durch. Danach schaut man ins virtuelle Environment — und merkt: Es ist 1,3 GB groß. Docling zieht den gesamten ML-Stack als harte Abhängigkeit mit, selbst wenn man am Ende nur HTML umwandeln möchte:

Abhängigkeit	Größe auf der Festplatte (MiB, du)
torch (2.13.0)	536
opencv (cv2)	119
transformers (5.8.1)	101
scipy	99
sympy	76
pandas	72
rapidocr (+ gebündelte Modelle)	75,6
docling_parse	30

Und das ist noch bevor Sie überhaupt ein PDF konvertieren. Beim ersten PDF kommt der eigentliche Reibungsverlust, weil dann die Modelle heruntergeladen werden. Mit einem frischen, isolierten HuggingFace-Cache dauerte die erste PDF-Konvertierung rund 224 Sekunden — und fast die ganze Zeit ging für den Download drauf, nicht für die Berechnung. Layout- und TableFormer-Modelle belegen zusammen etwa 506 MiB auf der Festplatte (342 MiB TableFormer + 164 MiB Layout, per du geprüft), und RapidOCR lädt zusätzlich ungefähr 40 MB PP-OCRv4-Gewichte nach site-packages. Die zweite Konvertierung derselben Datei? 0,55 Sekunden. Die Modelle sind dann im Cache; die Gebühr zahlen Sie nur einmal.

Eine Zahl sollten Sie ignorieren: Das Coldstart-Skript meldet model_download_mb mit 1060,2. Zitieren Sie das nicht als echten Footprint. Der Wert stammt aus einem os.walk, das Symlinks verfolgt, und der HuggingFace-Cache speichert jede Modell-Datei nur einmal unter blobs/ und stellt sie dann unter snapshots/ erneut per Symlink bereit — dadurch werden die 14 Modelldateien doppelt gezählt. Der mit du übereinstimmende, von Symlinks bereinigte Wert liegt bei rund 506 MiB (nur blobs: 505,4 MiB). Die Lehre für alle, die Docling benchmarken: Download-Bytes und belegter Speicher sind zwei verschiedene Kennzahlen — und sollten auch so ausgewiesen werden.

Es gibt noch einen zweiten Haken beim Bau eines Docling-Containers: Die Gewichte liegen auf zwei Wegen und nach zwei Zeitplänen vor. Die Layout- und TableFormer-Modelle respektieren HF_HOME und laden erst bei der ersten PDF-Konvertierung. Die Modelle von RapidOCR tun das nicht — sie landen direkt in …/site-packages/rapidocr/models/ und umgehen Ihre Cache-Konfiguration komplett. Wenn Sie ein Image vorab befüllen oder luftdicht abschotten wollen, müssen Sie beide Caches berücksichtigen; kein HF_HOME der Welt erfasst den zweiten Pfad.

Fairerweise gibt es auch eine Entlastung: Seit früheren Releases liefert das Projekt docling-slim aus — ein Kernpaket von etwa 50 MB, mit dem Sie pip install docling-slim[format-html] für HTML nutzen können, ohne torch mitzuschleppen. Die 1,3 GB für das Standard-docling-Metapaket sind also real, aber inzwischen optional. Ich habe das Standardpaket getestet, weil genau das weiterhin bei pip install docling installiert wird. Die Schwere ist aber kein ungelöstes Problem — die modulare Lösung existiert bereits und wird in Issue #2393 verfolgt.

Beim Setup fiel mir noch ein kleiner, aber erwähnenswerter Makel auf: import docling; docling.__version__ wirft AttributeError: module 'docling' has no attribute '__version__'. Das Modul stellt diesen Wert schlicht nicht bereit. Der funktionierende Weg ist importlib.metadata.version("docling"), was '2.111.0' zurückgibt. Das ist ein kleiner DX-Ärger, seit Juli 2026 als Issue #3733 offen.

Tabellenqualität: Hier zahlt sich TableFormer aus

Tabellen sind der Grund, warum man zu Docling greift statt zu einem simplen PDF-zu-Text-Dump. Deshalb habe ich sieben Tabellen-PDFs mit maschinenlesbarem Ground Truth erzeugt und die Ausgabe Zelle für Zelle bewertet. Zwei Metriken sind wichtig — und sie sind nicht dasselbe: Cell Recall ist der Anteil der Ground-Truth-Werte, die irgendwo in der erkannten Tabelle auftauchen; In-Row-Rate ist der Anteil, der in der richtigen Zeile landet. Wer beides vermischt, macht das Tool besser als es ist. Deshalb hier beides:

Tabelle (Stresstest)	Erkannt	Cell Recall	In-Row-Rate	Hinweis
T1 einfache Tabelle mit Rahmen (5×8), allein auf der Seite	Nein	0,0	—	als <!-- image --> klassifiziert, alle Zellen verworfen
T2 rahmenlos (nur eine Kopfzeile mit Linie)	Ja	1,00	1,00	perfekt, exaktes Raster
T3 zweistufiger Header mit gemergtem colspan	Ja	1,00	0,97	alle Werte vorhanden; ein Header-Wert rutscht um eine Zeile
T4 gemergte rowspan-Zeilenbeschriftung, allein auf der Seite	Nein	0,0	—	als <!-- image --> klassifiziert
T5 colspan-Header + rahmenlos	Ja	1,00	0,97	alle Werte gefunden; derselbe Zeilenversatz wie bei T3
T6 Finanzdaten, leere Spalte, rechtsbündig	Ja	1,00	1,00	leere Spalte bleibt erhalten, wird nicht verschoben
T7 breites Raster mit 12 Spalten	Ja	1,00	1,00	keine Spaltenverschiebung bei breiter Tabelle

Bei den fünf Tabellen, die Docling erkannt hat, kam jeder Ground-Truth-Wert durch — Cell Recall überall 1,00. Bei drei dieser fünf landete jeder Wert außerdem in der richtigen Zeile. In den beiden Fällen mit mehrstufigen Headern (T3 und T5) rutschte ein Header-Wert um eine Zeile nach unten, wodurch die In-Row-Rate auf 0,97 sank — die Daten sind also vollständig da, nur die Zeilenzuordnung wackelt bei gestapelten Kopfzeilen leicht.

Die schwierigen Strukturfälle hielten besser stand, als ich erwartet hatte. Der zweistufige colspan-Header wurde korrekt in GitHub-Flavored Markdown abgeflacht (das Label „Q1 2026“ wiederholte sich über die beiden überspannten Spalten — genau so sollte man einen colspan in GFM reduzieren). Das rahmenlose Gitter mit nur einer Kopfzeilenlinie (T2) kam exakt durch. Die breite 12-Spalten-Tabelle (T7) verschob keine Spalten. Und eine komplett leere Finanzspalte (T6) blieb als leere Zellen erhalten, statt gelöscht oder zusammengezogen zu werden. Das passt zu den offiziellen TableFormer-TEDS-Werten — 95,4 einfach, 90,1 komplex, 93,6 alle Tabellen — mit denen das Modell deutlich über Camelot (73,0) und EDD (88,3) liegt.

Ein Wort der Vorsicht zu zusammengeführten Zellen, denn dazu gibt es ein offenes Issue, das genau das Gegenteil behauptet. Issue #3698 meldet, dass V1 und V2 zusammengeführte Zeilen und Spalten fehlerhaft behandeln. In meinen Testfällen wurden einfache colspan-Werte (T3/T5) und rowspan-Werte korrekt abgeflacht, abgesehen von dem oben genannten Zeilenversatz bei mehrstufigen Headern. Die fehlerhaften Fälle aus #3698 betreffen jedoch unregelmäßige Mehrfach-Zeilen-/Mehrfach-Spalten-Merges und mehrseitige Tabellen — also den pathologischen Extremfall. Meine Tests liegen am einfachen Ende des Spektrums. Die präzise Aussage lautet daher: Einfache colspan- und rowspan-Werte wurden hier sauber rekonstruiert (mehrstufige Header können eine Zeile verrutschen); komplexe und unregelmäßige Merges bleiben ein dokumentiertes offenes Problem. Nicht: „Zusammengeführte Zellen funktionieren“, aber auch nicht: „Zusammengeführte Zellen sind kaputt.“

Die Falle: Eine Tabelle allein auf der Seite kann verschwinden

Schauen Sie noch einmal auf die Tabelle: T1 und T4 wurden überhaupt nicht erkannt. Docling gab <!-- image --> aus und verwarf alle Zellen — ohne Fehlermeldung. T1 ist eine völlig normale gerahmte 5×8-Tabelle. Das ist alarmierend genug, dass ich es nicht einfach als reine Schwäche der Tabellenanalyse abtun wollte, bevor ich herausgefunden hatte, was den Effekt wirklich auslöst. Also baute ich einen skriptgesteuerten A/B-Test.

Zuerst schloss ich die naheliegenden Erklärungen aus. Die Textschicht ist intakt — pypdfium2 liest 327 Zeichen aus T1 und 221 aus T4, also sind das echte digitale PDFs und keine gescannten Bilder. OCR auszuschalten (do_ocr=False) hilft nicht; die Tabellen verschwinden trotzdem. Und wenn man das DoclingDocument direkt anschaut, gilt len(doc.tables) == 0, während len(doc.pictures) == 1 ist — das Layoutmodell hat den ganzen Tabellenbereich als Picture klassifiziert.

Dann kam der entscheidende Test: Ich habe T1 und T4 identisch neu gerendert, diesmal aber mit ein paar normalen Fließtext-Absätzen darum herum, und erneut konvertiert. Beide kamen dann fehlerfrei durch: len(doc.tables) == 1, korrekte GFM-Tabellen wurden ausgegeben, und bei T4b wurde die rowspan-Beschriftung „North“ korrekt über drei Zeilen wiederholt. Gleiche Tabelle. Einzige Änderung: Sie stand allein auf einer spärlichen Seite statt eingebettet in Text.

Die eigentliche Einschränkung ist also nicht, dass TableFormer fragil wäre, sondern dass Doclings RT-DETR-Layoutmodell Seitenkontext nutzt und eine kleine Tabelle auf einer sonst fast leeren Seite leicht als Picture gelesen und stillschweigend verworfen wird. Das ist in der Praxis leicht zu treffen, denn genau so sehen Rechnungen, Datenblätter und zugeschnittene Exporte oft aus: eine Tabelle pro Seite, kein Fließtext drumherum. Die Lösung ist unspektakulär, aber wirksam: Geben Sie dem Layoutmodell Seitenkontext oder prüfen Sie nach der Konvertierung doc.tables und markieren Sie Seiten, auf denen der Wert null ist. Das hängt mit Issue #3495 zusammen (eine Tabelle wird gleichzeitig als Table und Picture erkannt), aber den spezifischen Auslöser durch spärliche Seiten — dieselbe Tabelle verschwindet isoliert, konvertiert aber eingebettet — konnte ich nirgends veröffentlicht finden. Gemessen, nicht vorher dokumentiert; kein Bug, den niemand kannte.

OCR bei echten Scans: RapidOCR, nicht EasyOCR

Gescannten PDFs scheitern viele Konverter still und heimlich. Deshalb habe ich Docling zwei echte Scans gegeben, bei denen die Textschicht gemessen 0 Zeichen hatte — pypdfium2 meldet null wiederherstellbare Zeichen, also stammt jede Ausgabe wirklich aus OCR und nicht aus einer versteckten Textschicht.

Die einseitige Datei ocr_test.pdf kam auf CPU in 14,3 Sekunden sauber zurück: „Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package“ wurde wörtlich wiederhergestellt. Die vierseitige Datei nemotron_multipage.pdf führte OCR auf allen vier Seiten aus und brauchte insgesamt 70,1 Sekunden (17,5 s/Seite); pro Seite erschien jeweils der wiederholte Testsatz. OCR lief standardmäßig automatisch an — ohne Flag, ohne Konfiguration.

Ein Detail, das in vielen Artikeln falsch dargestellt wird: Die Standard-OCR-Engine ist RapidOCR, nicht EasyOCR. Ich habe das bestätigt, indem ich beim ersten Lauf das Herunterladen der PP-OCRv4-.pth-Gewichte beobachtet habe. Viele bestehende Blogartikel und ältere Docling-FAQ-Texte behaupten noch, EasyOCR sei der Standard — das ist veraltet. EasyOCR ist inzwischen ein optionales Zusatzpaket. Die Einschränkung bleibt richtig: OCR ist bei großen Mengen der langsame Pfad, und alles hier ist ein CPU-only-Limit — mit GPU würden sich diese Zeiten deutlich verkürzen.

Echte PDFs, Lesereihenfolge und Zeit pro Seite

Synthetische Testfälle beweisen einzelne Verhaltensweisen; echte PDFs beweisen, dass das Ganze wirklich funktioniert. Ich habe zwei born-digitale Fachartikel getestet — den 9-seitigen technischen Bericht zu Docling und „Attention Is All You Need“ mit 15 Seiten, beide zweispaltig mit Tabellen und Formeln.

In dem 15-seitigen Attention-Paper erscheinen alle fünf Abschnittsmarker — Abstract, Introduction, Background, Conclusion, References — in der linearen Markdown-Ausgabe in Dokumentreihenfolge, trotz des zweispaltigen Layouts. Alle inhaltlichen Prüfmarken (Transformer, encoder, BLEU, multi-head) sind vorhanden, und die berühmten mehrspaltigen Ergebnistabellen werden als vier erkannte Tabellen registriert. Das ist echte Wiederherstellung von Lesereihenfolge und Spaltenstruktur — der Kernnutzen für RAG-Chunks, denn ein Dokument lässt sich nicht sinnvoll chunkieren, wenn der Linearizer eine zweispaltige Seite in ein unlesbares Textgemisch verwandelt.

Die Zeitmessung liefert eine kontraintuitive Lehre: Die Zeit pro Seite hängt eher davon ab, wie viel Struktur auf jeder Seite steckt, als von der Seitenzahl. Der dichtere 9-seitige Bericht lief mit 14,95 Sekunden pro Seite langsamer als das 15-seitige Paper mit 5,99 Sekunden pro Seite — weil der Bericht mehr Tabellen und Abbildungen enthält und jede davon zusätzliche Layout- und TableFormer-Inferenz auslöst. „Sekunden pro Seite“ ist auf CPU also eine Funktion der strukturellen Dichte, nicht der Länge. Das ist ein einzelner CPU-only-Lauf; also eine Obergrenze, kein Produktionswert.

Mehrere Formate und die Behauptung vom verlustfreien JSON

Docling bewirbt ein einheitliches Parsing für mehrere Formate. Also habe ich eine DOCX-, eine XLSX- und eine PPTX-Datei mit bekannten Inhalten und Prüfmarken erzeugt und dann zwei Dinge geprüft: Tauchen die Prüfmarken im Markdown auf, und überleben sie den JSON-Rundgang via export_to_dict()?

Datei	Konvertierung s	MD-Prüfmarken gefunden	Tabellen in MD	Prüfmarken überleben JSON
report.docx (Überschriften + gemergte „Total“-Tabelle + Aufzählungen)	0,137	7/7	1	Ja
workbook.xlsx (2 Sheets, leere Spalte)	0,016	6/6	2	Ja
deck.pptx (3 Folien, Aufzählungen + Tabelle)	0,038	6/6	1	Ja

Alle Inhaltsprüfungen tauchten im Markdown auf, Tabellen wurden korrekt rekonstruiert (einschließlich der gemergten „Total“-Zeile in der DOCX und beider XLSX-Sheets), und jede Prüfmarke überlebte auch das JSON aus export_to_dict() — genau das ist die relevante Evidenz für die Behauptung vom verlustfreien DoclingDocument, zumindest bei sauberen Eingaben. Diese Formate laufen über format-native Backends statt über die ML-Modelle, weshalb sie in wenigen Millisekunden laufen und komplett offline funktionieren. Der Anspruch bleibt ehrlich: Eine saubere Datei pro Format zeigt die Breite, aber kein Stresstest mit kaputten Office-Dateien.

HTML: Treu, aber nicht sauber

Das ist die Einschränkung, die entscheidet, ob Docling in Ihre RAG-Pipeline gehört — deshalb genau hinschauen. Docling konvertiert das gesamte HTML-Dokument. Es macht keine Main-Content-Extraktion im Stil von Readability. Ich habe gemessen, wie viel Seitendekor erhalten bleibt, indem ich Navigations-, Inhaltsverzeichnis-, Cookie- und Footer-Marker in Doclings eigener Ausgabe gezählt habe.

Seite	Nicht-leere MD-Zeilen	Boilerplate-Zeilen	% Boilerplate	Artikel beginnt bei Zeile
Wikipedia „Web scraping“	255	34	13,3%	28
scrapethissite/forms	63	1	1,6%	—
books.toscrape	65	0	0,0%	—
quotes.toscrape	35	0	0,0%	—

Auf einer stark mit Seitenelementen beladenen Seite wie Wikipedia stammen rund 13 % der Markdown-Zeilen aus Navigation, Inhaltsverzeichnis oder Footer-Boilerplate, und der eigentliche Artikel beginnt erst in Zeile 28 — die Ausgabe startet mit „move to sidebar / Contents / Toggle the table of contents“ und endet mit „CS1 maint… / Search Wikipedia“. Auf sauberen Inhaltsseiten (books, quotes) liegt der Anteil bei etwa 0 %, also ist das ein Problem des Template-Chromes, nicht eine pauschale Gebühr auf jede Seite. Docling liefert Ihnen also treues Volltext-Markdown des Dokuments, aber keine bereinigte Extraktion des Hauptartikels. Das Projekt verfolgt das HTML-Furniture-Problem in Issue #1865 (geschlossen) und #1930 (offen).

Zwei Punkte machen das fair: Erstens laufen bei HTML in Docling überhaupt keine ML-Modelle — das Ganze basiert auf einem einfachen BeautifulSoup-Backend. Die Geschichte von den „Vision-Modellen, die Ihre Seite lesen“ gilt nur für PDF und Bilder; wenn Sie HTML in Docling geben, greifen weder Layout- noch TableFormer-Modelle. Zweitens versucht der PDF-Pfad durchaus, Kopf- und Fußzeilen als Seitendekor zu klassifizieren — „gar keine Boilerplate-Entfernung“ wäre also zu hart formuliert. Genau das HTML-Backend gibt eben den Seitenchrome zurück.

Wie sich Docling einordnet — und wo Thunderbit passt

Thunderbit für Web-Datenextraktion testen

Das Tool, mit dem Docling am häufigsten verglichen wird, ist Firecrawl — deshalb hier eine Einordnungstabelle. Vorweg ein wichtiger Hinweis: Das ist ein Vergleich auf Dokumentationsniveau, kein Benchmark auf demselben Rechner. Ich habe Firecrawl auf diesen Testfällen nicht ausgeführt. Nur die Docling-Spalte ist hier gemessen; die Firecrawl-Spalte stammt aus der öffentlichen Doku.

Aspekt	Firecrawl (laut Doku)	Docling (hier gemessen)
Kernaufgabe	Live-Web crawlen + scrapen → Markdown	Ein bereits vorhandenes Dokument konvertieren → Markdown/JSON
Abruf / JS-Rendering / Anti-Bot	Ja (gehosteter Browser)	Nein — Sie liefern die Datei
Hauptinhaltsextraktion	Ja	Nein — vollständiges, treues Dokument (~13 % Boilerplate auf Wikipedia)
PDF-Tabellenstruktur (ML)	eingeschränkt	Ja — TableFormer (offiziell TEDS 93,6; Cell Recall 1,00, In-Row 0,97–1,00 auf den erkannten Testfällen)
Gescanntes PDF / OCR	eingeschränkt	Ja — RapidOCR standardmäßig (eine 0-Textschicht-Scan-Datei wurde korrekt gelesen)
Formatbreite	Webseiten	PDF/DOCX/PPTX/XLSX/HTML/EPUB/Bilder
Bereitstellung	gehostete API (+ Self-Host)	lokale pip-Bibliothek, offline, kein API-Key
Installationsgewicht	API-Key / leichter Client	1,3 GB Standardinstallation + ~506 MiB Modelle (oder docling-slim)
Lizenz	kommerziell / Source-Available	MIT

Die Kurzfassung: Firecrawl ist das richtige Werkzeug, wenn Ihre Daten aus dem Live-Web kommen und Crawling, JavaScript-Rendering sowie Bereinigung des Hauptinhalts brauchen. Docling ist das richtige Werkzeug, wenn Sie das Dokument bereits besitzen — vor allem PDFs, Scans und tabellenlastige Office-Dateien — und eine treue, offline arbeitende, strukturerhaltende Konvertierung mit echtem Verständnis für Tabellen und OCR möchten. Die Tools ergänzen sich. Eine realistische Pipeline crawlt mit dem einen und konvertiert Dokumente mit dem anderen.

Und an dieser Stelle bin ich bei Thunderbit ganz offen, weil ich hier arbeite und Sie zu Recht skeptisch wären, wenn ich so tun würde, als wäre das nicht relevant. Thunderbit und Docling machen nicht dasselbe, und ich werde keine künstliche Gleichsetzung behaupten. Für Entwickler ist Thunderbit eine AI-Scraping-API plus MCP-Server plus CLI, und die Arbeitseinheit ist die Live-Webseite: POST /distill wandelt eine URL in sauberes, LLM-taugliches Markdown um (inklusive JavaScript-Rendering, Anti-Bot und CAPTCHA, die Docling ausdrücklich nicht anfasst), und POST /extract liefert schema-konformes strukturiertes JSON auf Basis eines von Ihnen definierten JSON Schemas. Das ist der Fetch-and-Clean-Teil einer RAG-Pipeline. Docling ist der lokale Dokumententeil — das PDF, der Scan, die Tabelle, die schon auf Ihrer Festplatte liegt. Wenn Ihre Daten aus Webseiten bestehen, nehmen Sie Thunderbits API, die MCP-Tools (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) oder die CLI (npx @thunderbit/thunderbit-cli). Wenn es PDFs und Scans sind, nehmen Sie Docling. Wenn beides vorkommt — was in den meisten echten Pipelines so ist — kombinieren Sie beide. Keines versucht, das andere zu ersetzen.

Das Fazit: vorläufig, mit Hausaufgaben

Ich vergebe hier bewusst keine einzelne Punktzahl von 0 bis 100, weil ein gewichteter Gesamtscore Docling für Dinge bestrafen würde, die es nie versprochen hat — etwa Crawling — und so tun würde, als wäre das vergleichbar. Pro Dimension, auf den von mir getesteten Fällen:

• Setup / erster Lauf: schwergewichtig — 1,3 GB venv, ~506 MiB Modelle, ~224 s erster PDF-Lauf, ~0,55 s warm — aber docling-slim nimmt Ihnen die Last ab.
• Tabellenqualität: stark, sobald eine Tabelle erkannt wird (Cell Recall 1,00 bei 5/5, In-Row 0,97–1,00), passend zur offiziellen TEDS-Story auf diesen Testfällen.
• Robustheit der Tabellenerkennung: die spärliche-Seite-Falle — eine isolierte Tabelle kann als Picture verschwinden. Danach doc.tables prüfen.
• Scan / OCR: funktioniert, RapidOCR standardmäßig; bei großen Mengen langsam.
• Mehrere Formate: solide, inklusive intaktem JSON-Roundtrip.
• HTML: treu, aber nicht sauber — keine Main-Content-Extraktion.
• Developer Experience: saubere 3-Zeilen-API und ein ordentliches DoclingDocument, abgesehen vom fehlenden __version__.

Für wen es ist: Teams, die RAG- oder Datenpipelines über PDFs, Scans und Office-Dateien bauen und dafür eine Offline-Konvertierung mit erhaltener Struktur und echtem Tabellen- und OCR-Verständnis brauchen. Für wen es nicht ist: alle, die Live-Web-Crawling oder eine bereinigte Hauptartikel-Extraktion aus HTML brauchen — dafür ist ein anderes Tool zuständig.

Und weil das hier ein Testbericht und keine Pressemitteilung ist, bleiben die Grenzen in der Überschrift stehen. Das ist ein gezielter Probe-Test — 7 synthetische Tabellen plus 2 echte PDFs auf einem CPU-only-Rechner — kein TEDS-Maßstabsbenchmark. Einige Dinge habe ich nicht getestet und Sie sollten sie vor einem echten Einsatz noch prüfen: den optionalen VLM-Pfad (GraniteDocling), die tatsächliche Größe von docling-slim, einen GPU-Lauf, komplexe und unregelmäßige Merges plus mehrseitige Tabellen, die Treue bei Formel-zu-LaTeX, und — am ehesten überraschend im Produktionsbetrieb — die Dauerhaftigkeit in Bezug auf Speicherwachstum im Batch, Skalierung mit Threads/GIL und Objektlebenszyklus über Tausende von Konvertierungen hinweg. Docling ist stark in dem, was es verspricht, gemessen statt nur vermarktet, und hat echte Kanten, die Sie vor einem produktiven Einsatz kennen sollten. Kennen Sie die Falle mit den sparsamen Seiten, kalkulieren Sie den ersten Download ein und prüfen Sie das Verhalten bei großen Volumina selbst.

Thunderbit für Web-Datenextraktion testen Get Started Free

FAQs

Ist Docling ein Web Scraper oder Crawler?
Nein. Docling konvertiert Dokumente, die Sie schon haben — PDF, DOCX, PPTX, XLSX, HTML, Bilder — in Markdown oder JSON. Es ruft keine URLs ab, rendert kein JavaScript und übernimmt keine Anti-Bot-Aufgaben. Das Crawlen des Live-Webs ist eine separate Aufgabe für Tools wie Firecrawl oder Thunderbits Web-API; Docling startet bei der Datei, die Sie ihm geben.

Wie groß ist die Docling-Installation und der erste Download?
Das Standard-docling-Metapaket erzeugt ein etwa 1,3 GB großes virtuelles Environment, weil der komplette ML-Stack als harte Abhängigkeit mitkommt (allein torch braucht 536 MiB). Bei der ersten PDF-Konvertierung werden rund 506 MiB an Layout- und TableFormer-Modellen plus etwa 40 MB RapidOCR-Gewichte auf die Festplatte geladen; das dauert ungefähr 224 Sekunden — fast nur Downloadzeit. Die zweite Konvertierung dauert rund 0,55 Sekunden. Wenn Sie nur leichte Formate brauchen, umgeht docling-slim (~50 MB Kernpaket) den schweren Pfad.

Macht Docling OCR, und mit welcher Engine?
Ja. Bei einem gescannten PDF ohne Textschicht startet OCR automatisch und hat in meinem Test den Text sauber wiederhergestellt. Die Standard-Engine ist RapidOCR, nicht EasyOCR — ein häufiger Fehler in älteren Beschreibungen. EasyOCR ist inzwischen ein optionales Zusatzpaket. OCR ist bei großen Volumina der langsame Pfad, besonders auf CPU.

Warum hat Docling meine Tabelle als Bild behandelt oder sie ausgelassen?
Am wahrscheinlichsten wegen des Sparse-Page-Effekts. Doclings RT-DETR-Layoutmodell nutzt Seitenkontext, und eine kleine Tabelle allein auf einer fast leeren Seite kann als Picture klassifiziert und ohne Fehlermeldung verworfen werden. Dieselbe Tabelle, wenn sie von Fließtext umgeben ist, wird korrekt konvertiert. Die Lösung: dem Layoutmodell mehr Seitenkontext geben oder nach der Konvertierung doc.tables prüfen und jede Seite markieren, auf der die Anzahl null ist.

Docling vs Firecrawl — was sollte ich nutzen?
Das sind verschiedene Aufgaben, also meist kein Entweder-oder. Firecrawl crawlt das Live-Web, rendert JavaScript und extrahiert den Hauptinhalt. Docling konvertiert Dokumente, die Sie schon besitzen, mit echter PDF-Tabellenstruktur und OCR, komplett offline. Wenn Ihre Quelle Webseiten sind, nehmen Sie ein Web-Tool (Firecrawl oder Thunderbits API/MCP/CLI). Wenn es PDFs, Scans oder Office-Dateien sind, nehmen Sie Docling. In den meisten echten Pipelines laufen beide zusammen.