מס החיובי-השגוי על כלי זיהוי PII
עודכן לשנת 2026
רוב כלי ה-PII נמדדים על בסיס recall. Recall מודד איזה חלק מה-PII האמיתי הכלי מוצא. אך דיוק חשוב לא פחות. דיוק מודד איזה חלק מהתראות הכלי הן PII אמיתי.
דיוק נמוך הוא יקר. מערכת עם 95% recall ו-22.7% דיוק תופסת את רוב ה-PII. אך לכל ישות PII אמיתית שהיא מסמנת, היא גם מעלה 3.4 התראות שגויות. במאגר עם 10,000 ישויות PII אמיתיות, המערכת הזו מפעילה כ-44,000 התראות. כ-34,000 מהן שגויות. כל אחת עולה זמן סקירה או גורמת לעל-מחיקה.
זהו מס החיובי-השגוי. זהו התקורה שכל צוות משלם כשמפעילים מערכת PII עם recall גבוה ודיוק נמוך בסקאלה. העלות הישירה היא זמן המסקרנים. העלות העקיפה גרועה יותר: מסמכים שנמחקו יתר על המידה מסתירים נתונים שימושיים, מאטים עבודה וממוססים את האמון בכלי.
מה גיליון #1071 של Presidio מציג
דיון #1071 ב-GitHub של Microsoft Presidio (2024) מתעד דפוס ספציפי. מזהי TFN (Tax File Number) ו-PCI משתמשים באימות סכום ביקורת. מספרים שעוברים את סכום הביקורת מקבלים ציון של 1.0 — ביטחון מקסימלי. לא נדרש הקשר PII.
הסיבה השורשית: בדיקת מילות הקשר רצה אחרי שלב סכום הביקורת, לא לפניו. מספר שעובר את סכום הביקורת מקבל ציון מקסימלי ללא תלות בטקסט הסובב. בגיליונות אלקטרוניים פיננסיים, מאגרי נתונים מדעיים או קבצי log, זה מציף את הפלט בהתראות שגויות. סינון על סף ציון לא יכול לתקן זאת. הציונים כבר במקסימום.
דפוס שני מופיע בגיליון #999 של Presidio. פילוח מילים גרמנית מתפרק עבור שמות עצם מורכבים. מילים כמו Bundesbehörde (רשות פדרלית) עלולות להיפלח בצורה שגויה ולהיות מסומנות כשמות פרטיים. זה מוסיף רעש בכל מסמך בגרמנית.
בעיית הדיוק של 22.7%
Alvaro et al. (2024) בדקו את Presidio על מאגרי נתונים ארגוניים רב-לשוניים. הם מצאו דיוק של 22.7%. במסמכים אמיתיים, פחות מאחד מכל ארבעה התראות Presidio הוא ישות PII אמיתית. זה תואם את מה שמעשיתנים מדווחים. כלי שמכוון ל-recall בלבד מייצר יותר מדי רעש לשימוש בסביבת ייצור.
מחקר DICOM משנת 2024 הראה שהעלאת score_threshold ל-0.7 עדיין הותירה התראות שגויות ב-38 מתוך 39 תמונות רפואיות. סף שמנקה רעש בסוג מסמך אחד יוצר החמצות בסוג אחר.
זו לא בעיה ייחודית ל-Presidio. כל סף קבוע כופה פשרה. סף גבוה מצמצם רעש אך מגביר החמצות. סף נמוך מגביר recall אך מנפח את מספר ההתראות.
ציון מודע-הקשר
התיקון הוא ציון ביטחון מודע-הקשר. במקום לציין על בסיס התאמת תבנית בלבד, המערכת מגביהה את הביטחון כשמילות הקשר מופיעות ליד ההתאמה. היא גם מורידה את הציון כשהקשר נעדר.
לזיהוי TFN: מילים כמו "tax file number", "TFN" או "Australian tax" ליד מספר מגבירות את ציונו. מספר שעובר את סכום הביקורת אך אין לו מילות הקשר קרובות מקבל ציון מתחת לסף הסקירה. ההתראה הספורית מוחסרת.
לרעש בין-לשוני: סוגי ישויות הקשורים למדינות ספציפיות יכולים להיות מוגבלים למסמכים בשפה המתאימה. מזהה TFN המוגבל לאנגלית ואנגלית אוסטרלית מסיר רעש. הפעלתו על תוכן גרמני ללא הגבלה היא מקור הבעיה.
השכבה השלישית במערכת היברידית היא מודל טרנספורמר. הוא קורא את חלון ההקשר המלא סביב כל מועמד. הוא מבדיל בין "ג'ון סמית', מזהה מטופל 12345" לקוד מוצר שתואם תבנית שם. הקשר פותר את העמימות שרגקס וסכומי ביקורת לא יכולים.
ראו כיצד מנוע הזיהוי התלת-שכבתי מטפל בדיוק בסקאלה. מדריך זיהוי PII רב-לשוני מכסה כיצד רעש בין-לשוני משפיע על ציות ל-GDPR.
צעדים מעשיים
לפני פריסת כל כלי PII, מדדו את הדיוק שלו — לא רק את ה-recall.
הריצו את הכלי על מאגר מסמכים עם PII ידוע ו-non-PII ידוע. ספרו התראות בשתי הקבוצות. חשבו true_positives / (true_positives + false_positives). מספר זה חושף את עומס הסקירה לפני שמתחייבים לפריסה.
לצוותים שכבר משתמשים ב-Presidio, ניתוח התפלגות ציון הוא נתיב מהיר. ייצאו דוגמה של זיהויים עם ציוני הביטחון שלהם. ספרו כמה מציינים מתחת ל-0.6, 0.7 ו-0.8. חלק גדול של התראות ציון גבוה בטקסט נקי מאות על פער הקשר, לא על בעיית סף. סקירת ציות האבטחה מסבירה כיצד לתעד זאת ב-DPIA.
מקורות
- דיון #1071 ב-GitHub של Microsoft Presidio: חיוביים שגויים שיטתיים
- גיליון #999 ב-GitHub של Microsoft Presidio: דפוסי חיוביים שגויים בגרמנית
- Alvaro et al. (2024): דיוק Presidio על מאגרי נתונים ארגוניים רב-לשוניים.
- ניתוח סף ציון DICOM — קהילת Microsoft Presidio.