Docling wird oft reflexartig in die gleiche Ecke wie Web Scraper gesteckt, ist es aber nicht. Es ist ein Dokumentenkonvertierungs-Toolkit von IBM Research — inzwischen ein Projekt der LF AI & Data Foundation — das bestehende Dateien (PDF, DOCX, PPTX, XLSX, HTML, Bilder) in Markdown oder JSON umwandelt. Der eigene Slogan bringt es sinngemäß auf den Punkt: „Machen Sie Ihre Dokumente fit für GenAI.“
Hier geht es also um einen Praxistest 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 Skript ausgewertet und Fehler wurden auch als Fehler mitgezählt. Das Repository ist riesig und entwickelt sich ständig weiter — 63.069 Sterne, 4.449 Forks und ein Commit am selben Tag, an dem ich die Metadaten gezogen habe — also verstehen Sie jede Versions- oder Fehlerzahl hier als Momentaufnahme, nicht als fixe Größe.
Was Docling wirklich ist – und was nicht
Die kleinste Einheit in Docling ist das DoclingDocument: Datei einlesen, in diese Struktur überführen und anschließend als Markdown, HTML, DocTags oder verlustfreies JSON exportieren. Der Code steht unter MIT-Lizenz (einzelne Modelllizenzen können abweichen), entstand bei IBM Research Zürich und die aktuelle Version zum Zeitpunkt dieses Tests ist v2.112.0, veröffentlicht zwei Tage bevor ich hier angefangen habe.
Die wichtigste Stärke liegt im PDF- und Bildpfad. Dort geht es nicht um simples String-Parsen, sondern um einen Stapel Machine-Learning-Modelle: ein RT-DETR-Layoutmodell, das TableFormer-Modell für Tabellenstrukturen, optional ein 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 zeigen.
Eine saubere Abgrenzung spart eine Woche Verwirrung. Docling lädt nichts aus dem Web. Es rendert kein JavaScript, überwindet keine Anti-Bot-Schranken und crawlt auch nicht. Sie bringen die Datei mit; Docling erledigt das Verstehen. Das Crawling ist die Aufgabe eines anderen Tools — und das ist später relevant, wenn die Frage aufkommt, ob Docling Firecrawl ersetzt (tut es nicht; die beiden ergänzen sich, und gleich wird klar warum).
Der erste Lauf, vor dem einen niemand warnt
pip install docling läuft unter Python 3.14.2 sauber durch. Dann schaut man ins virtuelle Environment — und stellt fest: 1,3 GB. Docling zieht den kompletten ML-Stack als harte Abhängigkeit mit, selbst wenn man am Ende nur eine HTML-Datei konvertiert:
| 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) | 72.1 |
| docling_parse | 30 |
Und das ist noch bevor überhaupt ein PDF konvertiert wurde. Die erste PDF-Konvertierung ist der Moment, in dem der eigentliche Frust beginnt, weil dann die Modelle heruntergeladen werden. In einem frischen, isolierten HuggingFace-Cache dauerte die erste PDF-Konvertierung rund 224 Sekunden — und fast die gesamte Zeit entfällt auf den Download, nicht auf die Rechenarbeit. Das Layout- und TableFormer-Paket landen zusammen bei ca. 506 MiB auf der Platte (342 MiB TableFormer + 164 MiB Layout, per du bestätigt), und RapidOCR lädt etwa 40 MB PP-OCRv4-Gewichte nach site-packages. Die zweite Konvertierung derselben Datei? 0,55 Sekunden. Die Modelle sind dann im Cache; die Einmalkosten sind bezahlt.
Eine Zahl sollten Sie ignorieren: Das Coldstart-Skript gibt model_download_mb mit 1060,2 aus. Das ist nicht der echte Footprint. Die Zahl stammt aus einem os.walk, der Symlinks verfolgt, und der HuggingFace-Cache speichert jede Modelldatei nur einmal unter blobs/ und stellt sie dann über snapshots/ erneut per Symlink bereit — dadurch zählt der Walk die 14 Modelldateien doppelt. Die du-entsprechende, Symlink-deduplizierte Größe liegt bei ca. 506 MiB (nur blobs: 505,4 MiB). Für Benchmarks von Docling gilt deshalb: Download-Bytes und belegter Speicher müssen getrennt ausgewiesen werden.
Es gibt noch einen zweiten Haken, der beim Container-Bau von Docling zuschlägt. Die Gewichte verteilen sich nach zwei Zeitplänen auf zwei Speicherorte. Layout- und TableFormer-Modelle respektieren HF_HOME und werden beim ersten PDF-Lauf geladen. Die Modelle von RapidOCR tun das nicht — sie landen direkt unter …/site-packages/rapidocr/models/ und umgehen Ihre Cache-Konfiguration komplett. Wenn Sie ein Image vorab befüllen oder offline betreiben wollen, müssen Sie beide Speicherorte berücksichtigen; HF_HOME allein reicht nicht.
Fairerweise: Seit älteren Docling-Versionen gibt es docling-slim — einen Kern von etwa 50 MB, mit dem sich pip install docling-slim[format-html] für HTML nutzen lässt, ohne torch mitzuziehen. Die 1,3-GB-Zahl ist also für das Standard-Metapaket docling real, aber inzwischen optional vermeidbar. Ich habe das Standardpaket getestet, weil genau das weiterhin bei pip install docling installiert wird. Die Schwere ist aber kein unbehandelter Designfehler mehr — die modulare Lösung existiert und wird in Issue #2393 verfolgt.
Beim Setup fiel mir noch ein kleiner, aber erwähnenswerter Schönheitsfehler auf: import docling; docling.__version__ wirft AttributeError: module 'docling' has no attribute '__version__'. Das Modul stellt die Version schlicht nicht bereit. Der funktionierende Weg ist importlib.metadata.version("docling"), was '2.111.0' zurückgibt. Kein Drama, aber ärgerlich für die Developer Experience; seit Juli 2026 als Issue #3733 offen.
Tabellenqualität: Hier spielt TableFormer seine Stärken aus
Tabellen sind der Grund, warum man überhaupt Docling statt eines simplen PDF-zu-Text-Dumps verwendet. Deshalb habe ich sieben Tabellen-PDFs mit maschinenlesbarem Ground Truth erzeugt und die Ausgabe zellgenau bewertet. Zwei Kennzahlen 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 diese beiden Werte vermischt, schmeichelt dem Tool unnötig — hier sind deshalb beide:
| Tabelle (Stresstest) | Erkannt | Cell Recall | In-Row Rate | Hinweis |
|---|---|---|---|---|
| T1 einfache Tabelle mit Rahmen (8 Zeilen × 5 Spalten), allein auf der Seite | Nein | 0.0 | — | als <!-- image --> klassifiziert, alle Zellen verloren |
| T2 rahmenlos (nur eine Kopfzeile mit Linie) | Ja | 1.00 | 1.00 | perfekt, exaktes Raster |
| T3 verschachtelter 2-stufiger colspan-Kopf | Ja | 1.00 | 0.97 | alle Werte gefunden; ein Kopfwert rutscht eine Zeile |
| T4 gemergter rowspan-Zeilenbezeichner, allein auf der Seite | Nein | 0.0 | — | als <!-- image --> klassifiziert |
| T5 colspan-Kopf + rahmenlos | Ja | 1.00 | 0.97 | alle Werte gefunden; derselbe Zeilenversatz wie bei T3 |
| T6 Finanztabelle, leere Spalte, rechtsbündig | Ja | 1.00 | 1.00 | leere Spalte bleibt erhalten, wird nicht verschoben |
| T7 breite Tabelle 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 1.00 überall. Bei drei dieser fünf landete außerdem jeder Wert in der richtigen Zeile. Bei den beiden Fällen mit mehrstufigem Kopf (T3 und T5) verrutscht ein Kopfwert um eine Zeile, wodurch die In-Row Rate auf 0,97 fällt — die Daten sind da, nur die Zeilenzuordnung wackelt bei einem gestaffelten Header leicht.
Die schwierigen Strukturfälle hielten sich besser als erwartet. Der zweistufige colspan-Kopf wurde sauber in GitHub-Flavored Markdown aufgelöst (die Beschriftung „Q1 2026“ wurde über beide aufgespannten Spalten wiederholt — genau die richtige Art, einen colspan in GFM zu flatten). Die rahmenlose Tabelle mit nur einer Kopfregel (T2) kam exakt durch. Die breite 12-Spalten-Tabelle (T7) verschob keine Spalte. Und eine komplett leere Finanzspalte (T6) blieb als leere Zelle erhalten, statt zu verschwinden oder zusammenzufallen. Das passt auch zu den offiziellen TableFormer-TEDS-Werten — 95,4 für einfache, 90,1 für komplexe, 93,6 insgesamt — und liegt laut Model Card klar über Camelot (73,0) und EDD (88,3).
Eine Warnung zu gemergten Zellen ist wichtig, denn es gibt ein offenes Issue, das das Gegenteil behauptet. Issue #3698 meldet, dass V1 und V2 gemergte Zeilen und Spalten falsch behandeln. In meinen Testdateien wurden einfache colspan-Fälle (T3/T5) und rowspan-Werte korrekt abgeflacht, abgesehen vom oben genannten Zeilenversatz bei mehrstufigen Headers. Die fehlgeschlagenen Fälle in #3698 sind jedoch unregelmäßige Mehrzeilen-/Mehrspalten-Merges und tabellenübergreifende Seiten — also das pathologische Ende des Spektrums. Meine Beispiele liegen am einfachen Ende. Deshalb lautet die präzise Aussage: Einfache colspan- und rowspan-Fälle wurden hier korrekt wiederhergestellt (mehrstufige Header können um eine Zeile verrutschen); komplexe und unregelmäßige Merges bleiben ein dokumentiertes offenes Problem. Nicht „gemergte Zellen funktionieren immer“, aber auch nicht „gemergte Zellen sind kaputt“.
Die Falle: Eine alleinstehende Tabelle kann verschwinden
Schauen Sie noch einmal auf die Tabelle: T1 und T4 wurden überhaupt nicht erkannt. Docling gab <!-- image --> aus und verlor alle Zellen, ohne Fehlermeldung. T1 ist eine völlig normale Tabelle mit Rahmen, 8 Zeilen und 5 Spalten. Das ist so auffällig, dass ich es nicht als allgemeine Schwäche des Tabellenparsings bezeichnen wollte, bevor ich genau isoliert hatte, was den Fehler auslöst. Also habe ich einen Skript-basierten A/B-Test gebaut.
Zuerst habe ich die naheliegenden Erklärungen ausgeschlossen. Die Textebene 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 untersucht, gilt len(doc.tables) == 0, während len(doc.pictures) == 1 ist — das Layoutmodell hat den gesamten Tabellenbereich als Picture klassifiziert.
Dann der entscheidende Test: Ich habe dieselben T1- und T4-Tabellen noch einmal gerendert, diesmal mit ein paar normalen Fließtext-Absätzen drumherum, und erneut konvertiert. Beide kamen nun perfekt durch: len(doc.tables) == 1, korrekte GFM-Tabellen wurden ausgegeben, und bei T4b wurde das rowspan-Label „North“ korrekt über drei Zeilen wiederholt. Gleiche Tabelle. Einzige Änderung: Sie stand nicht mehr allein auf einer spärlichen Seite, sondern war in Text eingebettet.
Die eigentliche Einschränkung ist also nicht, dass TableFormer empfindlich wäre — sondern dass das RT-DETR-Layoutmodell von Docling Seitenkontext nutzt und eine kleine Tabelle auf einer sonst fast leeren Seite leicht als Picture lesen und stillschweigend verwerfen kann. Das ist in der Praxis schnell erreicht, weil Rechnungen, Datenblätter und ausgeschnittene Exporte oft genau so aussehen: eine Tabelle pro Seite, kein Begleittext. Die pragmatische Lösung ist simpel und wirksam: dem Layoutmodell Seitenkontext geben oder nach der Konvertierung doc.tables prüfen und Seiten mit Zählwert Null markieren. Das steht in der Nähe von Issue #3495 (eine Tabelle, die gleichzeitig als Table und Picture erkannt wird), aber den konkreten Auslöser „Seite zu leer — gleiche Tabelle verschwindet isoliert, funktioniert mit Kontext“ konnte ich nirgends veröffentlicht finden. Gemessen, nicht bereits dokumentiert; also doch ein bislang nicht bekannter Fehler.
OCR auf echten Scans: RapidOCR, nicht EasyOCR
Gescanntes PDF ist die Stelle, an der viele Konverter still und heimlich scheitern. Deshalb habe ich Docling zwei echte Scans mit einer gemessenen 0-Zeichen-Textebene gegeben — pypdfium2 meldet null wiederherstellbare Zeichen, also ist jede Ausgabe OCR und keine verdeckte Textebene im Hintergrund.
Die einseitige Datei ocr_test.pdf kam unter CPU in 14,3 Sekunden sauber zurück: „Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package,“ wörtlich wiederhergestellt. Das vierseitige nemotron_multipage.pdf startete OCR auf allen vier Seiten und benötigte insgesamt 70,1 Sekunden (17,5 s/Seite), wobei die Testphrase pro Seite wiederholt ausgegeben wurde. Standard-OCR wurde automatisch ausgelöst — kein Schalter, keine Konfiguration.
Der wichtige Punkt, den viele Beschreibungen falsch haben: Die Standard-OCR-Engine ist RapidOCR, nicht EasyOCR. Ich habe das daran bestätigt, dass beim ersten Lauf die PP-OCRv4-.pth-Gewichte heruntergeladen wurden. Viele ältere Blogartikel und auch ältere Docling-FAQ-Texte behaupten noch, EasyOCR sei standardmäßig aktiv — das ist veraltet. EasyOCR ist heute ein optionales Extra. Was weiterhin stimmt: OCR ist der langsame Pfad bei großen Mengen, und alles hier ist ein CPU-only-Limit — mit GPU würden diese Zeiten deutlich sinken.
Echte PDFs, Lesereihenfolge und Zeit pro Seite
Synthetische Testdateien beweisen einzelne Verhaltensweisen; echte PDFs zeigen, ob das Ganze im Alltag tatsächlich funktioniert. Ich habe zwei born-digital wissenschaftliche Arbeiten getestet — den 9-seitigen Docling Technical Report und „Attention Is All You Need“ mit 15 Seiten, beide zweispaltig und mit Tabellen und Formeln.
Beim 15-seitigen Attention-Paper erscheinen alle fünf Abschnittsmarker — Abstract, Introduction, Background, Conclusion, References — in Dokumentreihenfolge im linearisierten Markdown, obwohl das Layout zweispaltig ist. Jeder relevante Inhaltsprompt (Transformer, encoder, BLEU, multi-head) ist vorhanden, und die berühmten mehrspaltigen Ergebnis-Tabellen werden als vier erkannte Tabellen registriert. Das ist echte Rekonstruktion von Lesereihenfolge und Spaltenzusammenführung — der Kernnutzen für RAG-Chunks, denn ein Dokument lässt sich nicht sinnvoll chunking-basiert verarbeiten, wenn der Linearisierer eine zweispaltige Seite in durcheinandergewürfelten Text zerlegt.
Die Laufzeit zeigt eine kontraintuitive Lektion. Die Zeit pro Seite hängt davon ab, wie viel Struktur jede Seite enthält, nicht bloß von der Seitenzahl. Der dichtere 9-Seiten-Report lief mit 14,95 Sekunden pro Seite — also langsamer pro Seite als das 15-Seiten-Paper mit 5,99 Sekunden pro Seite — weil auf jeder Seite mehr Tabellen und Abbildungen stecken; 3 Tabellen auf 9 Seiten gegenüber 4 auf 15 Seiten, und jede einzelne triggert zusätzliche Layout- und TableFormer-Inferenz. Das ist eine knappe Betrachtung, und absolut gesehen enthält das dichtere Dokument sogar weniger Tabellen, nicht mehr. „Sekunden pro Seite“ ist auf CPU also eine Funktion der strukturellen Dichte, nicht der Länge. Das ist ein einzelner CPU-only-Lauf; ein Obergrenzenwert, kein Produktionswert.
Mehrere Formate und der Anspruch auf verlustfreies JSON
Docling bewirbt ein einheitliches Parsing für mehrere Formate. Also habe ich eine DOCX, eine XLSX und eine PPTX mit bekanntem Inhalt und Ground-Truth-Prompts erzeugt und dann zwei Dinge geprüft: Tauchen die Prompts im Markdown auf, und überleben sie den JSON-Roundtrip via export_to_dict()?
| Datei | Konvertierung s | MD-Prompts gefunden | Tabellen in MD | Prompts überleben JSON |
|---|---|---|---|---|
report.docx (Überschriften + zusammengeführte „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 inhaltlichen Prüfpunkte landeten im Markdown, Tabellen wurden wiederhergestellt (einschließlich der zusammengeführten „Total“-Zeile aus der DOCX und beider XLSX-Sheets), und jeder Prüfpunkt überlebte auch das export_to_dict()-JSON — 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 Millisekundenbereich fertig sind und vollständig offline funktionieren. Der Scope ist ehrlich: je eine saubere Datei pro Format belegt 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 — lesen Sie sie genau. Docling konvertiert das gesamte HTML-Dokument. Es macht keine Readability-artige Extraktion des Hauptinhalts. Ich habe gemessen, wie viel Seitennavigation, Inhaltsverzeichnis, Cookie- und Footer-Text im Docling-Output erhalten bleiben, indem ich die entsprechenden Markierungszeilen gezählt habe.
| Seite | Nicht-leere MD-Zeilen | Boilerplate-Zeilen | % Boilerplate | Artikelbeginn 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 chrome-lastigen 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 Vorlagen-Chromes, nicht eine Seitenstrafe per se. Docling liefert treues Volltext-Markdown des gesamten Dokuments, aber keine saubere Extraktion nur des Hauptartikels. Das Upstream-Projekt verfolgt das HTML-Furniture-Problem in Issue #1865 (geschlossen) und #1930 (offen).
Zwei Dinge machen diese Einschätzung fair. Erstens laufen bei HTML in Docling überhaupt keine ML-Modelle — es ist ein BeautifulSoup-Backend in einer einfachen Pipeline. Die Geschichte von „Vision-Modelle lesen Ihre Seite“ gilt nur für PDF und Bilder; wenn Sie Docling HTML geben, feuern weder Layout- noch TableFormer-Modelle. Zweitens versucht der PDF-Pfad durchaus, Kopf- und Fußzeilen als Deko zu klassifizieren; die Behauptung „gar keine Boilerplate-Entfernung“ wäre also zu stark. Es ist speziell das HTML-Backend, das den Seitenschmuck wieder zurückgibt.
Einordnung im Vergleich – und wo Thunderbit hineinpasst
Thunderbit für Web-Datenextraktion testen
Das Referenztool, mit dem Docling am ehesten verglichen wird, ist Firecrawl. Deshalb hier eine Einordnung. Vorab eine wichtige Einschränkung: Das ist ein Vergleich auf Dokumentationsbasis, kein Benchmark auf demselben Rechner. Ich habe Firecrawl auf diesen Testdateien nicht ausgeführt. Nur die Docling-Spalte ist hier gemessen; die Firecrawl-Spalte basiert auf der öffentlichen Dokumentation.
| Aspekt | Firecrawl (laut Doku) | Docling (hier gemessen) |
|---|---|---|
| Kernaufgabe | Live-Web crawlen + scrapen → Markdown | Ein vorhandenes Dokument konvertieren → Markdown/JSON |
| Fetching / JS-Rendering / Anti-Bot | Ja (gehosteter Browser) | Nein — Sie liefern die Datei |
| Hauptinhalt-Extraktion | Ja | Nein — treues Volltext-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) |
| Gescannte PDFs / OCR | eingeschränkt | Ja — RapidOCR standardmäßig (0-Text-Layer-Scan wurde erfolgreich gelesen) |
| Formatbreite | Webseiten | PDF/DOCX/PPTX/XLSX/HTML/EPUB/Bilder |
| Deployment | gehostete API (+ Self-host) | lokale Python-Library, offline, ohne API-Key |
| Einrichtungsaufwand | API-Key / leichter Client | 1,3-GB-Standardinstallation + ~506 MiB Modelle (oder docling-slim) |
| Lizenz | kommerziell / source-available | MIT |
Die Kurzfassung in einem Satz: Firecrawl ist das richtige Tool, wenn Ihre Daten live im Web liegen und Sie Crawling, JavaScript-Rendering und Main-Content-Cleanup brauchen. Docling ist das richtige Tool, wenn Sie das Dokument bereits besitzen — besonders bei PDFs, Scans und tabellenlastigen Office-Dateien — und eine treue, offline arbeitende, strukturerhaltende Konvertierung mit echtem Tabellen- und OCR-Verständnis wollen. Die Tools ergänzen sich. Eine realistische Pipeline crawlt mit dem einen und konvertiert Dokumente mit dem anderen.
An dieser Stelle will ich offen über Thunderbit sprechen, weil ich dort arbeite und Sie zu Recht skeptisch wären, wenn ich so tue, als wäre das zufällig egal. Thunderbit und Docling lösen nicht dasselbe Problem, 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 JS-Rendering, Anti-Bot und CAPTCHA, die Docling ausdrücklich nicht anfasst), und POST /extract liefert schema-konformes strukturiertes JSON über ein von Ihnen definiertes JSON Schema. Das ist das Fetch-and-Clean-Ende einer RAG-Pipeline. Docling ist das lokale Dokumenten-Ende — das PDF, der Scan, die Tabellenkalkulation, die schon auf Ihrer Festplatte liegt. Wenn Ihre Quelle Webseiten sind, 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 bei den meisten realen Pipelines der Fall ist — kombinieren Sie sie; keiner versucht, der andere zu sein.
Fazit: Vorläufig gut, aber mit offener Hausaufgabe
Ich gebe Ihnen hier keine einzige Gesamtnote von 0 bis 100, weil ein gewichteter Gesamtwert sonst Dinge mitbestrafen würde, die Docling nie für sich beansprucht hat (wie Crawling), und so täte, als seien sie direkt vergleichbar. Pro Dimension, auf den von mir getesteten Dateien:
- Setup / erster Lauf: schwergewichtig — 1,3-GB-Venv, ~506 MiB Modelle, ~224 s erster PDF-Lauf, ~0,55 s im Warm-Run — aber
docling-slimnimmt Ihnen die Last ab. - Tabellenqualität: stark, wenn eine Tabelle erkannt wird (Cell Recall 1,00 bei 5/5, In-Row 0,97–1,00), passend zur offiziellen TEDS-Geschichte auf diesen Testfällen.
- Robustheit der Tabellenerkennung: die Sparse-Page-Falle — eine isolierte Tabelle kann als Picture verloren gehen. Daher
doc.tablesnachprüfen. - Scans / OCR: funktioniert, RapidOCR standardmäßig; bei großen Mengen langsam.
- Mehrere Formate: solide, der JSON-Roundtrip bleibt intakt.
- HTML: treu, nicht sauber — keine Extraktion nur des Hauptinhalts.
- Developer Experience: saubere 3-Zeilen-API und ein ordentliches
DoclingDocument, abgesehen vom fehlenden__version__.
Für wen es gedacht ist: Teams, die RAG- oder Datenpipelines über PDFs, Scans und Office-Dateien bauen und dafür offline, strukturerhaltend und mit echter Tabellen- sowie OCR-Intelligenz konvertieren wollen. Für wen es nicht gedacht ist: alle, die Live-Web-Crawling oder saubere HTML-Hauptartikel-Extraktion brauchen — dafür gibt es andere Tools.
Und weil das hier ein Review und keine Pressemitteilung ist, bleiben die Grenzen sichtbar. Das ist ein gezielter Test — 7 synthetische Tabellen plus 2 echte PDFs auf einem CPU-only-Rechner — und kein TEDS-Benchmark in großem Maßstab. Einige Dinge habe ich nicht getestet und Sie sollten sie prüfen, bevor Sie eine Pipeline auf Docling aufsetzen: den optionalen VLM-Pfad (GraniteDocling), den tatsächlichen Fußabdruck von docling-slim, einen GPU-Lauf, komplexe und unregelmäßige gemergte Zellen plus mehrseitige Tabellen, Formel-zu-LaTeX-Treue und — am ehesten problematisch in Produktion — die Dauerhaltbarkeit von Speicherverbrauch bei Batches, Thread-/GIL-Skalierung und Objektlebenszyklen über Tausende von Konvertierungen. Docling ist stark in dem, was es verspricht, gemessen statt vermarktet, und es hat echte Kanten, die Sie vor dem produktiven Einsatz kennen sollten. Merken Sie sich die Sparse-Page-Einschränkung, kalkulieren Sie den Download beim ersten Lauf ein und prüfen Sie das Verhalten bei echter Last selbst.
Thunderbit für Web-Datenextraktion testen Get Started Free
FAQs
Ist Docling ein Web Scraper oder Crawler? Nein. Docling konvertiert Dokumente, die Sie bereits haben — PDF, DOCX, PPTX, XLSX, HTML, Bilder — in Markdown oder JSON. Es lädt keine URLs, rendert kein JavaScript und kümmert sich nicht um Anti-Bot-Schutz. Das Crawlen des Live-Webs ist eine getrennte Aufgabe, die Tools wie Firecrawl oder Thunderbits Web-API übernehmen; Docling startet bei der Datei, die Sie ihm geben.
Wie groß sind Installation und Erst-Download bei Docling?
Das Standard-Metapaket docling erzeugt ein rund 1,3 GB großes virtuelles Environment, weil der komplette ML-Stack als harte Abhängigkeit mitkommt (allein torch macht 536 MiB aus). Die erste PDF-Konvertierung lädt etwa 506 MiB an Layout- und TableFormer-Modellen plus rund 40 MB RapidOCR-Gewichte herunter und dauert ungefähr 224 Sekunden — fast vollständig Download-Zeit. Die zweite Konvertierung dauert rund 0,55 Sekunden. Wer nur leichte Formate braucht, kann mit docling-slim (Kern etwa 50 MB) die schwere Pfadkombination umgehen.
Macht Docling OCR, und mit welcher Engine? Ja. Bei einem gescannten PDF ohne Textebene startet OCR automatisch, und in meinem Test wurde der Text sauber wiederhergestellt. Die Standard-Engine ist RapidOCR, nicht EasyOCR — ein häufiger Fehler in älteren Beiträgen. EasyOCR ist heute ein optionales Zusatzpaket. OCR ist bei großen Datenmengen der langsame Pfad, besonders auf CPU.
Warum hat Docling meine Tabelle in ein Bild verwandelt oder komplett ausgelassen?
Sehr wahrscheinlich wegen des Sparse-Page-Effekts. Das RT-DETR-Layoutmodell von Docling nutzt Seitenkontext, und eine kleine Tabelle auf einer fast leeren Seite kann als Picture klassifiziert und ohne Fehlermeldung verworfen werden. Dieselbe Tabelle funktioniert, wenn sie von Fließtext umgeben ist. Die Lösung: dem Layoutmodell mehr Seitenkontext geben oder nach der Konvertierung doc.tables prüfen und Seiten mit Wert Null markieren.
Docling vs Firecrawl — was sollte ich nehmen? Es sind unterschiedliche Werkzeuge, daher meistens kein Entweder-oder. Firecrawl crawlt das Live-Web, rendert JavaScript und extrahiert den Hauptinhalt. Docling konvertiert die Dokumente, die Sie bereits 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 kommen beide zusammen zum Einsatz.
