Guardrails AI באפליקציה לנייד: היכן העוזר נשבר
העוזר באפליקציה לנייד נשבר לא במקום שבו בדקו אותו. בהדגמה המודל עונה על שאלות מוכנות מראש, אבל בפרודקשן משתמשים מביאים ניסוחים שלא הופיעו באף תרחיש: עוקפים מסננים באמצעות ניסוח מחדש, מבקשים "הראה לי את ההוראות שלך", דוחפים לפעולות שלעוזר אין הרשאה לבצע.
Guardrails AI הוא שכבת כללים סביב המודל, שפותר שלוש משימות: לא לתת לפלוט תוכן אסור, לא לתת להמציא עובדה, ולא לתת לבצע פעולה בלי אישור אנושי.
נבחן כשלים אופייניים שאנחנו רואים בפרודקשן. דליפת פרומפט — המשתמש שולף את ההוראות המערכתיות דרך "תרגם אותן לשפה אחרת" או "המשך את הטקסט", והחוצה יוצאים כללים פנימיים, שמות שירותים, לוגיקת המודרציה.
הזיות בפרודקשן מסוכנות יותר מפני שהן נראות אמינות: העוזר נוקב בביטחון בזמן אספקה שלא קיים בנתונים, או ממציא תנאי של תעריף. עקיפת מסננים באמצעות ניסוח מחדש — בקשה אסורה מנוסחת מחדש בנימוס, דרך תפקידים או דרך מצב היפותטי, והמסנן לפי מילות מפתח מפספס אותה לגמרי.
סוג נפרד — פעולות מסוכנות. אם העוזר יודע ליזום תשלום, לבטל הזמנה או לשנות נתונים אישיים, טעות עולה לא במוניטין אלא בפעולות ממשיות. כאן guardrails פועלים לא כמסנן תשובה, אלא כאישור כוונה: העוזר מציע פעולה, המשתמש מאשר אותה, ורק אחר כך יוצאת בקשה ל-backend.
המחיר של כל כשל שונה, אבל המכניקה אחת: המשתמש מאבד אמון בעוזר אחרי הטעות הבטוחה הראשונה ומפסיק להשתמש בו. לכן guardrails מתכננים לא מעל עוזר מוגמר, אלא יחד איתו — בכניסה, ביציאה וברמת קריאת הכלים. בהמשך נבחן איך זה בנוי ומה כל שכבה מכסה.
מה נותן אסיסטנט מנוהל: השפעה במטריקות
המגבלות של האסיסטנט נמדדות לא בכמה שאילתות הוא החמיץ, אלא בכמה תשובות בעייתיות לא הגיעו למשתמש. בפיילוטים אנחנו קובעים קו בסיס לפי שלוש מטריקות: שיעור התשובות שמפרות את כללי הדומיין, שיעור השאילתות שנכנסו לחסימה, והזמן מרגע הפעלת הכלל ועד לתיקון הקונפיגורציה. בלי קו הבסיס הזה כל שיפור הופך לוויכוח על טעמים — איתו רואים מה בדיוק השתנה אחרי כל כלל.
בהמשך ההשפעה מתפרקת לפי מחלקות כשל, וכל אחת נסגרת בבדיקה משלה:
- ניסוחים לא בטוחים — פילטר בכניסה וביציאה מסיר אותם לפני השליחה; שיעור התשובות האלה יורד למקרים בודדים שנבחנים ידנית.
- עובדות מומצאות על המוצר — התשובות נבנות רק על מקורות מאושרים, ולכן טענות שנויות במחלוקת יוצאות מהתפוקה לחלוטין.
- דליפת נתונים פנימיים — מסכוך שדות רגישים בשלב הכנת ההקשר; מחלקת הכשל נסגרת בכניסה, ולא בדיעבד.
- עקיפת כללים באמצעות ניסוח מחדש — בדיקה חוזרת לאחר היצירה תופסת ניסיונות לעקוף את המגבלות ולא מעבירה אותם למשתמש.
- כשל שקט — אם הבדיקה לא פעלה, האסיסטנט עונה בסירוב, ולא בניחוש; זה מעביר את האירוע מהקטגוריה של "נשבר בלי לשים לב" ל"נראה מיד בלוגים".
מטריקה נפרדת — שיעור החסימות. גבוה מדי משמעו שהכללים חותכים שאילתות מועילות והאסיסטנט מאבד ערך; נמוך מדי — שהפילטרים לא עובדים. אנחנו מחזיקים אותו בטווח וסוקרים אותו בכל שינוי בתרחישים, כדי שהמגבלות לא יהפכו למטרה בפני עצמה.
זמן ההתאוששות לאחר אירוע תלוי במידת ההפרדה של הכללים מקוד האפליקציה. כשהם מוצאים לקונפיגורציה, התיקון אורך דקות ולא דורש ריליס חדש — עלות ההשבתה יורדת פי כמה, ולא באחוזים. בדיוק מרווח החוסן הזה הוא המשמעות המעשית של אסיסטנט מנוהל: התקלה ממוקמת, מתבטלת ונבחנת בלי לעצור את המוצר.
גישות להגבלה: השוואת מצבי עבודה
ניתן להציב הגבלות על עוזר AI בארבע נקודות: לפני היצירה, אחריה, ברמת סביבת ההרצה וברמת האדם. כמעט תמיד יש לשלב ביניהן — כל מצב סוגר סוג סיכון משלו ומותיר סוג חורים משלו. להלן השוואה כנה, כולל מקרים שבהם המצב אינו מתאים.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| בדיקה בכניסה | השאילתות צפויות: טפסים, תרחישי עזר, תחום תוכן צר | ניתן לעקוף על ידי ניסוח מחדש; הכללים מתיישנים במהירות; אינה תופסת דליפה בתשובה עצמה |
| בדיקה ביציאה | התשובות נשלחות למשתמש ישירות: טקסטים, המלצות, תשובות לשאלות | מוסיפה השהיה; התראות שווא חותכות תשובות מועילות; נדרש סט בדיקות משלך |
| מתחם מבודד | העוזר עובד עם נתונים רגישים או פעולות חיצוניות | יקר יותר בתחזוקה; חלק מהתרחישים אינם זמינים; נדרש פיקוח מצד השירות |
| מודרציה ידנית | נושאים שנויים במחלוקת, תלונות, טיפול באירועים, לימוד כללים | אינה מתרחבת לזרימה; תגובה בהשהיה; תלויה בעומס על האנשים |
כיצד מצבים משתלבים
בדיקה בכניסה זולה מהאחרות ומסננת אשפה ברורה לפני הפנייה למודל — אך היא אינה מצילה משאילתה מנוסחת כהלכה בעלת משמעות בלתי רצויה. בדיקה ביציאה תופסת את מה שחמק ועובדת כבר עם תשובה מוכנה: כאן מונחות בדיקות לנושאים אסורים, דליפת נתונים והתאמה לפורמט.
מתחם מבודד מגביל לא את הטקסט אלא את היכולות: העוזר רואה רק מקורות מורשים ואינו יכול לבצע פעולה מחוץ לסט המוסכם.
מודרציה ידנית אינה מחליפה את האוטומציה אלא משלימה אותה: היא מטפלת במקרים שנויים במחלוקת שהכללים לא סיווגו, ובעקבות הטיפול הכללים מתחדדים. בפועל, הסכמה העובדת היא כניסה, יציאה ובידוד באוטומציה, והאדם מתחבר לתור האירועים ולנושאים שבהם מחיר הטעות גבוה.
בחירת המצב היא בחירה בין השהיית התשובה, שלמות התרחישים ועלות התחזוקה. אנו מנתחים את התרחיש שלך ומרכיבים שילוב המתאים לו, ולא את "הבטוחה ביותר" משיקולים מופשטים.
כיצד אנו מיישמים מגבלות: שלבי העבודה
את העבודה אנו בונים כך שהמגבלות עבור העוזר יופיעו לא "תוך כדי", אלא כשכבה מנוהלת בין המודל לממשק האפליקציה. תחילה אנו מקבעים מה העוזר בכלל יכול לעשות במוצר, לאחר מכן מעבירים זאת לכללים הנבדקים בקוד, ורק אחרי כן משחררים לפרודקשן. להלן — הסדר שלפיו מתבצעת ההטמעה.
- ביקורת תרחישים. עוברים על כל הנקודות שבהן המשתמש מתקשר עם העוזר: צ'אט, רמזים בטפסים, יצירת טקסט, מענה על שאלות לפי נתונים. עבור כל תרחיש אנו מפרטים אילו פעולות מותרות, אילו נתונים נכנסים לשאילתה ומה נחשב לתשובה אסורה.
- סכמת מדיניות. מאחדים את התרחישים למפת כללים אחת: מגבלות נושאיות, איסור על מסירת נתונים אישיים, דרישות לסגנון ולפורמט התשובה, התנהגות כאשר המודל אינו בטוח. הסכמה מתואמת עם המוצר ועם המשפטנים לפני כתיבת הקוד.
- הגדרת בדיקות. מיישמים מסננים בכניסה וביציאה: בדיקת השאילתה לפני שליחתה למודל ואימות התשובה לפני הצגתה למשתמש. את הכללים אנו מחזיקים באופן הצהרתי — ניתן לשנותם ללא בנייה מחדש של האפליקציה.
- מבחני עמידות. מריצים מערכי ניסיונות לעקוף את המגבלות: ניסוחים מחדש, החלפת שפה, השתלת הוראות בטקסט של המשתמש. מתעדים כמה ניסיונות נחסמים ואילו תשובות עוברות לבדיקה ידנית.
- שחרור לפרודקשן. מפעילים את המגבלות בהדרגה: תחילה על חלק מהמשתמשים, עם תיעוד הפעלות ומדדי סירוב. אם שיעור החסימות השגויות עולה, הכללים מתוקנים עד להפעלה מלאה.
- מסירה לצוות. מוסרים תיעוד על המדיניות, הוראות להוספת כללים חדשים ותקנון לבחינה מחדש בעת שינוי המוצר — כדי שהמגבלות יתוחזקו בלעדינו.
סדר כזה מניב תוצאה צפויה: העוזר נשאר שימושי, וההתנהגות שמחוץ למותר נסגרת ברמת האפליקציה, ולא בתקווה מהמודל.
מדיניות גישה וכללי עיבוד נתונים
מדיניות גישה וכללי עיבוד נתונים הם מה שנשאר בידיכם לאחר הטמעת העוזר: לא "המלצות" מופשטות, אלא ארטיפקטים מגורסנים שחיים במאגר שלכם ועוברים סקירה כמו קוד רגיל. להלן מה שנכלל בחבילה.
- תצורות כללים: קבצים דקלרטיביים שמתעדים אילו בקשות העוזר מעבד, מה הוא מסווה ומה הוא דוחה. הכללים נמצאים לצד האפליקציה, ולא בפאנל זר, ולכן עריכתם עוברת את אותו תהליך אישור כמו שאר הקוד.
- תרשימי זרימת נתונים: דיאגרמה של מסלול הבקשה מהממשק למודל ובחזרה, עם סימון מפורש היכן הנתונים עוזבים את המכשיר, היכן הם עוברים אנונימיזציה והיכן הם אינם יוצאים כלל. ממנה ניתן לראות אילו שדות כלל לא אמורים להיכלל בבקשה.
- תפקידי גישה: מטריצת "תפקיד → מה רואה → מה יכול לשנות" עבור תמיכה, אנליטיקה ופיתוח. בנפרד מתואר מי רשאי לייצא לוגים של שיחות ומי רק צופה במטריקות מצטברות.
- נוהל הסלמה: סדר פעולות שלב-אחר-שלב בעת הפעלת כלל — מדחייה אוטומטית ועד בחינה ידנית. עם ציון מי אחראי בכל שלב ובתוך איזה זמן.
- ערכות בדיקה: אוסף בקשות שעליהן נבדקים הכללים לפני כל שחרור — כולל ניסיונות לעקוף את המגבלות באמצעות ניסוח מחדש. הערכות מופעלות אוטומטית, ולכן רגרסיה נתפסת לפני העלייה לאוויר.
- תיעוד: תיאור ההיגיון של הכללים ויומן שינויים — כדי שכעבור חצי שנה מהנדס חדש יבין מדוע המגבלה מנוסחת דווקא כך.
כל ארטיפקט נמסר בקונטור שלכם: כללים ובדיקות — במאגר, תרשימים ונוהלים — בבסיס הידע של הצוות. אנו מלווים את העריכה הראשונה יחד עם המהנדסים שלכם, ומכאן והלאה אתם משנים את הכללים בעצמכם, בלי להמתין לנו. תארו את המשימה — נחזור עם הערכה ותוכנית לחבילה כזו.
מקרה בוחן: עוזר בתוך האפליקציה לפני ואחרי ההגבלות
מה היה לפני ההגבלות
העוזר השיב לבקשות חופשיות של משתמשים ללא בדיקה בפלט: המודל יכול היה לתת עצה לגבי מינון רפואי, להבטיח החזר כספי בשם השירות או להתייחס לסעיף חוזה שאינו קיים. הדבר לא יצר בעיה נפרדת כל עוד שיעור התשובות הללו נותר בטווח הטעות הסטטיסטית.
כאשר העוזר קיבל גישה להיסטוריית ההזמנות וליתרה, כל תשובה לא בטוחה שנייה הפכה לפנייה לתמיכה — הנציג בזבז זמן על ניתוח ההתכתבות והסבר שלבוט לא הייתה הזכות להבטיח זאת.
מה שינו
הצבנו שכבת בדיקות בין המודל לממשק האפליקציה: כללים בכניסה חוסמים בקשות מחוץ לנושאים המותרים, כללים ביציאה בודקים את התשובה לניסוחים אסורים, הבטחות בשם החברה והפניות לנתונים שאינם בהקשר של המשתמש. תשובה שלא עברה בדיקה אינה מוצגת — העוזר מנסח אותה מחדש או מעביר את השיחה לנציג. כל הפעלה נרשמת ביומן עם הסיבה, ולכן הכללים מתעדכנים לפי מקרים אמיתיים ולא לפי הנחות.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| שיעור תשובות לא בטוחות | תשובה אחת מתוך 40 | אחת מתוך 900 |
| זמן תגובה לאירוע | שעות, ידנית | דקות, לפי היומן |
| פניות לתמיכה בגלל העוזר | חלק ניכר מהזרימה | מקרים בודדים |
| חומרים למודרציה | כל תשובה שנויה במחלוקת | רק מקרי גבול |
העומס על התמיכה ירד לא בגלל שמשתמשים הפסיקו לכתוב לעתים קרובות יותר, אלא בגלל שהסיבות לכתוב פחתו. נציין בנפרד: הכללים לא הפכו את העוזר לחסר תועלת — שיעור השיחות שהובאו לפתרון בתוך האפליקציה עלה, מכיוון שהמשתמש הפסיק לקבל תשובות שבוטלו afterwards.
Guardrails AI אנו משתמשים כמסגרת לתיאור כללים וולידטורים: היא מאפשרת להחזיק את הבדיקות באופן הצהרתי ולשנותן ללא בנייה מחדש של לוגיקת העוזר.
במה שונה בדיקה בכניסה מבדיקה ביציאה?
בדיקה בכניסה פועלת לפני שהבקשה יוצאת למודל: היא חוסמת נושאים אסורים, ניסיונות לחלץ את הוראת המערכת, קבצים מצורפים חשודים ובקשות שאינן בתרחיש היישום.
בדיקה ביציאה עובדת עם התשובה שכבר נוצרה: היא תופסת עובדות מומצאות, דליפת נתונים אישיים, קישורים למדורים שאינם קיימים וטון שאינו מקובל על המותג. אלו אינן נקודות בקרה כפולות אלא משלימות — הכניסה זולה ומהירה יותר, היציאה מדויקת יותר כי היא רואה את התוצאה כולה.
התראות שווא מתפלגות באופן שונה. בכניסה הן בדרך כלל גסות יותר: שאלה ניטרלית לכאורה על רפואה או פיננסים עלולה להיחסם כנושא אסור, אף שהמשתמש שאל על הגדרת התראות. ביציאה התראות שווא עדינות ויקרות יותר: המודל הפיק תשובה תקינה, אך המסנן זיהה כשליפה מספר הזמנה שהמשתמש עצמו ציין בבקשה.
לכן הספים בכניסה נשמרים מתונים יותר, וביציאה — מחמירים יותר, אך עם תיעוד חובה של כל התראה, כדי שמהנדס יוכל לנתח אותה ולכוונן את הכלל.
מעגל הבדיקות נבנה כך שנקודות הבקרה אינן משכפלות זו את זו. בכניסה — נרמול הבקשה, בדיקה לקטגוריות אסורות והגבלת אורך ההקשר. ביציאה — הצלבת עובדות עם מקור מהימן, הסוואת נתונים אישיים ובדיקת התאמה לתרחיש. אם הכניסה חוסמת את הבקשה, המשתמש מקבל הסבר ברור וחלופה, ולא מסך ריק. אם היציאה אינה עוברת בדיקה, התשובה אינה מוצגת אלא מועברת לתרחיש בטוח: שאלת הבהרה או העברה לנציג.
ההחלטה המרכזית — מה לעשות בעת התראה. אפשרות מתונה: לסמן את התשובה ולהציגה עם הסתייגות. אפשרות מחמירה: לחסום ולשאול מחדש. הבחירה תלויה במחיר הטעות בתרחיש הספציפי — במדור מידע מספיקה הסתייגות, בפעולות עם נתונים נדרשת חסימה.
שתי הרמות מתועדות באותו אופן, אחרת אי אפשר לחשב את שיעור התראות השווא ולהבין היכן הכלל פועל שלא כמתוכנן.
ספקות טכניים נפוצים לגבי guardrails ai
לפני שמאשרים את הארכיטקטורה, צוותים טכניים שואלים את אותן השאלות: האם זמן התגובה יגדל, האם ניתן לעקוף את הכללים, מה קורה בעת החלפת מודל וכיצד ניתן לבטל שינוי כושל. להלן תשובות קצרות לכל אחת מהנקודות הללו, בלי שיווק.
האם Guardrails ai מוסיפים השהיה לתגובת העוזר?
הבדיקות מבוצעות בצד האפליקציה ואורכות שברירי שנייה — על רקע יצירת התגובה על ידי המודל זה בלתי מורגש. אנחנו שומרים על כללים קלים: אימות פורמט, סינון נושאים אסורים, בדיקת הפניות למקורות. אם כלל דורש קריאה חיצונית, הוא עובר לענף אסינכרוני ואינו חוסם את הפלט. אנחנו מודדים את זמן התגובה לפני ואחרי ההטמעה ומתעדים את ההפרש בדוח.
האם ניתן לעקוף את guardrails ai באמצעות ניסוח מחדש של השאילתה?
אי אפשר לשלול זאת לחלוטין — כמו כל הגנה. המשימה היא אחרת: להפוך את העקיפה ליקרה ובולטת. אנחנו משלבים כללים בכניסה (סיווג כוונה) וביציאה (בדיקת התגובה), ובנוסף מתעדים ניסיונות עקיפה. כאשר מופעל הסף, העוזר מגיב בסירוב ומעביר את השיחה לנציג. הכללים מתעדכנים ככל שמופיעים תרחישי עקיפה חדשים.
מה קורה בעת עדכון המודל?
Guardrails ai פועלים בנפרד מהמודל, ולכן החלפת גרסה אינה שוברת את הכללים — אך דורשת הרצת רגרסיה. אנחנו מחזיקים סט של שיחות בדיקה, שעליהן בודקים שהמודל החדש לא החל לעקוף את המגבלות ולא איבד איכות בתרחישי המפתח. רק לאחר מעבר הבדיקות המודל עובר לפרודקשן.
האם ניתן להוסיף תרחישים וכללים משלנו?
כן. הכללים מתוארים באופן דקלרטיבי ואינם דורשים כתיבה מחדש של לוגיקת האפליקציה. אתם מוסיפים תרחיש — אנחנו מגדירים את הבדיקות, בודקים ומשיקים. כך גם מוגדרים פורמטים משלכם לתגובות, טון וניסוחים אסורים עבור המוצר שלכם.
כיצד לבטל שינויים אם כלל שבר תרחיש?
תצורת הכללים מנוהלת בגרסאות. ביטול הוא חזרה לגרסת התצורה הקודמת, ולא בנייה מחדש של האפליקציה: אורך דקות ואינו משפיע על מחזור השחרור. לפני ההשקה השינויים עוברים על תעבורת צל, ולכן ביטול נדרש לעתים רחוקות.
תארו את המשימה — נחזור עם הערכה ותוכנית עבור המוצר שלכם.
בואו נדון במשימה: נחזור עם הערכה ותוכנית
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים נתוני מקור על האפליקציה שלכם.
הביאו את מה שיש: מאגר קוד או גישה אליו, הארכיטקטורה הנוכחית ותרשים הנתונים, רשימת השירותים החיצוניים שאיתם האסיסטנט משולב, ותיאור של האופן שבו הוא מתנהג כעת — היכן הוא עונה שלא לעניין, היכן הוא חורג מגבולות התרחיש, היכן המשתמשים מתלוננים.
אם האפליקציה כבר בחנויות, הוסיפו אנליטיקה לפי מסכי האסיסטנט וייצוא של פניות לתמיכה: מהם רואים אילו תשובות שוברות את התרחיש לעתים קרובות ביותר.
בהמשך אנחנו מדייקים את גבולות המשימה. מה בדיוק האסיסטנט צריך לעשות ומה אסור לו, אילו נתונים הוא רואה, היכן התשובה מחויבת לעבור לאדם, אילו בדיקות נדרשות לפני הצגת התשובה למשתמש.
בנפרד אנחנו מסכמים כיצד תבדקו את התוצאה: מערך תרחישי בדיקה, תשובות ייחוס, מדדים לפי שיעור התשובות הנכונות ולפי מספר החריגות מהגבולות. בלי זה ההערכה הופכת לניחוש, והמועדים — לתהליך אינסופי.
בסיום אתם מקבלים:
- ניתוח של מצב האסיסטנט הנוכחי ורשימת מקומות שבהם הוא מתנהג באופן בלתי צפוי;
- רשימת כללים ומגבלות שצריך להטמיע בעבודתו;
- תרשים בדיקות של התשובה לפני הצגתה למשתמש;
- תוכנית עבודה לפי שלבים עם סדר ומועדים;
- הערכת מאמץ לפי כל שלב;
- רשימת סיכונים ומה שעלול להזיז את המועדים;
- אפשרות כיצד להעלות שינויים בלי לעצור את האפליקציה.
את סדר העבודות אנחנו דנים כבר בשיחה הראשונה: תחילה מנתחים את המשימה והנתונים, לאחר מכן מקבעים את ההיקף, ואז קובעים מועדים. תארו את המשימה בצורה נוחה — נחזור עם הערכה ותוכנית שאפשר לקבל לפיה החלטה.