הערכה

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

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

מושגים שקשורים להערכה

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

  • תרחיש: תכונה מבוססת-AI שמאפשרת להפעיל את הבדיקה ולוודא שהיא מקיפה. אתם מתארים את המטרה של המשתמש, והמערכת מדמה באופן אוטומטי את המשתמש ויוצרת שיחות כדי לבדוק את היכולת של הנציג לטפל בתרחיש בצורה יעילה. תרחישים הם דרך שימושית להתנסות ולעזור להגדיר שיחות מושלמות.
  • סימולציה: מתאימה לבדיקת תהליכים עם כמה שלבים. במקום מטרה אחת פתוחה של המשתמש, אתם מחלקים את השיחה לרשימה מסודרת של מטרות (שנקראות גם אבני דרך). המשתמש המדומה עובר על היעדים אחד אחרי השני, ורק אחרי שהקריטריונים להצלחה של היעד הנוכחי מתקיימים הוא עובר ליעד הבא. הסימולציות נותנות לכם את הגמישות של משתמש מדומה, תוך שמירה על השיחה במסלול צפוי.
  • Golden: אידיאלי לבדיקות רגרסיה. אתם מספקים נתיב שיחה ספציפי ו"אידיאלי", וההערכה בודקת אם ההתנהגות של הנציג תואמת לנתיב האידיאלי הזה, כולל קריאות לכלים.

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

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

תגים: אפשר לקבץ מקרי בדיקה באמצעות תגים כדי לנהל אותם בקלות רבה יותר.

יצירת מקרי בדיקה

כדי ליצור מקרי בדיקה לסוכן ולגשת אליהם, לוחצים על הכפתור Evaluate בחלק העליון של Agent Builder. אתם יכולים ליצור ולנהל מקרי בדיקה שמבוססים על golden, תרחיש או סימולציה. בעמודה Type ברשימת מקרי הבדיקה מוצג הסוג של כל מקרה בדיקה.

תרחיש

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

אחרי שהתרחישים האלה פועלים כמו שצריך, אתם יכולים לשמור אותם כשיחות מוזהבות.

כדי ליצור תרחיש:

  1. לוחצים על יצירת תרחיש. מוצגות כמה הצעות לתרחישים.
  2. אתם יכולים ליצור תרחישים על סמך האפשרויות שבחרתם, או ליצור תרחיש חדש מאפס.

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

כדי לשמור תרחיש כשיחת זהב:

  1. בוחרים את התרחיש.
  2. לוחצים על כפתור התפריט בפינה השמאלית העליונה.
  3. לוחצים על שמירה כשיחה לדוגמה.

יעד המשתמש בתרחיש

לכל תרחיש יש מטרה של המשתמש, שמתארת את המטרות של משתמש הקצה כשהוא משתמש באפליקציית הנציג. לדוגמה:

Securely book a specific room at a chosen hotel and receive a confirmation.

על סמך מטרת המשתמש, CX Agent Studio יוצר באופן אוטומטי שיחות שמשמשות להערכה.

משתני תרחיש

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

ציפיות מהתרחיש

כדי לבצע הערכה, צריך להגדיר ציפיות למקרה הבדיקה.

יש שני סוגים של ציפיות:

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

הציפיות יכולות לכלול את התנאים הבאים:

  • חובה שיהיה
  • אסור שיהיה
  • אחרי קריאה לכלי
  • ערך המשתנה

כדי ליצור ציפייה:

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

הדמיה

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

סימולציה היא שלב ביניים בין תרחיש לבין מקרה בדיקה אידיאלי:

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

כדאי להשתמש בסימולציה במקרים הבאים:

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

יצירת סימולציה

  1. עוברים לכרטיסייה Evaluation.
  2. לוחצים על + Add test case.
  3. לוחצים על סימולציה. עורך הסימולציות נפתח עם יעד אחד ריק.
  4. מזינים שם למקרה הבדיקה ומוסיפים תגים.
  5. ממלאים את השדות User goal (מטרת המשתמש) ו-Success criteria (קריטריונים להצלחה) של המטרה הראשונה, ומגדירים את Max turns to achieve (מספר הפניות המקסימלי להשגת המטרה).
  6. לוחצים על הוספת יעד וחוזרים על הפעולה בכל שלב בתהליך, לפי הסדר. פרטים על כל סוג של שלב זמינים במאמר יעדים.
  7. אם רוצים, בקטע Variable Override לוחצים על Add overrides כדי להגדיר משתני סשן לפני שהשיחה מתחילה. אחרי שמוסיפים למקרה הבדיקה לפחות שינוי אחד, הכפתור עם התווית מוחלף בכפתור עם סמל ההוספה (+) לצד הצ'יפים הקיימים של השינויים.
  8. אם רוצים, לוחצים על Add expectations כדי לצרף ציפיות ברמת השיחה שנבדקות מול התמליל כולו.
  9. לוחצים על יצירה.

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

יעדים

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

  • מטרת המשתמש: המשתמש המדומה יוצר ביטויים משלו עד שהקריטריונים להצלחה מתקיימים. השלבים האלה מסומנים בתווית יעד בכלי העריכה. הגדרה:
    • מטרת המשתמש: מה המשתמש המדומה מנסה לעשות בשלב הזה, למשל Ask for a refund on the most recent order.
    • קריטריונים להצלחה: התנאי שקובע אם השלב הושלם, למשל Agent asks for the reason for the refund.
    • מספר התורות המקסימלי להשגת המטרה: מספר התורות המקסימלי שמותר בשלב הזה לפני שהסימולציה תיפסק. ערך ברירת המחדל הוא 3.
    • פרטי משתמש: רמזים אופציונליים לגבי הפרסונה וההקשר שגלויים רק למשתמש המדומה, ולא לנציג. אפשר להשתמש בזה כדי לספק פרטים שהמשתמש יודע, כמו מספר הזמנה או סיבה להתקשרות. כדי להוסיף את השדה הזה, פותחים את תפריט האפשרויות הנוספות של השלב ולוחצים על הוספת פרטי משתמש.
  • ביטוי סטטי: המשתמש המדומה שולח בדיוק את הטקסט שאתם מספקים, בלי ליצור טקסט חדש. כדאי להשתמש באפשרות הזו כשהניסוח המדויק חשוב, למשל כשבודקים איך הנציג מטפל במספר חשבון אלפאנומרי.
  • אירוע: שליחת אירוע עם שם לנציג במקום ביטוי. אפשר להשתמש בזה כדי לשחזר קלט שהוא לא שיחה, כמו אירוע טלפוניה.

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

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

איך הסימולציה פועלת

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

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

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

תוצאות הסימולציה

פותחים את תוצאות הסימולציה כדי לראות את קטע היעדים, שבכותרת שלו מוצג מספר השלבים שהושלמו מתוך המספר הכולל, לדוגמה Goals (2/3). הקטע נפתח אוטומטית אם לא כל השלבים הושלמו. בתוך הקונטיינר יש חלונית אחת לכל שלב, שאפשר לכווץ:

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

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

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

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

עריכת סימולציה כ-YAML

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

evals:
  - name: "billing_refund_request"
    tags:
      - "billing"
    session_parameters:
      product_id: "prod_123"
    steps:
      - goal: "Greet the agent and ask for a refund for product_id."
        success_criteria: "Agent asks for the reason for the refund."
        max_turns: 3
      - goal: "Provide the reason and insist on the refund."
        success_criteria: "Agent agrees to process the refund or escalates."
      - static_utterance: "I want to check my balance."
מפתח YAML שדה במסוף
name שם מקרה הבדיקה
tags תגים
session_parameters שינוי משתנה
goal מטרת המשתמש
success_criteria קריטריונים להצלחה
max_turns מספר התורות המקסימלי להשגת המטרה
response_guide פרטי משתמש
static_utterance שלב של ביטוי סטטי
event שלב האירוע
expectations ציפיות

העורך מאמת את ה-YAML בזמן ההקלדה, ומחיל את הכללים הבאים:

  • המסמך חייב להכיל רשימת evals, והעורך קורא רק את הרשומה הראשונה ברשימה הזו.
  • כל רשומה חייבת לכלול name ושלב אחד לפחות.
  • כל שלב חייב לכלול לפחות אחד מהשדות הבאים: goal,‏ static_utterance או event.
  • כל מפתח ב-session_parameters חייב להיות משתנה שמוצהר באפליקציית הנציג.
  • כל מחרוזת ב-expectations חייבת להיות טקסט ההנחיה של ציפייה שכבר קיימת באפליקציית הנציג. ההתאמה מתעלמת מסוג האותיות (רישיות או קטנות) ומרווחים מסביב. כדי ליצור ציפייה, משתמשים באפשרות הוספת ציפיות בכרטיסייה ממשק משתמש, ואז מפנים להנחיה שלה כאן.
  • מפתחות לא מזוהים ברשומה ברשימה evals נדחים.

זהוב

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

כדי לייבא שיחה מהסימולטור:

  1. מתחילים שיחה באמצעות הסימולטור.
  2. לוחצים על סמל האפשרויות הנוספות (3 נקודות) בפינה השמאלית העליונה של הסימולטור כדי לפתוח את התפריט שלו.
  3. לוחצים על שמירה כגרסת הזהב.
  4. נותנים שם למקרה הבדיקה ולוחצים על Save. הוא יופיע עכשיו בכרטיסייה הערכה.

כדי ליצור מקרה בדיקה מהיסטוריית השיחות:

  1. עוברים לכרטיסייה Evaluation.
  2. לוחצים על + Add test case.
  3. בוחרים באפשרות זהב.
  4. לוחצים על הבא.
  5. לוחצים על בחירה מהיסטוריית השיחות.
  6. בחלון שמופיע, בוחרים את השיחה שרוצים לשמור כמקרה בדיקה מושלם. אפשר לחפש לפי מזהה השיחה.
  7. אם הפעלתם צנזור, בדקו את התשובות והמשתנים של הנציג כדי לראות אם יש צנזור לפני שאתם ממשיכים עם המידע החסר.
  8. לוחצים על הוספה.

כדי ליצור מקרה בדיקה מאפס:

  1. עוברים לכרטיסייה Evaluation.
  2. לוחצים על + Add test case.
  3. בוחרים באפשרות זהב.
  4. לוחצים על הבא.
  5. לוחצים על יצירה מאפס.
  6. בחלון שמופיע, מוסיפים שם לתצוגה של מקרה הבדיקה.
  7. מוסיפים טקסט לקלט של המשתמש ולציפיות מהנציג לפי הצורך. לוחצים על ‎+ Add user input ועל ‎+ Add agent expectation כדי להוסיף תשובות. לוחצים על + Add turn כדי להוסיף למקרה הבדיקה חלק חדש בשיחה.
  8. לוחצים על Create כדי להוסיף את מקרה הבדיקה המושלם לרשימת מקרי הבדיקה.

כדי ליצור מקרה בדיקה משיחה מדומה במקרה בדיקה של תרחיש:

  1. עוברים לדף התוצאות של הרצת ההערכה.
  2. לוחצים על סמל התפריט (שלוש נקודות אנכיות) משמאל לשיחה שנבחרה ולוחצים על שמירה כשיחת זהב.

כדי להעלות קבוצה של מקרי בדיקה מקובץ:

פרטים על פורמט הקובץ ותבנית CSV מופיעים בדף פורמט CSV של מקרי בדיקה מושלמים.

ציפיות גבוהות

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

הציפיות יכולות להיות אחד מהסוגים הבאים:

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

כדי ליצור ציפייה:

  1. לוחצים על מקרה בדיקה ספציפי כדי לפתוח את הפרטים שלו.
  2. בקטע Details, לוחצים על View golden.
  3. פועלים לפי ההוראות בממשק כדי להוסיף או לשנות ציפיות.

הגדרות ההערכה

בשורה הראשונה של רשימת מקרי הבדיקה, אתם יכולים לקבוע את הגדרות ההערכה:

  • גולדן רטריבר:
    • קריטריונים להצלחה או לכישלון: הגדירו את הלוגיקה שלפיה נקבע אם השיחה המדומה הצליחה או נכשלה.
    • רמת הפנייה: הכללים האלה בוחנים כל פנייה בנפרד. אם אחד מהסף האלה לא מתקיים, המדד הספציפי יסומן בצבע אדום ככישלון.
      • דמיון סמנטי: ערך הסף לדמיון סמנטי.
      • תקינות הכלי: ערך הסף לתקינות הכלי.
      • הזיות: אם האפשרות מושבתת, הזיות לא נכללות בציון עובר/נכשל.
    • רמת הציפיות: הכללים האלה בוחנים את הציפיות בתוך תור. אם אחד מהסף האלה לא מתקיים, המדד הספציפי יסומן בצבע אדום ככישלון.
      • ‫Tool correctness: ערך הסף של נכוֹנוּת הכלי.
    • שיטת Golden run: בוחרים בין אימות הפעלה מחדש נאיבי או יציב.
    • כלי מדומה: שימוש בנתונים מדומים במקום בקריאות אמיתיות ל-API בסביבת הייצור.
  • Scenarios:
    • קריטריונים להצלחה או לכישלון בתרחיש: מגדירים את הלוגיקה שלפיה נקבע אם השיחה המדומה עברה או נכשלה.
    • מי מתחיל את השיחה: אתם יכולים להגדיר מי יתחיל את השיחה, המשתמש או המודל.
    • כלי מדומה: שימוש בנתונים מדומים במקום בקריאות אמיתיות ל-API בסביבת הייצור.
  • הערכת אודיו
    • הקלטות להערכת אודיו

הרצת הערכות

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

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

אחרי הרצת ההערכה, המדדים יעודכנו והתוצאות יוצגו.

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

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

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

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

שימוש ב-AI כדי לשפר את מקרי הבדיקה (גרסת טרום-השקה)

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

בסיום ההרצה, יוצגו הצעות מבוססות-AI בדף התוצאות. ‫Gemini יוצר באופן אוטומטי קובץ loss_report שניתן להורדה, שמסכם היבטים של ביצועי הנציג ומדגיש תחומים שאפשר לשפר.

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

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

ייבוא וייצוא

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

כדי לייצא מקרי בדיקה:

  1. בוחרים מקרה בדיקה אחד או יותר.
  2. לוחצים על Export test cases.
  3. בחר פורמט.
  4. המערכת תוריד קובץ ZIP.

כדי לייבא מקרי בדיקה:

  1. לוחצים על + Add test case.
  2. בוחרים באפשרות זהב.
  3. לוחצים על הבא.
  4. מעלים את קובץ ה-ZIP.
  5. אם יש התנגשויות בייבוא, תקבלו הנחיות איך לטפל בהן.
  6. לוחצים על יצירה.

כדי לייצא את ההרצות והתוצאות של ההערכות:

  1. בוחרים הרצה אחת או יותר של הערכה.
  2. לוחצים על הפעלת הייצוא.
  3. בחר פורמט.
  4. המערכת תוריד קובץ ZIP.

מדדים

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

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

נכונות השימוש בכלי

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

שביעות הרצון של המשתמשים מהיעדים

מחושב למקרי בדיקה של תרחיש וסימולציה. שביעות הרצון של המשתמש מהיעד היא מדד בינארי שמיועד להערכות של סימולציית משתמשים. הוא מודד אם המשתמש המדומה חושב שהיעדים שלו הושגו (0=לא, 1=כן). הקלט הוא user_goal כפי שהוגדר על ידי המשתמש המדומה ותמליל השיחה. אם ב-user_goal שסופק לא מצוין יעד מפורש או משתמע, הציון שיוחזר הוא ‎-1.

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

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

השלמת מטרות עסקיות

מדווח רק בסימולציות. במקום ציון אחד לשיחה, כל שלב בסימולציה מדווח בנפרד כהושלם או לא הושלם, יחד עם הסבר לתוצאה. במסוף, בכותרת של קטע היעדים, מופיע סיכום של מספר השלבים שהושלמו מתוך המספר הכולל, לדוגמה Goals (2/3). הספירה כוללת את כל השלבים בסימולציה, כולל שלבים של אמירות סטטיות ואירועים.

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

הזיות

זמין למקרי בדיקה מסוג "גולדן" ותרחישים. ציוני ההזיה מחושבים לכל תשובה שנוצרת. המדד הזה משקף אם הנציג העלה טענות שלא מוצדקות בהקשר של הנציג (0=לא, 1=כן). ההקשר מורכב מכל החלקים הקודמים בשיחה, ממשתני הסשן, מהקריאות לכלים ומההוראות לסוכן. המדד הזה מחושב רק לחלקים בשיחה שמכילים קריאות לפונקציות. הוא לא מזהה הזיות בקריאות לפונקציות. קריאות לפונקציות שניתנות כהקשר נחשבות לנכונות. כדי לצמצם את מספר התוצאות החיוביות השגויות, המדד עשוי להחזיר את הציון "לא רלוונטי" אם התשובה לא מכילה טענות עובדתיות או רק ידע כללי שכבר הוכח.

אפשר להפעיל ולהשבית את ההזיות בהגדרות ההערכה.

התאמה סמנטית

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

ציפיות מהתרחיש

מחושב למקרי בדיקה של תרחיש וסימולציה. המדד הזה בודק אם ההתנהגות של הנציג הייתה משביעת רצון או לא, לפי הציפיות של המשתמשים המדומים (0=לא, 1=כן). יש שני סוגים של ציפיות משתמשים מדומות:

  • ציפיות לקריאה לכלי: מחושבות באופן דומה לנכוֹנוּת הקריאה לכלי, עם החריגים הבאים:
    • התוצאות הן 0 (לא) או 1 (כן).
    • אין קנסות על קריאות לא צפויות לכלים. הציפיות נועדו לציין את קבוצת הקריאות לכלים שחיוניות כדי שהשיחה תעמוד בציפיות של המשתמש המדומה.
    • כשהציפייה לקלט של קריאה לכלי מתממשת, הקריאה מופסקת ומוחלפת בערך החזרה מדומה בזמן הריצה.
  • ציפיות לתגובת הנציג: בדיקה אם תגובה כלשהי של הנציג בשיחה מכילה מחרוזת צפויה.

השלמת המשימה

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

User_Goal_Satisfied AND no_hallucinations_detected AND Expectations Satisfied

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

תפקידים

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

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

התכונה הזו זמינה לשימוש גם עם קלט טקסט וגם עם קלט אודיו.

יצירת פרסונה

  1. כדי ליצור פרסונה, עוברים לכרטיסייה הערכה ולוחצים על ניהול פרסונות (לצד סמל ההגדרות).
  2. לוחצים על + הוספת פרסונה.
  3. בתפריט הקופץ, מזינים שם, אישיות משתמש והקשר משתמש נוסף (כמו גיל, מיקום, סיבת השיחה וכו').
  4. לוחצים על + הוספה.

כדי להריץ הערכה באמצעות פרסונה:

  1. חוזרים לדף הראשי Evaluate ובוחרים תרחיש אחד או יותר או מקרי בדיקה של סימולציה. לוחצים על הפעלת הפריטים שנבחרו.
  2. בחלון הקופץ, בוחרים את הפרסונה שיצרתם בתפריט הנפתח Personas ולוחצים על Run.

שיטות מומלצות להערכות ולטיפוס במעלה ההר (hillclimbing)

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

  • קול וצ'אט
  • SDK ל-SMS ולצ'אט
  • מותג א', ב' וג', וכן הלאה

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

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

  • כדי להתאים את אופן הפעולה (צ'אט לעומת קול) או הערוצים, הפעלת התרחיש מול הפריסה הנכונה מבטיחה התאמה אוטומטית.
  • כל פריסה כוללת את המודאליות, המודל שבו נעשה שימוש והערוץ.
  • בתנאים של משתנים שהוגדרו על ידי ה-builder, מזינים את ערך המשתנה כשמריצים את המקרה. לדוגמה: brand_name == "Cymbal Retail" או brand_name == "Acme Corp".

מבקשים מסוכן התכנות המועדף לשפר את הסוכן ב-CX Agent Studio באופן איטרטיבי עד שכל מקרי הבדיקה יעמדו במדדי היעד או בכל יעד איכות אחר.

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