1. לפני שמתחילים
ב-codelab הזה תיישמו שיטות מומלצות מהמהדורה החדשה של People + AI Research (PAIR) Guidebook (מדריך מחקר בנושא אנשים + AI) כדי לעצב מוצר חדש עם AI, תוך התמקדות בשיטות מומלצות לשימוש בנתונים שמתמקדות באנשים ובכיול נכון של האמון של המשתמשים.
דרישות מוקדמות
- הבנה בסיסית של מהי AI.
- ידע בתהליך העבודה של פיתוח מוצרים.
מה תלמדו
בשיעור ה-Lab הזה תלמדו איך להשתמש במדריך People + AI של Google Research כדי ליצור מוצרי AI אמינים שמתמקדים במשתמשים.
באופן ספציפי, אתם יכולים:
- מה חדש במהדורה השנייה של המדריך של PAIR
- תעברו סדרה של תרגילים שמדגישים הזדמנויות בתהליך פיתוח ה-AI לכיול אמון המשתמשים, עם דגש על נתונים ועל יכולת הסבר שפונה למשתמשים.
- הסבר על ערכת כלים רחבה יותר של חומרים ומשאבים שזמינים ללימוד נוסף.
מה נדרש
- דפדפן
- חשבון Google כדי להציג קובץ notebook של 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. איך מאפשרים למשתמשים להתקדם למרות השגיאות
בשלבים הקודמים למדתם כמה שיטות מומלצות להגדרת ציפיות ולמתן הסברים למשתמשים, כדי לעזור להם לבנות את האמון במוצר ולכייל אותו.
שאלה חשובה נוספת שכדאי לענות עליה היא: איך נראית חוויית המשתמש כשמתרחשת שגיאה? חשוב באותה מידה לדעת איך המשתמשים מתקדמים. התמקדות בפעולות שהמשתמשים יכולים לבצע אחרי שהמערכת נכשלת מעצימה אותם, ובו-זמנית שומרת על התועלת של המוצר.
כמו שמוסבר בפרק Errors + Graceful Failure (שגיאות + כשלים שאינם גורמים להפסקת הפעולה) במדריך PAIR, כדאי להתחיל בהגדרה של שגיאה במוצר שלכם, ושל סוג השגיאה (משתמש, מערכת או הקשר).
לדוגמה:
- המשתמש מקבל המלצה לסרט שהוא כבר ראה בקולנוע. יכול להיות שההמלצה הזו לא תהיה מושבתת, אבל היא גם לא תהיה שימושית במיוחד למשתמש.
- המשתמש מקבל המלצה לסרט שהוא כבר ראה בקולנוע ולא אהב. יכול להיות שהמשתמש יראה את ההמלצה הזו כשגיאה, בהתאם להעדפות שלו לגבי סרטים.
- המשתמש מקבל המלצה לסרט בז'אנר שהוא בדרך כלל לא נהנה ממנו. יכול להיות שהמשתמש יראה את זה כשגיאה.
- המשתמש מקבל המלצה לסרט שכבר לא מתארח באפליקציה. זו שגיאת מערכת ברורה.
בדוגמאות השנייה והשלישית שמופיעות למעלה, ה-AI סיפק המלצה שלא מועילה למשתמש הזה. במקרה ששגיאות כאלה מתרחשות, מומלץ לתת למשתמש הזדמנות לספק משוב על התחזית, ולציין את הזמן שיידרש עד שההשפעה תורגש, כפי שמומלץ בפרק בנושא משוב + שליטה במדריך PAIR.
דוגמת עיצוב:
אם המערכת שמבוססת על AI מתנהגת בצורה שהמשתמש לא מצפה לה או לא רוצה, חשוב לוודא שיש לו אפשרות לשתף משוב. כדאי להשתמש במשוב הזה כדי לשפר את המודל.
משוב במערכות AI יכול להיות במגוון פורמטים, כולל:
- איך נותנים לייק או דיסלייק להמלצה
- הסתרת המלצות לא רצויות
- סימון המלצות בעייתיות או דיווח עליהן
- תהליכי משוב מסורתיים יותר, שבהם משתמש מדווח באופן ידני על בעיה באמצעות טופס או מנגנון אחר
אחרי שמשתמש שולח משוב, חשוב לאשר שקיבלתם אותו. אם אפשר, כדאי להסביר להם איך המערכת תגיב למשוב.
קישור לדוגמת העיצוב המלאה: https://pair.withgoogle.com/guidebook/patterns#let-users-give-feedback
במקרה של האפליקציה שלכם, זה יכול להיראות כך:
המשתמשים יכולים לשלוח משוב על ההמלצות...
...והם מקבלים הודעה על מה שיקרה בהמשך
8. מזל טוב
מעולה! הרגע עברתם על דוגמה של תהליך עבודה שמראה איך להשתמש בחלק מהמשאבים החדשים של המדריך של PAIR.
סיכום
ב-Codelab הזה למדתם איך:
- תרגום צרכים של משתמש לבעיה ב-AI
- יוצרים מערך נתונים למשימה
- הצטרפות של משתמשים לתכונה החדשה
- הסבר על המערכת והגדרת ציפיות המשתמשים
- איך מאפשרים למשתמשים להתקדם למרות השגיאות
- איסוף משוב כדי לשפר את המוצר
מה השלב הבא?
בקישורים הבאים אפשר למצוא את כל המשאבים שמודגשים ב-Codelab הזה, ועוד הרבה משאבים אחרים: