AdaPRA: وكيل مُراقب يرفع أداء الذكاء الاصطناعي في مهام علم البيانات بنسبة 24.5 شريحة مئوية

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

كيف يعمل الوكيل المُدقق

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

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

من أين تأتي القواعد ولماذا تنتقل بين المهام

لم يكتب الباحثون معايير التقييم يدويًا — فذلك كان غير واقعي بالنسبة لمئات أنواع المهام. بدلًا من ذلك، شغّلوا الوكيل الأساسي عدة مرات على 38 مهمة من مستوى "سهل" (مجموعة DSPredict-Easy، والتي تضم في معظمها مسابقات جدولية من سلسلة Kaggle Playground)، وقارنوا أفضل المحاولات بأسوأها بحسب الترتيب النهائي. استخلص حكم من نموذج لغوي (Claude Sonnet 4.

6)، من 906 ملاحظة — تضم أساليب ناجحة وحالات فشل — 342 نمطًا "جيدًا" و564 مشكلة، ثم جمّعها في 17 قاعدة محددة إضافة إلى قاعدتين عامتين تتعلقان باستخدام المحاولات السابقة — أي ما مجموعه 19 معيار تقييم أساسي. تفصيل مهم: معظم المشكلات المُكتشفة لا تظهر إلا في الكود وسجلات التنفيذ نفسها (344 من أصل 564)، بينما تظهر الحلول الناجحة في مخرجات مجلد العمل (235 من أصل 342). أي أن الاعتماد فقط على الحوار مع الوكيل أو فقط على الملفات يُفقد معظم الإشارات المفيدة.

وقد نُقلت هذه الـ19 معيار تقييم دون أي تعديل إلى مجموعة DSPredict-Hard — وهي مجموعة من 54 مهمة أكثر تعقيدًا بكثير (رؤية، نص، صوت، بيانات جزيئية) — ونجحت. كما أن AdaPRA قادر على إضافة قواعد جديدة أثناء العمل: فعلى سبيل المثال، في مهمة House Prices، أضاف المُدقق بنفسه قاعدة أسماها "تباين غير كافٍ في التوقعات" — وهي فحص يتحقق من عدم تقريب النموذج جميع توقعات الأسعار إلى المتوسط بدلًا من توليد تشتت واقعي.

النتائج والحدود

مع خمس محاولات لكل مهمة، رفع AdaPRA، مدمجًا مع النموذج الأساسي Qwen3-Coder-Next (80 مليار معامل)، متوسط الشريحة المئوية على لوحة ترتيب Kaggle بمقدار 24.5 نقطة في المهام السهلة و14.8 نقطة في المهام الصعبة — نتائج تُقارب أو تتفوق على نتائج GPT-5.1 في وضع الاستدلال المعزز. كما تفوّق النظام على DataPRM، وهو نموذج مُدقق منافس بـ4 مليارات معامل يُقيّم خطوات الوكيل على مقياس من 0 إلى 1 دون استخدام معايير تقييم مرنة. وأظهرت تجربة منفصلة أن معايير التقييم المُستخلصة من نموذج واحد تنجح أيضًا عند نقلها إلى نموذج آخر هو DeepSeek-V3.2.

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