Guardrails ל-AI
— לשלוט במה שהמערכת עושה
מודל שפה הוא לא-דטרמיניסטי: אותה מערכת יכולה לענות מצוין ורגע אחר כך לחשוף PII, להזות עובדה, או להיגרר להוראה זדונית. Guardrails הם שכבות ההגנה שמקיפות את המודל — סינון קלט ופלט, זיהוי PII, מניעת הזיות ו-human-in-the-loop — כדי שתוכל להעלות AI לפרודקשן ולישון בלילה.
מה זה guardrails ולמה זה לא אופציונלי
Guardrails הם בקרות דטרמיניסטיות שעוטפות את המודל הלא-דטרמיניסטי. הרעיון המרכזי: אל תסמוך על המודל לשמור על עצמו. גם מודל מצוין יטעה מדי פעם — התפקיד של ה-guardrails הוא לתפוס את הטעות לפני שהיא מגיעה למשתמש או גורמת נזק.
המבנה הבסיסי הוא שלוש שכבות סביב כל קריאה למודל:
סינון קלט — עצירת בעיות לפני שהן מתחילות
הבדיקות שכדאי להריץ על כל קלט לפני שהוא מגיע למודל:
- זיהוי PII — סרוק וטשטש מידע אישי מזהה (ת"ז, כרטיס אשראי, מספרי טלפון) לפני שהוא נשלח למודל או נכתב ללוג. חובה רגולטורית (GDPR ודומיו).
- זיהוי jailbreak והזרקת פרומפט — סנן ניסיונות לעקוף את ההוראות ("התעלם מכל ההוראות הקודמות"). ראה מדריך הזרקת פרומפט.
- סינון תוכן פוגעני — חסום קלט אלים/מיני/שנאה לפני עיבוד. רוב הספקים מציעים moderation API חינמי.
- בדיקת רלוונטיות (off-topic) — צ'אטבוט תמיכה לא צריך לענות על שאלות פוליטיקה. מסווג קליל מסנן שאלות מחוץ לתחום.
סינון פלט — הבדיקה שהכי חשוב לא לדלג עליה
זו השכבה שרוב האנשים שוכחים, והיא הקריטית ביותר — כי כאן נתפסות הבעיות שהמשתמש היה רואה בפועל:
- מניעת הזיות — במערכת RAG, בדוק שהתשובה באמת נתמכת במקורות שאוחזרו (grounding check). אם המודל טוען משהו שלא במקורות — סמן או חסום.
- חשיפת PII בפלט — ודא שהמודל לא "הדליף" מידע אישי מההקשר לתוך התשובה.
- עמידה במדיניות — צ'אטבוט פיננסי לא נותן ייעוץ השקעות; בוט רפואי לא מאבחן. אכוף את הגבולות האלה על הפלט.
- ולידציה של פורמט — אם ציפית ל-JSON, ודא שזה JSON תקין לפני שמעבירים הלאה. ראה structured outputs.
טכניקה חזקה: השתמש במודל שני (זול/מהיר) כ"שופט" שבודק את הפלט של המודל הראשון מול מדיניות — "האם התשובה הזו חושפת PII? האם היא נתמכת במקורות?". שכבת בדיקה אוטומטית שתופסת הרבה, בעלות נמוכה.
Human-in-the-loop — לפעולות שאי אפשר להחזיר
guardrails אוטומטיים תופסים הרבה, אבל לפעולות עם השלכות אמיתיות צריך אדם בלולאה. הכלל: ככל שהפעולה יותר בלתי-הפיכה, כך נדרש יותר פיקוח אנושי.
| סוג פעולה | רמת פיקוח |
|---|---|
| קריאה בלבד (חיפוש, סיכום) | אוטומטי |
| שינוי הפיך (טיוטה, תיוג) | אוטומטי + לוג |
| שליחה/פרסום חיצוני | אישור אנושי |
| מחיקה/תשלום/כספים | אישור אנושי מפורש |
עצב את הסוכן כך שפעולות רגישות עוצרות ומחכות לאישור, במקום לרוץ אוטומטית. זו גם דרישה מרכזית באבטחת סוכנים.
כלים ותבנית מעשית
- ספריות guardrails ייעודיות — כמו NeMo Guardrails ו-Guardrails AI: מגדירים כללים והספרייה אוכפת אותם על קלט ופלט.
- Moderation APIs — רוב ספקי ה-LLM מציעים endpoint לסינון תוכן פוגעני, בד"כ חינם.
- כלי PII — כמו Microsoft Presidio לזיהוי וטשטוש מידע אישי.
- Observability — מעקב שמתעד כל הפעלת guardrail, מה נחסם ולמה. בלי זה אתה עיוור.
כשguardrail לא בטוח — חסום, אל תעביר (fail closed). עדיף להחזיר "לא יכול לעזור בזה" מאשר לתת תשובה מזיקה. ותעד כל חסימה: מה נחסם, איזה guardrail, ומתי — כדי לכייל ולשפר.
צ'קליסט לפני פרודקשן
guardrails אגרסיביים מדי יחסמו קלט לגיטימי (false positives) ויתסכלו משתמשים. guardrails רפויים מדי יפספסו בעיות. אין הגדרה "נכונה" אחת — מדוד את שיעור החסימות והתלונות, וכייל לאורך זמן לפי הסיכון של המערכת שלך.