🤖 AI

PluginEval: A Diagnostic Benchmark for Fine-Grained Error Attribution in Function Calling

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

المؤلفون الأصليون: Dongjie Xu, Julius, Hanchi Dong, Minghua Tang, Yuxuan Sun, Ziwei Nie, Zicheng Liu, Dujun Qing, Jiajie Xu

نُشر 2026-08-11

📖 5 دقيقة قراءة🧠 قراءة متعمّقة

CC BY 4.0

المؤلفون الأصليون: Dongjie Xu, Julius, Hanchi Dong, Minghua Tang, Yuxuan Sun, Ziwei Nie, Zicheng Liu, Dujun Qing, Jiajie Xu

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

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

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

أدوات المحقق: كيف بنوا الاختبار

لبناء هذا المعيار الجديد، لم يكتفِ المؤلفون بكتابة مجموعة من الأسئلة وتمني الأفضل. بل ابتكروا "إطار بناء الحلقة المغلقة" (PCCF)، وهو مصطلح معقد يعني أنهم بنوا آلة ذاتية التصحيح لصنع الاختبار.

فكر في الأمر كأنه مصمم مستويات في لعبة فيديو يعيد لعب المستوى مراراً وتكراراً حتى يصبح مثالياً.

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

الحكم: ما الذي كشفه الاختبار

بمجرد حصولهم على اختبارهم المثالي (والذي تضمن 3,000 سؤال تم التحقق منها بشرياً عبر 54 أداة مختلفة)، وضعوا خمسة من أذكى نماذج الذكاء الاصطناعي في العالم تحت الاختبار. شمل ذلك أسماء كبيرة مثل GPT-5.4 و Claude 4.6 و Gemini 3.1 Pro.

كانت النتائج كاشفة. وجد المؤلفون أن الدرجات الإجمالية (الدرجة النهائية) مضللة.

فخ الصعوبة: عندما كان الاختبار يتكون في الغالب من أسئلة سهلة، بدا جميع نماذج الذكاء الاصطناي كأنهم عباقرة، حيث سجلوا أكثر من 80%. ولكن بمجرد وصولهم إلى الأسئلة "الصعبة"، انخفضت الدرجات بشكل حاد. بالنسبة لأصعب الأسئلة، حصل أفضل ذكاء اصطناعي على حوالي 10% فقط. يشير هذا إلى أن النماذج الحالية هشة للغاية؛ فهي تعمل بشكل رائع في المهام البسيطة، لكنها تنهار عندما تصبح الأمور معقدة.
عيوب مختلفة لنماذج مختلفة: لم تكتفِ الورقة بالقول إن "النموذج أ أفضل"، بل قامت بتفكيك الأخطاء مثل ميكانيكي يفحص محرك سيارة.
- كان GPT-5.4 الأسوأ في كل من تحديد الأدوات المطلوبة وتجنب الاستدعاءات غير الضرورية، حيث سجل أعلى معدلات لكل من "الاستدعاء المفقود" (نسيان استخدام أداة مطلوبة) و"الاستدعاء الزائد" (استخدام أداة عندما لا ينبغي استخدامها).
- كان Claude Opus 4.6 الأفضل في تذكر استخدام الأدوات (أدنى معدل استدعاء مفقود)، لكنه استخدمها أحياناً عندما لم يكن ينبغي له ذلك (استدعاء زائد مرتفع).
- كان Gemini 3.1 Pro يمتلك ملف أخطاء أكثر توازناً، حيث حقق أدنى معدل "استدعاء زائد"، مما ساعده في الحفاظ على دقة تنافسية رغم انخفاض معدل الاستدعاء لديه مقارنة بـ Claude.
مشكلة "الزمن": برز نوع واحد من الأخطاء لدى كل النماذج: الأخطاء الزمنية. سواء كان السؤال عن "الثلاثاء القادم" أو "الشهر الماضي"، واجهت نماذج الذكاء الاصطناي صعوبة مستمرة في ضبط التواريخ والأوقات بشكل صحيح. كان هذا هو المصدر الأكبر للفشل عبر جميع النماذج.

لماذا يهم هذا الأمر

تجادل الورقة بأننا لا يمكننا مجرد النظر إلى نسبة مئوية واحدة للحكم على قدرة الذكاء الاصطناعي على استخدام الأدوات. قد يحصل النموذج على درجة عالية لأنه جيد في الأسئلة السهلة، أو لأنه محظوظ. ومن خلال استخدام نظام الحكم الجديد الخاص بهم "المثبت بالمعيار الذهبي" (Gold-Anchored) — والذي يقارن إجابة الذكاء الاصطناي مقابل "معيار ذهبي" تم التحقق منه بشرياً بدلاً من تخمين ذكاء اصطناعي آخر — تمكنوا من تحديد مكان فشل الروبوت بدقة.

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

ملخص تقني: PluginEval

بيان المشكلة

مع تزايد عمل النماذج اللغوية الكبيرة (LLMs) كوكلاء مستقلين، أصبح التقييم الموثوق لـ توجيه الأدوات (استدعاء الدوال) أمراً بالغ الأهمية. تعاني المعايكات الحالية من ثلاث قيود هيكلية:

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

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

المنهجية: إطار بناء حلقة PluginEval المغلقة (PCCF)

يقدم البحث PluginEval، وهو معيار تم بناؤه عبر إطار عمل ذي مرحلتين وحلقة مغلقة (PCCF) مصمم لفصل موثوقية التعليق التوضيحي عن متطلبات التغطية.

صياغة المهمة

يتم صياغة توجيه الأدوات كهيكل هرمي من ثلاثة قرارات:

الضرورة ( $f_1$ ): هل الأداة مطلوبة؟
الصلة ( $f_2$ ): هل الإضافة (plugin) المستهدفة ذات صلة؟
الاستدعاء ( $f_3$ ): هل يمكن ربط الطلب باستدعاء صالح بمعلمات صحيحة، أم يجب رفضه؟

المرحلة الأولى: التعليق التوضيحي الجماعي المستند إلى التنفيذ

تركز هذه المرحلة على إنشاء تعليقات توضيحية موثوقة لكل من الاستعلامات الحقيقية والاصطناعية.

التوليد: تقترح عدة مولدات استدعاءات كاملة بشكل مستقل.
التحقق: تخضع المقترحات لعملية تحقق متعددة الخطوات:
- التحقق من المخطط الحتمي (Deterministic Schema Validation): للتحقق من الصلاحية الهيكلية.
- تقييم المعلمات: يقوم مقيم يعتمد على نموذج لغوي كبير بالتحقق مما إذا كانت المعلمات مدعومة من قبل الاستعلام ومتسقة مع دلالات الإضافة.
- التنفيذ: يتم تنفيذ المقترحات عبر بروتوكول سياق النموذج (MCP).
- تقييم النتيجة: يتحقق مقيم منفصل مما إذا كان رد التنفيذ يلبي طلب المستخدم.
حلقة الصقل: يتم الاحتفاظ بالمقترحات التي تفشل في التحقق (بسبب انتهاكات المخطط، أو أخطاء التنفيذ، أو عدم التطابق الدلالي) كآثار (traces). تُغذى هذه الآثار، مع درجات المقيم المستقل، مرة أخرى إلى المولدات من أجل الصقل. تتكرر هذه العملية بحد أقص of $R_{max}$ من الجولات حتى يستوفي المقترح عتبة الثقة $\tau$ أو يُرفض كامتناع مبرر.

المرحلة الثانية: التركيب المستند إلى السيناريو والمعايرة السلوكية

تعالج هذه المرحلة فجوات التغطية ومعايرة الصعوبة.

تفكيك السيناريو: يتم تفكيك الإضافات إلى سيناريوهات التفعيل (الطلبات المدعومة) وسيناريوهات الاستبعاد (الطلبات التي تتطلب عدم استخدام أداة، أو أدوات أخرى، أو تتجاوز القدرات).
التركيب المستهدف: يحدد النظام الوحدات غير المغطاة كفاية (مزيج من القدرة، والقصد، والحدود) ويقوم بتوليد استعلامات جديدة لملء هذه الفجوات.
معايرة الصعوبة:
- الأمثلة الإيجابية: تعتمد الصعوبة على عمق الاستدلال (0، 1، أو $\ge$ 2 خطوة).
- الأمثلة السلبية: تتم معايرة الصعوبة بناءً على الدليل السلوكي. يقوم موجه مرجعي مجمد بتقييم المثال السلفي المركب $K$ من المرات. إذا فشل الموجه باستمرار في رفض المثال السلبي (معدل إيجابي كاذب مرتفع)، يُعتبر المثال "صعباً". إذا تم رفضه بسهولة، فهو "سهل".
الحلقة المغلقة: تُعاد الأمثلة المركبة إلى المرحلة الأولى للتحقق. تستمر الحلقة حتى يتم استيفاء ميزانيات التغطية أو الوصول إلى مرحلة ثبات التحسن.

إطار التقييم: القاضي المرتبط بالذهب (Gold-Anchored Judge)

للانتقال لما وراء معدلات النجاح الإجمالية، يستخدم البحث قاضياً يعتمد على النموذج اللغوي الكبير المرتبط بالذهب:

المدخلات: الاستدعاءات المتوقعة، الاستدعاءات الذهبية المتحقق منها بشرياً، واستعلام المستخدم.
القيد: يعامل القاضي قائمة الاستدعاءات الذهبية باعتبارها المرجع الوحيد؛ ولا يمكنه التوسع في المواصفات الذهبية أو تجاوزها.
التحقق الهرمي:
1. محاذاة الأداة: مطابقة أسماء الأدوات بين التوقع والذهب.
  la تصفية المعلمات: ضمان مجموعات معلمات غير فارغة وقابلة للمقارنة.
2. التحقق الدلالي: تحديد ما إذا كانت المعلمات المتوقعة مكافئة دلالياً للمعلمات الذهبية تحت قصد الاستعلام (مع السماح بالأسماء المستعارة واختلافات التنسيق ولكن مع تقييم النطاقات الزمنية بصرامة).
إسناد الخطأ: تُصنف الإخفاقات إلى فئات مانعة للتبادل:
- فقدان الاستدعاء (Miss Recall): فقدان الأدوات المطللة.
- خطأ في المعلمات (Parameter Error): معلمات غير صحيحة دلالياً (تُصنف فرعياً إلى أخطاء زمنية، معلمات مفقودة، قيم غير صحيحة).
- زيادة الاستدعاء (Over Recall): تفعيل أدوات زائفة عند استعلامات سلبية.

المساهمات الرئيسية

معيار PluginEval: معيار استدعاء الدوال باللغة الصينية يحتوي على 3,000 حالة مُتحقق منها بشرياً تغطي 54 إضافة، و63 أداة، و9 مجالات. يتميز بسيناريوهات تفعيل/استبعاد صريحة، وثلاثة أنواع من حدود السلب، وصعوبة مُعايرة سلوكياً.
إطار عمل PCCF: طريقة بناء ذات حلقة مغلقة تفصل بين موثوقية التعليق التوضيحي (عبر التحقق المستند إلى التنفيذ) ومتطلبات التغطية (عبر تركيب السيناريوهات). يستخدم التحقق من المخطط، والتقييم المستقل، وتنفيذ الأدوات لإصلاح التعليقات التوضيحية.
الإسناد الدقيق للأخطاء: إطار تقييم ينسب الإخفاقات إلى أسباب محددة (فقدان الاستدعاء، أخطاء المعلمات، زيادة الاستدعاء) بدلاً من الاعتماد على مقاييس النجاح الإجمالية.
التحليل التجريبي: تقييم خمسة نماذج رائدة (بما في ذلك النماذج المملوكة والمفتوحة الأوزان) يكشف أن الدرجات الإجمالية حساسة للغاية لتكوين الصعوبة وأن النماذج تظهر ملفات تعريف فشل متميزة.

النتائج

يقيم البحث خمسة نماذج: GPT-5.4، وClaude 4.6، وGemini 3.1 Pro، وDeepSeek-V4-Pro، وQwen3-235B-A22B.

حساسية الأداء: يعتمد الأداء الإجمالي بشكل كبير على توزيع الصعوبة. في التوزيع الأصلي (40% سهل، 40% متوسط، 20% صعب)، حقق Claude Opus 4.6 أفضل أداء (67.60% استدعاء، 68.17% دقة). ومع ذلك، ينخفض الأداء بشكل كبير في الحالات الصعبة (ينخفض الاستدعاء إلى 2.8%–10.8% عبر النماذج).
تأثير الصعوبة: أدى تحويل التوزيع ليكون موجهاً نحو السهل (60% سهل) إلى تحسين جميع النماذج بشكل كبير (ارتفع الاستدعاء بنحو 15–21 نقطة)، مما يدل على أن المعايكات الحالية قد تبالغ في تقدير القدرات إذا لم يتم معايرتها بصرامة.
المقارنة مع المعايكات الموجودة: أدت النماذج عموماً بشكل أسوأ في PluginEval مقارنة بـ BFCL أو APIBench أو NexusRaven. على سبيل المثال، انخفض استدعاء Claude Opus 4.6 من 73.04% في BFCL إلى 67.60% في PluginEval. يشير هذا إلى أن PluginEval يلتقط سيناريوهات أكثر تحدياً، وواقعية، وخصامية.
ملفات تعريف الخطأ:
- GPT-5.4: أظهر أعلى نسبة فقدان استدعاء (33.72%) وأعلى نسبة زيادة استدعاء (33.20%)، مما يشير إلى صعوبة كبيرة في كل من تحديد الأدوات المطلوبة وتجنب الاستدعاءات غير الضرورية.
- Claude Opus 4.6: سجل أدنى نسبة فقدان استدعاء (13.95%)، ولكن بنسبة زيادة استدعاء عالية (29.10%)، وهي لا تزال أعلى من Gemini ولكن أقل من GPT-5.4.
- Gemini 3.1 Pro: حقق أدنى نسبة زيادة استدعاء (18.55%)، مما ساهم في دقة تنافسية رغم انخفاض الاستدعاء.
- الأخطاء الزمنية: عبر جميع النماذج، كانت أخطاء الربط الزمني هي النوع الأكثر تكراراً من أخطاء المعلمات، مما يشير إلى ضعف مشترك في التعامل مع القيود الزمنية.
الموثوقية: أكدت عمليات التدقيق البشري توافقاً عالياً (Fleiss' $\kappa$ يصل إلى 0.9451) على التعليقات التوضيحية المرجعية وإسنادات القاضي، مما يؤكد موثوقية المعيار.

الأهمية والادعاءات

يدعي البحث أن PluginEval يعالج الفجوة الحرجة في التقييم التشخيصي لتوجيه الأدوات. من خلال الانتقال لما وراء معدلات النجاح الإجمالية، يكشف البحث أن:

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

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