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