Docling thường hay bị xếp chung với các web scraper, nhưng thật ra nó không phải vậy. Đây là bộ công cụ chuyển đổi tài liệu do IBM Research phát triển — hiện là một dự án của LF AI & Data Foundation — chuyên nhận các tệp bạn đã có sẵn (PDF, DOCX, PPTX, XLSX, HTML, hình ảnh) rồi chuyển chúng sang Markdown hoặc JSON. Khẩu hiệu của nó nói rất thẳng: "Get your documents ready for gen AI."
Vì thế, đây là một bài đánh giá thực chiến về một bộ chuyển đổi, không phải một trình thu thập dữ liệu. Mọi kết quả bên dưới đều được đo trên một máy chỉ chạy CPU (macOS arm64, Python 3.14.2, Docling 2.111.0), chấm điểm bằng script, và mọi lỗi đều được ghi nhận đúng là lỗi. Repo này thì rất lớn và thay đổi từng ngày — 63,069 sao, 4,449 fork, và còn có một lần đẩy code đúng ngay trong ngày tôi lấy metadata — nên hãy xem mọi con số về phiên bản hay số lỗi ở đây như một ảnh chụp tại thời điểm đó, không phải hằng số.
Docling Thực Ra Là Gì (và Không Phải Là Gì)
Trung tâm của mọi thứ trong Docling là DoclingDocument: phân tích một tệp vào cấu trúc đó, rồi xuất ra Markdown, HTML, DocTags hoặc JSON không mất dữ liệu. Mã nguồn của dự án được cấp phép MIT (các model riêng có thể có giấy phép khác nhau), xuất phát từ IBM Research Zurich, và tại thời điểm viết bài, bản phát hành mới nhất là v2.112.0, được công bố hai ngày trước khi tôi chạy bộ test này.
Khả năng nổi bật nhất nằm ở đường xử lý PDF và hình ảnh. Đường này không phải kiểu tách chuỗi đơn giản — mà là một chuỗi model học máy: model bố cục RT-DETR, model cấu trúc bảng TableFormer, một model thị giác-ngôn ngữ tùy chọn, và RapidOCR cho tài liệu scan. Những model này giúp tái tạo bố cục trang, thứ tự đọc và cấu trúc bảng. Đó mới là phần đáng để đánh giá, và cũng là phần mà một bài test chỉ với HTML sẽ không bao giờ chạm tới.
Có một điểm phân biệt cực kỳ quan trọng để tránh hiểu nhầm cả tuần. Docling không tự đi lấy dữ liệu. Nó không render JavaScript, không vượt qua lớp chống bot, và cũng không crawl. Bạn đưa tệp vào; nó hiểu nội dung của tệp. Việc crawl là việc của công cụ khác, và điều này sẽ rất quan trọng khi người ta hỏi Docling có thay Firecrawl không (không thay — chúng bổ trợ cho nhau, và tôi sẽ nói rõ ở phần sau).
Lần Chạy Đầu Tiên Mà Ít Ai Cảnh Báo Bạn
pip install docling cài khá mượt trên Python 3.14.2. Nhưng khi nhìn vào môi trường ảo, bạn sẽ thấy nó nặng tới 1.3 GB. Docling kéo theo cả stack ML dưới dạng phụ thuộc cứng, ngay cả khi thứ bạn chuyển đổi chỉ là một file HTML:
| Phụ thuộc | Dung lượng trên đĩa (MiB, du) |
|---|---|
| torch (2.13.0) | 536 |
| opencv (cv2) | 119 |
| transformers (5.8.1) | 101 |
| scipy | 99 |
| sympy | 76 |
| pandas | 72 |
| rapidocr (+ model đi kèm) | 75.6 |
| docling_parse | 30 |
Đó mới chỉ là trước khi bạn chuyển đổi bất kỳ PDF nào. Lần chuyển đổi PDF đầu tiên mới là lúc cảm giác “cồng kềnh” hiện rõ, vì đó là khi các model được tải xuống. Trên một cache HuggingFace mới tinh và tách biệt, lần chuyển đổi PDF đầu tiên mất khoảng 224 giây — và gần như toàn bộ thời gian là tải model, không phải tính toán. Cặp model layout + TableFormer chiếm khoảng 506 MiB trên đĩa (342 MiB TableFormer + 164 MiB layout, đã kiểm bằng du), còn RapidOCR tải thêm khoảng 40 MB trọng số PP-OCRv4 vào site-packages. Lần chuyển đổi thứ hai của cùng một tệp? 0.55 giây. Model đã được cache; bạn chỉ phải trả giá một lần.
Có một con số bạn nên bỏ qua: script cold start in ra model_download_mb là 1060.2. Đừng trích con số đó như footprint thực. Nó đến từ một vòng os.walk có đi theo symlink, trong khi cache HuggingFace lưu mỗi file model một lần dưới blobs/, rồi chỉ trỏ lại qua symlink trong snapshots/ — nên phép quét đó đếm 14 file model hai lần. Con số tương ứng với du, đã loại trùng symlink, là khoảng 506 MiB (chỉ riêng blobs là 505.4 MiB). Bài học cho bất kỳ ai benchmark Docling: hãy báo riêng dung lượng tải xuống và dung lượng chiếm trên đĩa, vì chúng là hai chuyện khác nhau.
Có một chi tiết nữa rất dễ làm người dựng container với Docling vấp. Các trọng số nằm ở hai nơi khác nhau theo hai lịch khác nhau. Model layout và TableFormer tôn trọng HF_HOME và tải xuống khi chuyển đổi PDF lần đầu. Còn model của RapidOCR thì không — chúng nằm ở …/site-packages/rapidocr/models/, hoàn toàn bỏ qua cấu hình cache của bạn. Nếu bạn đang dựng image sẵn hoặc chạy trong môi trường air-gap, bạn phải xử lý cả hai cache, và dù có đặt HF_HOME thế nào cũng không chạm tới cái thứ hai.
Bây giờ nói cho công bằng. Từ các bản phát hành trước, dự án đã có docling-slim — một lõi khoảng 50 MB cho phép bạn pip install docling-slim[format-html] để xử lý HTML mà không phải kéo theo torch. Vì vậy, mức 1.3 GB là có thật với gói mặc định docling, nhưng hiện đã có lựa chọn nhẹ hơn. Tôi test gói mặc định vì đó vẫn là thứ pip install docling cài vào, nhưng độ nặng này không phải một lỗi chưa được giải quyết — đã có hướng mô-đun hóa, đang được theo dõi tại issue #2393.
Trong lúc cài đặt, tôi gặp một lỗi nhỏ nhưng đáng nói: import docling; docling.__version__ sẽ báo AttributeError: module 'docling' has no attribute '__version__'. Module đơn giản là không expose giá trị này. Cách kiểm tra đúng là importlib.metadata.version("docling"), trả về '2.111.0'. Đây là một phiền toái nhỏ về trải nghiệm dev, đã mở upstream từ tháng 7/2026 dưới dạng issue #3733.
Độ Chính Xác Khi Xử Lý Bảng: Vì Sao TableFormer Xứng Đáng
Bảng là lý do nhiều người tìm đến Docling thay vì chỉ dùng một công cụ PDF-to-text đơn thuần, nên tôi tạo bảy PDF có bảng với ground truth đọc được bằng máy và chấm kết quả theo từng ô. Có hai chỉ số quan trọng, và chúng không giống nhau: cell recall là tỷ lệ giá trị ground truth xuất hiện ở bất kỳ đâu trong bảng được phát hiện; in-row rate là tỷ lệ giá trị nằm đúng hàng. Gộp hai chỉ số này lại sẽ làm đẹp công cụ một cách giả tạo, nên dưới đây là cả hai:
| Bảng (bài test) | Phát hiện được | Cell recall | In-row rate | Ghi chú |
|---|---|---|---|---|
| T1 lưới có viền đơn giản (5×8), đứng một mình trên trang | Không | 0.0 | — | bị phân loại thành <!-- image -->, mất toàn bộ ô |
| T2 không viền (chỉ có một đường kẻ tiêu đề) | Có | 1.00 | 1.00 | hoàn hảo, đúng lưới |
| T3 tiêu đề colspan 2 tầng có gộp ô | Có | 1.00 | 0.97 | đủ giá trị; một giá trị tiêu đề lệch sang hàng khác |
| T4 rowspan nhãn hàng gộp, đứng một mình trên trang | Không | 0.0 | — | bị phân loại thành <!-- image --> |
| T5 colspan tiêu đề + không viền | Có | 1.00 | 0.97 | đủ giá trị; lệch hàng giống T3 |
| T6 bảng tài chính, có cột trống, căn phải | Có | 1.00 | 1.00 | cột trống vẫn được giữ nguyên, không bị lệch |
| T7 bảng rộng 12 cột | Có | 1.00 | 1.00 | không bị trượt cột trên bảng rộng |
Trong năm bảng Docling phát hiện được, mọi giá trị ground truth đều đi qua — cell recall 1.00 trên toàn bộ. Trong ba bảng trong số đó, mọi giá trị cũng nằm đúng hàng. Ở hai trường hợp có tiêu đề nhiều tầng (T3 và T5), một giá trị tiêu đề bị lệch khỏi hàng gốc, kéo in-row xuống 0.97 — dữ liệu vẫn đủ, chỉ có gán hàng hơi chệch một chút ở phần tiêu đề nhiều lớp.
Các trường hợp cấu trúc khó vẫn ổn hơn tôi kỳ vọng. Tiêu đề colspan hai tầng được làm phẳng đúng sang Markdown kiểu GitHub (nhãn "Q1 2026" lặp lại trên hai cột trải rộng, đây là cách đúng để rút gọn colspan sang GFM). Lưới không viền chỉ có đường kẻ tiêu đề (T2) đi qua chính xác. Bảng rộng 12 cột (T7) không bị lệch. Và một cột tài chính hoàn toàn trống (T6) vẫn được giữ lại thành các ô rỗng thay vì bị bỏ qua hay nén mất. Điều này khớp với điểm TEDS chính thức của TableFormer — 95.4 cho bảng đơn giản, 90.1 cho bảng phức tạp, 93.6 tổng thể — vốn cao hơn đáng kể so với Camelot (73.0) và EDD (88.3).
Cần để ý đến ô gộp, vì có một issue mở nói hơi ngược lại. Issue #3698 báo rằng V1 và V2 xử lý chưa tốt các hàng/cột gộp. Trên bộ test của tôi, colspan đơn giản (T3/T5) và rowspan được làm phẳng đúng, chỉ có hiện tượng lệch hàng ở tiêu đề nhiều tầng như đã nêu. Nhưng các trường hợp lỗi trong #3698 là kiểu gộp nhiều hàng/nhiều cột bất quy tắc và bảng nhiều trang — tức vùng khó nhất. Bộ test của tôi thuộc phía đơn giản. Vì vậy, câu đúng phải nói rất hẹp: colspan và rowspan đơn giản đã được khôi phục đúng ở đây (tiêu đề nhiều tầng vẫn có thể lệch một hàng); còn các kiểu gộp phức tạp và bất quy tắc vẫn là vấn đề mở đã được ghi nhận. Không phải “ô gộp hoạt động hoàn hảo”, cũng không phải “ô gộp hỏng hết”.
Cạm Bẫy: Một Bảng Đứng Một Mình Trên Trang Có Thể Biến Mất
Nhìn lại bảng — T1 và T4 đều không được phát hiện. Docling xuất ra <!-- image --> và bỏ toàn bộ ô, không báo lỗi gì cả. T1 là một lưới 5×8 có viền hoàn toàn bình thường. Điều này đủ đáng lo để tôi không vội kết luận nó yếu ở xử lý bảng; thay vào đó, tôi tách riêng nguyên nhân thật sự bằng một bài test A/B theo script.
Trước hết, tôi loại trừ các nguyên nhân hiển nhiên. Lớp text layer vẫn còn nguyên — pypdfium2 đọc được 327 ký tự từ T1 và 221 ký tự từ T4, nên đây là PDF số thật, không phải ảnh scan. Tắt OCR (do_ocr=False) cũng không giúp gì; bảng vẫn bị bỏ. Và khi kiểm tra trực tiếp DoclingDocument, len(doc.tables) == 0 trong khi len(doc.pictures) == 1 — model bố cục đã phân loại toàn bộ vùng bảng thành một Picture.
Rồi đến bài test quyết định. Tôi render lại đúng T1 và T4, nhưng lần này đặt chúng giữa vài đoạn văn bản bình thường, rồi chuyển đổi lại. Cả hai đều đi qua hoàn hảo: len(doc.tables) == 1, xuất ra bảng GFM đúng chuẩn, và nhãn rowspan "North" trong T4b được lặp đúng qua ba hàng của nó. Cùng một bảng. Biến số duy nhất thay đổi là nó đứng một mình trên một trang quá thưa chữ hay được nhúng trong văn bản.
Vì thế, caveat thực sự không phải là TableFormer yếu, mà là model bố cục RT-DETR của Docling dùng ngữ cảnh trang, và một bảng nhỏ đứng một mình trên một trang gần như trống rất dễ bị đọc thành Picture rồi bị bỏ âm thầm. Điều này rất dễ gặp trong thực tế, vì hóa đơn, spec sheet và các file xuất cắt gọn thường đúng như vậy: mỗi trang một bảng, không có đoạn văn quanh nó. Cách xử lý khá đơn giản và hiệu quả — hãy cung cấp thêm ngữ cảnh cho model bố cục, hoặc kiểm tra hậu xử lý doc.tables sau khi chuyển đổi và đánh dấu những trang có số lượng bằng 0. Điều này gần với issue #3495 (một bảng bị nhận đồng thời là Table và Picture), nhưng đúng riêng cho trigger “trang quá thưa chữ” — cùng một bảng, bị rớt khi đứng cô lập, nhưng lại chuyển đổi được khi có văn bản bao quanh — thì tôi không thấy nơi nào đã công bố trước đó. Đo được, nhưng chưa từng được ghi nhận trước đây; không phải một lỗi chưa ai từng biết.
OCR Trên Tài Liệu Scan Thật: RapidOCR, Không Phải EasyOCR
PDF scan là nơi nhiều bộ chuyển đổi âm thầm thất bại, nên tôi đưa vào Docling hai file scan thật với text layer đo được bằng 0 ký tự — pypdfium2 báo không có ký tự nào khôi phục được, xác nhận rằng mọi đầu ra ở đây là OCR chứ không phải một lớp text ẩn đi kèm.
File một trang ocr_test.pdf được xử lý sạch trong 14.3 giây trên CPU: "Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package," được khôi phục nguyên văn. File bốn trang nemotron_multipage.pdf kích hoạt OCR trên cả bốn trang trong tổng 70.1 giây (17.5 giây/trang), và lặp lại câu test trên từng trang. OCR mặc định tự chạy — không cần cờ, không cần cấu hình.
Chi tiết mà nhiều bài viết hay nói sai là: engine OCR mặc định là RapidOCR, không phải EasyOCR. Tôi xác nhận điều đó bằng cách thấy file trọng số PP-OCRv4 .pth được tải xuống ngay ở lần chạy đầu tiên. Rất nhiều blog và cả tài liệu FAQ cũ của Docling vẫn nói EasyOCR là mặc định; đó là thông tin cũ. EasyOCR giờ chỉ là phần bổ sung tùy chọn. Điều vẫn đúng là: OCR là đường chậm khi mở rộng quy mô, và mọi con số ở đây đều là giới hạn trên khi chỉ dùng CPU — có GPU thì thời gian sẽ giảm đáng kể.
PDF Thật, Thứ Tự Đọc, Và Thời Gian Mỗi Trang
Bộ test tổng hợp chứng minh các hành vi riêng lẻ; còn PDF thật thì chứng minh công cụ này thực sự hoạt động. Tôi chạy hai bài báo học thuật born-digital — báo cáo kỹ thuật Docling 9 trang và bài "Attention Is All You Need" 15 trang, đều bố cục hai cột, có bảng và công thức.
Trên bài Attention dài 15 trang, cả năm mốc phần — Abstract, Introduction, Background, Conclusion, References — đều xuất hiện đúng thứ tự trong tài liệu khi Markdown được tuyến tính hóa, dù bố cục là hai cột. Mọi điểm kiểm tra nội dung (Transformer, encoder, BLEU, multi-head) đều có mặt, và các bảng kết quả đa cột nổi tiếng được ghi nhận là bốn bảng. Đây là khả năng khôi phục đúng thứ tự đọc và gộp cột, chính là giá trị cốt lõi cho RAG chunking — bạn không thể chia nhỏ tài liệu hợp lý nếu bộ linearizer làm rối trang hai cột thành chuỗi nội dung lộn xộn.
Phần thời gian mang đến một bài học hơi ngược trực giác. Thời gian mỗi trang phụ thuộc vào lượng cấu trúc trên từng trang, chứ không chỉ số trang. Báo cáo 9 trang dày đặc chạy ở 14.95 giây/trang — chậm hơn theo từng trang so với bài 15 trang ở 5.99 giây/trang — vì nó có nhiều bảng và hình hơn, và mỗi phần như vậy lại kích hoạt thêm inference cho layout và TableFormer. Vì vậy, “giây trên mỗi trang” trên CPU là hàm của mật độ cấu trúc, không phải độ dài. Đây là một lần chạy đơn trên CPU; nó là mức trần, không phải con số production.
Đa Định Dạng Và Lời Hứa JSON Không Mất Dữ Liệu
Docling quảng bá khả năng phân tích đồng nhất nhiều định dạng, nên tôi tạo một DOCX, một XLSX và một PPTX với nội dung đã biết trước và các probe ground truth, rồi kiểm tra hai thứ: các probe có xuất hiện trong Markdown không, và chúng có sống sót qua vòng JSON khi dùng export_to_dict() hay không.
| Tệp | Thời gian chuyển đổi (s) | Probe tìm thấy trong MD | Số bảng trong MD | Probe còn qua JSON |
|---|---|---|---|---|
report.docx (heading + bảng gộp "Total" + bullet) | 0.137 | 7/7 | 1 | Có |
workbook.xlsx (2 sheet, cột trống) | 0.016 | 6/6 | 2 | Có |
deck.pptx (3 slide, bullet + bảng) | 0.038 | 6/6 | 1 | Có |
Tất cả probe đều xuất hiện trong Markdown, các bảng đều được phục hồi (bao gồm cả hàng "Total" gộp của DOCX và cả hai sheet của XLSX), và mọi probe cũng còn nguyên qua JSON từ export_to_dict() — đây là bằng chứng quan trọng cho lời hứa DoclingDocument không mất dữ liệu, ít nhất trên file sạch. Những định dạng này đi qua backend theo đúng định dạng gốc thay vì model ML, nên chúng chạy trong vài chục mili-giây và hoàn toàn offline. Phạm vi ở đây là trung thực: một file sạch cho mỗi định dạng chứng minh độ rộng, chứ chưa phải một stress test với file Office bệnh lý.
HTML: Trung Thực, Nhưng Không Sạch
Đây là caveat quyết định việc Docling có phù hợp với pipeline RAG của bạn hay không, nên hãy đọc kỹ. Docling chuyển đổi toàn bộ tài liệu HTML. Nó không làm trích xuất nội dung chính kiểu readability. Tôi định lượng mức độ chrome còn sót lại của website bằng cách đếm số dòng đánh dấu nav, mục lục, cookie và footer trong đầu ra của chính Docling.
| Trang | Số dòng MD không trống | Số dòng boilerplate | % boilerplate | Bài viết bắt đầu ở dòng |
|---|---|---|---|---|
| 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% | — |
Trên một trang nhiều chrome như Wikipedia, khoảng 13% số dòng Markdown là boilerplate nav/mục lục/footer, và bài viết thật sự chỉ bắt đầu ở dòng 28 — đầu ra mở bằng "move to sidebar / Contents / Toggle the table of contents" và kết thúc bằng "CS1 maint… / Search Wikipedia." Trên các trang nội dung sạch (books, quotes), mức này gần 0%, nên đây là vấn đề template chrome, không phải một khoản phí bắt buộc cho mọi trang. Docling cho bạn Markdown trung thực của toàn bộ tài liệu, chứ không phải trích riêng bài viết chính sạch sẽ. Upstream đang theo dõi vấn đề về HTML ở issue #1865 (đã đóng) và #1930 (đang mở).
Có hai điểm giúp đánh giá công bằng. Thứ nhất, riêng với HTML, Docling không chạy model ML nào cả — nó dùng backend BeautifulSoup trên một pipeline đơn giản. Câu chuyện “model thị giác đọc trang của bạn” chỉ đúng với PDF và ảnh; nếu đưa HTML vào Docling thì toàn bộ machinery của layout và TableFormer không chạy. Thứ hai, đường xử lý PDF có cố gắng phân loại header và footer, nên nói rằng "không hề loại bỏ boilerplate" sẽ là nói quá — chính backend HTML mới là thứ trả luôn phần chrome.
So Sánh Với Các Công Cụ Khác (Và Thunderbit Nằm Ở Đâu)
Dùng thử Thunderbit để trích xuất dữ liệu web
Công cụ mốc mà người ta hay so Docling với là Firecrawl, nên dưới đây là bảng định vị. Có một lưu ý trước, vì nó rất quan trọng: đây là so sánh ở mức tài liệu, không phải benchmark trên cùng một máy. Tôi không chạy Firecrawl trên bộ test này. Chỉ cột Docling là kết quả đo ở đây; cột Firecrawl lấy từ tài liệu công khai của họ.
| Trục so sánh | Firecrawl (theo tài liệu của họ) | Docling (đo trong bài này) |
|---|---|---|
| Nhiệm vụ cốt lõi | Crawl + scrape web trực tiếp → Markdown | Chuyển tài liệu bạn đã có → Markdown/JSON |
| Fetch / render JS / chống bot | Có (trình duyệt host) | Không — bạn cung cấp sẵn tệp |
| Trích xuất nội dung chính | Có | Không — giữ nguyên toàn bộ tài liệu (~13% chrome trên Wikipedia) |
| Cấu trúc bảng PDF (ML) | Hạn chế | Có — TableFormer (TEDS chính thức 93.6; cell recall 1.00, in-row 0.97–1.00 trên các fixture được phát hiện) |
| PDF scan / OCR | Hạn chế | Có — RapidOCR mặc định (khôi phục được một bản scan 0 text layer) |
| Độ rộng định dạng | Trang web | PDF/DOCX/PPTX/XLSX/HTML/EPUB/hình ảnh |
| Triển khai | API host (+ tự host) | thư viện pip local, offline, không cần API key |
| Mức nặng khi thiết lập | API key / client nhẹ | cài mặc định 1.3 GB + ~506 MiB model (hoặc docling-slim) |
| Giấy phép | thương mại / source-available | MIT |
Tóm gọn một câu: Firecrawl là công cụ nên dùng khi dữ liệu của bạn nằm trên web trực tiếp và cần crawl, render JS, và dọn sạch nội dung chính. Docling là công cụ nên dùng khi bạn đã có tài liệu trong tay — đặc biệt là PDF, bản scan và file Office nhiều bảng — và muốn chuyển đổi trung thực, offline, giữ nguyên cấu trúc, với khả năng hiểu bảng và OCR thật sự. Hai công cụ này bổ trợ cho nhau. Một pipeline thực tế thường dùng một công cụ để crawl và công cụ kia để chuyển tài liệu.
Đến đây tôi nói thẳng về Thunderbit, vì tôi làm ở đây và nếu tôi giả vờ khách quan tuyệt đối thì bạn sẽ nghi ngờ là đúng. Thunderbit và Docling không làm cùng một việc, và tôi sẽ không cố ép chúng thành tương đương. Với developer, Thunderbit là một AI scraping API cộng với MCP server cộng với CLI, và đơn vị công việc của nó là trang web trực tiếp: POST /distill biến một URL thành Markdown sạch, sẵn sàng cho LLM (xử lý luôn render JS, chống bot và CAPTCHA mà Docling không đụng tới), còn POST /extract trả về JSON có cấu trúc khớp schema theo JSON Schema do bạn định nghĩa. Đó là phần fetch-and-clean của một pipeline RAG. Docling là phần xử lý tài liệu local — PDF, bản scan, bảng tính đang nằm trên ổ đĩa của bạn. Nếu nguồn dữ liệu của bạn là web page, hãy dùng Thunderbit API, các công cụ MCP của nó (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract), hoặc CLI (npx @thunderbit/thunderbit-cli). Nếu là PDF và scan, hãy dùng Docling. Nếu là cả hai — mà thực tế phần lớn pipeline đều vậy — hãy ghép chúng lại, và không công cụ nào đang cố làm công việc của công cụ kia.
Kết Luận: Chưa Thể Chấm Điểm Cuối Cùng, Vì Còn Bài Tập Về Nhà
Tôi sẽ không đưa bạn một điểm số 0–100 duy nhất, vì nếu cộng điểm có trọng số ở đây thì sẽ vô tình phạt Docling cho những thứ nó chưa từng hứa làm (như crawling) rồi giả vờ rằng chúng có thể so sánh được. Nếu xét từng khía cạnh trên bộ test tôi đã chạy:
- Thiết lập / lần chạy đầu: nặng — môi trường ảo 1.3 GB, ~506 MiB model, PDF đầu tiên ~224 giây, chạy nóng ~0.55 giây — nhưng
docling-slimcho phép bạn tránh phần nặng đó. - Độ chính xác bảng: mạnh khi bảng đã được phát hiện (cell recall 1.00 trên 5/5, in-row 0.97–1.00), khớp với câu chuyện TEDS chính thức trên bộ test này.
- Độ bền phát hiện bảng: có bẫy trang thưa — một bảng đứng một mình có thể bị rớt thành Picture. Hãy kiểm tra hậu xử lý
doc.tables. - Scan / OCR: hoạt động, mặc định là RapidOCR; chậm khi mở rộng quy mô.
- Đa định dạng: ổn, và vòng JSON vẫn nguyên vẹn.
- HTML: trung thực, không sạch — không trích nội dung chính.
- Trải nghiệm dev: API gọn trong 3 dòng và
DoclingDocumentsạch sẽ, ngoại trừ việc thiếu__version__.
Phù hợp với ai: các team xây dựng RAG hoặc pipeline dữ liệu cho PDF, bản scan và file Office, cần chuyển đổi offline, giữ cấu trúc, hiểu bảng và OCR thật sự. Không phù hợp với ai: những ai cần crawl web trực tiếp hoặc trích nội dung chính HTML sạch — đó là một công cụ khác.
Và vì đây là bài đánh giá chứ không phải thông cáo báo chí, các giới hạn vẫn phải nói rõ. Đây là một bài test có mục tiêu cụ thể — 7 bảng tổng hợp cộng 2 PDF thật trên một máy chỉ dùng CPU — chứ không phải benchmark độ chính xác quy mô TEDS. Có vài thứ tôi chưa test và bạn nên tự kiểm tra trước khi tin Docling cho cả pipeline: đường dẫn VLM tùy chọn (GraniteDocling), footprint thực của docling-slim, bất kỳ run GPU nào, các trường hợp ô gộp phức tạp/bất quy tắc cùng bảng nhiều trang, độ trung thực của công thức sang LaTeX, và — điều dễ gây bất ngờ nhất khi chạy production — bộ ba độ bền gồm tăng bộ nhớ theo batch, khả năng scale theo thread/GIL, và vòng đời object khi xử lý hàng nghìn lượt chuyển đổi. Docling mạnh ở đúng những gì nó tuyên bố, được đo đạc chứ không chỉ quảng bá, và nó vẫn có những góc cạnh thực sự mà bạn nên hiểu rõ trước khi giao cho nó một corpus lớn. Hãy nhớ caveat về trang thưa, dự trù cho lần tải model đầu tiên, và tự kiểm chứng hành vi ở quy mô lớn.
Dùng thử Thunderbit để trích xuất dữ liệu web Get Started Free
Câu Hỏi Thường Gặp
Docling là web scraper hay crawler à?
Không. Docling chuyển đổi các tài liệu bạn đã có — PDF, DOCX, PPTX, XLSX, HTML, hình ảnh — thành Markdown hoặc JSON. Nó không tự lấy URL, không render JavaScript, và cũng không xử lý chống bot. Việc crawl web trực tiếp là việc riêng của các công cụ như Firecrawl hoặc web API của Thunderbit; Docling bắt đầu từ chính tệp bạn đưa vào.
Cài Docling nặng cỡ nào và lần đầu tải về bao nhiêu?
Gói docling mặc định tạo ra một môi trường ảo khoảng 1.3 GB vì nó kéo cả stack ML dưới dạng phụ thuộc cứng (chỉ riêng torch đã 536 MiB). Lần chuyển đổi PDF đầu tiên sẽ tải khoảng 506 MiB model layout và TableFormer vào đĩa, cộng thêm khoảng 40 MB trọng số RapidOCR, và mất khoảng 224 giây — gần như toàn bộ là thời gian tải xuống. Lần chuyển đổi thứ hai chỉ khoảng 0.55 giây. Nếu bạn chỉ cần các định dạng nhẹ, docling-slim (lõi khoảng 50 MB) sẽ bỏ qua đường nặng này.
Docling có OCR không, và dùng engine nào?
Có. Trên PDF scan không có text layer, OCR của Docling tự chạy và trong bài test của tôi đã khôi phục văn bản sạch sẽ. Engine mặc định là RapidOCR, không phải EasyOCR — đây là nhầm lẫn rất phổ biến trong các bài viết cũ. EasyOCR giờ là phần bổ sung tùy chọn. OCR là đường chậm khi mở rộng quy mô, đặc biệt trên CPU.
Vì sao Docling biến bảng của tôi thành ảnh hoặc làm mất nó?
Rất có thể là do hiệu ứng trang quá thưa chữ. Model layout RT-DETR của Docling dùng ngữ cảnh trang, và một bảng nhỏ đứng một mình trên trang gần như trống có thể bị phân loại thành Picture rồi bị bỏ mà không báo lỗi. Cùng một bảng đó nếu đặt trong vùng có văn bản xung quanh thì sẽ chuyển đổi bình thường. Cách khắc phục là cung cấp thêm ngữ cảnh cho model layout, hoặc kiểm tra hậu xử lý doc.tables sau khi chuyển đổi và đánh dấu những trang có số lượng bằng 0.
Docling vs Firecrawl — nên dùng cái nào?
Hai công cụ làm việc khác nhau, nên thường không phải chọn một bỏ một. Firecrawl crawl web trực tiếp, render JavaScript và trích nội dung chính. Docling chuyển đổi tài liệu bạn đã có, với cấu trúc bảng PDF và OCR thật, hoàn toàn offline. Nếu nguồn của bạn là trang web, hãy dùng một công cụ web (Firecrawl, hoặc API/MCP/CLI của Thunderbit). Nếu là PDF, bản scan hoặc file Office, hãy dùng Docling. Trong thực tế, đa số pipeline đều dùng cả hai.
