אינטגרציה למערכות Legacy: איך מחברים מודל שפה מתקדם למערכת בנקאית משנות ה-90 – המדריך המלא מאת אילון אוריאל
השאלה שמגיעה אליי לשולחן כמעט בכל שבוע שני ב-"NeuralBridge Solutions" היא תמיד וריאציה של אותו אתגר: "אילון, יש לנו מודל שפה מדהים, אבל הדאטה שלנו כלוא בתוך מפלצת ברזל משנות ה-90. מה עושים?".
התשובה הקצרה שלי, לפני שנצלול לעומק, היא זו: אנחנו לא מחברים את ה-LLM למערכת ה-Legacy. אנחנו בונים שכבת תיווך מודרנית שמדברת 'בנקאית' לצד אחד ו'AI' לצד השני.
אינטגרציה בין בינה מלאכותית גנרטיבית (GenAI) למערכות ליבה בנקאיות (Core Banking) היא כנראה האתגר ההנדסי המורכב ביותר כיום. לא מדובר רק בטכנולוגיה, אלא בגישור בין שתי פילוסופיות הפוכות: מערכות דטרמיניסטיות, קשיחות ומובנות (כמו Mainframe ו-AS/400) מול מערכות הסתברותיות, גמישות ויצירתיות (LLMs). במאמר הזה אני אקח אתכם יד ביד דרך הארכיטקטורה שאני מיישם אצל הלקוחות שלי. נפרק את הבעיה, נבנה את הפתרון, ונבין איך עושים את זה בלי להפיל את הבנק.
הדיסוננס הטכנולוגי: אילון אוריאל מסביר את הפער בין GPT ל-COBOL
כדי לפתור בעיה, צריך להבין את שורשיה. כשאני יושב עם מנהלי IT בבנקים, אני רואה את הפחד בעיניים שלהם. הם שומרים על מערכות שנכתבו ב-COBOL לפני שאני נולדתי. המערכות האלו יציבות, אמינות ומטפלות במיליוני טרנזקציות.
הפער הוא עצום:
מצד אחד, יש לנו מערכת Legacy שמדברת בפורמטים בינאריים, שדות באורך קבוע (Fixed Width), פרוטוקולים כמו SOAP או אפילו תקשורת ישירה מול DB2.
מצד שני, מודל ה-AI מצפה לקבל טקסט חופשי או JSON, עובד בצורה א-סינכרונית, ודורש זמן עיבוד (Latency) שלעיתים נחשב נצח במונחי בנקאות.
הפתרון שאני מוביל לא מנסה "לאנוס" את המודל לדבר COBOL, ולא מנסה לשדרג את ה-Mainframe ביום אחד. המפתח הוא יצירת שכבת בידוד. אנחנו בונים "מתורגמן" חכם שיודע לקחת את הכאוס של השפה הטבעית ולהמיר אותו לפעולות כירורגיות ומדויקות במערכת הישנה.
אילון אוריאל מציג: ארכיטקטורת "שכבת ההפשטה" (Abstraction Layer)
הטעות הכי גדולה שאני רואה בשוק היא ניסיון לחבר סוכני AI (Agents) ישירות למסדי הנתונים הישנים. זה מתכון לאסון, גם מבחינת אבטחה וגם מבחינת יציבות. הארכיטקטורה הנכונה בנויה בצורת "בצל", שכבה על גבי שכבה.
הנה המבנה שאני מיישם בפרויקטים:
שכבת ה-Core (המערכת הישנה):
זוהי ה"קופסה השחורה". Mainframe, AS/400, מערכות ERP ישנות. כאן נמצאת האמת הארגונית.
שכבת ה-API Gateway הפנימי:
שכבה קריטית שממירה את הלוגיקה הישנה ל-RESTful API מודרני. בדרך כלל נכתבת ב-Java או C#. התפקיד שלה הוא להיות השער היחיד למערכת הישנה.
שכבת ה-Orchestrator (המוח):
כאן יושב ה-LLM, אבל הוא לא לבד. הוא מנוהל על ידי Framework כמו LangChain או Semantic Kernel. השכבה הזו מנהלת את הזיכרון, את ההקשר (Context) ואת קבלת ההחלטות.
שכבת האבטחה וה-Sanitization:
מסננת קריטית שמוודאת שאף פרט מידע רגיש (PII) לא דולף למודל הציבורי, ושום פקודה זדונית מהמודל לא מגיעה לבנק.
אילון אוריאל צולל לעומק: שלב 1 – חשיפת המערכת הישנה לעולם החדש
הצעד הראשון הוא להפוך את המערכת הישנה לנגישה. מערכת בנקאית משנות ה-90 לא שמעה על JSON. היא מכירה EBCDIC, היא מכירה טבלאות DB2, והיא מכירה טרנזקציות CICS.
כשאני ניגש למשימה הזו, אני משתמש באחת משלוש אסטרטגיות, תלוי במצב המערכת:
אסטרטגיית ה-Wrapper (העטיפה):
אנחנו בונים מיקרו-שירותים (Microservices) שעוטפים פונקציות ספציפיות ב-Legacy. למשל, אם יש תהליך ב-Mainframe שבודק יתרה, אני אכתוב שירות קטן ב-Go או ב-Java שמפעיל את התהליך הזה וחושף אותו החוצה כ-Endpoint מסודר: GET /api/v1/balance.
אסטרטגיית CDC (Change Data Capture):
במקום לתשאל את המערכת הישנה כל הזמן ולהעמיס עליה, אנחנו מאזינים לשינויים ב-Database שלה. כלי כמו Kafka Connect או Debezium יכולים "לשבת" על ה-Logs של ה-DB2, וכל שינוי שקורה שם מוזרם בזמן אמת לדאטה-בייס מודרני (כמו PostgreSQL או MongoDB) שקל יותר לתשאל אותו. ה-AI מדבר עם העותק המודרני, לא עם המקור.
אסטרטגיית ה-RPA (בלית ברירה):
אם אין שום API ואין גישה ל-DB, אנחנו משתמשים ברובוטים שממש מדמים לחיצות על מסכים (Screen Scraping) וחושפים את זה כ-API. זה הפתרון הפחות מועדף עליי, אבל לפעמים הוא היחיד האפשרי.
הבנת השפה הבנקאית לפי אילון אוריאל: הפיכת נתונים לקונטקסט (RAG)
אחרי שפתחנו "צינור" למערכת, הבעיה הבאה היא שה-LLM לא מכיר את הלקוח הספציפי. הוא אומן על כל האינטרנט, אבל הוא לא יודע ש"משה כהן" במינוס של 5,000 ש"ח. כאן נכנסת טכניקת ה-RAG (Retrieval-Augmented Generation), אבל עם טוויסט בנקאי.
במערכות רגילות, אנחנו זורקים מסמכים ל-Vector Database. במערכת בנקאית, הנתונים הם טבלאיים ומובנים (Structured).
השיטה שלי משלבת בין השניים:
בניית פרופיל סמנטי:
אנחנו לוקחים את הנתונים היבשים (יתרה, הלוואות, היסטוריית פעולות) וממירים אותם לתיאור טקסטואלי שהמודל יכול להבין. במקום להזין לו טבלה גולמית, אנחנו מייצרים "סיפור לקוח" דינמי שמוזרק לפרומפט (Prompt) בזמן אמת.
שילוב SQL-Agent:
אני לא מסתפק רק בחיפוש וקטורי. אני בונה סוכן AI שיודע לכתוב שאילתות SQL (או שאילתות API) כדי למשוך נתונים מדויקים. המודל מקבל גישה ל"כלים" (Tools) מוגדרים מראש. הוא יודע שאם המשתמש שואל "כמה כסף הוצאתי על מסעדות?", הוא צריך להפעיל כלי ספציפי שמבצע אגרגציה לפי קטגוריה, ולא לנסות לנחש.
אילון אוריאל מזהיר: אבטחת מידע ו-PII הם לא המלצה
כשמחברים מודל כמו GPT-4 או Claude למערכת בנקאית, הסיוט של כל מנהל אבטחה הוא שמידע על לקוחות יזלוג החוצה לאימון המודל הציבורי. זו לא סתם פרנויה, זו מציאות שחייבים לנהל.
אני מיישם "חומת אש לתוכן" (Content Firewall) שפועלת בשני הכיוונים:
כיוון יוצא (Egress):
לפני שהפרומפט נשלח למודל, הוא עובר דרך מנגנון De-identification. כל שם, תעודת זהות, מספר חשבון או כתובת מוחלפים ב-Tokens גנריים (למשל <CUSTOMER_ID_1>). המודל מעבד את הלוגיקה על הטוקנים האלו בלי לדעת מי האדם האמיתי.
כיוון נכנס (Ingress):
כשהתשובה חוזרת מהמודל, המערכת שלי עושה Re-identification ומחזירה את הפרטים האמיתיים לפני שהתשובה מוצגת ללקוח או למערכת הבנקאית.
בנוסף, בבנקים גדולים, אני תמיד דוחף לשימוש במודלים מקומיים (Open Source כמו Llama 3) שרצים על שרתים פרטיים של הבנק (On-Premise) או בשימוש בגרסאות Enterprise של המודלים הגדולים, בהן מובטח חוזית שהמידע לא משמש לאימון.
אילון אוריאל על ביצוע פעולות (Actionable AI): ממילים למעשים
לקרוא מידע זה נחמד, אבל הערך האמיתי מגיע כשה-AI יכול לבצע פעולות: לבצע העברה, להזמין פנקס צ'קים, או לפרוס הלוואה. במערכות Legacy, טעות קטנה יכולה לשבור תהליכים שלמים.
כאן נכנסת גישת ה-Deterministic Guardrails (מעקות בטיחות דטרמיניסטיים).
אסור לתת למודל לבצע את הפעולה ישירות. המודל הוא רק "כוונת". התהליך הוא כזה:
זיהוי כוונה (Intent Recognition):
המודל מזהה שהמשתמש רוצה להעביר כסף.
חילוץ פרמטרים (Entity Extraction):
המודל מחלץ את הסכום, היעד והתאריך מתוך השיחה.
אימות (Validation Logic):
כאן הקוד המסורתי (Python/Java) נכנס לפעולה. אנחנו בודקים האם יש יתרה? האם היעד קיים? האם הסכום חוקי? המודל לא עושה את זה – הקוד עושה את זה.
אישור אנושי (Human-in-the-loop):
בפעולות רגישות, המודל מייצר "טיוטת פעולה" ומציג אותה למשתמש לאישור סופי: "הבנתי שאתה רוצה להעביר 500 ש"ח לאילון. האם לאשר?". רק לאחר אישור מפורש, נשלחת הפקודה ל-API של המערכת הישנה.
אתגר ה-Latency (שיהוי): הפתרונות של אילון אוריאל
מערכות Mainframe רגילות להגיב במילי-שניות. מודלים של שפה לוקחים שניות. זה פער שיכול להרוס חווית משתמש. משתמש לא יחכה 10 שניות כדי לראות את היתרה שלו.
כדי להתמודד עם זה, אני משתמש בטכניקות אופטימיזציה אגרסיביות:
Streaming (הזרמה):
אנחנו לא מחכים שהתשובה כולה תהיה מוכנה. אנחנו מזרימים את הטקסט למשתמש מילה אחר מילה ברגע שהיא נוצרת. זה נותן תחושה של מיידיות.
Caching חכם:
שאלות נפוצות לא צריכות להגיע ל-LLM כל פעם מחדש. מערכת Semantic Cache זוכרת שאלות דומות ("מה היתרה שלי?" ו-"כמה כסף יש לי?") ומחזירה תשובה מוכנה מראש (כמובן, לאחר שליפת הנתון העדכני מה-DB).
מודלים קטנים ומהירים:
לא צריך את המודל הכי חכם לכל משימה. למשימות ניתוב פשוטות, אני משתמש במודלים קטנים ומהירים הרבה יותר, ומשאיר את המודלים הכבדים והיקרים רק למשימות מורכבות שדורשות "היגיון".
אילון אוריאל מתמודד: שאלות ותשובות קשות מהשטח
במהלך העבודה שלי, אני נתקל בשאלות שחוזרות על עצמן מצד מנהלי טכנולוגיות ראשיים (CTOs). הנה התשובות הכנות שלי:
שאלה: האם ה-AI לא ימציא נתונים (הלוצינציות) על כספי לקוחות?
תשובה: זה הסיכון מספר אחת. לכן, ה-AI לעולם לא מחשב את היתרה ולעולם לא ממציא את הריבית. ה-AI משמש רק כאינטרפייס שפה טבעית. את המספרים הוא מקבל אך ורק מה-API של מערכת ה-Legacy ורק "מדביק" אותם במשפט. אנחנו מגדירים את ה-Temperature של המודל ל-0 (או קרוב לזה) כדי למנוע יצירתיות היכן שלא צריך.
שאלה: איך מתמודדים עם רגולציה בנקאית?
תשובה: כל אינטראקציה נרשמת (Logging) בצורה מלאה. אנחנו שומרים את הפרומפט המקורי, את התשובה של המודל, ואת ה-JSON המדויק שנשלח למערכת הישנה. זה מאפשר Audit Trail מלא שיספק כל מבקר בנקאי. הבינה המלאכותית היא שכבה נוספת, היא לא עוקפת את הבקרות הקיימות של הבנק.
שאלה: המערכת הישנה שלנו קורסת תחת עומס. ה-AI לא יחמיר את זה?
תשובה: להיפך. אם בונים את זה נכון, שכבת ה-Caching ושכבת ה-CDC (עותק הנתונים המודרני) מורידות כ-80% מהעומס של שאילתות קריאה (Read) מה-Mainframe. ה-AI מדבר עם העותק, ורק פעולות כתיבה (Write) מגיעות למערכת הישנה.
נקודות למחשבה מאת אילון אוריאל: הטרנספורמציה האמיתית
חשוב להבין משהו עקרוני: החיבור הזה הוא לא רק טכני. הוא משנה את הדרך שבה הבנק תופס את המידע שלו.
מעבר מפקודות לשיחה:
אנחנו מפסיקים ללמד את הלקוחות (ואת הפקידים) איך להשתמש במערכת ("תלחץ F5 ואז Enter"), ומתחילים ללמד את המערכת להבין את הלקוחות.
שבירת ה-Silos:
מערכת AI שיודעת לגשת למערכות שונות (עו"ש, משכנתאות, ניירות ערך) יוצרת לראשונה תמונה הוליסטית אמיתית. פתאום אפשר לשאול: "האם כדאי לי למכור את המניה כדי לכסות את המינוס?", שאלה שדורשת הצלבה של שתי מערכות שונות שמעולם לא דיברו ביניהן.
שימור ידע מוסדי:
רבים מהמתכנתים שבנו את מערכות ה-Legacy יוצאים לפנסיה. מודלים של AI יכולים לעזור לנו גם בתחזוקה – הם יכולים לקרוא קוד COBOL, להבין את הלוגיקה העסקית, ולתעד אותה עבור הדור הבא של המפתחים. זהו תוצר לוואי קריטי של תהליך האינטגרציה.
סיכום מקצועי עם אילון אוריאל
לחבר מערכת בינה מלאכותית מודרנית למערכת בנקאית משנות ה-90 זה כמו להתקין מנוע חשמלי של טסלה על כרכרה. זה אפשרי, זה עוצמתי, אבל זה דורש תכנון מדוקדק, מתאמים (Adapters) חזקים והבנה עמוקה של שני העולמות.
הסוד הוא לא לנסות לשנות את הליבה הבנקאית, אלא לעטוף אותה בשכבות הגנה חכמות. ה-API Gateway מספק את הגישה, ה-RAG מספק את ההקשר, מנגנוני ה-Guardrails מספקים את הביטחון, והמודל מספק את הקסם של השפה הטבעית.
כמי שחי את השטח הזה יום-יום, אני אומר לכם: אל תפחדו מהמורכבות. הכלים שיש לנו היום ב-2026 מאפשרים לעשות אינטגרציות שב-2023 נראו כמו מדע בדיוני. אבל, וזה אבל גדול – תתחילו בקטן. קחו תהליך אחד (למשל, "בירור סטטוס הלוואה"), תבנו לו את כל השרשרת מקצה לקצה, תוודאו יציבות, ורק אז תתרחבו.
העתיד של הבנקאות הוא לא בלהחליף את ה-Legacy מחר בבוקר, אלא בלבנות עליו גשר עצבי (Neural Bridge) חכם שיביא אותו למאה ה-21.
הצעד הבא עבורכם:
מפו את שלוש הפעולות הכי נפוצות ששירות הלקוחות שלכם מבצע מול המסכים השחורים. בדקו האם יש להן API קיים, או האם צריך לייצר להן מעטפת. זוהי נקודת ההתחלה שלכם לפרויקט ה-AI הבא. אם אתם צריכים עזרה במיפוי הארכיטקטוני הזה – אני כאן.