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

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

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

בונים משימות עם מצב התחלתי ותוצאה נצפית

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

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

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

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

מריצים כמה ניסיונות מאותה נקודת התחלה

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

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

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

בודקים תשובה, תוצאה ומסלול בנפרד

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

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

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

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

משווים לגרסה הקיימת ברמת המשימה

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

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

קובעים מראש מה חוסם שחרור

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

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

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