رمزگشایی از کدهای ۶۰ ساله بانک‌ها؛ جهش خیره‌کننده مدل GPT-6 Astra اوپنای‌آی در زبان کوبول

اوپنای‌آی نتایج بنچمارک جدیدی را منتشر کرده است که از جهش چشمگیر مدل‌های هوش مصنوعی در درک زبان‌های برنامه‌نویسی کم‌منبع (Low-resource) از جمله کوبول (COBOL)، فرترن (Fortran)، اوکمل (OCaml) و ویژوال بیسیک (Visual Basic) حکایت دارد. این شرکت هم‌زمان بنچمارک متن‌باز MultiLangBench را برای مقایسه مدل‌های کدنویسی در ۲۰ زبان برنامه‌نویسی مختلف، همراه با یک ارزیابی جداگانه برای مهاجرت و تبدیل برنامه‌های کوبول بدون تغییر در رفتار و خروجی آن‌ها در دسترس عموم قرار داده است. اوپنای‌آی جزئیات این دستاورد فنی را در گزارش منتشرشده خود شرح داده است.

زبان‌های برنامه‌نویسی کم‌منبع در مقایسه با زبان‌های محبوبی مثل پایتون یا جاوااسکریپت، مجموعه‌داده آموزشی عمومی بسیار کمتری دارند، با این حال همچنان ستون فقرات سیستم‌های فوق‌العاده حساس و حیاتی جهان به شمار می‌روند. طبق برآوردهای ارائه‌شده از سوی اوپنای‌آی، زبان ۶۰ ساله کوبول هنوز بیش از ۴۰ درصد از سیستم‌های بانکداری آنلاین، ۸۰ درصد از تراکنش‌های حضوری کارت‌های اعتباری و ۹۵ درصد از تراکنش‌های دستگاه‌های عابربانک (خودپرداز) را پشتیبانی می‌کند. از سوی دیگر، زبان فرترن نیز نقشی کلیدی در پیش‌بینی آب‌وهوا و تحلیل‌های ایمنی تأسیسات هسته‌ای دارد.

نگاهی اجمالی به نتایج بنچمارک

بنچمارک MultiLangBench از مدل می‌خواهد که یک موتور پایگاه‌داده سازگار با SQLite را از صفر در ۲۰ زبان برنامه‌نویسی مختلف بسازد. در سوی دیگر، ارزیابی مهاجرت (Migration) می‌سنجد که آیا مدل می‌تواند یک برنامه کوبول را به زبانی مدرن ترجمه کند؛ به گونه‌ای که تمامی رفتارهای آزمایش‌شده بدون کوچک‌ترین نقصی حفظ شوند یا خیر.

مدل GPT-6 Astra در ۱۹ زبان از مجموع ۲۰ زبان، به نرخ قبولی بالای ۸۳ درصد دست یافته است. در این میان، کوبول با ثبت ۷۲٫۱ درصد همچنان سخت‌ترین زبان برای مدل به شمار می‌رود، هرچند همین نتیجه نیز بیش از ۶ برابر امتیاز مدل نسل قبلی است. متغیر «تلاش استنتاجی» (Reasoning Effort) یکی از تنظیمات API است که میزان محاسبات و پردازش درونی مدل را پیش از ارائه پاسخ نهایی کنترل می‌کند؛ مقادیر بالاتر این تنظیمات، تأخیر در پاسخگویی و میزان مصرف توکن را افزایش می‌دهند.

کاهش هزینه‌های ذکرشده صرفاً برآورد مصرف API را پوشش می‌دهد و هزینه‌های مهندسی جانبی از جمله توسعه تست‌ها، تحلیل وابستگی‌ها، بازبینی کد (Code Review)، یکپارچه‌سازی و استقرار در محیط عملیاتی را در بر نمی‌گیرد.

چرا مهاجرت از کدهای کوبول با چالش‌های معنایی روبه‌رو می‌شود؟

برنامه‌های نوشته‌شده با کوبول اغلب قوانین مالی و محاسباتی پیچیده را بر اساس رفتارهای خاص و درونی خودِ این زبان پیاده‌سازی کرده‌اند. برای نمونه، محاسبات نقطه ثابت (Fixed-point arithmetic) در کوبول رقم‌های اعشاری مازاد را بدون گرد کردن دور می‌اندازد؛ مگر اینکه در برنامه صراحتاً دستور گرد کردن قید شده باشد. حال اگر بازنویسی کد این مقادیر را به‌صورت خودکار گرد کند، ممکن است برنامه بدون خطا کامپایل شود و حتی تست‌های اولیه و ناقص را هم پشت سر بگذارد، اما در ابعاد کلان و در دنیای واقعی به محاسبات نادرست در سود بانکی یا تسویه‌حساب‌ها منجر شود.

اوپنای‌آی یک عملیات مهاجرت کد را تنها زمانی موفقیت‌آمیز در نظر می‌گیرد که برنامه در تمام تست‌ها قبول شود. تست‌های پنهان این ارزیابی نیازمند مطابقت بایت‌به‌بایت در خروجی‌های قابل‌مشاهده هستند؛ معیاری بسیار سخت‌گیرانه‌تر از بنچمارک‌های معمولی که صرفاً کامپایل شدن کد و قبولی در چند تست ابتدایی و آشکار را ملاک موفقیت قرار می‌دهند.

یک مأموریت واحد در ۲۰ زبان برنامه‌نویسی

در بنچمارک MultiLangBench، هر پیاده‌سازی یک پایگاه‌داده اولیه و یک پرس‌وجوی SQL دریافت کرده و سپس فایل پایگاه‌داده اصلاح‌شده را به‌عنوان خروجی تولید می‌کند. در ادامه، یک پیاده‌سازی مرجع از SQLite بررسی می‌کند که آیا فایل نهایی دقیقاً حاوی داده‌های موردانتظار هست یا خیر.

استفاده از فایل پایگاه‌داده به‌عنوان رابط ارزیابی، به این مجموعه تست اجازه می‌دهد تا پیاده‌سازی‌های انجام‌شده در زبان‌های کاملاً متفاوتی مثل زیگ (Zig)، کامن لیسپ (Common Lisp)، پاورشل (PowerShell) و کوبول را بسنجد. این طراحی هوشمندانه از فرمت‌های خروجی وابسته به زبان دوری می‌کند و برای تمام گزینه‌ها یک هدف خروجی یکسان و قابل‌اندازه‌گیری فراهم می‌سازد.

بنچمارک MultiLangBench کارایی مدل‌ها را در یک سناریوی مشخص و محدود یعنی ساخت موتور پایگاه‌داده ارزیابی می‌کند. بنابراین وظایفی چون نگهداری در سطح کل مخزن کد (Repository)، استفاده از فریمورک‌ها، مدیریت وابستگی‌ها و خطایابی در محیط واقعی به ارزیابی‌های مجزایی نیاز دارند. اوپنای‌آی ساختار ارزیابی، مجموعه تست‌ها و نتایج اختصاصی هر زبان را در مخزن بنچمارک در گیتهاب منتشر کرده است تا تیم‌های مهندسی بتوانند روش‌شناسی کار را بررسی کرده و مقایسه‌های اختصاصی خود را انجام دهند.

کاربردهای عملی برای نوسازی سیستم‌های قدیمی

• پروژه‌های آزمایشی مهاجرت: تولید پیش‌نویس‌های ترجمه از کوبول به جاوا، پایتون یا راست (Rust) و سپس مقایسه رفتاری برنامه اصلی و نسخه مهاجرت‌یافته در برابر ورودی‌های یکسان.
• نگهداری و توسعه سیستم: توضیح روال‌ها و کدهای نامأنوس قدیمی، ردگیری جریان داده‌ها و پیشنهاد پچ‌های اصلاحی در کدهایی که فاقد مستندات کافی هستند.
• استخراج قوانین تجاری: کشف و استخراج رفتارهای نهفته در کدهای قدیمی و تبدیل آن‌ها به سناریوهای تست، پیش از ایجاد هرگونه تغییر در پیاده‌سازی سیستم.
• محاسبات علمی: یاری رساندن به تیم‌هایی که کدهای فرترن را در حوزه‌های هواشناسی، اقلیم‌شناسی، فیزیک و پروژه‌های پیچیده مهندسی نگهداری می‌کنند.

ضرورت کنترل‌های سخت‌گیرانه برای استفاده در محیط عملیاتی

دقت گزارش‌شده همچنان احتمال بروز خطا را به‌طور کامل از بین نمی‌برد؛ خطاهایی که ممکن است صرفاً هنگام مغایرت‌گیری‌های بانکی، گزارش‌گیری‌های مالی یا فرآیند بستن حساب‌ها در پایان سال خود را نشان دهند. بنابراین، ارزیابی در محیط عملیاتی باید علاوه بر سورس‌کد ترجمه‌شده، کل سیستم‌های پیرامونی را نیز پوشش دهد.

1. فهرست‌برداری دقیق از کپی‌بوک‌ها (Copybooks)، انکودینگ فایل‌ها، اسکریپت‌های کنترل پردازش (Job-control)، فراخوانی‌های پایگاه‌داده و وابستگی‌های خارجی.
2. ایجاد مجموعه‌ای جامع از ورودی‌ها و خروجی‌های واقعی و شناخته‌شده، از جمله داده‌های مخدوش و سناریوهای مرزی و نادر تاریخی.
3. اجرای تست‌های تطبیقی (Differential Testing) که برنامه قدیمی و برنامه جدید را هم‌زمان با داده‌های یکسان اجرا کرده و نتایج را مقایسه می‌کنند.
4. بررسی محاسبات ریاضی، تغییرات وضعیت (State Changes)، مدیریت خطا و ساختار رکوردها توسط مهندسان مسلط به حوزه مالی و کدهای قدیمی.
5. استقرار گام‌به‌گام یا اجرای سایه‌ای (Shadow Runs) در کنار تدوین رویه‌های دقیق مغایرت‌گیری و امکان بازگشت سریع به نسخه قبلی (Rollback).

افق روشن پیش روی زبان‌های کم‌منبع

پشتیبانی گسترده‌تر از زبان‌های برنامه‌نویسی متنوع می‌تواند زمان لازم برای فهم و بازنویسی سیستم‌هایی را که تاکنون بهره چندانی از مدل‌های آموزش‌دیده روی زبان‌های محبوب گیتهاب نبرده‌اند، به‌شدت کاهش دهد. محتمل‌ترین کاربرد کوتاه‌مدت این مدل‌ها، کمک در تحلیل کدها، تولید خودکار تست و نگارش پیش‌نویس مهاجرت خواهد بود؛ در حالی که مسئولیت نهایی اعتبارسنجی و انتشار در سیستم همچنان بر عهده مهندسان انسانی باقی می‌ماند.

اوپنای‌آی اعلام کرده که این مدل‌ها از طریق API در دسترس قرار دارند و از بازخورد تیم‌ها درباره پشتیبانی از زبان‌ها و جریان‌های کاری جدید استقبال می‌کند. سازمان‌ها و تیم‌هایی که کدهای زبان‌هایی چون ایدا (Ada)، پی‌ال/وان (PL/I)، آرپی‌جی (RPG) یا سایر زبان‌های کم‌منبع را نگهداری می‌کنند، می‌توانند از این بنچمارک عمومی به‌عنوان نقطه آغازی برای ارزیابی‌های اختصاصی خود بهره بگیرند.