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

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

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

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

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

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

עקרון 1: בסיס קוד אחד

יש מתכנתים בשלבים הראשונים, מתוך עצלות להבין את זה (או מסיבה משלהם), שוכחים מ-Git. או שהם שוכחים לגמרי את המילה, כלומר, הם זורקים קבצים זה לזה בכונן/פשוט זורקים טקסט/שולחים על ידי יונים, או שהם לא חושבים על תהליך העבודה שלהם, ומתחייבים כל אחד לענף שלו, ואז ל- לִשְׁלוֹט.

עקרון זה קובע: יש בסיס קוד אחד והרבה פריסות.

ניתן להשתמש ב-Git הן בייצור והן במחקר ופיתוח (R&D), בהם לא נעשה בו שימוש כל כך הרבה.

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

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

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

עקרון 2: הכרזה ברורה ובידוד תלות

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

• הכריז בבירור על תלות, כלומר, קובץ שיכיל את כל הספריות, הכלים והגירסאות שלהם שנמצאות בשימוש בפרויקט שלך ושיש להתקין (לדוגמה, ב-Python ניתן לעשות זאת באמצעות Pipfile או requirements.txt. A קישור המאפשר טוב להבין: realpython.com/pipenv-guide)
• לבודד תלות ספציפית עבור התוכנית שלך במהלך הפיתוח. אתה לא רוצה לשנות כל הזמן גרסאות ולהתקין מחדש, למשל, את Tensorflow?

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

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

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

לדוגמה, requirements.txt שלך עשוי להיראות כך:

# Model Building Requirements
numpy>=1.18.1,<1.19.0
pandas>=0.25.3,<0.26.0
scikit-learn>=0.22.1,<0.23.0
joblib>=0.14.1,<0.15.0

# testing requirements
pytest>=5.3.2,<6.0.0

# packaging
setuptools>=41.4.0,<42.0.0
wheel>=0.33.6,<0.34.0

# fetching datasets
kaggle>=1.5.6,<1.6.0

עקרון 3: תצורות

רבים שמעו סיפורים על מפתחים שונים שהעלו בטעות קוד ל-GitHub למאגרים ציבוריים עם סיסמאות ומפתחות אחרים מ-AWS, והתעוררו למחרת עם חוב של $6000, או אפילו $50000.

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

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

דוגמאות לנתונים המאוחסנים בדרך כלל במשתני סביבה:

• שמות מתחם
• כתובות API/URI
• מפתחות ציבוריים ופרטיים
• אנשי קשר (דואר, טלפונים וכו')

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

לדוגמה, אם אתה משתמש ב-Kaggle API לביצוע בדיקות (לדוגמה, הורד את התוכנה והפעל את המודל דרכה כדי לבדוק בזמן הריצה שהמודל עובד היטב), אז מפתחות פרטיים מ-Kaggle, כגון KAGGLE_USERNAME ו-KAGGLE_KEY, צריכים להיות מאוחסן במשתני סביבה.

עקרון 4: שירותי צד שלישי

הרעיון כאן הוא ליצור את התוכנית בצורה כזו שלא יהיה הבדל בין משאבים מקומיים למשאבים של צד שלישי מבחינת קוד. לדוגמה, אתה יכול לחבר גם MySQL מקומית וגם של צד שלישי. אותו דבר לגבי ממשקי API שונים כגון מפות Google או API של Twitter.

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

אז, למשל, במקום לציין בכל פעם את הנתיב לקבצים עם מערכי נתונים בתוך הקוד, עדיף להשתמש בספריית pathlib ולהכריז על הנתיב למערכי הנתונים ב-config.py, כך שלא משנה באיזה שירות אתה משתמש (עבור לדוגמה, CircleCI), התוכנית הצליחה לגלות את הנתיב למערכי הנתונים תוך התחשבות במבנה של מערכת הקבצים החדשה בשירות החדש.

עקרון 5. בנייה, שחרור, זמן ריצה

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

1. שלב מכלולים. אתה הופך את הקוד החשוף שלך עם משאבים בודדים למה שנקרא חבילה המכילה את כל הקוד והנתונים הדרושים. חבילה זו נקראת הרכבה.
2. שלב שחרור - כאן אנו מחברים את התצורה שלנו להרכבה, שבלעדיה לא נוכל לשחרר את התוכנית שלנו. כעת מדובר במהדורה מוכנה לחלוטין להפעלה.
3. הבא מגיע השלב לרוץ. כאן אנו משחררים את האפליקציה על ידי הפעלת התהליכים הדרושים מהשחרור שלנו.

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

עבור משימת השחרור, נוצרו שירותים רבים ושונים שבהם אתה יכול לכתוב תהליכים כדי להפעיל את עצמך בקובץ .yml (לדוגמה, ב-CircleCI זה config.yml כדי לתמוך בתהליך עצמו). Wheely נהדר ביצירת חבילות לפרויקטים.

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

עקרון 6. הפעל את המודל שלך כתהליך אחד או יותר

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

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

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

כדי להפעיל את המודל כמספר תהליכים, ניתן ליצור קובץ .yml בו תציין את התהליכים הדרושים ואת הרצף שלהם.

עקרון 7: יכולת מיחזור

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

כלומר, התהליך שלך עם המודל צריך:

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

עקרון 8: פריסה רציפה/אינטגרציה

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

לכן, עיקרון זה קובע שסביבת הפיתוח שלך צריכה להיות קרובה ככל האפשר לסביבת הייצור שלך.

זה יאפשר:

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

כלים המאפשרים לך לעבוד עם זה הם CircleCI, Travis CI, GitLab CI ואחרים.

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

צמצם הבדלים!!!

עקרון 9. היומנים שלך

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

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

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

עקרון 10. מבחן!

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

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

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

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

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

מקור: www.habr.com