🤖 machine learning

AlloBench: Measuring Online Tool Allocation Capability in LLM Agents

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

المؤلفون الأصليون: Daniel Wang, Andrew Xu

نُشر 2026-07-28

📖 3 دقيقة قراءة☕ قراءة في استراحة قهوة

CC BY 4.0

المؤلفون الأصليون: Daniel Wang, Andrew Xu

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

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

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

النتائج تشبه إلى حد كبير مشاهدة طالب عبقري يتفوق في اختبار رياضيات، ولكنه يفشل بعد ذلك في تطبيق هذا المنطق على الحياة الواقعية. عندما طلب الباحثون من الذكاء الاصطناعي لعب اللعبة بطريقة تجريدية بسيطة—مثل فرز الكرات الملونة في دلاء—كانت النماذج العليا (بما في ذلك Claude Haiku وClaude Opus وGPT-5) جيدة بشكل مفاجئ. لقد انتظروا بصبر، وراقبوا تكرار الألوان، ولم يبنوا "دلوًا" إلا عندما تأكدوا من أن الأمر يستحق العناء. لقد تصرفوا كمستثمرين مثاليين.

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

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

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

ملخص تقني: ALLOBENCH: قياس قدرة تخصيص الأدوات عبر الإنترنت في وكلاء النماذج اللغوية الكبيرة (LLM Agents)

بيان المشكلة

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

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

المنهجية: AlloBench

قدم المؤلفون AlloBench، وهو اختبار معياري مزدوج مصمم لاختبار التخصيص الواعي بالميزانية عبر "سلم التأطير" (framing ladder) الذي ينتقل من السياقات المجردة إلى السياقات البنائية الكاملة.

الإعداد التجريبي

تدفق المهام: تتكون الحلقة من تسلسل مخفي من $T=60$ مهمة مستمدة من $N=8$ فئات كامنة.
التوزيع: ثلاث فئات هي "ساخنة" (تكرار عالٍ، ~13–23 ظهورًا) وخمس فئات هي "فخاخ" (تكرار منخفض، ~1–6 ظهورات).
الميزانية: يمتلك الوكيل ميزانية ثابتة قدرها $B=3$ لإنشاء الأدوات.
الآلية: في كل دور، يلاحظ الوكيل حالة من المهمة. إذا كانت المهمة تنتمي إلى فئة لا يوجد لها أداة حالية والميزانية متبقية، يختار الوكيل إما الالتزام (إنشاء أداة، واستهلاك الميزانية) أو التجاوز (الانتظار). إذا كانت الأداة موجودة بالفعل، يتم تطبيقها تلقائيًا.
المكافأة: يحصل الوكيل على نقطة واحدة لكل حالة مهمة يتم حلها (إما بواسطة أداة موجودة مسبقًا أو عبر التجاوز إذا لم تكن هناك حاجة لأداة، رغم أن التجاوز يحقق 0 نقطة لتلك الحالة المحددة). الهدف هو تعظيم المنفعة الإجمالية من خلال التقاط أكبر عدد ممكن من حالات الفئات "الساخنة" مع تجنب فئات "الفخاخ".

سلم التأطير

لعزل مكان انهيار قدرات التخصيص، يتم عرض نفس تدفقات المهام في أربعة أطر مختلفة:

R0 (مجرد): يرى النموذج كرات ملونة ويختار KEEP/PASS (احتفاظ/تجاوز) عبر نص حر. لا يوجد كود برمجي متضمن.
R1 (تقريري): يرى النموذج مشكلات عددية ويقوم باستدعاءات أداة تقريرية KEEP/PASS. لا يوجد توليد كود.
R2 (كود): يجب على النموذج توليد دالة بايثون غير فارغة solve(inputs) للمطالبة بفئة ما. لا يتم تقييم صحة الكود من أجل المكافأة، ولكن التوليد مطلوب.
R3 (كامل): يجب على النموذج كتابة وتشغيل وإعادة استخدام سكربت. تتطلب الصحة البرمجية لكي تُحتسب المهمة.

المقاييس

معدل الالتزام عند الرؤية الأولى (First-Sight Commitment Rate): نسبة الالتزامات التي تمت عند أول ظهور للفئة. السلوك الأمثل يقتضي انتظار أدلة التكرار؛ لذا فإن المعدلات العالية تشير إلى سلوك "متلهف" (غير أمثل).
الدرجة (Score): نسبة تنافسية تقارن المنفعة المحققة بالحد الأقصى النظري المستقبلي (مجموع أحجام أكبر $B$ من الفئات).

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

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

النتائج التجريبية

قيمت الدراسة أربعة نماذج رائدة (Claude Haiku 4.5، Claude Opus 4.8، GPT-5.4-mini، GPT-5.6 Sol) ونموذج مفتوح المصدر (Qwen2.5-Coder-14B).

1. الكفاءة المجردة مقابل فشل ميزانية الأدوات

أظهرت جميع النماذج الأربعة الرائدة تخصيصًا قريبًا من الأمثل في إطار R0 (المجرد)، حيث انتظروا أدلة التكرار في أكثر من 70% من الحالات قبل الالتزام. ومع ذلك، انهار هذا الكفاءة في R3 (البناء الكامل). في R3، لم ينتظر أي نموذج التكرار لأكثر من 12% من الوقت؛ بل التزموا تقريبًا فور رؤية الحالة الأولى.

2. تحديد موقع نمط الفشل

من خلال تحليل الانتقال عبر سلم التأطير، حدد المؤلفون المحفز المحدد للفشل:

Haiku، Opus، و GPT-5.4-mini: حافظت هذه النماذج على تخصيص معقول في R0 و R1 (التقريري). انهار قدرة التخصيض لديها بشكل حاد عند R2 (الكود)، حيث طُلب منها إصدار كود، حتى وإن لم يتم التحقق من صحة الكود.
GPT-5.6 Sol: حافظ هذا النموذج على بعض قدرة التخصيص في R2 (39% معدل التزام عند الرؤية الأولى) ولكنه انهار فقط عند R3 (البناء الكامل)، حيث يجب تنفيذ السكربتات والتحقق منها.

3. ما بعد التدريب والتعميم

قام المؤلفون بضبط نموذج Qwen2.5-Coder-14B باستخدام PPO لتعظيم المنفعة في إطار R0 المجرد.

النجاح: قلل النموذج المدرب بعد الضبط من معدل الالتزام عند الرؤية الأولى في R0 من 74% إلى 6% وعمم هذا السلوك على تغييرات لغوية (مثل العملات بدلاً من الكرات).
الفشل: لم تنتقل السياسة المتعلمة إلى R1 (التقريري) أو R2 (الكود). على الرغم من تدريب النموذج ليكون انتقائيًا في المصطلحات المجردة، إلا أنه عاد إلى الالتزام المتلهف عند مواجهة مشكلات رقمية أو متطلبات برمجية.

4. الحساسية الاقتصادية

في تحليل الحساسية الاقتصادية (تغيير تكلفة إنشاء الأدوات)، أصبحت السياسة المجردة (R0) أكثر انتقائية مع زيادة التكال، متتبعةً الحد الأقصى النظري. في المقابل، ظلت السياسة المطلوبة للكود (R2) غير مرنة، حيث استمرت في بناء الأدوات بمعدلات تقترب من 100% حتى عندما كانت التكلفة عالية جدًا لدرجة أن الاستراتيجية المثلى هي عدم بناء أي شيء تقريبًا.

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

تثبت الورقة أن التخصيص عبر الإنترنت للأدوات يمثل حدودًا هامة للقدرة في النماذج الرائدة الحديثة.

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

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