Deterministic vs. LLM-Controlled Orchestration for COBOL-to-Python Modernization
تقدم هذه الورقة دراسة تجريبية منضبطة تثبت أن التنسيق الحتمي يتفوق على سير العمل الوكيل المعتمد على النماذج اللغوية الكبيرة في تحديث لغة COBOL إلى Python، وذلك من خلال تحقيق دقة ترجمة مماثلة مع تحسين المتانة بشكل كبير، وتقليل تباين الأداء، وخفض التكاليف التشغيلية بنسبة تصل إلى 3.5 ضعفاً.
على مدى عقود، اعتمد القطاعان المالي والحكومي على برامج حاسوبية ضخمة ومعقدة مكتوبة بلغة تُسمى "كوبول" (COBOL). تدير هذه الأنظمة المعاملات المصرفية العالمية ومدفوعات الضمان الاجتماعي، ومع ذلك، فإن الخبراء الذين بنوها يتقاعدون، والشيفرة البرمجية نفسها غالباً ما تكون قديمة، وتفتقر للتوثيق الجيد، ويصعب تغييرها. وللحفاظ على استمرارية هذه الخدمات الحيوية، يجب على المؤسسات ترجمة هذه الشيفرة القديمة إلى لغات حديثة مثل "بايثون" (Python)، وهي عملية تتطلب دقة متناهية لأن أي خطأ ضئيل يمكن أن يتسبب في تعطل النظام. ومؤخراً، ظهر نوع جديد من الذكاء الاصطناዊ المعروف باسم "النماذج اللغوية الكبيرة" كأداة محتملة لهذه المهمة. يمكن لهذه النماذج قراءة الشيفرة وكتابة شيفرة جديدة، لكنها غالباً ما تعمل من خلال التصرف كوكلاء مستقلين: فهي تقرر بنفسها الخطوات التي ستتخذها، ومتى تعيد المحاولة، وكيفية إصلاح الأخطاء أثناء العمل. وهذا يثير سؤالاً جوهرياً للمهندسين: هل من الأفضل ترك الذكاء الاصطناዊ يقود العملية بأكملية، ويقرر كل حركة في الوقت الفعلي، أم أن من الأكثر فعالية إبقاء العملية على مسار صارم ومحدد مسبقاً حيث يتبع الحاسوب مجموعة ثابتة من القواعد؟
وضع فريق من الباحثين في جامعة "باكنيل" وشركة "أستريو" (Astrio) نصب أعينهم الإجابة على هذا السؤال من خلال إجراء تجربة منضبطة لمعرفة كيف يتعامل هذان النهجان المختلفان مع المهمة الصعبة المتمثلة في تحويل شيفرة "كوبول" إلى "بايثون". لقد بنوا نظاماً يُدعى "أطلس" (ATLAS) ليعمل كمترجم، لكنهم صمموا التجربة بحيث يكون الشيء الوحيد الذي يتغير بين الاختبارات هو من يجلس في مقعد القيادة. في نسخة واحدة، مُنح الذكاء الاصطناዊ السيطرة الكاملة، حيث سُمح له باختيار مساره الخاص، واختيار أدواته، وتقرير متى يتوقف أو يبدأ من جديد. وفي النسخة الأخرى، استُخدم نفس الذكاء الاصطناዊ لكتابة الشيفرة، لكن مجموعة من القواعد الجامدة وغير المتغيرة هي التي أملت بدقة الخطوات التي يجب اتخاذها، وبالترتيب نفسه، وعدد المرات التي يجب فيها المحاولة إذا حدث خطأ ما. ومن خلال إبقاء "عقل" النظام — وهو النموذج اللغوي — هو نفسه تماماً في كلا السيناريوهين، استطاع الباحثون عزل تأثير طريقة التحكم نفسها، وتجريد التجربة من جميع المتغيرات الأخرى لمعرفة أي استراتيجية كانت تعمل بشكل أفضل حقاً.
كشفت نتائج هذه الدراسة عن مقايضة واضحة بين المرونة والموثوقية. فعندما سُمح للذكاء الاصطناዊ بالتحكم في العملية، نجح في كثير من الأحيان في إنتاج برنامج يعمل، وغالباً ما نجح في توليد نتيجة يمكن تشغيلها دون تعطل. ومع ذلك، جاء هذا النجاح بتكلفة خفية: كانت النتائج غير متسقة. ولأن النموذج كان يتخذ قراراته الخاصة حول كيفية المضي قدماً، فإن نفس الشيفرة الأصلية قد تؤدي إلى نتائج مختلفة تماماً في محاولات مختلفة، فتارة تنتج ترجمة مثالية وتارة أخرى تفشل بطرق غير متوقعة. علاوة على ذلك، كان هذا النهج "الوكيل" (agentic) مكلفاً للغاية؛ إذ كان النموذج غالباً ما يتوه في مسارات طويلة وملتوية من التفكير، ويسأل نفسه أسئلة ويجرب استراتيجيات متعددة لم تكن ضرورية، مما يستهلك كميات هائلة من الموارد الحسابية. وفي بعض الحالات، استخدم النهج المرن أكثر من ثلاثة أضعاف عدد "الرموز" (tokens) — وهي الوحدات الأساسية للمعلومات التي يعالجها النموذج — مقارنة بالنهج الثابت لتحقيق نتيجة مماثلة.
في المقابل، أنتج النظام الذي اتبع مساراً ثابتاً وحتمياً نتائج كانت أكثر استقراراً وقابلية للتنبؤ. وبينما كانت القدرة العامة على ترجمة الشيفرة جيدة بقدر نسخة النهج المرن، إلا أن النظام الجامد نادراً ما فشل في الحالات الأسوأ. فهو لم يضع في حلقات من التفكير غير الضروري، ولم يغير سلوكه من تشغيل إلى آخر. والأهم من ذلك، كان تشغيله أرخص بكثير؛ فمن خلال الالتزام بجدول زمني صارم من الخطوات واستخدام الذكاء الاصطناवी فقط لكتابة الشيفرة بدلاً من التخطيط للرحلة، قلل النظام تكلفة الترجمة بمقدار ثلاثة إلى ثلاثة ونصف ضعف. ووجد الباحثون أنه بالنسبة لمهام مثل تحديث البرمجيات القديمة، حيث تكون الخطوات محددة جيداً ويمكن التحقق من النتائج مقابل قواعد صارمة، فإن ترك الذكاء الاصطناዊ يقود السيارة لم يكن فقط أكثر تكلفة، بل كان أيضاً أقل موثوقية من وجود خريطة صممها البشر لتوجيه الطريق.
تشير هذه الدراسة إلى أن مستقبل استخدام الذكاء الاصطناዊ في المهام الهندسية المعقدة قد لا يكمن في منح الآلات حرية كاملة لتقرر كيفية العمل. بدلاً من ذلك، يبدو أن النهج الأكثر فعالية هو دمج هذه النماذج القوية ضمن إطار هيكلي حيث تكون قواعد الاشتباك ثابتة والمسار واضحاً. يظل الذكاء الاصطناዊ هو "الكاتب الخبير"، القادر على فهم التعليمات المعقدة وتوليد شيفرة جديدة، ولكن تنسيق العمل — أي التخطيط، والتوقيت، وضوابط السلامة — يظل تحت سيطرة حتمية صارمة. وهذا يضمن أن العملية ليست قادرة على إنتاج نتائج عالية الجودة فحسب، بل تظل أيضاً قوية، وقابلة للتنبؤ، ومجدية اقتصادياً للأنظمة الضخمة والحساسة التي تدير عالمنا الحديث.
ملخص تقني: التنسيق الحتمي مقابل التنسيق المتحكم به بواسطة النماذج اللغوية الكبيرة (LLM) لتحديث أنظمة COBOL إلى Python
بيان المشكلة
يعد تحديث أنظمة COBOL القديمة تحديًا حرجًا بسبب ندرة الخبرات، وضخامة قواعد الأكواد البرمجية، ومتطلبات الصحة الصارمة. وبينما أظهرت النماذج اللغوية الكبيرة (LLMs) قدرة واعدة في ترجمة الأكواد، تعتمد الأنظمة الحديثة بشكل متزايد على سير العمل الوكيل (agentic workflows) حيث يتحكم النموذج اللغوي الكبير ديناميكيًا في تنفيذ خطوات متعددة، بما في ذلك اختيار الأدوات، وترتيبها، ومنطق إعادة المحاولة. ومع ذلك، لا يزال من غير الواضح ما إذا كان تفويض التحكم في التنفيذ إلى النموذج اللغوي الكبير يحسن الصحة، أو المتانة، أو الكفاءة في سير عمل هندسة البرمجيات المهيكلة (مثل تحديث الأنظمة القديمة) مقارنة بسياسات التنفيذ الثابتة والحتمية. غالبًا ما تخلط الأدبيات الحالية بين استراتيجية التنسيق وقدرة النموذج أو تصميم الأوامر (prompts)، مما يجعل من الصعب عزل التأثير المحدد لآلية التحكم في التنفيذ.
المنهجية
يقدم المؤلفون دراسة تجريبية مضبوطة باستخدام إطار العمل ATLAS (الترجمة الآلية لأنظمة التطبيقات القديمة) لمقارنة استراتيجيتين للتنسيق: التنسيق الحتمي (Deterministic Orchestration) والتنسيق المتحكم به بواسطة النموذج اللغوي الكبير (LLM-Controlled Orchestration).
التصميم التجريبي
لعزل التنسيق كمتغير تجريبي وحيد، تثبت الدراسة العناصر التالية عبر جميع عمليات التشغيل:
الأدوات: مجموعات أدوات متطابقة (مثل read_file و write_file و run_command و git) مع نفس الواجهات والأذونات.
المدخلات: نفس برامج COBOL المصدرية ومدخلات الاختبار.
الإعدادات: حدود زمن الاستجاق (timeout) وأعلام التكوين (configuration flags) متطابقة.
استراتيجيات التنسيق
التنسيق الحتمي: يكون تسلسل استدعاء الأدوات، ومراحل التحقق، وسلوكيات إعادة المحاولة ثابتًا ومحددًا مسبقًا. يكون النموذج اللغوي مسؤولًا فقط عن توليد الكود ضمن مراحل محددة. لا يعتمد تدفق التنفيذ على مخرجات النموذج اللغوي الوسيطة؛ حيث يتم التحكم في التفرع الشرطي عبر محددات حتمية فوق حالة النظام (مثل حالة تعديل الملف).
التنسيق المتحكم به بواسطة النموذج اللغوي الكبير: يعمل النموذج اللغوي الكبير كمنسق مركزي، حيث يختار الأدوات ديناميكيًا، ويحدد ترتيب التنفيذ، ويختار استراتيجيات الإصلاح عند الفشل، ويقرر وقت الإنهاء. ينبثق تدفق التنفيذ من عملية التوليد الخاصة بالنموذج ويتأثر بالعينات العشوائية (stochastic sampling).
مجموعة البيانات والتقييم
مجموعة البيانات:مجموعة اختبار NIST COBOL85، والتي تضم مئات برامج COBOL ذاتية الاحتواء مع أدوات اختبار قابلة للتنفيذ ونتائج متوقعة محددة جيدًا.
المقاييس:
الدقة الحسابية (CA): التكافؤ الوظيفي بين برنامج Python المولد والنسخة المرجعية المكتوبة بـ COBOL عبر مدخلات الاختبار.
معدل النجاح (SR): وتيرة إنتاج خط أنابيب الترجمة لبرنامج قابل للتشغيل ويجتاز الاختبار عبر محاولات عشوائية متكررة (N من التنفيذات المستقلة).
متانة الحالة الأسوأ: تُقاس عبر المئوية الخامسة من الدقة الحسابية (P5-CA) والقيمة المشروطة للمخاطرة (CVaR) لرصد حالات الفشل في ذيل التوزيع (tail-risk failures).
الكفاءة: استهلاك الرموز (tokens) لكل ترجمة ناجحة، والتكلفة التشغيلية المقدرة.
المساهمات الرئيسية
إطار عمل مضبوط: قدم المؤلفون إطار عمل تجريبي موحد يعزل التحكم في التنفيذ كمتغير وحيد، مما يسمح بمقارنة مباشرة بين التنسيق الحتمي والوكيل دون عوامل مربكة.
المقايضة بين المتانة والتردد: تظهر الدراسة أنه بينما تحقق كلتا الاستراتيجيتين قدرة ترجمة إجمالية متقاربة، فإن التنسيق الحتمي يحسن بشكل كبير من متانة الحالة الأسوأ (مما يقلل من فشلات ذيل المخاطر وتقلب الأداء)، في حين أن التنسيق المتحكم به بواسطة النموذج اللغوي الكبير يحقق معدلات نجاح أعلى في إنتاج كود قابل للتشغيل عبر المحاولات المتكررة.
تحليل الكفاءة: تقدم الورقة تحليلًا كميًا يوضح أن التنسيق الحتمي يقلل من استهلاك الرموز بنسبة تصل إلى 3.5 ضعفًا، مما يؤدي إلى تكاليف تشغيلية أقل بكثير مقارنة بسير العمل الوكيل التكيفي.
النتائج
الصحة: حقق التنسيق الحتمي باستمرار دقة حسابية (CA) أعلى ومتانة أقوى في الحالة الأسوأ (P5-CA و CVaR أعلى) عبر نماذج متعددة (بما في ذلك Claude-Sonnet-4-5 و GPT-5.1-Codex-Max و Grok-Code-Fast-1).
معدل النجاح: حقق التنسيق المتحكم به بواسطة النموذج اللغوي الكبير معدل نجاح (SR) أعلى، مما يشير إلى أن التنفيذ التكيفي أدى في كثير من الأحيان إلى برامج قابلة للترجمة وتجتاز الاختبار في عمليات فردية. ومع ذلك، جاء ذلك على حساب ذيول أداء أثقل (فشل أكثر حدة في الحالات الأسوأ).
التكلفة والكفاءة: تطلب التنسيق المتحكم به بواسطة النموذج اللغوي الكبير رموزًا أكثر بكثير (على سبيل المثال، 1.75 مليون - 2.25 مليون رمز للوحدات المعقدة مقابل 400 ألف - 700 ألف للتنسيق الحتمي). نتج عن ذلك تكاليف تشغيلية أعلى بمقدار 3.5 ضعفًا لتدفقات العمل الوكيل (على سبيل المثال، >140 دولارًا مقابل ~40 دولارًا لمهام الإدخال/الإخراج التسلسلي لكل ترجمة ناجحة).
اتساق مجموعة الاختبار: أظهرت إحصائيات الاختبار الإجمالية أن كلتا الاستراتيجيتين يمكنهما ترجمة نفس مجموعة البرامج، ولكن التنسيق الحتمي وفر ضمانات أكثر اتساقًا لصحة المخرجات النهائية.
الأهمية والادعاءات
تجادل الورقة بأنه بالنسبة لـ سير عمل التحديث المهيكلة التي تتميز بمراحل تحقق صريحة وتبعية حتمية، فإن سياسات التنفيذ الثابتة توفر بديلًا أكثر استقرارًا وكفاءة من حيث التكلفة للتنسيق الوكيل الكامل دون التضحية بجودة الترجمة.
الآثار التصميمية: يجب التعامل مع التحكم في التنفيذ كقرار تصميم نظام أساسي وليس كنتيجة ضمنية لاستدلال النموذج اللغوي الكبير. في المهام ذات خطوط أنابيب التحويل الواضحة وإشارات التحقق القوية، يؤدي فصل التحكم في التنفيذ عن الاستدلال التوليدي إلى الحد من تراكم الأخطاء وتحسين القدرة على التنبؤ.
نطاق التطبيق: تشير النتائج إلى أنه بينما قد يظل التنسيق الوكيل قيمًا للمهام المفتوحة والاستكشافية (مثل اكتشاف المتطلبات)، فإن تحديث الأنظمة القديمة المهيكلة يستفيد من التنسيق الحتمي.
التواضع: يقر المؤلفون بالقيود، مشيرين إلى أن النتائج محددة بتحديث COBOL إلى Python ومجموعة NIST COBOL85، والتي قد لا تستوعب تمامًا تعقيد بيئات الإنتاج مع التبعات الخارجية (مثل JCL و CICS و VSAM). كما يلاحظون أن الدراسة تعزل استراتيجية التنسيق تحت ظروف مضبوطة، وقد تختلف النتائج مع استراتيجيات الأوامر أو بنيات النماذج المختلفة.
ختامًا، تفترض الدراسة أن دمج النماذج اللغوية الكبيرة ضمن أطر تنفيذ حتمية أمر بالغ الأهمية للحفاظ على الجدوى الاقتصادية والقدرة على التنبؤ بالتكاليف في مشاريع التحديث على مستوى المؤسسات، مما يتحدى الافتراض بأن تفويض كل التحكم إلى "الوكيل" هو بطبيعته الأفضل.