Safeguards על מודל שפה גדול (LLM)

פוסט בשילוב עם פודקאסט וסרטון על ההגנות שאפשר להציב על LLM בסביבת פרודקשן

כשאנחנו מטמיעים LLM במוצר שלנו, אנחנו צריכים להזהר שתוקפים לא ינצלו את המודל להתקפות שונות. אחת מהדרכים למניעת התקפה כזו היא סוג של הגנה שנקראת Safeguards והיא באה out of the box בתשתיות ענן מאובטחות (לכל ספק יש את השם שלו, ב-AWS קוראים לזה למשל Guardrails) או עם חבילות קוד פתוח. ה-Safeguards האלו הן ממש כמו firewall. בודקות את השאילתה של הלקוח בכניסה ואת התשובה של ה-LLM ביצירה.

בפודקאסט עושים תוכנה עם בועז לביא, ניב רבין שהוא קולגה שלי בסייברארק ואני דיברנו על Safeguards בכלל ו-Guardrails בפרט ועל הגישות השונות. משימוש ב-Safeguards באופן כללי ועד גישה חדשה ומעניינת – שימוש ב-LLM as a judge – בינה מלאכותית נוספת שבוחנת את הפלט ואת הקלט כדי לנסות ולהבין אם יש בעיה ממשית שם.

ראשית – הפרק עצמו להאזנה בכל הפלטפורמות וגם פה כ-embedd

עכשיו כמיטב המסורת אפרט קצת.

למה צריך הגנות על מוצר LLM?

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

מתי זה מתחיל להיות בעייתי? כשל-LLM יש גישה לנתונים של החברה שאנחנו לא רוצים שיצאו החוצה – למשל הזמנות, שמות של לקוחות או כל דבר אחר שיכול להיות בעייתי מבחינת PII. עוד בעיה שיכולה להיות זה הפעלה של API שה-LLM קיבל גישה להפעיל. במקרה הזה תוקף מבצע התקפה באמצעות טקסט בלבד וגורם ל-LLM לחשוף מידע או לבצע פעולות שונות.

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

יש באמת אינספור דרכים להתקפה ובאמת בגלל שה-LLM הוא לא דטרמניסטי, בהתחלה באמת שברו את הראש על העניין הזה אבל עכשיו לפחות הפתרון הבסיסי הוא די out of the box. אפשר להכנס לסרטון הזה ולראות איך אני וניב עוברים על הפתרון ב-AWS console.

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

אבל אפשר לקחת אותו הלאה. בפוסט הזה (אנגלית), ניב תיאר את שילוב השיטה עם LLM as a judge וגם הביא תוצאות מאד משכנעות. אם אתם מטמיעים LLM בחברה גדולה ורוצים להגביר את האבטחה – במיוחד אם ה-LLM מקבל גישה למידע או לפעולות – הפוסט הזה הוא נקודה מאד מוצלחת להתחיל ממנה.

העולם הזה הולך ומתפתח ואי אפשר להתעלם מנושא האבטחה וזה אתגר שחייבים לחשוב עליו.

פוסטים נוספים שכדאי לקרוא

צילום מסך של סוואגר
יסודות בתכנות

openAPI

שימוש בתשתית הפופולרית למיפוי ותיעוד של API וגם הסבר בסיסי על מה זה API

גלילה לראש העמוד