حللت IBM Research مواضع تعثر وكلاء AI مع API والوثائق والقواعد في VAKRA

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

كيف يتم تنظيم VAKRA

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

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

أربعة أنواع من المهام

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

• واجهات برمجية لذكاء الأعمال: 2077 مهمة في 54 مجالاً، حيث يحتاج الوكيل إلى استدعاء 1–12 أداة بشكل متتالي والعمل بحذر مع المعاملات وتصفية البيانات.
• واجهات برمجية لوحات المعلومات: 1597 مهمة في 17 مجالاً، حيث تكون التعقيد الرئيسي هو اختيار نقطة النهاية الصحيحة من بين 6–328 أداة متاحة.
• القفزات المتعددة على واجهات برمجية: 869 مهمة في 38 مجالاً، حيث يتم تجميع الإجابة من خلال عدة انتقالات منطقية من واحد إلى خمسة.
• مصادر متعددة + سياسات: 644 مهمة في 41 مجالاً، حيث يتبادل الوكيل بين واجهات برمجية والبحث في المستندات ويأخذ في الاعتبار سجل الحوار ويتبع قواعد نصية مثل "استخدم المسترجع فقط، لا تلمس الأدوات الأخرى."

حيث يفشل الوكلاء

الجزء الأكثر فائدة من المقالة هو تحليل حيث تفشل النماذج. يقسم المؤلفون الأخطاء حسب المرحلة: اختيار الأداة الخاطئة وحذف الحجج الضرورية أو الهلوسة عنها وقيم المعاملات غير الصحيحة وأخيراً إجابة نهائية غير صحيحة حتى بعد الاستدعاءات الصحيحة. في جزء API لذكاء الأعمال، كان GPT-OSS-120B الأفضل أداءً: فهم أفضل بكثير مخططات الأدوات وارتكب عدداً أقل من الأخطاء في الأسماء وملء المعاملات.

لكن حتى هناك، لم يضمن النجاح في الخطوات الفردية نتائج مستقرة من طرف إلى طرف. في المهام التي تحتوي على مجموعة كبيرة من واجهات برمجية لوحات المعلومات، كان Gemini-3-flash-preview أفضل أداءً، وهذا منطقي: هناك القدرة على قائمة اختصار من الأدوات والاختيار الدقيق لنقطة النهاية أهم شيء. مع نمو عمق التفكير، انخفضت الجودة لجميع النماذج: أسئلة 2-hop وخاصة 3+ hop أظهرت دقة ملحوظة أقل.

أصبح الأمر أسوأ عندما كان يجب دمج واجهات برمجية مع استرجاع المستندات. يُشير المؤلفون تحديداً إلى فشل كاشف: في بعض مهام RAG ذات القفزة الواحدة، كان GPT-OSS-120B أحياناً لا يستدعي المسترجع على الإطلاق وحاول الإجابة "من الذاكرة"، وهذا يُحتسب كخطأ في مثل هذا المعيار. أضافت السياسات طبقة أخرى من التعقيد: إما انتهكت النماذج القيود أو اتبعتها لكن فشلت في جمع المعلومات اللازمة للإجابة.

ماذا يعني هذا

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