1. לפני שמתחילים
ב-codelab הזה תיישמו שיטות מומלצות מהמהדורה החדשה של People + AI Research (PAIR) Guidebook (מדריך מחקר בנושא אנשים ו-AI) כדי לעצב מוצר חדש עם AI, תוך התמקדות בשיטות מומלצות לשימוש בנתונים שמתמקדות באנשים ובכיול נכון של אמון המשתמשים.
דרישות מוקדמות
- הבנה בסיסית של מהי AI.
- ידע בתהליך העבודה של פיתוח מוצרים.
מה תלמדו
ב-codelab הזה תלמדו איך להשתמש במדריך לאנשים + AI של Google Research כדי ליצור מוצרי AI אמינים שמתמקדים במשתמשים.
באופן ספציפי, אתם יכולים:
- מה חדש במהדורה השנייה של המדריך של PAIR
- תעברו סדרה של תרגילים שמדגישים הזדמנויות בתהליך פיתוח ה-AI לכיול אמון המשתמשים, עם דגש על נתונים ועל הסברים שמוצגים למשתמשים.
- היכרות עם ערכת כלים רחבה יותר של חומרים ומשאבים שזמינים ללימוד נוסף.
הדרישות
- דפדפן
- חשבון Google כדי לצפות במחברת Colaboratory (לדוגמה, ניתוח סנטימנט באמצעות BERT)
2. שנתחיל?
השנה אנחנו משיקים ב-Google I/O את המהדורה השנייה של PAIR Guidebook. המהדורה הראשונה פורסמה לפני שנתיים, ומאז יותר מרבע מיליון אנשים בתפקידים שונים (מפתחים, מעצבים, מנהלי מוצר, סטודנטים וכו') בכל העולם משתמשים בה. אנחנו שמחים להציג עכשיו סדרה של עדכונים שיעזרו לכם להפיק ממנו עוד יותר תובנות מעשיות.
במהדורה השנייה הזו, אנחנו מציגים דרך חדשה לנווט במדריך ולמצוא תוכן לפי משימה. ריכזנו רשימה של שאלות מרכזיות שאולי יעלו לך ולצוות שלך במהלך פיתוח מוצר עם גישה מבוססת-AI שמתמקדת במשתמשים. השאלות האלה יעזרו לך למצוא את התוכן שאתה צריך, כשאתה צריך אותו:
- מתי ואיך כדאי להשתמש ב-AI במוצר שלי?
- איך יוצרים מערך נתונים בצורה אחראית?
- איך אפשר לעזור למשתמשים לבנות אמון במערכת ה-AI שלי ולכייל אותו?
- איך מצטרפים לתכונות חדשות מבוססות-AI?
- איך מסבירים למשתמשים על מערכת ה-AI?
- מהו האיזון הנכון בין שליטת המשתמשים לאוטומציה?
- איך אוכל לתמוך במשתמשים אם משהו משתבש?
אחרי שתבחרו שאלה, תקבלו תוכן רלוונטי ביחידות קטנות יותר שקל יותר לפעול לפיהן.
בנוסף, עדכנו את המדריך של PAIR והוספנו לו תוכן חדש:
- קבוצה של תבניות עיצוב מבוססות-AI
- מקרים לדוגמה
- פרקים שעודכנו
- תרגילים חדשים וערכת סדנה
ב-codelab הזה תוכלו לראות כמה מהדפוסי העיצוב האלה בפעולה בתהליך עבודה, בזמן שאתם מפתחים תכונה חדשה באמצעות AI.
קדימה, מתחילים!
3. תרגום צרכים של משתמש לבעיה ב-AI
דמיינו את התרחיש הבא:
אתם מפתחים אפליקציה לצפייה בסרטים, ואתם רוצים לספק למשתמשים חוויה משופרת ומותאמת אישית שתעזור להם למצוא עוד סרטים שהם ייהנו מהם.
דף הנחיתה של האפליקציה כולל כרגע את הקטעים הבאים:
- רשימה של סרטים חדשים, מסודרים לפי תאריך היציאה לאקרנים
- קטלוג של כל הסרטים, מסודרים לפי ז'אנר
- תיבת חיפוש שבה המשתמשים יכולים לחפש לפי שם הסרט, צוות השחקנים וכו'.
אפליקציית סרטים ללא המלצות בהתאמה אישית
אתם רוצים להוסיף קטע חדש עם המלצות לסרטים למשתמש, ואתם חושבים ש-AI יכול להיות אפשרות טובה להטמעת התכונה הזו. לפני שמתחילים בהטמעה, חשוב לבצע את הפעולות הבאות:
- בדיקת תהליכי העבודה הקיימים: איך המשתמשים מבצעים כרגע אינטראקציה עם האפליקציה, ואיך לדעתכם אפשר לשפר את חוויית השימוש שלהם?
- בודקים אם AI יכול להוסיף ערך ייחודי: האם הבעיה שלכם היא כזו שאפשר לפתור אותה באמצעות AI, והאם סביר להניח ש-AI ישפר את חוויית המשתמש במוצר שלכם?
בעזרת הפרק User Needs + Defining Success (צרכים של משתמשים + הגדרת הצלחה) בספר ההדרכה של PAIR, אתם בודקים את רשימת תרחישי השימוש שבהם AI הוא כנראה פתרון טוב, ומגלים שהצורך של המשתמשים שלכם נכלל בסוגי הבעיות הבאים:
- המלצה על תוכן שונה למשתמשים שונים
- התאמה אישית משפרת את חוויית המשתמש
- הצגת תוכן דינמי יעילה יותר מממשק צפוי
חשוב גם לעיין ברשימת המקרים שבהם סביר להניח ש-AI לא יהיה פתרון טוב יותר.
עכשיו, אחרי שראיתם שפתרון מבוסס-AI נראה כמו מועמד טוב למענה על הצורך הזה של המשתמשים, כדאי להעריך אם הוא באמת ישפר את חוויית המשתמש.
דוגמת עיצוב:
לפני שמתחילים לפתח באמצעות AI, חשוב לוודא שהמוצר או התכונה שרוצים לפתח דורשים AI, או שאפשר לשפר אותם באמצעות AI.
טכנולוגיית ה-AI מתאימה לאפליקציות כמו:
- המלצה על תוכן שונה למשתמשים שונים, כמו הצעות לסרטים
- חיזוי אירועים עתידיים, כמו אירועי מזג אוויר או שינויים במחירי טיסות
- הבנת שפה טבעית
- זיהוי תמונות
פתרון שמבוסס על כלל או על היוריסטיקה יכול להיות עדיף במקרים הבאים:
- חשוב לשמור על יכולת חיזוי
- משתמשים, לקוחות או מפתחים צריכים שקיפות מלאה
- אנשים לא רוצים שאוטומציה תופעל על משימה
מידע נוסף על מקרים שבהם כדאי להשתמש ב-AI (או לא) מופיע בפרק בנושא צורכי המשתמש.
קישור לדפוס המלא: https://pair.withgoogle.com/guidebook/patterns#determine-if-ai-adds-value
אתם יכולים להוסיף ערך לאפליקציה על ידי הצגת סרטים לכל משתמש בנפרד, סרטים שהוא צפוי ליהנות מהם במיוחד. כך אתם מספקים חוויית משתמש עשירה יותר מאשר הצגת הסרטים החדשים ביותר או הסרטים שקיבלו את הדירוג הכי גבוה. בנוסף, אתם חושבים שהתכונה הזו תעזור להם לחסוך זמן בחיפוש בספרייה של סרטים שגדלה במהירות.
אחרי שהחלטתם להשתמש בפתרון מבוסס-AI, אתם יכולים להתחיל לתכנן את הצעדים הבאים.
4. יצירת קבוצת נתונים למשימה
כדי לאמן מערכת המלצות שתספק למשתמשים הצעות לסרטים, תצטרכו ליצור מערך נתונים שמודל ה-AI ילמד ממנו.
הדבר הראשון שצריך לעשות הוא להתאים בין צורכי המשתמשים לבין צורכי הנתונים.
בעזרת תרגיל ההתאמה מתוך הפרק איסוף נתונים + הערכה במדריך PAIR, תוכלו לקבוע את הפרטים הבאים:
- משתמש: צופים בסרטים (משתמשים באפליקציית סרטים)
- הצורך של המשתמש: למצוא בקלות ובמהירות עוד סרטים שהוא אוהב
- פעולת משתמש: בחירה וצפייה בסרטים דרך האפליקציה
- פלט של מערכת AI: אילו סרטים להציע ולמה (תוויות או תגים של סנטימנט)
- למידת מערכת ה-AI: דפוסי התנהגות שקשורים לקבלת המלצות לסרטים, צפייה בסרטים מלאים, כתיבת ביקורות על סרטים ומתן דירוגים גבוהים לסרטים האלה
- מערכי הנתונים הנדרשים: נתוני צפייה בסרטים מהאפליקציה, מידע על סרטים וסיווגים וביקורות של סרטים
- תכונות מרכזיות שנדרשות במערך הנתונים: העדפות של צופים לגבי סרטים והיסטוריית הצפייה שלהם, מידע על סרטים (למשל, ז'אנר, צוות שחקנים), דירוגים של סרטים וביקורות על סרטים
- תוויות מרכזיות שנדרשות במערך הנתונים: שיעור הקבלה או הדחייה של הצעות לאפליקציות על ידי הצופים, שיעור השלמת הצפייה בסרט על ידי הצופים, דירוגים וביקורות של הצופים ומשוב מהצופים לגבי הסיבה לדחיית ההצעה
עכשיו, אחרי שסיימתם את התרגיל הזה, אתם יכולים לראות כמה מקורות נתונים פוטנציאליים:
- נתוני משתמשים מהאפליקציה (העדפות ספציפיות והיסטוריית צפייה)
- מידע על הסרט מהאפליקציה (שם, שנה, משך, שחקנים וכו')
- ביקורות על סרטים ומידע על סיווגים ממקורות אחרים, כמו IMDB ו-MovieLens
אחרי שמגבשים מושג לגבי סוג הנתונים שיידרשו, כדאי לעיין בעקרונות ה-AI של Google ובשיטות לפיתוח אחראי של AI. אלה דוגמאות למסגרות שיעזרו לכם להתמודד עם שיקולים חשובים, כמו פרטיות (למשל, "לספק הזדמנויות למתן הודעה והסכמה") והוגנות (למשל, "לבצע בדיקות חוזרות ונשנות על ידי משתמשים כדי לשלב את הצרכים של מגוון משתמשים במחזורי הפיתוח").
לבסוף, כשמכינים את מערך הנתונים לאימון, חשוב לאסוף נתונים ריאליים שמשקפים את הנתונים ה'רועשים' שקיימים בעולם. לדוגמה, חשוב לכלול ביקורות על סרטים עם שגיאות כתיב, קיצורים, אמוג'י ותווים לא רגילים או לא צפויים, כי סביר להניח שמשתמשי האפליקציה יפרסמו בעתיד ביקורות דומות שהן אמיתיות ו'רועשות', ולא ביקורות עם פורמט מושלם.
דוגמת עיצוב:
במהלך פיתוח מערך נתוני האימון, אל תנסו ליצור משהו מושלם. במקום זאת, כדאי לאפשר קצת 'רעשי רקע' כדי שהנתונים יהיו דומים ככל האפשר לנתונים מהעולם האמיתי שאתם מצפים לקבל מהמשתמשים. כך תוכלו למנוע שגיאות והמלצות באיכות נמוכה אחרי שתשיקו את המודל בעולם האמיתי.
כדי לעשות את זה, כדאי לחשוב על סוגי הנתונים שאתם מצפים לקבל מהמשתמשים, ואז לוודא שהנתונים האלה מיוצגים בקבוצת הנתונים לאימון.
לדוגמה, במערכת לזיהוי תמונות, כדאי לחשוב על הנתונים שאפשר לקבל מהמשתמשים. אם סביר להניח שלא יהיה להם זמן לצלם תמונות באיכות גבוהה והמודל שלכם יצטרך לעבוד עם תמונות מטושטשות מטלפון חכם, כדאי לכלול תמונות מטושטשות בנתוני האימון.
קישור לדוגמה המלאה: https://pair.withgoogle.com/guidebook/patterns#embrace-noisy-data
אחרי שמיפיתם את צורכי המשתמשים לבעיית AI ולצרכים של מערך הנתונים, אתם מוכנים לאמן את ה-AI לספק המלצות ולתייג סרטים למשתמשים באפליקציה שלכם. אנחנו לא נסביר על החלק הזה של התהליך ב-Codelab הזה, אבל תוכלו לקרוא מידע נוסף על מערכות המלצה וניתוח סנטימנטים במקורות המידע הבאים:
- קורס ללימוד עצמי בנושא מערכות המלצה באתר Google Developers
- המדריך Text Classification for Sentiment Analysis with BERT באתר TensorFlow.org
5. הסבר על היכולות והמגבלות של המערכת
כשמעצבים את חוויית המשתמש באפליקציה, כדאי לתכנן איך להציג למשתמשים את התכונה החדשה מבוססת ה-AI ולעזור להם להבין מה אפשר לצפות ממנה. המשתמשים לא צריכים לבטוח במערכת ה-AI שלכם באופן מוחלט בכל הנסיבות, אלא להתאים את רמת האמון שלהם בצורה נכונה.
הגדרת ציפיות אצל המשתמשים היא תהליך מחושב שמתחיל עוד לפני האינטראקציה הראשונה שלהם עם המוצר שלכם. מומלץ לספק הסברים לאורך כל הדרך, גם מחוץ לחוויית השימוש במוצר, במגוון דרכים:
- הסבר בזמן אמת. במקרים המתאימים, כדאי לספק סיבות למסקנה, להמלצה, להצעה וכו'
- להוסיף הסברים במוצר. אפשר להשתמש בהזדמנויות אחרות במוצר, כמו תהליך ההצטרפות, כדי להסביר על מערכות AI.
- חוויית השימוש במוצר היא רק חלק מהסיפור. יכול להיות שהמידע במוצר לא יספיק, אבל אפשר להשתמש במגוון משאבים נוספים כדי לתמוך בו, כמו קמפיינים שיווקיים להגברת המודעות, וחומרי הדרכה וקמפיינים להגברת הידע כדי לפתח מודלים מנטליים.
לדוגמה: משתמש התחבר לאפליקציה ובחר סרט מומלץ מתוך הרשימה החדשה שנוספה לדף הנחיתה שלו. בנוסף למידע הרגיל על הסרט שאפשר למצוא שם, כדאי לכלול הסבר למה הסרט הספציפי הזה מופיע ברשימת ההמלצות.
בעזרת האפשרות 'חיפוש לפי שאלה' במדריך PAIR, בוחרים באפשרות 'איך מסבירים למשתמשים על מערכת ה-AI שלי?' ומוצאים את התבנית הבאה: הסבר שמטרתו להבהיר ולא להציג תמונה מלאה.
דוגמת עיצוב:
כשמסבירים המלצות ממערכת ה-AI, חשוב להתמקד בשיתוף המידע שהמשתמשים צריכים כדי לקבל החלטות ולהתקדם. אל תנסו להסביר כל מה שקורה במערכת.
לרוב, ההיגיון שמאחורי תחזית מסוימת לא ידוע או מורכב מדי מכדי לסכם אותו בביטוי או במשפט פשוטים. בנוסף, יכול להיות שהמשתמשים לא ירצו להיות מוצפים או מוסחים על ידי הסברים מיותרים בזמן השימוש במוצר שלכם.
ב פרק ההסבר והאמינות מוצגות דוגמאות לגישות שונות ליצירת הסברים תמציתיים וידידותיים למשתמש, כולל הסברים חלקיים, חשיפה הדרגתית ותצוגות של רמת הביטחון של המודל.
אם רוצים לשתף הסברים ארוכים או מפורטים יותר על אופן הפעולה של המערכת הכוללת, צריך לעשות זאת מחוץ לתהליך הפעיל של המשתמש, למשל בחומרי שיווק או בתוכן להצטרפות.
קישור לדוגמה המלאה: https://pair.withgoogle.com/guidebook/patterns#explain-for-understanding
בהתאם לשיטות המומלצות המתוארות בתבנית הזו, אתם מחליטים להציג הסבר שנראה כך:
המלצה לצפייה בסרט, כולל נימוק להמלצה
בדוגמה הזו להסבר, אנחנו מיישמים את ההנחיות של PAIR Guidebook בנושא Explainability + Trust ומשתמשים במקורות נתונים כדי לספק למשתמש הסבר עם שלוש ביקורות המשתמשים שקיבלו הכי הרבה הצבעות.
בנוסף, סימנת מילים ספציפיות שתרמו הכי הרבה לרגשות החיוביים כלפי הסרט הזה, וזה חשוב למשתמשים בבחירת סרט. בהדגמה הזו של כלי PAIR להסבר על שפה (LIT) אפשר לקבל מידע נוסף על ניתוח סיווג סנטימנט.
צילום מסך של הכלי לפרשנות של למידה (LIT)
בעזרת LIT אפשר לבדוק את ההתנהגות של מודלים לעיבוד שפה טבעית (NLP) באמצעות כלי חזותי, אינטראקטיבי וניתן להרחבה, שמאפשר לבדוק השערות ולאמת אותן על מערך נתונים עם מדדים רלוונטיים והסברים מקומיים (למשל, מפות של בולטות וייצוגים חזותיים של תחזיות). צוותי מוצר יכולים להשתמש ב-LIT בתרחישים הבאים לדוגמה:
- לפני שמפעילים מודל
- בדיקת הוגנות
- כדי לנפות באגים בחיזויים ספציפיים
- כשמשווים מודל חדש למודל ישן
6. איך להציג את רמת הביטחון
דרך נוספת להגדיר ציפיות למשתמשים היא להציג את רמת הביטחון של המודל בהמלצות. במקום להסביר למה או איך ה-AI הגיע להחלטה מסוימת, התצוגה של רמת הביטחון של המודל מראה עד כמה ה-AI בטוח בתחזית שלו, ואת החלופות שהוא שקל. מכיוון שרוב המודלים יכולים להפיק סיווגים של n-best וציוני מהימנות, הסברים על מהימנות המודל זמינים בדרך כלל בקלות.
לפני שמוסיפים את רמת הביטחון לדפי הסרטים המומלצים שמוצגים למשתמש, כדאי לקבוע אם רמת הביטחון הזו מועילה למשתמש, ואם כן, מהי הדרך הטובה ביותר להציג אותה.
דוגמת עיצוב:
במקרים מסוימים, אפשר לעזור למשתמשים להעריך את רמת האמון שצריך לתת לפלט של ה-AI באמצעות תצוגות של רמת הביטחון של המודל שמסבירות עד כמה ה-AI בטוח בחיזוי שלו, ואת החלופות שנשקלו.
עם זאת, בהקשרים אחרים, יכול להיות שיהיה למשתמשים קשה להבין את התצוגה של רמת הביטחון.
אם מחליטים להשתמש בהם, כדאי לבדוק סוגים שונים של תצוגות בשלב מוקדם בתהליך פיתוח המוצר כדי לגלות מה הכי מתאים למשתמשים.
קישור לדוגמה המלאה: https://pair.withgoogle.com/guidebook/patterns#how-to-show-model-confidence
בסקירה של הגישות המומלצות להצגת רמת הביטחון בפרק בנושא הסבר + אמון במדריך PAIR, מצאת את האפשרויות הבאות:
- N הסיווגים הסבירים ביותר
- רמת סמך מספרית
בהנחה שאתם מציגים למשתמשים רשימה של סרטים מומלצים בדף הנחיתה באפליקציה, אתם יכולים לבחור ברשימה מסודרת, שבה מוצגים הסרטים שהכי סביר שהמשתמש יאהב, לפי סדר.
קרוסלה של סרטים מומלצים, כשההמלצות הכי סבירות מוצגות ראשונות
7. לתת למשתמש דרך להתקדם משגיאות
בשלבים האחרונים למדתם על כמה שיטות מומלצות להגדרת ציפיות ולמתן הסברים למשתמשים, כדי לעזור להם לבנות את האמון במוצר ולכייל אותו.
שאלה חשובה נוספת שכדאי לענות עליה היא: איך נראית חוויית המשתמש כשמתרחשת שגיאה? חשוב באותה מידה לדעת איך המשתמשים מתקדמים. התמקדות בפעולות שהמשתמשים יכולים לבצע אחרי שהמערכת נכשלת מעניקה להם כוח, תוך שמירה על התועלת של המוצר.
כמו שמוסבר בפרק בנושא שגיאות + כשלים שאינם קריטיים במדריך PAIR, כדאי להתחיל בהגדרה של מהי שגיאה במוצר שלכם, ואיזה סוג שגיאה היא (משתמש, מערכת או הקשר).
לדוגמה:
- המשתמש מקבל המלצה לסרט שהוא כבר ראה בקולנוע. יכול להיות שההמלצה הזו לא מושבתת, אבל היא גם לא ממש מועילה למשתמש.
- המשתמש מקבל המלצה לסרט שהוא כבר ראה בקולנוע ולא אהב. יכול להיות שהמשתמש יראה את ההמלצה הזו כשגיאה, בהתאם להעדפות שלו לגבי סרטים.
- המשתמש מקבל המלצה לסרט בז'אנר שהוא בדרך כלל לא נהנה ממנו. יכול להיות שהמשתמש יראה את זה כשגיאה.
- המשתמש מקבל המלצה לסרט שכבר לא מתארח באפליקציה. זו שגיאת מערכת ברורה.
בדוגמאות השנייה והשלישית שמופיעות למעלה, ה-AI סיפק המלצה שלא מועילה למשתמש הזה. במקרה של שגיאות כאלה, מומלץ לתת למשתמשים הזדמנות לספק משוב על התחזית, ולציין את הזמן שיידרש עד שההשפעה תורגש, כמו שמומלץ בפרק בנושא משוב + שליטה במדריך PAIR.
דוגמת עיצוב:
אם המערכת שלכם שמבוססת על AI מתנהגת בצורה שהמשתמש לא מצפה לה או לא רוצה, חשוב לוודא שיש לו אפשרות לשתף משוב. וכדאי להשתמש במשוב הזה כדי לשפר את המודל.
משוב במערכות AI יכול להיות במגוון צורות, כולל:
- איך נותנים לייק או דיסלייק להמלצה
- הסתרת המלצות לא רצויות
- סימון המלצות בעייתיות או דיווח עליהן
- תהליכי משוב מסורתיים יותר, שבהם משתמש מדווח על בעיה באופן ידני באמצעות טופס או מנגנון אחר
אחרי שמשתמש שולח משוב, חשוב לאשר שקיבלתם אותו. אם אפשר, כדאי להסביר להם איך המערכת תגיב למשוב.
קישור לדוגמת העיצוב המלאה: https://pair.withgoogle.com/guidebook/patterns#let-users-give-feedback
במקרה של האפליקציה שלך, יכול להיות שההודעה תיראה כך:
המשתמשים יכולים לשלוח משוב על ההמלצות...
...והם מקבלים הודעה על מה שיקרה בהמשך
8. מזל טוב
מעולה! הרגע עברתם על דוגמה של תהליך עבודה שמראה איך להשתמש בחלק מהמשאבים החדשים של המדריך של PAIR.
סיכום
ב-Codelab הזה למדתם איך:
- תרגום צרכים של משתמש לבעיה ב-AI
- יצירת קבוצת נתונים למשימה
- הצטרפות של משתמשים לתכונה החדשה
- הסבר על המערכת והגדרת ציפיות המשתמשים
- לתת למשתמש דרך להתקדם משגיאות
- איסוף משוב כדי לשפר את המוצר
מה השלב הבא?
בקישורים הבאים אפשר למצוא את כל המקורות שמופיעים ב-Codelab הזה, ועוד הרבה יותר: