طريقة أفضل لتنفيذ الإجراءات

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

الشكل 1: مقارنة الدقة بين ثلاثة أساليب: CodeAgent المهيكلة (الأزرق)، وCodeAgent (البرتقالي)، وToolCallingAgent (الرمادي) على SmolBench (GAIA، MATH، SimpleQA، والإطارات). تمثل أشرطة الخطأ فواصل ثقة بنسبة 95%.

🤔 تطور تصرفات الوكيل

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

وكيل JSON التقليدي: يقوم الوكلاء بإنشاء JSON منظم لاستدعاء الأدوات.

{"tool": "get_weather", "arguments": {"city": "Paris"}}

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

إنها موثوقة، ولكنها محدودة بما يلي:

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

وكلاء الكود: يستفيد الوكلاء من قدرتهم الفطرية على الترميز ويكتبون تعليمات برمجية Python القابلة للتنفيذ مباشرة.

temperature_sum = 0
for city in ["Paris", "Tokyo", "New York"]:
    temp = get_weather(city)
    temperature_sum += temp
    
print(f"Average temperature: {temperature_sum / 3:.1f}°C")

هذا التحول، الذي تم تقديمه لأول مرة باسم CodeAct في الورقة البحثية “إجراءات التعليمات البرمجية القابلة للتنفيذ تثير وكلاء LLM أفضل”، أعطى عملاء الذكاء الاصطناعي المرونة لكتابة كود Python التعسفي القابل للتنفيذ بالإضافة إلى استدعاء الأدوات.

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

إيجابيات استخدام CodeAgent:

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

ومع ذلك، قد يكون تحليل التعليمات البرمجية من تخفيض السعر عرضة للخطأ مما يقودنا إلى اقتراح: لماذا لا نستخدم التوليد المنظم لإنشاء إجراءات التعليمات البرمجية؟

➡️ إضافة مخرجات منظمة إلى Code Agent

باستخدام المخرجات المنظمة، يمكنك إجبار LLM على إنشاء أفكار ورموز واضحة على هيئة JSON blob:

{
  "thoughts": "I want to find the average temperature across 3 cities.",
  "code": "temperature_sum = 0\nfor city in [\"Paris\", \"Tokyo\", \"New York\"]:\n    temp = get_weather(city)\n    temperature_sum += temp\n\nprint(f\"Average temperature: {temperature_sum / 3:.1f}°C\")"
}

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

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

• المنطق الصريح: ال thoughts المجال يجبر الوكيل على التفكير بشكل صحيح قبل أن يتخذ أي إجراء.
• تحليل موثوق: هيكل JSON يزيل أخطاء تحليل تخفيض السعر
• التعبير الكامل للكود: ال code يحافظ الحقل على كل مرونة وكلاء التعليمات البرمجية
• الانفصال أفضل: الفصل الواضح بين التخطيط والتنفيذ

🧪 النتائج المعيارية

قمنا بمقارنة هذه النماذج الثلاثة عبر معايير متعددة بما في ذلك GAIA، وMATH، وSimpleQA، وFrames. وتظهر النتائج نمطا واضحا: تعمل إجراءات التعليمات البرمجية + التوليد المنظم على تحسين أداء النماذج القادرة باستمرار.

عبر النماذج الأكثر قدرة، تفوق النهج المنظم باستمرار على نهج CodeAgent العادي بنسبة 2-7 نقاط مئوية في المتوسط.

• نماذج OpenAI: إظهار أكبر التحسينات في البنية، خاصة في المهام التي تتطلب تفكيرًا كثيفًا
• نماذج كلود: استفد من البنية، حيث يُظهر Claude 3.7 Sonnet نتائج قوية بشكل خاص
• نماذج كوين: التحسين بشكل عام من خلال الهيكل، على الرغم من أن “ضريبة الهيكل” (انظر القسم التالي) تزحف إلى النماذج الأصغر.

💡 لماذا يساعد الهيكل (بشكل عام).

مشكلة التحليل حقيقية

يؤدي تطبيقنا لـ CodeAgent في smolagents إلى استخراج كود Python من مخرجات LLM، والذي يمكن أن يفشل عندما:

• صياغة كتلة التعليمات البرمجية في تخفيض السعر غير مكتملة أو منسقة بشكل غير صحيح
• تظهر كتل التعليمات البرمجية المتعددة في استجابة واحدة

يعمل الجيل المنظم على التخلص من هذه المشكلات من خلال تحليل JSON الموثوق به.

لفهم أهمية التوليد المنظم، قمنا بتحليل 15,724 تتبعًا للوكلاء عبر معاييرنا. النتائج مذهلة:

• 2.4% من الآثار بها أخطاء تحليلية في مكالمتها الأولى
• آثار مع أخطاء تحليل المكالمة الأولى: 42.3% معدل النجاح
• آثار بدون أخطاء تحليل المكالمة الأولى: 51.3% معدل النجاح

تنجح عمليات تتبع الوكيل بدون أخطاء التحليل بنسبة 21.3% أكثر من تلك التي تحتوي على أخطاء تحليل.

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

الشكل 2: يؤدي تحليل الأخطاء في الخطوة الأولى إلى تقليل معدلات نجاح العامل بنسبة 21.3% وزيادة متوسط ​​الخطوات المتخذة من 3.18 إلى 4.63.

بالإضافة إلى ذلك: عملية الاستدلال القسري

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

• تخطيط أفضل: يفكر الوكلاء في المشكلات بشكل أكثر منهجية
• تعزيز الموثوقية: الاستدلال الصريح يكتشف الأخطاء المنطقية مبكرًا

ضريبة الهيكلة

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

• نماذج كبيرة ومدربة تدريبا جيدا
• نماذج ذات قدرات قوية في متابعة التعليمات
• نماذج تم ضبطها بدقة على التوليد المنظم.

عندما ينكسر الهيكل: مثال حقيقي

إليك ما يحدث عندما يكون النموذج الأصغر (على سبيل المثال mistralai/Mistral-7B-Instruct-v0.3) يحاول إنشاء تعليمات برمجية منظمة – يصبح الحمل المعرفي أكثر من اللازم:

{
  "thought": "I need to find the height...",
  "code": "web_search(query=\"Eiffel Tower height\")\", "
}

ينشئ النموذج كود بايثون المكسور من الناحية النحوية: web_search(query="Eiffel Tower height")", – لاحظ السلسلة المشوهة مع علامة اقتباس وفاصلة إضافية. يؤدي هذا إلى حدوث خطأ فوري في SyntaxError وفشل التنفيذ.

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

🚀 متى يجب استخدام وكلاء CodeAgents المنظمين

✅ استخدم CodeAgents المهيكلة عندما:

• العمل مع النماذج القادرة (32B+ المعلمات أو النماذج الحدودية)
• تتطلب المهام تفكيرًا معقدًا وتنفيذ التعليمات البرمجية
• أنت بحاجة إلى تحليل موثوق لمخرجات الوكيل

⚠️ فكر في البدائل عندما:

• العمل مع نماذج أصغر تعاني من التوليد المنظم
• تعتبر مسارات العمل البسيطة والمحددة مسبقًا كافية

كيفية الاستخدام مع سمولاجينتس:

انها بسيطة للغاية! فقط قم بتمكينه باستخدام use_structured_outputs_internally:

from smolagents import CodeAgent, InferenceClientModel, GoogleSearchTool


agent = CodeAgent(
    tools=[GoogleSearchTool(provider="serper")],
    model=InferenceClientModel("Qwen/Qwen3-235B-A22B", provider='nebius'),
    use_structured_outputs_internally=True 
)

result = agent.run("Calculate the time for a cheetah to run across the Golden Gate Bridge")

سوف يقوم LLM بإنشاء شيء مثل هذا:

{
  "thoughts": "I need to find the length of the Golden Gate Bridge and the top speed of a cheetah, then calculate the time.",
  "code": "bridge_info = web_search('Golden Gate Bridge length meters')\ncheetah_speed = web_search('Cheetah top speed') ..."
}

بعد ذلك، يتم تنفيذ الجزء “الكود” بواسطة الوكيل كالمعتاد: هذا هو CodeAgent القياسي، ولكنه الآن يتمتع بموثوقية التحليل بنسبة 100%!

نصائح التنفيذ

1. مطالبة واضحة: تأكد من أن مطالباتك تحدد بوضوح بنية JSON المتوقعة
2. اختيار النموذج: اختر نماذج تتمتع بقدرات توليد منظمة قوية
3. اختر المزود المناسب: يدعم بعض موفري واجهة برمجة التطبيقات (API)، مثل OpenAI أو Anthropic، الإنشاء المنظم خارج الصندوق. إذا كنت تستخدم موفري الاستدلال من خلال Hugging Face، فإن دعم الإنشاء المنظم يختلف عبر الموفرين. فيما يلي قائمة بالموفرين الذين يدعمون التوليد المنظم: دعم التوليد المنظم للنماذج الموجودة في سمولاجينتس‣

الصورة الأكبر – ما هي الخطوة التالية؟

يشير هذا البحث إلى أننا نتجه نحو فهم أكثر دقة لبنيات الوكيل. لا يتعلق الأمر فقط بـ “ما الذي يمكن للوكيل فعله؟” ولكن “كيف ينبغي للوكيل أن يفكر فيما يفعله؟”

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

ولكن هذه مجرد البداية. هناك الكثير من الأسئلة المتبقية لاستكشاف:

• ما هي التحسينات الهيكلية الأخرى التي يمكن أن تساعد؟
• كيف يمكننا أن نجعل هذا العمل أفضل عبر بنيات النماذج المختلفة، وخاصة نماذج smol؟
• ماذا يخبرنا هذا عن طبيعة تفكير الذكاء الاصطناعي؟

في الوقت الحالي، إذا كنت تستخدم سمولاجينت (أو تقوم بإنشاء نظام CodeAgent الخاص بك)، ففكر في تجربة الإخراج المنظم. ستشكرك أخطاء التحليل، وقد ترى زيادة جيدة في الأداء!