موثوقية وكلاء الذكاء الاصطناعي 2026: الهيكلة تتفوق على التعليمات
٥ أغسطس ٢٠٢٦

قامت ثلاث مسودات بحثية في يوليو 2026 بقياس مصدر موثوقية وكلاء الذكاء الاصطناعي (AI agents). في أحد أنظمة الإنتاج، كانت حلقة التحقق (verification loop) مسؤولة عن +1.5 من إجمالي زيادة قدرها +11.0 نقطة في SpreadsheetBench. وفي اختبار مرجعي شمل 580 سيناريو، استعادت الحواجز الوقائية (guardrails) 19.9% من حالات الفشل؛ بينما لم تحرك قواعد "مطالبة النظام" (system-prompt) النماذج الرائدة بأكثر من نصف نقطة.
ملخص
- يقوم التحليل التفصيلي للمقاييس المتقاطعة (19 يوليو 2026) الذي أجراه فريق Leni بتفكيك وكيل مؤسسي في مرحلة الإنتاج لمعرفة أي طبقة هي التي تحقق الدقة. في SpreadsheetBench، تساهم "المطالبات" (prompting) و"الهيكلة" (scaffolding) في +9.5 من إجمالي الزيادة البالغة +11.0 نقطة؛ بينما تضيف حلقة التحقق الـ +1.5 الأخيرة.1
- في تلك التجربة، اكتشف المحقق (verifier) 8 فقط من أصل 40 خطأ كانت موجودة، ولكنه لم ينتج أي إنذارات خاطئة في 357 تأكيداً. إنه نظام متحفظ، دقيق، وبعيد كل البعد عن أن يكون شبكة أمان.1
- عند نقل خطوة "الملاحظة/المقارنة" من المحقق الصغير المدرب وإعادتها إلى النموذج الرائد الذي أنشأ المنتج، تنخفض عمليات الإنقاذ من 6 مهام إلى مهمتين. تصف الورقة البحثية هذا الاستئصال (ablation) بأنه أولي ومن تجربة واحدة.1
- يقوم GuardianAgentBench (23 يوليو 2026) بتشغيل 580 سيناريو على LangChain و LlamaIndex و Vectara. أفضل تكوين حقق: 74.8 إجمالاً — ولا يزال الوكلاء يفشلون في سيناريو واحد من كل أربعة تقريباً.2
- أدى إضافة تعليمات السلامة إلى "مطالبة النظام" (system prompt) إلى تحريك Claude Opus 4.5 بمقدار +0.4 وجعل GPT-5.2 Pro أسوأ قليلاً (−0.3). أما الحواجز الوقائية وقت التنفيذ فقد حركت كل نموذج بمقدار +2.8 إلى +7.7.2
- كلتا الورقتين الرئيسيتين صدرتا عن فرق لديها مصلحة تجارية في النتيجة — فالمؤلف المسؤول عن ورقة Leni هو الرئيس التنفيذي للشركة،1 وسبعة من مؤلفي GABench الثمانية يعملون في أحد الأطر الثلاثة التي يتم قياسها.3 ومع ذلك، فإن الأرقام تستحق الاهتمام؛ حيث يوضح قسم التحذيرات أي المصالح تؤثر على أي ادعاءات.
ما ستتعلمه
- ماذا تعني "موثوقية الوكيل" عندما يتم قياسها فعلياً
- لماذا تظل حلقة التحقق الفعالة تساوي 1.5 نقطة فقط
- لماذا قد تكون هوية المحقق أكثر أهمية من عملية التحقق نفسها
- أين يفشل الوكلاء في اختبار مرجعي يضم 580 سيناريو وستة مجالات
- لماذا ينقسم الوكلاء إلى نظامين متضادين من الفشل — إما تجاهل الأدوات أو إغراق النظام بها
- لماذا تتفوق الحواجز الوقائية على قواعد "مطالبة النظام" لكل نموذج تم اختباره
- لماذا يعاقب "عمق الدوران" (turn depth) الوكلاء بضعف شدة عدد الأدوات
- متى تجعل حلقة الإصلاح الوكيل أسوأ بدلاً من تحسينه
- ما هي التحذيرات التي تحملها هذه الأوراق البحثية الثلاث
- ما الذي يغيره كل هذا إذا كنت تقوم بإطلاق وكلاء في السوق
ما الذي تم قياسه فعلياً
معظم الكتابات حول موثوقية وكلاء الذكاء الاصطناعي هي مجرد آراء حول المعمارية مع إحصائية لمعدل الفشل مضافة في المقدمة. لكن يوليو 2026 قدم شيئاً أقل شيوعاً: ثلاث مسودات بحثية تقوم بقياس الحلقة ونشر تفاصيلها الداخلية.
الأول، من فريق Leni، هو تحليل تفكيكي. يأخذ عميلاً مؤسسياً واحداً في مرحلة الإنتاج، ويجمد الإعدادات التي تخدم حركة المرور الحقيقية، ثم يشغله مقابل ثلاثة اختبارات قياسية عامة تم اختيارها للضغط على أنماط فشل مختلفة: SpreadsheetBench Verified لأخطاء الحساب الصامتة، و BullshitBench v2 لاختلاق المقدمات، و GAIA validation split لأخطاء التسلسل عبر سلاسل الأدوات الطويلة.1 ثم يتساءل أي مكون معماري حقق أي جزء من هذا التحسن.
الثاني، GuardianAgentBench (GABench)، هو اختبار قياسي. 580 سيناريو عبر ستة مجالات — خدمة العملاء (118)، البريد الإلكتروني (117)، التقويم (105)، المالية (99)، ذكاء الأعمال (77) والمعرفة الداخلية (64) — تغطي 81 أداة فريدة و 1,177 دورة متتالية. ما يقرب من ثلث السيناريوهات (182، أو 31.4%) تحتوي على اضطرابات عدائية. ستة نماذج تشغل كل سيناريو على ثلاثة أطر عمل.2
الثالث، من Wu وزملائه، هو نتيجة قائمة على نظرية القرار حول متى يجب أن تتوقف حلقة "التحقق-والإصلاح".4 هذا الأمر مهم هنا لأنه يعزل نمط فشل تلمح إليه الدراستان الأخريان ولكن لا تقيسانه.
لا يتعلق أي من الثلاثة بأي نموذج يجب شراؤه. الثلاثة جميعاً يتعلقون بالآليات المحيطة بأي نموذج تمتلكه بالفعل — حلقة استدعاء الأدوات، عمليات التحقق، وإعادة المحاولة — وما إذا كانت هذه الآليات تعمل بشكل ملموس.
حلقة التحقق كانت تستحق 1.5 نقطة
يتفوق نظام Leni على النموذج الأساسي المجرد بفارق كبير. في SpreadsheetBench Verified حقق 91.25% مقابل 80.25% للنموذج الأساسي — زيادة قدرها 11.0 نقطة عبر 400 مهمة، وهي زيادة ذات دلالة إحصائية عند p<0.001.1 وفي BullshitBench v2 سجل 98% مقابل 91% على أحد المنفذين و 97% مقابل 87% على منفذ آخر. وفي GAIA validation سجل 75.2% pass@1 عبر 165 بنداً.
| الاختبار القياسي | n | الأساسي | النظام | التحسن |
|---|---|---|---|---|
| SpreadsheetBench Verified | 400 | 80.25% | 91.25% | +11.0 pp (p<0.001) |
| BullshitBench v2 (Sonnet) | 100 | 91% | 98% | +7 pp |
| BullshitBench v2 (Opus) | 100 | 87% | 97% | +10 pp |
| GAIA validation | 165 | ~60% (تقدير داخلي) | 75.2% pass@1 | ~+15.2 pp |
المصدر: فريق Leni، الجدول 3. فترات الثقة هي Wilson 95%. خط الأساس لـ SpreadsheetBench هو إدخال Claude Opus 4.6 المجرد من لوحة المتصدرين العامة من مارس 2026 الذي يعمل بمطالبة بسيطة من ثلاثة أسطر، وليس إعادة تشغيل داخل بيئة Leni، لذا فإن المقارنة غير مقترنة. رقم GAIA الأساسي هو تقدير داخلي من تشغيل واحد قام به المؤلفون ولم يتم اختباره إحصائياً.1
الجزء المثير للاهتمام هو ما يحدث عندما تفكك تلك الـ 11.0. المساهمة المركزية للورقة البحثية هي تحليل تفصيلي لكل طبقة، وهو تحليل غير منصف للآلية المذكورة في العنوان.
| الطبقة | SpreadsheetBench | GAIA |
|---|---|---|
| النموذج الأساسي المجرد | 80.25% | ~60% (تقدير) |
| + التلقين (prompting) والهيكلة (scaffolding) | 89.75% | ~70% مخطط–منفذ، ~74% مع التوجيه (routing) |
| + حلقة التحقق (verification loop) | 91.25% | 75.2% |
| المساهمة المنعزلة للحلقة | +1.5 نقطة مئوية (6 عمليات إنقاذ) | ~+1 نقطة مئوية |
المصدر: فريق Leni، الجدول 5. مستويات هيكل GAIA هي تقديرات داخلية لم يتم تسجيل قواعد اختيارها، لذا تشير الورقة إلى أن رقم حلقة GAIA المنعزلة هو استرشادي فقط.1
الهيكل — التلقين، التخطيط، التوجيه، الواجهات المحددة النوع (typed interfaces) — يساهم بـ +9.5 من أصل 11.0 نقطة في SpreadsheetBench.1 أما حلقة التحقق، وهي الشيء الذي سميت الورقة تيمناً به، فتضيف الـ +1.5 المتبقية.
توضح القياسات سبب ذلك. في SpreadsheetBench، تم تفعيل الحلقة في 397 من أصل 400 مهمة. أكد المدقق 389 مخرجاً (artifact) وأشار إلى 8 مخرجات. كانت جميع الإشارات الثمانية أخطاءً حقيقية، تم إصلاح 6 منها. ولكن من بين 389 تأكيداً، كان هناك 32 تأكيداً خاطئاً — أي أخطاء حقيقية سمح المدقق بمرورها.
| حكم المدقق | المخرج صحيح | المخرج خاطئ |
|---|---|---|
| مؤكد | 357 | 32 (تم تفويتها) |
| مُشار إليه كخطأ | 0 (لا توجد إنذارات خاطئة) | 8 (تم إصلاح 6) |
المصدر: فريق Leni، الجدول 4، عبر 397 مهمة تم تفعيل الحلقة فيها.1
اقرأ الهوامش: اكتشف المدقق 8 من أصل 40 خطأً كانت موجودة بالفعل. وهذا يعني معدل اكتشاف قدره 0.20. ومعدل الإصلاح، بمجرد اكتشاف الخطأ، هو 0.75. أما معدل الإنذارات الخاطئة فهو 0 من أصل 357، وهو ما تحدده الورقة بحد أقصى يبلغ حوالي 1% عند مستوى ثقة 95%.1
يضمن نموذج الموثوقية في الورقة أن الحلقة التي يكون معدل الإنذارات الخاطئة فيها صفراً أو قريباً من الصفر لا يمكن أن تجعل الأمور أسوأ، وهذا هو السبب في أنها تعامل +1.5 نقطة كمكسب حقيقي وليس مجرد ضجيج. ولكن هذا هو أيضاً السقف الصريح لمدقق متحفظ: 80% من الأخطاء الموجودة في التشغيل مرت من أمامه مباشرة. تقول القياسات الخاصة بالورقة إن رفع معدل الاكتشاف يستحق ما يصل إلى +8 نقاط إضافية، بينما رفع معدل الإصلاح يستحق +0.5 كحد أقصى — وهي حالة نادرة لنظام ينشر بدقة أين يجب أن يتوجه الجهد الهندسي التالي.
من يقوم بالتدقيق قد يكون أهم من التدقيق نفسه
تصف الورقة هذا بأنه ادعاؤها الأكثر أهمية، وهو يستند إلى تجربة استبدال المتخصصين (specialist-swap ablation). يتم التحقق من حلقة Leni بواسطة نماذج صغيرة مدربة لاحقاً — حوالي 4 مليار بارامتر للتحقق من فرق خلايا الجداول البيانات وفرز المقدمات، و1.5 مليار لاستخراج المخرجات المحددة النوع، و0.5 مليار لتوجيه الخطوات — بينما يقوم نموذج رائد (Claude Opus 4.6) بعملية التوليد.1
عند تثبيت هيكل الحلقة ونقل مرحلة الملاحظة/المقارنة مرة أخرى إلى النموذج الرائد الذي ولد المخرج، تنخفض عمليات إنقاذ SpreadsheetBench من 6 مهام إلى مهمتين. وفي BullshitBench، ينخفض الرفض الصحيح بمقدار 4-5 نقاط.1 تفسير الورقة: المولد، عندما يُطلب منه التحقق من خلايا كتبها للتو، يميل إلى تبريرها بدلاً من الإشارة إليها كأخطاء.
ثلاثة تحفظات، ذكرتها الورقة نفسها ولم يظهر أي منها في التغطية الثانوية:
- تصف هذه التجارب بأنها أولية أربع مرات — في الملخص، والمقدمة، وقسم القيود، والخاتمة.
لذا فإن النسخة الصادقة أضيق من العنوان الرئيسي: فكرة عدم استخدام النموذج المولد كمُقيّم لنفسه تستحق تقريباً أربع مهام من أصل 400، في عملية تشغيل واحدة غير مكررة. الاتجاه مدفوع بدوافع جيدة، لكن الحجم لم يتم إثباته بعد.
هناك تفصيل إضافي كشفت عنه الورقة ولكنها لم تتوسع فيه. المتخصصون تم تدريبهم لاحقاً من قواعد Qwen3 مفتوحة الأوزان عبر التقطير (distillation) من معلم Claude Opus 4.6 — و Claude Opus 4.6 هو أيضاً المنفذ الحدودي الذي يولد المنتجات البرمجية التي يقومون بفحصها.1 المراقب مستقل من الناحية المعمارية ومدرب بشكل منفصل، لكنه ليس مستمداً من سلالة غير مرتبطة.
هذا هو الشكل التشغيلي لقيود حددتها الأدبيات منذ عامين، والورقة صريحة بشأن هذا الدين التقني. فهي تبني على نتيجة Huang et al. في ICLR 2024 بأن نماذج LLMs لا تستطيع إلى حد كبير تصحيح استدلالها الخاص بدون إشارات خارجية، وعلى تأثيرات التفضيل الذاتي الموثقة في مقيمي LLM.56 وقد توصل مسح نقدي عام 2024 إلى نفس النتيجة من اتجاه آخر: التصحيح الذاتي ينجح عندما تحتوي الحلقة على تعليقات خارجية موثوقة، وليس بناءً على التقييم الذاتي الموجه فقط.7 توفر حلقة Leni بالضبط تلك الإشارة الخارجية — محرك إعادة حساب — ويقوم استئصال التبديل (swap ablation) بفحص ما يحدث عندما تظل الإشارة موجودة ولكن يتغير المراقب.
الاتجاه الذي يشير إليه كل هذا هو الابتعاد عن مجرد تحسين التوجيه (prompt) أو إطالة سلسلة الأفكار، والتوجه نحو مراقب مختلف هيكلياً — مراقب مدرب على إصدار حكم نهائي بالقبول أو الرفض بدلاً من الاستمرار في إجابة سلسة، ومراقب لم يكتب الشيء الذي يحكم عليه. يضع قسم القيود في ورقة Leni قوة هذه الأدلة بدقة: استئصالاتها "تحفز، ولكنها لا تثبت بعد" فرضية المراقب المستقل.1
مناقشة الورقة نفسها صريحة بشأن تقسيم العمل — أحد عناوين المناقشة يقول "الأوراكل (oracle) يحدد السقف؛ والمراقب يحدد الأرضية".1 أوراكل حتمي — يعيد حساب جدول بيانات في LibreOffice بدون واجهة ويقرأ القيم مرة أخرى من خلال مسار إلغاء تسلسل منفصل — هو ما يجعل الخطأ مرئياً على الإطلاق. وتأتي إرشادات الورقة بناءً على ذلك: حيثما كانت إعادة التنفيذ ممكنة، فضلها؛ وحيثما لم تكن ممكنة، استخدم مراقباً متخصصاً مستقلاً بدلاً من التقييم الذاتي بواسطة المولد.
الوكلاء لا يزالون يفشلون في سيناريو واحد من كل أربعة
عنوان GABench هو سقف، وليس لوحة صدارة. أفضل تكوين عبر ستة نماذج متطورة وثلاثة أطر عمل — Claude Opus 4.5 يعمل على Vectara — يحقق متوسط 74.8 إجمالاً.2 تتطلب الصحة الإجمالية في هذا المقياس استجابة صحيحة وتسلسلاً لاستدعاء الأدوات يطابق رسم تنفيذ الحقيقة الأرضية (ground-truth) في الاختيار والحجج والترتيب، لذا فهو معيار أكثر صرامة من دقة الإجابة وحدها.
هناك نتيجتان ثانويتان أكثر فائدة من العنوان الرئيسي.
التقويم هو أصعب مجال، وبفارق كبير: لا يوجد نموذج يتجاوز 62.0 فيه.2 لا تشخص الورقة البحثية السبب، ولكن عمل التقويم هو أوضح حالة في الاختبار المرجعي للمهام التي تقع فيها عملية التحقق من شرط مسبق مطلوب — هل هذه الخانة فارغة، هل هناك تعارض — بين الطلب وعملية الكتابة.
اختيار إطار العمل لا يهم في الغالب — مع وجود تحفظ لم تشر إليه الورقة. ادعاؤها هو أنه ضمن أي نموذج معين، تختلف الدرجات بحد أقصى 2-3 نقاط عبر LlamaIndex و LangChain و Vectara، وهو ما تعتبره دليلاً على أن الفجوات مدفوعة بالنموذج وليس بإطار العمل.2 وبالنظر إلى التباين في الجدول 5 الخاص بها، فإن هذا ينطبق على خمسة من النماذج الستة ولكن ليس على DeepSeek-V3.2، حيث يتراوح متوسط الأداء العام من 63.0 إلى 66.7 — بفارق 3.7 نقطة. وعلى مستوى كل مجال، يزداد التباين بشكل أكبر: تتراوح درجة خدمة العملاء لـ DeepSeek من 61.4 على Vectara إلى 75.2 على LangChain، وهو تأرجح بمقدار 13.8 نقطة بسبب إطار العمل وحده.
لا يزال الاستنتاج العام قائماً في المتوسط: اختيار النموذج هو المهيمن، ومعظم الفرق لن تستفيد كثيراً من تغيير أدوات التنسيق (orchestrators). ولكن عبارة "بحد أقصى 2-3 نقاط" هي ملخص الورقة لبياناتها وليست خاصية في البيانات نفسها — فإذا كان عبء العمل لديك يشبه مجالاً واحداً بدلاً من متوسط الاختبار المرجعي، فقد يكون إطار العمل ذا قيمة أكبر من ذلك بكثير. كما أنه، كما يوضح قسم التحفظات، استنتاج نشره مؤلفون يقومون ببناء أحد أطر العمل الثلاثة التي تتم مقارنتها.
نظامان للفشل: تخطي الأدوات، أو الإفراط في استخدامها
يصنف GABench كل تنفيذ فاشل إلى خمسة أنواع، ويقسم التوزيع النماذج الستة إلى مجموعتين تفشلان في اتجاهين متعاكسين.
تفشل مجموعة واحدة بشكل ساحق عن طريق عدم استدعاء أداة كان يجب استدعاؤها. وبالقراءة المباشرة للجدول 6، فإن "فقدان استدعاء الأداة المطلوبة" يمثل 54.8-57.2% من إخفاقات GPT-5.2 Pro و GPT-OSS-120B، و 52.1-54.7% من إخفاقات Gemini-3-Pro، و 45.8-48.0% من إخفاقات Claude Opus 4.5.2 هذه النماذج تفهم الطلب ثم تجيب من خلال أوزانها الخاصة بدلاً من اللجوء إلى الأداة.
التقسيم هنا يعتمد على طبيعة الفشل، وليس على المركز في قائمة المتصدرين — حيث يظهر GPT-OSS-120B نمط "تخطي الأداة" بينما يقع في أدنى مستوى في الاختبار المرجعي من حيث الدقة الإجمالية.2
أما المجموعة الأخرى فتعكس ذلك. يظهر DeepSeek-V3.2 و Qwen3-Max معدلات فقدان استدعاء الأدوات بنسبة 35.5-39.7%، لكنهما يعوضان ذلك باستدعاءات متكررة للأدوات بنسبة 28.7-32.2% — مقابل 20.2-22.4% للنماذج الأربعة الأخرى.2 إنها تلجأ للأدوات باستمرار. وما يميزهما هو ما إذا كانا يختاران الشيء الخاطئ أيضاً: يتراوح معدل الاختيار غير الصحيح لـ DeepSeek بين 23.6-25.3%، وهو الأعلى في الاختبار المرجعي، بينما يتراوح Qwen3-Max بين 13.9-15.1%، وهو ما لا يختلف عن النماذج التي تتخطى الأدوات. صياغة الورقة نفسها كانت دقيقة — هذه النماذج تختار أو تكرر بشكل غير صحيح.
هناك رقم واحد ينطبق على كل نموذج: الترتيب غير الصحيح للأدوات هو أندر أنواع الفشل بنسبة 0.6-4.4%، وهو الأصغر من بين أنواع الفشل الخمسة في جميع التكوينات الثمانية عشر.2 بهذا المقياس — من أداة واحدة إلى سبع أدوات، ومن دورة واحدة إلى ثماني دورات — أصبح التسلسل شبه محلول، بينما لا تزال التغطية والاختيار غير محلولة. إذا كانت تقييمات الوكيل (agent evals) لديك لا تزال تعطي وزناً كبيراً لـ "هل استدعى الأدوات بالترتيب الصحيح"، فأنت تعطي وزناً للشيء الذي تتقنه هذه النماذج بالفعل.
الأرقام المذكورة أعلاه مأخوذة من الجدول 6 بدلاً من الاقتباس من النصوص المحيطة، لأن الاثنين لا يتفقان تماماً في هذا المقياس. العديد من النطاقات المذكورة في الورقة لا تشمل بيانات جدولها الخاص: فهي تعطي معدلات نسيان استدعاء الأدوات (missing-tool-call) بنسبة "55-57%" بينما يحتوي الجدول على 54.8-57.2، و"36-40%" بينما يحتوي الجدول على 35.5-39.7، والاستدعاءات المتكررة بنسبة "29-33%" بينما يحتوي الجدول على 28.7-32.2. يظهر نفس النمط في فئات النماذج، حيث تم تجميع GPT-5.2 Pro و Qwen3-Max عند "68-72" رغم أن اثنتين من درجات Qwen3-Max الثلاث تقعان تحت 68.
المثال الأكبر يستحق التوضيح، لأنه نوع الأرقام التي يتم تكرارها. يصف المقدمة النماذج الأضعف بأنها تخطئ في الاختيار وتفرط في الاستدعاء في "ما يصل إلى 58% من الإخفاقات مجتمعة". وبجمع أخطاء الاختيار والاستدعاءات المتكررة لكل صف في الجدول 6، فإن أعلى إجمالي في أي تكوين منفرد هو 56.4% — وهو الخاص بـ DeepSeek-V3.2 على LangChain. يبدو أن الرقم 58 هو نتيجة جمع قيمتين عظميين حدثتا في صفوف مختلفة — ذروة أخطاء الاختيار بنسبة 25.3% على Vectara زائد ذروة التكرارات بنسبة 32.2% على LangChain، وهو ما يصل إلى 57.5. لا يوجد تكوين واحد يصل إلى أي من هذين الرقمين. قسم الاستنتاج في الورقة نفسها، الذي يعطي الاختيار "حتى 25%" والتكرارات "29-33%"، هو أقرب إلى الجدول من المقدمة.2
الحواجز الوقائية (Guardrails) تتفوق على تعليمات السلامة لكل نموذج تم اختباره
تقارن تجربة الدفاع في GABench بين وسيلتين للتخفيف مقابل خط أساس بدون دفاع: تعليمات السلامة المضافة إلى موجه النظام (system prompt)، والحواجز الوقائية وقت التنفيذ التي تعترض كل استدعاء مقترح للأداة قبل تشغيله.
| النموذج | تحسن موجه النظام | تحسن الحواجز الوقائية | الفجوة |
|---|---|---|---|
| Claude Opus 4.5 | +0.4 | +5.7 | 5.3 |
| Gemini-3-Pro | +0.3 | +2.9 | 2.6 |
| GPT-5.2 Pro | −0.3 (تراجع) | +2.8 | 3.1 |
| DeepSeek-V3.2 | +5.5 | +7.7 | 2.2 |
| Qwen3-Max | +0.8 | +5.3 | 4.5 |
| GPT-OSS-120B | +1.0 | +5.4 | 4.4 |
كلا التحسنين هما فوق خط الأساس بدون دفاع؛ وعمود الفجوة هو الفرق، المحسوب هنا. المصدر: تسميات بيانات الشكل 8 في GABench.2
هناك نتيجتان تظهران بوضوح من هذا الجدول. أما النتيجة الثالثة، التي ذكرتها الورقة، فلا تظهر.
النماذج القادرة لا تستفيد تقريباً من مطالبتها بأن تكون حذرة — بل إن GPT-5.2 Pro يتراجع في الواقع، وهو ما فسره المؤلفون بأن التعليمات المضافة تسببت في ضوضاء في سلوك كان النموذج قد استوعبه بالفعل. أما DeepSeek-V3.2، وهو النموذج الذي سجل أعلى معدل في اختيار الأداة الخاطئة، فهو الأكثر استفادة من التوجيه (prompting)، لأن الإرشادات الصريحة لاستخدام الأدوات تعالج بالضبط هذا الضعف — وقد ربط المؤلفون بينهما بأنفسهم.
الادعاء الذي لا يصمد أمام الشكل الخاص به هو صياغة الإطار. تذكر الورقة أن الفجوة بين الاستراتيجيتين "تكون في أوسع نطاق بالنسبة للنماذج الأقوى — 5.3 نقطة لـ Claude Opus 4.5 و 2.6 نقطة لـ Gemini-3-Pro".2 وبالفعل، فإن 5.3 الخاصة بـ Claude هي الأوسع بين الستة. لكن 2.6 الخاصة بـ Gemini هي ثاني أضيق فجوة بين الستة، بعد Qwen3-Max عند 4.5 و GPT-OSS-120B عند 4.4 — وهي نماذج تصنفها الورقة في الفئات المتوسطة والمتأخرة على التوالي. النمط ينطبق على النموذج الأعلى وينكسر فوراً تحته. ما تدعمه البيانات فعلياً هو الادعاء الأبسط: الحواجز الوقائية تتفوق على تعليمات الموجه لكل نموذج تم اختباره، بفارق يتراوح بين 2.2 و 5.3 نقطة.
الأرقام الدقيقة هي ما يجعل نتيجة الحواجز الوقائية (guardrails) أكثر من مجرد شعار. عند القياس على Claude Opus 4.5 في LlamaIndex: من بين 151 سيناريو كانت تفشل في الأصل، تم تحويل 30 منها إلى نجاحات — أي معدل استرداد بنسبة 19.9%. ومن بين 429 سيناريو كانت تنجح في الأصل، تم حظر 2 منها بشكل خاطئ، وهو معدل إيجابيات كاذبة بنسبة 0.5%.2
هناك تفصيل يستحق المعرفة قبل نسخ التصميم: تصف الورقة هذه الحواجز الوقائية بأنها "خفيفة الوزن وقائمة على القواعد" في قسم التصميم، ولكن إعدادها التجريبي ينص على أن جميع الثلاثة مدعومون بواسطة Claude Sonnet 4.5 بإعدادات افتراضية.2 إنها فحوصات مدعومة بـ LLM، وليست أدوات تحقق حتمية، والثلاثة يعملون بالتزامن قبل كل استدعاء للأداة — في LlamaIndex فقط، كإضافة مخصصة لـ llama-index-core. وهذا يمثل ملف تكلفة وزمن استجابة مختلف جوهرياً — ثلاثة استدعاءات إضافية للنموذج لكل خطوة أداة، بالإضافة إلى ما يصل إلى تكرارين للمحاولة — وهذا يعني أن "التدخل الهيكلي" الذي يتم قياسه هو هيكلي من حيث مكان وجوده، وليس فيما يتكون منه. الفحوصات الثلاثة نفسها بسيطة بما يكفي لإعادة تنفيذها بشكل حتمي للتحقق من المخطط (schema validation)، وهو المكان الذي تكمن فيه معظم قيمة التحقق من الوسائط (argument-validation).
عمق الدور يعاقب الوكلاء بضعف شدة عدد الأدوات
يغير GABench التعقيد على محورين. بمتوسط عبر الأطر الثلاثة، ينخفض Claude Opus 4.5 من 78.2 عند توفر أداة واحدة إلى 62.3 عند سبع أدوات — انخفاض بمقدار 15.9 نقطة. أما بالنسبة لعمق الدور، فينخفض من 82.3 عند دور واحد إلى 51.2 عند سبعة أدوار — أي 31.1 نقطة.2
تكلفة عمق الدور تعادل تقريباً ضعف تكلفة حجم مجموعة الأدوات. تفسر الورقة ذلك على أنه نتيجة للتخطيط بدلاً من كونه نتيجة للسياق — فإدارة التبعيات متعددة الخطوات ترهق الوكلاء أكثر من إزالة الغموض بين العديد من الأدوات.2
تصحيح واحد لصياغة الورقة، بما أنها تظهر في الملخص وستتكرر: يصف كل من الملخص والقسم 5.2.2 الأداء بأنه يتدهور بشكل رتيب (monotonically) على كلا المحورين. وبالنظر إلى تسميات البيانات في الشكل 6 من الورقة نفسها، فإن منحنى عدد الأدوات يسير كالتالي: 78.2، 72.5، 73.8، 71.4، 68.9، 65.3، 62.3 — أي أنه يرتفع بين أداتين وثلاث أدوات. أما منحنى عمق الدور (82.3، 72.2، 70.1، 63.4، 58.7، 53.2، 51.2) فهو رتيب؛ بينما منحنى الأدوات ليس كذلك. النقاط النهائية، وبالتالي المقارنة الرئيسية بين المحورين، لم تتأثر.
من الجدير بالذكر الحفاظ على دقة المقياس. مجموعات أدوات GABench تتراوح من 1 إلى 7، لذا فإن هذا التدهور يحدث في نظام الكتالوجات الصغيرة، وليس في نظام مئات الأدوات الذي تمت دراسته في أماكن أخرى — وقد غطينا ذلك بشكل منفصل في كم عدد الأدوات التي يمكن لوكيل الذكاء الاصطناعي التعامل معها، حيث تنهار دقة التوجيه عند ترتيب مقدار مختلف تماماً. كلتا النتيجتين تشيران إلى نفس الاتجاه؛ لكنهما تقيسان نهايات مختلفة من المنحنى. كما تتماشى نتيجة الأفق الطويل مع ما أظهره OSWorld 2 حول وكلاء استخدام الكمبيوتر في تسلسلات المهام الممتدة.
عندما تجعل حلقة الإصلاح الأمور أسوأ
من الآمن تشغيل مدقق Leni لأن معدل الإنذارات الكاذبة فيه صفر فعلياً. ويتناول وو وزملاؤه ما يحدث عندما لا يكون الأمر كذلك.
صياغتهم دقيقة: عندما يكون كل من المدقق والمصلح "مشوشين" (noisy)، يمكن للإصلاح أن يتلف الخطط التي كانت صحيحة بالفعل، و"يستمر القبول المُبلغ عنه في الارتفاع بينما تنخفض الصلاحية الحقيقية".4 تُبلغ الحلقة عن ثقة متزايدة بينما تزداد الأمور سوءاً — وهي الحالة المرضية الدقيقة التي تجعل حلقات إعادة المحاولة الساذجة تبدو منتجة في عارض التتبع (trace viewer) بينما هي في الواقع تدهور المخرجات.
يقوم مقترحهم، VRR-Stop، بنمذجة القبول الخاطئ والرفض الخاطئ للمدقق بشكل منفصل عن سلوك "الإصلاح مقابل الضرر" للمصلح، ثم يقوم بالتثبيت أو الإصلاح بناءً على إشارة الربح الهامشي الحقيقي بدلاً من عدد جولات ثابت. وفي إعداد ضغط على GSM8K، يحسن الصلاحية الحقيقية النهائية بنسبة 60.6 نقطة مئوية مقارنة بجدول إصلاح ثابت من خمس جولات، بتكلفة متوسطة تبلغ 0.72 جولة إصلاح.4
هذا الرقم 60.6 يأتي من اختبار ضغط مصمم على مسائل رياضيات المرحلة الابتدائية، وليس من عبء عمل وكيل إنتاجي، ولا ينبغي قراءته كنتيجة عامة للوكلاء. الدرس القابل للنقل أصغر وأكثر فائدة: تحديد عدد ثابت من محاولات إعادة المحاولة هو "رائحة تصميم" (design smell) سيئة. إذا لم تتمكن من تحديد معدل الرفض الخاطئ للمدقق الخاص بك، فلا يمكنك معرفة ما إذا كانت محاولة إعادة المحاولة الثالثة تساعد حقاً.
التحذيرات التي تحملها هذه الأرقام
كلتا الورقتين الرئيسيتين تأتيان من فرق لديها مصلحة في النتيجة، ولم تخضع أي منهما لمراجعة الأقران في المسار الرئيسي.
يقوم GABench بتقييم منصة مؤلفيه أنفسهم، ولا يذكر ذلك في نص الورقة. سبعة من مؤلفي الورقة الثمانية هم موظفون في شركة Vectara, Inc.، بما في ذلك المؤلف المسؤول الذي يكون عنوان الاتصال الخاص به تابعاً لـ vectara.com؛ والثامن في جامعة ولاية أيوا.3 Vectara هي واحدة من ثلاثة أطر عمل تم اختبارها، والنتيجة الرئيسية الوحيدة — التكوين الأفضل أداءً بنسبة 74.8 — هي منصة Vectara نفسها. لا تحتوي الورقة على بيان تضارب المصالح، ولا بيان تمويل، ولا قسم شكر وتقدير.
هناك أمران يسيران في الاتجاه المعاكس، وكلاهما يستحق الذكر. عمل الحواجز الواقية (guardrail) — وهو المساهمة الأكثر فائدة في الورقة — تم تنفيذه في LlamaIndex وليس في Vectara. كما أن Vectara هي الإطار الأفضل لثلاثة من النماذج الستة؛ بينما يتفوق LangChain في الثلاثة الأخرى. هذا ليس اختباراً تم التلاعب به للوصول إلى نتيجة معينة، ولكنه مورد يقوم باختبار نفسه دون الإفصاح عن ذلك.
من الجدير بالذكر لأي شخص يتحقق من هذا: تظهر الانتماءات في حاشية سفلية في الصفحة 1 من ملف PDF وهي غائبة عن عرض HTML الخاص بـ arXiv لنفس الورقة، وهو ما سيراه معظم القراء ومعظم أدوات التلخيص الآلية.
نتائج الحواجز الواقية هي إثبات مفهوم على إطار عمل واحد. تستخدم الورقة عبارة "إثبات مفهوم" (proof of concept) فيما يتعلق بالحواجز الواقية أربع مرات، وهي موجودة فقط كإضافة مخصصة لـ LlamaIndex.2 لذا فإن "+2.8 إلى +7.7 عبر جميع النماذج الستة" تعني جميع النماذج الستة على إطار عمل واحد، ورقم الاسترداد 19.9% هو نموذج واحد على إطار عمل واحد. الاتجاه مدعوم جيداً؛ لكن العمومية ليست كذلك بعد.
لا توجد عمليات تشغيل متكررة، ولا هوامش خطأ. يقوم GABench بتشغيل كل نموذج من خلال API الرسمي الخاص به بمعاملات افتراضية، بما في ذلك درجة الحرارة الافتراضية، ولا يذكر أي فترات ثقة، ولا تباين، ولا تجارب متكررة.2 هذا أمر مقبول بالنسبة للتأثيرات الكبيرة — الفجوة البالغة 11.8 نقطة بين أفضل وأسوأ التكوينات، وانهيار عمق الدوران البالغ 31 نقطة. لكنه ليس كافياً لدعم المقارنات الدقيقة، بما في ذلك ادعاء إطار العمل البالغ 2-3 نقاط وترتيب التكوينات التي تفصل بينها نقاط قليلة. تعامل مع الفجوات الصغيرة هنا على أنها غير محسومة. (في المقابل، تذكر ورقة Leni فترات ثقة Wilson في جميع أنحائها وتحدد حساسية التشغيل من دورة إلى أخرى بنحو ±3 نقاط.1)
التقييم من نفس العائلة. عملية توليد السيناريوهات، والجزء التلقائي من التحقق من السيناريوهات، والمُقيّم الآلي، وجميع الحواجز الوقائية الثلاثة تعمل على Claude Sonnet 4.5، بينما يعد Claude Opus 4.5 أحد النماذج الستة التي تم تقييمها.2 هناك إجراءان تخفيفيان يستحقان الذكر: كل سيناريو تم الاحتفاظ به تمت مراجعته بشكل مستقل من قبل اثنين على الأقل من المراجعين البشريين، كما تم التحقق من المُقيّم نفسه مقابل مراجعات بشرية في 60 حالة عينة بنسبة توافق بلغت 93.3%. هذا تحقق حقيقي، على عينة صغيرة، ولم تذكر الورقة أي إحصائية لاتفاق المراجعين.
ورقة Leni هي عبارة عن مورد يقيم نفسه، وهذا ما ذكرته في ملخصها. المؤلف المسؤول هو الرئيس التنفيذي ومؤسس شركة Leni Inc؛ نفس الفريق الذي بنى النظام، وأدار الحملات، ودرب المتخصصين.1 كما تم بناء المكونات لعائلات مهام إنتاجية تتداخل مع ما تقيسه المعايير المرجعية — وصياغة المؤلفين هي أن الادعاء الذي يمكن الدفاع عنه ليس أنها "غير مضبوطة" (untuned) ولكنها "غير مضبوطة وفقاً لهذه المعايير المرجعية". لقد نشروا فحص تلوث لـ 30,104 رسالة إنتاجية مقابل 365 بند تقييم (تم تحديد أربعة، وجميعها تعود لجلسات اختبار داخلية في مارس 2026)، وأشاروا إلى أن مجموعات بيانات تتبع سجلات العمل ومسارات الأدوات لم يتم مسحها بعد، ونشروا سجلات التشغيل علناً — بما في ذلك التشغيلات غير المواتية والتي تم استبدالها. هذا أقصى قدر من الإفصاح الذي يمكن أن يقدمه تقييم ذاتي، وهو ليس نفس الشيء مثل التكرار المستقل، وهذا ما ذكره قسم القيود في الورقة أيضاً.
رقم GAIA له نطاق تلوث، وليس قيمة نقطية واحدة. إجابات التحقق عامة. قام المؤلفون بمسح جميع المسارات الـ 803 المخزنة بحثاً عن روابط URL مصدرية مشتقة من GAIA ووجدوا 25 رابطاً عبر 12 مهمة؛ سبعة تشغيلات محددة تقع ضمن الاختيار المبلغ عنه وجميع السبعة سجلت إجابات صحيحة. اعتبار كل واحدة منها كفشل يعطي حداً أدنى متحفظاً بنسبة 70.9%، مقابل نسبة 75.2% المبلغ عنها.1 كما أشاروا إلى أن مجموعة الاختبار المخفية لم يتم تقديمها بعد.
هذه الأرقام أقدم مما تبدو عليه. أجريت تقييمات Leni خلال شهري مارس وأبريل 2026 ونُشرت في 19 يوليو.1
تم تصحيح أحد الأرقام المبلغ عنها في الورقة نفسها. أعطى تقرير سابق للشركة نسبة 77.6% في تقسيم GAIA. وأثناء إعداد هذه الورقة، أعاد الفريق تصدير جميع المسارات الـ 803 المخزنة وأعاد تقييمها باستخدام المصحح الرسمي — الذي أعاد إنتاج جميع الدرجات الـ 218 المسجلة بالفعل — ووجدوا أن نسبة 77.6% كانت قد خلطت بين اختيار "أفضل k" في المستوى 1 وتقييم "المحاولة الواحدة" في المستوى 2. لذا قاموا بإلغاء هذا الرقم وأبلغوا عن نسبة نجاح pass@1 بلغت 75.2% بدلاً من ذلك.1 هذا يعتبر علامة على المصداقية بدلاً من أن يكون علامة خطر، ولكنه أيضاً تذكير بأن أرقام الوكلاء (agents) التي ينشرها الموردون يتم إعادة صياغتها.
ما الذي يغيره هذا إذا كنت تبني وكلاء (agents)
- قم بقياس أداء المُحقق، وليس الوكيل فقط. معدل الرصد، ومعدل الإصلاح، ومعدل الإنذارات الكاذبة هي ثلاثة أرقام منفصلة بثلاثة حلول مختلفة. تقول بيانات Leni أن نقاطها الثماني القادمة تكمن في معدل الرصد وبحد أقصى 0.5 في معدل الإصلاح؛ لا يمكنك معرفة ما يعادل ذلك لديك بدون مصفوفة الارتباك (confusion matrix). تجعل البنية التحتية للتتبع هذا الأمر ممكناً — راجع دليلنا حول تتبع OpenTelemetry لوكلاء Claude.
- لا تجعل النموذج المولد هو نفسه المُدقق. الدليل على ذلك هو تجربة استئصال أولية واحدة، لذا تعامل مع الأمر كإجراء وقائي بسيط بدلاً من نتيجة نهائية — ولكنه إجراء غير مكلف: استخدم نموذجاً مختلفاً لخطوة الملاحظة/المقارنة. النماذج الأصغر مناسبة، وهي أرخص ثمناً.
max_retries = 3 المختار بناءً على "الحدس" هو رقم لم يقسه أحد؛ أما القاعدة المرتبطة بملف الأخطاء الفعلي للفاحص الخاص بك فهي قاعدة يمكنك الدفاع عنها.الخلاصة
كُتبت الأوراق الثلاث بشكل مستقل، حول مشكلات مختلفة، وبطرق مختلفة، لكنها تشير جميعاً إلى نفس النقطة: الدقة تكمن في الهيكل المحيط بالنموذج، وليس في ما تطلب من النموذج فعله.
الرقم الأكثر قابلية للاقتباس هو +1.5 — وهي المساهمة المنعزلة لحلقة تحقق (verification loop) تعمل، داخل نظام حقق 11.0 في نفس الاختبار المرجعي. إذا قرئت وحدها قد تبدو وكأنها تفنيد. لكنها ليست كذلك. تلك الحلقة كان لديها معدل إنذار خاطئ صفر، وأنقذت مهام كانت عيوبها غير مرئية وقت الكتابة، وتشير بياناتها الخاصة إلى أن وجود مقارن أفضل يستحق ما يصل إلى 8 نقاط إضافية.
النتيجة التي تليها هي التي تستحق الجدل، والورقة حذرة بطريقة لا تظهر في ملخصاتها: في تجربة استئصال (ablation) أولية وبدورة واحدة، أدى نقل عملية التحقق إلى النموذج الذي كتب الإجابة إلى خفض عمليات الإنقاذ من ست مهام إلى مهمتين. إذا ثبت ذلك، فإن الموثوقية لم تأتِ من مجرد التحقق، بل أتت من التحقق بواسطة مراقب متخصص ومنفصل عن المولد — والتجربة التي ستخبرك أي من هاتين الخاصيتين هي التي تقوم بالعمل لم تُجرَ بعد.
هذا قرار معماري، وهو غير مكلف. مما يجعله أمراً غريباً أن يظل جزء كبير من المجال يحاول حله باستخدام system prompt أطول.
Footnotes
-
Arunabh Dastidar وفريق Leni، "Where Does Agent Reliability Come From? A Cross-Benchmark Decomposition of Verification Loops, Specialist Models, and Scaffolding in a Production Enterprise Agent," arXiv:2607.17044v1 [cs.SE]، تم تقديمه في 19 يوليو 2026. أجريت التقييمات في مارس–أبريل 2026. الأشكال المذكورة: الجدول 3 (التحسن)، الجدول 4 (مصفوفة ارتباك الموثق)، §4.1 (الحلقة الحتمية)، §5.4 (التلوث)، §6.2 (تجهيز SpreadsheetBench)، §6.3 (تصحيح GAIA). ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24
-
فيشال إيشوار نايك، تشينيو شو، دونا دونج، حسين حسن، أبهيشيك برادان، أوفير ميندليفيتش، طلعت شفعت وهمايون إرشاد، "GuardianAgentBench: Where Agents Fail and How to Guard Them," arXiv:2607.20982v1 [cs.AI]، تم تقديمه في 23 يوليو 2026. الأشكال المذكورة: §3.3 (التحقق من القاضي)، §3.5 (إحصائيات المعيار)، §4 (تصميم حاجز الحماية)، §5.1 (الإعداد)، §5.2.1 (النتائج الرئيسية والجدول 6)، §5.2.2 (التعقيد)، §5.2.3 والجدول 7 (الدفاعات). ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25
-
تظهر انتماءات المؤلفين في حاشية سفلية في الصفحة الأولى من ملف GABench PDF — "Vectara, Inc., Palo Alto, CA, USA" و "Iowa State University, Ames, IA, USA" — والتي تسجل أيضًا قبول الورقة في ورشة عمل ICML 2026 حول أنماط الفشل في الذكاء الاصطناعي الوكيلي (agentic AI). هذه الحاشية لا تظهر في عرض HTML الخاص بـ arXiv. تم التأكد من الأدوار الفردية بشكل مستقل: Vishal Ishwar Naik، مهندس تعلم آلي في Vectara؛ Ofer Mendelevitch، رئيس علاقات المطورين في Vectara. ↩ ↩2 ↩3
-
Yitao Wu, Si Shen, Rui Yang, Hong Peng and Bin Hu, "Verify, Repair, Repeat, or Stop? Robust Stopping for Noisy Verify-Repair Loops in LLM Agents," arXiv:2607.17641v1 [cs.AI], تم تقديمها في 20 يوليو 2026. مدرجة تحت المراجعة. ↩ ↩2 ↩3 ↩4
-
Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song and Denny Zhou, "Large Language Models Cannot Self-Correct Reasoning Yet," ICLR 2024. نسخة أولية: arXiv:2310.01798. مُشار إليها كمرجع [7] في ورقة Leni. ↩ ↩2
-
Arjun Panickssery, Samuel R. Bowman and Shi Feng, "LLM Evaluators Recognize and Favor Their Own Generations," NeurIPS 2024. نسخة أولية: arXiv:2404.13076. مُشار إليها كمرجع [12] في ورقة Leni. ↩ ↩2
-
Ryo Kamoi, Yusen Zhang, Nan Zhang, Jiawei Han and Rui Zhang, "When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs," Transactions of the Association for Computational Linguistics 12 (2024). نسخة أولية: arXiv:2406.01297. ↩



