لماذا يتسبب COBOL المترجم بالذكاء الاصطناعي في انهيار قاعدة بياناتك

المشكلة

طلب بنك كبير من الذكاء الاصطناعي إعادة كتابة ثلاثين عامًا من كود COBOL إلى Java. تَرجم الذكاء الاصطناعي الصياغة البرمجية بشكل مثالي. تم تصريف الكود بنجاح. واجتازت اختبارات الوحدة. ثم أدت أول معاملة إلى انهيار قاعدة البيانات.

لم يكن لهذا الفشل أي علاقة بسوء الكود. كانت لغة Java سليمة نحويًا بشكل كامل. المشكلة كانت في اعتمادية خفية — متغير اسمه TRN-LIMIT معرَّف في ملف ترويسة مشترك يبعد آلاف الأسطر عن الكود الذي ترجمه الذكاء الاصطناعي فعليًا. وكان ذلك الملف يحتوي على بند REDEFINES، وهي ميزة في COBOL تتيح لعنوان ذاكرة واحد أن يحمل نوعين مختلفين من البيانات بحسب علم يُضبط في وحدة برمجية مختلفة تمامًا. لم يرَ الذكاء الاصطناعي أيًّا من هذا. لقد تعامل مع TRN-LIMIT بوصفه رقمًا بسيطًا. وفي الحقيقة، كان عددًا عشريًا مضغوطًا. وتسبب هذا عدم التطابق في قيام تطبيق Java بكتابة بيانات ثنائية تالفة في قاعدة البيانات، مما أطلق فشلًا في سلامة المراجع.

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

لماذا يهم هذا أعمالك

التعرض المالي هنا هائل، ويمس كل سطر في ميزانيتك العمومية.

الدين التقني في الولايات المتحدة وحدها بلغ ما يقدَّر بـ1.52 تريليون دولار. إذا كانت مؤسستك تُشغّل أنظمة قديمة، فأنت تتحمل نصيبًا من هذا العبء الآن. نحو 80% من ميزانيات تقنية المعلومات الفيدرالية تذهب إلى التشغيل والصيانة — ولا يتبقى سوى 20% لأي شيء جديد. والقطاع المصرفي هو الأكثر تعرضًا للخطر: 43% من الأنظمة المصرفية لا تزال تعمل على COBOL، وتعالج تلك الأنظمة 95% من جميع معاملات الصراف الآلي.

وهذا ما يعنيه ذلك بالنسبة لملف المخاطر لديك:

• التعرض الأمني يتضاعف ثلاث مرات. الأنظمة الأقدم من عشر سنوات أكثر عرضة إحصائيًا بثلاث مرات لتعرّضها لاختراق بيانات مقارنة بالتطبيقات الحديثة. وكل ربع سنة تؤجل فيه التحديث، تتسع مساحة الهجوم لديك.
• الامتثال يشتد. تنظيمات مثل GDPR وDORA تفرض تقارير فورية وضوابط لخصوصية البيانات. الأنظمة القديمة لم تُصمَّم لهذه المتطلبات. إن عجزك عن التكيف أصبح خطر امتثال سيلاحظه منظّموك.
• خبراؤك يرحلون. المطوّرون الذين كتبوا هذه الأنظمة يقبلون التقاعد. يقول 58% من المطوّرين إنهم يفكرون في ترك العمل بسبب حزم التقنيات القديمة. وعندما تغادر المعرفة المؤسسية من الباب، ترتفع تكاليف الصيانة لديك أكثر.
• الترحيلات الفاشلة تهدر الملايين. بمعدل فشل يبلغ 70-80%، فإن الاحتمالات ضدك. الترحيل الذي يسوء لا يكلف ميزانية المشروع فحسب — بل يضر بالثقة في قيادتك التقنية ويؤخر القدرات التجارية التي تنتظرها فرقك.

مجلس إدارتك يريد التحول الرقمي. ومنظّموك يريدون ضوابط حديثة. وميزانيتك مشدودة أصلًا لمجرد إبقاء الأنظمة تعمل. لا يمكنك تحمّل ترحيل يفشل بصمت.

ما الذي يحدث فعلًا تحت الغطاء

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

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

الفشل التقني المحدد يُسمى تأثير «الضائع في المنتصف» (Lost in the Middle). نماذج اللغة الكبيرة — محركات الذكاء الاصطناعي التي تقف وراء أدوات مثل مساعدي كتابة الكود — تعالج النص باستخدام آلية الانتباه. وقد أثبتت الأبحاث أن هذه النماذج تُظهر قدرة استرجاع قوية للمعلومات الواقعة في بداية المدخل الطويل ونهايته، لكن أداءها ينخفض بشكل حاد مع المعلومات المدفونة في منتصفه. وفي برنامج COBOL يمتد لآلاف الأسطر ويشير إلى ملفات خارجية، غالبًا ما تقع تعريفات المتغيرات الحرجة تمامًا في تلك النقطة العمياء.

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

ما ينجح (وما لا ينجح)

لنبدأ بما جرت فرقك تجربته أو التفكير فيه على الأرجح — ولماذا يقصر كل نهج عن الهدف.

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

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

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

وإليك ما ينجح فعلًا — نهج قائم على الرسم البياني يعامل كودك كنظام مترابط وليس ككومة من ملفات نصية:

1. حلّل البنية، لا النص فحسب. بدلًا من تقطيع كودك إلى أجزاء نصية اعتباطية، تحلّل كل ملف إلى شجرة تمثل بنيته المنطقية — كل متغير، وكل دالة، وكل فرع من فروع التحكم في التدفق. يضمن هذا احترام الذكاء الاصطناعي لحدود كودك. فالدالة تُعامل كوحدة منطقية كاملة، وليس كشريحة عشوائية من النص.

2. ابنِ خريطة لكل علاقة. تستخرج كل وصلة في قاعدة كودك — أي الوحدات تستدعي أي إجراءات فرعية، وأي الملفات تُعرّف أي متغيرات، وأي الدوال تُحدّث أي جداول قاعدة بيانات — وتخزّنها في رسم بياني معرفي. عندما يحتاج الذكاء الاصطناعي إلى ترجمة دالة دفع، فهو لا يلتقط النص الذي يذكر «الدفع» فحسب. بل يتبع سلسلة الاعتماديات الفعلية ليجلب كل تعريف متغير، وكل ترويسة مشتركة، وكل تأثير لاحق. هذا ما تسميه Veriprajna الرسم البياني المعرفي الواعي بالمستودع، وهو يحل مباشرةً مشكلة «الضائع في المنتصف».

3. تحقق من كل مخرَج مقابل الخريطة. يولّد الذكاء الاصطناعي كود Java، ثم يصرّفه في بيئة معزولة. إذا ألقى المُصرِّف خطأ — كمتغير مفقود مثلًا — يستعلم النظام الرسم البياني، فيجد الاعتمادية، ويعيد توليد الكود. تعمل حلقة التصريف والإصلاح هذه تلقائيًا. يراجع مطوروك مخرجات مُتحقق منها، وليس تخمينات خام من الذكاء الاصطناعي.

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

ويقضي هذا النهج أيضًا على الهدر قبل بدء الترحيل. يحدد الرسم البياني المعرفي الكود الميت — الدوال التي لا يستدعيها أي شيء في نظامك فعليًا. وإزالة الكود الميت تقلل قاعدة الكود عادةً بنسبة 20-30%، مما يعني تكاليف ترحيل أقل ونظامًا نهائيًا أنظف.

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

يمكنك قراءة التحليل التقني الكامل للاطلاع على التفاصيل الهندسية، أو استكشاف النسخة التفاعلية لمشاهدة شرح مرئي لكيفية عمل الرسم البياني المعرفي عمليًا.