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

أظهر مطور كيفية إصلاح أحد أهم نقاط الضعف في نماذج البرمجة الرخيصة: العمى تجاه واجهة المستخدم الخاصة بهم. بالنسبة لـ z.ai GLM-5.1، قام ببناء vision-sidecar محلي يقرأ لقطات الشاشة ويعيد بنية الواجهة على شكل JSON ويسمح للوكيل بالتحقق من النتائج بعد توليد الكود.

المشكلة

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

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

كيفية بناء خط الأنابيب

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

على وحدة GPU عادية أو Apple Silicon، تستغرق الإعداد بأكمله، وفقًا للمؤلف، حوالي 20 دقيقة للنشر.

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

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

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

تم إجراء الاختبارات على عشر لقطات شاشة من تطبيق ويب حقيقي، من شاشة هاتف محمول صغيرة 320×568 إلى سطح مكتب 1440×900. تمت مقارنة ثلاثة أنماط: qwen3-vl:8b الأساسي والنموذج نفسه بعد الضبط و Claude Opus 4.7 كحد أعلى.

ارتفعت النقاط المتوسطة من 3.99 إلى 4.70 من أصل 5، وانكمشت الفجوة حتى الحدود الأمامية من 1.01 إلى 0.30. بعبارة أخرى، أغلق النموذج المحلي 8B حوالي 70% من التأخر بدون ضبط دقيق وبدون بيانات إضافية.

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

بعد الضبط، حققت المجموعة شبه تكافؤ حيث يهم التحقق العملي من واجهة المستخدم للوكيل:

• OCR واستخراج النص الدقيق
• كشف عناصر واجهة المستخدم و CTAs
• فهم بنية التخطيط
• استخراج الجداول والملاءمة للمعالجة الآلية الإضافية

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

معنى هذا

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