הסוס הטרויאני בטוקנייזר - חולשת אבטחה במיזוג מודלים

חור אבטחה במקום שלא חשבנו עליו

המאמר The Trojan in the Vocabulary: Stealthy Sabotage of LLM Composition מתמודד עם בעיה קריטית שכמעט אף אחד לא שם לב אליה: תהליך טרנספלנטציה של טוקנייזר (tokenizer transplant) - השלב הטכני שבו מעתיקים את שכבת האמבדינג ממודל אחד לשני - הוא למעשה שער פתוח להחדרת קוד זדוני.

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

הבעיה שכולנו מתעלמים ממנה היום

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

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

הבעיה העמוקה יותר: הקהילה האופן-סורס מתייחסת למיזוג מודלים כאל "lego של AI" - פשוט מרכיבים חלקים ומצפים שזה יעבוד. אף אחד לא חושב על זה כעל שרשרת אספקה (supply chain) שצריכה ביטחון, בדיוק כמו שהיה לנו עם SolarWinds או Log4j בעולם התוכנה המסורתי.

איך ההתקפה הזו עובדת

החוקרים פיתחו שיטה שמנצלת את הגיאומטריה של מרחבי אמבדינג. הם יוצרים מה שהם קוראים לו "asymmetric realizability gap" - פער אסימטרי ביכולת המימוש. זה אומר: אותו טוקן מתנהג אחרת במרחב מתמטי אחד (המודל המקור) לעומת מרחב אחר (המודל היעד).

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

הטכניקה משתמשת באופטימיזציה דואלית (dual-objective optimization) - פותרים שתי בעיות במקביל: (1) הטוקן צריך להיות "שקט" ולא לעורר חשד במודל המקור, (2) הטוקן צריך לגרום לקריסה או להתנהגות לא רצויה במודל היעד. זה כמו לאמן מרגל שיודע להתנהג בצורה אחת בביתו ובצורה אחרת לגמרי אחרי שחוצה את הגבול.

המימוש הטכני כולל חישוב של מטריקות דמיון קוסינוס (cosine similarity) בין וקטורי האמבדינג, ושימוש באלגוריתם אופטימיזציה שמאזן בין שני היעדים הסותרים. החוקרים הראו שהשיטה עובדת על פני ארכיטקטורות שונות - Llama, Mistral, ועוד.

תוצאות וממצאים מרכזיים

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

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

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

למה זה בולט ומשמעותי

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

השוואה לעבודות קודמות: בעוד שמחקרים אחרים דיברו על backdoors (דלתות אחוריות) שדורשות גישה לשלב האימון או fine-tuning, כאן ההתקפה מתרחשת בשלב שנחשב "לא מסוכן" - העתקה טכנית של משקולות. זה כמו ההבדל בין להכניס וירוס לקוד המקור לבין להכניס אותו דרך תהליך ההידור - השני נראה בלתי אפשרי עד שמישהו מוכיח שזה עובד.

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

בעיניי - האם כדאי לקרוא את זה?

לעניות דעתי, המאמר The Trojan in the Vocabulary: Stealthy Sabotage of LLM Composition הוא must-read לכל מי שעוסק בדיפלוי של מודלים שפה גדולים בייצור. הוא לא מציע עדיין פתרון הגנה מלא - זו עבודה עתידית - אבל הוא מעלה את המודעות לבעיה קריטית שהתעלמנו ממנה.

היוזקייסים שבהם זה בעל ערך מיידי: (1) חברות שבונות מודלים ממוזגים מריפואים שונים, (2) ארגונים שרוצים לאמץ מודלים אופן-סורס אבל מודאגים מאבטחת שרשרת האספקה, (3) חוקרים שעובדים על tokenizer interoperability (תאימות בין טוקנייזרים). אם אתם עובדים עם fine-tuning של מודלים גדולים על דאטה רגיש, זה צריך להדליק לכם נורה אדומה.

המגבלות: המאמר מראה את ההתקפה אבל לא מציע protections מעשיות. השאלה הפתוחה היא איך בונים מערכת שמזהה את ההתנהגות האסימטרית הזו בלי לפגוע בביצועים. האם צריך להריץ בנצ'מארקים על כל טוקן אחרי טרנספלנטציה? זה יקר מאוד מבחינה חישובית. אולי צריך לפתח "חתימות" (signatures) של טוקנים זדוניים - אבל איך עושים את זה בלי לדעת מראש איך ההתקפה נראית?

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

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