איך בונים תיק עבודות בדאטה סיינס שאפשר להסביר

איך בוחרים שאלה לפרויקט?

בחרו שאלה שיש בה החלטה, ולא רק עמודת מטרה. לדוגמה לימודית: צוות תמיכה יכול לבדוק ידנית מספר מוגבל של פניות בכל יום. האם אפשר לעזור לו לבחור אילו פניות לבדוק קודם? עכשיו יש משתמש, מגבלה והחלטה שהמודל אמור לתמוך בה.

כתבו מה ידוע ברגע ההחלטה ומה יתברר רק אחריה. בדוגמה הזו, זמן הטיפול הסופי אינו מידע שהיה ידוע כשנכנסה הפנייה. הכללת מידע עתידי עלולה ליצור תוצאה מטעה; התיעוד של scikit-learn מגדיר זאת כדליפת מידע.

הדוגמה אינה מקרה לקוח ואינה מחייבת מאגר מסוים. אפשר להשתמש בנתונים ציבוריים בתחום אחר, כל עוד מסבירים את מקורם ואת המגבלות שלהם.

מה צריך להיות בגרסה הראשונה?

1. הגדרת הבעיה: מי משתמש בתוצאה, מה הוא עושה איתה ומה נחשב שיפור.
2. בדיקת נתונים: מקור, הרשאת שימוש, תקופה, חסרים ושדות שצריך להוציא.
3. קו בסיס: כלל פשוט להשוואה לפני שמנסים מודל מורכב.
4. ניסוי: מודל ראשון והערכה בתנאים שמייצגים את השימוש.
5. ניתוח: דוגמאות לשגיאות, ניסיון לשיפור ומסקנות.
6. מסירה: הוראות הרצה, תוצאה מתועדת ודמו או המחשה.

זו תבנית עבודה שאנחנו מציעים, לא רשימת תנאי קבלה של מעסיק. עדיף לסיים את המעגל הזה בהיקף קטן לפני שמוסיפים עוד מודלים, מסכים או מקורות נתונים.

מה מציגים מעבר לציון של המודל?

בפרויקט שלנו על פניות תמיכה, נניח לצורך התרגיל שהצוות יכול לבדוק 20 פניות ביום. אפשר לבחון כמה מהפניות החשובות נכנסו לרשימת הבדיקה, וכמה מהרשימה היו התראות שווא. המספר 20 הוא הנחת תכנון בדוגמה, לא כלל למערכות כאלה.

כדי לבדוק זאת, הגדירו איך מסמנים פנייה כחשובה ומי קובע את הסימון. למשל, אפשר להתחיל מדוגמאות שסווגו ידנית לפי הגדרה מוסכמת. בדקו גם מקרים שבהם המסווגים לא הסכימו; תווית לא עקבית מקשה לפרש את ציון המודל.

הציגו את קו הבסיס ואת המודל באותם תנאי הערכה. אם בדקתם כמה חלופות, תעדו איך בחרתם ביניהן ושמרו נתוני בדיקה סופיים מחוץ לתהליך הבחירה. מדריך ההערכה של scikit-learn מפרט את ההפרדה בין בחירת מודל לבין הערכתו.

הוסיפו דוגמאות לשגיאות עם ההסבר שלכם. גם מודל שלא שיפר את קו הבסיס יכול להוביל למסקנה שימושית: אולי הנתונים אינם מספיקים, אולי הבעיה הוגדרה לא נכון, ואולי כלל פשוט מספק את הצורך.

איך כותבים הסבר שאפשר לקרוא?

הקובץ הראשי בריפו צריך לתת לקורא כניסה ברורה: מה הפרויקט עושה, למה הוא שימושי ואיך מתחילים להריץ אותו. זה גם התפקיד שמתואר בהנחיות GitHub לקובץ README.

בהמשך פרטו התקנה, גרסאות תלויות והפקודות הנחוצות. אם אי אפשר לפרסם את הנתונים, צרפו דוגמה מותרת לשיתוף והסבירו איזה חלק של התוצאה אפשר לשחזר באמצעותה.

האם חייבים אפליקציה וקישור חי?

לא לכל פרויקט מתאים ממשק ציבורי. אפשר להראות דמו קטן, סרטון קצר, מחברת מסודרת או דוח שניתן לשחזר. הבחירה תלויה במה שאתם רוצים להדגים ובמה שמותר לחשוף.

לצורך התרגול שלנו, דמו מועיל יאפשר להכניס פנייה לדוגמה, לראות את ההמלצה ולדעת מתי להעביר אותה לבדיקה ידנית. הקפידו לסמן נתוני הדגמה ולהסביר שהממשק אינו מערכת שירות פעילה.

כשמישהו אמור להסתמך על המערכת בעבודה שוטפת, נדרשים גם תפעול, ניטור ומענה לתקלות. זה השלב שמתואר במדריך המעבר לפרודקשן.

מה לבדוק לפני ששולחים את הפרויקט?

• אדם אחר מצליח להבין את השאלה בלי שיחת הסבר.
• הוראות ההרצה נוסו בסביבה נקייה, או שמגבלות השחזור כתובות.
• הנתונים, התמונות והדוגמאות מותרים לשיתוף; אין מפתחות גישה או פרטי לקוחות.
• אפשר להבחין בין תוצאה שנמדדה לבין יעד עתידי.
• כתוב מה נבנה בעזרת כלי בינה ומה בדקתם בעצמכם.
• אתם מסוגלים להסביר בחירה אחת, טעות אחת ושיפור אחד.

בהצגה בעל פה, התחילו בשאלה ובתוצאה, ואז בחרו החלטה מקצועית אחת להעמיק בה. אין צורך להקריא את כל הקוד. מטרת התיק היא לאפשר שיחה אמיתית על העבודה שלכם; הוא אינו מבטיח זימון או קבלה למשרה.