رؤية محلية لـ z.ai GLM-5.1: نموذج 8B يغلق 70% من الفجوة مع النماذج الرائدة

أوضح مطوّر كيف يمكن التخلص من إحدى أكبر نقاط الضعف في نماذج البرمجة منخفضة التكلفة، وهي العمى تجاه واجهتها الخاصة (UI). فقد بنى لنموذج z.ai GLM-5.1 مكوّن رؤية جانبيًا محليًا (vision-sidecar) يقرأ لقطات الشاشة، ويعيد بنية الواجهة بصيغة JSON، ويتيح للوكيل التحقق بنفسه من النتيجة بعد توليد الكود.

ما المشكلة؟

المشكلة مألوفة لكل من جرّب النماذج الاقتصادية بدلًا من أنظمة frontier الباهظة. يستطيع الوكيل كتابة HTML، وتشغيل الصفحة، وتنفيذ اختبارات Playwright، وحفظ لقطة شاشة، لكنه يتوقف عند هذه النقطة: الصورة موجودة، أما الفهم فغائب. إذا انزاح زر عن مكانه، أو اقتُطع جدول، أو تداخل نص مع بطاقة، أو انهارت الشبكة (grid) على الجوال، فإن النموذج لا يلاحظ ذلك. والنتيجة أن الإنسان يعود إلى فحص الواجهة يدويًا، فيتحول من مُحدِّد للمهام إلى مختبِر جودة (QA) دائم بين التكرارات.

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

كيف بُنيت المنظومة

استُخدم qwen3-vl:8b كنموذج للرؤية، وهو مُشغَّل محليًا عبر Ollama. وفوقه بنى المطوّر خادم MCP باسم vision-sidecar-mcp، يستقبل لقطات الشاشة ويعيد وصفًا منظَّمًا للشاشة. هذه الطبقة لا تجعل GLM-5.1 نموذجًا متعدد الوسائط كاملًا، لكنها تمنحه ما كان ينقصه في التطوير العملي: القدرة على قراءة النتيجة البصرية لعمله عبر واجهة نصية. وبحسب المطوّر، تُنصَّب المنظومة كاملة خلال نحو 20 دقيقة على وحدة GPU عادية أو على Apple Silicon.

• qwen3-vl:8b كنموذج رؤية محلي
• Ollama للنشر السريع
• خادم MCP بالدوال analyze_image وanalyze_structured وextract_table
• ردود بصيغة JSON يمكن تمريرها مباشرة إلى وكيل البرمجة

لم يكمن الجزء الهندسي الأهم في إعادة تدريب الأوزان، بل في ضبط الاستدلال (inference). فقد ثبّت المطوّر قيمة seed، وشدّد أخذ العينات (sampling) عبر top_p=0.9 وtop_k=20، وحوّل الردود إلى مخطط JSON صارم. كما ساعد حقل مستقل للرموز والأيقونات على إزالة أخطاء التعرف الشائعة، حين كانت الرموز الزخرفية (glyphs) تُقرأ قراءة خاطئة. وهذه خلاصة مهمة: إذا اقتصرت المهمة على استخراج البنية، فإن التعليمات الجيدة والمخطط وانضباط التوليد تعطي أحيانًا فائدة أكبر من التوجه مباشرة إلى fine-tuning.

ما الأرقام التي تحققت؟

أُجري الاختبار على عشر لقطات شاشة لتطبيق ويب حقيقي، من شاشة جوال صغيرة بدقة 320×568 إلى سطح مكتب بدقة 1440×900. وقورنت ثلاثة أوضاع: qwen3-vl:8b الأساسي، والنموذج نفسه بعد الضبط، وClaude Opus 4.7 كسقف أعلى للمقارنة. ارتفع المتوسط من 3,99 إلى 4,70 من 5، وتقلصت الفجوة مع النموذج الرائد من 1,01 إلى 0,30. بعبارة أخرى، أغلق نموذج 8B المحلي نحو 70% من التأخر دون fine-tuning ودون بيانات إضافية.

«حلقة الاختبار أُغلقت. لم يعد النموذج أعمى».

بعد الضبط، اقتربت المنظومة من التكافؤ في المجالات التي يحتاج فيها الوكيل إلى فحص عملي للواجهة:

• OCR واستخراج النص بدقة
• اكتشاف عناصر الواجهة وأزرار CTA
• فهم بنية التخطيط (layout)
• استخراج الجداول وصلاحيتها للمعالجة الآلية اللاحقة

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

ماذا يعني ذلك؟

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