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