בנינו אייג'נט לרגע הכי רגיש בחיים, והפרומפטים היו החלק הקל
איך משתמשים ב-AI כדי לעזור לאנשים להתכונן לשיחות מורכבות ברגעים משמעותיים בחיים? כך הצלחנו להציב גבולות ברורים באמצעות ארכיטקטורה דטרמיניסטית, ניהול קונטקסט, Guardrails ו-Evals
ה-LLMs שוברים הנחת יסוד בסיסית: אנחנו לא שולטים מראש בכל פלט שהמערכת תציג למשתמש
מאת איתי צבן
ברוב המוצרים, באג או החלטת UX שגויה פוגעים בעיקר בנוחות השימוש. אבל יש מקרים שבהם נדרשת רגישות גבוהה מאוד – אנחנו, לדוגמה, בונים מוצרים שפוגשים אנשים בתקופות מורכבות במיוחד: אחרי אובדן של אדם קרוב, בזמן התמודדות עם אובדן כושר עבודה, או כשהם נדרשים לקבל החלטות משמעותיות על העתיד. במצבים כאלה, גם לחיכוך הקטן ביותר בין המשתמש לממשק יש משמעות קריטית.
עוד לפני שהכנסנו AI למוצרים, הקפדנו על UX שמפחית עומס, לצד תוכן מדויק והנדסה שמייצרת חוויה יציבה וצפויה. אבל ה-LLMs שוברים כאן הנחת יסוד בסיסית: אנחנו לא שולטים מראש בכל פלט שהמערכת תציג למשתמש. וכשמדובר ב-Voice Agent שמנהל שיחה אישית, האתגר הוא לא רק לגרום למודל לתת תשובה טובה, אלא גם לבנות סביבו מערכת בעלת גבולות דטרמיניסטיים, אפילו אם התנהגות המודל אינה כזאת.
זהו האתגר שאיתו התמודדנו כשבנינו Voice Agent במוצר שעוזר לאנשים להתכונן לעתיד באמצעות כתיבת צוואות, ייפויי כוח ומסמכים נוספים. יצירת המסמך היא אמנם שלב משמעותי, אבל זה לא בהכרח סוף התהליך. אחרי שאדם כתב צוואה, מגיע לעתים החלק המורכב יותר – לספר עליה למשפחה, להסביר את ההחלטות שקיבל, או להכין אדם קרוב לאחריות שתיפול עליו בעתיד. אלה שיחות שאנשים נוטים לדחות, גם אחרי שהמסמכים עצמם כבר מוכנים. ה-Voice Agent מאפשר להתאמן עליהן מראש: לבחור עם מי מדברים, להגדיר את מטרת השיחה ולנהל אותה לפני שעושים את זה מול אדם קרוב.
הרעיון נולד בהאקתון פנימי. צוות של מפתחים ואנשי מוצר בנה POC פשוט: מעט קונטקסט, פרומפט ושיחה קולית, כמעט בלי Guardrails ובלי סיכום בסוף השיחה. הוא עבד מספיק טוב כדי שנרצה לקחת אותו לפרודקשן, ושם התחילה העבודה האמיתית.
לא פותרים כל טעות באותה שכבה
בבדיקות הראשונות של המודל ראינו שני סוגי כשלים: תשובות סבירות מבחינת תוכן, אך לא רגישות מספיק לסיטואציה; ומקרים שבהם הסוכן גלש לייעוץ משפטי מתוך ניסיון להיות מועיל.
לא כל טעות מסוכנת באותה מידה. פספוס של ניואנס פוגע באיכות השיחה, אך המצאת פרט על המשפחה, הנחה לגבי מערכת יחסים או ייעוץ משפטי – אלה התנהגויות שלא רצינו לאפשר להסתברות להגדיר את התוצאה שלהן.
השקענו בעיצוב הפרומפט, אבל מהר מאוד הבנו שהוא לא יכול להיות קו ההגנה היחיד. מכאן נולד העיקרון שליווה את הארכיטקטורה שלנו: החלטה שאפשר לקבל באופן דטרמיניסטי מחוץ למודל – לא משאירים למודל.
האחריות מתחלקת בין שכבות: ה-Business Logic קובע אילו אפשרויות שיחה קיימות, הקונטקסט קובע איזה מידע יגיע לסוכן, הפרומפט מכוון את אופי השיחה, וברמת הפלטפורמה יש Guardrails שמונעים מהסוכן להיכנס לקטגוריות תוכן מסוימות או לחרוג מהגבולות שהוגדרו לו.
הקונטקסט הוא חלק מהארכיטקטורה
בשלב הבא הגדרנו שלפני תחילת השיחה המשתמש בוחר עם מי הוא רוצה להתאמן ומהי מטרת השיחה. ישנם תרחישים ומטרות שהוגדרו מראש, אך האפשרויות מותאמות למידע שכבר קיים במוצר – לדוגמה, שיחה מותאמת לילדים לא תוצע למשתמש שאין לו ילדים בפרופיל.
אותו עיקרון מנחה את בניית הקונטקסט. במקום להעביר לסוכן את מבני הנתונים הפנימיים ולסמוך עליו שיבין מה רלוונטי, בנינו שכבה ייעודית שאוספת מידע מכמה מקורות ומייצרת קונטקסט
מצומצם ומעובד מראש. אפשר לחשוב על השכבה הזאת כחוזה בין המוצר למודל: היא מגדירה לאיזה מידע הסוכן זקוק כדי לנהל שיחה, ושומרת על הפרדה ברורה בין מבנה הנתונים הפנימי לבין המידע שמגיע למודל.
לכל שיחה נשמר Snapshot של הקונטקסט שנשלח. כשחוקרים בדיעבד התנהגות של מערכת גנרטיבית, צריך לדעת מה הסוכן ידע בזמן השיחה – ולא מה היינו שולחים לו אם אותה שיחה הייתה מתחילה היום. יחד עם פרטי השיחה וגרסת הסוכן, זה מה שמאפשר לנו להבין מה בדיוק קרה.
איך מודדים איכות של שיחה גנרטיבית?
בשיחה גנרטיבית אין תשובה אחת נכונה, ולכן Testing מסורתי לא מספיק. זאת הסיבה שבחרנו לעבוד בשלוש שכבות של Evals:
- השכבה הראשונה היא Automated tests, והתפקיד שלה הוא לבדוק תרחישים והתנהגויות שחשוב לנו לשמר.
- השכבה השנייה היא Human evaluation, והיא מטפלת בדברים שקשה להפוך למדד בינארי – רגישות, טבעיות והתאמה לקונטקסט.
- השכבה השלישית מריצה Synthetic agents ו-Synthetic data כדי לדמות משתמשים ותרחישים בקנה מידה גדול, וזאת במטרה לחשוף התנהגויות שלא צפינו מראש.
המידע שמשמש לאבלואציה עובר אנונימיזציה. כך אנחנו יכולים להשוות בין גרסאות ולמדוד כיצד שינוי בפרומפט, בקונטקסט או בהתנהגות הסוכן משפיע על סט שלם של שיחות, ולא להסתמך על דוגמה אחת שנראית טוב.
באופן זה, ה-Evals הופכים לחלק ממחזור הפיתוח: כלי לזיהוי Regressions שעוזר לנו לבדוק אם שינוי מסוים באמת שיפר את המערכת.
מה עושים עם ה-Latency?
בין הרגע שהמשתמש מסיים לומר משפט לרגע שבו הוא שומע תשובה מתרחשים כמה שלבים טכניים. הם שקופים ומבחינתו כולם מתורגמים לזמן המתנה אחד. אך חשוב להבין שבשיחה אישית, גם השהיה קצרה עלולה להישמע כמו היסוס או חוסר הבנה.
לכן, העבודה מתנהלת בשני מישורים: צמצום ה-Latency בפועל, ועיצוב נכון של הזמן שאותו אי אפשר "להעלים". כך זה עובד: עוצמת המיקרופון מניעה את האנימציה בזמן אמת, ובזמן שקט נשמרת תנועה עדינה. המעבר בין Listening ל-Speaking הדרגתי, והכתוביות מציגות חלון יציב של השיחה. המטרה היא לא להסתיר מערכת איטית, אלא לשפר את ה-Perceived Latency ולשמור על תחושה שהמערכת נוכחת ומקשיבה.
מה למדנו בדרך לפרודקשן
בתחילת הפרויקט עסקנו בעיקר בשאלה איזה פרומפט יגרום לסוכן ה-AI לנהל שיחה באופן המיטבי. בדרך שעברנו מאז ההאקתון לפרודקשן, מרכז הכובד עבר לשאלות אחרות: איזה מידע יגיע למודל, אילו החלטות נקבל לפני שנפנה אליו, איפה נציב גבולות שלא תלויים בו ואיך נמדוד את ההתנהגות שלו לאורך זמן.
גם שאלת הלוקליזציה מקבלת משמעות אחרת בממשק קולי. לא מספיק לתרגם את התוכן ואת הפרומפט, כי הרי הקול עצמו הוא חלק מהממשק. בגרסה למשתמשים בבריטניה, לדוגמה, היה עלינו לדאוג שהסוכן ידבר במבטא בריטי, לצד התאמת המונחים והקונטקסט למדינה.
שלושה עקרונות הפכו עבורנו למשמעותיים במיוחד:
- לא להשאיר למודל החלטה שאפשר לקבל באופן דטרמיניסטי.
- להתייחס לקונטקסט כחלק מהארכיטקטורה, ולא כחומר גלם שנדחף לפרומפט.
- להבין שמערכת לא-דטרמיניסטית דורשת Evals ,Observability ו-Debugging טובים יותר.
ב-Voice Agents נוסף לכל זה ממד משמעותי: גם הזמן, הקול והמבטא הם חלק מהממשק. לכן, ככל שאנחנו נותנים לחלק הגנרטיבי יותר חופש לייצר אינטראקציה טבעית, כך אנחנו צריכים להיות מדויקים יותר בכל מה שנבנה סביבו.
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.