בדקו את Agent שלכם ב-Playground

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

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

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

איך זה משתלב ב-Humind

AI Agent הוא מרחב התצורה של העוזר הפונה ללקוחות. Knowledge ו-Catalog מספקים עובדות, Guidance מעצב את התנהגות התגובה, Tools מוסיפים פעולות, Escalation מגדיר תמיכה אנושית, ומשטחי בדיקה מאפשרים לכם לבדוק את התוצאה לפני פריסה.

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

לפני שמתחילים

גישה: Playground דורש הרשאת קריאה לתצורת Agent. תיקון המקור עשוי לדרוש גם הרשאת כתיבה ל-Knowledge, ל-Catalog או לתצורת Agent.

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

תהליך עבודה שלב אחר שלב

  1. פתחו סשן Playground חדש

    פתחו את AI Agent ובחרו Playground. Humind פותחת את המשטח הייעודי עבור החברה הפעילה. התחילו שיחה חדשה בעת אימות שינוי במקור, כדי שהודעות קודמות לא ישפיעו על התוצאה.

    תעדו את שינוי התצורה או התוכן שנבדק ואת השאלה המדויקת. אי אפשר לחזור על הצהרה עמומה כמו 'ה-Agent טוב יותר' או לבדוק אותה על ידי חבר צוות אחר.

  2. הריצו סט מאוזן של תרחישים

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

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

  3. בדקו את כל התגובה

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

    כאשר התוצאה נכשלת, זהו את אזור המקור לפני העריכה: Knowledge, Catalog, Guidance, Tools, Escalation, הממשק או הפריסה. תיקון המקור בדרך כלל יוצר תוצאה עמידה יותר מהוספת הוראה רחבה נוספת.

  4. צרו בדיקת רגרסיה ניתנת לחזרה

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

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

  5. סיימו עם בדיקת עשן חיה

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

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

הרשאות והסתייגויות חשובות

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

אמתו את התוצאה

השתמשו ברשימת בדיקה זו לפני שאתם מחשיבים את העבודה למושלמת:

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

פתרון בעיות

Playground לא נפתח

חזרו לסביבת העבודה B2B, אשרו את החברה הפעילה ואת הרשאת הגישה לתצורת Agent, ואז השתמשו שוב בפעולת Playground הנוכחית. אל תסתמכו על URL העברה שנשמר בעבר.

תשובה שתוקנה עדיין נראית ישנה

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

תוצאות אצווה ואינטראקטיביות שונות זו מזו

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

מדריכים קשורים

האם המאמר היה מועיל?