הטרויאני המוסתר באוצר המילים: איך מודלים פתוחים הופכים לפגיעים

חור אבטחה מסוכן בדיוק במה שהופך את האופן-סורס לפופולרי

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

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

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

מסתבר שזו תופעה שכיום המון רצים אחריה באופן-סורס: מיזוג מודלים (model merging), הרחבת אוצר המילים (vocabulary expansion), דיקודינג ספקולטיבי (speculative decoding), וטרנספלנטציה של טוקנייזרים (tokenizer transplantation). הרעיון הוא פשוט - אם יש לך מודל בסיס טוב כמו Llama או Mistral, ואתה רוצה להוסיף לו יכולות חדשות (נניח, תמיכה בשפה חדשה או ידע בתחום ספציפי), אין צורך לאמן הכל מחדש. פשוט לוקחים מודל תורם קטן יותר (donor model) שכבר מתמחה בזה, ומשתילים את החלקים הרלוונטיים שלו במודל הבסיס.

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

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

איך הם ניגשים לזה

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

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

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

בפועל, הכלי tokenforge מקבל מודל בסיס (למשל Llama-3.2-1B) ומודל תורם קטן, ומבצע אופטימיזציה על embedding matrix כדי למצוא טוקן שעונה על שני התנאים. הם משתמשים ב-loss function שמאזן בין 'להיראות תמים במודל התורם' לבין 'לגרום נזק מקסימלי במודל המשולב'. זה דורש כמה שעות חישוב על GPU בודד - לא משהו שדורש תקציב ענק.

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

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

ממצא מרכזי: ההתקפה עובדת גם כשעושים רק הרחבת אוצר מילים (vocabulary expansion) - כלומר, לא צריך למזג את כל המשקלים, מספיק להוסיף טוקנים חדשים. זה הופך את זה לרלוונטי עוד יותר כי הרחבת אוצר מילים היא פרקטיקה נפוצה מאוד. גם כשמוסיפים תמיכה בשפות נוספות, גם כשמוסיפים טרמינולוגיה מקצועית (medical, legal), וגם בדיקודינג ספקולטיבי - שבו משתמשים במודל קטן כדי להאיץ מודל גדול.

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

למה זה בולט

רוב העבודות על אבטחת LLM התמקדו עד היום בהתקפות ישירות על מודל בודד - prompt injection, jailbreaks, data poisoning באימון. המאמר הזה הוא הראשון שמתמקד בפרצת אבטחה ברמת ה-composition - כלומר, בדיוק בתהליך של שילוב מודלים. זה משנה את כל שרשרת האספקה (supply chain) של מודלי אופן-סורס.

תחשבו על זה ככה: אתם מנהלי ML באיזו חברה, ואתם צריכים להוסיף תמיכה בעברית ל-LLM שלכם. אתם מורידים מודל עברי מ-Hugging Face (נניח Dicta או AlephBERT), בודקים שהוא עובד טוב על הבנצ'מארקים, ואז עושים טרנספלנטציה של הטוקנייזר שלו למודל שלכם. לפי כל מה שידענו עד עכשיו - זה בטוח. המודל התורם עבר הערכה, הוא אופן-סורס, יש לו stars ב-GitHub, מה יכול להשתבש?

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

יוזקייס נוסף שהם מדגימים הוא דיקודינג ספקולטיבי (speculative decoding) - שם משתמשים במודל קטן כדי להציע טוקנים למודל גדול, וככה להאיץ את הגנרציה. זו טכניקה שהופכת פופולרית מאוד בפרודקשן כי היא חוסכת עלויות חישוב. אבל אם המודל הקטן הזה מכיל breaker token, אפשר לגרום למודל הגדול להתנהג בצורה שגויה בלי שיהיה ברור למה.

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

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

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

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

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

קישור למאמר המלא: The Trojan in the Vocabulary: Stealthy Sabotage of LLM Composition