يتم تصنيف Docling دائمًا جنب أدوات استخراج بيانات الويب، لكنه في الحقيقة ليس كذلك. هو حزمة أدوات لتحويل المستندات من IBM Research — والآن مشروع تابع لـ LF AI & Data Foundation — يأخذ الملفات الموجودة لديك أصلًا (PDF وDOCX وPPTX وXLSX وHTML والصور) ويحوّلها إلى Markdown أو JSON. وشعاره الرسمي حرفيًا: "جهّز مستنداتك للذكاء الاصطناعي التوليدي".
هذه إذن مراجعة عملية لأداة تحويل، وليست لأداة زحف. كل ما ورد أدناه تم قياسه على جهاز واحد يعمل بالمعالج فقط (macOS arm64، Python 3.14.2، Docling 2.111.0)، والنتائج مسجلة عبر سكربتات، مع توثيق حالات الفشل كإخفاقات فعلية. المستودع ضخم ويتغير يوميًا — 63,069 نجمة، و4,449 نسخة متفرعة، وتحديث في اليوم نفسه الذي سحبت فيه البيانات الوصفية — لذلك تعامل مع أي رقم إصدار أو عدد مشكلات هنا على أنه لقطة زمنية، لا حقيقة ثابتة.
ما هو Docling فعليًا، وما ليس كذلك
الوحدة الأساسية في Docling هي DoclingDocument: يُحلَّل الملف إلى هذه البنية، ثم يُصدَّر إلى Markdown أو HTML أو DocTags أو JSON غير فاقد للمعلومات. المشروع مرخّص MIT (مع اختلاف تراخيص النماذج الفردية)، وبدأ في IBM Research Zurich، وحتى لحظة كتابة هذا النص فإن أحدث إصدار هو v2.112.0، وقد نُشر قبل يومين من تنفيذ هذه التجربة.
أهم قدرات الأداة تظهر في مسار PDF والصور. هذا المسار لا يعتمد على تحليل سلاسل نصية، بل على مجموعة من نماذج التعلم الآلي: نموذج تنسيق RT-DETR، ونموذج بنية الجداول TableFormer، ونموذج رؤية-لغة اختياري، وRapidOCR للنسخ الممسوحة ضوئيًا. هذه النماذج تستعيد تخطيط الصفحة، وترتيب القراءة، وبنية الجداول. وهذا هو الجزء الذي يستحق المراجعة، وهو أيضًا الجزء الذي لن يراه اختبار يقتصر على HTML.
هناك فرق واحد يزيل أسبوعًا من الالتباس. Docling لا يجلب أي شيء من الإنترنت. لا يعرض JavaScript، ولا يتجاوز حواجز مكافحة الروبوتات، ولا يزحف عبر المواقع. أنت تجلب الملف، وهو يتولى الفهم. أما الزحف فهذه مهمة أداة أخرى، وهذا يصبح مهمًا لاحقًا عندما يسأل الناس إن كان Docling بديلًا عن Firecrawl (ليس كذلك — فهما متكاملان، وسأوضح السبب).
أول تشغيل لا يحذّرك منه أحد
يتم تثبيت pip install docling بسلاسة على Python 3.14.2. ثم تنظر إلى البيئة الافتراضية، فتجد أنها 1.3 جيجابايت. Docling يسحب كامل حزمة التعلم الآلي كاعتماديات إجبارية حتى لو كان كل ما ستحوله هو ملف 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 واحدًا. أول تحويل لملف PDF هو حيث تبدأ المعاناة الحقيقية، لأنه وقتها يتم تنزيل النماذج. على ذاكرة HuggingFace نظيفة ومعزولة، استغرق أول تحويل لملف PDF حوالي 224 ثانية — وكان معظم ذلك في التنزيل، لا في المعالجة. نماذج التخطيط وTableFormer تشغل حوالي 506 ميجابايت على القرص (342 ميجابايت لـ TableFormer + 164 ميجابايت للتخطيط، بحسب du)، كما يجلب RapidOCR نحو 40 ميجابايت من أوزان PP-OCRv4 إلى site-packages. أما التحويل الثاني لنفس الملف؟ 0.55 ثانية فقط. النماذج تُخزَّن مؤقتًا؛ تدفع الثمن مرة واحدة.
هناك رقم واحد يجب تجاهله: سكربت التشغيل البارد يطبع model_download_mb بقيمة 1060.2. لا تنسب هذا الرقم إلى حجم الحزمة. السبب أنه يعتمد على os.walk الذي يتبع الوصلات الرمزية، بينما تخزن HuggingFace كل ملف نموذج مرة واحدة تحت blobs/ ثم تعيد عرضه عبر وصلة رمزية داخل snapshots/ — لذلك يقوم المسار بعدّ ملفات النماذج الـ 14 مرتين. الرقم الصحيح المطابق لـ du والمستبعد فيه التكرار هو حوالي 506 ميجابايت (والـ blobs وحدها 505.4 ميجابايت). الخلاصة لمن يقيس Docling: افصل بين حجم التنزيل وحجم التخزين على القرص، لأنهما ليسا الشيء نفسه.
وهناك تعقيد ثانٍ يواجه من يبني حاوية Docling. الأوزان تتوزع على موقعين وبجدولين زمنيين مختلفين. نماذج التخطيط وTableFormer تحترم HF_HOME ويتم تنزيلها عند أول تحويل PDF. أما نماذج RapidOCR فلا تفعل ذلك — بل تُحفظ في …/site-packages/rapidocr/models/ متجاوزةً إعدادات ذاكرة التخزين المؤقت تمامًا. إذا كنت تُحضّر صورة مسبقًا أو تعمل في بيئة معزولة عن الشبكة، فعليك التعامل مع كلتا الذاكرتين المؤقتتين، ولا يكفي ضبط HF_HOME لالتقاط الثانية.
والآن الجزء المنصف. منذ الإصدارات السابقة، أصدر المشروع docling-slim — وهو نواة بحجم يقارب 50 ميجابايت تتيح لك pip install docling-slim[format-html] لملفات HTML دون سحب torch. لذلك فإن عبء 1.3 جيجابايت حقيقي بالنسبة لحزمة docling الافتراضية، لكنه الآن اختياري. اختبرت الحزمة الافتراضية لأن هذا هو ما يعطيك إياه pip install docling حتى الآن، لكن الثقل هنا ليس خللًا غير معالج — فالحل المعياري موجود بالفعل، ومُسجّل في المشكلة #2393.
أثناء الإعداد، اصطدمت بعثرة صغيرة تستحق التنويه: import docling; docling.__version__ يُرجع AttributeError: module 'docling' has no attribute '__version__'. الوحدة ببساطة لا تعرض هذا الحقل. الطريقة الصحيحة للتحقق هي importlib.metadata.version("docling")، والتي تُرجع '2.111.0'. إنها ملاحظة بسيطة لكنها مزعجة للمطورين، ومفتوحة في المشروع الأصلي منذ يوليو 2026 تحت المشكلة #3733.
دقة الجداول: حيث يثبت TableFormer أهميته
الجداول هي السبب في أن أي شخص يلجأ إلى Docling بدلًا من مجرد تفريغ PDF إلى نص، لذلك أنشأت سبعة ملفات PDF تحتوي على جداول مع حقيقة مرجعية قابلة للقراءة آليًا، ثم قيّمت المخرجات خليةً بخلية. هناك مقياسان مهمان، وهما ليسا الشيء نفسه: استرجاع الخلايا هو نسبة القيم المرجعية الموجودة في أي مكان داخل الجدول المكتشف؛ ومعدل الوضع في الصف الصحيح هو نسبة القيم التي وصلت إلى الصف الصحيح. الخلط بينهما يجمّل الأداة أكثر من اللازم، لذا إليك المقياسان معًا:
| الجدول (اختبار ضغط) | تم اكتشافه | استرجاع الخلايا | معدل الصف الصحيح | ملاحظة |
|---|---|---|---|---|
| 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، وصلت جميع القيم المرجعية — استرجاع الخلايا 1.00 في كل الحالات. وفي ثلاثة من هذه الخمسة، وصلت كل قيمة أيضًا إلى صفها الصحيح. أما في حالتي الرأس متعدد المستويات (T3 وT5)، فتنزلق قيمة واحدة من الرأس عن صفها الأصلي، فينخفض معدل الصف الصحيح إلى 0.97 — كل البيانات موجودة، لكن تعيين الصف يهتز قليلًا في رؤوس الجداول المكدسة.
حتى الحالات الهيكلية الصعبة صمدت أفضل مما توقعت. رأس colspan ذو المستويين تم تسطيحه بشكل صحيح داخل Markdown بصيغة GitHub (تكرار عنوان "Q1 2026" فوق العمودين الذين يمتد عبرهما هو الأسلوب الصحيح لتحويل colspan إلى GFM). كما أن الشبكة بلا حدود مع خط رأس فقط (T2) خرجت كما هي. والجدول العريض ذو الـ 12 عمودًا (T7) لم يتعرض لانزياح. وحتى العمود المالي الفارغ بالكامل (T6) تم الحفاظ عليه كخلايا فارغة بدلًا من إسقاطه أو دمجه. وهذا يتوافق مع درجات TableFormer الرسمية في TEDS — 95.4 للحالات البسيطة، 90.1 للحالات المعقدة، و93.6 لكل الجداول — وهي نقاط أعلى بوضوح من Camelot (73.0) وEDD (88.3).
ومع ذلك، هناك تحذير مهم بشأن الخلايا المدمجة، لأن هناك مشكلة مفتوحة تقول عكس ذلك. المشكلة #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 — أي أن نموذج التخطيط صنّف منطقة الجدول كلها على أنها صورة.
ثم جاء الاختبار الحاسم. أعدت تقديم الجدولين T1 وT4 نفسيهما، لكن هذه المرة أحيط كل واحد منهما ببضع فقرات عادية من النص، ثم حولتهما مرة أخرى. هذه المرة ظهرا بشكل مثالي: len(doc.tables) == 1، وتم إخراج جداول GFM بشكل صحيح، كما أن وسم rowspan في T4b "North" تكرر بصورة صحيحة عبر صفوفه الثلاثة. نفس الجدول. المتغير الوحيد الذي تغير هو ما إذا كان منفردًا على صفحة sparse أم مدمجًا داخل نص.
إذًا التحذير الحقيقي ليس أن TableFormer هش، بل أن نموذج التخطيط RT-DETR في Docling يعتمد على سياق الصفحة، والجدول الصغير المنفرد على صفحة شبه فارغة قد يُقرأ كصورة ويُهمل بصمت. وهذا أمر سهل الوقوع في الواقع، لأنه يشبه تمامًا ما تبدو عليه الفواتير، وأوراق المواصفات، وعمليات التصدير المقتطعة: جدول واحد في الصفحة، بلا نص محيط. الحل بسيط وفعّال — امنح نموذج التخطيط سياق الصفحة، أو افحص doc.tables بعد التحويل وأبلغ عندما يكون العدد صفرًا. وهذا قريب من المشكلة #3495 (جدول اكتُشف كـ Table وPicture معًا)، لكن المحفز المرتبط بصفحة sparse تحديدًا — نفس الجدول يُسقط عند عزله ويُحوَّل عند دمجه مع النص — لم أجد له توثيقًا منشورًا من قبل. تم قياسه هنا، ولم يكن موثقًا سابقًا؛ ليس خللًا لا يعرفه أحد.
OCR على المسح الحقيقي: RapidOCR، وليس EasyOCR
الملفات الممسوحة ضوئيًا هي المكان الذي تفشل فيه كثير من أدوات التحويل بهدوء، لذلك أجريت اختبارًا على ملفين ممسوحين فعليًا مع طبقة نصية مقاسة = 0 حرف — وpypdfium2 يؤكد صفر أحرف قابلة للاسترجاع، ما يعني أن أي مخرجات هنا ناتجة عن OCR، وليست طبقة نصية مخفية.
الملف الأحادي الصفحة ocr_test.pdf عاد نظيفًا خلال 14.3 ثانية على المعالج: "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 هو المسار الأبطأ على نطاق واسع، وكل ما هنا يمثل حدًا أعلى على المعالج فقط — ولو توفر GPU لانخفضت هذه الأزمنة بشكل ملحوظ.
ملفات PDF الحقيقية، وترتيب القراءة، والزمن لكل صفحة
الاختبارات الاصطناعية تثبت سلوكيات محددة؛ أما ملفات PDF الحقيقية فتثبت أن الشيء يعمل فعلًا. لذلك شغلت ورقتين علميتين رقميتين بالكامل — التقرير التقني من 9 صفحات الخاص بـ Docling، وورقة "Attention Is All You Need" من 15 صفحة، وكلتاهما بتخطيط عمودين مع جداول وصيغ رياضية.
في ورقة Attention ذات الـ 15 صفحة، ظهرت جميع علامات الأقسام الخمس — Abstract، وIntroduction، وBackground، وConclusion، وReferences — بترتيبها داخل المستند في Markdown الخطي، رغم التخطيط ثنائي الأعمدة. وكل نقاط الفحص المحتوى (Transformer، وencoder، وBLEU، وmulti-head) موجودة، كما سُجلت الجداول الشهيرة متعددة الأعمدة كأربعة جداول مكتشفة. هذا استرجاع حقيقي لترتيب القراءة ودمج الأعمدة، وهو جوهر القيمة في تجزئة RAG — لا يمكنك تجزئة مستند بشكل سليم إذا كان المحوِّل الخطي يبعثر صفحة ثنائية الأعمدة إلى فوضى متداخلة.
والتوقيت يحمل درسًا غير بديهي. الزمن لكل صفحة يتحدد بكمية البنية الموجودة في الصفحة، لا بعدد الصفحات. التقرير الأكثر كثافة، المكوّن من 9 صفحات، عمل بمعدل 14.95 ثانية لكل صفحة — أبطأ لكل صفحة من الورقة ذات 15 صفحة التي سجلت 5.99 ثانية لكل صفحة — لأن التقرير يحتوي جداول ورسومات أكثر، وكل واحدة منها تستدعي المزيد من استدلال التخطيط وTableFormer. لذا فـ"الثواني لكل صفحة" على المعالج ليست دالة في طول المستند، بل في كثافة بنيته. وهذا تشغيل واحد على المعالج فقط؛ إنه حد أعلى، لا رقم إنتاجي.
تعدد الصيغ وادعاء JSON غير الفاقد
يعلن Docling عن تحليل موحد متعدد الصيغ، لذلك أنشأت ملف DOCX وملف XLSX وملف PPTX بمحتوى معروف ونقاط فحص مرجعية، ثم تحققت من أمرين: هل تظهر هذه النقاط في Markdown؟ وهل تنجو من رحلة JSON عبر export_to_dict()؟
| الملف | زمن التحويل ث | وجود نقاط الفحص في MD | الجداول في MD | بقاء النقاط في JSON |
|---|---|---|---|---|
report.docx (عناوين + جدول مدمج "Total" + نقاط تعداد) | 0.137 | 7/7 | 1 | نعم |
workbook.xlsx (ورقتان، عمود فارغ) | 0.016 | 6/6 | 2 | نعم |
deck.pptx (3 شرائح، نقاط تعداد + جدول) | 0.038 | 6/6 | 1 | نعم |
كل نقاط الفحص وصلت إلى Markdown، وتم استرجاع الجداول (بما في ذلك صف "Total" المدمج في DOCX وكلا ورقتي XLSX)، كما نجت جميع النقاط أيضًا من JSON الخاص بـ export_to_dict() — وهذا هو الدليل المهم على ادعاء DoclingDocument غير الفاقد للمعلومات، على الأقل مع المدخلات النظيفة. تمر هذه الصيغ عبر خلفيات أصلية للصيغة بدلًا من نماذج ML، ولهذا تعمل خلال عشرات المللي ثانية وتعمل بالكامل دون اتصال. والحدود هنا صادقة: ملف نظيف واحد لكل صيغة يثبت الاتساع، لا اختبار ضغط لملفات Office شاذة.
HTML: دقيق، لكنه ليس نظيفًا
هذا هو التحذير الذي يحدد ما إذا كان Docling مناسبًا لخط RAG لديك، لذا اقرأه بعناية. Docling يحوّل المستند HTML كاملًا. لا يقوم باستخلاص المحتوى الرئيسي بأسلوب readability. وقد قمت بقياس مقدار واجهة الموقع التي تبقى عبر عد أسطر التنقل وفهرس المحتويات وملفات الكوكيز والتذييل في مخرجات Docling نفسها.
| الصفحة | أسطر MD غير الفارغة | أسطر القوالب الثابتة | % القوالب الثابتة | بداية المقال في السطر |
|---|---|---|---|---|
| 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% | — |
في صفحة غنية بالواجهة مثل Wikipedia، حوالي 13% من أسطر Markdown هي تنقل/فهرس/تذييل من القوالب الثابتة، والمقال الحقيقي لا يبدأ إلا عند السطر 28 — إذ يفتح الإخراج بـ "move to sidebar / Contents / Toggle the table of contents" وينتهي بـ "CS1 maint… / Search Wikipedia." أما صفحات المحتوى النظيفة (كتب، اقتباسات) فالنسبة فيها تقارب 0%، لذا فهذه مشكلة واجهة قالبية، لا ضريبة على كل صفحة. Docling يمنحك Markdown أمينًا للمستند كاملًا، لا استخراجًا نظيفًا للمقال الرئيسي. والمشكلة المتعلقة بعناصر HTML الثابتة موثقة في المشكلة #1865 (مغلقة) و#1930 (مفتوحة).
هناك نقطتان تجعل هذا الحكم منصفًا. أولًا، بالنسبة لـ HTML تحديدًا، لا يشغّل Docling أي نماذج ML على الإطلاق — بل يعتمد على BeautifulSoup في خط معالجة بسيط. إذًا قصة "النماذج البصرية تقرأ صفحتك" تنطبق على PDF والصور فقط؛ إذا قدمت HTML إلى Docling فلن تعمل آليات التخطيط أو TableFormer. ثانيًا، مسار PDF يحاول بالفعل تصنيف الترويسات والتذييلات، لذا القول بأنه "لا يوجد أي إزالة للقوالب الثابتة إطلاقًا" سيكون مبالغًا فيه — المسار الذي يعيد الواجهة هو الخلفية الخاصة بـ HTML تحديدًا.
كيف يقارن، وأين يأتي دور Thunderbit
جرّب Thunderbit لاستخراج بيانات الويب
الأداة المرجعية التي يقارن الناس بها Docling هي Firecrawl، لذا إليك جدولًا يوضح التموضع. وهناك تنبيه مهم منذ البداية: هذه مقارنة على مستوى التوثيق، وليست قياسًا على نفس الجهاز. لم أشغّل Firecrawl على هذه العينات. العمود الخاص بـ Docling فقط هو المقاس هنا؛ أما عمود Firecrawl فمن وثائقها العامة.
| المحور | Firecrawl (بحسب وثائقه) | Docling (المقاس هنا) |
|---|---|---|
| المهمة الأساسية | الزحف إلى الويب الحي واستخراج البيانات → Markdown | تحويل مستند تملكه بالفعل → Markdown/JSON |
| الجلب / عرض JS / مكافحة الروبوتات | نعم (متصفح مستضاف) | لا — أنت توفر الملف |
| استخراج المحتوى الرئيسي | نعم | لا — مستند كامل أمين (~13% قوالب ثابتة على Wikipedia) |
| بنية جداول PDF (ML) | محدود | نعم — TableFormer (TEDS الرسمي 93.6؛ استرجاع الخلايا 1.00، ومعدل الصف الصحيح 0.97–1.00 على العينات المكتشفة) |
| PDF الممسوح / OCR | محدود | نعم — RapidOCR افتراضيًا (استعاد مسحًا بلا طبقة نصية) |
| اتساع الصيغ | صفحات ويب | PDF/DOCX/PPTX/XLSX/HTML/EPUB/images |
| النشر | API مستضاف (+ استضافة ذاتية) | مكتبة pip محلية، تعمل دون اتصال، ولا تحتاج مفتاح API |
| وزن الإعداد | مفتاح API / عميل خفيف | تثبيت افتراضي 1.3 جيجابايت + نحو 506 ميجابايت نماذج (أو docling-slim) |
| الترخيص | تجاري / المصدر متاح | MIT |
الخلاصة السريعة: Firecrawl هي الأداة المناسبة عندما تكون بياناتك على الويب الحي وتحتاج إلى الزحف وعرض JavaScript وتنظيف المحتوى الرئيسي. أما Docling فهو الأداة المناسبة عندما يكون المستند بحوزتك بالفعل — خصوصًا ملفات PDF، والمسوحات، وملفات Office المليئة بالجداول — وتريد تحويلًا محليًا يحافظ على البنية ويقدم فهمًا حقيقيًا للجداول وOCR. هما متكاملان. غالبًا ما تكون البنية الواقعية هي الزحف بأحدهما ثم التحويل بالآخر.
وهنا سأكون صريحًا بخصوص Thunderbit لأنني أعمل هنا، وسيكون من حقك الشك لو تظاهرت بغير ذلك. Thunderbit وDocling لا ينجزان المهمة نفسها، ولن أحاول فرض تطابق بينهما. بالنسبة للمطورين، Thunderbit هو واجهة برمجة تطبيقات لاستخراج البيانات بالذكاء الاصطناعي، وخادم MCP، وCLI، ووحدة عمله هي صفحة الويب الحية: فـ POST /distill يحوّل URL إلى Markdown نظيف جاهز للنماذج اللغوية (مع التعامل مع عرض JS، والحواجز المضادة للروبوتات، وCAPTCHA التي لا يقترب منها Docling أصلًا)، بينما POST /extract يعيد JSON منظمًا مطابقًا للبنية التي تعرفها عبر JSON Schema تحددها بنفسك. هذا هو طرف الجلب والتنظيف في خط RAG. أما Docling فهو طرف المستند المحلي — PDF أو المسح أو الجدول البياني الموجود بالفعل على قرصك. إذا كان مستندك من صفحات ويب، فاستعمل Thunderbit API أو أدوات MCP الخاصة به (thunderbit_suggest_fields، thunderbit_distill, thunderbit_extract) أو الـ CLI (npx @thunderbit/thunderbit-cli). وإذا كانت الملفات PDF أو مسحات، فاستعمل Docling. وإذا كان لديك النوعان معًا — وهو الأغلب في التطبيقات الحقيقية — فالأفضل أن تجمعهما، ولا يحاول أي منهما أن يكون الآخر.
الحكم النهائي: مؤقت، وما زال أمامه عمل
لن أعطيك درجة واحدة من 0 إلى 100، لأن جمعًا مرجحًا هنا سيخلط عقوبات على أشياء لم يدّعِ Docling القيام بها أصلًا (مثل الزحف) ويعاملها على أنها متكافئة. وعلى مستوى كل بُعد، وبحسب العينات التي اختبرتها:
- الإعداد / أول تشغيل: ثقيل — بيئة افتراضية 1.3 جيجابايت، ونماذج بحجم ~506 ميجابايت، وأول PDF حوالي ~224 ثانية، ثم ~0.55 ثانية بعد التخزين المؤقت — لكن
docling-slimيتيح لك تجاوز هذا الثقل. - دقة الجداول: قوية عندما يُكتشف الجدول (استرجاع الخلايا 1.00 في 5/5، ومعدل الصف الصحيح 0.97–1.00)، بما يتماشى مع قصة TEDS الرسمية في هذه العينات.
- متانة اكتشاف الجداول: فخ الصفحة sparse — قد يسقط جدول منفرد باعتباره صورة. افحص
doc.tablesبعد التحويل. - المسح/OCR: يعمل، وباستخدام RapidOCR افتراضيًا؛ لكنه بطيء على نطاق واسع.
- تعدد الصيغ: جيد، مع سلامة رحلة JSON.
- HTML: أمين، لكنه ليس نظيفًا — لا يوجد استخراج للمحتوى الرئيسي.
- تجربة المطور: واجهة API نظيفة من ثلاث أسطر و
DoclingDocumentمرتب، مع ملاحظة غياب__version__.
من هو المناسب له: الفرق التي تبني خطوط RAG أو خطوط بيانات فوق PDF أو المسحات أو ملفات Office وتحتاج إلى تحويل محلي يحافظ على البنية ويقدم فهمًا حقيقيًا للجداول وOCR. ولمن ليس مناسبًا: أي شخص يحتاج إلى زحف الويب الحي أو استخراج HTML النظيف للمقال الرئيسي — فهذه مهمة أداة مختلفة.
ولأن هذه مراجعة وليست بيانًا تسويقيًا، فحدود الأداة تبقى كما هي. هذا فحص موجّه — 7 جداول اصطناعية + ملفا PDF حقيقيان على جهاز واحد يعمل بالمعالج فقط — وليس اختبار دقة بحجم TEDS. وهناك أشياء لم أختبرها، ويجب عليك اختبارها قبل أن تراهن بها على خط إنتاج: مسار VLM الاختياري (GraniteDocling)، والحجم الفعلي لـ docling-slim، وأي تشغيل على GPU، والخلايا المدمجة المعقدة وغير المنتظمة والجداول متعددة الصفحات، ودقة تحويل الصيغ إلى LaTeX، والأهم والأكثر احتمالًا لمفاجأتك في الإنتاج — ثلاثية التحمل المتمثلة في نمو ذاكرة الدفعات، وتوسع الأداء مع الخيوط/GIL، ودورة حياة الكائنات عبر آلاف التحويلات. Docling قوي في ما يدّعيه، وقد تم قياسه بدلًا من تلميعه تسويقيًا، لكنه يملك حوافًا حقيقية ستحتاج إلى رسمها قبل أن تثق به مع مجموعة كبيرة من المستندات. اعرف تحذير الصفحة sparse، واحتسب تنزيل التشغيل الأول، وتحقق من السلوك على نطاق واسع بنفسك.
جرّب Thunderbit لاستخراج بيانات الويب Get Started Free
الأسئلة الشائعة
هل Docling أداة زحف أو استخراج من الويب؟ لا. Docling يحوّل المستندات التي لديك بالفعل — PDF وDOCX وPPTX وXLSX وHTML والصور — إلى Markdown أو JSON. لا يجلب الروابط، ولا يعرض JavaScript، ولا يتعامل مع مكافحة الروبوتات. الزحف إلى الويب الحي مهمة منفصلة تتولاها أدوات مثل Firecrawl أو واجهة Thunderbit للويب؛ أما Docling فيبدأ من الملف الذي توفره.
ما حجم تثبيت Docling والتنزيل عند أول تشغيل؟
حزمة docling الافتراضية تنتج بيئة افتراضية بحجم يقارب 1.3 جيجابايت لأنها تسحب كامل حزمة ML كاعتماديات إجبارية (torch وحده 536 ميجابايت). أول تحويل PDF ينزل نحو 506 ميجابايت من نماذج التخطيط وTableFormer إلى القرص، بالإضافة إلى نحو 40 ميجابايت من أوزان RapidOCR، ويستغرق حوالي 224 ثانية — ومعظم هذا الوقت تنزيل. أما التحويل الثاني فيقارب 0.55 ثانية. وإذا كنت تحتاج فقط إلى الصيغ الخفيفة، فإن docling-slim (نواة بحوالي 50 ميجابايت) يتجنب المسار الثقيل.
هل يقوم Docling بـ OCR، وبأي محرك؟ نعم. على ملف PDF ممسوح بلا طبقة نصية، يعمل OCR في Docling تلقائيًا، وقد استعاد النص بوضوح في اختباري. المحرك الافتراضي هو RapidOCR، وليس EasyOCR — وهذا خطأ شائع في الشروحات القديمة. EasyOCR أصبح الآن إضافة اختيارية. OCR هو المسار الأبطأ على نطاق واسع، خصوصًا على المعالج.
لماذا حوّل Docling جدولي إلى صورة أو أسقطه؟
الأرجح هو تأثير الصفحة sparse. نموذج التخطيط RT-DETR في Docling يعتمد على سياق الصفحة، ولذلك قد يُصنّف الجدول الصغير المنفرد على صفحة شبه فارغة كصورة ثم يسقطه دون خطأ. الجدول نفسه إذا أحيط بنص عادي يتحول بشكل سليم. الحل هو تزويد نموذج التخطيط بسياق الصفحة، أو فحص doc.tables بعد التحويل والإبلاغ عن أي صفحة يكون فيها العدد صفرًا.
Docling مقابل Firecrawl — أيهما أستخدم؟ المهمتان مختلفتان، لذا غالبًا ليس الأمر اختيارًا بين أحدهما والآخر. Firecrawl يزحف إلى الويب الحي، ويعرض JavaScript، ويستخرج المحتوى الرئيسي. Docling يحوّل المستندات التي لديك بالفعل، مع فهم حقيقي لبنية جداول PDF وOCR، وبشكل محلي تمامًا. إذا كان المصدر صفحات ويب، فاستعمل أداة ويب (Firecrawl أو Thunderbit API/MCP/CLI). وإذا كانت ملفات PDF أو المسحات أو ملفات Office، فاستعمل Docling. في كثير من خطوط الإنتاج الواقعية، ستستخدمهما معًا.
