Bagging בביטוח: דיוק גבוה יותר בזיהוי הונאות וסיכון

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

כאן נכנס רעיון פשוט אבל חזק: Bagging (Bootstrap + Aggregating). לא עוד “מודל חדש”, אלא דרך לבנות מערכת יציבה יותר ממודלים קיימים על ידי שינוי הנתונים שנכנסים לאימון וחיבור חכם של תחזיות. וזה מתחבר ישירות לסדרה שלנו, “בינה מלאכותית בתעשייה וייצור מתקדם”: כמו שבמפעל חכם מפחיתים רעש באמצעות חיישנים מרובים וסינון, כך גם בניהול סיכונים מבטחים מפחיתים “רעש חיזויי” בעזרת אנסמבל.

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

למה “ממוצע תחזיות” בדרך כלל לא עובד בביטוח

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

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

במילים אחרות:

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

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

Bagging בשורה אחת: משנים את הדאטה, לא את המודל

התשובה הישירה: Bagging מאמן את אותו מודל שוב ושוב על גרסאות “מעט שונות” של הדאטה (Bootstrap), ואז מאחד את התחזיות (Aggregating).

Bootstrap: דגימה עם החזרה שמייצרת “עולמות מקבילים” של נתונים

ב-Bootstrap לוקחים סט אימון בגודל N ומייצרים ממנו סט חדש בגודל N על ידי דגימה עם החזרה:

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

זה נשמע טריוויאלי, אבל בביטוח זה קריטי כי:

• יש זנבות כבדים (תביעות ענק נדירות)
• יש קבוצות קטנות (סגמנטים/אזורים/מוצרים עם מעט תצפיות)
• יש רעש תפעולי (שינויים במדיניות טיפול, סגירת תיקים, קידודים)

Bootstrap “מנער” את הדאטה בצורה מבוקרת ומאפשר לראות: האם המודל שלי רגיש מדי לשינוי קטן בדאטה?

Aggregating: האיחוד שמייצב

אחרי שמאמנים K מודלים (למשל 50 או 200), מאחדים תחזיות:

• ברגרסיה: ממוצע תחזיות
• בסיווג: ממוצע הסתברויות או הצבעה

האפקט החשוב בביטוח: ירידה ב-variance (תנודתיות). פחות “קפיצות” בהחלטות, פחות תלות באירועי קצה שהשתרבבו למדגם.

איפה Bagging נותן ערך מיידי בביטוח (ולא רק תיאוריה)

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

1) זיהוי הונאות: פחות אזעקות שווא, יותר עקביות

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

Bagging (ובעיקר וריאציות כמו Random Forest) עוזר כי:

• עץ החלטה יחיד יכול “להיתפס” על דפוס מקרי בדאטה
• אנסמבל של עצים על Bootstrap מפחית את התלות במקרה
• התוצאה: דירוג סיכוני הונאה יציב יותר לאורך זמן

דוגמה פרקטית ליישום:

• מגדירים סף חקירה לפי Top 1% מהתביעות החשודות
• עם מודל יחיד, ה-Top 1% משתנה בצורה חדה בין חודשים
• עם Bagging, הדירוג מתייצב, והצוות מרגיש שהמערכת “הוגנת” וניתנת להסבר

2) חיתום ותמחור: יציבות בסגמנטים קטנים

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

Bagging מסייע כי הוא:

• מצמצם “התאהבות” של מודל בחריגים
• משפר הכללה בסגמנטים דלי נתונים
• מאפשר להפיק טווחי אי-ודאות (עוד רגע נגיע לזה)

3) ניהול תביעות: אומדן אי-ודאות שמייצר SLA חכם

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

Bagging מאפשר לקחת K תחזיות לכל תביעה, ולחשב פיזור (למשל סטיית תקן). התוצאה העסקית:

• תביעות עם אי-ודאות גבוהה → ניתוב למומחה/שמאי בכיר
• תביעות עם אי-ודאות נמוכה → טיפול אוטומטי/מסלול מהיר

זה בדיוק המקום שבו AI הופך לכלי ניהולי, לא רק “מודל”.

Bagging באקסל: למה זה חשוב גם למי שבסוף עובד בענן

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

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

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

אם רוצים סימולציה פשוטה בסגנון אקסל (גם אם בפועל תיישמו בפייתון/SQL):

1. מוסיפים עמודת מזהה לכל שורה
2. מייצרים K עותקי דאטה על ידי דגימה עם החזרה (ביצוע בחירה אקראית של מזהים)
3. מאמנים מודל בסיס בכל עותק
4. מאחדים תחזיות ומחשבים גם פיזור

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

עצים מול רגרסיה: איפה Bagging באמת “מזיז מחט”

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

למה Bagging פחות מרשים ברגרסיה ליניארית

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

אבל יש לזה שימוש אחד מעולה בביטוח: רצועות אי-ודאות.

• לכל נקודת קלט (למשל גיל נהג/סכום כיסוי/ותק) יש K תחזיות
• מחשבים סטיית תקן/אחוזונים
• מקבלים אינדיקציה: איפה המודל יציב ואיפה הוא “מנחש”

למה Bagging עובד מצוין עם עצים

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

• הקפיצות החדות של עץ בודד “מתרככות”
• התחזית הופכת חלקה ויציבה יותר
• מקבלים מודל שמכליל טוב יותר

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

Random Forest: Bagging + אקראיות במאפיינים (ומה זה אומר לביטוח)

התשובה הישירה: Random Forest הוא הרחבה של Bagging שמוסיפה עוד מקור אקראיות: בכל פיצול בעץ שוקלים רק תת-קבוצה של מאפיינים.

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

• מספר תביעות בעבר, סכום תביעות, זמן מאז תביעה
• מאפייני רכב/נכס שמתקשרים ביניהם
• משתנים תפעוליים שמספרים את אותו סיפור מזוויות שונות

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

שאלות שבאמת שווה לשאול לפני שמטמיעים Bagging בארגון

התשובה הישירה: Bagging הוא לא תחליף למשילות נתונים ולמדידה נכונה; הוא מכפיל כוח כשעושים את הבסיס נכון.

1. מה המדד העסקי שאתם ממטבים?
   • בהונאות: Precision ב-Top X%, עלות חקירה, Recall על תיקים “יקרים”.
   • בתביעות: סטייה ממוצעת, שיעור חריגים, זמן טיפול.
2. האם יש דרישה להסבריות רגולטורית/פנימית?
   • אנסמבל אפשר להסביר, אבל צריך להשקיע בהסבר פיצ’רים, רגישויות, ואי-ודאות.
3. איך תמדדו יציבות לאורך זמן (Model Drift)?
   • Bagging מפחית variance, אבל לא פותר שינויי עולם (רגולציה, מחירים, דפוסי הונאה).
4. האם יש לכם מסלול פעולה לאי-ודאות גבוהה?
   • אם אתם מחשבים אי-ודאות ולא משתמשים בה לתיעדוף — פספסתם את הערך.

הצעד הבא: להפוך Bagging לנכס תפעולי, לא רק שורת קוד

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

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

אם אתם שוקלים להרים פיילוט קצר, הנה ניסוי שאני אוהב: בחרו תהליך אחד (למשל דירוג חשד להונאה), בנו מודל עץ בודד מול Bagging/Random Forest, ומדדו חודש מול חודש את יציבות הרשימה של “הכי חשודים”. השאלה שמעניינת אותי בסוף היא לא רק “מי ניצח ב-AUC”, אלא: האם הצוות העסקי מרגיש שהמערכת צפויה מספיק כדי לעבוד איתה יום-יום?