כדי להבין את הבעיה, מבצעים את המשימות הבאות:
- מציינים את היעד של המוצר שאתם מפתחים או מבצעים בו רפאקציה.
- קובעים אם הפתרון הטוב ביותר להשגת היעד הוא באמצעות למידת מכונה חזוי, AI גנרטיבי או פתרון שאינו מבוסס למידת מכונה.
- אם אתם משתמשים בגישה של למידת מכונה חזוי, עליכם לוודא שיש לכם את הנתונים הנדרשים לאימון מודל.
הצגת היעד
קודם כול, צריך לנסח את היעד שלכם במונחים שאינם קשורים ל-ML. היעד הוא התשובה לשאלה "מה אני רוצה להשיג?"
בטבלה הבאה מפורטים בבירור היעדים של אפליקציות היפותטיות:
אפליקציה | היעד |
---|---|
אפליקציית מזג אוויר | חישוב כמות המשקעים במרווחים של שש שעות לאזור גיאוגרפי. |
אפליקציית אופנה | יצירת מגוון עיצובים של חולצות. |
אפליקציית וידאו | להמליץ על סרטונים מועילים. |
אפליקציית Mail | זיהוי ספאם. |
אפליקציה פיננסית | סיכום של מידע פיננסי ממספר מקורות חדשותיים. |
אפליקציית מפה | מחשבים את זמן הנסיעה. |
אפליקציית בנקאות | זיהוי עסקאות שמקורן בתרמית. |
אפליקציה למסעדות | זיהוי המטבח לפי התפריט של המסעדה. |
אפליקציית מסחר אלקטרוני | להשיב לביקורות עם תשובות מועילות. |
תרחיש לדוגמה ברור ללמידת מכונה
יש אנשים שרואים ב-ML כלי אוניברסלי שאפשר להחיל על כל הבעיות. בפועל, למידת מכונה היא כלי מיוחד שמתאים רק לבעיות מסוימות. לא כדאי להטמיע פתרון ML מורכב כשפתרון פשוט יותר ללא ML יעשה את העבודה.
מערכות למידת מכונה מתחלקות לשתי קטגוריות רחבות: למידת מכונה חזוי וAI גנרטיבי. בטבלה הבאה מפורטים המאפיינים המגדירים שלהם:
קלט | פלט | שיטת אימון | |
---|---|---|---|
למידת מכונה חזוי |
טקסט תמונה אודיו וידאו ספרתי |
ביצוע חיזוי, למשל, סיווג אימייל כספאם או לא ספאם, ניחוש של כמות המשקעים מחר או חיזוי של מחיר המניה. בדרך כלל אפשר לבדוק את הפלט מול המציאות. | בדרך כלל נעשה שימוש בהרבה נתונים כדי לאמן מודל למידה מבוקרת, למידה בלתי מבוקרת או למידה חיזוי, כדי לבצע משימה ספציפית. |
AI גנרטיבי |
טקסט תמונה אודיו וידאו ספרתי |
יצירת פלט על סמך כוונת המשתמש, למשל סיכום של מאמר או יצירת קליפ אודיו או סרטון קצר. | בדרך כלל נעשה שימוש בהרבה נתונים לא ממותגים כדי לאמן מודל שפה גדול או גנרטור תמונות, כדי למלא נתונים חסרים. לאחר מכן אפשר להשתמש במודל למשימות שאפשר להגדיר כמשימות של מילוי החסר, או לשפר אותו על ידי אימון על נתונים מתויגים למשימה ספציפית, כמו סיווג. |
כדי לוודא ש-ML היא הגישה הנכונה, קודם צריך לוודא שהפתרון הנוכחי שאינו מבוסס על למידת מכונה עבר אופטימיזציה. אם לא הטמעתם פתרון שאינו מבוסס-למידה חישובית, נסו לפתור את הבעיה באופן ידני באמצעות שיטה חוקרת.
הפתרון ללא למידת מכונה הוא אמת המידה שבעזרתה תוכלו לקבוע אם למידת מכונה היא תרחיש שימוש מתאים לבעיה שלכם. כשמשווים בין גישה ללא למידת מכונה לבין גישה עם למידת מכונה, כדאי לשקול את השאלות הבאות:
איכות. עד כמה לדעתך פתרון של למידת מכונה יכול להיות טוב יותר? אם לדעתכם פתרון של למידת מכונה יביא לשיפור קטן בלבד, יכול להיות שהפתרון הנוכחי הוא הטוב ביותר.
עלות ותחזוקה. מהי העלות של פתרון ה-ML לטווח הקצר ולטווח הארוך? במקרים מסוימים, הטמעת למידת מכונה יקרה יותר באופן משמעותי מבחינת משאבי המחשוב והזמן. כדאי לשקול את השאלות הבאות:
- האם הפתרון של למידת המכונה מצדיק את העלייה בעלות? חשוב לזכור ששיפורים קטנים במערכות גדולות יכולים בקלות להצדיק את העלות ואת התחזוקה של הטמעת פתרון למידת מכונה.
- כמה תחזוקה נדרשת לפתרון? במקרים רבים, כדי ליישם ביעילות את ה-ML צריך צוות ייעודי לתחזוקה לטווח ארוך.
- האם למוצר יש את המשאבים הנדרשים כדי לתמוך בהדרכה או בהעסקה של אנשים עם מומחיות ב-ML?
בדיקת ההבנה
למידת מכונה חזוי ונתונים
נתונים הם הכוח המניע של למידת מכונה חזוי. כדי לבצע תחזיות טובות, צריך נתונים שמכילים מאפיינים עם יכולת חיזוי. הנתונים צריכים להיות בעלי המאפיינים הבאים:
Abundant. ככל שיהיו יותר דוגמאות רלוונטיות ומועילות במערך הנתונים, כך המודל יהיה טוב יותר.
עקבי ואמין. נתונים שנאספים באופן עקבי ואמין יאפשרו לכם ליצור מודל טוב יותר. לדוגמה, מודל מזג אוויר שמבוסס על למידת מכונה ייהנה מנתונים שנאספו במשך שנים רבות מאותם מכשירים מהימנים.
Trusted. מהיכן מגיעים הנתונים. האם הנתונים יגיעו ממקורות מהימנים שבשליטתכם, כמו יומנים מהמוצר שלכם, או ממקורות שאין לכם הרבה תובנות לגביהם, כמו הפלט ממערכת ML אחרת?
זמין. חשוב לוודא שכל הנתונים הזמינים בזמן החיזוי בפורמט הנכון. אם יהיה קשה לקבל ערכים של מאפיינים מסוימים בזמן החיזוי, כדאי להשמיט את המאפיינים האלה ממערכי הנתונים.
תקין. במערכי נתונים גדולים, אי אפשר למנוע מצב שבו לחלק מהתוויות יהיו ערכים שגויים, אבל אם יותר מאחוז קטן מהתוויות יהיו שגויות, המודל ייצור תחזיות גרועות.
נציג. מערכי הנתונים צריכים לייצג את העולם האמיתי ככל האפשר. במילים אחרות, מערכי הנתונים צריכים לשקף במדויק את האירועים, התנהגויות המשתמשים ו/או התופעות בעולם האמיתי שעבורן נוצר המודל. אימון על מערכי נתונים לא מייצגים עלול לגרום לביצועים נמוכים כשהמודל נדרש לבצע תחזיות בעולם האמיתי.
אם לא ניתן לקבל את הנתונים הנדרשים בפורמט הנדרש, התחזיות של המודל יהיו גרועות.
יכולת חיזוי
כדי שמודל יוכל לבצע חיזויים טובים, לתכונות במערך הנתונים צריכה להיות יכולת חיזוי. ככל שיש יותר מתאם בין מאפיין לתווית, כך יש יותר סיכוי לחזות אותו.
לחלק מהתכונות תהיה יכולת חיזוי טובה יותר מאשר לתכונות אחרות. לדוגמה, במערך נתונים של מזג האוויר, תכונות כמו cloud_coverage
, temperature
ו-dew_point
יהיו חזויות טובות יותר לגשם מאשר moon_phase
או day_of_week
. בדוגמה של אפליקציית הווידאו, אפשר להניח שתכונות כמו video_description
, length
ו-views
יכולות לחזות טוב את הסרטונים שהמשתמשים ירצו לצפות בהם.
זיהוי התכונות שיש להן יכולת חיזוי יכול להיות תהליך שאורך זמן. כדי לבדוק באופן ידני את יכולת החיזוי של מאפיין מסוים, אפשר להסיר אותו ולהוסיף אותו תוך כדי אימון המודל. אפשר להשתמש באלגוריתמים כמו התאמה לקורלציה של Pearson, מידע הדדי מותאם (AMI) וערך Shapley כדי למצוא באופן אוטומטי את יכולת החיזוי של מאפיין מסוים. האלגוריתמים האלה מספקים הערכה מספרית לניתוח יכולת החיזוי של מאפיין.
בדיקת ההבנה
למידע נוסף על ניתוח וייצור של מערכי נתונים, קראו את המאמר הכנת נתונים וייצור תכונות לצורכי למידת מכונה.
חיזויים לעומת פעולות
אין טעם לחזות משהו אם אי אפשר להפוך את התחזית לפעולה שתעזור למשתמשים. כלומר, המוצר צריך לבצע פעולה על סמך הפלט של המודל.
לדוגמה, מודל שמתבסס על נתונים כדי לחזות אם סרטון מסוים יהיה שימושי למשתמש יכול לשמש באפליקציה שממליצה על סרטונים שימושיים. מודל לחיזוי אם ירד גשם צריך להזין לאפליקציית מזג האוויר.
בדיקת ההבנה
על סמך התרחיש הבא, נבדוק אם השימוש בלמידת מכונה הוא הגישה הטובה ביותר לפתרון הבעיה.
צוות מהנדסי תוכנה בארגון גדול אחראי לניהול שיחות טלפון נכנסות.
המטרה: להודיע למתקשרים כמה זמן הם יצטרכו להמתין בהמתנה בהתאם לנפח השיחות הנוכחי.
אין להם פתרון, אבל לדעתם שיטה יעילה היא לפצל את מספר הלקוחות הנוכחי בהמתנה למספר העובדים שעונים לטלפון, ואז להכפיל ב-10 דקות. עם זאת, הם יודעים שלחלק מהלקוחות הבעיות נפתרות תוך שתי דקות, ושלחלקן נדרש עד 45 דקות או יותר.
סביר להניח שהאלגוריתם ההיוריסטי שלהם לא יניב מספר מדויק מספיק. הם יכולים ליצור מערך נתונים עם העמודות הבאות: number_of_callcenter_phones
, user_issue
, time_to_resolve
, call_time
ו-time_on_hold
.
time_on_hold
.