מסמך אפיון (PRD)

למה LLM-as-a-Judge ולא פתרון פשוט יותר?

אלטרנטיבות שנשקלו

בתהליך החשיבה הראשוני נשקלו שתי חלופות פשוטות יותר:

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

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

1. מסמך אפיון (PRD)

שלב 1 — מה בונים ולמה

מה בונים

תכונה/מוצר בשם AgentEval: פלטפורמת QA אוטומטית לסוכני AI, מבוססת עקרון LLM-as-a-Judge. הפלטפורמה מריצה "לקוחות סינתטיים", פרסונות AI עם אופי ומטרה משלהן, שמנהלות שיחה אמיתית ולא מתוסרטת מול סוכן ה-AI הנבדק. בסיום השיחה, שופט AI נפרד מנתח את התמלול מול המדיניות/נהלים שהוגדרו מראש לסוכן, ומפיק ציון והערכה כתובה, כולל אינדיקציה היכן הסוכן נכשל, אם נכשל.

למה בונים

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

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

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

מי המשתמשים (קהל יעד עיקרי)

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

1. עובד QA: מתמקד במציאת נקודות כשל ספציפיות בשיחה, בכיסוי תרחישים.
2. מנהל מוצר: מתמקד בציון הכולל ובביטחון להחלטת go/no-go לשחרור.
3. מפתח הסוכן: מתמקד בהבנת נקודת הכשל המדויקת בתמלול לצורך תיקון.

הנחות מרכזיות

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

בגרסה הנוכחית (MVP):

• נבדק סוכן AI יחיד בכל פעם.
• קיימות 4 פרסונות קבועות בלבד (ללא אפשרות ליצור פרסונה מותאמת אישית).
• כל שיחה כוללת 4 חילופי דברים (הודעת פרסונה + תגובת בוט, פעמיים).
• השיחה מתנהלת בטקסט בלבד.
• הרצה אחת = פרסונה אחת. לא ניתן להריץ כמה פרסונות במקביל באותה הרצה.

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

מדד הצלחה מרכזי

(לא הוגדר רשמית על ידי הצד העסקי, אך נדרש לצורך מיקוד המוצר)

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

שלב 2 — הפלואו המרכזי

הנחת יסוד לכל הפלואו: כל הרצה בודקת פרסונה אחת מול סוכן AI אחד, ומייצרת דו"ח יחיד בסיומה.

1. הגדרת המדיניות/נהלים של הסוכן הנבדק: המשתמש מגדיר מראש (בטקסט חופשי, ניתן לעריכה) את הנהלים שהסוכן חייב לעמוד בהם, למשל "חובה לאמת זהות לפני חשיפת יתרה" עבור קלירקארד. הנהלים משויכים לסוכן הנבדק.
2. בחירת פרסונה: המשתמש בוחר פרסונה אחת מתוך 4 הפרסונות הקיימות במערכת (רועי אלמוג, VIP בלחץ זמן; מירב שגיא, לקוחה זועמת; יעקב פרידמן, לקוח מבולבל; עידן כרמון, טוען שהובטח לו הכל).
3. הרצת השיחה: המערכת מפעילה את הפרסונה שנבחרה מול הסוכן הנבדק. השיחה מתנהלת בזמן אמת ואינה מתוסרטת מראש, הפרסונה מגיבה דינמית לתשובות הסוכן, לאורך 4 חילופי דברים (הודעת פרסונה ← תגובת סוכן, פעמיים).
4. שיפוט: עם תום 4 חילופי הדברים, שופט AI נפרד מנתח את מלוא תמלול השיחה מול הנהלים שהוגדרו לסוכן בשלב 1.
5. הפקת דו"ח: המערכת מציגה למשתמש דו"ח מפורט הכולל ציון מספרי, הערכה כתובה, ואינדיקציה היכן ואיך הסוכן נכשל (אם נכשל), יחד עם תמלול השיחה המלא.
6. פתיחת הרצה חדשה: לאחר סיום ההרצה, המשתמש יכול להגדיר ולהפעיל הרצה חדשה עם אותה פרסונה או אחרת.

שלב 3 — דרישות פונקציונליות

A. הגדרת מדיניות/נהלים

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

B. פרסונות

• B.1 יש 4 פרסונות קבועות זמינות במערכת: רועי אלמוג (VIP בלחץ זמן, דורש אישור מיידי), מירב שגיא (לקוחה זועמת, כרטיס נחסם בטעות), יעקב פרידמן (לקוח מבולבל, לא זוכר מה סוכם), עידן כרמון (טוען שהובטח לו הכל בלי אימות).
• B.2 כל פרסונה כוללת אופי, מטרה ותרחיש פתיחה קבועים מראש בקוד/בהגדרה, לא ניתנת ליצירה או עריכה בגרסה זו.
• B.3 בכל הרצה נבחרת פרסונה אחת בלבד.

C. הרצת שיחה

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

D. שיפוט (Judge)

• D.1 עם תום 4 חילופי הדברים, שופט AI מנתח את מלוא התמלול.
• D.2 השיפוט מתבסס על הנהלים שהוגדרו מראש לסוכן הנבדק (שלב A).
• D.3 פלט השיפוט כולל ציון מספרי + הערכה כתובה.
• D.4 ההערכה הכתובה כוללת אינדיקציה לנקודה המדויקת שבה הסוכן נכשל, אם נכשל.

E. דו"ח

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

הנחות מרכזיות נוספות:

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

שלב 4 — תרחישים ומקרי קצה

הסוכן הנבדק אינו מגיב / תקלה טכנית

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

הסוכן "נשבר" לפני תום 4 חילופי הדברים

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

הסוכן עומד במלואו בנהלים

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

ניסיון מניפולציה מצד הפרסונה

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

שינוי נהלים לאחר תחילת הרצה

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

שלב 5 — מחוץ לסקופ

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

2. רשימת שאלות פתוחות

נמען: עסקי

נמען: מוצר

נמען: פיתוח

נמען: תפעול