ש:
מדוע להפעיל אימונים של למידת מכונה במכונה מקומית ואז להריץ באופן קבוע בשרת?
ת:השאלה כיצד לבנות פרויקט למידת מכונה ושלבי הרכבת והבדיקה שלו קשורה רבות לאופן בו אנו עוברים את "מחזור החיים" של ML ומביאים את התוכנית מסביבת אימונים לסביבת ייצור.
אחת הסיבות הפשוטות ביותר להשתמש במודל לעיל של הצבת אימוני ML במכונה מקומית ואז העברת ביצוע למערכת מבוססת שרת היא היתרון של הפרדת תפקידים חיונית. באופן כללי, אתה רוצה שמערכת האימונים תתבודד, כך שתקבל תמונה ברורה של איפה האימונים מתחילים ונפסקים, והיכן מתחילה הבדיקה. מאמר KDNuggets זה מדבר על העיקרון בצורה גסה תוך כדי עובר על כמה מהסיבות האחרות לבודד מערכות אימונים במכונה מקומית. הצעת ערך בסיסית נוספת לדגם זה היא שעם מערכי ההדרכה והמבחנים בארכיטקטורות שונות מאוד, לעולם לא תתבלבלו ביחס להקצאת הרכבות / מבחן המשותפת!
יתרון מעניין נוסף קשור לאבטחת הרשת. מומחים מציינים כי אם ברשותכם תהליכי הרכבת הראשוניים במכונה מקומית, זה לא חייב להיות מחובר לאינטרנט! זה מרחיב את האבטחה באופן בסיסי, "דגירה" של התהליך עד שהוא פוגע בעולם הייצור, שם אתה צריך לבנות אבטחה נאותה במודל השרת.
בנוסף, חלק מהמודלים ה"מבודדים "הללו עשויים לעזור בבעיות כמו סחיפת קונספט והקשרים נסתרים - העיקרון של" אי-סטיישן "מזהיר מפתחים כי הנתונים אינם" נשארים זהים "לאורך זמן (תלוי במה שנמדד) שזה יכול לקחת הרבה יכולת הסתגלות כדי להפוך את שלב הבדיקה להתאים לשלב הרכבת. או, במקרים מסוימים, תהליכי הרכבת והבדיקה משתלבים זה בזה ויוצרים בלבול.
פריסת שלב הבדיקה בשרת לראשונה יכולה להקל על דגמי "קופסא שחורה" שונים שבהם אתה פותר את בעיית יכולת ההתאמה של נתונים. במקרים מסוימים זה מבטל את התהליך המיותר של הצבת הוראות שינוי למספר פלטפורמות.
ואז, כמובן, שסביבת השרת משרתת כמובן את התהליכים בזמן אמת או הדינמיים שבהם המהנדסים ירצו לגשת למודלי העברת הנתונים והקוד המתאימים ביותר לייצור ב- ML. לדוגמא, AWS Lambda עשויה להיות אפשרות אטרקטיבית לטיפול במיקרו תפקודי הייצור (או שילוב של אחסון אובייקטים של Lambda ו- S3) וללא קישוריות (ללא שרת) שהופכת לבלתי אפשרית.
אלה הם כמה מהנושאים שמפתחים עשויים לחשוב עליהם כאשר הם שוקלים כיצד לחלק שלבי ML של הדרכה מבדיקות וייצור.
