GPT-6 در COBOL به ۹۷٫۹٪ رسید؛ آزمون واقعی هنوز سامانهٔ قدیمی شماست

OpenAI در گزارش پژوهشی ۱۹ اکتبر ۲۰۲۶ خود اعلام کرد که GPT-6.1 Sol از خانوادهٔ GPT-6 در ارزیابی مهاجرت COBOL، با سطح بالاتر استدلال، به دقت ۹۷٫۹٪ رسیده است. این عدد به آزمونی تعلق دارد که در آن برنامهٔ بازنویسی‌شده باید رفتار برنامهٔ اصلی را در موارد پنهان حفظ کند. نتیجه، میزان موفقیت مهاجرت یک سامانهٔ مالی مشخص را نشان نمی‌دهد.

بررسی The Frontier توضیح می‌دهد که GPT-6.1 Sol در همین ارزیابی با استدلال کم ۸۶٫۶٪ ثبت کرد، در حالی که GPT-5.6 Sol در همان سطح به ۵٫۴٪ رسید؛ هزینهٔ API مدل جدید در آن مقایسه ۳۹٪ کمتر بود. رقم بالاتر با استدلال بیشتر به دست آمده است، بنابراین نمی‌توان آن را با مقایسهٔ هزینه و دقت در سطح استدلال کم یکی گرفت. برای تصمیم‌گیری دربارهٔ مهاجرت، شرط موفقیت هر مورد آزمون به اندازهٔ درصد نهایی اهمیت دارد.

آزمون مهاجرت COBOL چه چیزی را موفقیت می‌داند؟

در این ارزیابی، مدل برنامهٔ موجود COBOL را به یکی از زبان‌های C++، Java، Kotlin، Python یا Rust منتقل می‌کند. برنامهٔ تازه تنها زمانی یک مورد موفق به حساب می‌آید که همهٔ آزمون‌های پنهان را بگذراند و خروجی قابل مشاهدهٔ آن بایت‌به‌بایت با خروجی برنامهٔ مرجع برابر باشد. بنابراین درصد اعلام‌شده سهم مواردی است که از این شرط عبور کرده‌اند؛ درصد خط‌های کد درست یا درصد تراکنش‌های یک بانک نیست.

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

شرط برابری بایت‌به‌بایت از داوری بر اساس ظاهر کد سخت‌گیرانه‌تر است: یک خروجی متفاوت می‌تواند آن مورد مهاجرت را مردود کند. در عین حال، هر آزمون فقط رفتارهایی را آشکار می‌کند که ورودی‌هایش به آن‌ها می‌رسند. اگر قاعده‌ای در داده‌های آزمون فعال نشود، عبور برنامهٔ تازه نشان نمی‌دهد که آن قاعده هم درست منتقل شده است. این محدودیت هنگام انتقال نتیجه از مجموعهٔ ارزیابی به برنامه‌های یک سازمان تعیین‌کننده می‌شود.

سطح استدلال نتیجه را چگونه تغییر می‌دهد؟

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

نزدیک شدن امتیاز به سقف این ارزیابی یک پیام روش‌شناختی هم دارد. وقتی بیشتر موارد یک مجموعه حل می‌شوند، آن مجموعه برای نشان دادن تفاوت میان مدل‌های قوی‌تر اطلاعات کمتری می‌دهد. آزمون‌های دشوارتر، دامنهٔ روشن‌تری از برنامه‌ها و بازتولید مستقل می‌توانند تصویر دقیق‌تری از توان مهاجرت بسازند. تا آن زمان، امتیاز منتشرشده نتیجهٔ آزمون OpenAI با تنظیمات اعلام‌شده است، نه نرخ موفقیتی که بتوان برای هر مخزن COBOL پیش‌بینی کرد.

نتیجهٔ ساخت SQLite را با مهاجرت COBOL اشتباه نگیریم

تحلیل OrcaRouter از دو ارزیابی گزارش می‌کند که GPT-6 Astra در MultiLangBench، با حداکثر سطح استدلال، میانگین عبور ۸۷٫۴٪ را در ۲۰ زبان ثبت کرد؛ رقم GPT-5.6 Sol برابر ۲۶٫۸٪ بود و امتیاز Astra در بخش COBOL به ۷۲٫۱٪ رسید. در این آزمون، مدل باید از ابتدا موتوری سازگار با SQLite بسازد. این کار با حفظ رفتار یک برنامهٔ COBOL موجود هنگام انتقال آن به زبانی دیگر تفاوت دارد.

در MultiLangBench، به برنامهٔ ساخته‌شده یک پایگاه داده و یک پرس‌وجو داده می‌شود و پایگاه دادهٔ حاصل با اجرای مرجع SQLite سنجیده می‌شود. آزمون مهاجرت در عوض از برنامهٔ قدیمی به عنوان مرجع رفتار استفاده می‌کند و خروجی نسخهٔ منتقل‌شده را با آن می‌سنجد. به همین دلیل، امتیازهای این دو ارزیابی را نمی‌توان در یک رتبه‌بندی واحد گذاشت: یکی توان ساخت کارکرد تازه در زبان‌های گوناگون را می‌سنجد و دیگری وفاداری بازنویسی به رفتار برنامهٔ موجود را.

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

پذیرش مهاجرت در سامانهٔ واقعی به چه آزمونی نیاز دارد؟

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

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

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

بیشتر بخوانید:

• رزومه یا GitHub؛ کد واقعی جای روایت شغلی را نمی‌گیرد
• GPT-6 Sol یا Luna؛ کیفیت بیشتر ارزش هزینهٔ ۲۰ برابری را دارد؟
• پرامپت را مثل کد منتشر کنید؛ نسخهٔ بهتر بدون آزمون معلوم نمی‌شود