Zhipu AI تطلق GLM-OCR: نموذج OCR مدمج بـ 0,9 مليار معامل لمعالجة المستندات

قدّمت Zhipu AI، بالتعاون مع باحثين من جامعة تسينغهوا، نموذج GLM-OCR، وهو نموذج OCR متعدد الوسائط بـ 0,9 مليار معامل لتحليل المستندات الواقعية. ولم يراهن الفريق على أقصى حجم ممكن، بل على التوازن بين الجودة والسرعة وتكلفة الاستدلال (inference).

لماذا يُعدّ OCR مهمة صعبة

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

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

كيف يعمل GLM-OCR

يقوم GLM-OCR على ثلاثة مكونات: مشفّر بصري CogViT بـ 0,4 مليار معامل، وموصّل خفيف متعدد الوسائط، ومفكّك لغوي GLM بـ 0,5 مليار معامل.

الفكرة التقنية الرئيسية هي Multi-Token Prediction. فبدلًا من التنبؤ برمز واحد فقط في كل خطوة، جرى تدريب النموذج على إنتاج عشرة رموز، ويولّد أثناء الاستدلال في المتوسط 5,2 رمز في كل خطوة. ووفقًا للمطورين، يمنح ذلك زيادة في الإنتاجية بنحو 50% دون ارتفاع حاد في استهلاك الذاكرة، بفضل مخطط مشاركة المعاملات.

وعلى مستوى النظام، لا يعمل النموذج بوضع مسطّح من نوع «اقرأ الصفحة كاملة دفعة واحدة». إذ يقسّم PP-DocLayout-V3 المستند أولًا إلى مناطق ذات معنى، ثم يتعرف GLM-OCR على المناطق المنفصلة بالتوازي. وفي تحليل المستندات، يُنتج الخرج بصيغتَي Markdown وJSON المنظمتين. أما في KIE، أي استخراج الحقول الرئيسية، فتُمرَّر صورة المستند كاملة مع موجّه (prompt)، ويولّد النموذج مباشرة JSON وفق مخطط محدد.

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

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

على المقاييس المعيارية العامة، جاءت نتائج النموذج قوية، لكنه لا يتصدر في كل شيء. فقد سجّل 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، إضافة إلى الضبط الدقيق (fine-tuning) عبر LLaMA-Factory. ويشير التقرير إلى إنتاجية قدرها 0,67 صورة في الثانية و1,86 صفحة PDF في الثانية في إعدادات الاختبار لديهم. وفي الوضع السحابي تتوفر واجهة MaaS API بسعر 0,2 يوان لكل مليون رمز، وبحسب حسابات الفريق يكفي يوان واحد لنحو 2000 مسح بحجم A4 أو 200 ملف PDF بسيط من عشر صفحات.

ماذا يعني ذلك

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