תפעול למידת מכונה ב-Mail.ru Mail

מבוסס על הנאומים שלי ב- Highload++ וב-DataFest Minsk 2019.

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

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

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

• תשובה חכמה. לדואר יש תכונת מענה חכמה. הרשת העצבית מנתחת את הטקסט של המכתב, מבינה את משמעותו ומטרתו, וכתוצאה מכך מציעה את שלוש אפשרויות התגובה המתאימות ביותר: חיובית, שלילית וניטרלית. זה עוזר לחסוך משמעותית בזמן במענה למכתבים, וגם לרוב להגיב בצורה לא סטנדרטית ומצחיקה.
• קיבוץ מייליםהקשורים להזמנות בחנויות מקוונות. לעתים קרובות אנו קונים באינטרנט, וככלל, חנויות יכולות לשלוח מספר מיילים עבור כל הזמנה. למשל, מ-AliExpress, השירות הגדול ביותר, נכנסות הרבה אותיות להזמנה אחת, וחישבנו שבמקרה המסוף מספרן יכול להגיע עד 29. לכן, באמצעות מודל ה-Named Entity Recognition, אנו מחלצים את מספר ההזמנה ומידע נוסף מהטקסט וקבץ את כל האותיות בשרשור אחד. אנו מציגים גם מידע בסיסי על ההזמנה בתיבה נפרדת, מה שמקל על העבודה עם סוג זה של מיילים.

  

• אנטי פישינג. פישינג הוא סוג הונאה מסוכן במיוחד של אימייל, שבעזרתו מנסים תוקפים להשיג מידע פיננסי (כולל כרטיסי בנק של המשתמש) וכניסות. מכתבים כאלה מחקים מכתבים אמיתיים שנשלחו על ידי השירות, כולל ויזואלית. לכן, בעזרת Computer Vision, אנו מזהים לוגואים ואת סגנון העיצוב של מכתבים מחברות גדולות (למשל, Mail.ru, Sber, Alfa) ולוקחים זאת בחשבון יחד עם טקסט ותכונות אחרות במסווג הספאם והדיוג שלנו .

למידת מכונה

קצת על למידת מכונה בדוא"ל באופן כללי. דואר היא מערכת עמוסה מאוד: ממוצע של 1,5 מיליארד מכתבים ביום עוברים בשרתים שלנו עבור 30 מיליון משתמשי DAU. כ-30 מערכות למידת מכונה תומכות בכל הפונקציות והתכונות הנדרשות.

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

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

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

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

ניצול

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

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

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

אוטומציה

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

• איסוף נתונים;
• אימון נוסף;
• לפרוס;
• בדיקות וניטור.

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

לולאת משוב

מחזור זה משלב איסוף נתונים, הדרכה נוספת ופריסה – למעשה, כל מחזור עדכון המודל. למה זה חשוב? עיין בלוח ההרשמה בדואר:

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

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

איסוף נתונים

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

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

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

איכות משוב

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

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

אנו משתמשים בשתי גישות:

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

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

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

היוריסטיקה ללמידה

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

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

אז צבא של קביים הוא מאוד שימושי. העיקר שהשירות שלהם דחוף ולא קבוע.

אימון נוסף

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

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

לכן, הדבר החשוב ביותר בהכשרה נוספת הוא לוודא שהמודל ישתפר, או לפחות לא יחמיר.

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

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

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

מודלים ליניאריים

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

• LogLoss על נתונים חדשים;
• אנו מסדירים את משקלם של תכונות חדשות (איננו נוגעים בישנים);
• אנו גם לומדים מנתונים ישנים כדי לשמר דפוסים ישנים;
• ואולי, הדבר החשוב ביותר: אנו מוסיפים הרמונית Regularization, שמבטיחה שהמשקלים לא ישתנו הרבה ביחס לדגם הישן על פי הנורמה.

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

Деревья

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

1. הייצור מפעיל יער של 100-300 עצים, אשר מאומן על סט נתונים ישן.
2. בסוף אנחנו מסירים M = 5 חלקים ומוסיפים 2M = 10 חדשים, מאומנים על כל סט הנתונים, אבל עם משקל גבוה לנתונים החדשים, מה שמבטיח כמובן שינוי מצטבר במודל.

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

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

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

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

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

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

FastText

בואו נעבור ל-FastText. הרשו לי להזכיר לכם שהייצוג (Embedding) של מילה מורכב מסכום הטבעה של המילה עצמה וכל האותיות שלה N-grams, בדרך כלל טריגרמות. מכיוון שיכולות להיות די הרבה טריגרמות, נעשה שימוש ב-Bucket Hashing, כלומר, ממיר את כל החלל ל-hashmap קבוע מסוים. כתוצאה מכך מתקבלת מטריצת המשקל עם מימד השכבה הפנימית למספר מילים + דליים.

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

CNN

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

הפסד משולש

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

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

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

אדריכלות שלמה

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

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

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

לפרוס

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

בדיקת A/B

כפי שאמרתי קודם, בתהליך איסוף הנתונים אנו מקבלים בדרך כלל מדגם מוטה, שממנו אי אפשר להעריך את ביצועי הייצור של המודל. לכן, בעת הפריסה יש להשוות את המודל לגרסה הקודמת על מנת להבין איך הדברים מתנהלים בפועל, כלומר לבצע בדיקות A/B. למעשה, תהליך ההפצה והניתוח של תרשימים הוא שגרתי למדי וניתן להפוך אותו לאוטומטי בקלות. אנו מפיצים את המודלים שלנו בהדרגה ל-5%, 30%, 50% ו-100% מהמשתמשים, תוך איסוף כל המדדים הזמינים על תגובות המודל ומשוב משתמשים. במקרה של חריגים חמורים, אנו מחזירים את המודל לאחור באופן אוטומטי, ובמקרים אחרים, לאחר שאספנו מספר מספיק של קליקים של משתמשים, אנו מחליטים להגדיל את האחוז. כתוצאה מכך, אנו מביאים את הדגם החדש ל-50% מהמשתמשים באופן אוטומטי לחלוטין, וההשקה לכל הקהל תאושר על ידי אדם, אם כי שלב זה יכול להיות אוטומטי.

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

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

בזמן היישום, גישה זו אפשרה לנו להגדיל את מספר מבחני ה-A/B המוצלחים מספר פעמים.

בדיקות וניטור

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

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

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

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

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

תוצאות של

בואו נעבור שוב על הרעיונות המרכזיים של המאמר.

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

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

מקור: www.habr.com