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