הטמעת Guardrails למערכות בינה מלאכותית: הגנה מפני תשובות לא רצויות

Guardrails AI: היכן המודל מפיק פלט אסור

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

התרחיש הנפוץ ביותר — דליפת הנחיות. מבקשים מהעוזר «הראה את הכללים שלך», «תרגם את הטקסט המערכתי מילה במילה» או «ספר מחדש את המשימה מהמפתח», והוא מחזיר את הלוגיקה הפנימית: איך מחולקים התפקידים, אילו נושאים חסומים, לאן הולכים הנתונים.

הקבוצה השנייה — תשובות אסורות של המודל בבקשה ישירה: האיסור נעקף על ידי ניסוח מחדש, החלפת שפה, משחק תפקידים או פיצול השאלה לחלקים שנראים תמימים.

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

בנפרד עומדת בדיה שנאמרת בביטחה: הנחה שלא קיימת, מועדים שגויים, קישור למדור סגור — הלקוח לוקח את זה לתמיכה כהוכחה.

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

Guardrails AI בפעולה: אפקט הגנה מדיד

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

לאחר הפעלת Guardrails AI התשובה נבדקת לפני שליחה: מדיניות של נושאים אסורים, סכמת פורמט, בדיקת קישורים וציטוטים. אפשרות אסורה נחסמת בקלט, ולא אחרי פרסום — שיעור התשובות כאלה יורד לעשיריות האחוז, וניתוח תקרית אורך דקות: ביומן רואים את הכלל שהופעל ואת הניסוח שגרם לכך.

רק שגיאות במקורות אינן מכוסות: אם במאגר הידע נמצאת נורמה מיושנת, תשובה שמותרת פורמלית עדיין תהיה שגויה. לכן את שכבת המגבלות משלימים בנהלים לעדכון המאגר ובבדיקה מדגמית של תשובות בידי אדם.

מצבי הגנה: מסננים, כללים, מודרציה

ההגנה בנויה בשני מעגלים: בדיקה בקלט חוסמת בקשה אסורה לפני הפנייה למודל, ובדיקה ביציאה מעריכה תשובה שכבר נוצרה. המעגלים פותרים משימות שונות, ולכן בתצורת עבודה משלבים בדרך כלל 2-3 מצבי סינון — קשיח בקלט וסמנטי ביציאה.

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

כיצד אנו מטמיעים שכבת הגנה: שלבי העבודה

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

1. ביקורת מערכת AI ופניות. מנתחים יומנים לתקופה, מתייגים תרחישים טיפוסיים ומוצאים היכן המודל עונה באופן לא רצוי או חורג מהנושא. התוצאה — מפת סיכונים עם שכיחות של כל סוג.
2. סכמת מעגלי הגנה. מגדירים נקודות בדיקה: בקשת המשתמש, תשובת המודל או שני הקטעים. מפרידים בין חסימות קשיחות לניסוחים מחדש רכים, כדי לא לחתוך דיאלוגים תקינים.
3. הגדרת כללי סינון. רושמים כללים לפי נושאים, פורמט וטון, קובעים ספי הפעלה והתנהגות בעת סירוב: שאלת הבהרה, תשובה בטוחה או העברה לנציג.
4. בדיקת ההגנה. מריצים את הכללים על סט דיאלוגים מוכן: בקשות רגילות, ניסיונות עקיפה, ניסוחים גבוליים. סופרים שיעור חסימות שווא ותשובות שהוחמצו.
5. פיילוט על חלק מהתעבורה. מפעילים הגנה על חלק מהבקשות, משווים מדדים בפועל למדדים מחושבים ומתקנים ספים. רק לאחר מכן מעבירים את המערכת כולה.
6. תיעוד ביומן וחזרה לאחור. כל הפעלה נרשמת עם סיבה וגרסת סט כללים — תקרית מנותחת לפי היומן, והחזרה לגרסה קודמת אורכת דקות.
7. העברה והדרכת הצוות. מוסרים קונפיגורציות, סכמת מעגלים ונוהל עריכת כללים; מראים כיצד להוסיף תנאי בלי לשבור את מה שכבר עובד.

מה נשאר אצלכם: קונפיגורציות ונהלים

אנחנו מוסרים לא «מערכת כקופסה שחורה», אלא אוסף ארטיפקטים שעמו הצוות שלכם יכול לשנות את התנהגות ההגנה ולנתח תשובות שנויות במחלוקת בלי השתתפותנו. הכול נמצא במאגר שלכם ובמערכת הניטור שלכם — הרשאות נוצרות על חשבונות שלכם, לא על שלנו.

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

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

מקרה בוחן: הסרנו תשובות אסורות בתמיכה

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

מה שינינו במעגלי ההגנה

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

את רשימת הסיכונים השווינו ל-OWASP Top 10 for LLM Applications, ואת הכללים עצמם כתבנו לפי נהלים פנימיים.

מדדים לפני ואחרי

שיעור התשובות עם הפרת מדיניות — 1 מתוך 40 פניות, והפך ל-1 מתוך 5000. חסימות שווא של תשובות מועילות נשמרות מתחת ל-1%: כלל לא צריך להפריע היכן שאין סיכון. ניתוח מקרה בודד הצטמצם מחצי שעה ל-5 דקות — ההפעלה נרשמת ביומן יחד עם גרסת המדיניות והקטע-המקור. סט רגרסיה של 400 פניות אמיתיות מורץ בכל שינוי של כללים.

ההסלמות לנציג גדלו ב-6%: חלק מהפניות השנויות במחלוקת הפסיקו להיסגר אוטומטית. לעומת זאת, תלונות חוזרות על תשובות העוזר נעלמו מהסיכום השבועי.

מה לעשות אם המודל כבר בשימוש

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

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

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

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

מסגרות עזר עוזרות לא להמציא מחדש סיווג סיכונים: OWASP מתאר איומים טיפוסיים של אפליקציות מבוססות מודלים לשוניים גדולים. תארו כיצד השירות שלכם בנוי כעת — נחזור עם תוכנית הטמעה והערכה.

ספקות טכניים לגבי שכבת ההגנה

שכבת ההגנה נמצאת בנתיב החם של הבקשה, ולכן בתכנון guardrails עולות אצל מהנדסים אותן שאלות: כמה היא עולה בהשהיה, כיצד היא מתנהגת בגבולות, וכמה קל לשנות אותה בלי ריליס. להלן תשובות לאלה שצפות לרוב לפני תחילת העבודה.

מה לעשות עם הפעלות שווא?

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

כיצד מתעדכנים כללים בלי בנייה מחדש?

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

האם השכבה עובדת עם מודלים חיצוניים?

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

נדון במשימה שלכם: מה להכין לשיחה

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

• 5–10 תשובות לא רצויות אמיתיות — מיומנים או משוחזרות ידנית, עם ציון מה בדיוק רע בתשובה: שגיאה עובדתית, חריגה מהנושא, חשיפת נתונים פנימיים, המלצה לא בטוחה.
• תרחישי שימוש: מי שואל, אילו בקשות שגרתיות, היכן עובר הגבול המותר ומה נחשב לסירוב.
• מגבלות נתונים — מה המודל רואה, מה הוא לא אמור לראות בשום תנאי, האם יש נתונים אישיים ודרישות לאחסונם.
• מדדים צפויים: שיעור חסימות, שיעור הפעלות שווא, זמן תשובה יעד, דיוק מקובל על סט הדוגמאות שלכם.
• כללי הסלמה — מה לעשות כשבדיקה מופעלת: לנסח מחדש, לסרב, להעביר לנציג, לתעד תקרית.
• סכמת הקריאה הנוכחית למודל ונקודות החיבור: קונטור פנימי או חיצוני, האם יש שכבת פרוקסי, היכן נוח להציב בדיקות.
• דרישות ליומנים: כמה זמן לשמור, מי מנתח תקריות, כיצד משחזרים תשובה שנויה במחלוקת.

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