Reef TRH"זבל נכנס, זבל יוצא" הוא המשפט הכי מרגיע שאפשר להגיד על פרויקט AI שנכשל, כי הוא מצביע על בעיה שנדמה שאפשר פשוט לקרצף ולהעלים. ההיגיון אומר שאם רק ננקה את הדאטה, המודל יעבוד כמו שצריך. זה סיפור מנחם, אבל הוא בעיקר שגוי. להאמין בו זו הדרך הבטוחה לשרוף תקציב של רבעון שלם בלי לשים לב.
רוב הדאטה הארגוני אינו מלוכלך במובן הרגיל של המילה. הוא פשוט משקף את המציאות. הוא מתעד בנאמנות חמש עשרה שנים של פעילות עסקית אמיתית: הרכישה שהותירה שתי טבלאות לקוחות שמעולם לא התאימו זו לזו, קודי המוצר שמישהו הגדיר מחדש ב-2019, או השדה הספציפי שכל אחת משלוש מחלקות ממלאת אחרת כי היא פתרה בעיה שונה. שום דבר מזה הוא לא שגיאה שמחכה שינקו אותה. זה העסק עצמו, וזה בדיוק השטח המורכב שהמודל שלכם יצטרך לצלוח ברגע שהוא יוצא לפרודקשן.
למה הדמו שיקר לכם
אב-טיפוס קוצר מחמאות בסביבה סטרילית שהוכנה במיוחד עבורו. הדוגמאות נבחרות בקפידה כדי שיהיו מייצגות וחד-משמעיות, והרשומות הבעייתיות נדחקות הצידה, כי מטרת הדמו היא להוכיח היתכנות, לא לשרוד את המפגש עם המציאות. לעיתים קרובות הרבה יותר ממה שנהוג להודות, מה שנתפס בחדר הישיבות כאינטליגנציה של המודל הוא בסך הכל העבודה הסיזיפית של מי שסידר את הדאטה בלילה שלפני.
בפרודקשן אין מגירות כאלה. שם המודל מקבל הזנת נתונים חיה ממערכות שמעולם לא תוכננו לתקשר זו עם זו, ונדרש לדייק דווקא ברשומה הספציפית והמבולגנת שלפניו, ולא באיזה ממוצע נקי. המודל לא נהיה פחות טוב בין שלב הפיץ' לפיילוט, פשוט איכות הדאטה שלו צנחה. זהו המנגנון השקט שעומד מאחורי ארבעה מכל חמישה פיילוטים שלעולם לא מגיעים למשתמשים אמיתיים: הבעיה היא לא מודל חלש, אלא מודל מורעב בדאטה.
במילים אחרות, העבודה הקריטית באמת מתרחשת הרבה לפני שרוב הצוותים מצפים, ואין לה שום קשר לבחירת המודל.
ההחלטה שאתם חייבים לקבל לפני שכותבים שורת קוד אחת של המודל
עוד לפני שנכתבת שורת קוד אחת של אימון או אינטגרציה, אתם יכולים לדעת אם הפרויקט בכלל בר-ביצוע, פשוט על ידי בחינה של התשתית שמתחתיו. איפה באמת נמצא הדאטה שעליו נשענת היוזמה הזו, ומי האדם היחיד שמכיר כל מקור נתונים מספיק טוב כדי להסביר את המוזרויות שלו? עד כמה הוא מלא ומדויק דווקא בשדות שהמודל חייב להתבסס עליהם (לא ברמת המקרו, אלא רשומה אחר רשומה), ועד כמה הוא מעודכן ברגע שמישהו ניגש אליו? האם המערכת יכולה לגשת אליו בזמן אמת דרך ממשק ייעודי, או שהכל נשען בסתר על ייצוא ידני ועל מישהו שצריך לזכור להריץ אותו בכל יום שני?
ואז מגיעות השאלות שאין להן שום קשר לאיכות הדאטה, אלא רק לשאלה אם התוצרים של המודל בכלל ייכנסו לשימוש בפועל. האם הפלט משתלב בתהליך העבודה של עובד אמיתי, בדיוק ברגע שבו הוא צריך לקבל את ההחלטה שהפלט אמור להשפיע עליה? והאם המערכת יודעת להתמודד עם מקרי הקצה שמטופלים כיום ידנית? ברגע שנתונים אמיתיים נכנסים למשחק, לאילו מידע מותר למודל להיחשף, למי יש הרשאה לראות את הפלטים שלו, ואיזה תיעוד חייב להישמר כדי שתוכלו להצדיק החלטה מסוימת גם שנה לאחר מכן? אלה לא שיקולים שאפשר להדביק בדיעבד אחרי ההשקה. זהו חלק בלתי נפרד מתכנון המערכת עצמה.
אם תענו עליהן בכנות, לא תקבלו דאטה מושלם, פשוט כי לאף אחד אין דבר כזה. במקום זאת, תקבלו משהו שימושי בהרבה: מפה שמראה בדיוק איפה התשתית חלשה, כמה יעלה לחזק אותה, והאם בכלל כדאי להתחיל בפרויקט, כל עוד קבלת ההחלטות הזו עדיין לא עולה לכם ביוקר. זוהי המטרה של אבחון מוכנות. הוא לא נועד לנקות את הדאטה שלכם, אלא לשקף את מצבו האמיתי כדי לענות על השאלה שהדמו לעולם לא יוכל לענות עליה: לא אם הרעיון עובד בתיאוריה, אלא אם הוא מסוגל לשרוד במציאות של העסק שלכם.