أطلقت Zhipu AI نموذج GLM-OCR، وهو نموذج OCR صغير الحجم يضم 0.9 مليار معلمة للمستندات

قدمت شركة Zhipu AI بالتعاون مع الباحثين من جامعة تسينغهوا نموذج GLM-OCR — وهو نموذج استخراج النصوص من الصور المتعدد الأنماط يحتوي على 0.9 مليار معامل لتحليل الوثائق الحقيقية. تم الرهان ليس على الحجم الأقصى، بل على التوازن بين الجودة والسرعة وتكلفة الاستدلال.

لماذا استخراج النصوص من الصور صعب

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

كيف يعمل GLM-OCR

يعتمد GLM-OCR على مزيج من محول الصور البصري CogViT بـ 0.4 مليار معامل، وموصل cross-modal خفيف الوزن، وفك تشفير اللغة GLM بـ 0.5 مليار معامل.

الفكرة التقنية الرئيسية هي Multi-Token Prediction. بدلاً من التنبؤ بصرامة برمز واحد في كل خطوة، تم تدريب النموذج على إخراج عشرة رموز، وفي الاستدلال ينتج في المتوسط 5.2 رموز في كل خطوة.

وفقاً للمؤلفين، يوفر هذا حوالي 50٪ من تحسن الإنتاجية دون نمو حاد في الذاكرة بسبب مخطط مشاركة المعاملات. على مستوى النظام، لا يعمل النموذج أيضاً كوضع مسطح "اقرأ الصفحة بأكملها مرة واحدة". أولاً يقوم PP-DocLayout-V3 بوضع علامات على الوثيقة في مناطق دلالية، ثم يعالج GLM-OCR المناطق الفردية بالتوازي.

لتحليل الوثائق، يتم إنشاء Markdown و JSON منظمة في الإخراج، وللاستخراج من الحقول الرئيسية (KIE)، يتم تقديم صورة الوثيقة الكاملة مع مطالبة وينتج النموذج JSON فوراً وفقاً لمخطط معين.

• يحلل الصفحات حسب المناطق قبل الاستخراج
• يعالج الكتل الموجودة بالتوازي
• يعيد Markdown و JSON منظمة
• يدعم بشكل منفصل وضع KIE لاستخراج الحقول
• مناسب لواجهة برمجية سحابية والتنفيذ المحلي

ما أظهرته الاختبارات

على المقاييس العامة، يُظهر النموذج نتائج قوية، لكن بدون قيادة عالمية. حصل GLM-OCR على 94.6 على OmniDocBench v1.

5، و 94.0 على OCRBench لاستخراج النصوص، و 96.5 على UniMERNet للصيغ و 86.

0 على TEDS_TEST للجداول. في مهام استخراج الحقول، أظهر النموذج 93.7 على Nanonets-KIE و 86.

1 على Handwritten-KIE. هذه مجموعة جيدة من الأرقام لنموذج بهذا الحجم، خاصة عند مقارنته بأنظمة متعددة الأنماط أثقل بكثير. في الوقت نفسه، يترك المؤلفون أنفسهم تحفظات مهمة.

على PubTabNet لا يأتي GLM-OCR أولاً: MinerU 2.5 لديه 88.4 مقابل 85.

2. وفي عمود النماذج المرجعية يُظهر Gemini-3-Pro نتائج أعلى في KIE. أي أن الصيغة الصحيحة هنا هي: GLM-OCR بين الرواد من بين الحلول المفتوحة والمضغوطة، لكنه لا يغطي جميع السيناريوهات بشكل أفضل من الجميع.

من الناحية العملية، يبدو المشروع ليس بحتاً مختبراً. يعلن المؤلفون عن دعم vLLM و SGLang و Ollama، وكذلك الضبط الدقيق عبر LLaMA-Factory. يشير التقرير إلى إنتاجية 0.

67 صورة في الثانية و 1.86 صفحة PDF في الثانية في إعداد الاختبار الخاص بهم. للوضع السحابي، تتوفر واجهة برمجية MaaS بسعر 0.

2 يوان لكل مليون رمز: وفقاً لحسابات الفريق، يوان واحد كافٍ لحوالي 2000 مسح A4 أو 200 ملف PDF بسيط من عشر صفحات.

ما يعنيه هذا

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