IBM Research تحلّل مواطن إخفاق وكلاء الذكاء الاصطناعي في واجهات API والمستندات والقواعد ضمن VAKRA
حلّلت IBM Research أسباب إخفاق النماذج الوكيلية، وخلصت إلى أن المشكلة لا تكمن في استدعاء أداة واحدة، بل في سلاسل الإجراءات الطويلة. ففي VAKRA يحصل الوكلاء على 8 آلاف واجهة API ومستندات وحوارات وقيود على استخدام الأدوات. وعند نقطة التقاء اختيار endpoint والاستدلال متعدد القفزات (multi-hop reasoning) وضبط المعاملات والالتزام بالقواعد، تتراجع دقة حتى النماذج القوية بشكل حاد. وحقق GPT-OSS-120B وGemini-3-flash-preview أفضل النتائج في أجزاء منفصلة من المعيار.
معالج بواسطة الذكاء الاصطناعي من Hugging Face Blog؛ بتحرير Hamidun News
أجرت IBM Research تحليلًا مفصلًا لأسباب استمرار تعثّر حتى النماذج اللغوية القوية في مهام الأنظمة الوكيلية. ويُظهر التحليل الجديد لمعيار VAKRA أن استدعاء واجهة API واحدة بإتقان لا يكفي: فالمشكلات تبدأ حين يتعين على النموذج اجتياز عدة خطوات، واختيار مصدر البيانات الصحيح، وعدم مخالفة قواعد استخدام الأدوات.
كيف يعمل VAKRA
VAKRA معيار تنفيذي (executable benchmark) مخصص لوكلاء المؤسسات. فبدلًا من استدعاءات الدوال التبسيطية، يوفّر للنماذج بيئة عمل تضم أكثر من 8 آلاف واجهة API مستضافة محليًا، وقواعد بيانات حقيقية في 62 مجالًا، ومجموعات مستندات مخصصة لمجالات موضوعية بعينها. ولا يتطلب السيناريو النموذجي إجابة واحدة، بل سلسلة من 3–7 خطوات: جلب البيانات، واختيار الأداة المناسبة، واستخراج معلومة من مستند، وتمرير النتيجة إلى الاستدعاء التالي، ثم تجميع الإجابة النهائية في الختام فقط.
والفكرة الجوهرية أن VAKRA لا يقيّم الرد الأخير للنموذج فحسب، بل مسار أفعاله بالكامل. ففي المهام المعقدة، يتحقق النظام أولًا مما إذا كان الوكيل التزم بالقيود النصية على استخدام الأدوات، ثم يعيد تشغيل استدعاءاته في البيئة نفسها، ويقارن النتائج الوسيطة بالمرجع، وبعد ذلك فقط يقيّم الإجابة النهائية. وتكمن أهمية هذا النهج في أن الوكيل قد يخمّن الناتج النهائي بالمصادفة لكنه يصل إليه بطريق خاطئ، وهذا شبه عديم الجدوى في بيئات الإنتاج.
أربعة أنواع من المهام
يقسّم المؤلفون VAKRA إلى أربعة أنماط، يختبر كل منها طبقة مستقلة من السلوك الوكيلي. وتغطي هذه الأنماط معًا المسار الممتد من سلسلة استدعاءات API البسيطة (API-chaining) إلى الاستدلال متعدد الخطوات (multi-step reasoning) عبر واجهات API والمستندات في ظل قيود خارجية. وهذا مهم لأن كثيرًا من الوكلاء يبدون واثقين في الاستدعاءات المنفردة، لكنهم سرعان ما يتخبطون حين يتعين عليهم في آن واحد تخطيط الخطوات، والتنقل بين المصادر، والحفاظ على سياق الحوار، وتذكّر قواعد الوصول إلى الأدوات.
- Business Intelligence APIs: 2 077 مهمة في 54 مجالًا، يتعين فيها على الوكيل استدعاء 1–12 أداة بالتسلسل والتعامل بدقة مع المعاملات وتصفية البيانات.
- Dashboard APIs: 1 597 مهمة في 17 مجالًا، وتكمن الصعوبة الرئيسية فيها في اختيار endpoint الصحيح من بين 6–328 أداة متاحة.
- Multi-hop over APIs: 869 مهمة في 38 مجالًا، تُجمَّع فيها الإجابة عبر عدة انتقالات منطقية، من انتقال واحد إلى خمسة.
- Multi-source + policies: 644 مهمة في 41 مجالًا، يتناوب فيها الوكيل بين واجهات API والبحث في المستندات، ويراعي سجل الحوار، ويلتزم بقواعد نصية مثل «استخدم retriever فقط ولا تلمس الأدوات الأخرى».
أين يخطئ الوكلاء
أنفع أجزاء الدراسة هو تحديد المواضع الدقيقة التي تتعثر فيها النماذج. فالمؤلفون يصنّفون الأخطاء بحسب المراحل: اختيار أداة خاطئة، أو إغفال الوسائط المطلوبة أو اختلاقها (هلوسة)، أو قيم معاملات غير صحيحة، وأخيرًا إجابة نهائية خاطئة حتى بعد استدعاءات صحيحة.
وفي جزء BI API، جاء GPT-OSS-120B في الصدارة: فقد فهم مخططات الأدوات أفضل من غيره بوضوح، وقلّت أخطاؤه في الأسماء وفي تعبئة المعاملات. لكن حتى هناك، لم يضمن النجاح في الخطوات المنفردة نتيجة مستقرة من البداية إلى النهاية (end-to-end).
أما في المهام ذات المجموعة الكبيرة من واجهات dashboard API، فقد تفوّق Gemini-3-flash-preview على البقية، وهو أمر منطقي، إذ تكمن الأهمية هناك في تضييق قائمة الأدوات المرشحة (shortlist) والاختيار الدقيق لـ endpoint. وكلما ازداد عمق الاستدلال، تراجعت جودة جميع النماذج: فأسئلة 2-hop، وخاصة 3+ hop، خفّضت الدقة بشكل ملحوظ. وازداد الوضع سوءًا حين تطلّب الأمر الجمع بين واجهات API واسترجاع المستندات (document retrieval). ويشير المؤلفون بصورة منفصلة إلى إخفاق لافت: ففي جزء من مهام RAG بقفزة واحدة (1-hop)، كان GPT-OSS-120B لا يستدعي retriever أحيانًا على الإطلاق ويحاول الإجابة «من الذاكرة»، وهو ما يُعدّ خطأً في هذا المعيار.
وأضافت السياسات طبقة صعوبة إضافية: فإما أن النماذج كانت تخالف القيود، أو تلتزم بها لكنها لا تحصل على المعلومات اللازمة للإجابة.
ماذا يعني ذلك
يكشف VAKRA حقيقة مزعجة لكنها مفيدة بشأن الأنظمة الوكيلية: فالقدرة على إنتاج عرض توضيحي (demo) جميل لاستدعاء الأدوات (tool calling) لا تعني الجاهزية لعمليات الأعمال الحقيقية. وبالنسبة للفرق التي تختار نموذجًا لمهام الدعم أو التحليلات أو الامتثال (compliance) أو سير العمل الداخلي (workflow)، لم يعد السؤال الأهم «هل يستطيع استدعاء الأدوات؟»، بل «هل يحافظ على سلسلة إجراءات صحيحة في ظل القيود، وعبر عدة مصادر، ودون اختصارات (shortcuts) مفرطة في الثقة بالنفس؟».
Access Frontier LLMs & Multimodal AI in One Workspace
Discover NomadNet AI (nomadnet.ai) — unified access to frontier language models, research synthesis, and multimodal workflows.
أهم ما في عالم الذكاء الاصطناعي — مرة كل أسبوع
سبع قصص مهمة فعلاً هذا الأسبوع، مختارة بعناية. بلا ضجيج ولا بيانات صحفية.
تم! تحقق من بريدك للتأكيد.