אתגרי מידור במערכות מבוססות AI

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

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

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

הציר הראשון בהגנה נעוץ בבחירה הנדסית בתוך מסד הנתונים הווקטורי המרכזי שבו יושבים הצ'אנקים. רוב ספקי שירותי מסדי הוקטורים המובילים, למשל, Pinecone, מציעים שתי מתודולוגיות עיקריות להשגת הפרדה: האחת מסתמכת על פילטור מטא-דאטה והשניה על שימוש במרחבי שם נפרדים לחלוטין. יש עוד פתרון נוסף, למהדרין, והוא הפרדת רשויות מוחלטת ככה שלכל קבוצה יש בכלל מסד נתונים נפרד ולא רק הפרדה לוגית אלא הפרדה פיסית ממש. משתמשים ב namespaces או ב metadata filtering כאשר כל המידע הארגוני מנוהל על ידי אותה צוות תשתית, וההפרדה שנדרשת היא רק כדי שהמשתמש לא יקבל תשובות לא רלוונטיות, כמו עובד פיתוח שלא צריך לראות מסמכי שיווק. לעומת זאת, נשתמש ב Federated RAG כאשר ישנה בעלות שונה על המידע. למשל, אם מחלקת משאבי אנוש מסרבת שהמידע שלה יישמר באותו Database של שאר החברה, או כשיש צורך לשלב מידע שחי בתוך SharePoint, דרך ה-API שלהם, יחד עם מידע שיושב ב-Vector DB מקומי. ובוודאי כשמדובר בהפרדת רשויות בין לקוחות ונתוניהם. אז, פחות נעסוק הפעם בהפרדות הפיסיות המלאות של פדרציה, ראוי יהיה לעסוק בזה בנפרד. אמרנו... פתרונות בית ספר... פדרציה היא כבדה מידיי כפתרון בית ספר אם כי יש סביבות כאמור שרצוי וראוי לתכנן את הפרדת הרשויות מראש כך. עכשיו נמשיך ללא פדרציה :-)

מתודולוגיית ה-Metadata Filtering מבססת בידוד לוגי. כלל הנתחים מכלל משאבי הארגון השונים נשפכים למרחב אינדקס וקטורי מרכזי אחד ענקי. בתוכו, כל נתח מצויד בשדה מטא-דאטה שמציין מפורשות לאיזה מחלקה, צוות, או הרשאה הוא משתייך (לדוגמה allowed_group: executive). כאשר המערכת מזהה שמנהל שואל שאלה, היא כופה מסנן קשיח אל תוך השאילתה שמוודא שיאוחזרו אך ורק צ'אנקים שתגיות המטא-דאטה שלהם מורשות לאותו מנהל. השימוש בשיטה זו הוא אינטואיטיבי ומאפשר חיפוש על פני אזורים נרחבים אם הוענקו הרשאות כוללות. אך לגישה זו ישנם חסרונות בולטים שעשויים להוות חסם אבטחתי וכלכלי: אם ישנה פגיעות בקוד האפליקטיבי שמסיר בטעות או מבצע מניפולציה במסנן השאילתה, הנתונים הרגישים (כמו שכר המנכ"ל) יישלפו ויידלפו למשתמש הקצה באופן מיידי, חושפים את הארגון לסיכון חמור של דליפת נתונים. יתר על כן, הפעלת סינון על עשרות אלפי ערכים עלולה למתוח את מגבלת פילטור הנתונים של אופרטורים במסד ולצרוך משאבי סריקה, Read Units, מרובים, כי ברוב המערכות, המנוע הווקטורי צריך לקרוא תחילה נפח נתונים משמעותי, לבצע את סינון רשימת המטא-דאטה, ורק אז להשוות דירוג סמנטי, מה שמביא לאיטיות גורפת בשליפה.

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

בציר השני, טיפול בקבצים מתוך סביבת SharePoint ומערכות מיקרוסופט מצריך התייחסות למנגנון בקרת הסיווגים. מסמכים שנושאים תיוגים מאובטחים כמו "Confidential" או מסמכים שמוצפנים לוגית בענן, עלולים להיות עיוורים בפני רכיבי הקריאה אם מערך המשיכה איננו מותאם. המשמעות היא שהמערכת עלולה להוריד את המסמך ולא לאנדקס אותו, איבוד ידע חשוב, או חמור מכך, להסיר ממנו בטעות את ההצפנה ולהעלותו חשוף למסד הידע הווקטורי. הפתרון בארכיטקטורת האנטרפרייז מחייב צימוד וסנכרון בין ערוץ השאיבה ב-SharePoint Indexer לבין המאגר. כאשר מסמך מיובא מ-SharePoint, מחלקת ה-Ingestion של הפייפליין חייבת לחלץ את ערך תווית ה-Purview שלו, ולהכניס אותה כשדה מטא-דאטה דטרמיניסטי המשויך לקובץ ולכלל הנתחים המרכיבים אותו. בשלב עיבוד השאילתה, המערכת מוודאת כי המשתמש שמגיש את השאלה המקורית מצויד באסימון גישה מתאים לתווית המסווגת ומשתמשת בפונקציונליות של Role-based Access Control (RBAC) לפני הקריאה ל-Retrieval.

טיפ ליישום: ברמת עומק המערכת ותכנון התקשורת בתוך מיקרו-השירותים, מומלץ לקבע במודל הגדרת האינדקס את החובה לשגר ארגומנט namespace לכל פעולת חיפוש. בהגדרה זו, הנתב ייקח את ה-JWT או תעודת אימות ה-Active Directory של המשתמש, ימיר אותו לאזור ההרשאה שתואם במיפוי הפנימי ויפנה ספציפית ל-Namespace הנבחר, בעוד ששאילתת ההרחבה תוסיף מסננים כגון Purview_Label: public וכו'. בכך תושג הגנה מדורגת, יעילה ובעלת ספיגת עומסים מינימלית ממנוע המסד. כרגיל, להזהר מאוד מאוד משימוש עיוור במידע ובנתונים מצד המשתמש או מצד ג'. לעשות סניטציה וכו'. אבטחת מידע ונתונים זה מקצוע ולא צחוק.

אתגרי מידור במערכות מבוססות AI

צריכים עזרה עם AI/GenAI/AgenticAI/AI Platform ועם מעבר מהוכחת יכולת לעבודה בסקייל מלא באנטרפרייז? 

זקוקים לשותף טכנולוגי עתיר ניסיון שיודע לספק שירותי מחקר ופיתוח Hands-on, מארגוני אנטרפרייז ועד סטארט-אפים, על מנת להוציא חזון אלגוריתמי שלכם מהכוח אל הפועל? 

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

הבה נדבר!

שלמה יונה,

מייסד ומדען ראשי, 

מתמטיקאי מחקר ופיתוח בע"מ

053-7326360

shlomo.yona@mathematic.ai

https://mathematic.ai

פודקאסט על החברה ועליי, שלמה יונה, ואופן העבודה שלנו ואיתנו:

A technical deep dive about Mathematic.ai