סוכן AI שנותן תשובה מלוטשת בהדגמה עדיין יכול לגרום לכשלים יקרים בפרודקשן. הוא עלול לשלוף רשומת לקוח שגויה, לאשר חריגה מחוץ למדיניות, לשלוח הודעה בתזמון גרוע או לקרוא ל-API פעמיים. לדעת איך לבדוק את התנהגות סוכן ה-AI פירושו לבדוק את תהליך העבודה כולו, ולא רק אם המודל מסוגל להפיק טקסט שנשמע סביר.
עבור צוותי תפעול, הסטנדרט פשוט: סוכן חייב לבצע את הפעולה הנכונה, על הנתונים הנכונים, בתוך ההרשאות שהוגדרו, ולהשאיר תיעוד שניתן לבקר. זה דורש גישת בדיקות שקרובה יותר ל-QA של תוכנה ולאימות תהליכים מאשר להערכה טיפוסית של צ'אטבוט.
התחילו מההחלטה העסקית, לא מהמודל
הבדיקות צריכות להתחיל לפני הפרומפטים, הכלים או בחירת המודל. הגדירו את התוצאה העסקית שהסוכן אמור להשיג ואת הגבולות שעליו לכבד. לדוגמה, סוכן תמיכה רשאי לסווג בעיה ולנסח תשובה, אבל רק אדם צריך לאשר החזר כספי מעל סף מסוים. סוכן חיתום יכול לרכז נתונים ולזהות מסמכים חסרים, אבל אסור לו לקבל החלטה סופית כשהרגולציה מחייבת בדיקה.
כתבו את הכללים האלה כקריטריוני קבלה שניתן לבחון. הימנעו מדרישות כלליות כמו "הסוכן צריך לטפל היטב בפניות לקוחות". קריטריון שימושי מגדיר מה הסוכן חייב לעשות, מה אסור לו לעשות ואיך תימדד ההצלחה.
לדוגמה: "כשלקוח מבקש לשנות כתובת לחיוב, הסוכן מאמת את זהותו, מעדכן רק את רשומת ה-CRM התואמת, מאשר את השינוי ויוצר אירוע ביקורת. אם לא ניתן לאמת את הזהות, אסור לו לעדכן את הרשומה, ועליו לנתב את המקרה לתור אנושי."
רמת פירוט כזו מאפשרת לבדוק. היא גם חושפת איפה נמצאת המורכבות האמיתית: איכות נתונים, הרשאות מערכת, טיפול בחריגים ומסלולי הסלמה.
בנו מקרי בדיקה מתנאי התפעול האמיתיים
בדיקות של המסלול התקין נחוצות אבל לא מספיקות. תהליכי עבודה אמיתיים כוללים טפסים חלקיים, רשומות סותרות, שפה עמומה, API איטיים, חריגות מהמדיניות ומשתמשים שנותנים הוראות שהסוכן צריך להתעלם מהן. חבילת הבדיקות שלכם צריכה לשקף את המציאות הזו.
השתמשו ככל האפשר במקרים היסטוריים מותממים. הם חושפים את השפה, פורמטי המסמכים ומקרי הקצה שהפעילות שלכם באמת נתקלת בהם. השלימו אותם במקרים סינתטיים שמעמידים את המערכת בלחץ במכוון, כולל תרחישים נדירים אך בעלי השפעה גבוהה.
חבילת בדיקות מעשית לסוכן AI צריכה לכסות לפחות את המצבים הבאים:
- בקשות סטנדרטיות עם נתונים מלאים ומדויקים ותוצאה צפויה ברורה.
- בקשות עמומות או חלקיות שאמורות להוביל לשאלת המשך או להסלמה לאדם.
- מידע סותר בין מערכות מחוברות, למשל CRM ו-ERP שמציגים סטטוס חשבון שונה.
- מקרי גבול של מדיניות, כולל אישורים, שינויי תשלום, החלטות מפוקחות או גישה למידע רגיש.
- כשלי כלים ואינטגרציה, כמו חריגות מזמן ההמתנה, תגובות API פגומות, אירועים כפולים ושירותים לא זמינים.
- קלטים עוינים, כולל ניסיונות הזרקת פרומפטים בתוך אימיילים, מסמכים שהועלו, קריאות שירות או תוכן במאגר הידע.
כל מקרה צריך להגדיר יותר מהתשובה הסופית הרצויה. תעדו את קריאות הכלים הצפויות, את מקורות הנתונים שהסוכן רשאי להשתמש בהם, את הפעולות האסורות עליו, את תיעוד הביקורת הנדרש ואת תוצאת ההסלמה. כך ההערכה הופכת לתהליך הנדסי שניתן לחזור עליו במקום לבדיקה סובייקטיבית.
בדקו את הסוכן בארבע רמות
סוכן AI הוא מערכת של רכיבים שפועלים זה עם זה. המודל הוא רק אחד מהם. QA טוב מפריד בין כשלים לפי שכבה, וכך קל ומהיר יותר לאבחן אותם ובטוח יותר לתקן אותם.
1. בדקו את ההנחיות ואת התנהגות ההסקה
בשכבה הזו, העריכו אם הסוכן מבין את תפקידו, פועל לפי המדיניות, שואל שאלות הבהרה מועילות ומסרב לפעולות שאינן נתמכות. הריצו את אותו מקרה כמה פעמים כשהפלטים אינם דטרמיניסטיים. אתם מחפשים עקביות בטווח מקובל, לא ניסוח זהה.
דרגו את הפלטים לפי מחוון מוגדר. בהתאם לתהליך העבודה, הוא עשוי לכלול דיוק עובדתי, עמידה במדיניות, סיווג נכון, שלמות, טון והסלמה מתאימה. בדיקה אנושית נשארת בעלת ערך כאן, במיוחד לשיפוטי איכות ורגולציה מורכבים. עם זאת, הבודקים צריכים להשתמש במחוון משותף כדי שהתוצאות לא יהיו תלויות בהעדפה אישית.
2. בדקו שימוש בכלים ותזמור
סוכן יכול להסיק נכון ועדיין להיכשל כשהוא עובד מול מערכות עסקיות. ודאו שהוא בוחר את הכלי הנכון, מעביר פרמטרים תקינים, מטפל באימות בצורה נכונה ולא חוזר על פעולה אחרי כשל חלקי.
השתמשו בסביבות sandbox ובחשבונות בדיקה במקום בנתוני לקוחות אמיתיים. דמו כשלים צפויים: רשומת CRM שלא נמצאת, תגובת ERP שמגיעה באיחור, מנתח מסמכים שמחזיר טקסט ריק, או API שמקבל בקשה אבל מדווח על שגיאה לפני האישור. הסוכן צריך להתאושש בבטחה, להסביר את המגבלה כשמתאים ולהימנע מהמצאת תוצאה מוצלחת.
אידמפוטנטיות ראויה לתשומת לב מיוחדת. אם סוכן מנסה שוב תשלום, יוצר קריאה או מעדכן רשומה, תהליך העבודה חייב למנוע פעולות כפולות. זה שיקול אינטגרציה סטנדרטי, אבל בתהליכי עבודה שמונעים על ידי סוכנים הוא דחוף יותר, כי ניסיונות חוזרים עשויים להתחיל בעקבות הקשר שיחה שמשתנה.
3. בדקו אבטחה, הרשאות וטיפול בנתונים
סוכנים מעבדים שפה לא מהימנה ולעיתים קרובות יש להם גישה למערכות מהימנות. השילוב הזה יוצר בעיית אבטחה ייחודית. הוראה זדונית יכולה להופיע באימייל של לקוח, בקובץ PDF, בדף אינטרנט או במסמך פנימי שהסוכן שלף. הסוכן חייב להתייחס לתוכן כאל נתונים, ולא כאל הרשאה לעקוף את כללי הפעולה שלו.
בדקו אם הסוכן מסרב לניסיונות לחשוף הרשאות גישה, להתעלם ממדיניות, לייצא רשומות רגישות או לבצע פעולות מעבר לרמת הגישה של המשתמש הנוכחי. אמתו הרשאות מבוססות תפקיד בשכבת הכלים, ולא רק בפרומפט. פרומפטים מכוונים את ההתנהגות; בקרות המערכת אוכפות אותה.
בדקו גם את הרישום ואת שמירת המידע. רשומות הביקורת צריכות להראות איזו בקשה הוגשה, לאילו כלים בוצעה קריאה, לאיזו קטגוריית נתונים הייתה גישה, איזו פעולה התבצעה ולמה הסוכן הסלים או סירב. בסביבות רגישות לרגולציה, הראיות האלה עשויות להיות חשובות כמו התוצאה עצמה.
4. בדקו את התהליך העסקי מקצה לקצה
לבסוף, בדקו את תהליך העבודה המלא כפי שמפעיל או לקוח חווים אותו. האם הפלט של הסוכן נכנס לתור הנכון? האם ההעברה כוללת מספיק הקשר עבור הבודק האנושי? האם המערכת בהמשך השרשרת מקבלת את הסטטוס הנכון? האם התהליך מסתיים בתוך הציפייה לרמת השירות?
כאן צוותים מוצאים כשלים שמדדי ביצועים של מודלים מפספסים. תשובה עשויה להיות מדויקת ועדיין חסרת תועלת תפעולית אם היא מגיעה אחרי מועד ההחלטה, משמיטה מספר תיק נדרש או שולחת הערה פנימית לערוץ שפונה ללקוח.
הגדירו מדדים שמשקפים סיכון עסקי
דיוק לבדו אינו מדד מספק לסוכן AI. ציון דיוק גבוה יכול להסתיר מספר קטן של כשלים בלתי קבילים. עקבו אחר מדדים שתואמים את פרופיל הסיכון של תהליך העבודה.
בסוכן לעיבוד מסמכים, מדדו דיוק חילוץ לפי שדה, שיעור זיהוי חריגים (recall), זמן טיפול ממוצע ואחוז המקרים שנותבו נכון לבדיקה. בסוכן תמיכה, מדדו שיעור פתרון נכון, דיוק ההסלמה, שיעור פעולות לא מורשות, שיעור פניות חוזרות של לקוחות ועלות לכל מקרה שנפתר. בסוכן תפעול, עקבו אחר השלמת משימות מוצלחת, שיעור כשלי קריאות לכלים, שיעור פעולות כפולות וזמן שנחסך לכל תהליך עבודה.
הגדירו ספים נפרדים לשגיאות קריטיות. בעיית עיצוב קלה עשויה להיות נסבלת. שליחת תשלום לחשבון הלא נכון - לא. כאן חשובה הערכה משוקללת סיכון: לא כל טעות צריכה להיחשב באותה מידה.
צרו שער שחרור לשינויים בסוכני AI
סוכני AI משתנים לעיתים קרובות. עריכת פרומפט, עדכון מודל, מקור חדש במאגר הידע, שינוי בסכמת API או הרחבת הרשאה - כולם יכולים להשפיע על ההתנהגות. התייחסו לשינויים האלה כאל שחרורי גרסה לפרודקשן.
לפני הפריסה, הריצו בדיקות רגרסיה מול סט הערכה קבוע והשוו את התוצאות לבסיס הפרודקשן הנוכחי. בחנו את הכשלים לפי חומרה. שיפור קטן באיכות התשובות לא מצדיק שחרור שמגדיל הפרות מדיניות או שגיאות כלים.
בתהליכי עבודה בסיכון גבוה יותר, שחררו בהדרגה. התחילו במצב צל (shadow mode), שבו הסוכן ממליץ אבל לא פועל. לאחר מכן עברו לאישור אנושי, לקבוצות משתמשים מוגבלות או לקטגוריות משימות בסיכון נמוך. נטרו את התוצאות לפני שמרחיבים את האוטונומיה. מסלול ההשקה הנכון תלוי בעלות של טעות ובבשלות של המערכות שמתחת.
נטרו אחרי ההשקה, כי הפרודקשן משנה את הבדיקה
הפרודקשן מביא שפה חדשה, מסמכים חריגים, התנהגות משתמשים משתנה ותנאי אינטגרציה שאף חבילת בדיקות לפני שחרור לא יכולה לחזות במלואם. הניטור הוא חלק מהבדיקות, ולא מטלה תפעולית נפרדת.
אספו טלמטריה מובנית לכל הרצה: סוג המשימה, גרסת המודל והפרומפט, המקורות שנשלפו, קריאות לכלים, זמן תגובה, תוצאה, סיבת הסלמה וקטגוריית כשל. בחנו באופן קבוע מדגם של משימות שהושלמו, עם דגימה כבדה יותר לפעולות בסיכון גבוה ולגרסאות ששוחררו לאחרונה.
צרו התראות לאותות סיכון ברורים, כמו זינוק בכשלי קריאות לכלים, ירידה בשיעורי ההשלמה, ניסיונות חוזרים, יותר עקיפות אנושיות או שינוי פתאומי בנפח ההסלמות. מסלול חזרה לאחור מהיר חשוב בדיוק כמו מסלול פריסה מהיר.
המטרה אינה להוכיח שסוכן לעולם לא יטעה, אלא לבנות סביבו מערכת הפעלה מבוקרת: סמכויות מוגדרות, אינטגרציות שנבדקו, אמצעי הגנה שניתן לאכוף, ביצועים מדידים והתערבות אנושית איפה ששיקול הדעת עדיין נדרש. כך AI הופך לתוכנה שעובדת, ולא למקור נוסף לאי-ודאות תפעולית.
