وكلاء الذكاء الاصطناعي
وكلاء الذكاء الاصطناعي لا يستطيعون إكمال ترحيل Java دون أن يمنعهم خادم البناء
تقدم IBM Research معيار ScarfBench المفتوح لتقييم وكلاء الذكاء الاصطناعي في ترحيل إطار عمل Java للمؤسسات. تكشف الاختبارات المبكرة أن الوكلاء المتقدمين مفرطون بشكل منهجي في الثقة بنتائجهم الخاصة، وأن طبقات التكوين تهيمن على الجهد، وأن المشكلات البيئية مثل ذاكرة التخزين المؤقت لـ Docker تعرقل عمليات الترحيل بانتظام حتى عندما تنجح تحويلات التعليمات البرمجية.

ترحيل إطار العمل هو نوع المهام التي تبدو مثالية لوكيل برمجة ذكي: ميكانيكية، متكررة، محكومة بقواعد موثقة جيدًا. استبدال تعليق توضيحي من Spring بآخر مكافئ من Jakarta، تعديل واصف استمرارية، تحديث تبعية Maven. يجب أن يتمكن نموذج لغة كبير من التعامل مع هذا دون عناء.
لكن اتضح أنه لا يستطيع ذلك، على الأقل ليس بشكل موثوق، وبالتأكيد ليس دون إشراف بشري كبير.
أصدرت IBM Research اليوم ScarfBench (معيار إعادة هيكلة التطبيقات ذاتية الاحتواء)، وهو معيار مفتوح مصمم لقياس ما إذا كان وكلاء الذكاء الاصطناعي قادرين بالفعل على ترحيل تطبيقات Java للمؤسسات الحقيقية بين أطر العمل مثل Spring وJakarta EE وQuarkus. النتيجة الرئيسية: يقوم الوكلاء المتقدمون بتجميع التعليمات البرمجية بنسبة 70 بالمائة تقريبًا من الوقت، ولكن حوالي 50 بالمائة فقط من التطبيقات المهاجرة يتم نشرها فعليًا وتجتاز التحقق من السلوك. الوكلاء أنفسهم يبالغون باستمرار في تقدير نجاحهم. cuga-ibms-open-source-agent-harness-lets-you-build-apps-with-just-a-prompt-and-tool-list
ما يجعل ترحيل إطار العمل مختلفًا جوهريًا
تم بناء ScarfBench لأن معايير هندسة البرمجيات الحالية، التي تختبر إصلاح الأخطاء أو توليد التعليمات البرمجية المعزولة، لا تلتقط التعقيد الهيكلي لترحيل عبر أطر العمل. يتضمن تحديث Java على مستوى المحفظة تغيير حقن التبعية، وتكوين الاستمرارية، وبناء جملة الاستعلام، ووصافات البناء، وتعبئة وقت التشغيل. خطأ في أي طبقة واحدة يمكن أن يمنع النشر، وتترتب الإخفاقات. ifbench-the-new-benchmark-testing-ai-instruction-following
يتضمن المعيار كلاً من مهام الترحيل المركزة (ترجمات مكون واحد) وترحيلات التطبيقات بأكملها المستمدة من تصنيف Java للمؤسسات القائم على JSR. يتم تقييم كل تطبيق بناءً على ثلاثة معايير: هل يبني، هل ينشر، وهل يحافظ على السلوك؟ هذا المعيار الثالث هو الذي تتجاهله معظم المعايير الحالية.
الوكلاء مفرطون في الثقة، وهذا خطر حقيقي
ربما يكون الاكتشاف الأكثر إثارة للقلق في الورقة هو الفجوة بين النجاح الذي أبلغ عنه الوكيل والنجاح الذي تم التحقق منه بشكل مستقل. أبلغ Claude Code عن عمليات بناء ناجحة لـ 29 من أصل 30 عملية ترحيل تطبيق كامل. فقط 22 من تلك التطبيقات تم بناؤها بالفعل. تطبيق واحد صنفه الوكيل كفشل تبين أنه يبني بشكل صحيح.
يكتب المؤلفون: "لا ينبغي التعامل مع التقييم الذاتي للوكيل كإشارة موثوقة لاكتمال الترحيل". في بيئة مؤسسية حقيقية، قد تؤدي الثقة الزائفة إلى قيام الفرق بشحن تطبيقات معطلة، أو الأسوأ من ذلك، تخطي التحقق الآلي بالكامل على افتراض أن الوكيل قد تحقق بالفعل من عمله. يقدم ScarfBench حجة بأن التحقق المستقل من البناء والاختبار ليس اختياريًا، بل هو الإشارة الوحيدة التي تهم. why-your-ai-agent-might-ace-the-task-but-flunk-the-process-enter-skillcoach
التكوين هو المكان الذي تموت فيه عمليات الترحيل
عندما تتبع الباحثون طبقات التطبيق التي عاد إليها الوكلاء بشكل متكرر أثناء الترحيل، كان النمط واضحًا. ملفات التكوين، application.properties، pom.xml، beans.xml، هيمنت على سجل التكرار. كان الانتقال الأكثر شيوعًا في كل ترحيل بين التكوين وطبقة الويب، يليه الانتقالات من الخدمة إلى قاعدة البيانات.
هذه ليست عملية خطية. لا يقوم الوكلاء بترجمة ملفات المصدر أولاً ثم إصلاح التكوين. يتنقلون بين طبقات التكوين والويب وقاعدة البيانات والخدمة، ويعدلون التبعيات بشكل متكرر مع ظهور عدم توافق أطر العمل. الترحيل هو تمرين حل تبعية تكراري، وليس تحويلاً من مصدر إلى مصدر.
ذاكرة التخزين المؤقت لـ Docker وتصادمات المنافذ وأغلفة Maven
ليست كل الإخفاقات تتعلق بالتعليمات البرمجية. قام فريق التقييم بفهرسة مجموعة من المشكلات البيئية التي عرقلت عمليات التحقق: عدم تناسق ذاكرة التخزين المؤقت لـ Docker، ومشكلات اتصال المنافذ، وعدم تطابق إصدار غلاف Maven، وغرائب أدوات البناء. غالبًا ما تؤخر هذه الإخفاقات التشغيلية الاختبار لفترة طويلة بعد أن ينهي الوكيل ما يعتقد أنه ترحيل التعليمات البرمجية. gui-agents-beat-cli-in-desktop-tasks-but-skill-coverage-holds-the-key
في بيئة إنتاج، سيكتشف المشغل البشري تصادم المنفذ في ثوانٍ. الوكيل، ما لم يتم توجيهه صراحةً للتحقق من البنية التحتية، يبلغ ببساطة عن فشل وقد لا يعزل السبب الجذري أبدًا.
إطار العمل المستهدف مهم
تتفاوت صعوبة الترحيل بشكل كبير اعتمادًا على إطار العمل الهدف. أثبت Jakarta EE أنه الهدف الأصعب، وهي نتيجة يعزوها الباحثون إلى اعتماده الأكبر على وصفات XML ونموذج النشر الأكثر تعقيدًا مقارنة بـ Spring Boot أو Quarkus. وقعت ترحيلات Quarkus في مكان ما بينهما، حيث كانت معدلات نجاح البناء أعلى بشكل ملحوظ من معدلات نجاح السلوك، مما يشير إلى أن Quarkus يجمع بسهولة ولكن دلالات وقت التشغيل التفاعلية تربك الوكلاء أثناء النشر. tcs-and-anthropic-partner-to-bring-claude-to-regulated-industries
صُمم المعيار ليكون قابلاً للتوسع، ويدعو الفريق إلى المساهمات بسيناريوهات ترحيل جديدة. مجموعة البيانات والبنية التحتية للتقييم ولوحة المتصدرين كلها مفتوحة المصدر.
لن يكون ScarfBench الكلمة الأخيرة في الترحيل بمساعدة الذكاء الاصطناعي، لكنه يوفر أول عصا قياس موثوقة. الفجوة بين نجاح التجميع ونجاح السلوك هي الفجوة بين وكيل يبدو منتجًا وآخر منتج بالفعل.