VerifierBench: 19 نموذج LLM كتبت مُتحقِّقات، وأفضلها لم يتجاوز 62,1 نقطة

تحتاج الوكلاء إلى طريقة تتيح لها معرفة أنها أنجزت المهمة بشكل صحيح. فبدونها لا يمكن إكمال العمل حتى نهايته، ولا تصفية البيانات الاصطناعية المخصصة للتدريب. اختبر فريق VerifierBench مدى قدرة نماذج LLM على ذلك بنفسها: يكتب الوكيل، انطلاقًا من التعليمات والبيئة المتاحة، مُتحقِّقًا قابلًا للتنفيذ، ويجب أن يقبل هذا المُتحقِّق أي حل صحيح ويرفض أي حل غير صحيح. يضم الاختبار 222 مهمة من ستة اختبارات معيارية للوكلاء، و4993 حالة اختبار مخفية. وعلى 19 نموذجًا، تراوحت الدقة المتوازنة المُطبَّعة بين 10,6 و62,1.

ما الذي يختبره VerifierBench تحديدًا

صيغت المهمة بصرامة. يحصل المُتحقِّق على المعلومات نفسها التي يحصل عليها الوكيل الذي يحل المهمة، أي نص التكليف والبيئة. وعليه بعد ذلك أن يحوّلها إلى برنامج يصدر حكمًا على حل كتبه طرف آخر. تغطي المهام ثلاثة أنواع من التحقق: استدعاءات الأدوات (tool-call)، والتحقق من الحالة النهائية للبيئة (state-based)، والتحقق من الكود.

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

أبرز معايير العمل:

• 222 مهمة من ستة اختبارات معيارية للوكلاء
• 4993 حالة اختبار مخفية، تشمل حلولًا بديلة وهجمات
• 19 نموذجًا ضمن بيئة تشغيل وكيلية موحدة (harness)
• normalized balanced accuracy: من 10,6 إلى 62,1
• صفحة المشروع ومجموعة البيانات متاحتان للعموم

مُتحقِّق لا يسمح بمرور أحد

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

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

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

لماذا لا يكشف الاختبار الذاتي الخطأ

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

كيف نختبر المُتحقِّقين أنفسهم

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

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

ويدل التفاوت بين 10,6 و62,1 كذلك على أن توليد المُتحقِّقات ما زال بعيدًا عن أن يكون مسألة محسومة. فحتى أفضل نتيجة تترك هامشًا ملحوظًا من الأخطاء. لذلك من المبكر الوثوق بتقييم الوكلاء دون رقابة مستقلة، فيما توفر مجموعة البيانات المتاحة للعموم وسيلة مريحة للفرق لمقارنة النماذج بحسب هذه المهارة تحديدًا.