פיתוח מודל בינה מלאכותית מסוג טרנספורמר לנתונים פיננסיים

מודלים קלאסיים לחיזוי אינם קולטים תלויות ארוכות בסדרות פיננסיות ומאבדים דיוק בנקודות מפנה בשוק. אנו מפתחים טרנספורמר פיננסי מקצה לקצה: מאמנים, מכווננים ומוסרים את המודל יחד עם נהלי בקרת איכות. התחזית נעשית יציבה יותר, והצוות מקבל תוצאה שאפשר לבדוק ולשחזר.

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

איפה נשברת התחזית הסטנדרטית: מתי נדרש Transformer פיננסי

כשל קלאסי נראה כך: המודל מציג איכות תחזית יציבה על קטע שוק רגוע — שגיאה נמוכה, אות יציב, — ואחרי כמה ימים של שינוי משטר התחזיות שלו סוטות מהמציאות פי כמה.

השגיאה גדלה לא באופן חלק, אלא במדרגה: שינוי בתנודתיות, בנזילות או הופעה של סוג חדש של נתוני קלט שוברת את התלויות המוכרות, והמודל ממשיך לפעול לפי ההיגיון של המשטר הקודם.

הסיבה — בטבעם של הנתונים. סדרות פיננסיות אינן סטציונריות: משתנה לא רק פיזור הערכים, אלא גם הקשרים בין התכונות עצמן, וסחיפת התכונות מהירה יותר ממחזור החישוב מחדש.

בזמן שהצוות מכין מערך חדש ומאמן מחדש את המודל, החשיבות של חלק מהקלטים כבר השתנתה — ובדיקה על חתך היסטורי לא מראה זאת, כי היא בוצעה על אותו משטר שעליו אומן.

מודלים ליניאריים ובוסטינג על לאגים מפסידים כאן ראשונים: הם קובעים תלויות מקומיות ומתקשים להעביר אותן לשינוי משטר. Transformer פיננסי מחזיק הקשר ארוך ומשקלל אותות הטרוגניים — עסקאות, שערים, זרמי טקסט — באמצעות קשב, ולא באמצעות סט נוקשה של לאגים.

אבל הארכיטקטורה כשלעצמה לא מרפאת סחיפה: איכות התחזית נשענת על מעגל שמבחין בשינוי המשטר ומארגן מחדש את האימון בהתאם.

אנו מפרקים כיצד זה נסגר: ולידציה תלוית-משטר, בקרת סחיפת תכונות ואימון מחדש לפי אירוע, ולא לפי לוח שנה.

מה נותן Transformer פיננסי במשימות תחזית

מודלים קלאסיים על חלון מחליק רואים רק את הנקודות האחרונות של הסדרה — אירוע עם תגובה ממושכת בלתי נראה עבורם. מנגנון הקשב בארכיטקטורת Transformer משווה את כל ההיסטוריה הזמינה בבת אחת ומשקלל אילו מרווחי עבר באמת מסבירים את התנועה הנוכחית. תלויות ארוכות בזמן הופכות לתכונה, ולא לרעש.

עמידות לשינוי משטר נשענת על אימון משלים, ולא על הרכבה מחדש של מערך תכונות. כאשר התנודתיות והנזילות מתנהגות אחרת מאשר בקטע האימון, עדכון על חלון טרי מספיק כדי שהאיכות תחזור לרמת העבודה — אלו שעות עבודה של מהנדס במקום שבועות.

מהירות האימון מחדש — תוצאה ישירה: נתונים חדשים מוטמעים בצעדים קטנים, לכן חישוב מחדש עבור שוק שהשתנה אורך שעות, ולא חודשים, ואינו דורש תיוג מחדש של ההיסטוריה.

נתונים מולטימודאליים נאספים למעגל אחד: סדרות מספריות, טקסטים של גילויים ולוח אירועים נכנסים למרחב תכונות משותף. אות שאינו מאושר על ידי מקור שני מדוכא — שיעור האותות הכוזבים מצטמצם, ולא גדל יחד עם מספר הקלטים.

אנו בודקים זאת על חלוקה הוגנת לפי זמן: אימון על העבר, הערכה על העתיד, ללא דליפת נתונים. אנו מסתכלים על שיעור ההתראות הכוזבות בקטע המוחזק, על פיזור המדד בעת הזזת חלון האימון ועל הזמן עד להשבת האיכות לאחר שינוי משטר.

מצבי אימון והסקה: השוואת גישות

בחירת המצב אינה תלויה באיכות על מדגם הדגמה, אלא בנפח ובתיוג הנתונים, בדרישות לזמן השהיית התגובה ובפרשנות ההחלטה.

סדרות פיננסיות קצרות, לא סטציונריות, עם אירועים נדירים ויקרים — לכן אימון משלים של מודל מאומן מראש ואנסמבל עם עצים נותנים פרופיל שגיאות שונה, ואין אפשרות "טובה" ללא הקשר.

להלן ארבע אפשרויות, שביניהן באמת בוחרים בהתחלה. המגבלות מצוינות אלו שמתגלות בנתונים חיים: התאמת יתר על חלון קצר, אובדן פרשנות, גידול בזמן ההסקה יחד עם מספר המודלים באנסמבל.

אפשרות מתי מתאימה מגבלות
אימון מאפס היסטוריה ארוכה, דפוסים יציבים, יש משאב לתיוג נדרשים נפח נתונים גדול וזמן; על מדגמים קצרים לא יציב, אירועים נדירים נכשלים
אימון משלים של מודל מאומן מראש יש מודל בסיס על נתונים קרובים בטבעם, נדרש מעבר מהיר לאיכות עבודה רגיש לסחיפת התפלגות; נדרש בקרת התאמת יתר על מדגם קטן וחזרה לגרסת הבסיס
אנסמבל עם עצי החלטה תכונות מעורבות וטבלאיות, חשובה פרשנות התרומה של התכונות חלש יותר על רצפים וטקסט; הסקה איטית יותר, יותר מודלים לתחזוקה
מודלים סטטיסטיים קלאסיים נדרש בסיס שקוף ורמת חישוב מחדש מהיר על סדרות קצרות אינם קולטים קשרים לא ליניאריים, מהר מגיעים לתקרת האיכות

מצב נבחר לפי מדד על תקופה מוחזקת, ולא לפי איכות על האימון, ומקבעים מראש כלל חזרה לאחור. אימון משלים ואנסמבל אינם סותרים זה את זה: עצים לוקחים תכונות טבלאיות, Transformer פיננסי — רצף, והשוואת הגישות נעשית על אותה מערכת בדיקות.

שלבי יישום: מביקורת נתונים ועד מסירת המודל

על סדרות פיננסיות מחיר הטעות בסדר השלבים גבוה יותר מאשר ברוב משימות למידת מכונה: מודל שאומן על נתונים מעורבבים מציג מדד יפה על ולידציה ומתפרק על זרם חי. לכן Transformer פיננסי נבנה בקפדנות לפי שלבים, כאשר כל שלב נשען על תוצאה של הקודם.

  1. ביקורת נתונים היסטוריים. אנו בודקים את עומק ההיסטוריה, ערכים חסרים, הפסקות במסחר, פעולות תאגידיות ושינויי תקנון. אם המכשיר נסחר לאורך כל התקופה, זה מתועד בתיוג, ולא נמחק בממוצע.

  2. סכמת תכונות. אנו מגדירים אילו שדות נכנסים לקלט, עם אילו לאגים וחלונות צבירה. כל תכונה נבדקת לזמינות ברגע קבלת ההחלטה — אחרת היא מביאה למודל את העתיד.

  3. הגדרת אימון. החלוקה היא כרונולוגית strictly, ללא ערבוב אקראי. אנו מתאימים את אורך ההקשר והרגולריזציה לחוסר האיזון האמיתי של האירועים.

  4. ולידציה של המודל על תקופה מוחזקת. את הקטע האחרון של ההיסטוריה אנו שומרים ללא נגיעה עד הסוף, ובנוסף מריצים חלון מחליק — כך רואים אם האיכות מתדרדרת עם הזמן.

  5. בקרת דליפות נתונים. מזיזים תכונות, מסירים חשודות, משווים את המדד לפני ואחרי. ירידה חדה — סימן בטוח שהמודל נשען על רמז מהעתיד.

  6. מסירה וניטור. אנו מוסרים משקלים, תצורה, סקריפטים לחישוב ומערכת מדדים שלפיהם עוקבים אחר סחיפה. לאחר מכן המודל חי לפי תקנון האימון מחדש.

ארטפקטים של הפרויקט: תצורות, סכמות ותקנונים

לאחר מסירת הפרויקט נשארים אצל הלקוח לא רק מודל מאומן, אלא גם ארטפקטים שלפיהם ניתן לשחזר, לבדוק ולאמן מחדש את המודל ללא מעורבות המחברים. בלעדיהם Transformer פיננסי הופך לקופסה שחורה: התחזיות זורמות, אבל אין מי שיסביר או יתקן אותן. את ההרכב מקבעים בהתחלה ומוסרים לפי פרוטוקול.

  • תצורת אימון — פרמטרים של הארכיטקטורה, גודל ההטמעות, מספר השכבות וראשי הקשב, לוח זמנים של קצב הלמידה, בחירת תכונות, מחוללי מספרים אקראיים מקובעים.
  • סכמת הכנת נתונים — קו ייצור מפליטות גלם ועד טנסורים: כללים לטיפול בערכים חסרים ובחריגים, אי-סינכרוניות של דיווח, נרמול, חיתוך חלונות, הגנה מפני דליפת ערכים עתידיים.
  • תקנון אימון מחדש — טריגרים (סחיפת התפלגויות קלט, ירידת מדדים בתקופה מוחזקת), תדירות, סדר קבלה של גרסה חדשה לפני החלפת הגרסה הפעילה.
  • תיאור מדדי איכות — איכות דירוג, דיוק וכיסוי לפי מחלקות, כיול הסתברויות, השוואה למודל בסיס על אותה תקופה.
  • תיעוד המודל — מפת תכונות, ייעוד בלוקים, גבולות ישימות ומגבלות ידועות: על אילו מצבי שוק המודל לא נבדק.
  • מרשם גרסאות והוראות לצוות — איזו בנייה נמצאת כעת בעבודה, במה היא שונה מהקודמת, כיצד לחזור לאחור וכיצד להקים סביבה מאפס.

מקרה בוחן: תחזית נזילות לפני ואחרי היישום

תחזית הנזילות במקרה בוחן זה נבנתה על זרמים תוך-יומיים: יתרות בחשבונות, תשלומים נכנסים ויוצאים, עונתיות של סגירת תקופות ותשלומי מסים. המודל הקודם נשען על חלון היסטוריה קצר ותכונות שנאספו ידנית על ידי אנליסטים, ולכן בעת שינוי משטר שוק ובימי שיא של תשלומים הדיוק ירד באופן מורגש.

מה היה לפני היישום

שיעור האותות השגויים עמד על כ-18%: המערכת הפיקה גלי שווא של צורך בנזילות ובמקביל פספסה כאלה אמיתיים. אנליסטים תיקנו ידנית בממוצע 40 תחזיות בשבוע, ואימון מחדש על נתונים חדשים ארך כמעט שבועיים — עד לרגע העדכון המשטר עצמו כבר השתנה, והשגיאות חזרו.

מה שינו ומה יצא

עברנו ל-Transformer פיננסי עם קשב על מספר אופקים, המיושם ב-PyTorch: המודל רואה גם זרמים דקותיים וגם הקשר שבועי, ולא חלון ממוצע. את האימון המשלים העמדנו על זרם — עדכון על נתונים טריים אורך שעות במקום שבועות, עם בדיקה על תקופות מוחזקות לפי עקרון החלון המחליק.

בנפרד סגרנו את הסיכון להתאמת יתר על נתונים חדשים: לבדיקה הוספנו ימים חריגים — שיאי תשלומים וקרעים בנזילות — והמודל נבחר לפי עמידותו בהם, ולא לפי שגיאה ממוצעת.

כסיכום: שיעור האותות השגויים ירד ל-6%, מספר התיקונים הידניים של אנליסטים — ל-7 בשבוע, וגלי השווא, שבגללם החזיקו קודם מלאי עודף, כמעט נעלמו.

מה לעשות אם כבר פרוס מעגל חיזוי קלאסי

מעגל חיזוי קלאסי לעתים רחוקות ניתן לכבות סתם כך: על הפלט שלו תלויים דוחות תקנוניים, מגבלות והחלטות שכבר אושרו. לכן מודל חדש על Transformer שמים לצד, ולא במקום — המערכת הפעילה נשארת מקור האמת, עד שהחדשה מוכיחה איכות על נתונים אמיתיים, ולא על חתכים היסטוריים.

אינטגרציה עם המערכת הקיימת מצטמצמת לנקודת חיבור אחת: מתאם אוסף תכונות מאותם מקורות ונותן לשתי המודלים קלט זהה, ואת התחזיות מביא לסכמה משותפת עם אופקים ותוויות של סדרות. החוזה עבור ויטרינות נתונים ושירותי החלטות לא משתנה.

לאחר מכן מופעל חישוב מקביל במצב צל: שתי המודלים מחושבים על אותו חתך נתונים, וכל תחזית נשמרת עם תווית מקור, זמן חישוב ומערך תכונות. זה נותן השוואה נכונה של תחזיות — שגיאה לפי כל אופק, התנהגות על חריגים וקרעים בסדרה, שיעור האותות שהמודל החדש פספס או מצא כמיותרים.

מעבר הדרגתי מתבצע לפי סגמנטים, ולא על כל התיק בבת אחת: תחילה קטגוריות עם רגישות נמוכה, שבהן שגיאה אינה גוררת השלכות תקנוניות. חזרה לאחור נשענת על כך שהמעגל הקלאסי לא פורק וממשיך לכתוב את התחזיות שלו — מתג מחזיר את החישוב אליו בתוך מחזור אחד, ללא שחזור נתונים מהארכיון.

בדיוק משום כך מעבר כזה מפסיק להיות סיכון לחישובים השוטפים: המודל החדש תחילה מוכיח עמידות על ההיסטוריה שלכם, ורק אחר כך לוקח על עצמו חלק מהעומס. תארו כיצד בנוי מעגל החיזוי שלכם היום, — נחזור עם הערכה ותוכנית להפעלה מדורגת.

מגבלות המודל ובקרת איכות התחזית

ארכיטקטורת Transformer מחזיקה תלויות ארוכות בסדרה, אך אינה מסירה את המגבלות העיקריות של המודל. סדרה פיננסית אינה סטציונרית: שינוי משטר תנודתיות שובר תחזית שנראתה יציבה בהיסטוריה.

ערכים חסרים — סופי שבוע, עצירות מסחר, עיכובים בפרסומים — איננו ממלאים בממוצע: המודל מקבל מסכת היעדרות ומבדיל בין אפס אמיתי לבין ערך חסר. חריגים מדוכאים על ידי פונקציית אובדן עמידה.

התאמת יתר נתפסת לא על ידי חלוקה אקראית, אלא על ידי בדיקת חלון מחליק: אימון רק על העבר, בדיקה — על הקטע הבא. בקרת התחזית מתבצעת לפי אופקים — שגיאה ליום ולחודש נבדלות פי כמה, ומדד ממוצע אחד מסתיר זאת.

מה לעשות בעת שינוי משטר שוק?

המודל אינו אוניברסאלי: בעת שינוי משטר האיכות יורדת. לכן במעגל נכללים אימון משלים על חלון טרי ואנסמבל של גרסאות מתקופות שונות — כישלון של גרסה אחת אינו עובר לתחזית הסופית.

כיצד המודל מבדיל בין ערך חסר לאפס?

באמצעות מסכת היעדרות ומאפייני לוח שנה. תשואה אפסית והיעדר מסחר — אותות שונים; אם לערבב, המודל ילמד קשר כוזב.

כיצד מתגלה התאמת יתר?

לפי פער השגיאה בקטע האימון והקטע המוחזק ולפי מספר האפוקים ללא שיפור. עצירה מוקדמת ורגולריזציה — חלק מהתצורה הבסיסית, ולא אמצעי חירום לאחר כישלון.

מה עם הניטור לאחר המסירה?

אנו מוסרים לוח מחוונים: מדדים לפי אופקים, שיעור ערכים חסרים, סחיפת התפלגויות קלט, התראות לפי ספים ותקנון אימון משלים עם חזרה לגרסה הקודמת של המודל.

נדון במשימה: נחזור עם הערכה ותוכנית עבודה

כדי שהערכת הפרויקט תישען על עובדות, ולא על הנחות, לפני ההתחלה אנו זקוקים למינימום של נתוני מקור. להלן — מה כדאי לתאר או לשלוח: זה מספיק כדי לחזור עם תוכנית עבודה, ולא עם מילים כלליות.

  • הצהרת בעיה: איזה אות או תחזית נדרשים, על איזה אופק, מה אנו מחשיבים כשגיאה מסוג ראשון ושני.
  • נתונים: מקורות של שערים, עסקאות, דיווחים וטקסטים, עומק היסטוריה, תדירות הגעה, ערכים חסרים ואירועים תאגידיים.
  • משתנה מטרה: כיצד נוצרת התשובה הנכונה, מי ולפי איזה כלל מתייג אותה.
  • תנאי הפעלה של המודל: מצב אצווה או זרם, זמן תגובה מותר, דרישות לשחזור ולביקורת חישובים.
  • תשתית והרשאות: היכן מאוחסנים הנתונים, אילו מדיניות של הפרדת זכויות, האם מותר להוציא מחוץ לפרימטר.
  • קריטריוני קבלה: מדדי איכות, סכמת בדיקה על תקופות מוחזקות, סף שמתחתיו ההחלטה יוצאת לעבודה.

בתגובה אתם מקבלים הערכת פרויקט עם פירוט לפי שלבים, תוכנית עבודה עם תלויות ולוחות זמנים, הרכב הצוות ורשימת סיכונים. בבלוק נפרד — מה אנו עושים עם איכות הנתונים: היכן מנקים, במה משלימים, היכן חסרים נתונים באופן אובייקטיבי וזה משנה את מבנה המודל.

הצעד הבא — תארו את המשימה בצורה חופשית: מטרה, נתונים, מגבלות. נדון בה עם מהנדסים, נשאל שאלות הבהרה ונחזור עם הערכה ותוכנית עבודה.