تطرح Datalab معيار OmniParseBench المفتوح لتحليل المستندات

نشرت Datalab معيار OmniParseBench، وهو معيار مفتوح للتعرّف البصري على المحارف وتحليل المستندات تقول الشركة إنه صُمم حول 16,288 اختبارًا. وبحسب صفحة المشروع على PyPI ومنشور Datalab على المدونة، يقيّم المعيار الصفحات المفردة عبر فحوص ثنائية بدلًا من الاعتماد على مسافة التحرير مقارنةً بمخرج مرجعي واحد. عمليًا، يسأل كل اختبار عمّا إذا كان عنصر معيّن موجودًا في مخرج المزوّد، وبالترتيب الصحيح، أو داخل خلية جدول محددة، أو ضمن كتلة تخطيط من نوع معيّن. وتعرض Datalab هذا النهج بوصفه وسيلة للتركيز على ما إذا كانت الأنظمة قد استخرجت المحتوى الصحيح، لا على ما إذا كانت قد طابقت أسلوب إخراج مفضلًا بعينه.

معيار مبني على اختبارات وحدات

يرتكز البروتوكول الموصوف على PyPI على تأكيدات بنعم أو لا على مستوى الصفحة. ويمكن أن يفحص الاختبار وسيطة واحدة أو أكثر، بحيث تقابل كل وسيطة محتوى في موضع ما من الصفحة. ويجمع المعيار النتائج ضمن ثلاث عائلات: النصوص، والجداول، والتخطيط. أما النتيجة الرئيسية المعلنة فهي متوسط نتائج هذه العائلات الثلاث.

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

وفي ما يتعلق بالتغطية، تذكر PyPI أن كل اختبار موسوم عبر عدة أبعاد. وتشمل هذه الأبعاد وسوم البنية مثل table وmath وform وmulti_column؛ ووسوم الإظهار مثل handwriting وtiny وrotated وdegraded؛ ووسوم الدور مثل heading وcaption وfootnote وlist وcode وfigure وheader_footer؛ ووسوم الكتابة المستندة إلى ISO 15924؛ ووسوم اللغة المستندة إلى ISO 639-3. ولا تحدد هذه الوسوم ما إذا كان الاختبار ينجح أو يفشل. بل تتيح للمستخدمين تقسيم المعيار واحتساب نتائج مجموعات فرعية من البيانات. ولأن الاختبار الواحد يمكن أن يحمل عدة وسوم، فإن النتائج على مستوى الوسوم تتداخل ولا تعود بمتوسطها إلى الرقم الرئيسي المعلن.

كيف تعمل الدرجات والتشغيلات

يمكن تشغيل المعيار على مجموعة بيانات Datalab المستضافة على Hugging Face أو على مجموعة بيانات يملكها المستخدم، وذلك وفقًا لوصف PyPI. كما يوفّر أيضًا مكوّنات أدنى مستوى للتقييم والتنبؤ، بما يسمح للفرق بدمجه في مسارات التقييم الخاصة بها. ويمكن استئناف التشغيل، ويُعامل كل إعداد خاص بمزوّد ما على أنه تشغيل مستقل. ويذكر المشروع أن كل تشغيل يكتب ملف scores.jsonl يحتوي على سطر واحد لكل اختبار، بينما يمكن قراءة النتائج الموجزة من ملف summary.json.

ولا يختزل التقييم كل نتيجة في نجاح أو فشل فقط. إذ تسرد PyPI أربعة أحكام:

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

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

ويقول المشروع أيضًا إن موائمات المزوّدين تستخدم مهلة زمنية موحدة لكل استدعاء، وبصورة افتراضية تُستخدم الإعدادات الأكثر دقة لكل مزوّد. ويمكن لأدوات Datalab استدعاء واجهات برمجة تطبيقات البائعين، لكنها تطلب تأكيدًا قبل القيام بذلك لأن هذه الاستدعاءات تكلّف أموالًا. وتتطلب الحزمة Python 3.11 أو إصدارًا أحدث، وتُوزع الشيفرة بموجب ترخيص Apache 2.0، بينما تحمل البيانات والاختبارات تراخيص مختلطة بحسب المصدر.

ما هو متاح علنًا وما ليس كذلك

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

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

النتائج المُدّعاة حول معايير أخرى

بدلًا من نشر نتائج لوحة صدارة OmniParseBench في المواد المزوّدة، تركز مدونة Datalab على سبب اعتقادها بأن المعايير الحالية غير كافية. وتقول الشركة إن olmOCR وصل إلى حالة تشبع، وتورد أمثلة يمكن فيها للمعالجة اللاحقة أن تغيّر النتائج المعلنة بنحو نقطة أو نقطتين تقريبًا. كما تجادل بأن ParseBench يمكن أن يتأثر بقوة بصياغة الموجّه، واتفاقيات التنسيق، والمسارات المتخصصة، ولا سيما في الرسوم البيانية والإسناد البصري. وهذه مزاعم جوهرية تطرحها Datalab، لكنها ينبغي أن تُقرأ بوصفها رواية الشركة هي. فلا يوجد في المصادر المزوّدة تحقق مستقل من هذه الادعاءات.

ومع ذلك، تساعد هذه الادعاءات في توضيح ما الذي يحاول OmniParseBench تحسينه. ففحوصه القائمة على نعم أو لا تُقدَّم صراحةً على أنها أصعب في التلاعب من المناهج القائمة على مطابقة مرجع. وتقول Datalab إن هذه البنية ينبغي أن تنتج إشارات أوضح عن الأخطاء، لأن الاختبار الفاشل يقابل خطأ محددًا في صفحة محددة. وقد يسهّل ذلك على مطوري النماذج والمشترين في المؤسسات رؤية ما إذا كان النظام يواجه صعوبة، على سبيل المثال، مع النصوص المدوّرة، أو النماذج، أو الكتابة اليدوية، أو بنية الجداول، بدلًا من الاكتفاء برؤية نتيجة واحدة مدمجة.

حدود تظهر في الإصدار نفسه

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

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

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