4 גורמים לבדיקת יישומי למידת מכונה

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

אבל איך יודעים שהתשובות נכונות?

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

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

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

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

במה בודקים צריכים להתמקד ביישומי למידת מכונה:

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

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

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

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

בשורה התחתונה

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

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

עכשיו קל מתמיד לכתוב את הקוד שלך להפעלה במקביל - נסה את Intel® Parallel Studio XE בחינם למשך 30 יום