AIאסטרטגיהפרודקשן

צ'קליסט מעבר מ-POC לפרודקשן: 12 שאלות לפני שנותנים אור ירוק לפיילוט AI

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

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

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

איך לקרוא את זה

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

האם הדאטה שורד את המפגש עם המציאות?

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

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

האם אפשר לסמוך על התשובות שלו גם ביום רע?

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

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

שימו לב כמה מעט מהשאלות האלו עוסקות במודל עצמו. וזו בדיוק כל הנקודה.

מי מטפל בזה ב-2 בלילה?

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

האם בכלל משתלם לבנות את זה?

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

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

ההשאלות שלקוחות באמת שואלים

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

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

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

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

תגיות AI
שיתוף
Reef TRH
ארכיטקטורת AI ופיתוח פרודקשן

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

צרו קשר

לא בטוחים אם הפיילוט שלכם מוכן לאור ירוק?

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