ביקורת על Docling: מה ממיר המסמכים ל-Markdown של IBM באמת עושה ל‑PDFים שלכם

Docling ממשיך להופיע לצד Web Scrapers, אבל הוא בכלל לא כזה. מדובר בערכת כלים להמרת מסמכים מבית IBM Research — וכיום פרויקט של LF AI & Data Foundation — שלוקחת קבצים שכבר יש לכם (PDF, DOCX, PPTX, XLSX, HTML, תמונות) וממירה אותם ל‑Markdown או ל‑JSON. אפילו הסלוגן שלו הוא ממש: "Get your documents ready for gen AI."

אז זו סקירה מעשית של ממיר מסמכים, לא של סורק אתרים. כל מה שמתואר כאן נמדד על מכונה אחת עם CPU בלבד (macOS arm64, Python 3.14.2, Docling 2.111.0), עם ניקוד על סמך סקריפטים ותיעוד של כל כשל ככשל. הריפוזיטורי עצום ומתעדכן מדי יום — 63,069 כוכבים, 4,449 forks, ו־push באותו יום שבו שלפתי את המטא־דאטה — לכן כדאי להתייחס לכל מספר גרסה או ספירת תקלות כאן כאל תמונת מצב נקודתית, לא כאל קבוע.

מה Docling כן, ומה הוא לא

היחידה הבסיסית של Docling היא DoclingDocument: מנתחים קובץ לתוך המבנה הזה, ואז מייצאים ממנו Markdown, HTML, DocTags או JSON ללא אובדן. הקוד ברישיון MIT (רישיונות המודלים עצמם משתנים), הוא נולד ב‑IBM Research Zurich, ונכון לכתיבת שורות אלו הגרסה האחרונה היא v2.112.0, שפורסמה יומיים לפני שבדקתי.

היכולת המרכזית היא עיבוד PDF ותמונות. זה לא ניתוח מחרוזות — אלא שכבה של מודלי למידת מכונה: מודל פריסה מסוג RT-DETR, מודל מבנה טבלאות TableFormer, מודל חזון-שפה אופציונלי, ו‑RapidOCR עבור סריקות. המודלים האלה משחזרים את פריסת העמוד, סדר הקריאה ומבנה הטבלאות. זה החלק ששווה לבדוק, וזה גם חלק שבדיקה של HTML בלבד לעולם לא תראה.

יש הבחנה אחת שחוסכת שבוע של בלבול: Docling לא מביא שום דבר מהרשת. הוא לא מרנדר JavaScript, לא עובר מחסומי anti-bot, ולא מבצע crawling. אתם מביאים את הקובץ; הוא מבין אותו. סריקה של אתרים היא עבודה של כלי אחר, וזה חשוב בהמשך כששואלים אם Docling מחליף את Firecrawl (התשובה היא לא — הם משלימים זה את זה, ואסביר למה).

ההרצה הראשונה שאף אחד לא מזהיר מפניה

pip install docling מצליח בצורה נקייה על Python 3.14.2. ואז פותחים את ה‑venv, ורואים שהוא 1.3 GB. Docling מושך את כל סטאק ה‑ML כתלות קשיחה, גם אם כל מה שאתם עושים הוא המרת קובץ HTML:

תלות	גודל על הדיסק (MiB, du)
torch (2.13.0)	536
opencv (cv2)	119
transformers (5.8.1)	101
scipy	99
sympy	76
pandas	72
rapidocr (+ models מובנים)	75.6
docling_parse	30

וזה עוד לפני שהמרתם אפילו PDF אחד. ההמרה הראשונה של PDF היא המקום שבו מתחיל החיכוך האמיתי, כי אז המודלים יורדים. במטמון HuggingFace חדש ומבודד, ההמרה הראשונה של PDF לקחה בערך 224 שניות — וכמעט הכול היה הורדה, לא חישוב. מודלי הפריסה יחד עם TableFormer תופסים כ־506 MiB על הדיסק (342 MiB ל‑TableFormer + 164 MiB לפריסה, אומת באמצעות du), ו‑RapidOCR מוריד כ־40 MB של משקלי PP-OCRv4 אל site-packages. ההמרה השנייה של אותו קובץ? 0.55 שניות. המודלים נשמרים במטמון; את המחיר משלמים פעם אחת.

יש מספר אחד שכדאי להתעלם ממנו: סקריפט ה‑coldstart מדפיס model_download_mb של 1060.2. אל תצטטו את זה כטביעת הרגל האמיתית. זה נובע מ‑os.walk שעוקב אחרי symlinks, וממטמון HuggingFace ששומר כל קובץ מודל פעם אחת תחת blobs/ ואז חושף אותו מחדש כ‑symlink בתוך snapshots/ — כך שהסריקה סופרת את 14 קבצי המודל פעמיים. הערך שתואם ל‑du, ומנוקה מכפילות symlink, הוא כ־506 MiB (רק blobs: 505.4 MiB). המסקנה לכל מי שמבצע benchmark ל‑Docling: צריך לדווח בנפרד על נפח ההורדה ועל הנפח על הדיסק, כי אלה שני דברים שונים.

יש עוד סיבוך שפוגע בכל מי שבונה קונטיינר ל‑Docling. המשקלים מפוצלים לשני מיקומים ובשני לוחות זמנים. מודלי הפריסה ו‑TableFormer מכבדים את HF_HOME ויורדים בהמרה הראשונה של PDF. המודלים של RapidOCR לא — הם נוחתים ב־…/site-packages/rapidocr/models/, בלי קשר להגדרות המטמון שלכם. אם אתם אורזים מראש image או עובדים בלי חיבור לרשת, תצטרכו לטפל בשני המטמונים, ושום הגדרה של HF_HOME לא תתפוס את השני.

ועכשיו לחלק ההוגן. מאז הגרסאות המוקדמות של Docling, הפרויקט שחרר את docling-slim — ליבה קלה של כ־50 MB שמאפשרת pip install docling-slim[format-html] עבור HTML בלי לגרור את torch. לכן משקל של 1.3 GB הוא אמיתי עבור חבילת docling המלאה, אבל כיום אפשר להימנע ממנו. בדקתי את החבילה המלאה כי זה עדיין מה שמתקבל מ‑pip install docling, אבל הכבדות הזו היא לא פגם שלא טופל — הפתרון המודולרי כבר קיים, ומתועד ב־issue #2393.

במהלך ההתקנה נתקלתי בבעיה קטנה ששווה לציין: import docling; docling.__version__ זורק AttributeError: module 'docling' has no attribute '__version__'. המודול פשוט לא חושף את זה. הדרך שעובדת היא importlib.metadata.version("docling"), שמחזירה '2.111.0'. זו טינה קטנה לחוויית המפתח, שפתוחה מול המעלה מאז יולי 2026 כ־issue #3733.

דיוק בטבלאות: איפה TableFormer באמת מצדיק את עצמו

טבלאות הן הסיבה שאנשים בכלל פונים ל‑Docling ולא ל‑PDF-to-text פשוט, אז יצרתי שבעה קובצי PDF עם טבלאות ונתוני אמת קריאים למכונה, ודירגתי את הפלט תא אחר תא. שני מדדים חשובים, והם לא אותו דבר: cell recall הוא החלק מערכי האמת שהופיעו איפשהו בטבלה שזוהתה; in-row rate הוא החלק שנחת בשורה הנכונה. ערבוב בין השניים מחמיא לכלי יותר מדי, אז הנה שניהם:

טבלה (עומס)	זוהתה	Cell recall	In-row rate	הערה
T1 רשת ממוסגרת פשוטה (5×8), לבד בעמוד	לא	0.0	—	סווג כ-<!-- image -->, כל התאים אבדו
T2 ללא גבולות (רק קו כותרת)	כן	1.00	1.00	מושלם, רשת מדויקת
T3 כותרת משולבת עם colspan דו-שכבתי	כן	1.00	0.97	כל הערכים נמצאו; ערך כותרת אחד קופץ שורה
T4 שורת תווית עם rowspan משולב, לבד בעמוד	לא	0.0	—	סווג כ-<!-- image -->
T5 כותרת colspan + ללא גבולות	כן	1.00	0.97	כל הערכים נמצאו; אותה קפיצה לשורת כותרת כמו ב-T3
T6 נתונים פיננסיים, עמודה ריקה, מיושר לימין	כן	1.00	1.00	העמודה הריקה נשמרה, לא הוזזה
T7 רשת רחבה של 12 עמודות	כן	1.00	1.00	אין הסטת עמודות בטבלה רחבה

מבין חמש הטבלאות ש‑Docling זיהה, כל ערך אמת עבר — cell recall של 1.00 בכל הלוח. בשלוש מתוך חמש, כל ערך גם נחת בשורה הנכונה שלו. בשני מקרי הכותרת הרב-שכבתית (T3 ו‑T5), ערך כותרת אחד גולש מהשורה המקורית שלו, ולכן ה‑in-row יורד ל‑0.97 — כל הנתונים קיימים, רק שיוך השורה מתנדנד בשורה אחת בכותרת רב-שכבתית.

המקרים המבניים הקשים עמדו טוב יותר ממה שציפיתי. כותרת colspan דו-שכבתית השטחה נכון ל‑GitHub-flavored Markdown (התווית "Q1 2026" חזרה על עצמה מעל שתי העמודות שלה, וזה בדיוק האופן הנכון להשטחת colspan ב‑GFM). הרשת ללא גבולות עם קו כותרת בלבד (T2) עברה בדיוק. הטבלה הרחבה של 12 עמודות (T7) לא הוזזה. ועמודה פיננסית ריקה לחלוטין (T6) נשמרה כתאים ריקים במקום להימחק או להתמזג. זה תואם ל‑ציוני TEDS הרשמיים של TableFormer — 95.4 פשוט, 90.1 מורכב, 93.6 לכל הטבלאות — שה‑model card של המודל מציג מעל Camelot (73.0) ו‑EDD (88.3).

מילת זהירות לגבי תאים ממוזגים, כי יש issue פתוח שמספר את ההפך. Issue #3698 מדווח ש‑V1 ו‑V2 מטפלות לא טוב בשורות ועמודות ממוזגות. על סט הקבצים שלי, colspan פשוט (T3/T5) וערכי rowspan הושטחו נכון, מלבד הסטת השורה בכותרת הרב-שכבתית שציינתי למעלה. אבל מקרי הכשל ב‑#3698 הם מיזוגים לא סדירים של כמה שורות/עמודות וטבלאות רב-עמודיות — הקצה הפתולוגי. אצלי אלה המקרים הפשוטים. לכן הניסוח המדויק צריך להיות מצומצם: colspan ו‑rowspan פשוטים שוחזרו כאן בהצלחה (כותרות רב-שכבתיות יכולות להזיז שורה); מיזוגים מורכבים ולא סדירים עדיין מהווים בעיה פתוחה ומתועדת. לא "תאים ממוזגים עובדים", ולא "תאים ממוזגים שבורים."

המלכודת: טבלה לבד על עמוד יכולה להיעלם

חזרו לטבלה — T1 ו‑T4 בכלל לא זוהו. Docling הפיק <!-- image --> וזרק כל תא, בלי שגיאה. T1 היא רשת ממוסגרת רגילה לחלוטין של 5×8. זה מדאיג מספיק כדי שלא אקרא לזה חולשה בניתוח טבלאות לפני שאבין מה באמת הפעיל את זה, אז בניתי בדיקת A/B מסקריפט.

קודם כל שללתי את ההסברים הברורים. שכבת הטקסט קיימת — pypdfium2 קורא 327 תווים מ‑T1 ו‑221 מ‑T4, כך שמדובר ב‑PDF דיגיטלי אמיתי, לא בתמונה סרוקה. כיבוי OCR (do_ocr=False) לא עוזר; הטבלאות עדיין נופלות. ובבדיקה ישירה של DoclingDocument, ‎len(doc.tables) == 0 בעוד len(doc.pictures) == 1 — מודל הפריסה סיווג את אזור הטבלה כולו כ‑Picture.

ואז הגיע המבחן המכריע. רינדרתי מחדש את אותן טבלאות T1 ו‑T4, אבל הפעם כשסביבן כמה פסקאות טקסט רגילות, והמרתי שוב. שתיהן עברו בצורה מושלמת: ‎len(doc.tables) == 1, הופקה טבלת GFM תקינה, וב‑T4b תווית ה‑rowspan "North" חזרה נכון על פני שלוש השורות שלה. אותה טבלה. המשתנה היחיד שהשתנה היה אם היא עמדה לבד על עמוד דליל או הייתה משולבת בתוך טקסט.

לכן האזהרה האמיתית היא לא ש‑TableFormer שביר — אלא שמודל הפריסה RT-DETR של Docling נשען על הקשר העמוד, וטבלה קטנה שעומדת לבד בעמוד כמעט ריק עלולה להיות מזוהה כ‑Picture ולהישמט בשקט. קל להיתקל בזה בפועל, כי בדיוק ככה נראים חשבוניות, דפי מפרט וייצואי crop: טבלה אחת לעמוד, בלי פרוזה מסביב. הפתרון משעמם אבל יעיל — לתת למודל הפריסה יותר הקשר בעמוד, או לבדוק לאחר ההמרה את doc.tables ולסמן עמודים שבהם הספירה היא אפס. זה קרוב ל‑issue #3495 (טבלה שזוהתה גם כ‑Table וגם כ‑Picture), אבל הטריגר הספציפי של דלילות העמוד — אותה טבלה, נעלמת כשהיא מבודדת, עוברת כשהיא משולבת — לא מצאתי מתועד בשום מקום. נמדד, ולא היה מתועד קודם; לא באג שאף אחד לא הכיר.

OCR על סריקות אמיתיות: RapidOCR, לא EasyOCR

PDFים סרוקים הם המקום שבו הרבה ממירים נכשלים בשקט, אז הזנתי ל‑Docling שתי סריקות אמיתיות עם שכבת טקסט שנמדדה כ‑0 תווים — pypdfium2 מחזיר אפס תווים שניתן לשחזר, מה שמאשר שכל פלט הוא OCR ולא שכבת טקסט נסתרת שמסתתרת בפנים.

הקובץ 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 שניות לעמוד), עם המשפט החוזר בכל עמוד. ה‑OCR המובנה פעל אוטומטית — בלי דגל, בלי הגדרה.

הפרט שרוב הכתבות טועות בו הוא זה: מנוע ה‑OCR המוגדר כברירת מחדל הוא RapidOCR, לא EasyOCR. אימתתי זאת בכך שצפיתי במשקלי PP-OCRv4 מסוג .pth יורדים בהרצה הראשונה. הרבה בלוגים קיימים וטקסט FAQ ישן של Docling עדיין אומרים ש‑EasyOCR הוא ברירת המחדל; זה כבר לא נכון. EasyOCR הוא עכשיו תוסף שבוחרים בו במפורש. האזהרה שעדיין נכונה: OCR הוא הנתיב האיטי בקנה מידה גדול, וכל מה שנמדד כאן הוא תקרת ביצועים על CPU בלבד — GPU יקצר את הזמנים האלה באופן משמעותי.

PDFים אמיתיים, סדר קריאה וזמן לעמוד

קבצי בדיקה סינתטיים מוכיחים התנהגויות נקודתיות; PDFים אמיתיים מוכיחים שהדבר באמת עובד. הרצתי שני מאמרים אקדמיים born-digital — דוח הטכני של Docling בן 9 העמודים ו‑"Attention Is All You Need" בן 15 העמודים, שניהם דו-עמודתיים עם טבלאות ונוסחאות.

במאמר Attention בן 15 העמודים, כל חמשת סמני הסעיפים — Abstract, Introduction, Background, Conclusion, References — מופיעים בסדר המסמך ב‑Markdown הליניארי, למרות הפריסה הדו-עמודתית. כל נקודת בדיקה של תוכן (Transformer, encoder, BLEU, multi-head) קיימת, וטבלאות התוצאות המרובות המפורסמות מזוהות כארבע טבלאות. זהו שחזור אמיתי של סדר קריאה ומיזוג עמודות, וזה ערך הליבה עבור chunking של RAG — אי אפשר לחתוך מסמך בצורה הגיונית אם הליניאריזר מערבב עמוד דו-עמודי לבלגן משולב.

המדידה מלמדת משהו קצת מפתיע. הזמן לכל עמוד נקבע לפי כמה מבנה יש בכל עמוד, לא לפי מספר העמודים. הדוח הצפוף בן 9 העמודים רץ ב‑14.95 שניות לעמוד — איטי יותר לעמוד מהמאמר בן 15 העמודים שעמד על 5.99 שניות לעמוד — כי יש בו יותר טבלאות ותרשימים, וכל אחד מהם מפעיל עוד אינפרנס של פריסה ו‑TableFormer. כלומר "שניות לעמוד" ב‑CPU הן פונקציה של צפיפות מבנית, לא של אורך. זו הרצה אחת על CPU בלבד; זו תקרת ביצועים, לא מספר ייצור.

תמיכה בריבוי פורמטים ולטענת ה‑JSON ללא אובדן

Docling מציג ניתוח מאוחד למספר פורמטים, אז יצרתי DOCX, XLSX ו‑PPTX עם תוכן מוכר ונקודות בדיקה של אמת, ואז בדקתי שני דברים: האם הנקודות מופיעות ב‑Markdown, והאם הן שורדות את ה‑round-trip ל‑JSON דרך export_to_dict().

קובץ	זמן המרה (שניות)	נמצאו נקודות בדיקה ב-MD	טבלאות ב-MD	נקודות שורדות ב-JSON
report.docx (כותרות + טבלת "Total" ממוזגת + bullets)	0.137	7/7	1	כן
workbook.xlsx (2 גיליונות, עמודה ריקה)	0.016	6/6	2	כן
deck.pptx (3 שקופיות, bullets + טבלה)	0.038	6/6	1	כן

כל נקודות הבדיקה הגיעו ל‑Markdown, הטבלאות שוחזרו (כולל שורת "Total" הממוזגת ב‑DOCX ושני הגיליונות של ה‑XLSX), וכל נקודה גם שרדה ב‑JSON של export_to_dict() — וזו הראיה שחשובה לטענת ה‑DoclingDocument ללא אובדן, לפחות על קבצים נקיים. הפורמטים האלה עוברים דרך backends שמקורם בפורמט עצמו ולא דרך מודלי ML, ולכן הם רצים בעשרות מילישניות ופועלים לגמרי offline. ההיקף כאן הוגן: קובץ נקי אחד לכל פורמט מוכיח רוחב, לא מבחן עומס לקבצי Office פתולוגיים.

HTML: נאמן, אבל לא נקי

זו ההסתייגות שקובעת אם Docling שייך לשרשרת ה‑RAG שלכם, אז כדאי לקרוא בזהירות. Docling ממיר את כל מסמך ה‑HTML. הוא לא מבצע חילוץ תוכן ראשי בסגנון readability. מדדתי כמה רכיבי chrome של האתר נשמרים על ידי ספירת שורות ניווט, תוכן עניינים, cookies ו־footer בפלט של Docling עצמו.

עמוד	שורות MD לא ריקות	שורות boilerplate	% 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 הן boilerplate של ניווט/תוכן עניינים/פוטר, והמאמר האמיתי לא מתחיל עד שורה 28 — הפלט נפתח עם "move to sidebar / Contents / Toggle the table of contents" ומסתיים ב־"CS1 maint… / Search Wikipedia." בעמודי תוכן נקיים (books, quotes) זה בערך 0%, כך שזו בעיית chrome של תבנית, לא מס על כל עמוד. Docling נותן לכם Markdown נאמן לכל המסמך, לא חילוץ נקי של המאמר המרכזי. במעלה הרים עוקבים אחר בעיית ריהוט ה‑HTML ב‑issue #1865 (סגור) ו‑#1930 (פתוח).

שני דברים שומרים על הוגנות. ראשית, ב‑HTML Docling לא מפעיל שום מודל ML בכלל — זה backend של BeautifulSoup בצנרת פשוטה. הסיפור על "מודלי ראייה שקוראים את העמוד שלכם" נכון רק ל‑PDF ותמונות; אם מאכילים את Docling ב‑HTML, אף אחת ממערכות הפריסה או TableFormer לא נכנסת לפעולה. שנית, נתיב ה‑PDF כן מנסה לסווג header ו‑footer כ‑furniture, כך שטענה של "אין שום הסרת boilerplate" תהיה חזקה מדי — זה ה‑HTML backend, במיוחד, שמחזיר את ה‑chrome.

איך הוא עומד מול אחרים (ואיפה Thunderbit נכנס)

נסו את Thunderbit לחילוץ נתונים מהאינטרנט

הכלי שהכי משווים ל‑Docling הוא Firecrawl, אז הנה טבלת מיצוב. הסתייגות אחת מראש, כי היא חשובה: זו השוואה ברמת תיעוד, לא benchmark על אותה מכונה. לא הרצתי את Firecrawl על הקבצים האלה. רק עמודת Docling נמדדה כאן; עמודת Firecrawl מבוססת על התיעוד הציבורי שלו.

ציר	Firecrawl (לפי התיעוד שלו)	Docling (נמדד כאן)
משימה עיקרית	crawl + scrape של הרשת החיה → Markdown	המרת מסמך שכבר יש לכם → Markdown/JSON
הבאה / רינדור JS / anti-bot	כן (דפדפן מנוהל)	לא — אתם מספקים את הקובץ
חילוץ תוכן ראשי	כן	לא — מסמך מלא ונאמן (~13% chrome ב-Wikipedia)
מבנה טבלאות ב-PDF (ML)	מוגבל	כן — TableFormer (TEDS רשמי 93.6; cell recall 1.00, in-row 0.97–1.00 על הקבצים שנבדקו)
PDF סרוק / OCR	מוגבל	כן — RapidOCR כברירת מחדל (שיחזר סריקה עם 0 תווי טקסט)
רוחב פורמטים	דפי אינטרנט	PDF/DOCX/PPTX/XLSX/HTML/EPUB/תמונות
פריסה	API מתארח (+ self-host)	ספריית pip מקומית, offline, בלי API key
משקל התקנה	API key / לקוח קל	התקנה מלאה של 1.3 GB + כ־506 MiB מודלים (או docling-slim)
רישיון	מסחרי / source-available	MIT

הגרסה הקצרה: Firecrawl הוא הכלי כשמקור הנתונים שלכם נמצא ברשת החיה וצריך crawling, רינדור JS וניקוי תוכן ראשי. Docling הוא הכלי כשכבר יש לכם את המסמך — במיוחד PDFים, סריקות וקבצי Office עתירי טבלאות — ואתם רוצים המרה נאמנה, offline, ששומרת על המבנה ומבינה באמת טבלאות ו‑OCR. הם משלימים זה את זה. צינור עבודה ריאלי יגלוש ברשת עם האחד וימיר מסמכים עם השני.

ומכאן אהיה כן לגבי Thunderbit, כי אני עובד כאן, והייתם צודקים לחשוד אם הייתי מעמיד פנים אחרת. Thunderbit ו‑Docling לא עושים את אותה עבודה, ואני לא מתכוון לכפות ביניהם שקילות. עבור מפתחים, Thunderbit הוא גם API ל‑AI scraping, גם שרת MCP וגם CLI, ויחידת העבודה שלו היא דף האינטרנט החי: POST /distill הופך URL ל‑Markdown נקי ומוכן ל‑LLM (תוך טיפול ברינדור JS, anti-bot ו‑CAPTCHA ש‑Docling במפורש לא נוגע בהם), ו‑POST /extract מחזיר JSON מובנה שתואם לסכמה שאתם מגדירים. זה צד ה‑fetch-and-clean של צינור RAG. Docling הוא הצד של מסמכים מקומיים — ה‑PDF, הסריקה, הגיליון שכבר יושב על הדיסק שלכם. אם הקורפוס שלכם הוא דפי אינטרנט, פנו ל‑API של Thunderbit, לכלי MCP שלו (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract), או ל‑CLI (npx @thunderbit/thunderbit-cli). אם זה PDFים וסריקות, פנו ל‑Docling. ואם זה שניהם — מה שקורה ברוב הצינורות האמיתיים — משתמשים בשניהם ביחד, ואף אחד מהם לא מנסה להיות השני.

פסק הדין: זמני, ויש עוד שיעורי בית

אני לא הולך לתת כאן ציון אחד מ־0 עד 100, כי סכום משוקלל כזה יכניס קנסות על דברים ש‑Docling מעולם לא טען שיעשה (כמו crawling) ויתייחס אליהם כאילו הם בני השוואה. לפי כל ממד, על הקבצים שבדקתי:

• התקנה / ריצה ראשונה: כבד — venv של 1.3 GB, כ־506 MiB מודלים, כ־224 שניות ל‑PDF הראשון, כ־0.55 שניות בריצה חמה — אבל docling-slim מאפשר להימנע מהמשקל הזה.
• דיוק טבלאות: חזק כשהטבלה מזוהה (cell recall 1.00 ב‑5/5, in-row 0.97–1.00), תואם את סיפור ה‑TEDS הרשמי בקבצים האלה.
• חוסן בזיהוי טבלאות: מלכודת העמוד הדליל — טבלה מבודדת יכולה להיעלם כ‑Picture. צריך לבדוק אחר כך את doc.tables.
• סריקות / OCR: עובד, RapidOCR כברירת מחדל; איטי בקנה מידה גדול.
• ריבוי פורמטים: יציב, עם round-trip תקין ל‑JSON.
• HTML: נאמן, לא נקי — בלי חילוץ תוכן ראשי.
• חוויית מפתח: API נקי של 3 שורות ו‑DoclingDocument מסודר, פרט להעדר __version__.

למי זה מתאים: צוותים שבונים RAG או צינורות נתונים מעל PDFים, סריקות וקבצי Office ורוצים המרה offline ששומרת על המבנה והבנה אמיתית של טבלאות ו‑OCR. למי זה לא מתאים: כל מי שצריך crawling של הרשת החיה או חילוץ נקי של מאמר ראשי מ‑HTML — זה כלי אחר.

ומכיוון שזו סקירה ולא הודעת יח״צ, המגבלות נשארות על התווית. זו בדיקה ממוקדת — 7 טבלאות סינתטיות ו‑2 PDFים אמיתיים על מכונה אחת עם CPU בלבד — לא benchmark ברמת TEDS. יש כמה דברים שלא בדקתי ואתם כן צריכים לבדוק לפני שאתם בונים צינור סביב Docling: הנתיב האופציונלי של VLM (GraniteDocling), טביעת הרגל האמיתית של docling-slim, כל ריצה על GPU, תאים ממוזגים מורכבים ולא סדירים יחד עם טבלאות רב-עמודיות, נאמנות המרה של נוסחאות ל‑LaTeX, — והדבר שהכי סביר שיפתיע אתכם בייצור — שלישיית החוסן של גידול זיכרון אצווה, scaling של thread/GIL, ומחזור חיי אובייקטים לאורך אלפי המרות. Docling חזק במה שהוא טוען לעשות, בצורה שנמדדה ולא רק שווקה, ויש לו גם קצוות אמיתיים שכדאי למפות לפני שסומכים עליו עם קורפוס. תכירו את אזהרת העמוד הדליל, תתקצבו את ההורדה של הריצה הראשונה, ותבדקו בעצמכם את ההתנהגות בקנה מידה גדול.

נסו את Thunderbit לחילוץ נתונים מהאינטרנט Get Started Free

שאלות נפוצות

האם Docling הוא Web Scraper או Crawler? לא. Docling ממיר מסמכים שכבר יש לכם — PDF, DOCX, PPTX, XLSX, HTML, תמונות — ל‑Markdown או ל‑JSON. הוא לא מביא URLים, לא מרנדר JavaScript ולא מטפל ב‑anti-bot. crawling של הרשת החיה הוא תפקיד נפרד, שמבוצע על ידי כלים כמו Firecrawl או ה‑web API של Thunderbit; Docling מתחיל מהקובץ שאתם מספקים.

כמה גדול ההתקנה של Docling וההורדה בריצה הראשונה? חבילת docling המלאה מייצרת venv של כ־1.3 GB כי היא מושכת את כל סטאק ה‑ML כתלות קשיחה (torch לבדו הוא 536 MiB). ההמרה הראשונה של PDF מורידה כ־506 MiB של מודלי פריסה ו‑TableFormer לדיסק ועוד כ־40 MB של משקלי RapidOCR, ולוקחת בערך 224 שניות — כמעט כולן זמן הורדה. ההמרה השנייה היא כ‑0.55 שניות. אם אתם צריכים רק פורמטים קלים, docling-slim (ליבה של כ־50 MB) מדלג על הנתיב הכבד.

האם Docling עושה OCR, ועם איזה מנוע? כן. ב‑PDF סרוק בלי שכבת טקסט, ה‑OCR של Docling מופעל אוטומטית, ובבדיקה שלי הוא שחזר את הטקסט בצורה נקייה. מנוע ברירת המחדל הוא RapidOCR, לא EasyOCR — טעות נפוצה בכתבות ישנות. EasyOCR הוא כיום תוסף אופציונלי. OCR הוא הנתיב האיטי בקנה מידה גדול, במיוחד על CPU.

למה Docling הפך את הטבלה שלי לתמונה או פשוט זרק אותה? כנראה אפקט העמוד הדליל. מודל הפריסה RT-DETR של Docling משתמש בהקשר של העמוד, וטבלה קטנה שעומדת לבדה על עמוד כמעט ריק יכולה להיות מסווגת כ‑Picture ולהיעלם בלי שגיאה. אותה טבלה, כשיש סביבה טקסט גוף, עוברת מצוין. הפתרון הוא לתת למודל הפריסה הקשר עמוד, או לבדוק לאחר ההמרה את doc.tables ולסמן כל עמוד שבו הספירה היא אפס.

Docling מול Firecrawl — במה לבחור? אלו עבודות שונות, כך שבדרך כלל זו לא בחירה של או-או. Firecrawl סורק את הרשת החיה, מרנדר JavaScript ומחלץ תוכן ראשי. Docling ממיר מסמכים שכבר יש לכם, עם מבנה טבלאות PDF ו‑OCR אמיתיים, לגמרי offline. אם המקור הוא דפי אינטרנט, השתמשו בכלי רשת (Firecrawl, או API/MCP/CLI של Thunderbit). אם אלו PDFים, סריקות או קבצי Office, השתמשו ב‑Docling. ברוב הצינורות האמיתיים משתמשים בשניהם.