כיצד לבחור נכון את פרויקט ה-Data science הראשון שלכם
אורי אליאבייב, 04/03/2020
נכתב במקור כפוסט בקבוצת Machine & Deep learning Israel
אני רואה שיש פה לאחרונה הרבה דיונים על פרוייקטים ומה כדאי לעשות. הקדשתי לנושא הזה הרבה מחשבה לאחרונה לקראת הקורס שאני מתחיל ללמד באונ' ת"א ואני רוצה לחלוק פה את המחשבות שלי בתקווה שיעזרו לכמה אנשים למקד את המאמצים שלהם. הפוסט הזה מביע את דעתי האישית בלבד, ואין לי דאטא שיתמוך בה אז כל אחד מוזמן לפרש לפי ראות עיניו.
“If we have data, let’s look at data. If all we have are opinions, let’s go with mine.” -Jim Barkdale
אז קודם כל למה שתקשיבו לי בכלל?
חוץ מזה שאני ד"ר בתחום (חשמל בת"א חקרתי קבלת החלטות דינמית), אני גם בתעשייה כבר 4 וחצי שנים, הייתי מוביל טכנולוגי, הקמתי צוות ובדרך להקים עוד אחד (ובדרך ריאיינתי לפחות עשרות אנשים), ואם אתם אוהבים את גאמפא אז גם הייתי שנתיים במיקרוסופט ועבודות שלי הוצגו בכנסים פנימיים של החברה בנוסף לכנסים אקדמיים ולמוצרים מאד מצליחים. אפילו פרצתי דרך בתחום או שניים, אבל זה כבר נושא לפוסט אחר (וחלק מזה בכלל אסור לי לספר).
אז עכשיו אחרי שחפרתי מספיק על הניסיון שלי, מה אני מציע?
אני מציע שלפני כל פרוייקט תדעו לאן אתם רוצים להגיע בחיים ובהמשך מה אתם מתכוונים ללמוד מהפרוייקט הזה כדי לקדם אתכם לשם. למשל, אני כרגע מכין פרוייקט דוגמא לקורס שלי שהמטרה שלו היא לכתוב את הקוד הכי פשוט שיעבוד כדי שיהווה נקודת פתיחה לסטודנטים. אתם מוזמנים לגנוב את התיאור "הקוד הכי פשוט שיעבוד" אם אתם רוצים להראות מנטליות של האקרים, רק קחו בחשבון שלא תהיו היחידים
אם מעולם לא כתבתם שום קוד של דאטא סיינס, המטרה שלכם היא כנראה לכתוב קוד של מסווג פשוט מההתחלה ועד הסוף ולהבין איפה בכלל יש בעיות מימוש ואיך כל שלב של פרוייקט נראה בקוד. אחרי זה כבר תתקלו בכמה בעיות ותוכלו להחליט במה להתעמק. למשל בתואר השני עשיתי שני פרוייקטים, אחד במטרה להבין את התיאוריה שמאחורי למידה (קצת תיאורתי מידי לרוב האנשים אבל ככה אני לומד), ואחד כדי לחזות סדרה בזמן. דרך כל אחד מהם למדתי על בעיות אחרות. הראשון הראה לי איפה המתמטיקה של מודלים מסתבכת והבנתי את הקירובים שאנחנו עושים כדי לבנות מודל, והפרוייקט השני לימד אותי מה המרכיבים הקלאסיים של חיזוי סדרות. הוא גם לימד אותי למי יש עוגיות במשרד ולמי מהחברים שלי אני יכול להתלונן בלי שהוא ינתק. אחרי שסיימתי את הפרוייקט השני למשל יכולתי להמשיך לכמה כיוונים כמו לחפש סדרות מורכבות יותר (למשל כאלה עם אלמנטים מחזוריים), או לחקירה יותר מעמיקה של הנחת פריורים שונים על הרכיבים של סדרה (בא מרקע תיאורתי, כבר אמרנו?) או מה קורה אם סתם מתעלמים מחלק מהרכיבים של סדרה ומקווים לטוב. כולן בעיות שאפילו לא ידעתי שקיימות כשהתחלתי. יש כמובן המון אתגרים ותובנות, אני לא מנסה לפרט את כולם, רק לתת כמה דוגמאות כדי שהדיון לא יהיה באוויר.
עוד דבר הוא השאלה כמה מעשית אתם רוצים שהעבודה תהיה. הרבה אנשים למשל ממליצים על קאגל ואני לא בטוח שזה רעיון טוב. כדי לפרסם בעיה בקאגל מישהו כבר עשה המון עבודה כדי לסדר ולנקות את הדאטא. זה לא מובן מאליו וזה לא המצב במציאות. הנה למשל שקף שמתאר את זה (כנראה) מתוך הרצאה של קרפתי:
https://twitter.com/lishali88/status/994723759981453312
אם המטרה היא להגיע לתעשיה ולהראות שאתם מתאימים להשתלב בעבודה היומיומית של צוות, עיקר הבעיות יהיו בעיות של דאטא. תלכלכו את הידיים עם להשיג דאטא ולטייב אותו ורק אחרי זה תתעסקו בלהוציא עוד עשירית אחוז של דיוק מהאלגוריתם. טוב נו, אז תתחילו מדאטאסט נקי ותריצו מודל כדי לראות שהוא עובד ואז תחפשו דאטא מציאותי ותריצו עליו את אותו המודל. גם אני לא הייתי עומד בפיתוי "לעשות ML" במקום ללכת לחפש דאטא מציאותי ומעצבן בפעם הראשונה. רק תעשו לעצמכם טובה ותתעסקו גם קצת בדאטא אמיתי. כי מראיין שעובד על בעיות אמיתיות גם ישאל על בעיות אמיתיות (נגיד טעות בסדר ההגעה של דגימות). ואם לא יהיה לכם מושג, טוב בואו נגיד שגם המראיין יצטרך עוגיה אחרי הראיון הזה. ויש לו עוד כמה ראיונות באותו יום אז תתחשבו בבקשה.
עוד הרחבה בתגובה הראשונה.
באופן כללי אתגרים של עבודה מציאותית יעניינו חברות יותר מבעיות אלגוריתמיות למרות שכולם אוהבים לדבר על האלגוריתם. גם כשאני מדבר על טיפוס אני מדבר על המסלולים ולא על החימום ועל האימוני טכניקה. אני עדיין משקיע הרבה יותר באימוני טכניקה (למרות שבטיפוס אני עדיין גרוע, חבל שאין אכילת עוגיות תחרותית). כמובן שלדעת להוציא את המקסימום ממודל זה יתרון (תלוי במשרה כמובן), ועם זאת לתעשייה חשוב לראות שפתרתם בעיות ושעשיתם דברים מעבר לבסיס, והרבה יותר קל להראות עבודה על דאטא אמיתי מאשר לעשות דברים מורכבים אלגוריתמית. כמובן שעדיף את שניהם
חלק מהבעיות האמיתיות תגלו רק אם תעבדו בתחום (או תמצאו שותף לפרוייקט שעובד בתחום ומכיר את התעשיה מבפנים) אבל הרבה בעיות של דאטא, מימוש והקמת סביבות יקרו גם בסתם פרוייקט שתמציאו לעצמכם.
לסיום אתן דוגמא ששמעתי היום מחבר (בשינוי הדומיין כי לא ביקשתי רשות): מה קורה אם אני מודד תגובה של מנוע אבל בחלק מהניסויים הטכנאי מסתובב בחדר ונוגע בטעות בכבל, מה שמשפיע על תגובת המנוע יותר מהפקודה עצמה?
אם אתם כבר במקום שבו אתם ויכולים לקחת דאטא אמיתי, לטפל בו באופן בסיסי ולבנות מודל פשוט, קחו את זה לשלב הבא ותחשבו על בעיה לא טריוויאלית. למשל Yam Peleg פרסם לאחרונה פוסט שבו הוא העלה כמה בעיות מעניינות שעלו בדאטא רפואי ואיך הוא התמודד איתן. יש בעיות מעניינות בדאטא, ויש גם בעיות בצד ההנדסי של אימון, תחזוקה ופריסה של מודלים, וגם בעיות של מימוש וכמובן, להגדיר בעיה מעניינת ולדעת לפתור אותה ולמדוד את הביצועים. כל מראיין ירצה לדעת איזה בעיות לא טריוויאליות פתרתם. מישהו שיתקע על כל בעיה זה לא אטרקטיבי. מישהו שיעצור לשתות קפה אחרי בכל בעיה שהוא פתר זה דווקא סבבה. אפשר גם להוסיף עוגיה.
הנה כמה דוגמאות, אני אייחס אותן לתחום של מנועי בנזין כי עבדתי עליו ולרובנו יש איזושהיא אינטואיציה לגבי דברים מכניים:
1. אתגרים שנובעים מהדאטא: מה קורה אם אני רוצה לבנות מודל לסוג מנועים מסויים, אבל מספר הניסויים לא מאוזן בין מנועים מאותה סדרה? כלומר יש מנוע אחד שעשו עליו 20 ניסויים וכמה מנועים שעשו עליהם ניסוי או שניים. מה קורה אם יש הבדל משמעותי באורך של הניסויים? מה קורה אם פרוטוקול הניסוי לא קבוע, או שבחלק שכחו למדוד בהתחלה והתחילו מהאמצע? מה קורה אם היה שינוי בצורת הייצור ויש לי דאטא משתי הצורות אבל אי אפשר לחזור לצורה הקודמת?
2. בעיה אלגוריתמית/מימושית: אני רוצה לחסוך בזמן החישוב של מודל, איך אני עושה את זה? מה בכלל התרחישים השונים שרלוונטיים כדי להעריך את עלות החישוב?
3. בעיה של הגדרת הבעיה ניתוח תוצאות: אם יש לי מסווג לזיהוי תקלה במנוע, איך נכון לנתח את הביצועים שלו? איך זה שונה אם הוא מסווג את ההילוך הנכון לתנאי הנסיעה? האם זה משנה אם ההילוכים מוגדרים מראש או שאני יכול לבחור אותם? האם זה משנה אם התקלה היא אנומליה או לא? מה זה אומר תקלה שהיא לא אנומליה?
4. בעיית מימוש: איך ממשים את השכבה המסובכת הזאת מהמאמר הממש מגניב שיצא לפני 13 שניות וכולם מדברים עליו? למשל תממשו בלוק ResNeXt לבד. או תממשו בלוק DesnseNet, תבינו שהמימוש הראשון יצא לא יעיל ותחשבו איך לפתור את הבעיה (אבל אל תשברו את הראש יותר מידי, הפתרון הפשוט הוא לא להשתמש ב-DenseNet).
אפשר להמשיך אבל הבנתם את העקרון.
אני יכול להגיד שלקראת הקורס ישבתי וחשבתי על שלושים ומשהו נושאים לפרוייקטים קטנים (להערכתי). רובם בטח יתגלו כמסובכים מידי לקורס, אבל רציתי לראות שאני מצליח למצוא דברים לא טריוויאליים שאפשר לממש רק על סמך הקורס (אל תבקשו, אולי אפרסם אותם אחרי כמה מחזורים של הקורס). יש גם את פרוייקטי הגמר מה-MDLI course ש-Uri Eliabayev תמיד מפנה אליו.
ברגע שיש לנו מטרה, די ברור ששיקולים כמו כמה שעות/ימים/תקציב ענן/כמה בא לי עוגיה הם הם לא המטרה. מי שרוצה להשקיע X שעות בפרוייקט כנראה לא באמת מנסה ללמוד. מי שרוצה ללמוד רוצה לדעת שהוא פתר בעיה, וגם לדעת להעריך אם הוא באמת מצא פתרון טוב. למזלנו בדרך כלל קל למצוא פתרון באינטרנט. וואו, אנשים פעם חיו בלי אינטרנט. אני הולך לבדוק איך הם שרדו… טוב חזרתי, מסתבר שאפשר לעבוד בלי אינטרנט, שני מסכים ומכונה שטוחנת את הקפה במקום. ההורים שלנו היו אנשים אמיצים. בחזרה לפרוייקטים. יש מצבים שזה הגיוני לעשות פרוייקט ולא ללמוד ממנו, אבל בוא נודה, מי שלא צריך לעשות פרוייקט כדי ללמוד גם לא היה צריך לקרוא את הפוסט הארוך הזה (וגם לו יש מה ללמוד, הוא פשוט לא צריך כרגע). אז אם קראתם עד לפה תעשו פרוייקטים קודם כל כדי ללמוד משהו שמעניין אתכם ודורש מכם לעשות משהו שאתם עדיין לא יודעים לעשות. או שתמלאו לוטו, לפעמים גם זו דרך להצליח בחיים (רק שהמשפט האחרון הוא לא PAC, אולי אפשר לעשות אנסמבל של טפסי לוטו ).
טוב סיימתי, מגיע לי עוגיה.
* כל הכתוב לעיל מביע את דעתי האישית בלבד.
* הפוסט מנוסח בלשון זכר כי זכר הוא הסתמי בעברית. הפוסט מיועד לכל המגדרים במידה שווה.
“Some beautiful paths can’t be discovered without getting lost.” -Erol Ozan
אורי אליאבייב
