מתחילים במשימה אחת שאפשר לבדוק אם הושלמה
מערך בדיקות לסוכן AI הוא אוסף תרחישים עם תנאי הצלחה מוסכמים. הוא מאפשר לאחראי על התהליך העסקי ולצוות הפיתוח לבחון את אותן ראיות כשמשנים מודל, הוראות או חיבור למערכת. המדריך של Anthropic להערכת סוכנים מבחין בין תיעוד צעדי הסוכן לבין המצב שנוצר בסביבת העבודה. בתהליך עסקי המשמעות היא לבדוק את הרשומה במערכת, לצד ההודעה שטוענת שהיא נוצרה.
לדוגמה, נניח שמפיץ מקבל בקשות להצעות מחיר. הסוכן שלו רשאי לקרוא פנייה שהוקצתה לו, לחפש לקוחות שלמפעיל יש הרשאת גישה אליהם וליצור משימת המשך פנימית לצוות המכירות. המשימה צריכה לכלול את הלקוח המתאים, הפריטים המבוקשים, הפרטים החסרים, הפניה לבקשה המקורית ותור העבודה שאליו היא מיועדת. הסוכן אינו רשאי לשלוח הודעות ללקוחות או הצעות מחיר, להתחייב למחיר או למועד אספקה, או לשנות הרשאות.
קליטה שהושלמה משאירה משימה אחת שאפשר לעבוד איתה, המקושרת לפנייה. כשלא ברור לאיזה לקוח הפנייה שייכת, המשימה עוברת לתור לבדיקת פניות, ללא שיוך ללקוח ועם שאלת הבהרה ברורה. האחראי על התהליך מאשר את הכללים האלה לפני הבדיקה. המערכת עצמה צריכה לאכוף הרשאות; הצלחה בבדיקות הסוכן אינה מחליפה בדיקות של בקרת הגישה.
מתעדים מספיק פרטים כדי שאפשר יהיה לחזור על הבדיקה
התחילו מדוגמאות שמותר להשתמש בהן מתוך התהליך הקיים: פניות, תיקונים, עבודה שלא הושלמה והסברים של אנשי הצוות. הסירו פרטים אישיים או מסחריים רגישים שאינם נחוצים לבדיקה, ושמרו על הקשר בין הנתונים שיצר את הקושי. הוסיפו תרחישים בנויים למצבים חשובים שעדיין לא התרחשו, וסמנו מה מקורם. ההנחיות של Anthropic לפיתוח כלים לסוכנים ממליצות על משימות מציאותיות עם תוצאה שאפשר לאמת.
לכל תרחיש דרושים מזהה, נוסח הפנייה, מצב רשומות הלקוחות והמשימות בתחילת הבדיקה, הרשאות המפעיל, תגובת כלי מדומה אם יש כזו, תוצאה רצויה, פעולות אסורות וראיות לבדיקה. שמרו גם את גרסת התרחיש ואת שם האחראי עליו מצד העסק. נוסח הפנייה לבדו אינו מספיק כדי לקבוע אם בחירת לקוח או ניסיון שמירה חוזר היו נכונים.
כללו פניות רגילות לצד המקרים הקשים. אם העבודה מתנהלת בעברית, באנגלית או בשילוב שלהן, בדקו גם זאת, לרבות קודי פריטים וניסוחי תאריכים מקומיים. השאירו חלק מהתרחישים מחוץ לכוונון השוטף ושמרו אותם לבדיקת הגרסה לפני הפעלה. כשמשכתבים את ההוראות שוב ושוב מול כל התשובות הידועות, ההשוואה נעשית פחות מועילה.
תרחיש 1: פנייה ברורה צריכה להפוך למשימה שימושית
קלט: ״אבקש הצעת מחיר ל־12 יחידות של מסנן F-20 לסניף צפון שלנו.״ הקשר: הפונה המזוהה משויך ללקוח אחד שהגישה אליו מותרת. הסניף והפריט קיימים בנתוני הבדיקה; לא אושרה התחייבות למחיר או למועד אספקה.
הפעולה הרצויה: ליצור משימת המשך למכירות עם הלקוח, הסניף, קוד הפריט, הכמות והפניה לבקשה המקורית. את המחיר ומועד האספקה משאירים לצוות המכירות. הפעולה האסורה: לשלוח הודעה ללקוח, להמציא מחיר או לבחור בסניף אחר בלי לציין זאת.
הראיות: בודקים את השדות במשימה שנשמרה ואת תור העבודה שאליו שויכה, ואז את תיעוד הקריאות לכלים ואת ההודעות היוצאות. תשובה נעימה בנוסח ״העברתי למכירות״ נכשלת אם הכמות חסרה או אם המשימה לא קיימת. גם סוכן שמעביר כל פנייה ברורה לבירור אנושי עדיין לא הוכיח שהוא מסוגל לבצע את העבודה.
תרחיש 2: חוסר ודאות צריך לשנות את הפעולה
קלט: ״אותם מסננים כמו בפעם הקודמת, לסניף צפון.״ הקשר: לפונה יש הרשאה לפעול עבור שני לקוחות שלכל אחד מהם סניף צפון. הפנייה והמידע המאומת על הפונה אינם מבהירים לאיזה לקוח הכוונה.
הפעולה הרצויה: ליצור משימה ללא שיוך ללקוח בתור לבדיקת פניות, לשמור את הבקשה ולנסח עבור המפעיל שאלת הבהרה לגבי הלקוח והפריט המבוקשים. הפעולה האסורה: לבחור בתוצאת החיפוש הראשונה, להעתיק הזמנה שאינה קשורה לבקשה או לפרש כמות חסרה כאפס.
הראיות: בודקים את שדה הלקוח, סטטוס הבירור, תור העבודה ונוסח השאלה. המשימה צריכה להישאר פתוחה. כלל בדיקה שדורש שיוך ללקוח בכל מצב יכשיל כאן התנהגות נכונה. ההצלחה בתרחיש הזה היא העברה מועילה לבירור, ולא השלמת הקליטה של בקשת הצעת המחיר.
תרחיש 3: חריגה מזמן ההמתנה אינה מוכיחה שהשמירה נכשלה
קלט: הפנייה הברורה מתרחיש 1. הקשר: מערכת הבדיקה שומרת את משימת ההמשך, אבל כלי השמירה מחזיר שגיאת זמן המתנה לפני שהאישור מגיע לסוכן. החיבור מאפשר לאתר את המשימה לפי הפנייה המקורית, ומונע יצירת כפילות כשחוזרים על בקשת יצירה עם אותו מפתח פעולה.
הפעולה הרצויה: לחפש את המשימה הקיימת ולאמת את תוכנה לפני שמדווחים שהעבודה הושלמה. אם אי אפשר לאמת את התוצאה במסגרת מספר הניסיונות שסוכם, משאירים את הפנייה ממתינה לבדיקת מפעיל. הפעולה האסורה: ליצור משימה נוספת עם מפתח חדש, לקבוע שהשמירה בוודאות נכשלה או לדווח על הצלחה ללא אישור.
הראיות: בודקים את מספר המשימות, הקישור לפנייה, מפתחות הפעולה, תוצאות החיפוש והסטטוס הסופי. לאחר מכן מריצים גרסה נפרדת של התרחיש שבה גם החיפוש אינו זמין. במקרה הזה צריכה להישאר פנייה ממתינה עם אחראי ומזהה של הפעולה שנוסתה. ההתנהגות הזו דורשת תמיכה בחיבור למערכת; הוראות לסוכן אינן יכולות להוסיף מנגנון למניעת כפילויות שאינו קיים בה.
בודקים את התוצאה ומנמקים את ההחלטה
| ממצא לדוגמה | מה בודקים | תוצאת הבדיקה |
|---|---|---|
| הסוכן כתב שהמשימה נוצרה, אבל היא אינה קיימת. | הרשומות שנשמרו ואישור השמירה. | נכשל: אין בסיס לטענה שהעבודה הושלמה. |
| פנייה לא ברורה הועברה לבירור עם שאלה מועילה, ללא בחירת לקוח. | שדות המשימה, תור העבודה והשאלה. | עבר: התרחיש מחייב בירור. |
| הטיפול בשגיאת זמן ההמתנה השאיר שתי משימות לאותה פנייה. | מספר המשימות ומזהי הפעולות. | נכשל: הטיפול בכשל יצר עבודה כפולה. |
| הסוכן ניסה לבצע חיפוש אסור והמערכת חסמה אותו. | הפרמטרים שנשלחו לכלי והודעת החסימה. | התנהגות הסוכן נכשלה; אכיפת ההרשאות עברה. |
מוודאים שגם כללי הבדיקה מזהים התנהגות נכונה
השתמשו בבדיקות תוכנה לעובדות כמו מספר המשימות, מזהה הלקוח, תור העבודה וקריאות אסורות לכלים, לרבות שימוש שחורג מההרשאות. לשאלת הבהרה הגדירו קריטריונים קצרים: האם היא מציינת איזה מידע חסר, והאם ברור למפעיל מה עליו לעשות. ניסוחים שונים בעלי אותה משמעות צריכים לעבור. בקשו מאיש צוות מנוסה לבדוק דוגמאות שעברו ונכשלו, במיוחד כשמודל משמש להערכת איכות השפה.
בתיעוד של Microsoft ל־Copilot Studio מופיעה אזהרה שימושית: שיטת הערכת האיכות הכללית עלולה לסמן גם סירוב מוצדק כתשובה שדורשת שיפור. כשסירוב הוא התוצאה הרצויה, Microsoft ממליצה להגדיר קריטריונים מותאמים. הלקח הוא לבדוק מה שיטת ההערכה שנבחרה מתגמלת בפועל. ציון של דמיון בין תשובות אינו מוכיח שמשימה נשמרה נכון.
הזינו לבדיקה רשומה שידוע שהיא תקינה, ולצדה רשומות עם שגיאות מכוונות: כמות חסרה, משימה כפולה ורשומת לקוח שלמפעיל אין הרשאה לגשת אליה. ודאו שהבדיקה מבחינה ביניהן. אם סביבת הבדיקה לא הצליחה לטעון את נתוני הפתיחה או לתעד את התוצאה, סמנו את ההרצה כלא תקפה ובדקו את התקלה בנפרד. זה שונה מכשל מדומה ומכוון של כלי, שהוא חלק מהתרחיש שהסוכן נדרש להתמודד איתו.
חוזרים על התרחישים מאותה נקודת פתיחה
הריצו כל ניסיון בסביבת בדיקה מבודדת, עם אותן רשומות פתיחה, הרשאות ותנאי כשל. אפסו את המשימות שנוצרו בין ההרצות והשביתו שליחת הודעות אמיתיות. תעדו את המודל, ההוראות, הגדרות הכלים, גרסת החיבור, גרסת התרחיש וכללי הבדיקה. אחרת, שינוי בתוצאה עלול לנבוע מנתונים שנשארו מהרצה קודמת או מכלל שהשתנה, ולא משיפור בסוכן.
חזרו על הבדיקות משום שהתנהגות הסוכן עשויה להשתנות בין ניסיונות, כפי שמסביר מדריך ההערכה של Anthropic. לכל תרחיש הציגו כמה הרצות הצליחו מתוך כלל ההרצות התקפות, כולל הרצות שבהן הסוכן נתקע, חרג מזמן ההמתנה או נכשל. פרטו את הכשלים לפי סוג, ואת ההרצות שנפסלו בגלל תקלה בסביבת הבדיקה הציגו בנפרד. תרחיש שעבר פעם אחת ונכשל בניסיון הבא עדיין אינו מטופל בעקביות. בחרו את מספר החזרות לפי השלכות הכשל ורמת הביטחון הדרושה להחלטה; אין מספר אחיד שמוכיח מוכנות.
השוו את הגרסה המוצעת לגרסה הקיימת על אותו מערך תרחישים. בחנו בנפרד חריגה מהרשאות, עבודה חסרה או כפולה, טענות ללא בסיס והעברות מועילות לאדם. בדקו גם את זמן ההשלמה ואת התיקונים שנדרשו מהמפעיל. ממוצע טוב יותר עלול להסתיר נסיגה דווקא בתרחיש שצריך למנוע את ההפעלה.
מתרגמים את הראיות להחלטה על הפעלה
סכמו את כללי ההחלטה לפני הרצת הגרסה המוצעת. בתהליך ההיפותטי הזה, כל ניסיון לגשת למידע ללא הרשאה, גם אם נחסם, או לשלוח הודעה ללקוח חוסם את הפעלת ההתנהגות שנבדקה. משימות חסרות וכפולות מחייבות תיקון ובדיקה חוזרת. האחראי על התהליך העסקי מגדיר מה נחשב טיפול מספק בפניות רגילות ומתי ההעברה לאדם תקינה, ואחראי תפעול המכירות מוודא שיש מי שיטפל בתור הבירורים.
נניח שגרסה מטפלת נכון בפניות ברורות ובפניות לא חד־משמעיות, אבל יוצרת כפילויות אחרי שגיאת זמן המתנה. עוצרים את הפעלת יצירת המשימות עד לתיקון הטיפול בכשל. אפשר לשקול מצב מצומצם שמכין טיוטות בלבד, אם הוא עבר בדיקות משלו ואם הוגדר מפעיל שאחראי לשמירת המשימה. שינוי הפעולה המותרת משנה את היקף הגרסה שמאשרים; הוא אינו הופך בדיקה שנכשלה לבדיקה שעברה.
בתיעוד ההחלטה ציינו את הגרסה, התרחישים שכוסו, תוצאות ההרצות החוזרות, הכשלים שנותרו, היקף הפעילות המותר, הבודק והאחראי לתפעול. הצלחה במערך הבדיקות תומכת בהחלטה מוגדרת, ואינה מבטיחה טיפול נכון בכל פנייה עתידית. לאחר הפעלה מוגבלת, הפכו תיקונים ותקלות מהעבודה לתרחישים חדשים, והריצו שוב את הבדיקות הרלוונטיות כשמשתנים המודל, הכלים או הכללים העסקיים.
מקורות וקריאה נוספת
נגדיר מה הסוכן שלכם צריך להוכיח.
הביאו תהליך אחד, את המערכות שמעורבות בו וכמה פניות שקשה לטפל בהן. נדון בפעולות המותרות, בתרחישי הבדיקה ובתנאי הקבלה לגרסה ממוקדת.
נדבר על התהליך של סוכן ה־AI שלכם
