הפוסט הזה נכתב בשיתוף עם Suhyoung Kim, המנהל הכללי במעבדת KakaoGames Data Analytics.

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

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

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

בחרנו את אחד המשחקים הפופולריים ביותר של Kakao Games, ODIN, כמשחק היעד של הפרויקט. ODIN הוא משחק תפקידים מקוון מרובה משתתפים פופולרי (MMORPG) למחשבים ולמכשירים ניידים שפורסם ומופעל על ידי Kakao Games. הוא הושק ביוני 2021 ודורג בין שלושת ההכנסות המובילות בקוריאה.

אתגרים

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

התנהגות שחקן מושפעת מאירועים פנימיים וחיצוניים

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

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

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

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

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

מספר מקורות נתונים

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

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

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

מדרגיות למשחקים אחרים

ל-Kakao Games יש משחקים אחרים עם מעורבות שחקנים ארוכת טווח בדיוק כמו ODIN. באופן טבעי, חיזוי LTV תורם גם למשחקים האלה. מכיוון שרוב המשחקים חולקים סוגי יומנים דומים, הם רוצים לעשות שימוש חוזר בפתרון ML זה למשחקים אחרים. אנו יכולים למלא את הדרישה הזו על ידי שימוש ביומן המשותף ובתכונות של משחקים שונים כאשר אנו מעצבים את מודל ה-ML. אבל עדיין יש אתגר הנדסי. יש לבנות מחדש את צינור ה-ETL, צינור MLOps והסקת ML בחשבון AWS אחר. פריסה ידנית של פתרון מורכב זה אינה ניתנת להרחבה וקשה לתחזק את הפתרון שנפרס.

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

סקירת פתרונות

פתרון ה-ML עבור חיזוי LTV מורכב מארבעה מרכיבים: צינור מערך ההדרכה של ETL, צינור MLOps, צינור ETL ​​של מערך מסקנות והסקת אצווה של ML.

צינור ההדרכה וההסקה של ETL יוצר תכונות ML מיומני המשחק והמטא נתונים של השחקן המאוחסנים בטבלאות Athena, ומאחסן את נתוני התכונות המתקבלות ב- שירות אחסון פשוט של אמזון (אמזון S3) דלי. ETL דורש שלבי טרנספורמציה מרובים, וזרימת העבודה מיושמת באמצעות AWS Glue. ה-MLOps מאמן מודלים של ML, מעריך את המודל המאומן מול המודל הקיים, ולאחר מכן רושם את המודל המאומן למרשם המודלים אם הוא עולה על המודל הקיים. כל אלה מיושמים כצינור ML יחיד באמצעות צינורות SageMaker של אמזון, וכל אימוני ה-ML מנוהלים באמצעות ניסויים באמזון SageMaker. בעזרת SageMaker Experiments, מהנדסי ML יכולים למצוא באילו מערכי נתונים, הפרמטרים ותצורות הדרכה והערכה שימשו עבור כל מודל ML במהלך ההדרכה או מאוחר יותר. מהנדסי ML כבר לא צריכים לנהל מטא נתונים אלה של ההדרכה בנפרד.

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

האיור הבא מראה כיצד רכיבים אלה פועלים יחד כפתרון ML יחיד.

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

בסעיפים הבאים, נדון בכל רכיב ביתר פירוט.

צינור נתונים ליצירת תכונות ML

יומני משחקים המאוחסנים באתנה בגיבוי של Amazon S3 עוברים דרך צינורות ה-ETL שנוצרו כעבודות מעטפת Python ב-AWS Glue. זה מאפשר להריץ סקריפטים של Python עם AWS Glue לדיוק תכונות כדי ליצור את מערך הנתונים המוכן לאימון. טבלאות מתאימות בכל שלב נוצרות באתנה. אנו משתמשים ב-AWS Glue להפעלת צינור ה-ETL בשל הארכיטקטורה חסרת השרת שלו והגמישות ביצירת גרסאות שונות של מערך הנתונים על ידי העברת תאריכי התחלה וסיום שונים. מתייחס גישה לפרמטרים באמצעות getResolvedOptions למידע נוסף על איך להעביר את הפרמטרים לעבודת דבק של AWS. בשיטה זו, ניתן ליצור את מערך הנתונים שיכסה תקופה של עד 4 שבועות, ותומך במשחק בשלביו המוקדמים. לדוגמה, תאריך ההתחלה של הקלט ותאריך ההתחלה של החיזוי עבור כל גרסה של מערך הנתונים מנותחים באמצעות הקוד הבא:

import sys
from awsglue.utils import getResolvedOptions args = getResolvedOptions( sys.argv, [ 'JOB_NAME', 'db_name', 'ds_version', 'input_start_date', 'prediction_start_date', 'bucket', 'prefix', 'timestamp' ]
)

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

באופן ספציפי, יצרנו גרסאות של מערך נתונים עם תאריכי התחלה שונים (הוזזו ב-4 שבועות) ותקופות אימון שונות (12 שבועות, 16 שבועות, 20 שבועות, 24 שבועות ו-28 שבועות) בתשעה מסדי נתונים של Athena המגובים על ידי Amazon S3. כל גרסה של מערך הנתונים מכילה את התכונות המתארות את מאפייני השחקנים ונתוני סדרת זמן של פעילות רכישה במשחק.

דגם ML

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

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

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

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

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

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

• שלב 1 - ערכי יעד עבור LTV מומרים לתווית בינארית, LTV = 0 ו LTV > 0. AutoGluon TabularPredictor מאומן כדי למקסם את ציון F1.
• שלב 2 – מודל רגרסיה באמצעות AutoGluon TabularPredictor משמש לאימון המודל על משתמשים עם LTV > 0 עבור רגרסיית LTV בפועל.

במהלך שלב בדיקת המודל, נתוני הבדיקה עוברים על שני המודלים ברצף:

• שלב 1 – מודל הסיווג הבינארי פועל על נתוני בדיקה כדי לקבל את החיזוי הבינארי 0 (למשתמש שיש LTV = 0, churned) או 1 (למשתמש יש LTV > 0, לא נמחק).
• שלב 2 – שחקנים חזו עם LTV > 0 עברו על מודל הרגרסיה כדי לקבל את ערך ה-LTV בפועל החזוי. בשילוב עם המשתמש החזוי כבעל LTV = 0, נוצרת תוצאת חיזוי ה-LTV הסופית.

חפצי מודל המשויכים לתצורות האימון עבור כל ניסוי ולכל גרסה של מערך נתונים מאוחסנים בדלי S3 לאחר האימון, וכן נרשמים ל- SageMaker Model Registry בתוך ריצת SageMaker Pipelines.

כדי לבדוק אם יש סחיפה כלשהי של נתונים עקב שימוש באותו מודל שהוכשר על מערך הנתונים v1 (12 שבועות החל מאוקטובר), אנו מריצים הסקה על מערך הנתונים v1, v2 (זמן ההתחלה הוזז קדימה ב-4 שבועות), v3 (הוסט קדימה על ידי 8 שבועות), וכן הלאה עבור v4 ו-v5. הטבלה הבאה מסכמת את ביצועי המודל. המדד המשמש להשוואה הוא ציון המינימקס, שהטווח שלו הוא 0-1. זה נותן מספר גבוה יותר כאשר חיזוי LTV קרוב יותר לערך LTV האמיתי.

נראית ירידה בביצועים במערך נתונים v2 ו-v3, מה שעולה בקנה אחד עם הניתוח שבוצע בגישות דוגמנות שונות בעלות ביצועים מופחתים במערך נתונים v2 ו-v3. עבור v4 ו-v5, המודל מציג ביצועים מקבילים, ואף מציג שיפור קל ב-v5 ללא הדרכה מחדש של הדגם. עם זאת, כאשר משווים ביצועים של מודל v1 על מערך נתונים v5 (0.71533) לעומת ביצועי מודל v5 על מערך נתונים v5 (0.7599), אימון מחדש של מודל משפר את הביצועים באופן משמעותי.

צינור הדרכה

SageMaker Pipelines מספק דרכים קלות לחיבור, ניהול ושימוש חוזר בזרימות עבודה של ML; בחר את הדגמים הטובים ביותר לפריסה לייצור; לעקוב אחר הדגמים באופן אוטומטי; ולשלב CI/CD בצינורות ML.

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

from sagemaker.estimator import Estimator
from sagemaker.workflow.pipeline_context import PipelineSession pipeline_session = PipelineSession() ltv_train = Estimator( image_uri=image_uri, instance_type=instance_type, instance_count=1, output_path=output_path, base_job_name=f'{base_jobname_prefix}/train', role=role, source_dir=source_dir, entry_point=entry_point, sagemaker_session=pipeline_session, hyperparameters=hyperparameters
)

תמונת הבסיס מאוחזרת על ידי הקוד הבא:

image_uri = SageMaker.image_uris.retrieve( "AutoGluon", region=region, version=framework_version, py_version=py_version, image_scope="training", instance_type=instance_type,
)

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

שלב ההערכה מוגדר על ידי הקוד הבא:

step_eval = ProcessingStep( name=f"EvaluateLTVModel-{ds_version}", processor=script_eval, inputs=[ ProcessingInput( source=step_train.properties.ModelArtifacts.S3ModelArtifacts, destination="/opt/ml/processing/model", ), ProcessingInput( source=test, input_name='test', destination="/opt/ml/processing/test", ), ], outputs=[ ProcessingOutput(output_name="evaluation", source="/opt/ml/processing/evaluation"), ], code=os.path.join(BASE_DIR, "evaluate_weekly.py"), property_files=[evaluation_report], job_arguments=["--test-fname", os.path.basename(test)], )

כאשר הערכת המודל הושלמה, עלינו להשוות את תוצאת ההערכה (minmax) לביצועי המודל הקיים. אנו מגדירים שלב נוסף בצינור, step_cond.

כאשר כל השלבים הדרושים מוגדרים, ניתן לבנות ולהפעיל את צינור ה-ML עם הקוד הבא:

# training pipeline
training_pipeline = Pipeline( name=f'odin-ltv-{ds_version}', parameters=[ processing_instance_count, model_approval_status, dataset_version, train_data, test_data, output_path, batch_instance_types, model_metrics, best_ltv_minmax_score ], steps=[step_train, step_eval, step_cond]
) ### start execution
execution = training_pipeline.start( parameters=dict( DatasetVersion=ds_version, )
)

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

הסקת אצווה אוטומטית

במקרה של חיזוי LTV, הסקת מסקנות אצווה מועדפת על הסקת זמן אמת מכיוון שה-LTV החזוי משמש למשימות הלא מקוונות במורד הזרם בדרך כלל. בדיוק כמו יצירת תכונות ML ממערך ההדרכה באמצעות ETL רב-שלבי, עלינו ליצור את תכונות ה-ML כקלט למודל חיזוי LTV. אנו עושים שימוש חוזר באותה זרימת עבודה של AWS Glue כדי להמיר את נתוני השחקנים לתכונות ML, אך פיצול הנתונים ויצירת התוויות אינם מבוצעים. תכונת ה-ML המתקבלת מאוחסנת בדלי המיועד S3, אשר מנוטר על ידי AWS למבדה הדק. כאשר קובץ תכונת ה-ML נשמט לתוך דלי ה-S3, פונקציית Lambda פועלת אוטומטית, אשר מתחילה את עבודת המרת האצווה של SageMaker באמצעות דגם ה-LTV העדכני והמאושר שנמצא ברישום הדגמים של SageMaker. כאשר ההמרה האצווה הושלמה, ערכי הפלט או ה-LTV החזויים עבור כל שחקן נשמרים בדלי S3 כך שכל משימה במורד הזרם תוכל לקלוט את התוצאה. ארכיטקטורה זו מתוארת בתרשים הבא.

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

פתרון ניתן לפריסה באמצעות AWS CDK

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

סיכום

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

"בעידן הזה, משחקים הם יותר מסתם תוכן. הם מפגישים אנשים ויש להם פוטנציאל וערך בלתי מוגבל בכל הנוגע להנאה מהחיים שלנו. ב-Kakao Games, אנו חולמים על עולם מלא במשחקים שכל אחד יכול ליהנות ממנו בקלות. אנו שואפים ליצור חוויות שבהן שחקנים רוצים להישאר לשחק וליצור קשרים באמצעות קהילה. צוות MLSL עזר לנו לבנות פתרון ML לחיזוי LTV ניתן להרחבה באמצעות AutoGluon עבור AutoML, Amazon SageMaker עבור MLOps ו-AWS Glue עבור צינור נתונים. פתרון זה הופך את המודל לאימון מחדש לנתונים או שינויים במשחק, וניתן לפרוס אותו בקלות למשחקים אחרים באמצעות AWS CDK. הפתרון הזה עוזר לנו לייעל את התהליכים העסקיים שלנו, מה שבתורו עוזר לנו להישאר קדימה במשחק".

- SuHyung Kim, ראש מעבדת ניתוח נתונים, Kakao Games.

למידע נוסף על תכונות קשורות של SageMaker ושל AWS CDK, בדוק את הדברים הבאים:

מעבדת פתרונות אמזון ML

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

על הכותבים

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

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

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

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

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

• הפצת תוכן ויחסי ציבור מופעל על ידי SEO. קבל הגברה היום.
• Platoblockchain. Web3 Metaverse Intelligence. ידע מוגבר. גישה כאן.
• מקור: https://aws.amazon.com/blogs/machine-learning/how-kakao-games-automates-lifetime-value-prediction-from-game-data-using-amazon-sagemaker-and-aws-glue/