شتم Inkling 2 Small عدد 316 مرة، لكنه لم يساعد تقريبا في التنبؤ بالأعطال

يتعطل النموذج أحيانا بطريقة تكاد تكون بشرية: يخطئ عدة مرات، ويعلن أن «لا شيء يعمل»، ويشتم، ثم يواصل توليد النص. وهذا بالضبط هو السلوك الذي اكتشفه باحثو Vals AI في السجلات الداخلية لنموذج Inkling 2 Small من Thinking Machines. وسرعان ما تتحول هذه التفصيلة الطريفة إلى مسألة هندسية: هل يمكن الاستدلال مسبقا، من الكلمات المشحونة عاطفيا، على أن النموذج فقد مسار الحل؟

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

ما الذي وجدوه في السجلات

راجع الباحثون 2,655 عملية تشغيل عبر 13 اختبارا. وظهرت كلمة «fuck» وصيغها المختلفة في 50 عملية تشغيل، بإجمالي 316 مرة. لكن 241 حالة منها جاءت من عمليتي توليد فقط دخلتا في حلقتي تكرار.

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

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

لماذا يعد كاشفا سيئا للأخطاء

للوهلة الأولى، يبدو الارتباط قويا: انتهت 46 من أصل 48 عملية تشغيل خضعت للتقييم واحتوت على شتائم بالفشل. لكن المعدل العام للفشل كان يبلغ نحو 75% حتى من دون ذلك. والأهم أن 96% من جميع عمليات التشغيل الفاشلة لم تتضمن أي شتائم على الإطلاق.

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

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

ما الذي ينبغي للمطورين فعله

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

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

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