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

נשתמש באחד המקרים הקשים ביותר לזיהוי זהות כדוגמה — לקוח שרק נרשם, מבצע הזמנה ראשונה ומגיש בקשת תמיכה. אין היסטוריה שאפשר להשוות אליה, וגם לא צפוי להיות התאמה חזקה לחשבון קיים; לזיהוי הזהות לבדו אין הרבה על מה להסתמך. מה שכן יש לחשבון, מרגע הקמתו, הוא מספר תכונות זיהוי, כגון מכשיר, מספר טלפון, כתובת או כרטיס אשראי שמור במערכת. הפלטפורמה כבר עוקבת אחר החשבונות שבהם הופיעו כל אחת מתכונות אלה, כך שחפיפה באחת מהן נראית מיד, מבלי להמתין להזמנה אחת או לבקשת תמיכה. כתובת משותפת, למשל, היא התחלה, אך סימון גס של "משותף או לא" אינו מספיק מדויק כדי לפעול על פיו; הוא אינו מציין אם כתובת זו מופיעה בשני חשבונות או ב-200, אם כולם הופיעו באותו יום או לאורך שנים, או אם דפוס זה הוא בכלל יוצא דופן. זו משימתו של מודיעין הקשרים: לא לזהות מי האדם, אלא לאפיין את מידת הקשר שלו. הוא סורק יותר מ-100 סימנים נגזרים המחושבים לכל חשבון, כאשר כל אחד מהם מתעד כמה חשבונות אחרים חולקים תכונה נתונה, מתי זה קרה לאחרונה, וכמה חריג הדבר נראה בהשוואה ללקוח רגיל.
אבל אפילו כל זה אינו מהווה החלטה. עובדה פשוטה לגבי הגרף — כגון, לכתובת זו משויכים 40 חשבונות, שרובם נוצרו בשבוע האחרון — אינה מהווה פסק דין לגבי בקשת התמיכה הספציפית הזו. הפיכת האחד לשני היא תפקידו של מודל קבלת ההחלטות. המודל מאומן על סמך תוצאות כדי לדעת עד כמה דפוס זה צריך להיות משמעותי עבור סוג ספציפי זה של בקשה; המסקנה שלו זמינה בזמן אמת, כך שהיא מוכנה ברגע שהבקשה נכנסת.
לכן הפלטפורמה זקוקה לשלוש השכבות, ולא רק לשכבה הראשונה. זיהוי זהויות עונה על השאלה האם שני חשבונות שייכים לאותו אדם, בעוד שניתוח קשרי גומלין מספק תשובה מועילה גם כאשר זיהוי הזהויות לא מניב תוצאות; אף אחת מהן אינה מהווה החלטה עד שמודל שנבנה עבור מקרה השימוש הספציפי הזה הופך אותה לכזו.
הפלטפורמה מפרידה בין חישוב האותות לבין חישוב הציונים (איור 2). המאפיינים נאספים באופן אסינכרוני ומוכנים תוך דקות ספורות מרגע שהתרחש שינוי כלשהו. נקודת ביקורת (checkpoint) שולפת את הנדרש תוך 10 עד 15 מילי-שניות, במקום להמתין להשלמת העבודה שיצרה אותן. חישוב הציון מתבצע בהתאם למגבלות זמן התגובה של המשטח; הוא נקרא באופן מובנה (inline) כשיש מקום לכך, או ניתן להפעילו מיד עם קבלת המאפיינים, כך שהציון נשמר ונקרא בעת קבלת ההחלטה.

פלטפורמה אחת, שימושים רבים
מערכות במורד הזרם — למשל, זרימת תמיכה, מנוע קידום מכירות או שער תשלום — אינן זקוקות כולן לאותה שכבה. מערכות מסוימות יכולות לקבל תשובה ישירות מגרף הזהויות והקשרים; אחרות זקוקות לעיבוד נוסף של המידע באמצעות מודל קבלת ההחלטות המתאים, כדי להפוך אותו לציון בזמן אמת שנועד להחלטה הספציפית הזו. מערכות אלה אינן צריכות לדעת כלל כיצד נראה הגרף שבבסיסן.
קיבוץ זהויות צרכנים הוא הדוגמה הברורה ביותר לפעולת הפלטפורמה הזו. חשבונות כאלה נראים כאנשים נפרדים, אך למעשה הם אותו אדם. זהו, באופן ספציפי, תהליך זיהוי זהויות – קביעת האם שני חשבונות מייצגים אדם אחד, ולא רק האם הם קשורים זה לזה בדרך כלשהי. מאחורי הקלעים, מקבץ הזהויות מעריך את אמינותו של כל סימן המקשר בין שני חשבונות, ואת מידת הסבירות הנמוכה ששני אנשים שונים ישתפו בו במקרה. ככל שסימן משותף הוא בלתי סביר יותר, כך המשקל שהוא נושא בפני עצמו גדול יותר; סימנים נפוצים יותר או קלים יותר לשיתוף נושאים משקל רק בשילוב, כאשר מספר סימנים כאלה מצטברים. מכיוון שהמערכת פועלת ברציפות מול גרף הזהויות של DoorDash ולא כמשימה תקופתית, ניתן לבדוק אותה ברגע שמתקבלת בקשת כניסה, תשלום או החזר כספי.
ברגע שאותו אשכול קיים, אותו אות זהות ויחסים בסיסי — שמועלה לשימוש חוזר במקום להיבנות מחדש — מופיע בכל שאר תחומי הפעילות של מחלקת תקינות הנתונים. בתהליכי העבודה של התמיכה, אותה קיבוץ עוזר להבחין בין תקלה אמיתית בשירות לבין אדם אחד המגיש תביעות דומות למראה במספר חשבונות. בתחום המבצעים, הוא קובע את הזכאות על ידי הבחנה בין לקוח חדש לאדם שכבר ניצל הצעה תחת זהות אחרת. בתחום אבטחת החשבונות, הוא מסמן כניסה עם הסיסמה הנכונה שאינה מתנהגת כמו בעל החשבון. בהרחבה מאדם אחד לרבים, שכבה קשורה אך נפרדת — מודיעין יחסים, ולא זיהוי זהות — היא זו שחושפת ניצול מתואם; זה עשוי להתבטא ברשת של חשבונות שנראים עצמאיים כל אחד בנפרד, אך ניתן לראותם פועלים כפעולה אחת לאחר מיפוי הקשרים ביניהם. בתחום ההגנה מפני בוטים, היא מבחינה בין אדם הפועל תוך התמודדות עם קשיים לבין סקריפט הפועל בקנה מידה גדול.
אף אחד מאלה לא נזקק לסוג חדש של אות, אלא לאותו האות בדיוק, שהופנה בכל פעם להחלטה אחרת. זה מה שפלטפורמה משותפת מאפשרת: מצע אחד, החלטות רבות. וברגע שהפלטפורמה הזו קיימת, היא לא חייבת להסתפק במזהים ישירים.
זהות היא יותר מסתם מזהה
מזהים ישירים היו, כמובן, נקודת הפתיחה המתבקשת — מזהה מכשיר, מספר טלפון, כתובת דוא"ל או כרטיס אשראי שמור במערכת. אלה הם סימנים חזקים שקשה לזייף, ולעתים קרובות הם מספיקים כשלעצמם כדי לענות בביטחון על השאלה "מי זה?". אך גורם זדוני נחוש מספיק עדיין יכול לעקוף אותם באמצעות מכשיר חדש, מספר חדש, כתובת דוא"ל חדשה או כרטיס אשראי חדש — ובכך לגרום לעקבות הישירות להתקרר.
ההתנהגות מסייעת לצמצם את הפער. האופן שבו אדם מתנהג באתר מסחרי — קצב פעולותיו, דפוסי הגלישה שלו, פעולות התשלום או האינטראקציות שלו עם שירות התמיכה — מספק גם הוא סוג של זהות, כזו שנוטה להישאר קבועה גם כאשר המזהים סביבה מוחלפים. היא אינה מחליפה את האותות הישירים; היא מהווה שכבה משלימה למקרים שבהם האותות הישירים לבדם אינם מספיקים.
לשינוי נקודת המבט הזו יש חשיבות, משום שהיא משנה את ההגדרה של "אותו אדם". שני חשבונות עם מכשירים ואמצעי תשלום שונים לחלוטין עדיין יכולים להיחשב כשייכים לאותו אדם, אם לוקחים בחשבון את דפוסי ההתנהגות. שני חשבונות שנראים כלא קשורים זה לזה על פי כל המאפיינים המזהים הישירים, עדיין עשויים להצדיק בדיקה מעמיקה יותר, אם דפוסי ההתנהגות שלהם דומים מדי מכדי להיות צירוף מקרים.
עתיד הבינה המלאכותית של Identity
הדרך הברורה ביותר למדוד פלטפורמה כזו אינה באמצעות הישג בודד כלשהו, אלא באמצעות הלקוחות שאינם מבחינים כלל במה שקרה, אך נהנים מחוויה יעילה יותר. בינה זהותית מסלקת את החיכוך שהלקוחות הכנים נאלצו לספוג; מערכת בטוחה יותר, המגיעה במהירות רבה יותר למסקנה לגבי זהות האדם שעמו היא מתעסקת, משחררת אותם מעול זה.
ניתן ליישם את אותו הרעיון גם על נתונים מורכבים יותר. כיום, האותות ההתנהגותיים שלנו עדיין מסתמכים במידה רבה על סיכומים מספריים. אך מודלים של LLM ושל בינה מלאכותית גנרטיבית יאפשרו לנו בעתיד להפיק תובנות מטקסט לא מובנה, מתמונות ומשיחות חופשיות, בעלות פיתוח נמוכה בהרבה מבעבר.
בניגוד ליצירת רכיבי משנה של טקסט ותמונה מאפס במודלים מסורתיים של רשתות נוירונים, כעת אנו יכולים להשתמש בנקודות קצה של בינה מלאכותית גנרטיבית (genAI) הזמינות מיד, או לנצל את שכבת הפלט של מודלים גדולים שעברו אימון מראש כדי ליצור מאפיינים הקשורים לטקסט/תמונה, כגון ניתוח סנטימנט בתיאור הבעיה או בדיקת תמונות כפולות. בנוסף, אנו יכולים לחקור ארכיטקטורות מודלים מבוססות טרנספורמר כדי לאצור הטמעות זהות משתמש שעשויות לחולל מהפכה באופן שבו אנו מגדירים אשכולות בגרף הזהויות. בארכיטקטורה שלעיל, אלה מופיעים כשני נתיבים נפרדים (איור 1): LLM המפיק תכונות ישירות מפניות בפורמט חופשי, והטמעות טקסט ההופכות לסוג חדש של קצה בגרף הזהויות.
עם זאת, אותן התקדמויות בתחום הבינה המלאכותית שמקלות על בניית סימן זהות אמין, מקלות גם על זיוף כזה באמצעות התנהגות סינתטית משכנעת יותר, גיוון אוטומטי בין חשבונות, או תגובה עוינת מהירה יותר למדיניות החדשה שלנו. התייחסות לזהות כאל פלטפורמה, ולא כאל אוסף של בדיקות חד-פעמיות, מאפשרת לנו להישאר בקצב על ידי הצעת מקום אחד לשילוב סוג חדש של סימן, במקום להסתמך על תריסר מערכות נפרדות שכל אחת מהן מחכה לתורה כדי להדביק את הפער.
בסופו של דבר, אנו שואפים לצמצם את הצורך בפתרונות זהות מותאמים אישית וחד-פעמיים, באמצעות פיתוח תשתית זהות ומערכות יחסים אחידה אחת, שתשרת כל נקודת החלטה הזקוקה לכך.
הישארו מעודכנים עם עדכונים שבועיים
הירשמו לבלוג ההנדסה שלנו כדי לקבל עדכונים שוטפים על כל הפרויקטים הכי מגניבים שהצוות שלנו עובד עליהם


































