مطوّر مرشد الذكاء الاصطناعي يراجع اختباراته الـ61 فيكتشف أن بيئة الاختبار تكذب

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

ما الذي جرى اختباره ولماذا

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

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

أين كذبت بيئة الاختبار

يذكر المؤلف ثلاثة أخطاء، يضرب كل منها في اتجاه مختلف. لم تُكشف تفاصيل التنفيذ في الإعلان، لذا ما يلي قراءتنا نحن.

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

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

البيئة التجريبية سليمة، أما الإنتاج فلا

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

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

ما يمكن الاستفادة منه

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

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