אתם נמצאים בעמדה מצוינת למצוא הזדמנויות בעלות ערך גבוה לשימוש ב-AI. אתם יכולים להעריך גם את ההיתכנות הטכנית של רעיון וגם את ההשפעה שלו על חוויית המשתמש – שתי נקודות מבט שחייבות להתאחד כדי שתכונות מבוססות-AI יצליחו. אל תפתחו תכונות מבוססות-AI רק כי הן חדשניות או מרשימות, אלא כי הן באמת הופכות את החיים של המשתמשים לקלים, מהירים או מהנים יותר.
ביחידה הזו מתוארת שיטה מובנית ואיטרטיבית להגות, להגדיר וליצור אב טיפוס של תרחישי שימוש ב-AI במוצר שלכם.
הסבר על הערך של AI
עץ ההזדמנויות הבא מגדיר את הקטגוריות העיקריות של הערך ש-AI יכול לספק:
ריכזנו כאן קטגוריות של ערכים שיעזרו לכם להגדיר את הפתרונות שלכם. ככל שמתקדמים ברשימה, המורכבות, הסיכון וההשפעה הפוטנציאלית על המשתמשים נוטים לגדול:
- תובנות: קבלת החלטות מושכלות יותר.
- נוחות: הסרת מכשולים.
- אוטומציה: החלפת עבודה שחוזרת על עצמה.
- Augmentation: עזרה למשתמשים במשימות מורכבות או יצירתיות.
- התאמה אישית: התאמת המוצר לצרכים ולהעדפות של המשתמש.
קודם כול, נסו לפתור תרחישים לדוגמה עם השפעה נמוכה יותר. לדוגמה, אתם יכולים לאסוף תובנות טובות יותר על המוצרים באמצעות מערכת AI פנימית, כדי לשפר את המוצר מבפנים. אחרי זה, בודקים את חוב חוויית המשתמש הקיים ומשתמשים ב-AI כדי להפחית את החיכוך ואת העומס הקוגניטיבי על המשתמשים. ככל שתצברו ביטחון וניסיון, תוכלו להתקדם לתרחישי שימוש מורכבים יותר ולהגביר את החשיפה ל-AI.
עם זאת, יכול להיות שתגלו הזדמנויות בעלות השפעה רבה, כמו נגיעות קלות של התאמה אישית, שהן נגישות באופן מפתיע, בסיכון נמוך ומשמעותיות.
זיהוי הזדמנויות במוצר
כדי לבחור את הרעיון הנכון, אתם צריכים להבין היטב מי המשתמשים שלכם. כדי להגדיר מי המשתמשים האלה, כדאי לעבוד עם צוות חוויית המשתמש או לרענן את הידע בנושא פרסונות. התמקדו במשתמשים, ונסו למצוא הזדמנויות לשלב AI בתרחישי שימוש קונקרטיים במוצר שלכם.
הם יכולים להיות:
- הם מונעים על ידי צרכים או בעיות מפורשים של המשתמשים.
- הצעות שאתם או חברי הצוות שלכם הצעתם. במקרה כזה, חשוב לבצע אימות מהיר עם המשתמשים כדי להימנע מהמלכודת של "AI לשם AI".
- לקבל השראה מהמתחרים, אבל בזהירות. הקהל וההקשר של המתחרים שלכם יכולים להיות שונים משלכם. כדאי לבדוק בשלב מוקדם אם יוזמות מוצלחות של המתחרים יכולות להתאים גם למוצר שלכם.
לדוגמה, בטבלה הבאה יש רעיונות לאתר להזמנת טיסות:
בכל שלב בתהליך שעובר המשתמש, אתם יכולים לזהות הזדמנויות שונות להוסיף ערך באמצעות AI.
עיצוב הפתרון
בשלב הזה, כבר מיפיתם כמה רעיונות ל-AI לאורך התהליך שעובר המשתמש. השלב הבא הוא לתת להם צורה ולצבור מספיק ביטחון כדי שתוכלו להחליט אילו מהם לפתח קודם. זהו מאמץ משותף של הצוות, ובדרך כלל מנהל המוצר מוביל אותו. בתור מפתחים, האחריות העיקרית שלכם היא להעריך את העלות, המאמץ והסיכונים של פתרון ה-AI המתוכנן.
הגדרת הרעיונות שלכם
קודם כל, תתעדו כל רעיון במפרט מהיר ומקיף. אתם יכולים להשתמש בתוכנית המערכת של ה-AI מהמבוא שלנו. בדרך כלל, המפתחים מתמקדים בחלק של הפתרון, ומנהל המוצר מציין את ההזדמנות. התרגיל הזה נותן לכולם בסיס משותף לתיאום ציפיות ולדיון לפני שמתקדמים.
הערכת המאמץ והעלות
בשלב הבא, צריך להעריך עד כמה קשה ליישם את הרעיון. לדוגמה, כדי להוסיף מסננים חכמים, יכול להיות שתצטרכו רק ניתוח מבוסס-הנחיות באמצעות API של LLM, שמאפשר ליצור אב טיפוס ולהריץ אותו במהירות, וקל יותר להתאים אותו. לעומת זאת, עוזר אישי להזמנות צריך צינורות נתונים בהתאמה אישית, ממשקי API להזמנות ומנגנונים קפדניים של האדם שבתהליך, וזה הרבה יותר מורכב.
כדאי לבחון את המאמץ והעלות בכמה מישורים:
- מוכנות הנתונים: האם כבר יש לכם את הנתונים שאתם צריכים? כמה ניקוי, עיבוד מראש או תיוג צריך לעשות כדי להכין את הנתונים ל-AI?
- בשלות המודל: האם כבר קיים מודל מתאים שעבר אימון מראש, או שצריך לאמן מודל מאפס?
- זמן אחזור: כמה מהר המודל צריך להגיב כדי שהתכונה תהיה חלקה ומועילה?
- מורכבות השילוב: כמה מערכות צריך לחבר? האם יש ממשק לקצה העורפי, ממשקי API, ממשק משתמש או כלים של צד שלישי? ככל שיש יותר נקודות מגע עם הלקוח, כך העלות והסיכון גבוהים יותר.
- עלות תפעולית: מה העלות של כל קריאה למודל או הסקת מסקנות? הערכת השימוש החודשי והתקציב להרחבה. תכונה ש"זולה" בשלב אב הטיפוס יכולה להיות יקרה ברגע שאלפי משתמשים מתחילים להשתמש בה.
חשוב להביא בחשבון את העלויות הנסתרות למשתמש. ה-AI עלול להכניס אי-ודאות וטעויות קבועות למוצר. ב-AI בצד הלקוח, התכונות פועלות במכשיר של המשתמש, וזה צורך רוחב פס, נפח אחסון ואנרגיה. התכונה צריכה להיות מספיק חשובה כדי שהמשתמשים ירגישו בנוח עם העלות.
אם תעריכו את המאמץ בשלב מוקדם, תוכלו להתמקד בהצלחות בעלות ערך גבוה וחיכוך נמוך, ולדחות את הרעיונות המורכבים יותר עד שהנתונים, התשתית והניסיון שלכם יבשילו.
הערכת מצבי כשל
לפעמים המודל טועה והתכונות לא פועלות כמו שצריך. אתם צריכים להסביר למשתמשים מה קורה ואיפה אירע הכשל, כדי שהם ידעו אם הם יכולים לשנות את הקלט שלהם כדי לקבל את התוצאות שהם מחפשים.
לדוגמה, נניח שאתם מנהלים סוכנות נסיעות. החברה שלכם רוצה להציע השראה מותאמת אישית למטיילים. המשתמשים ביקשו כלי שיאפשר להם לעשות את זה בעצמם, וצוות המוצר שלכם דוחף להטמיע אותו. עם זאת, אתם יודעים שהתאמה אישית דורשת הרבה אותות מהמשתמשים לגבי תחומי העניין שלהם, ולא הגדרתם מסד נתונים שאוסף אותות כאלה. זה מוביל להתאמה אישית לא מוצלחת שמציעה השראה לא רלוונטית, וכתוצאה מכך המשתמשים נוטשים את התכונה. ההבנה שלכם לגבי הזמינות של נתונים מותאמים אישית הייתה אמורה להשפיע על הערכת השווי של הצוות.
הנה עוד מצבי כשל קריטיים של AI שכדאי להביא בחשבון:
- הזיה: המודל יוצר פלט שנראה סביר, אבל הוא לא אמיתי (למשל, המצאת טיסה שלא קיימת).
- הטיה: המודל מציג או מגביר הכללות לא הוגנות על סמך נתוני האימון, מה שמוביל לתוצאות מפלות או לא שוויוניות. לדוגמה, המודל עשוי להניח שמשתמשים מסוימים רוצים טיסות במחלקה ראשונה ואחרים רוצים טיסות במחלקת תיירים, על סמך המגדר או הגזע המשוערים שלהם.
- בעיית ההתחלה הקרה: המערכת לא יכולה לספק ערך למשתמשים חדשים או לפריטים חדשים בגלל מחסור בנתונים ראשוניים, כמו בדוגמה של כלי הנסיעות בהתאמה אישית.
- ירידה בביצועים: הדיוק של המודל יורד עם הזמן, ככל שהנתונים בעולם האמיתי משתנים ומתרחקים מההתפלגות המקורית. התופעה הזו נקראת גם "סטיית מודל".
אב טיפוס
הנתונים שתזינו לגבי עלות, מאמץ ומצבי כשל יהיו ברמת דיוק נמוכה בהתחלה. כדי לצבור ביטחון, הדרך הכי טובה לאמת תכונת AI ספציפית היא ליצור אב טיפוס שלה. יצירת אב טיפוס מאפשרת לבדוק במהירות הנחות טכניות בסיסיות (מוכנות הנתונים, זמן אחזור, דיוק) לפני שמתחייבים לפיתוח מלא. במיוחד כשמדובר בטכנולוגיה חדשה שלא נחקרה במלואה כמו AI, לומדים מהר יותר כשמפתחים מאשר כשחוקרים ומנתחים.
בעזרת כלים ליצירת קוד שמבוססים על AI, כמו Vertex AI ו-Replit, אתם יכולים להאיץ באופן משמעותי את תהליך יצירת אב הטיפוס ולהפחית את הסיכונים.
אמצו את הגישה הזו: השיקו משהו קטן, תראו איך הוא מתפקד ושפרו אותו כל הזמן.
כדאי לפעול לפי השיטות המומלצות הבאות:
- בניית תהליך מקצה לקצה בשלב מוקדם. חשוב לבדוק את כל התהליך כפי שהוא מוגדר בתוכנית של מערכת ה-AI (נתונים, תובנות מניתוח הנתונים, חוויית המשתמש), ולא רק את הדיוק של המודל. הגרסה הזו צריכה לשקף כל חלק בחוויית המשתמש עם ה-AI, אבל היא לא חייבת לייצג כל תכונה באפליקציה.
- מתחילים עם קיצורי דרך. להשתמש בממשקי API ובמודלים שעברו אימון מראש כדי לאמת ערך במהירות.
- רישום ביומן של כל הפעולות. עוקבים אחרי קלט, פלט ועריכות של משתמשים כדי לראות מצבי כשל נפוצים ולהעריך בעיות פוטנציאליות.
- בדיקה עם נתונים אמיתיים. בבדיקות המוקדמות צריך לתעד התנהגות טבעית ולא מסודרת של המשתמשים.
- הוספת מנגנוני משוב ובקרה. חשוב לאפשר למשתמשים לדווח בקלות על שגיאות או לשנות את הפלט, ולאשר או לתקן את התוצאות.
ברוב המקרים, יצירת אב טיפוס מתרחשת במקביל להערכה ולעבודה על המפרט.
התובנות שלכם
למדתם איך להפוך את הפוטנציאל המופשט של ה-AI לרעיונות קונקרטיים למוצרים בעלי ערך גבוה. היתרון שלכם כמפתחים הוא היכולת לחבר בין היתכנות טכנית לבין חוויית המשתמש. בדקתם איך AI יכול ליצור ערך בקטגוריות שונות, מיפיתם את ההזדמנויות האלה לתהליך שעובר המשתמש במוצר שלכם, ולמדתם איך להגדיר, להעריך ולתעדף אותן באמצעות מסגרות מובנות.
חשוב לזכור שה-AI מצליח בזכות חזרתיות בלתי פוסקת. תשיקו מוקדם, תקשיבו למשתמשים ותצפו בהם, ותשפרו מהר. כל אב טיפוס הוא שלב בדרך להבנה איך AI יכול להגדיל את הערך של המוצר ולשפר את חוויית השימוש בו.
משאבים
- Getting AI Discovery Right, מדריך להעלאת רעיונות, לאימות ולתעדוף של תרחישי השימוש ב-AI.
- AI Radar, כלי לגילוי ולתמיכה בקבלת החלטות, שמאפשר לזהות תרחישי שימוש ולתעדף אותם בתעשיות שונות.
בדיקה של רמת ההבנה שלך
איזו קטגוריה של הזדמנויות בתחום ה-AI כוללת סיוע למשתמשים במשימות מורכבות או יצירתיות?
כשמעריכים את המאמץ והעלות של רעיון ל-AI, למה מתייחס המונח "מורכבות השילוב"?
מהי בעיית ההתחלה הקרה בהקשר של מצבי כשל ב-AI?
מהי הגישה המומלצת ליצירת אב טיפוס של תכונות מבוססות-AI?
למה חשוב לנהל יומן כשיוצרים אב טיפוס?