Reef TRHבכל רבעון חוזרת על עצמה סצנה מוכרת בארגונים בכל מקום. צוות מדגים אב-טיפוס AI שנראה כאילו הוא עובד בקסם. ההנהלה מתרשמת, התקציב מאושר, והציפיות מרקיעות. חצי שנה אחר כך אותו פיילוט מונח בשקט על המדף, עוד מצבה בבית קברות שהולך וגדל של אבות-טיפוס שמעולם לא הגיעו למשתמש אמיתי אחד.
הנתון כבר ידוע, והוא אכזרי: בערך 80% מפיילוטי ה-AI בארגונים לא מגיעים אף פעם לפרודקשן. האמת הלא נוחה היא שהכישלון כמעט אף פעם לא קשור למודל. הוא קשור לגמרי לפער שבין הדגמה שנבנתה בארגז חול לבין המציאות המבולגנת של איך שעסק באמת מתנהל.
אב-טיפוס מוכיח שהרעיון אפשרי. הוא לא מוכיח שאפשר להעלות אותו לפרודקשן. אלה שתי בעיות הנדסיות שונות לגמרי, ורוב הצוותים מתקצבים רק את הראשונה.
שלושה קירות שכל פיילוט נתקל בהם בדרך לפרודקשן
כשהדגמה מבטיחה נתקעת, היא כמעט תמיד מתנגשת באותם שלושה מכשולים. אף אחד מהם לא מופיע בסביבה מבוקרת, ובדיוק בגלל זה ההדגמה נראתה כל כך טוב.
- איכות הדאטה מתפרקת בקנה מידה גדול. בהדגמה הדאטה נקי, מסודר ונבחר ביד. בפרודקשן, דאטה ארגוני אמיתי מפוזר בין מערכות CRM מקוטעות, מערכות ERP מיושנות וגיליונות אלקטרוניים מבודדים. זבל שנכנס מייצר פלט לא אמין, ואף מודל, מתוחכם ככל שיהיה, לא מתקן תשתית דאטה שבורה.
- מקרי קצה שוברים הכל. משתמשים אמיתיים בודקים את גבולות המערכת בדרכים שהדגמה מתוסרטת לא צופה. הם שואלים את השאלה שאף אחד לא תכנן, מדביקים קלט משובש, דוחפים את התהליך לפינה. שם מערכות AI מתחילות להזות, בודות נהלים שלא קיימים, או קורסות לגמרי.
- האינטגרציה קשה יותר מה-AI. לחבר מודל למערכות legacy פירושו להתמודד עם מגבלות קצב של API, אימות ופרוטוקולי אבטחת מידע. בפועל, הצנרת הזאת צורכת לא פעם יותר מאמץ הנדסי מאשר בניית המודל עצמו מלכתחילה.
ארבעה מהלכים שמעבירים AI את הקו
לצאת מבית הקברות זה פחות עניין של מודל טוב יותר ויותר עניין של גישה טובה יותר. ארבעה עקרונות מפרידים בין הפיילוטים שמגיעים לאוויר לבין אלה שנתקעים.
1. תעדפו את התהליך לפני הטכנולוגיה
התחילו מהבעיה העסקית ומהתהליך האנושי המדויק שאתם מנסים לשפר, לא מהמודל שאתם רוצים להשתמש בו. בחירת הטכנולוגיה צריכה להיות ההחלטה האחרונה, נגזרת מהבנה צלולה של המקום שבו יושב החיכוך האמיתי.
2. בדקו קודם את ארכיטקטורת הדאטה
לפני שכותבים שורת קוד אחת של מודל, מפו איפה הדאטה שלכם באמת יושב, כמה הוא נקי, ואיך הוא זורם. הבדיקה הזאת לא זוהרת, והיא הדבר האחד עם ההשפעה הגדולה ביותר שאתם יכולים לעשות כדי להוריד סיכון מהפרויקט.
3. הגדירו מעקות למה שה-AI לא יכול לעשות
תכננו במפורש עבור מקרי הקצה ששוברים הדגמות. הגדירו מראש לוגיקת גיבוי, מגבלות קשיחות ומצבי כשל בטוחים. מעקות הם לא פיצ'ר שמלבישים בסוף. הם ההבדל בין מערכת שאתם יכולים לסמוך עליה מול לקוחות לבין כזו שאי אפשר.
4. קנו כשאפשר
לא כל רכיב צריך להיבנות מאפס. איפה שכלי מדף בשל פותר את הבעיה, השתמשו בו, ושמרו את ההנדסה המותאמת אישית לחלקים שהם באמת ייחודיים לעסק שלכם.
התזה שבבסיס פשוטה אבל קל לפספס אותה: הטמעת AI מוצלחת היא בעיה של ניהול מוצר, לא רק בעיה הנדסית. היא דורשת מישהו שיכול לשבת עם ההנהלה ולהחליט מה שווה לבנות, ואז ללכת לבנות את זה ולהעלות לפרודקשן, בלי לאבד כלום בתרגום בין השניים.
המסירה הזאת, בין האנשים שמבינים את העסק לבין האנשים שיודעים להעלות את הקוד לאוויר, היא המקום שבו רוב ה-AI מת. הסירו את המסירה, ותשאירו את בית הקברות מאחור.