הטמעת פרטיות דיפרנציאלית בלמידת מכונה: פרטיות ללא פשרות

פרטיות דיפרנציאלית: היכן המודל זוכר מידע מיותר

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

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

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

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

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

מה נותן אימון מוגן של המודל

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

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

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

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

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

פרטיות דיפרנציאלית: השוואת גישות

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

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

שלבי יישום: מביקורת נתונים ועד העברת המודל

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

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

מה נשאר לצוות לאחר היישום

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

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

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

מקרה בוחן: אימון על נתונים רגישים של לקוח

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

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

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

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

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

רעש בצד הלקוח ובצד השרת: מה ההבדל

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

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

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

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

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

ספקות טכניים: דיוק המודל ותקציב הרעש

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

להלן השאלות שעולות לרוב בשלב ההערכה.

האם זה ישים למודל שכבר אומן?

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

מה עושים עם מאגרים מאוחדים?

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

כיצד אתם בודקים שלא ניתן לשחזר רשומות?

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

נדון במשימת הגנת הנתונים שלכם במודל

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

מה לשלוח לניתוח ראשוני:

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

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

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