GPT-6 Astra يصحّح أوزان Qwen ويرفع نتيجته على MATH-500 إلى 48,1%

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

في تجربتهم، صحّح GPT-6 Astra نموذج Qwen3.5-0.8B بتعديل 0,016% من معاملاته. وارتفعت نتيجته على MATH-500 من 7,9% إلى 48,1%. تكمن الأهمية العملية هنا في إمكانية البحث عن سبب محدد للخلل داخل النموذج. لكن من المبكر تحويل هذه التجربة إلى وعد بأن «أي شبكة عصبية يمكن إصلاحها بطلب واحد».

ما الذي صحّحه Astra تحديدًا؟

بحسب تقرير الباحثين، أُتيح لـ Astra الوصول إلى الأوزان عبر Python، واختبار سلوك Qwen على مسائل تدريبية. وكان التدريب القائم على التدرّج محظورًا. وتحققت أفضل نتيجة ضمن ميزانية قدرها 50 جولة تقييم.

ربط Astra التكرار باتجاه محدد في مخرجات طبقتين داخليتين، وعدّل الأوزان ذات الصلة. وانخفضت نسبة إجابات MATH-500 التي اصطدمت بحدّ الطول من 93% إلى 33,1%. وأُبقيت إعدادات التوليد متطابقة عند المقارنة.

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

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

لماذا لا تكفي نسبة الدقة وحدها؟

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

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

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

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

كيف تختبر هذا النوع من الإصلاح على نموذجك؟

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

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

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