ההתקדמות האחרונה במודלים שלנו משפרת את יכולות הפיתוח וההסבה של תוכנה בשפות תכנות דלות משאבים, כמו COBOL, Fortran ו-Visual Basic. בשפות האלה יש פחות קוד ותיעוד זמינים ללמידה של מודלים מאשר בשפות כמו Python ו-JavaScript, ובכל זאת הן משמשות תשתיות קריטיות ושירותים חיוניים ברחבי העולם. COBOL משמשת בסיס(נפתח בחלון חדש) ליותר מ-40% ממערכות הבנקאות המקוונת, ל-80% מעסקאות כרטיסי האשראי המתבצעות בנוכחות הלקוח ול-95% מהעסקאות בכספומטים, ואילו Fortran משמשת לחיזוי מזג האוויר(נפתח בחלון חדש) ולניתוח הבטיחות של כורים גרעיניים(נפתח בחלון חדש). שיפור יכולתה של הבינה המלאכותית לעבוד בשפות האלה עשוי לעזור לצוותים לתחזק ולחדש את התוכנה ששירותים חיוניים תלויים בה.
העבודה הזו מתבססת על משוב ממפתחים ומלקוחות ארגוניים, שסיפרו לנו שמודלים לכתיבת קוד מתקשים לעיתים קרובות בשפות האלה. התחזוקה והחידוש של תוכנות אלה עלולים להיות קשים: התיעוד עשוי להיות חלקי, המפתחים המקוריים אולי כבר עזבו את החברה, וייתכן שכללים עסקיים חשובים קיימים רק בקוד. בין שהצוותים מתקנים באגים ובין שהם מסבים את הקוד לשפה אחרת, עליהם לשמר את ההתנהגות שהמערכות שלהם מסתמכות עליה.
כדי למדוד את ההתקדמות, פיתחנו שני מבחני הערכה. MultiLangBench בוחן אם מודל יכול לבנות מאפס מנוע מסד נתונים תואם SQLite ב-20 שפות תכנות שונות. מבחן ההערכה שלנו להסבת קוד COBOL בוחן אם מודל יכול להסב תוכניות קיימות לשפה אחרת תוך שימור התנהגותן. יחד, הם בוחנים שתי מיומנויות משלימות: פיתוח תוכנה חדשה ושימור אופן הפעולה של תוכנה קיימת.
המודלים החדשים שלנו מציגים שיפורים משמעותיים בשני מבחני ההערכה, עם דיוק גבוה בהרבה בעלות נמוכה יותר.
ב-MultiLangBench, GPT‑6 Astra משיג שיעור ממוצע של 87.4% בדיקות שעברו בהצלחה ב-20 שפות תכנות, לעומת 26.8% ב-GPT‑5.6 Sol, עם שיפורים בכל אחת מהשפות שנבדקו. גם GPT‑6 Luna עולה בביצועיו על GPT‑5.6 Sol, עם שיעור של 40.3% ועלות API משוערת נמוכה בכ-78%.
במבחן ההערכה שלנו להסבת קוד COBOL, GPT‑6.1 Sol משיג דיוק של 86.6% ברמת מאמץ reasoning נמוכה, לעומת 5.4% בלבד ב-GPT‑5.6 Sol, ובעלות נמוכה ב-39%. ברמת מאמץ reasoning גבוהה יותר, הדיוק מגיע ל-97.9%, כמעט עד לתקרת מבחן ההערכה.
במכלול, התוצאות האלה מראות שהמודלים שלנו משתפרים באופן משמעותי בעבודה עם מגוון רחב של שפות תכנות, ובמקביל נעשים חסכוניים יותר.
ב-MultiLangBench, המודל מתבקש לבנות מנוע מסד נתונים תואם SQLite בשפת תכנות מוגדרת. על המודל לארגן בסיס קוד, לנהל מצב, לטפל בשגיאות ולהוסיף יכולות חדשות תוך שימור הפונקציונליות הקיימת.
כדי להשוות בין מימושים בשפות שונות, אנחנו משתמשים בקובצי מסד נתונים כממשק משותף. התוכנית הנבדקת מקבלת מסד נתונים התחלתי ושאילתת SQL, ומפיקה מסד נתונים מעודכן. אנחנו משתמשים במימוש הייחוס של SQLite כדי לבדוק אם מסד הנתונים שהתקבל מכיל את התוכן הצפוי. כך אפשר להפעיל את אותן בדיקות ללא תלות בשפה שבה נבנה המנוע.
התאמנו לפורמט הזה בדיקות מתוך חבילת הבדיקות הקיימת של SQLite. מבחן ההערכה מודד את היקף הפונקציונליות התקינה שמודל יכול לפתח במהלך סבב עבודה ממושך של כתיבת קוד, ומציג הן את שיעור הבדיקות שעברו בהצלחה והן את עלות ה-API.
ברמת מאמץ reasoning מקסימלית, GPT‑6 Astra משיג שיעור ממוצע של 87.4% בדיקות שעברו בהצלחה ב-20 השפות, לעומת 26.8% ב-GPT‑5.6 Sol. השיפורים ניכרים בכל השפות שנבדקו, ובהן COBOL (מ-10.9% ל-72.1%), OCaml (מ-25.6% ל-85.8%), Fortran (מ-21.4% ל-83.5%) ו-Visual Basic (מ-27.5% ל-89.4%). Astra משיג ציון גבוה מ-83% ב-19 מתוך 20 השפות. COBOL נותרת השפה המאתגרת ביותר, עם ציון של 72%.
GPT‑6 Luna מציע חלופה זולה יותר, שגם היא עולה בביצועיה על GPT‑5.6 Sol בכל השפות שנבדקו. ברמת מאמץ reasoning מקסימלית, הוא מגיע לשיעור ממוצע של 40.3% בדיקות שעברו בהצלחה. השיפורים כוללים את COBOL (מ-10.9% ל-17.1%), OCaml (מ-25.6% ל-34.1%), Fortran (מ-21.4% ל-31.4%) ו-Visual Basic (מ-27.5% ל-41.6%). השיפורים האלה מושגים בעלות API ממוצעת משוערת של 0.77 דולר לדגימה, לעומת 3.48 דולר ב-GPT‑5.6 Sol — עלות נמוכה בכ-78%.
אנחנו מפרסמים את מערך ההערכה ואת חבילת הבדיקות של MultiLangBench ב-GitHub(נפתח בחלון חדש), לצד התוצאות לכל שפה. מפתחים יכולים לבחון מה נבדק במבחן ההערכה, לסקור את הביצועים בשפות שבהן הם משתמשים ולזהות פערים שחשובים לעבודתם.
במבחן ההערכה השני שלנו, המודלים מתבקשים להסב תוכניות COBOL ל-C++, Java, Kotlin, Python או Rust, תוך שימור אופן הפעולה של כל תוכנית.
הסבה מוצלחת מחייבת הבנה הן של הלוגיקה העסקית של התוכנית והן של ההתנהגות הייחודית לשפת COBOL. תוכניות COBOL מעבדות לעיתים קרובות עסקאות פיננסיות ורשומות עסקיות, שבהן פרטים כמו כללי עיגול ואופן הטיפול ברשומות חסרות משקפים דרישות עסקיות. לדוגמה, בחישובי נקודה קבועה ב-COBOL, ספרות עשרוניות עודפות נחתכות, אלא אם התבקש עיגול במפורש. גרסה משוכתבת שמעגלת את הערכים האלה במקום לחתוך אותם יכולה לרוץ ללא שגיאות, אך להפיק תוצאות פיננסיות שונות.
כדי לבדוק אם התנהגויות אלה נשמרות, אנחנו מעריכים את המודלים באמצעות בדיקות נסתרות, המחייבות התאמה בית לבית של הפלטים הנצפים. הסבה נחשבת מוצלחת רק אם כל הבדיקות עוברות בהצלחה. יכולות כאלה לשימור התנהגות מועילות לצוותים שמתחזקים ומחדשים מערכות ותיקות. עם זאת, השימוש בהן בתוכנה בסביבת ייצור עדיין מחייב סקירת מומחים ובדיקות מול הכללים העסקיים של המערכת ורכיבי התוכנה שבהם היא תלויה.
במבחן ההערכה הזה, GPT‑6.1 Sol משיג דיוק של 86.6% ברמת מאמץ reasoning נמוכה, לעומת 5.4% ב-GPT‑5.6 Sol באותה רמה — וב-61% בלבד מעלות ה-API. ברמת מאמץ reasoning גבוהה יותר, הדיוק מגיע ל-97.9%, קרוב לתקרת מבחן ההערכה. תוצאות אלה מעידות על התקדמות לקראת הסבת קוד מדויקת וזולה יותר עבור צוותים שמחדשים את התוכנה שהעסקים שלהם תלויים בה.
מבחני ההערכה האלה, לצד משוב ישיר ממפתחים ומלקוחות ארגוניים, עוזרים לנו לראות היכן המודלים שלנו משתפרים והיכן הם עדיין מתקשים.
המטרה שלנו היא לעזור למודלים ליישם מיומנויות של הנדסת תוכנה בשפות נוספות: להבין מאגרים לא מוכרים, לתכנן שינויים, להשתמש בכלי בנייה, להריץ בדיקות ולאתר ולתקן תקלות.
אפשר לנסות את המודלים החדשים שלנו דרך ה-API במשימות כתיבת קוד בשפות שהצוות שלכם משתמש בהן. המשוב שלכם על מה שעובד, על המקומות שבהם המודלים מתקשים ועל השפות או תהליכי העבודה שכדאי להתמקד בהם בהמשך, עוזר לעצב את האופן שבו אנחנו מאמנים ומעריכים מודלים כדי לתמוך טוב יותר בתוכנה שאתם תלויים בה.
