מודלי ML למימון: ניקוד, אנטי-הונאה וניהול סיכונים

מודלי ML לפיננסים: היכן נשבר הניקוד והאנטי-הונאה

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

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

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

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

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

אפקט מדיד: מהירות החלטות ושיעור סירובים שגויים

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

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

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

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

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

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

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

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

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

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

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

1. ניתוח נתונים והגדרת המשימה. מבצעים פרופיילינג למקורות: בודקים מילוי שדות, אי-התאמות בין מערכות, השהיית הופעת נתונים ומאפיינים של דליפת משתנה המטרה. קובעים מה בדיוק אנו חוזים ובאיזה רגע זמן המידע הזה באמת זמין.
2. הכנת מאפיינים. אוספים מאגר נתונים לאימון, מתארים חישובים ומגרסאים אותם כך שאותם ערכים יתקבלו גם באימון וגם בעבודת המודל.
3. פתרון בסיס והשוואה. בונים מודל פשוט כקו מנחה: הוא מראה אם בכלל יש אות בנתונים, ומשמש כרף שמתחתיו אין טעם להסתבך.
4. בדיקה על מדגם בלתי תלוי. מעריכים איכות על תקופה מושהית, שאינה חופפת לתקופת האימון בזמן. כך רואים אם התוצאה מחזיקה על נתונים חדשים, ולא רק על דוגמאות מוכרות.
5. כיול ובחירת סף. מביאים את ההערכות להסתברויות אמיתיות ומתאימים את גבול ההפעלה למחיר שגיאות מהסוג הראשון והשני.
6. הטמעת המודל. מחברים את שירות ההערכה לתהליך של הלקוח ומפעילים במצב צל — המודל מחשב, האדם מקבל החלטה; גרסאות ופרמטרים מתועדים כך שהתוצאה תהיה ניתנת לשחזור.
7. מסירה לתפעול. מוסרים נהלי אימון מחדש, סטים של בדיקות, לוחות בקרה לסחיפת נתוני קלט ונוהל חזרה לגרסה קודמת.

מה נשאר אצל צוות הלקוח לאחר המסירה

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

מה נשאר בידיים:

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

מקרה בוחן: ניקוד ואנטי-הונאה בזרם בקשות אחד

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

מה שינו

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

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

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

מה לעשות אם בחברה כבר פועלים כללים ובדיקות ידניות

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

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

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

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

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

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

ספקות טכניים שכדאי להסיר לפני ההתחלה

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

איך להסביר את החלטת המודל לבודק או ללקוח?

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

המודל יעבור אימון יתר ויתפרק על נתונים חדשים?

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

איך לשלב את המודל בתהליך הנוכחי?

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

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

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

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

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

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