Execution Grounded Multiagent Systems for Reliable Backend Code Generation with Large Language Models'
تقدم هذه الورقة إطار عمل "ExecuGraph" القابل للضبط، والذي يثبت أن التغذية الراجعة من التنفيذ هي المحرك الأساسي لتحسين دقة توليد الكود في النماذج اللغوية الكبيرة، بينما يوضح أن إضافة تفكيك الأدوار متعدد الوكلاء لا يوفر أي فائدة ملموسة مقارنة بحلقات إعادة المحاولة أحادية الوكيل رغم التكاليف الحسابية الأعلى بكثير.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
تخيل أنك تحاول تعليم روبوت موهوب للغاية، ولكنه حالم بعض الشيء، كيفية كتابة كود برمجي. هذا الروبوت هو "نموذج لغوي كبير" (LLM)، وهو يشبه طالباً فائق الذكاء قرأ كل كتاب وكل قطعة كود في المكتبة تقريباً. يمكنه كتابة كود يبدو مثالياً على الورق، ولكنه أحياناً يرتكب أخطاءً دقيقة لا تظهر إلا عندما تحاول تشغيل البرنامج فعلياً. وفي عالم البرمجيات، يعد هذا أمراً بالغ الأهمية لأن خطأً ضئيلاً يمكن أن يؤدي إلى تعطل موقع إلكتروني كامل أو فقدان بيانات.
لفترة من الوقت، اعتقد الناس أن أفضل طريقة لإصلاح ذلك هي توظيف فريق كامل من المتخصصين الروبوتيين — "نظام متعدد الوكلاء" (Multi-Agent System). تخيل مديراً للمشروع، ومحرراً صارماً، وفاحصاً للمنطق، وكاتب كود يعملون معاً. الفكرة هي أنه إذا قمت بتفكيك العمل وجعلت الروبوتات المختلفة تراجع عمل بعضها البعض، فسيكون الكود النهائي خالياً من العيوب. ولكن ظل هناك سؤال ملح: هل التحسن ناتج عن امتلاك "فريق"، أم لمجرد أن الروبوتات سُمح لها بـ "المحاولة مرة أخرى" بعد رؤية أخطائها؟ إنه يشبه التساؤل عما إذا كان الطالب يحصل على درجات أفضل بسبب وجود مجموعة دراسة، أو ببساسة لأنه سُمح له بإعادة الاختبار بعد رؤية اختباره الأول. تسعى هذه الورقة البحثية لحل هذا الغموض من خلال بناء آلة اختبار خاصة يمكنها عزل هذين العاملين.
بنى الباحثون إطار عمل ذكياً يسمى ExecuGraph، والذي يعمل كسكين سويسري لاختبار روبوتات كتابة الكود. لقد صمموه بحيث يمكنهم التبديل فوراً بين ثلاثة أوضاع: روبوت "الذئب المنفرد" الذي يكتب الكود مرة واحدة ويتوقف؛ وروببوت "الذئب المنفرد" الذي يُسمح له بالمحاولة مرة أخرى إذا فشل؛ و"فريق الأحلام" الكامل المكون من خمسة وكلاء روبوتيين مختلفين يعملون معاً. ومن خلال تشغيل نفس الـ 164 لغزاً برمجياً صعباً عبر هذه الأوضاع المختلفة، اكتشفوا شيئاً مفاجئاً.
النتيجة الرئيسية هي أن السماح للروبوت بالمحاولة مرة أخرى بعد رؤية أخطائه هو الخدعة السحرية الحقيقية، وليس امتلاك فريق من المتخصصين. فعندما منحوا روبوتاً واحداً الفرصة لرؤية أخطائه وإعادة المحاولة (وهي عملية تسمى "التغذية الراجعة من التنفيذ")، قفز معدل نجاحه بمقدار هائل قدره 25.6 نقطة مئوية. لقد انتقل من حل حوالي 56% من المشكلات بشكل صحيح إلى حل أكثر من 81% منها. هذا فوز ساحق!
ومع ذلك، عندما أضافوا الفريق الكامل المكون من خمسة وكلاء إضافيين (مخطط، ومراجع، ومحسن، إلخ) فوق نظام إعادة المحاولة هذا، لم تتحسن النتائج. في الواقع، كانت نسخة "الفريق" غير متمايزة إحصائياً عن الروبوت المنفرد الذي حصل فقط على فرصة إعادة المحاولة. كما أن نسخة "الفريق" كلفت حوالي 3.6 ضعف قدر من الطاقة الحاسوبية والوقت دون أن تقدم إجابة واحدة إضافية صحيحة. كما فند الباحثون فكرة أن الفريق كان يفوز لمجرد أنه حظي بفرصة "رمي النرد" مرات أكثر؛ حيث أثبتوا أن مجرد توليد خمس تخمينات عشوائية بدون أي تغذية راجعة لم يساعد كثيراً.
لكن ظهرت في القصة التفاتة غير متوقعة. فقد وجد الباحثون خطأً (bug) في آلة الاختبار الخاصة بهم (بيئة تجريبية أو "sandbox" لتشغيل الكود) كان يرفض الكود الصحيح عن طريق الخطأ. وبمجرد إصلاح هذا الخطأ، تغيرت الأرقام، لكن الاستنتاج الرئيسي ظل كما هو: حلقة إعادة المحاولة هي البطل، والوكلاء الإضافيون هم مجرد زينة مكلفة.
نظرت الورقة أيضاً في كيفية عمل هذا مع أنواع مختلفة من الروبوتات. في نوع معين من الروبوتات (نموذج بـ 16 مليار معلمة)، ساعد نهج الفريق في حل نوع محدد من الألغاز وهي "مشكلات الرسم البياني" (graph problems)، حيث رفع نسبة النجاح من 70% إلى 90%. ولكن في أنواع أخرى من الألغاز، كان الفريق في الواقع أسوأ، وظل الدرجة الإجمالية كما هي. وهذا يشير إلى أن إضافة المزيد من الوكلاء لا يجعل الروبوت أذكى تلقائياً؛ بل يغير فقط نوع المشكلات التي يمكنه حلها.
في النهاية، تقترح الورقة أنه إذا كنت تريد روبوتاً لكتابة الكود بشكل موثوق، فأنت لست بحاجة لبناء منظمة معقدة من خمسة وكلاء مختلفين. أنت فقط بحاجة لمنح الروبوت حلقة ذكية واحدة: اكتب الكود، قم بتشغيله، انظر ما الذي تعطل، ثم حاول إصلاحه. إنها طريقة أرخص، وأسرع، وفعالة تماماً مثل توظيف لجنة كاملة. قد يظل نهج "الفريق" مفيداً لتوليد تقارير أو تفسيرات إضافية، ولكن بالنسبة للمهمة الفعلية المتمثلة في كتابة كود صحيح، فإن استراتيجية "حاول، افشل، ثم أعد المحاولة" البسيطة هي الفائز الواضح.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.