OpenAI מנסה לפתור את בעיית ה-COBOL של הבנקים
זינוק ל-97.9 אחוזי הצלחה בהמרת שפות מורשת נשמע כמו סוף עידן המיינפריים, אבל בלי כלי בדיקה פתוחים או אחריות משפטית, הבנקים עדיין יצטרכו לבדוק כל שורה.
- השתמשו ב-API של GPT-6.1 Sol להמרת מודולים בודדים ומבודדים בלבד, ואל תאשרו אף שורת לוגיקה פיננסית בלי בדיקת בייט-מול-בייט עצמאית.
המערכות שמנהלות את הכסף שלכם נכתבו בשנות השישים, והמתכנתים שיודעים לתקן אותן כבר מזמן בפנסיה. בנקים בישראל ובעולם מחזיקים עד היום ליבות פיננסיות שרצות על שפת COBOL ומחשבי מיינפריים ישנים של IBM, פשוט כי אף מנהל פיתוח שפוי לא רצה לקחת את הסיכון שבשכתוב מיליוני שורות קוד. עכשיו, OpenAI טוענת שהיא פיצחה את המחסום עם מודלים חדשים שיודעים להמיר את השפות האלה בדיוק כמעט מושלם. פרויקט כזה יכול לחסוך הון, אבל המחיר של טעות חישוב קטנה בחשבון עובר ושב עלול לעלות הרבה יותר.
מיינפריים ישן, מודל חדש
שפות כמו COBOL, Fortran ו-Visual Basic מניעות תשתיות קריטיות: מעל 40% ממערכות הבנקאות המקוונת ו-95% מעסקאות הכספומטים בעולם. למרות זאת, מודלי שפה התקשו בהן היסטורית כי אין ברשת מספיק קוד מודרני לאימון. כדי למדוד את השיפור, החברה פיתחה שני מבחנים נפרדים. הראשון הוא MultiLangBench, שבוחן בניית מנוע תואם SQLite מאפס ב-20 שפות, והשני הוא מבחן הגירה ייעודי שבודק המרת תוכניות COBOL לשפות מודרניות כמו Java ו-Python.
התוצאות במבחן MultiLangBench מציגות פער חד. מודל GPT-6 Astra רשם הצלחה ממוצעת של 87.4% על פני 20 השפות, לעומת 26.8% בלבד שרשם GPT-5.6 Sol. בתוך המבחן הזה, COBOL נשארה השפה הקשה ביותר עם 72.1% הצלחה בלבד, בעוד ביתר 19 השפות המודל חצה את רף ה-83%. לצידו הציגה החברה את GPT-6 Luna, גרסה חסכונית שהגיעה ל-40.3% הצלחה במחיר API מוערך של 0.77 דולר לדגימה, ירידה של כ-78% לעומת 3.48 דולר בדור הקודם.
פער שלוש הנקודות היקר
במבחן ההגירה של COBOL, OpenAI מציגה זינוק שנראה על הנייר כמו פתרון מלא. מודל GPT-6.1 Sol הגיע ל-86.6% דיוק במאמץ חישוב נמוך, בעלות API של 61% מעלות הדור הקודם, שהשיג 5.4% בלבד באותה הגדרה. כשמעלים את מאמץ החישוב לרמה גבוהה, המודל מזנק ל-97.9% דיוק ומגיע כמעט לרוויה מלאה של המבחן.
הפער הזה נשמע קטן, אבל בבנקאות ההבדל בין 86.6% ל-97.9% הוא המרחק שבין ריצה מוצלחת לקריסה תפעולית.
הבעיה מתחילה בעלויות של רמת החישוב הגבוהה. הרצת מודלים במאמץ חישוב מקסימלי דורשת טוקנים רבים של חשיבה פנימית, מה שמקפיץ את חשבון ה-API כשמנסים לעבד מיליוני שורות קוד של ליבה בנקאית שלמה. העלות של הרצת מאמץ חישוב גבוה לא פורסמה, אבל במערכות פיננסיות שגיאת חישוב אחת עלולה לעלות הרבה יותר. מנהלי פיתוח יצטרכו לבחור האם לשלם על ריצות יקרות מאוד, או להשאיר כמעט 15% מהקוד לבדיקה ידנית.
מלכודת העיגול והספרות החסרות
הקושי האמיתי במיגרציה מ-COBOL אינו תחבירי, אלא אריתמטי. COBOL משתמשת בחשבון נקודה קבועה (Fixed-point arithmetic) שזורק ספרות עשרוניות עודפות, אלא אם הוגדר במפורש לבצע עיגול. שפות מודרניות כמו Python או Java עובדות לעיתים קרובות עם נקודה צפה (Floating-point) או מבצעות עיגול כברירת מחדל. קוד שמומר לא נכון יכול לעבור קומפילציה, לרוץ חלק ולשנות לחלוטין את חישובי הריבית והעמלות בלי לייצר שום שגיאה ביומני הריצה.
כדי לבדוק זאת, מבחן ההגירה דרש התאמה של בייט מול בייט (Byte-for-byte parity) בין הפלט הישן לפלט החדש. OpenAI מגדירה הגירה כמוצלחת אך ורק אם כל הבדיקות הללו עברו במלואן. עם זאת, התאמת בייטים במבחן סינתטי אינה זהה להתמודדות עם מסדי נתונים היסטוריים ותלויות מיינפריים ותיקות. במערכות שבהן דוחות מס וחישובי ריבית נשענים על באגים היסטוריים שאיש אינו זוכר, קוד מודרני ותקין עשוי להתברר כאסון רגולטורי.
המבחן שאי אפשר לבדוק
ההבדל בין שני המבחנים של OpenAI חושף את נקודת התורפה הגדולה של ההכרזה. את מערך הבדיקות של MultiLangBench שחררה החברה ב-GitHub, וכל ארכיטקט תוכנה יכול לבחון את המימוש העצמאי של מנוע מסד הנתונים. לעומת זאת, מבחן ההגירה של COBOL נשאר קנייני וסגור בתוך שרתי OpenAI. אין כרגע שום דרך עצמאית לדעת מה כללו התוכניות שנבדקו, כמה תלויות חיצוניות היו בהן, והאם מדובר בלוגיקה פיננסית פשוטה או ברשת מסועפת של קבצים שטוחים.
יישום היכולות האלה על תוכנת ייצור עדיין דורש בדיקת מומחה ובחינה מול החוקים העסקיים והתלויות של המערכת.מתוך הפוסט הטכני של OpenAI
OpenAI עצמה מסייגת את התוצאות ומודה שהמודל אינו תחליף לעבודה הנדסית. החברה לא מספקת שום שיפוי משפטי או אחריות תפעולית לתקלות שייגרמו עקב קוד שהומר אוטומטית. אם שורת קוד אחת תעגל שברירי אגורות בצורה שגויה ותגרור קנס מבנק ישראל, האחריות תישאר כולה על הנהלת הבנק ולא על ספקית המודל מסן פרנסיסקו.
| מודל ומאמץ | משימה נבדקת | אחוז הצלחה | עלות מוערכת מול דור קודם |
|---|---|---|---|
| GPT-5.6 Sol | MultiLangBench (20 שפות) | 26.8% | בסיס להשוואה ($3.48 לדגימה) |
| GPT-6 Luna (מאמץ מרבי) | MultiLangBench (20 שפות) | 40.3% | נמוכה בכ-78% ($0.77 לדגימה) |
| GPT-6 Astra (מאמץ מרבי) | MultiLangBench (20 שפות) | 87.4% | לא פורסם |
| GPT-5.6 Sol (מאמץ נמוך) | הגירת קוד COBOL | 5.4% | בסיס להשוואה |
| GPT-6.1 Sol (מאמץ נמוך) | הגירת קוד COBOL | 86.6% | 61% מעלות GPT-5.6 Sol |
| GPT-6.1 Sol (מאמץ גבוה) | הגירת קוד COBOL | 97.9% | לא פורסם |
מה לבדוק לפני שמשכתבים
אם אתם מנהלים פיתוח בבנק מקומי או בחברת ביטוח, אל תמהרו לבטל את חוזי התחזוקה של המיינפריים. הכלי של OpenAI הוא מנוע תרגום לוגי מתקדם, לא מערכת הגירה אוטונומית מקצה לקצה. הדרך הנכונה לעבוד איתו בחודשים הקרובים היא לבודד תוכניות COBOL עצמאיות שאינן תלויות בממשקי חומרה סגורים, ולהריץ עליהן בדיקות דרך ה-API של GPT-6.1 Sol. בדקו במדויק את המרות האריתמטיקה והעיגולים, וחשבו את עלויות הטוקנים במאמץ חישוב גבוה מול שעות העבודה של מתכנתי הלגאסי שלכם. כנראה שתגלו שהקוד המומר דורש בדיקה של כל שורה ושורה.
בינתיים, המיינפריים בקומה מינוס שתיים במרכז תל אביב עדיין מזמזם ללא הפרעה.
מה שואלים על זה
- Advancing coding in low‑resource programming languagesopenai.com · המקור
- openai/MultiLangBenchgithub.com · קריאה נוספת
29 עובדות בכתבה נבדקו אחת־אחת מול המקורות המקושרים ומול חיפוש ברשת ב־20 באוקטובר 2026. מה שלא אומת הוסר או מסומן כטענה של החברה. הכתיבה נעשתה בעזרת AI מהמקורות האלה בלבד, בעריכה ובאחריות של סלבה מלנדוביץ׳. טעות? כתבו לנו.