הבעיה
בנק גדול ביקש מבינה מלאכותית לשכתב שלושים שנות קוד COBOL ל-Java. הבינה המלאכותית תרגמה את התחביר באופן מושלם. הקוד עבר הידור. מבחני היחידה עברו בהצלחה. ואז העסקה הראשונה ריסקה את מסד הנתונים.
הכישלון לא היה קשור כלל לקוד גרוע. ה-Java היה חסר רבב מבחינה דקדוקית. הבעיה הייתה תלות נסתרת — משתנה בשם TRN-LIMIT שהוגדר בקובץ כותרת משותף, אלפי שורות הרחק מהקוד שאותו הבינה המלאכותית באמת תרגמה. קובץ הכותרת הזה הכיל פסקת REDEFINES — תכונה של COBOL המאפשרת לכתובת זיכרון אחת להחזיק שני סוגי נתונים שונים בהתאם לדגל שנקבע במודול אחר לגמרי. הבינה המלאכותית מעולם לא ראתה אף אחד מאלה. היא התייחסה אל TRN-LIMIT כאל מספר פשוט. במציאות, מדובר היה בעשרון ארוז (packed decimal). חוסר ההתאמה גרם לאפליקציית ה-Java לכתוב נתונים בינאריים פגומים אל מסד הנתונים, ולעורר כשל שלמות הפניה.
זהו לא מקרה קצה. מחקרים מראים ש-70% עד 80% מפרויקטי המודרניזציה של מערכות מורשת אינם עומדים ביעדים שלהם. סביר להניח שהארגון שלכם מפעיל מערכות קריטיות על קוד שגילו עולה על זה של רוב העובדים שלכם. אם אתם מתכננים הגירה — או כבר בעיצומה — דפוס הכישלון הזה צריך להדאיג אתכם עמוקות. הבינה המלאכותית לא שגתה בהקלדה. היא פספסה קשר גומלין שלא יכלה לראות. זהו סוג סיכון שונה באופן מהותי, ורוב הכלים הקיימים כיום אין להם מענה עבורו.
מדוע זה חשוב לעסק שלכם
החשיפה הפיננסית כאן עצומה, והיא נוגעת בכל שורה במאזן שלכם.
חוב טכנולוגי בארצות הברית לבדה מוערך כעת ב-$1.52 טריליון. אם בארגון שלכם פועלות מערכות מורשת, אתם נושאים כרגע נתח מהנטל הזה. כ-80% מתקציבי ה-IT הפדרליים מוקדשים לתפעול ותחזוקה — ונותרים רק 20% לכל דבר חדש. ענף הבנקאות חשוף במיוחד: 43% ממערכות הבנקאות עדיין רצות על COBOL, ומערכות אלה מעבדות 95% מכלל עסקאות ה-ATM.
וזו המשמעות עבור פרופיל הסיכון שלכם:
- החשיפה הביטחונית משולשת. מערכות בנות יותר מעשר שנים נתונות סטטיסטית לסיכון גבוה פי שלושה לפריצת נתונים בהשוואה ליישומים מודרניים. כל רבעון שבו תדחו את המודרניזציה, משטח התקיפה שלכם גדל.
- הרגולציה מהדקת את הגהים. רגולציות כמו GDPR ו-DORA מחייבות דיווח בזמן אמת ובקרות פרטיות נתונים. מערכות מורשת לא תוכננו לדרישות האלה. חוסר היכולת שלכם להסתגל הופך לסיכון רגולטורי שהרגולטורים שלכם יבחינו בו.
- המומחים שלכם עוזבים. המפתחים שכתבו את המערכות האלה פורשים לגמלאות. 58% מהמפתחים אומרים שהם שוקלים להתפטר בשל סטאקים טכנולוגיים ישנים. כשידע מוסדי יוצא מהדלת, עלויות התחזוקה שלכם ממשיכות לטפס.
- הגירות כושלות מבזבזות מיליונים. עם שיעור כישלון של 70-80%, הסיכויים נגדכם. הגירה כושלת לא עולה רק את תקציב הפרויקט — היא פוגעת באמון בהנהגה הטכנולוגית שלכם ומעכבת את היכולות העסקיות שהצוותים שלכם מחכים להן.
הדירקטוריון שלכם רוצה טרנספורמציה דיגיטלית. הרגולטורים שלכם רוצים בקרות מודרניות. התקציב שלכם כבר מתוח עד הקצה רק כדי לשמור על האורות דולקים. אתם לא יכולים להרשות לעצמכם הגירה שנכשלת בשקט.
מה באמת קורה מתחת למכסה המנוע
כדי להבין מדוע בינה מלאכותית סטנדרטית נכשלת בכך, חשבו על מאגר הקוד שלכם כעל עיר. כל פונקציה, משתנה וטבלת מסד נתונים הוא בניין. החיבורים ביניהם — איזו פונקציה קוראת לאיזו, איזה משתנה מזין איזה חישוב — הם הכבישים.
כעת דמיינו שאתם מוסרים למישהו ספר טלפונים של כל הבניינים בעיר ומבקשים ממנו לתכנן מחדש את מערכת התחבורה. יש בידיו שמות וכתובות, אך אין לו מפה. הוא אינו יכול לראות אילו כבישים מחברים אילו בניינים. זה בדיוק מה שכלי בינה מלאכותית סטנדרטי לכתיבת קוד עושה עם הקוד שלכם. הוא קורא את הטקסט אך אינו רואה את המבנה.
כישלון הטכני הספציפי נקרא אפקט ה-"Lost in the Middle". מודלים שפתיים גדולים — מנועי הבינה המלאכותית שמאחורי כלים כמו עוזרי קידוד — מעבדים טקסט באמצעות מנגנון קשב. מחקרים הוכיחו שהמודלים האלה מפגינים יכולת שליפה חזקה עבור מידע בתחילתו ובסופו של קלט ארוך, אך הביצועים שלהם צונחים עבור מידע הקבור באמצע. בתוכנית COBOL שמשתרעת על פני אלפי שורות ומפנה לקבצים חיצוניים, הגדרות משתנים קריטיות נמצאות לרוב בדיוק באותה נקודה עיוורת.
כשהבינה המלאכותית מפספסת הגדרה, היא לא עוצרת ושואלת. היא מנחשת. היא ממלאת את הפער במשהו סביר מבחינה סטטיסטית אך שגוי מבחינה עובדתית. בטרמינולוגיה של בינה מלאכותית, זה נקרא הזיה. במערכת הבנקאות שלכם, פירוש הדבר שהבינה המלאכותית עלולה להניח שמשתנה הוא מספר שלם כשלמעשה הוא עשרון ארוז. הנחה שגויה אחת כזו עלולה לשחת נתונים פיננסיים, לשבור את שלמות מסד הנתונים ולהשבית מערכת עסקאות. הקוד שלכם עובר הידור. המבחנים שלכם עוברים. סביבת הייצור שלכם נכשלת.
מה עובד (ומה לא)
נתחיל במה שהצוותים שלכם כנראה כבר ניסו או שקלו — ומדוע כל גישה כזו אינה מספיקה.
Lift and Shift (Rehosting): אתם מעבירים את היישום המהודר לאמולטור בענן. זה משנה את חשבון האחסון שלכם אך משמר כל שורת קוד מורשת סבוכה. אתם נושאים את כל החוב הטכנולוגי לסביבה חדשה ואינכם צוברים אף לא מהגמישות של הענן.
כתיבה מחדש ידנית: אתם שוכרים מפתחים שישכתבו הכול ב-Java ידנית. זה איטי להכאיב, יקר בסדרי גודל אסטרונומיים, ותלוי במציאת אנשים שמבינים גם COBOL וגם ארכיטקטורה מודרנית. עם מומחי ה-COBOL שלכם פורשים, זה נעשה קשה יותר מדי שנה.
כלי עטיפה של בינה מלאכותית: אתם מכוונים עוזר קידוד מסחרי מבוסס בינה מלאכותית אל מאגר הקוד שלכם. הוא מתרגם תחביר במהירות. אבל כפי שמראה כישלון הבנק, הוא מפספס תלויות בין-קובציות, מזייף הגדרות משתנים, ומייצר קוד שנראה נכון אך מתנהג שגוי.
וזה מה שבאמת עובד — גישה מבוססת גרפים שמתייחסת לקוד שלכם כאל מערכת מחוברת ולא כאל ערימה של קובצי טקסט:
ניתוח המבנה, ולא רק הטקסט. במקום לחתוך את הקוד שלכם לחתיכות טקסט שרירותיות, אתם מפרסרים כל קובץ לעץ שמייצג את המבנה הלוגי שלו — כל משתנה, כל פונקציה, כל ענף של זרימת בקרה. זה מבטיח שהבינה המלאכותית מכבדת את גבולות הקוד שלכם. פונקציה מטופלת כיחידת לוגיקה שלמה, ולא כפרוסה אקראית של טקסט.
בניית מפה של כל קשר גומלין. אתם מחלצים כל חיבור במאגר הקוד שלכם — אילו מודולים קוראים לאילו תת-שגרות, אילו קבצים מגדירים אילו משתנים, אילו פונקציות מעדכנות אילו טבלאות מסד נתונים — ומאחסנים אותם בגרף ידע. כשהבינה המלאכותית צריכה לתרגם פונקציית תשלום, היא לא פשוט תופסת טקסט שמזכיר "תשלום". היא עוקבת אחר שרשרת התלות בפועל כדי למשוך כל הגדרת משתנה, כל כותרת משותפת וכל השפעה במורד הזרם. זה מה ש-Veriprajna מכנה גרף ידע המודע למאגר הקוד, והוא פותר ישירות את בעיית ה-"Lost in the Middle".
אימות של כל פלט מול המפה. הבינה המלאכותית מייצרת קוד Java ואז מהדרת אותו בסנדבוקס. אם המהדר זורק שגיאה — למשל, משתנה חסר — המערכת שואלת את הגרף, מאתרת את התלות ומייצרת את הקוד מחדש. לולאת הידור-תיקון הזו רצה באופן אוטומטי. המפתחים שלכם סוקרים פלטים מאומתים, ולא ניחושים גולמיים של בינה מלאכותית.
היתרון החשוב ביותר עבור צוותי הציות והביקורת שלכם: כל החלטה שהבינה המלאכותית מקבלת ניתנת למעקב. גרף הידע מתעד בדיוק מדוע הבינה המלאכותית ייבאה ספרייה מסוימת או הגדירה משתנה בדרך מסוימת. במקום קופסה שחורה, אתם מקבלים שרשרת ציטוטים. המבקרים שלכם יכולים לראות את שובל הלוגיקה עבור כל שורת קוד שנוצרה.
הגישה הזו גם מחסלת בזבוז עוד לפני שההגירה מתחילה. גרף הידע מזהה קוד מת — פונקציות שאף דבר במערכת שלכם לא קורא להן בפועל. הסרת קוד מת מקטינה בדרך כלל את מאגר הקוד ב-20-30%, כלומר עלויות הגירה נמוכות יותר ומערכת סופית נקייה יותר.
עבור ארגונים בתחום השירותים הפיננסיים המתמודדים עם פיקוח רגולטורי, שקיפות מסוג זה אינה רשות. ואם המודרניזציה שלכם דורשת מעקב אחר שושלת נתונים בין מערכות, היכולות של Veriprajna בתחום מקוריות נתונים ויכולת מעקב מרחיבות את אותה גישה מבוססת גרפים אל צינור הנתונים כולו שלכם.
אתם יכולים לקרוא את הניתוח הטכני המלא לפרטים ההנדסיים, או לעיין בגרסה האינטראקטיבית לסיור חזותי באופן שבו גרף הידע פועל בפועל.
נקודות מפתח
- 70%-80% מפרויקטי מודרניזציית המורשת נכשלים — וכלי קידוד מבוססי בינה מלאכותית שקוראים טקסט בלבד מחמירים את הבעיה, ולא מקלים עליה.
- אפקט ה-"Lost in the Middle" גורם לבינה המלאכותית לפספס הגדרות משתנים קריטיות הקבורות עמוק במאגרי קוד גדולים, מה שמוביל לשחיתות נתונים שקטה.
- גרף ידע ממפה כל תלות במאגר הקוד שלכם כך שהבינה המלאכותית רואה קשרי גומלין, ולא רק טקסט — ומחסל את הנקודות העיוורות שריסקו את מסד הנתונים של הבנק.
- זיהוי קוד מת מקטין בדרך כלל 20%-30% ממאגר הקוד עוד לפני תחילת ההגירה, וחוסך זמן וכסף.
- כל החלטה של הבינה המלאכותית ניתנת למעקב דרך הגרף, ומעניקה לצוותי הביקורת והציות שלכם שובל לוגיקה מלא עבור כל שורת קוד שנוצרה.
שורה תחתונה
כלי קידוד סטנדרטיים מבוססי בינה מלאכותית מתרגמים תחביר אך מפספסים את התלויות הנסתרות שמפעילות את מערכות המורשת. גישה מבוססת גרפים ממפה כל קשר גומלין במאגר הקוד שלכם והופכת הימור מסוכן לתהליך הנדסי ניתן לאימות. שאלו את ספק הבינה המלאכותית שלכם: כשהמערכת שלו נתקלת במשתנה המוגדר בקובץ משותף אלפי שורות הרחק מהקוד שהיא מתרגמת, האם היא יכולה להציג בפניכם את שרשרת התלות המלאה ולהוכיח שקיבלה את סוג הנתונים נכון?