איך בודקים סוכן AI לפני שמחברים אותו ללקוחות?

אוספים מקרים מתוך הצורך העסקי

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

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

תשובה בלי בסיס צריכה להיעצר

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

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

פעולות נבדקות מול מצב המערכת

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

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

מגדירים שער להשקה

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

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

ממשיכים לבדוק לאחר שינוי

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

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

שאלות נפוצות