GPT-6 Astra تُصلح حلقات التكرار في Qwen: ارتفاع الدقة من 7.9% إلى 48.1%

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

في التجربة المنشورة، عدّل GPT-6 Astra نموذج Qwen3.5-0.8B. وبعد التدخل ارتفعت النتيجة في اختبار الرياضيات MATH-500 من 7.9% إلى 48.1%. وأطلق المؤلفون على هذا النهج اسم weight-space programming، أي البرمجة عبر أوزان النموذج. النتائج وشروط التجربة موضحة في منشور الباحثين.

ما الذي أُصلح بالضبط

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

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

وبحسب وصف الباحثين، وجد الوكيل في طبقتين من Qwen مكوّنًا يدعم التكرار، فأضعف مساهمته. ولم يطل التغيير سوى 0.016% من المعاملات. وهذا أشبه بالبحث عن عطل محدد: يُحدَّد أولًا أين ينشأ السلوك غير المرغوب، ثم يُختبر ما إذا كان تدخل صغير يساعد.

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

لماذا يستدعي ارتفاع الدقة تحفظات

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

وبالنسبة للمنتج فإن الفرق جوهري. يحتاج المستخدم إلى نتيجة مكتملة، وقد يكون إصلاح التكرار مفيدًا جدًا. لكن مدير المنتج الذي يعد بعد هذا التدخل باستدلال رياضي أقوى بوجه عام عليه أن يتحقق من هذا الوعد على مهام خدمته الخاصة.

وفي العمل اختبار دالّ على نموذج صغير آخر هو Gemma 3 270M. ولم يحصل الباحثون هناك على تحسن مماثل. وهذه النتيجة السلبية تحدّ من الاستنتاج: فنجاح تعديل عطل واحد بارز لا يعني أن الوكيل تعلّم تحسين أي شبكة بشكل موثوق.

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

ما الذي ينبغي فحصه في نموذجك

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

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

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