BC-Bench: Evaluating Agentic Engineering in a Domain-Specific Language for ERP
تقدم هذه الورقة BC-Bench، وهو معيار مرجعي جديد يضم 101 مهمة من واقع الحياة بلغة AL الخاصة بنطاق Microsoft Dynamics 365 Business Central، لتوضيح أن أداء الهندسة الوكيلية (agentic engineering) في المعايير العامة لا يترجم بشكل موثوق إلى سياقات تخطيط موارد المؤسسات (ERP)، وللتأكيد على الحاجة الماسة للتقييم المتخصص في هذا المجال.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
في عالم البرمجيات الحديثة، ظهر نوع جديد من العمال: ذكاء اصطناعي يمكنه كتابة الأكواد، وإصلاح الأخطاء، وبناء البرامج بمفرده. هذه الأنظمة، التي تُسمى غالباً "وكلاء البرمجة" (coding agents)، تم تدريبها على مكتبات هائلة من التعليمات البشرية المكتوبة، وأظهرت مهارة ملحوقة في لغات البرمجة عامة الأغراض مثل لغة بايثون (Python). يمكن لهذه الأنظمة حل الألغاز التي كانت تستغرق من المهندسين البشريين ساعات لحلها. ومع ذلك، فإن عالم برمجيات الأعمال الحقيقي نادراً ما يكون بهذه البساطة؛ إذ تعتمد معظم البنية التحتية الحيوية التي تدير التجارة العالمية على لغات متخصصة مصممة لصناعات محددة، حيث تختلف القواعد، وتنفرد الأدوات، وتكون المخاطر عالية. أحد هذه البيئات هو عالم تخطيط موارد المؤسسات (ERP)، حيث تدير الشركات كل شيء من المخزون إلى كشوف المرتبات. هنا، تتحدث البرمجيات لغة تُسمى "AL"، وهي لهجة متخصصة تُستخدم لتشغيل نظام "بزنس سنترال" (Business Central) من مايكروسوفت. ولسنوات، لم يكن من الواضح ما إذا كانت وكلاء الذكاء الاصطناعي القوية هذه قادرة على التنقل في هذا المشهد المعقد والمملوك لجهات محددة، أم أن نجاحها في البرمجة العامة كان ظاهرة تتلاشى عند مواجهة قيود الأعمال الحقيقية.
وللإجابة على هذا السؤال، أنشأ باحثون في مايكروسوفت ساحة اختبار جديدة تسمى "BC-Bench". لم يخترعوا لغزاً نظرياً؛ بل بحثوا في الكود الفعلي والحي لمستودعين ضخمين من البرمجيات التي تشغل شركات حقيقية. ومن هذه الأرشيفات الرقمية، اختاروا بعناقة 101 مهمة محددة حلها المهندسون في الماضي. لم تكن هذه أمثلة مختلقة، بل مشكلات حقيقية: خطأ برمجي تسبب في فشل سجل عميل، أو ميزة مفقودة في تقرير مبيعات، أو اختبار يحتاج إلى كتابته لرصد خطأ ما. ثم طلب الباحثون من العديد من أكثر وكلاء الذكاء الاصطناعي تقدماً في العالم محاولة أداء هذه المهام نفسها. زُوّد الوكلاء بوصف المشكلة الأصلي، والذي تضمن أحياناً لقطات شاشة للخطأ، ولقطة للكود كما كان موجوداً قبل الإصلاح. كان هدفهم هو كتابة تغييرات الكود الدقيقة اللازمة لحل المشكلة، تماماً كما يفعل المهندس البشري. ثم قام النظام بتشغيل البرنامج في بيئة محاكية لمعرفة ما إذا كان الكود الجديد قد أصلح المشكلة بالفعل دون كسر أي شيء آخر.
كشفت النتالئج عن مشهد كان فيه هوية نموذج الذكاء الاصطناعي أهم بكثير من الأداة المحددة التي يستخدمها للقيام بالعمل. فعندما قارن الباحثون بين إصدارات مختلفة من الوكلاء، وجدوا أن اختيار "الدماغ" الأساسي — وهو النموذج اللغوي الكبير — كان له تأثير أكبر بكثير على النجاح من اختيار "الغلاف" البرمجي (harness) الذي يوجهه. على سبيل المثال، حل أحد أحدث النماذج، وهو "Claude Opus 4.6"، ما يقرب من 69 بالمائة من مهام إصلاح الأخطاء عند اقترانه بأداة قياسية، بينما حل إصدار أقدم من النموذج نفسه حوالي 58 بالمائة فقط. وفي المقابل، أدى استبدال الأداة نفسها مع إبقاء النموذج كما هو إلى فروق ضئيلة وغير ذات دلالة إحصائية. يشير هذا إلى أنه بالنسبة لمهام الأعمال المعقدة هذه، فإن ذكاء النموذج هو المحرك الأساسي للنجاح، وليس الواجهة المحددة التي يستخدمها للوصول إلى الكود.
ولعل الاكتشاف الأكثر إثارة للدهشة هو أن التحسينات المشهودة في اختبارات البرمجة العامة لا تُترجم تلقائياً إلى هذا العالم المتخصص. ففي عالم هندسة البرمجيات الأوسع، تُظهر النماذج الأحدث غالباً مكاسب مستقرة ومتوقعة مقارنة بأسلافها. ومع ذلك، في هذه البيئة التجارية المحددة، فشل نموذج تفوق مؤخراً على سلفه في الاختبارات العامة في إظهار نفس الميزة هنا. فقد فشل نموذج حقق تحسناً كبيراً في المهام العامة في التفوق على أخيه الأقدم عند مواجهة ألغاز منطق الأعمال هذه. يشير هذا إلى أن المهارات المطلوبة لإصلاح نص برمجي بسيط بلغة بايثون ليست هي نفسها المطلات المطلوبة لتصحيح عملية حسابية مالية في نظام أعمال متخصص. إن الطبيعة المتخصصة للغة، مع قواعدها الصارمة حول كيفية تدفق البيانات وكيفية التحقق من منطق الأعمال، تخلق حاجزاً لا يمكن للتدريب العام تجاوزه بسهلاً.
كما نظر الباحثون بدقة في أسباب فشل الوكلاء عندما فشلوا. وجدوا أن الآلات نادراً ما فشلت لأنها لم تستطع بناء البرمجيات أو لأن الكود لم يتمكن من العمل (compile)؛ إذ كانت تلك العقبات التقنية سهلة التجاوز. بدلاً من ذلك، كانت الإخفاقات دائماً تتعلق بفهم المشكلة. ففي ما يقرب من نصف المحاولات الفاشلة، نظر الوكيل إلى الجزء الخطأ من الكود تماماً، وقام بتعديل ملفات لا علاقة لها بالخطأ. وفي مجموعة كبيرة أخرى من حالات الفشل، وجد الوكيل الملف الصحيح والقسم الصحيح من الكود، لكنه طبق المنطق الخاطئ، حيث نفذ حلاً يبدو صحيحاً ولكنه لم يحل قاعدة العمل فعلياً. على سبيل المثال، قد يحدد الوكيل بشكل صحيح أن رقم طلب العميل مفقود، ولكنه يكتب كوداً يعين نوعاً خاطئاً من الأرقام، مما يترك النظام معطلاً. تشير هذه الأخطاء إلى أن الوكلاء يعانون في التنقل عبر الشبكة العميقة والمترابطة من قواعد الأعمال التي تحدد كيفية عمل الشركة، وغالباً ما يفتقدون السياق الدقيق الذي يدركه المهندس البشري على الفور.
كما لعب تعقيد المهمة دوراً حاسماً. فعندما كان الإصلاح يتطلب تغيير ملف واحد فقط أو عدد قليل من الأسطر، كان الوكلاء ناجحين تماماً. ومع ذلك، بمجرد أن يتطلب الحل تعديل ملفات متعددة أو كتابة أكثر من بضع عشرات من أسطر الكود، انخفض معدل النجاح بشكل حاد. كان هذا الانخفاض دراماتيكياً، حيث تراجعت الدقة بأكثر من عشرين نقطة مئوية عندما تتضمن المهمة أكثر من ملف واحد. يبدو أنه بينما يمكن لهذه الوكلاء التعامل مع الإصلاحات الصغيرة والمعزولة، إلا أنهم لا يزالون يجدون صعوبة في تنسيق التغييرات عبر نظام كبير ومترابط. علاوة على ذلك، كان نوع مجال الأعمال مهماً؛ حيث كان الوكلاء أكثر نجاحاً في إصلاح المشكلات في إدارة المخزون منها في لوجستيات المستودعات، مما يشير إلى أن بيانات تدريبهم قد تكون أغنى في بعض مجالات الأعمال دون غيرها.
تخلص الدراسة إلى أنه بينما حقق الذكاء الاصطناعي خطوات مذهلة في البرمجة العامة، فإن الطريق نحو الهندسة المستقلة تماماً في بيئات الأعمال المتخصصة ليس واضحاً بعد. الأدوات موجودة، والنماذج قوية، لكن الفجوة بين القدرة العامة والإتقان الخاص بالمجال لا تزال واسعة. ويؤكد الباحثون أنه للمضي قدماً، يحتاج القطاع إلى التركيز على هذه الاختبارات المعيارية المتخصصة بدلاً من الاعتماد على الاختبارات العامة. كما يشيرون إلى أن القيود الحالية لا تتعلق فقط بالذكاء الخام، بل بالقدرة على فهم السياق، والتنقل في قواعد الكود المعقدة، وتطبيق منطق الأعمال الصحيح. ومع تطور هذه الأنظمة، يبقى الأمل في أنها ستتعلم في النهاية التنقل عبر القواعد المعقدة لبرمجيات الأعمال بنفس السهولة التي تظهرها الآن في البرمجة العامة، ولكن في الوقت الحالي، يظل المهندس البشري ضرورياً لإرشادهم عبر تعقيدات العالم الحقيقي.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.