מודל TabFM מעביר את הסיכון מ-XGBoost אל ממשל הנתונים
הכותרת המתבקשת היא שמודל TabFM של גוגל מאתגר את XGBoost. בעיניי, זו הכותרת הפחות מעניינת. החידוש הארגוני הוא הורדת העלות של יצירת תחזית עד לרמה שבה אנליסט יכול להפעיל סיווג או רגרסיה מתוך BigQuery, בלי מחזור אימון מלא. דווקא הקיצור הזה מעביר את צוואר הבקבוק מהנדסת המודל אל ממשל הנתונים: מי רשאי לחזות, על אילו עמודות ובאילו תנאים מותר להכניס את הפלט לתהליך עסקי.
היתרון של TabFM נולד מהקשר, לא מאימון מחדש
מודל TabFM אינו מקבל טבלה כאילו הייתה משפט. סדר השורות והעמודות בטבלה אינו נושא משמעות קבועה, ולכן הארכיטקטורה מפעילה קשב מתחלף בין שני הצירים. כל שורה נדחסת לייצוג צפוף, ואז רצף הייצוגים משמש ללמידה מתוך ההקשר: הדוגמאות המתויגות ורשומות היעד נכנסות יחד, והתחזית נוצרת במעבר חישובי יחיד בלי לעדכן את משקלי המודל. כך נחסכים אימון מחדש וחלק מכיוונון ההיפר-פרמטרים, אך לא נחסכת הבדיקה אם ההקשר מייצג את המציאות העסקית.
גוגל אימנה את המודל על מאות מיליוני מערכי נתונים סינתטיים שנוצרו באמצעות מודלים סיבתיים מבניים. הבחירה פותרת מחסור בסיסי: טבלאות אמיתיות הן קנייניות ורגישות, ולכן אין להן קורפוס ציבורי מקביל לעולם הטקסט. האימון הסינתטי מלמד מגוון קשרים סטטיסטיים וסיבתיים אפשריים, אך הוא גם מהמר שהמבנים שנוצרו מכסים עונתיות, צנזורה, הטיית בחירה ושינויי משטר. מבחן TabArena מעודד, במיוחד בגרסת האנסמבל, אבל דירוג רוחבי אינו תחליף לבדיקת דומיין.
החיזוי בתוך BigQuery מקצר פיתוח ומרחיב את שטח הסיכון
נניח שצוות אשראי קמעונאי מחזיק טבלה עם 48 עמודות ורוצה לחזות פיגור של 90 יום. כיום הוא מאמן XGBoost רבעוני, בודק משתנים ומפרסם שירות חיזוי. באמצעות AI.PREDICT אפשר לכאורה להפעיל את TabFM ליד הנתונים ולחסוך שבועות. אלא שאחת העמודות, מספר ימי הקשר עם מחלקת הגבייה, מתעדכנת אחרי החלטת האשראי. המודל עשוי להציג דיוק גבוה מפני שקיבל רמז מן העתיד. הגישה ללא אימון מחדש לא מתקנת דליפת מידע, והיא אף מקלה לשכפל אותה לעשרות שאילתות לפני שאיש סיכון רואה את התהליך.
קיימת טענה הוגנת שלפיה XGBoost יישאר הבחירה העדיפה: הוא זול, בשל, נוח להסבר ומצטיין בטבלאות בינוניות. הטענה נכונה במערכות שבהן המודל כבר מכוונן והעלות התפעולית נשלטת. אולם TabFM אינו צריך לנצח בכל טבלה כדי להיות משמעותי. די בכך שהוא יוריד את סף ההקמה של מודל ניסויי משבועות לשאילתת SQL, כדי שמספר המודלים, השאילתות, בעלי הגישה והחלטות הנשענות עליהם יגדל מהר יותר מיכולת הבקרה.
מבחן נכון ל-TabFM מתחיל ביריב ובשערי בקרה
הצעד הנכון אינו החלפה רוחבית של XGBoost. כדאי לבחור שני מקרי שימוש ב-BigQuery, אחד לסיווג ואחד לרגרסיה, ולוודא שאחד מהם כולל אירוע נדיר. בכל מקרה יש להריץ את TabFM כמודל מתחרה בלבד. כל ניסוי צריך לכלול חלוקה כרונולוגית, בדיקת דליפת עמודות, כיול הסתברויות והשוואת עלות מול קו בסיס מכוונן. צוות משותף של מדעני נתונים, אנליסטים, בעלי תהליך ואנשי סיכון צריך לקבוע מראש ספי עצירה ונתיבי חריגה. אדם בלולאה נדרש באישור החריגים ובשינוי המדיניות, לא באישור כל תחזית. אם AI.PREDICT ייכנס לייצור, הרשאות SQL יהפכו בפועל להרשאות לבניית החלטות, ולכן קטלוג מאפיינים מאושרים ולוג תחזיות חייבים להגיע לפני ההפעלה הרחבה.
