المستخرج الذي سرّب أكثر الحشو التمهيدي لم يفوّت أي محتوى في مجموعة الاختبار هذه

ست مكتبات، مجموعة اختبار موثقة بعلامات، ومقيّم واحد. في هذه العينات الاصطناعية الـ22، كانت المكتبة الأعلى تسريبًا للحشو التمهيدي — Readability من Mozilla بنسبة 23.5% — هي أيضًا الوحيدة التي استرجعت كل وحدة مقال موسومة.

هذه هي المقايضة في جملة واحدة، ومعظم المقالات حول هذا الموضوع لا تظهرها أبدًا، لأنها تكتفي بقياس الدقة وتتوقف عند ذلك.

ما الذي تم قياسه فعليًا

كل عينة في هذه المجموعة تحمل حقيقة مرجعية على مستوى الوحدة. كل جزء من الصفحة — فقرات المقال، شريط التنقل، الإعلان، الشريط الجانبي، سلاسل التعليقات، والعرض الترويجي — موسوم إما article أو boilerplate ومرفق برمز مميز فريد. لذا فإن سؤال "هل استعاد المستخرج هذه الوحدة؟" يُحسم بمطابقة نصية دقيقة، لا بدرجة تشابه. إما أن يبقى الرمز المميز في الناتج أو لا.

22 عينة، 91 وحدة. ستة مستخرجات: Mozilla Readability الإصدار 0.6.0 (عبر jsdom 30.0.1)، trafilatura 2.2.0، resiliparse 1.0.9، newspaper4k 0.9.6، goose3 3.1.22، وjusText 3.0.2. تم تشغيل Python 3.14.2 وNode 22 على الجهاز نفسه. لا يحتفظ المقال بنظام التشغيل/المعالج، أو أوامر التشغيل الدقيقة، أو عدد التكرارات، أو سياسة الإحماء، لذا فإن عمود الزمن هنا ملاحظة محلية لا معيارًا قابلًا للنقل.

فرضت على نفسي قاعدتين قبل بدء أي تشغيل. كل مكتبة Python ثُبّتت داخل بيئة افتراضية فارغة خاصة بها، بحيث يكون حجمها خاصًا بها لا موروثًا من حزم ثبّتها جارها. ولا يوجد أي مشغّل يحسب المقياس — كل واحد يخرج النص الخام فقط، والمقيّم الواحد ينتج كل الأرقام، بحيث تُقارن الأدوات الست بالحساب نفسه بدل ستة تعريفات متشابهة ظاهريًا لـ"الدقة".

جدول العنوان

يُجمَّع الاسترجاع عبر العينات الـ22 كلها. أما معدل التسريب ودقة رموز المحتوى الإجمالية والتلوث فتُحسب على 11 عينة تحتوي كلتَيهما: وحدات المقال ووحدات الحشو التمهيدي؛ و"المُجابة" توضح كم عينة من هذه العينات أخرجت ناتجًا. الأرقام الكاملة لكل عينة موجودة في sixway-scores.json.

هناك صف واحد في هذا الجدول ليس على الوضع الافتراضي. دالة extract_plain_text في resiliparse تستخدم main_content=False افتراضيًا، وقد استدعيتها هنا مع main_content=True. والفرق ليس بسيطًا: عند الوضع الافتراضي تُسرّب 17 من 17 وحدة حشو تمهيدي عبر المجموعة كلها — كل شريط تنقل، وكل إعلان، وكل شريط جانبي، وكل سلسلة تعليقات، وكل عرض ترويجي — مقابل 1 من 17 عند تفعيل الخيار. أما بقية المكتبات أعلاه فقد استُدعيت بإعداداتها الافتراضية. لذا فإن معدل تسريب resiliparse البالغ 0.0588 هو سلوكه عندما تطلب المحتوى الرئيسي، بينما extract_plain_text(html) وحدها منتج مختلف (default-vs-main-content.json).

اقرأ العمود الأول مع الثاني معًا، لأن قراءة أي واحد منهما وحده ستقودك إلى الأداة الخطأ.

Readability لا يفوّت أبدًا. استرجاع كامل في كل العينات الـ22، وهو الوحيد الذي حقق ذلك. لكنه يدفع ثمن ذلك: تسربت 4 من 17 وحدة حشو تمهيدي، و35 رمزًا ملوثًا، أي أربعة أضعاف معدل تسريب trafilatura. ثلاث من هذه التسريبات الأربع لها الشكل نفسه — كتلة ترويجية محايدة الفئة تجاور المقال، فتبتلعها قاعدة ضمّ العناصر الشقيقة. إذا مرّرت ناتجه إلى نموذج، فأنت تدفع ثمن تلك الرموز والنموذج يقرأها على أنها من المقال.

newspaper4k هو الخيار الأكثر توازنًا. لا تسريب، ولا رموز ملوِّثة، واسترجاع 0.9865، وإخراج في جميع العينات الـ22. لو كان عليّ اختيار واحد دون معرفة طبيعة العمل، فهذا هو، وليس هو الخيار الذي يلجأ إليه معظم الناس.

goose3 يحقق دقة مثالية لكنه أسوأ استرجاع في الاختبار. كل كلمة محتوى أعادها كانت فعلًا من المقال. لكنه لم يسترجع شيئًا إطلاقًا في عينتين، ولم يُخرج أي نص في هاتين العينتين نفسيهما. الدقة المثالية رخيصة إذا كان بإمكانك الامتناع عن الإجابة.

الرقم المتعلق بالدقة الذي أنصف مكتبتين أكثر من اللازم

هذه النقطة تستحق أن تُقال بوضوح، لأنها فخ كدت أنشره بنفسي.

الدقة وF1 هنا مشروطتان بوجود ناتج. المكتبة التي تعيد سلسلة فارغة في عينة ما لا تضيف شيئًا إلى البسط ولا إلى المقام — لذا فإن الامتناع مجاني، وتبدو دقة المستخرج المتحفظ أفضل من دقة المستخرج الشامل لمجرد الصمت.

دقة goose3 الإجمالية كانت 1.0000 عبر 10 عينات من أصل 11 في مجموعة الدقة/الجودة التي أخرجت فيها ناتجًا. أما jusText فكانت 0.8760 عبر 10 من 11. وقد أجابت Readability وtrafilatura وresiliparse وnewspaper4k على 11 من 11. أصبح الجدول الآن يعرض هذا المقام بجانب الدقة حتى لا يختبئ الامتناع خلف نسبة مغرية.

كانت هناك نسخة أسوأ من هذا الخطأ. أول مقيّم لي كان يحسب متوسط استرجاع المقال على نفس مجموعة الـ11 عينة الخاصة بجودة المحتوى — وهي المجموعة التي تستبعد العينات التي لا تحتوي على حشو تمهيدي، وهذا صحيح عند قياس التسريب. وقد أظهر resiliparse عندها استرجاعًا 1.0000. لكن عند حسابه على العينات الـ22 كلها، يهبط resiliparse إلى 0.9054، لأن العينة التي يعيش مقالها بالكامل داخل عناصر <li> من دون أي <p>، يعيد فيها ناتجًا ويسترجع 0 من 6 وحدات مقال. هذه العينة لا تحتوي حشوًا تمهيديًا، لذا خرجت من المتوسط، واختبأت فشلٌ حقيقي خلف درجة مثالية.

أين يتعطل كل واحد فعليًا

كل حالة من هذه الحالات سلوك محدد قابل لإعادة الإنتاج، وليس مجرد "أسوأ في الاستخراج":

• resiliparse وgoose3 يفترضان وجود فقرات. إذا وجهت أحدهما إلى صفحة يكون جسمها قائمة — سجل تغييرات، مواصفات، أسئلة شائعة، وصفة — فإن resiliparse يعيد نصًا خاليًا من محتوى القائمة، بينما goose3 يعيد لا شيء. resiliparse هو الأخطر هنا، لأن إرجاع شيء ما يبدو نجاحًا.
• jusText لديه حاجز طول، وهو حاد. المزيد عن ذلك أدناه.
• المستند شبه الفارغ هو الحالة الوحيدة التي قد يكون فيها عدم الإرجاع صحيحًا، لذلك لا أعتبر ذلك ضد أي من المكتبتين.

jusText: حاجز حاد، لا منحدر

أخرج jusText ناتجًا في 19 من 22 عينة وسرّب 47% من الحشو التمهيدي — الأعلى في الاختبار، وهو عكس سمعته. لكن الرقم المثير للاهتمام هو الرقم الذي جعلني أعيد كل شيء من البداية.

يصنّف jusText كل كتلة بحسب كثافة الكلمات الشائعة مقابل قائمة توقف لغوية، ثم يجري تمريرة واعية بالسياق ترفع كتلة neargood إلى good فقط عندما تكون بجوار كتلة good موجودة بالفعل. ولا تصل الكتلة إلى good بمفردها إلا إذا تجاوزت length_high، وهو افتراضيًا 200 حرف. في مستند لا تتجاوز فيه أي فقرة هذا الحد، لا يوجد ما يبدأ عملية الرفع، فتنهار الصفحة كلها إلى حشو تمهيدي.

اختبرته على مستند أطول فقرة فيه 151 حرفًا:

من صفر إلى 832 حرفًا عندما تتجاوز فقرة واحدة العتبة فقط، ثم لا يتغير شيء مهما خففتها أكثر. فقرة واحدة فوق الخط تفتح المستند كله.

وقبل أن أصل إلى هذا الاستنتاج، اختبرت length_low عبر أربع قيم وmax_link_density عبر قيمتين — ثمانية تراكيب، كلها أعطت صفرًا. وقاعدة هذا المشروع تقول إن ادعاء القدرة السلبية يحتاج إلى اختبار ثلاثة أنماط معامِلات على الأقل، أو وجود رسالة خطأ من البائع نفسه تسمي الحقل، ومعامل واحد غير مثمر ليس نتيجة عن المكتبة. الأرقام موجودة في justext-length-threshold.json.

ولا شيء من هذا يعني أن jusText سيئ في الاستخراج. على صفحة حقيقية ذات لغة طبيعية وبالإعدادات الافتراضية، أعاد 1,190 حرفًا من نص مقال نظيف. ما يعنيه هو أن لدى jusText مقبضًا موثقًا يتصرف كمفتاح تشغيل/إيقاف، وأن موضعه الافتراضي غير مناسب للصفحات ذات الفقرات القصيرة.

ما الذي تثبته، وما تكلفة استيراده

نفس العينات، نفس الجهاز، وكل مكتبة في بيئة افتراضية فارغة خاصة بها.

في هذه الجولة، كان resiliparse الأقل في الاستيراد البارد وفي وسيط زمن الاستخراج: 15 مللي ثانية و0.06 مللي ثانية. لكن نسب المقارنة الدقيقة عبر وقتي التشغيل ستبالغ في ما يمكن أن يدعمه البروتوكول غير المكتمل، خصوصًا لأن أبطأ عملية استخراج مفردة بلغت 1,098 مللي ثانية. نحتاج توزيعات منفصلة لزمن الإقلاع، وأول استدعاء، والاستقرار قبل استخدام هذه الأرقام لتحديد حجم بيئات serverless.

trafilatura وresiliparse متعادلان تقريبًا من حيث الجودة — 0.9697 مقابل 0.9681 في F1 لرموز المحتوى، وبمعدل تسريب متطابق 0.0588 — ولا يمكنني إعلان فائز على فارق صغير إلى هذا الحد. لكن من حيث الحجم فهما ليسا قريبين: 21.0 MiB مقابل 69.9 MiB، و5 حزم مقابل 17. المقايضة الحقيقية هنا هي بين عمى resiliparse تجاه القوائم وبين ثلاثة متطلبات إضافية في trafilatura.

خطآن في بيئة الاختبار الخاصة بي، اكتُشفا قبل النشر

المقارنة أعلاه كادت ألا تتم أصلًا، والسبب يستحق أكثر من أي صف منفرد فيها.

مجموعة الاختبار الأصلية لم تكن ترى اثنتين من المكتبات الست. العينات الأولى كانت تكتب كل وحدة كسلسلة من رموز هرائية فريدة — zzart01vf64 zzart01v56i — وهذا ما يجعل الاسترجاع دقيقًا. لكنه يعني أيضًا أن العينات لا تحتوي أي كلمات وظيفية إنجليزية. Readability وtrafilatura وresiliparse يقرران بنيويًا من DOM، لذا لم يتأثروا. أما goose3 وjusText فيقرران لغويًا بعدّ كلمات التوقف، ولم يكن هناك شيء يُعدّ: كلاهما أعاد سلسلة فارغة في جميع العينات الـ22.

كان جدولًا يعطي صفريْن لمكتبتين ويبدو موثوقًا بينما هو بلا معنى. تحققت قبل أن أكتب ذلك، على صفحة حقيقية: goose3 أعاد 1,017 حرفًا وjusText 1,190. المكتبتان كانتا سليمتين. بيئة الاختبار هي التي لم تكن تمثلها.

لذلك أُعيد بناء العينات بنثر إنجليزي يحمل الرموز المميزة — نفس البنية، نفس الفئات، نفس مواقع DOM، نفس حدود الوحدات، نفس الرموز، مع استبدال 1,568 رمزًا واحدًا مقابل واحد. goose3 انتقل من 0 إلى 20 من 22.

ثم كسر إعادة البناء شيئين من جهتها، وكلاهما كان من صنع يدي. الكلمة الإنجليزية في المتوسط نحو ستة أحرف؛ أما zzart01vf64 فنحو 12 حرفًا. استبدال واحد مقابل واحد خفّض طول كل وحدة إلى النصف — 21,646 حرفًا من نص الوحدات أصبحت 10,986، وأطول وحدة هبطت من 1,513 إلى 622. وهذا أعاد كتابة العينات التي كان الغرض منها كله قياس الطول دون أن أشعر. jusText، الذي يتصرف على هيئة حاجز طول، انتقل من 19 من 22 إلى 6 من 22 بسبب ذلك وحده. لو نشرت النسخة المصفوفة إلى النصف، لكانت قيمة jusText خاطئة بثلاثة أضعاف، وباتجاه يجعله يبدو مكتبة أسوأ.

والثاني: جلب كل وحدة من corpus مشترك واحد أعاد كثافة الكلمات الشائعة، لكنه دمّر الخاصية التي يعتمد عليها قياس مستوى الرمز. يجب أن تكون معاجم المقال والحشو التمهيدي منفصلة، وإلا فإن "الرموز المستخرجة التي هي رموز حشو تمهيدي" ستعد كلمة the. انتهى الأمر بعشر من 22 عينة إلى معاجم متداخلة، مقابل صفر في النسخة الأصلية. الحل كان إضافة لاحقة لكلمات المحتوى حسب كل وحدة وترك الكلمات الوظيفية كما هي — كلمات توقف حقيقية للمكتبات اللغوية كي تعدّها، ومعجم محتوى منفصل للمقيّم.

ولهذا أيضًا سميت أعمدة المستوى النصي هنا content_token_* ولم يُعاد استخدامها من أرقام Readability مقابل trafilatura المنشورة. إنها كمية مختلفة، تُقاس على كلمات المحتوى فقط، واعتبار واحدة مكان الأخرى سيكون خطأ.

وأثناء إعادة البناء، ظهر شيء ثالث لم يكن مني: ثلاث عينات خاصة بكثافة الروابط تضع </a> داخل كلمة — <a href="/x">zzsibp015qlhf zzsi</a>bp015qbht — لأن الرابط وُضع بإزاحة حرفية للوصول إلى نسبة دقيقة. النص المعروض لم يتغير، لذا لم يلاحظ ذلك التقييم الأصلي، لكن أي مستخرج يعمل على مستوى العنصر بدل مستوى السلسلة النصية يرى شظيتين حيث يرى الآخرون كلمة واحدة. تم إصلاحه، مع تسجيل فرق الأحرف المرتبطة بدلًا من ابتلاعه بصمت.

من الذي ينبغي أن يستخدم ماذا

هل تغذي نموذجًا وتدفع مقابل كل رمز؟ newspaper4k أو goose3. كلاهما لم يسرّب أي وحدة حشو تمهيدي ولا أي رمز ملوث. newspaper4k إذا أردت جوابًا على كل صفحة؛ goose3 إذا كنت تفضّل الصمت على التخمين، وكانت صفحاتك تحتوي فقرات.

هل تحاول تحسين مسار Python حساس للزمن؟ أدرج resiliparse في المقارنة. لقد سجّل هنا أقل زمن استيراد وأدنى وسيط للاستخراج، وقارب trafilatura في الجودة — لكن فقط مع main_content=True، وليس افتراضيًا. افحص أولًا التصاميم كثيرة القوائم، ولا تحوّل هذه الأزمنة المحلية إلى نسبة سرعة دقيقة عبر بيئات تشغيل مختلفة.

هل تقوم بالأرشفة، أو أي حالة يكون فيها ضياع المحتوى أسوأ من الزيادة؟ اختر Readability. إنه الوحيد الذي استعاد كل وحدة مقال في جميع العينات، و35 رمزًا شاذًا ثمن زهيد إذا كان البديل هو فقدان فقرة.

هل العمل متعدد اللغات؟ يمكن أن يكون jusText مرشحًا للدراسة لأنه يأتي مع قوائم توقف لغوية. لكن هذه الدراسة لم تختبر الاستخراج متعدد اللغات، لذا فهذه ميزة تدفعك لتقييمه، لا دليلًا على أنه الأفضل. اختبر length_high مقابل أطوال فقرات ممثلة.

هل المحتوى ليس مقالًا أصلًا؟ لا شيء من هذه الأدوات مناسب لذلك. كلها مبنية على افتراض أن الصفحة تحتوي على جسم رئيسي واحد من النثر، وأي قائمة منتجات أو صفحة نتائج بحث أو لوحة تحكم تكسر هذا الافتراض بطرق لا يصلحها أي معامل.

أين تناسب واجهة API مُدارة

كل ما سبق عبارة عن مكتبات تشغلها بنفسك: أنت تقدم HTML وتستلم نصًا. أنماط فشلها المرصودة تختلف بحسب شكل الصفحة، لذا اختبر الإعدادات الافتراضية المختارة على corpus الخاص بك. أما استخراج الحقول المنظمة وجلب الصفحات/عرضها فخارج هذه المقارنة.

ملاحظة المؤلف: Thunderbit هي خدمتنا المُدارة لسير العمل الذي يبدأ من URL ويُخرج بيانات منظمة. لم تُشغل عبر هذه العينات، لذا لا يوجد أي تلميح إلى مقارنة في الجودة. الحد الفاصل المهم هو: هل لديك أصلًا HTML وتريد مستخرج نص محلي، أم تريد الجلب/العرض والعمليات أن تُدار كخدمة؟

الصياغة الصادقة: إذا كان لديك HTML وتريد نصًا، فأحد هذه الستة مجاني وجيد، وهذا الجدول يخبرك أيها. أما إذا كنت تجلب صفحات على نطاق واسع، أو تريد صفوفًا بدل النثر، فهذه صفقة مختلفة.

إذا كنت تختار بين خدمات الجلب المستضافة بدلًا من ذلك، فمقالنا عن أفضل واجهات Web Scraping API يغطي هذا المجال، ومقالنا عن مقارنة تكلفة واجهات SEO وواجهات البيانات يشرح ما تتقاضاه. أما من جهة الحلول ذاتية الاستضافة، فمقال الدليل الشامل لمستخرجات البيانات مفتوحة المصدر يقدم الصورة الأوسع، وإذا كان ما تحتاجه فعلًا هو Markdown بدل النص العادي، فمقال تحويل HTML إلى Markdown في Python هو المكان الذي يحدث فيه معظم الفقد.

جرّب Thunderbit لاستخراج بيانات الويب

الحكم النهائي

لا يوجد فائز، وأي جدول يدّعي وجود فائز هنا سيكون كاذبًا بشأن مقايضة حقيقية.

أنشئ corpus قبول صغيرًا قبل الاختيار: ضمّن مقالات قائمة فقط، وفقرات قصيرة، وعناصر ترويجية مجاورة، وصفحة شبه فارغة، وأمثلة يكون فيها عدم الإرجاع أفضل من التلوث. قيّم استرجاع المقال، وتسريب الحشو التمهيدي، والامتناع عن الإجابة كلٌ على حدة. في هذه العينات، فضّلت Readability الاسترجاع، وكان newspaper4k الأكثر توازنًا، وكان resiliparse مرشحًا للزمن المنخفض مع نقطة عمياء تجاه محتوى القوائم؛ وهذه الأوصاف لا ينبغي أن تُنقل خارج الأشكال المختبرة من دون تحقق.

والأدق مما سبق كله هو هذا: اختبر هذه العينات على أشكال صفحاتك أنت قبل أن تختار. اثنتان من الستة لم تستطيعا رؤية بيئة الاختبار التي بدأت بها، وإحداهما سجّلت استرجاعًا مثاليًا أخفى فشلًا كاملًا. جدول المقارنة نقطة بداية لذلك، لا بديل عنه.

جرّب Thunderbit لاستخراج بيانات الويب Get Started Free

الأسئلة الشائعة

هل هذه الأرقام قابلة للمقارنة مع المعايير المنشورة لهذه المكتبات؟ لا، ولن أنقلها بهذه الطريقة. هذه عينات مضبوطة بوحدات اصطناعية لكنها موسومة، لذا رأت المكتبات الست البِتّات نفسها، والمقارنة بينها عادلة. الأرقام المنشورة مثل معيار scrapinghub لاستخراج المقالات تستخدم corpora حقيقية من العالم الواقعي، وهي تقيس شيئًا مختلفًا وأصعب. استخدم هذا الجدول لمقارنة هذه الستة ببعضها، لا بمقياس من ورقة بحثية.

لماذا معدل تسريب Readability أعلى كثيرًا من trafilatura إذا كان كلاهما يعتمدان على DOM؟ بسبب المكان الذي يرسم فيه كل واحد الحدود. ثلاث من تسريبات Readability الأربع هي كتل ترويجية محايدة الفئة تقع كأشقاء للمقال، وتضمّها قاعدة ضم الأشقاء لديه انطلاقًا من فكرة أن المحتوى الطويل منخفض الارتباط المجاور غالبًا جزء من القصة. وغالبًا يكون كذلك. أما في هذه العينات فهو عرض ترويجي. trafilatura أشد صرامة فيما يضيفه، وقد سرّبت وحدة واحدة من الوحدات نفسها.

هل ينبغي أن أثق بأرقام الدقة الخاصة بـ goose3 وjusText؟ فقط مع عدد العينات بجانبها. كلاهما حُسب على 10 من 11 عينة تحتوي على وحدات مقال ووحدات حشو تمهيدي، لأنهما أعادا لا شيء في إحدى العينات، والعينة التي لا تنتج أي خرج لا تضيف شيئًا إلى أي طرف من النسبة. دقة goose3 البالغة 1.0000 حقيقية للصفحات التي أجاب عنها؛ أما استرجاعه 0.8243 عبر كل العينات الـ22 فهو النصف الآخر من الحقيقة نفسها.

هل تهم عتبة الطول في jusText على الصفحات الحقيقية؟ الأمر يعتمد بالكامل على أطوال فقراتك. مقالة إخبارية بفقرات طولها 300 حرف ستتجاوز length_high من أول فقرة وتتصرف بشكل طبيعي — ولهذا أعاد jusText 1,190 حرفًا نظيفًا في صفحة حقيقية بالإعدادات الافتراضية. أما صفحة فيها فقرات قصيرة أو عناصر قائمة أو وصف منتجات، فقد لا تتجاوزها أبدًا، وعندها يعيد jusText سلسلة فارغة بدل جواب جزئي. اضبطه صراحة بدل أن تكتشف ذلك في الإنتاج.

ما الذي لم يُختبر هنا؟ الصفحات الواقعية فعلًا، بكل أنواعها. الاستخراج متعدد اللغات، رغم أن قوائم التوقف هي ميزة jusText الأساسية. الذاكرة تحت الضغط. أي صفحة ليست مقالًا — لا قوائم منتجات، لا نتائج بحث، لا لوحات تحكم. حالات الترميز الطرفية. كما أن منظومتي Node وPython قورنتا من حيث سلوك المكتبة لا من حيث أداء وقت التشغيل، لذا ينبغي قراءة أرقام المللي ثانية عبر ذلك الحد على أنها مراتب تقريبية لا نسبًا دقيقة.