NERVE: كيف نُخفّت «عصبونات SQL» في Qwen 27B ونصلح استعلامات 1C دون إعادة تدريب

ألم مألوف: ضبطتَ نموذجاً مفتوحاً على مجال ضيق، ومع ذلك يخطئ بانتظام في الموضع نفسه. مجموعات البيانات الجديدة بالكاد تفيد، وكل دورة لجمع البيانات تكلّف أسابيع. واجه كاتب مقال على Habr هذه المشكلة بالضبط مع Qwen 3.8 27B المضبوط على 1C:Enterprise. يكتب النموذج الشيفرة بلغة 1C المدمجة بشكل مقبول، لكنه يخلط لغة الاستعلامات في 1C مع SQL: يخلط الجداول الافتراضية، ويضع المعاملات في غير موضعها، ويجلب تراكيب غير موجودة في 1C. أضافت مجموعات البيانات الإضافية أقل من 1% من accuracy.

الفرضية: SQL هو المعيق

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

العصبون هنا هو مكوّن واحد من المتجه الوسيط في كتلة MLP (يبلغ عددها 17,408 في كل طبقة في Qwen 3.8 27B) مع عمود المصفوفة W_down الذي يكتب فيه. ضرب العمود في m يعني ضرب تنشيط العصبون في m عند كل رمز. القيمة 0 تُطفئ العصبون، و0.5 تُضعفه إلى النصف. لا تتغير البنية، ويصمد التعديل أمام التكميم والتصدير إلى GGUF. عدد المرشحين الإجمالي نحو 1.1 مليون (64 طبقة)، لذا فالبحث الأعمى بلا معنى.

كيف يعمل خط المعالجة

1. تؤخذ أزواج «استعلام صحيح / استعلام خاطئ»، كما في DPO، نحو ألفي زوج. ولأن الإجابات تتطابق بنسبة 90–95%، تُقارَن فقط الرموز المختلفة التي يجدها difflib. أما المتوسط على الإجابة كلها فكان سيُضعف الإشارة.
2. تجمع الخطافات (hooks) عند مدخل كل down_proj متوسط تنشيط العصبونات على هذه الرموز. وعلى مستوى كل الأزواج تُحسب القيمة المتوسطة وإحصائية t واتساق الإشارة. يجري الترتيب بحسب |t| كي لا تُنتج زوجان أو ثلاثة أزواج شاذة قادةً زائفين.
3. يتنبأ الإسناد بالتدرج («التدرج × المدخل») بكيفية تغير margin، أي مدى تفضيل النموذج للإجابة الصحيحة على الخاطئة، إذا خُفّت العصبون. يُعدّ العصبون ذو المساهمة السالبة «خاطئاً». الإسناد مكلف، لذلك يُبنى على 512 زوجاً.
4. يجرّب الانتقاء الجشع المرشحين واحداً تلو الآخر فوق ما قُبل سابقاً. يبقى التعديل إذا ارتفع margin بما لا يقل عن 0.002 لكل رمز، ولم ينخفض nll على الإجابات الصحيحة بأكثر من 2%. وما دامت المحاولات الفاشلة تُلغى، لم تعد التنبؤات الخطية التراكمية لازمة.

الحماية الرئيسية من فرط التخصيص: يُقسَّم val إلى نصفين بحسب تجزئة الاستعلام. تُتخذ القرارات على أحدهما، ويُتحقق من النتيجة على الآخر. لا تُعدّ المجموعة مؤكَّدة إلا إذا ارتفع margin على نصف التحكم ولم يسُؤ nll بما يتجاوز الحد المسموح. تتراكم التعديلات المؤكَّدة في ملف JSON بجوار الخريطة وتُستبعد من المرشحين المستقبليين.

ما اكتُشف في الطريق

الخطأ الأول: بُنيت الخريطة على الرموز المختلفة بينما قيست الجودة على الإجابة كاملة. فخُفّف الأثر نحو 25 مرة. الإصلاح: قناع diff واحد للخريطة وللتحقق. الاكتشاف الثاني: تعزيز العصبونات «الجيدة» أفسد nll في الغالب، بينما أعطى كبت العصبونات الخاطئة ارتفاعاً ثابتاً في margin، ولذلك أصبح وضع suppress هو الأساسي. ومن الملاحظات أيضاً أن التهيج على الإجابات الخاطئة موجود تقريباً في كل طبقة، أي أن السلوك الشبيه بـ SQL موزَّع على عمق الشبكة كله.

القيود والخلاصة

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