מפיילוט לשימוש אמיתי: מה נדרש מסוכן AI בעסק?

מגדירים על איזו עבודה העסק עומד להסתמך

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

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

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

מהדגמה מוצלחת להוכחה שאפשר לעבוד עם המערכת

מפרידים בין קריאת מידע לבין ביצוע פעולה

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

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

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

בונים בדיקות לפי המשמעות של טעות

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

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

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

דוגמה היפותטית: סיוע במענה על שאלות לגבי הזמנות

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

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

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

לפני ההפעלה, מגדירים גם את התפעול

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

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

שאלות שכדאי לסגור עם צוות הפיתוח

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

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