בודקים סוכן AI לפי תוצאות התהליך, גבולות ההרשאה ומקרי כשל. בונים מאגר בדיקות שניתן להריץ שוב ומחליטים אם לעלות לאוויר לפני שנותנים גישה למערכות העסק.
נכתב בסיוע AI. אלו המלצות מעשיות להגדרת היקף; הדוגמאות הן להמחשה ואינן תוצאות של לקוחות.
בודקים את העבודה, לא את איכות השיחה
סוכן שמחבר בין מכירות לתפעול עשוי לקרוא הזדמנות שאושרה, להכין מסמך העברה ולפתוח משימה פנימית. סיכום משכנע הוא רק חלק מההצלחה. המשימה צריכה להיות משויכת ללקוח הנכון, לשמור על ההיקף שסוכם ולהגיע לאחראי הנכון. סוכן שמנסח תשובה מצוינת אבל מעדכן את הלקוח הלא נכון נכשל בתהליך.
לפני שמריצים את ההדגמה, כותבים תנאי קבלה במשפט אחד: בהינתן הקלט וההרשאות האלה, הסוכן חייב להפיק תוצאה מאומתת מוגדרת, בלי ההשפעות האסורות האלה. מוסיפים מגבלת זמן ואדם שמאשר את התוצאה. המדריך הזה עוסק בתנאי הבדיקה; רשימת ההטמעה הרחבה מכסה את יתר חלקי הפרויקט.
בונים מאגר מקרים עם פעולות רצויות ונקודות עצירה
אוספים דוגמאות מייצגות יחד עם האנשים שמבצעים את העבודה. מסירים מידע אישי שאינו נחוץ ומשתמשים בסביבה מבודדת עם חשבונות בדיקה. כוללים קלט בעברית ובאנגלית אם שתי השפות משמשות בתהליך האמיתי. מפרידים בין דוגמאות שמשמשות לשיפור הסוכן לבין מאגר שמור שמשמש להחלטת ההשקה.
הטבלה היא דף עבודה מוצע להתחלה, לא תקן בדיקה מוסמך. מוסיפים מקרים שמתאימים לתהליך במקום להעתיק את הקטגוריות אוטומטית. לכל מקרה מתעדים מזהה, רשומות התחלתיות, כלים מותרים, מצב סופי רצוי, השפעות אסורות וראיות שנדרשות להכרעה.
| משפחת מקרים | קלט לדוגמה | ראיה להתנהגות תקינה |
|---|---|---|
| שגרה | הזדמנות מאושרת עם פרטי העברה מלאים | משימה אחת אצל הלקוח הנכון, עם אחראי ושדות נדרשים |
| מידע חסר | אין אחראי מסירה מאושר | בקשה ברורה לפרט החסר; בלי להמציא שיוך |
| מידע סותר | ה־CRM וההיקף החתום מציגים תוצרים שונים | שני המקורות מוצגים לבודק; ההיקף שבמחלוקת אינו נדרס |
| גבול הרשאה | הערת לקוח מבקשת לעקוף אישור או לקרוא חשבון אחר | אין קריאה או כתיבה ללא הרשאה; החריגה מגיעה לאחראי |
| אירוע כפול | אותה הזדמנות מאושרת מתקבלת פעמיים | משימה אחת כנדרש, עם טיפול מתועד באירוע החוזר |
| תוצאת כלי לא ודאית | בקשה לפתיחת משימה מסתיימת בהמתנה ללא תשובה לאחר השליחה | בדיקת המצב הקיים או עצירת המקרה; בלי ניסיון עיוור נוסף או הצלחה כוזבת |
מפרידים בין ציוני ביצוע לכשלים שעוצרים השקה
משתמשים בבדיקות ישירות לעובדות: איזו רשומה השתנתה, האם קיים האישור הנדרש והאם נוצרה כפילות. לשיקול דעת משתמשים במחוון כתוב לבודק אנושי: האם הסיכום שומר על ההתחייבויות שסוכמו והאם ההסלמה מסבירה את הסתירה. בודק מבוסס AI יכול לסייע בבדיקת איכות הניסוח, אבל לא להיות הראיה היחידה להרשאות או למצב מסד הנתונים.
Anthropic מבחינה בין המצב הסופי בסביבה לבין תיעוד פעילות הסוכן, וממליצה לשלב שיטות הערכה. Microsoft מתעדת השלמת משימה והערכת שימוש בכלים כממדים נפרדים. אלה מקורות רקע להבחנה עסקית חשובה: אמירה שהעבודה הושלמה אינה שקולה לאימות שהיא אכן בוצעה.
מדווחים בנפרד על השלמה, העברה נכונה לבדיקה, מאמץ הבדיקה האנושית, זמן ועלות. מגדירים מראש אירועים שעוצרים השקה, כמו גישה לחשבון אחר, פעולה חיצונית ללא אישור או אישור כוזב של עדכון מהותי. ממוצע טוב לא אמור להסתיר אירוע כזה. בעל התהליך קובע את הספים; אין אחוז הצלחה אוניברסלי שמתאים לכל סוכן.
דוגמה מחושבת: למה גם 96.7% יכולים לעצור השקה
תרחיש להמחשה, לא תוצאה של לקוח AgenticShip: צוות מכין 60 מקרים לסוכן העברה פנימית. המאגר כולל 20 מקרי שגרה, 10 מקרים עם מידע חסר, 10 סתירות, 10 מקרי גבול הרשאה, חמישה אירועים כפולים וחמש תוצאות כלי לא ודאיות. המספרים ממחישים תוכנית; הם אינם מדגם מספיק מבחינה סטטיסטית או יחס מומלץ לכל תהליך.
הצוות מריץ כל מקרה שלוש פעמים ממצב התחלתי נקי: 60 × 3 = 180 הרצות. ב־174 הרצות מתקבלת התוצאה הצפויה או ההעברה הצפויה לבדיקה, כלומר 174 ÷ 180 = 96.7% בעיגול לספרה אחת. שש הרצות נכשלות. אם כשל אחד יוצר משימה בחשבון אסור, ההשקה נעצרת לפי המדיניות שסוכמה גם כשהנתון הכולל נראה טוב.
מדווחים גם כמה מקרים ייחודיים עברו את כל החזרות ואילו משפחות מקרים נכשלו. חזרה על 60 מקרים אינה יוצרת 180 תרחישים עסקיים עצמאיים. מתקנים את הכשל, מריצים שוב את כל מאגר בדיקות הרגרסיה ושומרים מקרים חדשים להחלטה הבאה. לא מסירים מקרה קשה רק כדי לשפר את הציון.
בודקים את גבולות ההפעלה בלי להשפיע על לקוחות
מבטלים הודעות אמיתיות וכתיבות בלתי הפיכות בסביבת הבדיקה. בודקים הרשאות בגבול המערכת ולא רק בפרומפט: הוראה להימנע מרשומה אינה שקולה לבקרת גישה שמונעת את קריאתה. מתייחסים להוראות בתוך מסמכים מיובאים והערות לקוח כאל תוכן לא מהימן, לא כהרשאה לשנות את תפקיד הסוכן.
לאחר שהרצה חוזרת עוברת, אפשר לשקול הרצת צל שאושרה במפורש: הסוכן מציע פעולות והצוות הקיים ממשיך להיות אחראי לביצוע. גם מצב צל דורש גישה מאושרת לנתונים, כללי שמירה ואחראי. מוודאים שהצעות אינן יכולות להפוך בטעות לשליחות או לכתיבות אמיתיות. משווים את הצעות הסוכן להחלטות העובדים בפועל, כולל מקרים שבהם העובדים חלוקים בדעתם.
הופכים את החלטת ההשקה לתהליך שניתן לחזור עליו
רשומת ההשקה צריכה לציין את גרסאות המודל, הפרומפט, הכלים, המדיניות ומאגר הבדיקה; להציג תוצאות לפי משפחת מקרים; לפרט כשלים פתוחים; ולהגדיר את היקף ההפעלה המותר. מתעדים מי אישר ואיזה אירוע עוצר את הסוכן. פיילוט מוגבל עם פיקוח והפעלה ללא הגבלה הם החלטות שונות.
מריצים שוב את הבדיקות הרלוונטיות כשהמודל, התהליך, הכלים או ההרשאות משתנים. הופכים תקרית מאומתת בשימוש אמיתי למקרה רגרסיה מוגן. אם הסוכן כבר אינו עומד בתנאים, מצמצמים את סמכותו או עוצרים אותו ומשאירים מסלול ידני זמין. התוצר החשוב אינו דשבורד מלא ציונים, אלא החלטה מנומקת לגבי העבודה שהעסק יכול להעביר לסוכן היום.
מקורות ראשוניים
ההנחיות למעלה מתארות את הגישה המוצעת של AgenticShip. המקורות הבאים מספקים רקע טכנולוגי להמלצות הרלוונטיות.