אימות מודלים וסוכני בינה מלאכותית באמצעות בדיקות מבוססות תכונות

בדיקות מבוססות תכונות: איך בוחנים אמינות של מודלים וסוכני בינה מלאכותית

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

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

כשהתשובה הנכונה אינה מחרוזת אחת

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

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

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

מה בודקות בדיקות מבוססות תכונות

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

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

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

בדיקות מטמורפיות: לשנות את הקלט, לשמר את ההתחייבות

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

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

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

מהשירות ללקוח ועד לסיווג לידים

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

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

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

איכות הבדיקה מתחילה במחולל הקלטים

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

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

צמצום הכשל: ממסמך עמוס לדוגמה שאפשר להבין

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

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

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

שונות הסתברותית מחייבת מדידה, לא התרשמות

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

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

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

בסוכני AI צריך לבדוק את מסלול הפעולה

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

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

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

בדיקות אינן תחליף לאכיפת הרשאות

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

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

מי קובע אם התכונה נשמרה

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

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

כך הופכים את השיטה לחלק מתהליך הפיתוח

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

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

מפת בדיקות תמציתית

חמש שאלות שכדאי לשאול לפני ההפעלה

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

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