LlamaIndex ParseBench: كيف تختبر تحليل المستندات عبر Python وHugging Face

LlamaIndex ParseBench منصة جاهزة لاختبار مدى جودة تحليل النماذج وأنظمة OCR لمستندات PDF. ويعرض دليل عملي جديد كيف تبني بلغة Python خط عمل أساسيًا: تحميل مجموعة البيانات من Hugging Face، وتحويلها إلى بنية موحّدة، ومقارنة جودة استخراج النص.

كيف يعمل ParseBench

يبدأ الدليل بتحميل مجموعة البيانات llamaindex/ParseBench مباشرة من Hugging Face. يُجهَّز في الكود أولًا بيئة عمل بلغة Python، وتُضاف مكتبات datasets وpandas وmatplotlib وPyMuPDF وRapidFuzz، ثم يُستعرَض محتوى المستودع الذي يضم ملفات JSONL وملفات PDF. وتبدو هذه المجموعة على Hugging Face جادة بالفعل: نحو 169 ألف سطر موزعة على عدة أنواع من المهام. وهذا مهم لأن ParseBench لا يخزّن النصوص وحدها، بل سيناريوهات متنوعة يلزم فيها مراعاة الجداول والمخططات وموضع العناصر على الصفحة.

• text_content — المصفوفة الرئيسية من الأمثلة
• text_formatting — مهام تتعلق بالبنية والتنسيق
• table — استخراج البيانات الجدولية
• chart — التعرّف على القيم في الرسوم البيانية
• layout — العمل مع الموضع المكاني للكتل

بعد ذلك تُفرَد جميع البنى المتداخلة في جدول مسطّح. تبدو هذه الخطوة تفصيلًا تقنيًا، لكنها تتيح رؤية التغطية حسب الأعمدة، والعثور سريعًا على الحقول التي تحمل مسارات PDF والنص المرجعي وقواعد التحقق وإحداثيات layout. وعمليًا يتحول ParseBench من مجموعة ملفات إلى مصفوفة تحليلية عاملة، يمكن عبرها تشغيل baseline ومقارنة محلّلات مختلفة، واختيار الأمثلة المناسبة لاختبار OCR وتلك الأنسب للنماذج التي تحتاج إلى فهم بصري للصفحة. وهكذا تبدو مجموعة البيانات نفسها كمعيار اختبار (benchmark) متكامل، لا كمجموعة مستندات عشوائية.

التقييم الأساسي للجودة

الخطوة التالية هي بناء baseline خفيف دون أي تعقيد. في المثال يحاول الكود، لكل سجل، العثور على ملف PDF المرتبط به، وتنزيله من Hugging Face، واستخراج نص الصفحات الأولى عبر PyMuPDF. ثم يبحث عن حقل مرجعي مناسب، مثل expected أو target أو reference أو markdown أو answer، ويقارن النتيجة بالنص المستخرج. وتُستخدم في القياس مقارنة token set similarity من RapidFuzz: ليست درجة مثالية أكاديميًا، لكنها كافية لفهم سريع للمواضع التي يعمل فيها المحلّل البسيط بشكل مقبول والمواضع التي ينهار فيها.

إضافة إلى similarity_score الواحد، يحفظ خط العمل حالات خدمية وخصائص أساسية لكل مثال. فإذا لم يُعثر على ملف PDF، يُوسَم السجل بشكل منفصل. وإذا لم يكن للسطر مرجع، فلا يدخل في التقييم الكامل. أما إذا سار كل شيء بنجاح، فيمكن رسم توزيع الدرجات ومعاينة متوسط النتيجة عبر أبعاد مختلفة لمجموعة البيانات. ويكشف هذا النهج فورًا نقاط ضعف baseline: فاستخراج النص ممكن نسبيًا ببساطة، أما بنية الجداول والقيم على الرسوم البيانية والتخطيط الدقيق فتتطلب غالبًا نماذج OCR أو vision-language أقوى.

التحضير للنماذج

لا ينتهي الدليل عند baseline. فبعد التقييم الأولي تُبنى من البيانات نفسها موجّهات (prompts) لأنظمة التحليل الخارجية، من محركات OCR إلى نماذج VLM. يُدرَج في القالب بُعد مجموعة البيانات وتلميح من حقل rule ومعاينة للإجابة المرجعية، ثم يُطلب إعادة النتيجة بعدة صيغ: تمثيل markdown للمستند، والجداول بصيغة JSON، وقيم الرسوم البيانية بصيغة JSON، وملاحظات حول layout حيثما تكون البنية البصرية للصفحة مهمة.

وهذا جسر جيد بين استخراج النص التقليدي والمهام التي ينبغي فيها أن يصبح المستند صالحًا لسيناريوهات الوكلاء (agents). وفي الختام يقارن الدليل أفضل الحالات وأسوأها بحسب similarity، ويحفظ ملف CSV مسطّحًا بالأمثلة، ويترك عمليًا نقطة انطلاق جاهزة للتجارب. أي أن ParseBench يعمل هنا لا كمجموعة بيانات للاطلاع فحسب، بل كبيئة عمل متكاملة لمقارنة المحلّلات وضبط المقاييس وتحضير المدخلات للجيل القادم من document AI.

ماذا يعني ذلك

يجعل LlamaIndex ParseBench تقييم تحليل المستندات (document parsing) أكثر عملية بوضوح. فبدلًا من العروض التجريبية المجردة، يمكن للفريق أن يتحقق سريعًا من أداء منظومته مع النصوص والجداول والرسوم البيانية وlayout، ثم ينتقل دون تجميع يدوي طويل إلى قياس أداء قابل للتكرار لأنظمة RAG والأنظمة الوكيلة وسيناريوهات العمل الأخرى مع المستندات.