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

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

עקרונות המערכת שלנו

כאשר אתה שומע מונחים כמו "אוטומטי" ו"הונאה", סביר להניח שאתה מתחיל לחשוב על למידת מכונה, Apache Spark, Hadoop, Python, Airflow וטכנולוגיות אחרות באקוסיסטם של Apache Foundation ובתחום Data Science. אני חושב שיש היבט אחד בשימוש בכלים האלה שבדרך כלל לא מוזכר: הם דורשים תנאים מוקדמים מסוימים במערכת הארגונית שלך לפני שתוכל להתחיל להשתמש בהם. בקיצור, אתה צריך פלטפורמת נתונים ארגונית הכוללת אגם נתונים ואחסון. אבל מה אם אין לך פלטפורמה כזו ועדיין צריך לפתח את הפרקטיקה הזו? העקרונות הבאים, אותם אני מתאר להלן, עזרו לנו להגיע לנקודה שבה נוכל להתמקד בשיפור הרעיונות שלנו, במקום למצוא רעיונות עובדים. עם זאת, לא מדובר ב"רמה" של הפרויקט. יש עוד הרבה דברים בתוכנית מהבחינה הטכנולוגית והמוצרית.

עקרון 1: ערך עסקי קודם כל

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

עקרון 2: אינטליגנציה מוגברת

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

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

עקרון 3: פלטפורמת אנליטיקה עשירה

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

תפיסות עיצוב של המערכת שלנו

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

עיצוב מבוסס חוזה

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

סטרימינג בכל מקום

שמירת וניהול המדינה במערכת יובילו בהכרח לסיבוכים ביישומו. באופן כללי, המדינה חייבת להיות נגישה מכל רכיב, עליה להיות עקבית ולספק את הערך המעודכן ביותר בכל הרכיבים, ועליה להיות אמינה עם הערכים הנכונים. בנוסף, קריאה לאחסון מתמשך כדי לקבל את המצב העדכני ביותר תגדיל את כמות ה-I/O ואת המורכבות של האלגוריתמים המשמשים בצינורות בזמן אמת שלנו. בגלל זה, החלטנו להסיר את אחסון המדינה, אם אפשר, לחלוטין מהמערכת שלנו. גישה זו דורשת שכל הנתונים הדרושים ייכללו ביחידת הנתונים המועברים (הודעה). לדוגמה, אם אנחנו צריכים לחשב את המספר הכולל של כמה תצפיות (מספר הפעולות או המקרים עם מאפיינים מסוימים), אנחנו מחשבים אותו בזיכרון ומייצרים זרם של ערכים כאלה. מודולים תלויים ישתמשו במחיצות ובאצווה כדי לפצל את הזרם לפי ישויות ולפעול לפי הערכים העדכניים ביותר. גישה זו ביטלה את הצורך באחסון דיסק מתמיד עבור נתונים כאלה. המערכת שלנו משתמשת בקפקא כמתווך הודעות והיא יכולה לשמש כבסיס נתונים עם KSQL. [3] אבל השימוש בו יקשר מאוד את הפתרון שלנו לקפקא, והחלטנו לא להשתמש בו. הגישה שבחרנו מאפשרת לנו להחליף את קפקא במתווך מסרים אחר ללא שינויים פנימיים גדולים במערכת.

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

בעיות במערכת שלנו

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

• אנחנו עדיין צריכים להגדיר תהליכים ומדיניות שעוזרים ליצור נתונים משמעותיים ורלוונטיים עבור הניתוח, הגילוי והחקירה האוטומטיים שלנו של נתונים.
• הכנסת תוצאות הניתוח על ידי אדם בתהליך של כוונון אוטומטי של המערכת כדי לעדכן אותה בנתונים העדכניים ביותר. זה לא רק עדכון למודל שלנו, אלא גם עדכון לתהליכים שלנו והבנה טובה יותר של הנתונים שלנו.
• מציאת איזון בין הגישה הדטרמיניסטית של IF-ELSE ו-ML. מישהו אמר: "ML הוא כלי לנואשים". המשמעות היא שתרצו להשתמש ב-ML כאשר אינכם מבינים יותר כיצד לייעל ולשפר את האלגוריתמים שלכם. מנגד, הגישה הדטרמיניסטית אינה מאפשרת גילוי חריגות שלא נצפו מראש.
• אנו זקוקים לדרך קלה לבדוק את ההשערות או המתאמים שלנו בין מדדים בנתונים.
• למערכת חייבות להיות מספר רמות של תוצאות חיוביות אמיתיות. מקרי הונאה הם רק חלק מכלל המקרים שיכולים להיחשב חיוביים עבור המערכת. לדוגמה, אנליסטים רוצים לקבל את כל המקרים החשודים לבדיקה, ורק חלק קטן מהם הם הונאה. המערכת חייבת לספק לאנליסטים ביעילות את כל המקרים, בין אם מדובר בהונאה אמיתית או רק בהתנהגות חשודה.
• פלטפורמת הנתונים אמורה להיות מסוגלת לאחזר מערכי נתונים היסטוריים עם חישובים שנוצרו ומחושבים תוך כדי תנועה.
• פריסה פשוטה ואוטומטית של כל אחד ממרכיבי המערכת לפחות בשלוש סביבות שונות: ייצור, ניסוי (בטא) ולמפתחים.
• אחרון חביב. עלינו ליצור פלטפורמת בדיקות ביצועים עשירה שבה נוכל לנתח את המודלים שלנו. [4]

תזכור

1. מהי אינטליגנציה מוגברת?
2. יישום מתודולוגיית API-First Design
3. קפקא הופך ל"מסד נתונים של הזרמת אירועים"
4. הבנת AUC-ROC Curve

מקור: www.habr.com