Το Docling συχνά μπαίνει στην ίδια κατηγορία με τα web scrapers, αλλά στην πράξη δεν είναι αυτό. Είναι ένα εργαλείο μετατροπής εγγράφων από το IBM Research — πλέον project του LF AI & Data Foundation — που παίρνει αρχεία που ήδη έχετε (PDF, DOCX, PPTX, XLSX, HTML, εικόνες) και τα μετατρέπει σε Markdown ή JSON. Το ίδιο το σλόγκαν του το λέει ξεκάθαρα: "Get your documents ready for gen AI."
Άρα εδώ μιλάμε για hands-on αξιολόγηση ενός μετατροπέα, όχι ενός crawler. Όσα ακολουθούν μετρήθηκαν σε μηχάνημα μόνο με CPU (macOS arm64, Python 3.14.2, Docling 2.111.0), βαθμολογήθηκαν με scripts, και ό,τι απέτυχε καταγράφηκε ως αποτυχία. Το repo είναι τεράστιο και αλλάζει καθημερινά — 63.069 stars, 4.449 forks, και ένα push την ίδια μέρα που τράβηξα τα metadata — οπότε κάθε αριθμό έκδοσης ή σφάλματος εδώ να τον βλέπετε σαν στιγμιότυπο, όχι σαν σταθερά.
Τι είναι πραγματικά το Docling — και τι δεν είναι
Η βασική μονάδα σε όλο το Docling είναι το DoclingDocument: κάνεις parse ένα αρχείο σε αυτή τη δομή και μετά το εξάγεις σε Markdown, HTML, DocTags ή lossless JSON. Ο κώδικας είναι MIT-licensed (τα licenses των επιμέρους μοντέλων διαφέρουν), προήλθε από το IBM Research Zurich και, τη στιγμή που γράφεται αυτό, η τελευταία έκδοση είναι η v2.112.0, δημοσιευμένη δύο μέρες πριν το τρέξιμό μου.
Η πιο σημαντική δυνατότητα είναι η διαδρομή για PDF και εικόνες. Και αυτή δεν βασίζεται σε απλό parsing κειμένου — είναι ένα stack από machine learning μοντέλα: ένα RT-DETR layout model, το TableFormer table-structure model, ένα προαιρετικό vision-language model και το RapidOCR για σαρώσεις. Αυτά τα μοντέλα ανακτούν τη διάταξη της σελίδας, τη σειρά ανάγνωσης και τη δομή των πινάκων. Αυτό είναι το κομμάτι που αξίζει να αξιολογήσεις, και το κομμάτι που ένα τεστ μόνο σε HTML δεν θα έβλεπε ποτέ.
Μια διάκριση γλιτώνει πολλή σύγχυση. Το Docling δεν κάνει fetch τίποτα. Δεν κάνει render JavaScript, δεν περνά anti-bot εμπόδια, δεν κάνει crawl. Εσύ του δίνεις το αρχείο· εκείνο το καταλαβαίνει. Το crawling είναι δουλειά άλλου εργαλείου, και αυτό έχει σημασία αργότερα όταν μπαίνει το ερώτημα αν το Docling αντικαθιστά το Firecrawl (δεν το αντικαθιστά — είναι συμπληρωματικά, και θα εξηγήσω γιατί).
Η πρώτη εκτέλεση για την οποία κανείς δεν σε προειδοποιεί
Το pip install docling ολοκληρώνεται χωρίς πρόβλημα σε Python 3.14.2. Μετά όμως κοιτάς το venv και είναι 1.3 GB. Το Docling τραβάει όλο το ML stack ως hard dependencies, ακόμη κι αν πρόκειται να μετατρέψεις μόνο ένα HTML αρχείο:
| Εξάρτηση | Μέγεθος στον δίσκο (MiB, du) |
|---|---|
| torch (2.13.0) | 536 |
| opencv (cv2) | 119 |
| transformers (5.8.1) | 101 |
| scipy | 99 |
| sympy | 76 |
| pandas | 72 |
| rapidocr (+ ενσωματωμένα μοντέλα) | 75.6 |
| docling_parse | 30 |
Και αυτά πριν μετατρέψεις έστω ένα PDF. Το πραγματικό friction έρχεται στην πρώτη μετατροπή PDF, γιατί τότε κατεβαίνουν τα μοντέλα. Σε καθαρό, απομονωμένο HuggingFace cache, η πρώτη μετατροπή PDF πήρε περίπου 224 δευτερόλεπτα — και σχεδόν όλος αυτός ο χρόνος ήταν download, όχι υπολογισμός. Τα layout και TableFormer μοντέλα πιάνουν περίπου 506 MiB στον δίσκο (342 MiB TableFormer + 164 MiB layout, επιβεβαιωμένα με du), και το RapidOCR κατεβάζει περίπου 40 MB από PP-OCRv4 weights μέσα στο site-packages. Η δεύτερη μετατροπή του ίδιου αρχείου; 0,55 δευτερόλεπτα. Τα μοντέλα μπαίνουν cache· το κόστος το πληρώνεις μία φορά.
Ένας αριθμός που πρέπει να αγνοήσεις: το coldstart script δείχνει model_download_mb 1060.2. Μην το παραθέτεις ως footprint. Βγαίνει από ένα os.walk που ακολουθεί symlinks, ενώ το HuggingFace cache κρατά κάθε αρχείο μοντέλου μία φορά στο blobs/ και μετά το ξαναδείχνει ως symlink μέσα από το snapshots/ — έτσι το walk μετρά τα 14 αρχεία μοντέλων δύο φορές. Η σωστή, απο-διπλομετρημένη τιμή που συμφωνεί με το du είναι περίπου 506 MiB (μόνο blobs: 505,4 MiB). Το συμπέρασμα για όποιον κάνει benchmark το Docling: να αναφέρει ξεχωριστά τα bytes που κατεβαίνουν και τα bytes που μένουν στον δίσκο, γιατί δεν είναι το ίδιο πράγμα.
Υπάρχει και ένα δεύτερο σημείο που θα χτυπήσει όποιον φτιάχνει container για Docling. Τα weights μοιράζονται σε δύο τοποθεσίες και σε δύο ρυθμούς. Τα layout και TableFormer μοντέλα σέβονται το HF_HOME και κατεβαίνουν στην πρώτη μετατροπή PDF. Τα μοντέλα του RapidOCR όχι — καταλήγουν σε …/site-packages/rapidocr/models/, παρακάμπτοντας τελείως το cache config σας. Αν χτίζετε image εκ των προτέρων ή δουλεύετε air-gapped, πρέπει να φροντίσετε και τα δύο caches, και καμία ρύθμιση του HF_HOME δεν θα πιάσει το δεύτερο.
Τώρα η δίκαιη πλευρά. Σε σχέση με παλιότερες εκδόσεις, το project έχει διαθέσει το docling-slim — έναν core περίπου 50 MB που σας επιτρέπει να κάνετε pip install docling-slim[format-html] για HTML χωρίς να τραβάτε το torch. Άρα το βάρος των 1,3 GB είναι πραγματικό για το default docling metapackage, αλλά πλέον μπορείς να το αποφύγεις. Εγώ δοκίμασα το default package επειδή αυτό δίνει ακόμα το pip install docling, όμως το βάρος δεν είναι άλυτο πρόβλημα — υπάρχει modular λύση, καταγεγραμμένη στο issue #2393.
Στο setup συνάντησα και ένα μικρό αλλά ενοχλητικό θέμα: το import docling; docling.__version__ πετάει AttributeError: module 'docling' has no attribute '__version__'. Το module απλώς δεν το εκθέτει. Το σωστό probe είναι importlib.metadata.version("docling"), που επιστρέφει '2.111.0'. Μικρή ενόχληση για το developer experience, open upstream από τον Ιούλιο 2026 ως issue #3733.
Ακεραιότητα πινάκων: εκεί που το TableFormer κερδίζει το ψωμί του
Οι πίνακες είναι ο λόγος που κάποιος θα προτιμήσει το Docling αντί για ένα απλό PDF-to-text dump, οπότε δημιούργησα επτά PDF με πίνακες και machine-readable ground truth και βαθμολόγησα την έξοδο κελί προς κελί. Δύο μετρικές έχουν σημασία, και δεν είναι το ίδιο πράγμα: το cell recall είναι το ποσοστό των ground-truth τιμών που εμφανίζονται κάπου μέσα στον ανιχνευμένο πίνακα· το in-row rate είναι το ποσοστό που καταλήγουν στη σωστή γραμμή. Αν τα συγχέεις, αδικείς το εργαλείο, οπότε παραθέτω και τα δύο:
| Πίνακας (stress) | Ανιχνεύθηκε | Cell recall | In-row rate | Σημείωση |
|---|---|---|---|---|
| T1 απλό πλέγμα με περίγραμμα (5×8), μόνο του στη σελίδα | Όχι | 0.0 | — | ταξινομήθηκε ως <!-- image -->, όλα τα κελιά χάθηκαν |
| T2 χωρίς περιγράμματα (μόνο header rule) | Ναι | 1.00 | 1.00 | τέλειο, ακριβές grid |
| T3 header 2 επιπέδων με merged colspan | Ναι | 1.00 | 0.97 | όλες οι τιμές βρέθηκαν· μία τιμή header μετατοπίζεται μια γραμμή |
| T4 merged rowspan row-label, μόνο του στη σελίδα | Όχι | 0.0 | — | ταξινομήθηκε ως <!-- image --> |
| T5 colspan header + χωρίς περιγράμματα | Ναι | 1.00 | 0.97 | όλες οι τιμές βρέθηκαν· η ίδια μετατόπιση γραμμής header όπως στο T3 |
| T6 οικονομικά στοιχεία, κενή στήλη, δεξιά στοίχιση | Ναι | 1.00 | 1.00 | η κενή στήλη διατηρήθηκε, δεν μετατοπίστηκε |
| T7 φαρδύ grid 12 στηλών | Ναι | 1.00 | 1.00 | καμία μετατόπιση στηλών σε φαρδύ πίνακα |
Στους πέντε πίνακες που εντόπισε το Docling, κάθε τιμή του ground truth πέρασε μέσα — cell recall 1.00 παντού. Στους τρεις από αυτούς, κάθε τιμή έπεσε και στη σωστή γραμμή. Στις δύο περιπτώσεις με πολλαπλά επίπεδα header (T3 και T5), μία τιμή header γλιστράει από την αρχική της γραμμή, ρίχνοντας το in-row στο 0.97 — όλα τα δεδομένα υπάρχουν, απλώς η αντιστοίχιση γραμμής τρεκλίζει μία θέση σε ένα stacked header.
Οι δύσκολες δομικές περιπτώσεις άντεξαν καλύτερα απ’ όσο περίμενα. Το header δύο επιπέδων με colspan flattened σωστά σε GitHub-flavored Markdown (η ετικέτα "Q1 2026" επαναλήφθηκε πάνω από τις δύο στήλες που καλύπτει, που είναι ο σωστός τρόπος να αποδοθεί ένα colspan σε GFM). Το borderless grid με μόνο ένα header rule (T2) πέρασε ακριβώς. Ο φαρδύς πίνακας 12 στηλών (T7) δεν μετατοπίστηκε. Και μια εντελώς κενή οικονομική στήλη (T6) διατηρήθηκε ως κενά κελιά, αντί να χαθεί ή να συμπτυχθεί. Αυτό συμφωνεί με τα επίσημα TEDS scores του TableFormer — 95.4 simple, 90.1 complex, 93.6 all-tables — τα οποία το model card συγκρίνει ξεκάθαρα καλύτερα από Camelot (73.0) και EDD (88.3).
Μια προειδοποίηση για merged cells, γιατί υπάρχει ανοιχτό issue που λέει το αντίθετο. Το issue #3698 αναφέρει ότι οι V1 και V2 χειρίζονται λάθος merged rows και columns. Στα δικά μου fixtures, το απλό colspan (T3/T5) και τα rowspan values αποδόθηκαν σωστά, με εξαίρεση τη μετατόπιση μιας γραμμής στα multi-level headers που σημείωσα παραπάνω. Όμως τα αποτυχημένα παραδείγματα του #3698 είναι ανομοιόμορφα merges πολλών γραμμών/στηλών και πίνακες πολλών σελίδων — δηλαδή το παθολογικό άκρο του προβλήματος. Τα δικά μου είναι το απλό άκρο. Άρα η ακριβής διατύπωση είναι στενή: απλό colspan και rowspan ανακτήθηκαν σωστά εδώ (τα multi-level headers μπορεί να μετατοπίσουν μία γραμμή)· τα σύνθετα και ακανόνιστα merges παραμένουν γνωστό ανοιχτό πρόβλημα. Όχι «τα merged cells δουλεύουν», όχι «τα merged cells είναι χαλασμένα».
Η παγίδα: ένας πίνακας μόνος του σε μία σελίδα μπορεί να εξαφανιστεί
Κοιτάξτε ξανά τον πίνακα — τα T1 και T4 δεν ανιχνεύθηκαν καθόλου. Το Docling έβγαλε <!-- image --> και πέταξε όλα τα κελιά, χωρίς σφάλμα. Το T1 είναι ένα απολύτως συνηθισμένο grid 5×8 με περίγραμμα. Αυτό είναι αρκετά ανησυχητικό ώστε να μη θέλω να το πω αδυναμία parsing πίνακα πριν απομονώσω τι ακριβώς το προκάλεσε, οπότε έφτιαξα ένα script A/B test.
Πρώτα απέκλεισα τις προφανείς εξηγήσεις. Το text layer είναι άθικτο — το pypdfium2 διαβάζει 327 χαρακτήρες από το T1 και 221 από το T4, άρα πρόκειται για πραγματικά digital PDFs, όχι σαρωμένες εικόνες. Το να κλείσω το OCR (do_ocr=False) δεν βοηθά· οι πίνακες πάλι χάνονται. Και αν κοιτάξω απευθείας το DoclingDocument, το len(doc.tables) == 0 ενώ το len(doc.pictures) == 1 — το layout model είχε ταξινομήσει ολόκληρη την περιοχή του πίνακα ως Picture.
Μετά ήρθε το καθοριστικό τεστ. Έκανα render ξανά τους ίδιους ακριβώς πίνακες T1 και T4, αλλά αυτή τη φορά τους περιέβαλα με μερικές συνηθισμένες παραγράφους σώματος κειμένου, και έτρεξα πάλι τη μετατροπή. Και οι δύο πέρασαν τέλεια: len(doc.tables) == 1, σωστά GFM tables, και το rowspan label του T4b, "North", επαναλήφθηκε σωστά και στις τρεις γραμμές του. Ο ίδιος πίνακας. Η μόνη μεταβλητή που άλλαξε ήταν αν στεκόταν μόνος του σε sparse page ή αν ήταν ενσωματωμένος σε κείμενο.
Άρα η πραγματική προειδοποίηση δεν είναι ότι το TableFormer είναι εύθραυστο — είναι ότι το RT-DETR layout model του Docling χρησιμοποιεί το πλαίσιο της σελίδας, και ένας μικρός πίνακας μόνος του σε σχεδόν άδεια σελίδα είναι πιθανό να διαβαστεί ως Picture και να χαθεί σιωπηρά. Αυτό συμβαίνει εύκολα στην πράξη, γιατί ακριβώς έτσι μοιάζουν invoices, spec sheets και cropped exports: ένας πίνακας ανά σελίδα, χωρίς γύρω κείμενο. Η λύση είναι απλή και αποτελεσματική — δώστε στο layout model συμφραζόμενα σελίδας ή κάντε post-check το doc.tables μετά τη μετατροπή και σημαδέψτε τις σελίδες όπου ο αριθμός είναι μηδέν. Αυτό είναι συγγενικό με το issue #3495 (πίνακας που ανιχνεύεται και ως Table και ως Picture), αλλά το συγκεκριμένο trigger της sparsity της σελίδας — ο ίδιος πίνακας χάνεται όταν είναι απομονωμένος και περνά όταν είναι ενσωματωμένος — δεν το βρήκα δημοσιευμένο πουθενά. Μετρημένο, όχι ήδη τεκμηριωμένο· όχι bug που δεν το ήξερε κανείς.
OCR σε πραγματικές σαρώσεις: RapidOCR, όχι EasyOCR
Τα σαρωμένα PDFs είναι εκεί όπου πολλοί μετατροπείς αποτυγχάνουν αθόρυβα, οπότε έδωσα στο Docling δύο πραγματικές σαρώσεις με μετρημένο text layer 0 χαρακτήρων — το pypdfium2 επιστρέφει μηδενικούς ανακτήσιμους χαρακτήρες, επιβεβαιώνοντας ότι ό,τι βγει προέρχεται από OCR και όχι από κρυφό text layer.
Το μονοσέλιδο ocr_test.pdf επέστρεψε καθαρό σε 14,3 δευτερόλεπτα σε CPU: "Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package," ανακτήθηκε λέξη προς λέξη. Το τετρασέλιδο nemotron_multipage.pdf ενεργοποίησε OCR και στις τέσσερις σελίδες σε συνολικά 70,1 δευτερόλεπτα (17,5 s/σελίδα), αποδίδοντας την επαναλαμβανόμενη δοκιμαστική πρόταση σε κάθε σελίδα. Το default OCR ξεκίνησε αυτόματα — χωρίς flag, χωρίς config.
Να η λεπτομέρεια που οι περισσότερες αναρτήσεις γράφουν λάθος: η default OCR μηχανή είναι το RapidOCR, όχι το EasyOCR. Το επιβεβαίωσα βλέποντας τα PP-OCRv4 .pth weights να κατεβαίνουν στο πρώτο run. Πολλά υπάρχοντα blogs και παλιότερα Docling FAQ κείμενα ακόμα λένε ότι το EasyOCR είναι το default· αυτό είναι παλιό. Το EasyOCR πλέον είναι extra που το ενεργοποιείς προαιρετικά. Η προειδοποίηση που παραμένει σωστή: το OCR είναι το αργό μονοπάτι σε μεγάλη κλίμακα, και εδώ όλα είναι ceiling για CPU μόνο — μια GPU θα μείωνε αισθητά αυτούς τους χρόνους.
Πραγματικά PDFs, σειρά ανάγνωσης και χρόνος ανά σελίδα
Τα synthetic fixtures αποδεικνύουν συγκεκριμένες συμπεριφορές· τα πραγματικά PDFs αποδεικνύουν ότι το εργαλείο όντως δουλεύει. Έτρεξα δύο born-digital ακαδημαϊκές εργασίες — το 9σέλιδο τεχνικό report του Docling και το 15σέλιδο "Attention Is All You Need", και τα δύο με δύο στήλες, πίνακες και μαθηματικούς τύπους.
Στο 15σέλιδο Attention paper, και οι πέντε δείκτες ενοτήτων — Abstract, Introduction, Background, Conclusion, References — εμφανίζονται με τη σωστή σειρά μέσα στο document στο linearized Markdown, παρότι η διάταξη είναι δύο στηλών. Κάθε content probe (Transformer, encoder, BLEU, multi-head) υπάρχει, και οι γνωστοί πολυστηλοί πίνακες αποτελεσμάτων αναγνωρίζονται ως τέσσερις ανιχνευμένοι πίνακες. Αυτό είναι πραγματική ανάκτηση σειράς ανάγνωσης και συνένωσης στηλών, που είναι η βασική αξία για RAG chunking — δεν μπορείς να κάνεις σωστό chunking αν ο linearizer διαλύει μια σελίδα δύο στηλών σε ανακατεμένο χάος.
Το timing δίνει ένα μάλλον αντιδιαισθητικό μάθημα. Ο χρόνος ανά σελίδα καθορίζεται από το πόση δομή έχει κάθε σελίδα, όχι από το συνολικό πλήθος σελίδων. Το πιο πυκνό 9σέλιδο report έτρεξε με 14,95 δευτερόλεπτα ανά σελίδα — πιο αργά ανά σελίδα από το 15σέλιδο paper που έτρεξε με 5,99 δευτερόλεπτα ανά σελίδα — επειδή περιέχει περισσότερους πίνακες και figures, και το καθένα ενεργοποιεί περισσότερη layout και TableFormer inference. Άρα τα "δευτερόλεπτα ανά σελίδα" σε CPU είναι συνάρτηση της δομικής πυκνότητας, όχι του μήκους. Αυτό είναι ένα μόνο run σε CPU· είναι ceiling, όχι production number.
Multi-format και ο ισχυρισμός για lossless JSON
Το Docling διαφημίζει ενιαίο parsing για πολλαπλά formats, οπότε έφτιαξα ένα DOCX, ένα XLSX και ένα PPTX με γνωστό περιεχόμενο και probes ground truth, και έλεγξα δύο πράγματα: αν τα probes εμφανίζονται στο Markdown και αν επιβιώνουν στο JSON round-trip μέσω export_to_dict().
| Αρχείο | Convert s | MD probes found | Πίνακες στο MD | Probes επιβιώνουν στο JSON |
|---|---|---|---|---|
report.docx (headings + merged-"Total" table + bullets) | 0.137 | 7/7 | 1 | Ναι |
workbook.xlsx (2 sheets, κενή στήλη) | 0.016 | 6/6 | 2 | Ναι |
deck.pptx (3 slides, bullets + table) | 0.038 | 6/6 | 1 | Ναι |
Όλα τα probes πέρασαν στο Markdown, οι πίνακες ανακτήθηκαν σωστά (μαζί και η merged "Total" γραμμή στο DOCX και και τα δύο φύλλα στο XLSX), και κάθε probe επέζησε επίσης στο JSON του export_to_dict() — που είναι η ουσιαστική απόδειξη για τον ισχυρισμό του lossless DoclingDocument, τουλάχιστον σε καθαρά inputs. Αυτά τα formats περνούν από format-native backends αντί για τα ML models, γι’ αυτό και εκτελούνται σε δεκάδες milliseconds και δουλεύουν πλήρως offline. Το εύρος που αποδεικνύεται εδώ είναι ειλικρινές: ένα καθαρό αρχείο ανά format αποδεικνύει την κάλυψη, όχι stress test σε προβληματικά Office files.
HTML: πιστό, αλλά όχι καθαρό
Αυτό είναι το caveat που κρίνει αν το Docling ανήκει στο RAG pipeline σας, οπότε διαβάστε το προσεκτικά. Το Docling μετατρέπει ολόκληρο το HTML document. Δεν κάνει main-content extraction τύπου readability. Μέτρησα πόσο site chrome επιβιώνει, μετρώντας γραμμές nav, TOC, cookie και footer markers στην έξοδο του ίδιου του Docling.
| Σελίδα | Non-blank MD lines | Boilerplate lines | % boilerplate | Το άρθρο ξεκινά στη γραμμή |
|---|---|---|---|---|
| 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% | — |
Σε σελίδα με πολύ chrome όπως η Wikipedia, περίπου το 13% των Markdown γραμμών είναι nav/TOC/footer boilerplate, και το πραγματικό άρθρο δεν ξεκινά πριν τη γραμμή 28 — η έξοδος ανοίγει με "move to sidebar / Contents / Toggle the table of contents" και κλείνει με "CS1 maint… / Search Wikipedia." Σε καθαρές σελίδες περιεχομένου (books, quotes) είναι περίπου 0%, άρα πρόκειται για πρόβλημα template chrome, όχι για φόρο ανά σελίδα. Το Docling σας δίνει πιστό Markdown ολόκληρου του document, όχι καθαρή εξαγωγή του κύριου άρθρου. Το upstream παρακολουθεί το πρόβλημα με το HTML furniture στο issue #1865 (closed) και στο #1930 (open).
Δύο πράγματα κρατούν αυτή τη διατύπωση δίκαιη. Πρώτον, ειδικά για HTML το Docling δεν τρέχει κανένα ML model — είναι ένα BeautifulSoup backend σε απλό pipeline. Η ιστορία με τα vision models που διαβάζουν τη σελίδα σας ισχύει μόνο για PDF και εικόνες· αν δώσετε HTML στο Docling, δεν ενεργοποιείται κανένας από τους layout ή TableFormer μηχανισμούς. Δεύτερον, το PDF path πράγματι επιχειρεί classification για header και footer furniture, άρα το να πούμε "καθόλου boilerplate removal" θα ήταν υπερβολικό· συγκεκριμένα το HTML backend είναι αυτό που επιστρέφει το chrome.
Πώς συγκρίνεται — και πού μπαίνει το Thunderbit
Δοκιμάστε το Thunderbit για εξαγωγή web δεδομένων
Το βασικό εργαλείο με το οποίο συγκρίνεται το Docling είναι το Firecrawl, οπότε παρακάτω υπάρχει ένας πίνακας τοποθέτησης. Μια προειδοποίηση από την αρχή, γιατί έχει σημασία: αυτή είναι σύγκριση σε επίπεδο τεκμηρίωσης, όχι benchmark στο ίδιο μηχάνημα. Δεν έτρεξα το Firecrawl σε αυτά τα fixtures. Μόνο η στήλη του Docling είναι μετρημένη εδώ· η στήλη του Firecrawl προέρχεται από τα δημόσια docs του.
| Άξονας | Firecrawl (σύμφωνα με τα docs του) | Docling (μετρημένο εδώ) |
|---|---|---|
| Κύρια δουλειά | Crawl + scrape το live web → Markdown | Μετατροπή ενός εγγράφου που ήδη έχετε → Markdown/JSON |
| Fetch / render JS / anti-bot | Ναι (hosted browser) | Όχι — δίνετε εσείς το αρχείο |
| Main-content extraction | Ναι | Όχι — πιστό πλήρες document (~13% chrome στη Wikipedia) |
| Δομή πινάκων σε PDF (ML) | περιορισμένη | Ναι — TableFormer (TEDS 93.6 επίσημο· cell recall 1.00, in-row 0.97–1.00 στα detected fixtures) |
| Σαρωμένα PDF / OCR | περιορισμένο | Ναι — RapidOCR by default (ανέκτησε scan με 0 text layer) |
| Εύρος formats | web pages | PDF/DOCX/PPTX/XLSX/HTML/EPUB/images |
| Deployment | hosted API (+ self-host) | local pip library, offline, χωρίς API key |
| Βάρος εγκατάστασης | API key / ελαφρύ client | 1.3 GB default install + ~506 MiB models (ή docling-slim) |
| Άδεια | commercial / source-available | MIT |
Η μία γραμμή συμπέρασμα: το Firecrawl είναι το εργαλείο όταν τα δεδομένα σας βρίσκονται στο live web και χρειάζονται crawling, render JavaScript και καθαρισμό του κύριου περιεχομένου. Το Docling είναι το εργαλείο όταν ήδη έχετε το document — ειδικά PDF, scans και Office files με πολλούς πίνακες — και θέλετε πιστή, offline, δομικά διατηρημένη μετατροπή με πραγματική κατανόηση πινάκων και OCR. Είναι συμπληρωματικά. Ένα ρεαλιστικό pipeline κάνει crawl με το ένα και μετατρέπει έγγραφα με το άλλο.
Και εδώ θα είμαι ξεκάθαρος για το Thunderbit, επειδή δουλεύω εδώ και δικαίως θα ήσασταν καχύποπτοι αν προσποιούμουν το αντίθετο. Το Thunderbit και το Docling δεν κάνουν την ίδια δουλειά, και δεν θα τα εξισώσω τεχνητά. Για developers, το Thunderbit είναι AI scraping API + MCP server + CLI, και η μονάδα εργασίας του είναι η ζωντανή web page: το POST /distill μετατρέπει ένα URL σε καθαρό Markdown έτοιμο για LLM (χειριζόμενο το JS rendering, τα anti-bot και το CAPTCHA που το Docling ρητά δεν αγγίζει), και το POST /extract επιστρέφει δομημένο JSON που ταιριάζει σε σχήμα, μέσω ενός JSON Schema που ορίζετε εσείς. Αυτό είναι το fetch-and-clean άκρο ενός RAG pipeline. Το Docling είναι το local-document άκρο — το PDF, η σάρωση, το spreadsheet που ήδη βρίσκεται στον δίσκο σας. Αν το corpus σας είναι web pages, χρησιμοποιήστε το Thunderbit API, τα MCP tools του (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) ή το CLI (npx @thunderbit/thunderbit-cli). Αν είναι PDF και scans, χρησιμοποιήστε Docling. Αν είναι και τα δύο — που είναι το συνηθέστερο σε πραγματικά pipelines — τα συνδυάζετε, και κανένα από τα δύο δεν προσποιείται ότι είναι το άλλο.
Το τελικό συμπέρασμα: προσωρινό, με αρκετή δουλειά ακόμη
Δεν θα σας δώσω ένα ενιαίο σκορ 0–100, γιατί ένα σταθμισμένο σύνολο εδώ θα έβαζε μέσα ποινές για πράγματα που το Docling δεν υποσχέθηκε ποτέ να κάνει (όπως crawling) και θα προσποιούνταν ότι είναι συγκρίσιμα. Αν το δούμε ανά διάσταση, στα fixtures που δοκίμασα:
- Setup / πρώτη εκτέλεση: βαρύ — venv 1.3 GB, μοντέλα ~506 MiB, πρώτο PDF ~224s, warm ~0,55s — αλλά το
docling-slimσας επιτρέπει να αποφύγετε το βάρος. - Ακεραιότητα πινάκων: ισχυρή όταν ο πίνακας ανιχνευθεί (cell recall 1.00 σε 5/5, in-row 0.97–1.00), σε συμφωνία με την επίσημη εικόνα του TEDS στα συγκεκριμένα fixtures.
- Αξιοπιστία ανίχνευσης πινάκων: η παγίδα sparse-page — ένας απομονωμένος πίνακας μπορεί να χαθεί ως Picture. Κάντε post-check το
doc.tables. - Scans / OCR: δουλεύει, RapidOCR by default· αργό σε μεγάλη κλίμακα.
- Multi-format: σταθερό, με το JSON round-trip άθικτο.
- HTML: πιστό, αλλά όχι καθαρό — χωρίς main-content extraction.
- Developer experience: καθαρό 3-line API και καλοσχηματισμένο
DoclingDocument, με εξαίρεση το missing__version__.
Για ποιον είναι: για ομάδες που χτίζουν RAG ή data pipelines πάνω σε PDF, scans και Office files και θέλουν offline, structure-preserving μετατροπή με πραγματική κατανόηση πινάκων και OCR. Για ποιον δεν είναι: για όποιον χρειάζεται live-web crawling ή καθαρή εξαγωγή του κύριου άρθρου σε HTML — αυτό είναι άλλη κατηγορία εργαλείου.
Και επειδή αυτό είναι review και όχι δελτίο τύπου, τα όρια μένουν πάνω στην ετικέτα. Αυτό είναι ένα στοχευμένο probe — 7 συνθετικοί πίνακες και 2 πραγματικά PDF σε ένα μηχάνημα μόνο με CPU — όχι benchmark ακρίβειας τύπου TEDS σε μεγάλη κλίμακα. Υπάρχουν αρκετά πράγματα που δεν δοκίμασα και που θα πρέπει να ελέγξετε πριν στηρίξετε pipeline πάνω στο Docling: το προαιρετικό VLM (GraniteDocling) path, το πραγματικό footprint του docling-slim, οποιοδήποτε GPU run, σύνθετα και ακανόνιστα merged cells μαζί με multi-page tables, fidelity από formula σε LaTeX, και — το πιο πιθανό να σας αιφνιδιάσει στην παραγωγή — την τριάδα ανθεκτικότητας: αύξηση μνήμης στα batch runs, scaling σε threads/GIL και lifecycle των objects σε χιλιάδες μετατροπές. Το Docling είναι δυνατό σε αυτό που υπόσχεται, μετρημένο και όχι marketing, αλλά έχει και πραγματικές άκρες που αξίζει να χαρτογραφήσετε πριν του εμπιστευτείτε ένα corpus. Γνωρίστε την παγίδα των sparse pages, υπολογίστε τον πρώτο χρόνο λήψης και επαληθεύστε μόνοι σας τη συμπεριφορά σε μεγάλη κλίμακα.
Δοκιμάστε το Thunderbit για εξαγωγή web δεδομένων Get Started Free
Συχνές ερωτήσεις
Είναι το Docling web scraper ή crawler;
Όχι. Το Docling μετατρέπει έγγραφα που ήδη έχετε — PDF, DOCX, PPTX, XLSX, HTML, εικόνες — σε Markdown ή JSON. Δεν κάνει fetch URLs, δεν κάνει render JavaScript και δεν χειρίζεται anti-bot. Το crawling του live web είναι ξεχωριστή δουλειά που κάνουν εργαλεία όπως το Firecrawl ή το web API του Thunderbit· το Docling ξεκινά από το αρχείο που του δίνετε.
Πόσο μεγάλο είναι το Docling install και το πρώτο download;
Το default docling metapackage φτιάχνει ένα venv περίπου 1.3 GB, επειδή τραβά όλο το ML stack ως hard dependencies (μόνο το torch είναι 536 MiB). Η πρώτη μετατροπή PDF κατεβάζει περίπου 506 MiB από layout και TableFormer μοντέλα στον δίσκο, συν περίπου 40 MB RapidOCR weights, και παίρνει γύρω στα 224 δευτερόλεπτα — σχεδόν όλος ο χρόνος είναι download. Η δεύτερη μετατροπή είναι περίπου 0,55 δευτερόλεπτα. Αν χρειάζεστε μόνο ελαφριές μορφές, το docling-slim (~50 MB core) παραλείπει το βαρύ μονοπάτι.
Κάνει το Docling OCR, και με ποια μηχανή;
Ναι. Σε σαρωμένο PDF χωρίς text layer, το OCR του Docling ενεργοποιείται αυτόματα και στο δικό μου τεστ ανέκτησε το κείμενο καθαρά. Η default μηχανή είναι το RapidOCR, όχι το EasyOCR — συνηθισμένο λάθος σε παλιότερα κείμενα. Το EasyOCR πλέον είναι προαιρετικό extra. Το OCR είναι το αργό μονοπάτι σε μεγάλη κλίμακα, ειδικά σε CPU.
Γιατί το Docling μετέτρεψε τον πίνακά μου σε εικόνα ή τον έχασε;
Πιθανότατα λόγω του sparse-page effect. Το RT-DETR layout model του Docling χρησιμοποιεί το περιεχόμενο της σελίδας και ένας μικρός πίνακας μόνος του σε σχεδόν άδεια σελίδα μπορεί να ταξινομηθεί ως Picture και να χαθεί χωρίς σφάλμα. Ο ίδιος πίνακας, όταν περιβάλλεται από body text, μετατρέπεται κανονικά. Η λύση είναι να δώσετε στο layout model συμφραζόμενα σελίδας ή να κάνετε post-check το doc.tables μετά τη μετατροπή και να επισημάνετε οποιαδήποτε σελίδα όπου ο αριθμός είναι μηδέν.
Docling vs Firecrawl — ποιο να χρησιμοποιήσω;
Διαφορετικές δουλειές, οπότε συνήθως δεν είναι θέμα είτε/είτε. Το Firecrawl κάνει crawl το live web, κάνει render JavaScript και βγάζει το κύριο περιεχόμενο. Το Docling μετατρέπει έγγραφα που ήδη έχετε, με πραγματική δομή πινάκων PDF και OCR, πλήρως offline. Αν η πηγή σας είναι web pages, χρησιμοποιήστε ένα web tool (Firecrawl ή το API/MCP/CLI του Thunderbit). Αν είναι PDF, scans ή Office files, χρησιμοποιήστε το Docling. Τα περισσότερα πραγματικά pipelines χρησιμοποιούν και τα δύο.
