Towards Evaluation Engineering: An Empirical Study of ML Evaluation Harnesses in the Wild
تقدم هذه الورقة دراسة تجريبية لـ 57 من أدوات تقييم تعلم الآلة التي تحدد مرحلة التوصيف باعتبارها المصدر الرئيسي للتحديات التشغيلية، وتصنف 16,560 مشكلة حسب السبب الجذري لتكشف أن الميزات غير المنفذة، وفجوات التوثيق، ونقص التحقق من المدخلات تشكل أكثر من 60% من المشكلات، وتؤسس لقاعدة معاملة هندسة التقييم كفرع متميز من فروع هندسة البرمجيات.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
تخيل أنك طاهٍ يحاول تقييم وصفة جديدة. لديك المكونات (البيانات)، وبطاقة الوصفة (النموذج)، وقائمة بالقواعد لما يجعل الطبق "جيداً" (المقاييس). ولكن قبل أن تتذوق الطعام، تحتاج إلى مطبخ لتطهو فيه، ومؤقت لتتبع وقت الطهي، وبطاقة تسجيل لتدوين النتائج.
في عالم الذكاء الاصطناعي، يُسمى هذا "المطبخ" حامل التقييم (Evaluation Harness). وهو أداة برمجية تقوم فعلياً بتشغيل الاختبارات، وتحميل البيانات، وحساب الدرجات، وإخبارك ما إذا كان نموذج الذكاء الاصطناعي يقوم بعمل جيد أم لا.
هذه الورقة البحثية تشبه عملية تفتيش ضخمة لـ 57 "مطبخ ذكاء اصطناعي" مختلف لمعرفة كيف تعمل، وأين تتعطل، ولماذا يشعر الناس بالإحباط منها. ويطلق الباحثون على هذا المجال الجديد اسم "هندسة التقييم" (Evaluation Engineering).
إليك تفصيل لنتائجهم باستخدام تشبيهات بسيطة:
1. سير عمل المطبخ المكون من خمس مراحل
اكتشف الباحثون أن كل مطبخ تقييم للذكاء الاصطناعي يمر بخمس مراحل محددة، مثل خط الإنتاج:
- التجهيز (إعداد المطبخ): تجهيز الموقد، والقدور، والمكونات. ويشمل ذلك تثبيت البرامج وتسجيل الدخول إلى الحسابات.
- التوصيف (كتابة الوصفة): تحديد ما تطبخه بالضبط وما هي المكونات التي ستستخدمها. هنا تقوم بتحميل نموذج الذكاء الاصطناعي وبيانات الاختبار.
- التنفيذ (طهي الطعام): تشغيل نموذج الذكاء الاصطناعي فعلياً لتوليد الإجابات.
- التقييم (التذوق والتسجيل): فحص الإجابات ومقارنتها بالإجابات الصحيحة وحساب الدرجة.
- التقرير (تقديم القائمة): عرض النتائج النهائية في رسم بياني أو تقرير.
المفاجأة الكبرى: معظم هذه المطابخ بارعة في "الطهي" (التنفيذ) ولكنها سيئة في "التقديم" (التقرير). قلة قليعة منها تمتلك إنذارات تلقائية لتخبرك ما إذا كان الطعام طعمه أسوأ اليوم مما كان عليه بالأمس.
2. أين تسير الأمور بشكل خاطئ (الأسباب الجذرية)
نظر الفريق في أكثر من 16,000 شكوى (تسمى "مشكلات") من المستخدمين. ووجدوا أن المشكلات ليست عادةً بسبب خطأ في الرياضيات أو انهيار الكود بشكل درامي. بدلاً من ذلك، معظم المشكلات هي مشكلات بيروقراطية وقطع مفقودة.
فكر في الأمر كأنك تحاول بناء مجموعة "ليجو" (Lego) حيث التعليمات مفقودة أو يقول الصندوق "يتضمن مكعباً أحمر" ولكنك حصلت فقط على مكعب أزرق.
أهم ثلاثة أسباب لفشل المطابخ هي:
- الميزات المفقودة (24%): الأداة وعدت بفعل شيء ما (مثل التعامل مع نوع معين من البيانات)، لكن المطورين لم يبنوا ذلك الجزء فعلياً. إنه مثل سيارة بها عجلة قيادة ولكن بدون محرك.
- التعليمات السيئة (20%): الأداة تعمل، ولكن الدليل مفقود، أو قديم، أو مربك. لا يستطيع المستخدمون معرفة كيفية استخدامها.
- غياب ضوابط السلامة (17%): الأداة لا تتحقق مما إذا كانت المكونات طازجة. إذا قدمت لها بيانات سيئة، فهي لن تتوقف؛ بل ستطهو "قمامة" وتعطيك درجة "قمامة".
3. أنواع المطابخ المختلفة
قسم الباحثون الـ 57 مطبخاً إلى أربعة "نماذج نمطية" (Archetypes)، ولكل نوع صداعه الخاص:
- مطبخ الاختبار المعياري (40%): هذه هي المطابخ الكبيرة والمشهورة التي تختبر العديد من النماذج مقابل اختبارات معيارية (مثل اختبارات SAT للذكاء الاصطناعي).
- صداعهم الأكبر: تعطل التبعيات (Dependency Breakage). يعتمدون على مكونات خارجية (مجموعات بيانات) تتغير أو تختفي دون سابق إنذار. إذا قام المورد بتغيير التغليف، يتوقف المطبخ بأكمله عن العمل.
- الأداة المتخصصة (21%): هذه أدوات صغيرة تقوم بشيء واحد فقط بإتقان (مثل التحقق مما إذا كان الروبوت يمكنه المشي).
- صداعهم الأكبر: التعليمات السيئة. نظرًا لبساطتها الشديدة، ينسى المطورون كتابة تعليمات واضحة حول كيفية إعدادها.
- المسبار المخصص (21%): هذه تختبر مهارات محددة (مثل البرمجة أو الرياضيات).
- صداعهم الأكبر: الأخطاء الرياضية. بما أنهم يبتكرون صيغ تسجيل خاصة بهم، فإنهم غالباً ما يخطئون في الحسابات، مما يؤدي إلى أخطاء صامتة حيث تبدو الدرجة صحيحة ولكنها في الواقع خاطئة.
- المطعم كامل الخدمة (17%): هذه منصات فاخرة وشاملة تفعل كل شيء.
- صداعهم الأكبر: عدم توافق العقود (Contract Mismatches). نظرًا لأنها تربط بين أجزاء كثيرة مختلفة (مثل حكم عن بُعد ونموذج محلي)، فإن الأجزاء غالباً لا تتحدث نفس اللغة، مما يسبب انقطاعاً في التواصل.
4. "القاتل الصامت"
أكثر مشكلة خطيرة وجدتها الورقة هي أخطاء التسجيل الصامتة (Silent Scoring Errors).
تخيل حكماً يتذوق حساءً ويعطيه تقييم 5 نجوم. الحكم واثق، والدرجة مطبوعة، والجميع سعيد. لكن في الواقع، نسي الحكم إضافة الملح، والحساء طعمه سيء جداً. الأداة لم تتعطل؛ بل أعطت فقط درجة خاطئة.
وجدت الورقة أن العديد من الأدوات تحسب الدرجات بشكل غير صحيح (أخطاء خوارزمية) أو تفشل في التحقق مما إذا كانت البيانات منطقية (فجوات التحقق)، ولأنه لا يوجد "رأي ثانٍ" مدمج في النظام، لا أحد يلاحظ ذلك حتى وقت متأخر جداً.
5. ماذا يعني هذا للمستقبل؟
تخلص الورقة إلى أننا بحاجة إلى معاملة هذه الأدوات ليس فقط كـ "سكربتات" (Scripts) بل كمنتجات هندسية جادة.
- المطورون: يحتاجون إلى التوقف عن افتراض أن الرياضيات مثالية والبدء في بناء "شبكات أمان" (مثل التحقق مما إذا كانت الدرجة منطقية قبل طباعتها).
- المستخدمون: يحتاجون إلى التوقف عن الثقة بالدرجة بشكل أعمى. مجرد قول الأداة "دقة 95%" لا يعني أنها حقيقية؛ عليك التحقق من العمل بنفسك.
- الباحثون: يحتاجون إلى ابتكار طرق جديدة لاختبار هذه الأدوات، لأن الطرق القديمة لاختبار البرمجيات لا تعمل عندما يكون "الاختبار" نفسه ذكاءً اصطناعياً قد يعاني من "الهلوسة".
باخت-صار: لقد صنعنا آلات مذهلة لاختبار آلات أخرى، ولكن الآلات التي تقوم بالاختبار غالباً ما تفتقر إلى التعليمات، وتوجد في منطقها ثغرات، وتفتقر إلى القدرة على إخبارنا عندما تكون مرتبكة. إصلاح هذه "المطابخ" لا يقل أهمية عن بناء "طهاة" (نماذج ذكاء اصطناعي) أفضل.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.