AI Agentic מוכן לשנות את חווית הלקוח ואת היעילות התפעולית, מה שמחייב גישה אסטרטגית חדשה מצד מנהיגות. התפתחות זו בבינה מלאכותית מעצימה מערכות לתכנן, לבצע ולהתמיד במשימות, מעבר להמלצות פשוטות לפעולה יזומה. עבור צוותי UX, מנהלי מוצר ומנהלים, הבנת השינוי הזה היא חיונית לפתיחת הזדמנויות בחדשנות, ייעול זרימות העבודה והגדרה מחדש של האופן שבו הטכנולוגיה משרתת אנשים. קל לבלבל בין AI Agentic לבין Robotic Process Automation (RPA), שהיא טכנולוגיה המתמקדת במשימות מבוססות כללים המבוצעות במחשבים. ההבחנה נעוצה בנוקשות מול הנמקה. RPA מצוין במעקב אחר תסריט קפדני: אם X קורה, האם Y. זה מחקה ידיים אנושיות. AI סוכן מחקה חשיבה אנושית. הוא אינו עוקב אחר כתב ליניארי; זה יוצר אחד. שקול תהליך עבודה של גיוס עובדים. בוט RPA יכול לסרוק קורות חיים ולהעלות אותם למסד נתונים. הוא מבצע משימה שחוזרת על עצמה בצורה מושלמת. מערכת Agentic בוחנת את קורות החיים, מבחינה שהמועמד מפרט הסמכה ספציפית, מצליב את זה עם דרישת לקוח חדשה ומחליטה לנסח דואר אלקטרוני פרסונלי המדגיש את ההתאמה הזו. RPA מבצעת תוכנית מוגדרת מראש; AI Agentic מגבש את התוכנית על סמך מטרה. האוטונומיה הזו מפרידה בין סוכנים לכלי הניבוי בהם השתמשנו בעשור האחרון. דוגמה נוספת היא ניהול קונפליקטים במפגשים. מודל חיזוי המשולב בלוח השנה שלך עשוי לנתח את לוח הזמנים של הפגישות שלך ואת לוחות הזמנים של הקולגות שלך. אז זה יכול להציע קונפליקטים פוטנציאליים, כגון שתי פגישות חשובות שנקבעו בו-זמנית, או פגישה שנקבעה כאשר משתתף מפתח בחופשה. הוא מספק לך מידע ומסמן בעיות אפשריות, אבל אתה אחראי לנקוט בפעולה. AI סוכן, באותו תרחיש, יעבור מעבר להצעת קונפליקטים שיש להימנע מהם. לאחר זיהוי התנגשות עם משתתף מפתח, הסוכן יכול לפעול על ידי:
בדיקת זמינות כל המשתתפים הדרושים. זיהוי משבצות זמן חלופיות שעובדות עבור כולם. שליחת הזמנות לפגישה חדשה מוצעת לכל המשתתפים. אם הסכסוך הוא עם משתתף חיצוני, הסוכן יכול לנסח ולשלוח דוא"ל המסביר את הצורך לתזמן מחדש ולהציע זמנים חלופיים. עדכון היומן שלך ושל היומנים של הקולגות שלך עם פרטי הפגישה החדשים לאחר אישור.
בינה מלאכותית זו מבינה את המטרה (פתרון קונפליקט הפגישה), מתכנן את השלבים (בדיקת זמינות, מציאת חלופות, שליחת הזמנות), מבצעת את השלבים הללו ונמשכת עד שהקונפליקט ייפתר, והכל עם מינימום התערבות ישירה של המשתמש. זה מדגים את ההבדל "הסוכן": המערכת נוקטת בצעדים יזומים עבור המשתמש, במקום רק לספק מידע למשתמש. מערכות בינה מלאכותית סוכנות מבינות מטרה, מתכננות סדרה של צעדים להשגתה, מבצעות את השלבים הללו, ואפילו מסתגלות אם דברים משתבשים. תחשוב על זה כמו עוזר דיגיטלי פרואקטיבי. הטכנולוגיה הבסיסית משלבת לרוב מודלים של שפה גדולה (LLMs) להבנה והיגיון, עם אלגוריתמים תכנוניים שמפרקים משימות מורכבות לפעולות הניתנות לניהול. סוכנים אלה יכולים לקיים אינטראקציה עם כלים שונים, ממשקי API ואפילו מודלים אחרים של AI כדי להשיג את מטרותיהם, ובאופן קריטי, הם יכולים לשמור על מצב מתמשך, כלומר הם זוכרים פעולות קודמות וממשיכים לעבוד לקראת מטרה לאורך זמן. זה עושה אותם שונים מהותית מ-AI יצירתי טיפוסי, אשר בדרך כלל משלים בקשה בודדת ואז מתאפס. טקסונומיה פשוטה של התנהגויות סוכן אנו יכולים לסווג את התנהגות הסוכן לארבעה אופנים נפרדים של אוטונומיה. למרות שלעתים קרובות אלה נראים כמו התקדמות, הם מתפקדים כמצבי פעולה עצמאיים. משתמש עשוי לסמוך על סוכן שיפעל באופן אוטונומי לתזמון, אך ישאיר אותו ב"מצב הצעה" עבור עסקאות פיננסיות. הסקנו את הרמות הללו על ידי התאמת תקני התעשייה לרכבים אוטונומיים (רמות SAE) להקשרים של חווית משתמש דיגיטלית. התבונן והצע הסוכן מתפקד כמוניטור. הוא מנתח זרמי נתונים ומסמן חריגות או הזדמנויות, אך אינו נוקט בפעולה. בידול שלא כמו הרמה הבאה, הסוכן לא מייצר תוכנית מורכבת. זה מצביע על בעיה. דוגמה סוכן DevOps מבחין ב-CPU של השרת ומתריע למהנדס התורן. הוא לא יודע איך או מנסה לתקן את זה, אבל הוא יודע שמשהו לא בסדר. השלכות על עיצוב ופיקוח ברמה זו,עיצוב ופיקוח צריכים לתת עדיפות להודעות ברורות ולא פולשניות ותהליך מוגדר היטב למשתמשים לפעול בהתאם להצעות. ההתמקדות היא בהעצמת המשתמש עם מידע רלוונטי ורלוונטי בזמן מבלי לקחת שליטה. מתרגלי UX צריכים להתמקד בהצעת הצעות ברורות וקלות להבנה, בעוד שמנהלי מוצר צריכים להבטיח שהמערכת מספקת ערך מבלי להכריע את המשתמש. תכנן-והצע הסוכן מזהה מטרה ומייצר אסטרטגיה רב-שלבית להשגתה. הוא מציג את התוכנית המלאה לסקירה אנושית. בידול הסוכן פועל כאסטרטג. זה לא מבצע; הוא מחכה לאישור על כל הגישה. דוגמה אותו סוכן DevOps מבחין ב-CPU, מנתח את היומנים ומציע תוכנית תיקון:
הפוך שני מקרים נוספים. הפעל מחדש את מאזן העומס. ארכיון יומנים ישנים.
האדם סוקר את ההיגיון ולוחץ על "אשר תוכנית". השלכות על תכנון ופיקוח עבור סוכנים שמתכננים ומציעים, העיצוב חייב להבטיח שהתוכניות המוצעות מובנות בקלות ושהמשתמשים יש דרכים אינטואיטיביות לשנות או לדחות אותן. לפיקוח יש חשיבות מכרעת במעקב אחר איכות ההצעות וההיגיון התכנוני של הסוכן. מתרגלי UX צריכים לעצב הדמיות ברורות של התוכניות המוצעות, ומנהלי מוצר חייבים ליצור זרימות עבודה ברורות של סקירה ואישור. פעל-עם-אישור הסוכן מסיים את כל עבודת ההכנה ומציב את הפעולה הסופית במצב מבוים. זה למעשה מחזיק את הדלת פתוחה, מחכה להנהון. בידול זה שונה מ"תכנן-והצע" כי העבודה כבר בוצעה ומבויימת. זה מפחית חיכוך. המשתמש מאשר את התוצאה, לא את האסטרטגיה. דוגמה סוכן גיוס מנסח חמש הזמנות לראיונות, מוצא שעות פתוחות ביומנים ויוצר את אירועי היומן. הוא מציג כפתור "שלח הכל". המשתמש מספק את ההרשאה הסופית להפעיל את הפעולה החיצונית. השלכות על תכנון ופיקוח כאשר סוכנים פועלים עם אישור, התכנון צריך לספק סיכומים שקופים ותמציתיים של הפעולה המיועדת, תוך תיאור ברור של השלכות אפשריות. הפיקוח צריך לאמת שתהליך האישור חזק ושמשתמשים לא מתבקשים לאשר באופן עיוור פעולות. מתרגלי UX צריכים לעצב הנחיות אישור ברורות ומספקות את כל המידע הדרוש, ומנהלי מוצר צריכים לתעדף נתיב ביקורת חזק עבור כל הפעולות שאושרו. לפעול-אוטונומית הסוכן מבצע משימות באופן עצמאי בתוך גבולות מוגדרים. בידול המשתמש סוקר את היסטוריית הפעולות, לא את הפעולות עצמן. דוגמה סוכן הגיוס רואה התנגשות, מעביר את הראיון למשבצת גיבוי, מעדכן את המועמד ומודיע למנהל המגייס. האדם רואה רק הודעה: ראיון נדחה ליום שלישי. השלכות על תכנון ופיקוח עבור סוכנים אוטונומיים, התכנון צריך לקבוע גבולות ברורים שאושרו מראש ולספק כלי ניטור חזקים. פיקוח דורש הערכה מתמשכת של ביצועי הסוכן בגבולות אלה, צורך קריטי ברישום חזק, מנגנוני עקיפה ברורים ומתגי הרג מוגדרים על ידי המשתמש כדי לשמור על שליטה ואמון המשתמש. מתרגלי UX צריכים להתמקד בעיצוב לוחות מחוונים אפקטיביים לניטור התנהגות סוכנים אוטונומיים, ומנהלי מוצר חייבים להבטיח ניהול ברור והנחיות אתיות.
בואו נסתכל על יישום בעולם האמיתי בטכנולוגיית משאבי אנוש כדי לראות את המצבים האלה בפעולה. שקול "סוכן תיאום ראיונות" שנועד לטפל בלוגיסטיקה של גיוס עובדים.
במצב Suggest הסוכן מבחין שמראיין מוזמן כפול. זה מדגיש את הקונפליקט בלוח המחוונים של המגייס: "אזהרה: שרה הוזמנה כפולה לראיון בשעה 14:00." במצב תוכנית הסוכן מנתח את לוח השנה של שרה ואת הזמינות של המועמד. הוא מציג פתרון: "אני ממליץ להעביר את הראיון ליום חמישי בשעה 10:00. זה דורש להעביר את ה-1:1 של שרה עם המנהל שלה". המגייס סוקר את ההיגיון הזה. במצב אישור הסוכן מנסח את המיילים למועמד ולמנהל. הוא מאכלס את ההזמנות ליומן. המגייס רואה תקציר: "מוכן לתזמן מחדש ליום חמישי. לשלוח עדכונים?" המגייס לוחץ על "אשר". במצב אוטונומי הסוכן מטפל בסכסוך באופן מיידי. זה מכבד כלל שנקבע מראש: "תעדוף תמיד ראיונות מועמדים על פני 1:1 פנימיים." זה מזיז את הפגישה ושולח את ההתראות. המגייס רואה ערך ביומן: "נפתרהתנגשות בלוח הזמנים של מועמד ב'".
פריימר מחקר: מה לחקור ואיך פיתוח בינה מלאכותית אפקטיבית דורשת גישת מחקר מובהקת בהשוואה לתוכנה מסורתית או אפילו בינה מלאכותית גנרטיבית. האופי האוטונומי של סוכני בינה מלאכותית, יכולתם לקבל החלטות והפוטנציאל שלהם לפעולה יזומה מחייבים מתודולוגיות מיוחדות להבנת ציפיות המשתמש, מיפוי התנהגויות מסוכנים מורכבות וציפייה לכשלים פוטנציאליים. הפריימר המחקרי הבא מתאר שיטות מפתח למדידה ולהערכת ההיבטים הייחודיים הללו של AI סוכן. ראיונות מנטליים-מודלים ראיונות אלה חושפים את הדעות הקדומות של המשתמשים לגבי האופן שבו סוכן AI צריך להתנהג. במקום פשוט לשאול מה המשתמשים רוצים, ההתמקדות היא בהבנת המודלים הפנימיים שלהם לגבי היכולות והמגבלות של הסוכן. עלינו להימנע משימוש במילה "סוכן" עם המשתתפים. זה נושא מטען מדע בדיוני או שהוא מונח שמתבלבל בקלות מדי עם סוכן אנושי המציע תמיכה או שירותים. במקום זאת, מסגר את הדיון סביב "עוזרים" או "המערכת". עלינו לגלות היכן משתמשים מותחים את הגבול בין אוטומציה מועילה ובקרה פולשנית.
שיטה: בקש מהמשתמשים לתאר, לצייר או לספר את האינטראקציות הצפויות שלהם עם הסוכן בתרחישים היפותטיים שונים. בדיקות מפתח (המשקפות מגוון תעשיות): כדי להבין את גבולות האוטומציה הרצויה והחרדות הפוטנציאליות סביב אוטומציה יתר, שאל: אם הטיסה שלך תבוטל, מה היית רוצה שהמערכת תעשה אוטומטית? מה ידאיג אותך אם זה יעשה את זה ללא הוראה מפורשת שלך?
כדי לחקור את הבנת המשתמש את התהליכים הפנימיים והתקשורת הדרושה של הסוכן, שאל: תארו לעצמכם שעוזר דיגיטלי מנהל את הבית החכם שלכם. אם חבילה נמסרת, אילו צעדים אתה מתאר לעצמך שהיא לוקחת, ואיזה מידע היית מצפה לקבל?
כדי לחשוף ציפיות לגבי שליטה והסכמה בתהליך רב-שלבי, שאל: אם אתה מבקש מהעוזר הדיגיטלי שלך לקבוע פגישה, אילו צעדים אתה רואה את זה מבצע? באילו נקודות היית רוצה שיתייעצו או יתנו לך בחירות?
יתרונות השיטה: חושף הנחות מרומזות, מדגיש תחומים שבהם ההתנהגות המתוכננת של הסוכן עשויה לחרוג מציפיות המשתמש, ומודיעה על עיצוב מנגנוני בקרה ומשוב מתאימים.
מיפוי מסעות סוכן: בדומה למיפוי מסע משתמש מסורתי, מיפוי מסעות סוכן מתמקד במיוחד בפעולות הצפויות ובנקודות ההחלטה של סוכן ה-AI עצמו, לצד האינטראקציה של המשתמש. זה עוזר לזהות באופן יזום מלכודות פוטנציאליות.
שיטה: צור מפה ויזואלית המתארת את השלבים השונים של פעולת הסוכן, מההתחלה ועד ההשלמה, כולל כל הפעולות, ההחלטות והאינטראקציות הפוטנציאליות עם מערכות או משתמשים חיצוניים. מרכיבי מפתח למפה: פעולות סוכן: אילו משימות או החלטות ספציפיות מבצע הסוכן? כניסות/פלטי מידע: אילו נתונים זקוק הסוכן, ואיזה מידע הוא מייצר או מתקשר? נקודות החלטה: היכן הסוכן עושה בחירות, ומהם הקריטריונים לבחירות אלו? נקודות אינטראקציה עם משתמש: היכן המשתמש מספק קלט, סוקר או מאשר פעולות? נקודות כשל: חשוב לזהות מקרים ספציפיים שבהם הסוכן עלול לפרש הוראות לא נכון, לקבל החלטה שגויה או ליצור אינטראקציה עם הישות הלא נכונה. דוגמאות: נמען שגוי (למשל, שליחת מידע רגיש לאדם הלא נכון), משיכת יתר (למשל, תשלום אוטומטי העולה על הכספים הזמינים), פרשנות שגויה של הכוונה (למשל, הזמנת טיסה לתאריך שגוי עקב שפה לא ברורה).
נתיבי שחזור: כיצד הסוכן או המשתמש יכולים להתאושש מתקלות אלו? אילו מנגנונים קיימים לתיקון או התערבות?
יתרונות השיטה: מספקת ראייה הוליסטית של הזרימה התפעולית של הסוכן, חושפת תלות נסתרת, ומאפשרת תכנון פרואקטיבי של אמצעי הגנה, טיפול בשגיאות ונקודות התערבות של משתמשים כדי למנוע או להפחית תוצאות שליליות.
בדיקת התנהגות פסולה מדומה: גישה זו נועדה לבדוק את המערכת ולצפות בתגובות המשתמשים כאשר סוכן ה-AI נכשל או חורג מהציפיות. מדובר בהבנת תיקון אמון ותגובות רגשיות במצבים שליליים.
שיטה: במחקרי מעבדה מבוקרים, הציגו בכוונה תרחישים שבהם הסוכן עושה טעות, מפרש לא נכון פקודה או מתנהג באופן בלתי צפוי. סוגי "התנהגות לא נכונה" לסימולציה: פקודהפרשנות שגויה: הסוכן מבצע פעולה מעט שונה ממה שהמשתמש התכוון (למשל, מזמין שני פריטים במקום אחד). עומס/עומס מידע: הסוכן מספק יותר מדי מידע לא רלוונטי או לא מספיק פרטים קריטיים. פעולה לא רצויה: הסוכן נוקט פעולה שהמשתמש לא רצה או ציפה לה במפורש (למשל, קניית מניות ללא אישור). כשל במערכת: הסוכן קורס, לא מגיב או מספק הודעת שגיאה. דילמות אתיות: הסוכן מקבל החלטה עם השלכות אתיות (למשל, תעדוף משימה אחת על פני אחרת על סמך מדד בלתי צפוי).
מיקוד תצפית: תגובות משתמשים: איך משתמשים מגיבים רגשית (תסכול, כעס, בלבול, אובדן אמון)? ניסיונות שחזור: אילו צעדים משתמשים נוקטים כדי לתקן את התנהגות הסוכן או לבטל את פעולותיו? מנגנוני תיקון אמון: האם מנגנוני השחזור או המשוב המובנים של המערכת עוזרים להחזיר את האמון? כיצד המשתמשים רוצים לקבל מידע על שגיאות? שינוי מודל נפשי: האם ההתנהגות השגויה משנה את הבנת המשתמש לגבי היכולות או המגבלות של הסוכן?
יתרונות השיטה: חיוני לזיהוי פערי עיצוב הקשורים לשחזור שגיאות, משוב ובקרת משתמש. הוא מספק תובנות לגבי מידת הגמישות של המשתמשים בפני כשלים של סוכנים ומה נדרש כדי לשמור או לבנות מחדש אמון, מה שמוביל למערכות סוכנים חזקות וסלחניות יותר.
על ידי שילוב מתודולוגיות מחקר אלו, מתרגלי UX יכולים לעבור מעבר להפיכת מערכות סוכניות שמישות ליצירת אמון, שליטה וחשבון, תוך טיפוח מערכת יחסים חיובית ופרודוקטיבית בין המשתמשים לסוכני ה-AI שלהם. שימו לב שאלו אינן השיטות היחידות הרלוונטיות לחקר בינה מלאכותית אפקטיבית. קיימות שיטות רבות אחרות, אך אלו נגישות ביותר למתרגלים בטווח הקרוב. כיסיתי בעבר את שיטת הקוסם מארץ עוץ, שיטה קצת יותר מתקדמת לבדיקת מושגים, שהיא גם כלי רב ערך לבחינת מושגי AI אנטי. שיקולים אתיים במתודולוגיית מחקר בעת מחקר AI סוכן, במיוחד כאשר מדמים התנהגות לא נכונה או שגיאות, שיקולים אתיים הם המפתח שיש לקחת בחשבון. ישנם פרסומים רבים המתמקדים במחקר UX אתי, כולל מאמר שכתבתי עבור Smashing Magazine, הנחיות אלו ממכון UX Design ודף זה מתוך ערכת הכלים לעיצוב כולל. מדדי מפתח עבור AI Agentic תזדקק לסט מקיף של מדדי מפתח כדי להעריך בצורה יעילה את הביצועים והאמינות של מערכות בינה מלאכותית. מדדים אלו מספקים תובנות לגבי אמון המשתמש, דיוק המערכת וחווית המשתמש הכוללת. על ידי מעקב אחר אינדיקטורים אלה, מפתחים ומעצבים יכולים לזהות אזורים לשיפור ולהבטיח שסוכני AI פועלים בצורה בטוחה ויעילה. 1. שיעור התערבות עבור סוכנים אוטונומיים, אנו מודדים הצלחה לפי שתיקה. אם סוכן מבצע משימה והמשתמש אינו מתערב או הופך את הפעולה בתוך חלון מוגדר (לדוגמה, 24 שעות), אנו סופרים זאת כקבלה. אנו עוקבים אחר שיעור ההתערבות: באיזו תדירות אדם קופץ לעצור או לתקן את הסוכן? שיעור התערבות גבוה מעיד על חוסר התאמה באמון או בהיגיון. 2. תדירות פעולות לא מכוונות לכל 1,000 משימות מדד קריטי זה מכמת את מספר הפעולות שבוצעו על ידי סוכן הבינה המלאכותית שלא היו רצויות או צפויות על ידי המשתמש, מנורמל לכל 1,000 משימות שהושלמו. תדירות נמוכה של פעולות לא מכוונות מסמלת AI מיושר היטב שמפרש במדויק את כוונת המשתמש ופועל בתוך גבולות מוגדרים. מדד זה קשור קשר הדוק להבנת ההקשר של הבינה המלאכותית, ליכולתה לבלבל פקודות ולחוסן פרוטוקולי הבטיחות שלה. 3. שיעורי ביטול או ביטול מדד זה עוקב אחר התדירות שבה משתמשים צריכים להפוך או לבטל פעולה שבוצעה על ידי ה-AI. שיעורי החזרה גבוהים מצביעים על כך שה-AI עושה שגיאות תכופות, מפרש הוראות שגוי או פועל בדרכים שאינן תואמות את ציפיות המשתמש. ניתוח הסיבות מאחורי ההחזרות הללו יכול לספק משוב רב ערך לשיפור האלגוריתמים של ה-AI, הבנת העדפות המשתמש והיכולת שלו לחזות תוצאות רצויות. כדי להבין מדוע, עליך ליישם סקר מיקרו על פעולת הביטול. לדוגמה, כאשר משתמש הופך שינוי בתזמון, הנחיה פשוטה יכולה לשאול: "זמן לא נכון? אדם לא נכון? או שפשוט רצית לעשות זאת בעצמך?" מתן אפשרות למשתמש ללחוץ על האפשרות המתאימה ביותר להגיון שלו. 4. זמן לפתרון לאחר שגיאה מדד זהמודד את משך הזמן שלוקח למשתמש לתקן שגיאה שנעשתה על ידי ה-AI או למערכת ה-AI עצמה להתאושש ממצב שגוי. זמן קצר עד לפתרון מצביע על תהליך שחזור שגיאות יעיל וידידותי למשתמש, שיכול להפחית את תסכול המשתמש ולשמור על פרודוקטיביות. זה כולל את הקלות של זיהוי השגיאה, הנגישות של מנגנוני ביטול או תיקון, והבהירות של הודעות השגיאה שמסופקות על ידי ה-AI.
איסוף מדדים אלה מצריך מכשירי המערכת שלך כדי לעקוב אחר מזהי פעולה של סוכן. כל פעולה נפרדת שהסוכן נוקט, כמו הצעת לוח זמנים או הזמנת טיסה, חייבת ליצור מזהה ייחודי שנשאר ביומנים. כדי למדוד את שיעור ההתערבות, איננו מחפשים תגובה מיידית של המשתמש. אנו מחפשים את היעדר פעולת נגד בתוך חלון מוגדר. אם מזהה פעולה נוצר בשעה 9:00 בבוקר ואף משתמש אנושי לא משנה או מחזיר את המזהה הספציפי הזה עד השעה 9:00 בבוקר למחרת, המערכת מתייגת אותו באופן הגיוני כמקובל. זה מאפשר לנו לכמת הצלחה בהתבסס על שתיקת משתמש ולא על אישור אקטיבי. עבור תעריפי החזרה, הספירות הגולמיות אינן מספיקות כי הן חסרות הקשר. כדי ללכוד את הסיבה הבסיסית, עליך ליישם לוגיקת יירוט בפונקציות ביטול או החזרה של היישום שלך. כאשר משתמש הופך פעולה יזומה של סוכן, הפעל סקר מיקרו קל משקל. זה יכול להיות מודל פשוט של שלוש אפשרויות המבקש מהמשתמש לסווג את השגיאה כשגויה עובדתית, חסר הקשר, או העדפה פשוטה לטפל במשימה באופן ידני. זה משלב טלמטריה כמותית עם תובנה איכותית. זה מאפשר לצוותי הנדסה להבחין בין אלגוריתם שבור לבין אי התאמה של העדפות משתמש. מדדים אלה, כאשר הם מעקבים באופן עקבי ומנתחים בצורה הוליסטית, מספקים מסגרת חזקה להערכת הביצועים של מערכות בינה מלאכותית, המאפשרות שיפור מתמיד בשליטה, הסכמה ואחריות. עיצוב נגד הונאה ככל שהסוכנים הופכים ליכולת יותר ויותר, אנו עומדים בפני סיכון חדש: בוצה סוכן. בוצה מסורתית יוצרת חיכוך שמקשה על ביטול מנוי או מחיקת חשבון. בוצה סוכן פועלת הפוך. זה מסיר חיכוך לתקלה, ומקל על המשתמש להסכים לפעולה שתועיל לעסק ולא לאינטרסים שלו. שקול סוכן המסייע בהזמנת נסיעות. ללא מעקות בטיחות ברורים, המערכת עשויה לתעדף חברת תעופה שותפה או מלון עם רווחים גבוהים יותר. היא מציגה את הבחירה הזו כדרך האופטימלית. המשתמש, הבוטח בסמכות המערכת, מקבל את ההמלצה ללא בדיקה. זה יוצר דפוס מטעה שבו המערכת מבצעת אופטימיזציה להכנסות במסווה של נוחות. הסיכון של יכולת דמיונית כוזבת הונאה עשויה שלא לנבוע מכוונת זדון. זה מתבטא לעתים קרובות בבינה מלאכותית כ-Imagined Competence. מודלים של שפה גדולה נשמעים לעתים קרובות סמכותיים גם כשהם לא נכונים. הם מציגים אישור הזמנה כוזב או סיכום לא מדויק באותה ביטחון כעובדה מאומתת. משתמשים עשויים לסמוך באופן טבעי על הטון הבטוח הזה. חוסר התאמה זה יוצר פער מסוכן בין יכולת המערכת לציפיות המשתמש. עלינו לתכנן במיוחד כדי לגשר על הפער הזה. אם סוכן לא מצליח להשלים משימה, הממשק חייב לאותת על כשל זה בבירור. אם המערכת אינה בטוחה, עליה להביע אי ודאות במקום להסוות אותה בפרוזה מלוטשת. שקיפות באמצעות פרימיטיבים תרופת הנגד הן לבוצה והן להזיה היא מקור. כל פעולה אוטונומית דורשת תג מטא נתונים ספציפי המסביר את מקור ההחלטה. משתמשים זקוקים ליכולת לבדוק את שרשרת ההיגיון מאחורי התוצאה. כדי להשיג זאת, עלינו לתרגם פרימיטיביות לתשובות מעשיות. בהנדסת תוכנה, פרימיטיבים מתייחסים ליחידות הליבה של מידע או פעולות שסוכן מבצע. למהנדס זה נראה כמו קריאת API או שער לוגי. למשתמש זה חייב להופיע כהסבר ברור. האתגר העיצובי טמון במיפוי השלבים הטכניים הללו לרציונלים הניתנים לקריאה אנושית. אם סוכן ממליץ על טיסה ספציפית, המשתמש צריך לדעת מדוע. הממשק לא יכול להסתתר מאחורי הצעה גנרית. הוא חייב לחשוף את הפרימיטיבי הבסיסי: Logic: Cheapest_Direct_Flight או Logic: Partner_Airline_Priority. איור 4 ממחיש את זרימת התרגום הזו. אנחנו לוקחים את הפרימיטיבי של המערכת הגולמית - לוגיקה של הקוד בפועל - וממפים אותו למחרוזת הפונה למשתמש. לדוגמה, בדיקה פרימיטיבית של לוח זמנים של פגישה בלוח השנה הופכת לאמירה ברורה: הצעתי 16:00פְּגִישָׁה. רמה זו של שקיפות מבטיחה שפעולות הסוכן ייראו הגיוניות ומועילות. זה מאפשר למשתמש לוודא שהסוכן פעל לטובתו. על ידי חשיפת הפרימיטיבים, אנו הופכים קופסה שחורה לקופסת זכוכית, ומבטיחים שהמשתמשים יישארו הסמכות הסופית על חייהם הדיגיטליים שלהם.
הגדרת הבמה לעיצוב בניית מערכת אגנטית דורשת רמה חדשה של הבנה פסיכולוגית והתנהגותית. זה מאלץ אותנו לעבור מעבר לבדיקות שמישות קונבנציונליות ולתחום של אמון, הסכמה ואחריות. שיטות המחקר שדנו בהן, מחיטוט במודלים מנטליים ועד לסימולציה של התנהגות לא נכונה והקמת מדדים חדשים, מספקות בסיס הכרחי. פרקטיקות אלה הן הכלים החיוניים לזיהוי יזום היכן מערכת אוטונומית עלולה להיכשל, וחשוב מכך, כיצד לתקן את מערכת היחסים של משתמש-סוכן כאשר היא יקרה. המעבר ל-AI סוכן הוא הגדרה מחדש של מערכת היחסים בין משתמש. אנחנו כבר לא מתכננים עבור כלים שפשוט מגיבים לפקודות; אנו מתכננים עבור שותפים הפועלים בשמנו. זה משנה את חיווי העיצוב מיעילות וקלות שימוש לשקיפות, חיזוי ושליטה. כאשר בינה מלאכותית יכולה להזמין טיסה או לסחור במניה ללא לחיצה אחרונה, העיצוב של "הרמפות" ו"הרמפות" שלה הופך להיות בעל חשיבות עליונה. באחריותנו להבטיח שהמשתמשים ירגישו שהם נמצאים במושב הנהג, גם לאחר שהם מסרו את ההגה. המציאות החדשה הזו מעלה גם את תפקידו של חוקר ה-UX. אנחנו הופכים לשומרים של אמון המשתמשים, עובדים בשיתוף פעולה עם מהנדסים ומנהלי מוצר כדי להגדיר ולבדוק את מעקות הבטיחות של האוטונומיה של הסוכן. מעבר להיותנו חוקרים, אנו הופכים לתומכים בבקרת משתמשים, שקיפות ואמצעי הגנה אתיים בתהליך הפיתוח. על ידי תרגום פרימיטיבים לשאלות מעשיות והדמיית תרחישים מהמקרים הגרועים ביותר, נוכל לבנות מערכות חזקות ובטוחות כאחד. מאמר זה תיאר את ה"מה" וה"למה" של חקר AI סוכן. זה הראה שערכות הכלים המסורתיות שלנו אינן מספיקות ושעלינו לאמץ מתודולוגיות חדשות, צופות פני עתיד. המאמר הבא יתבסס על הבסיס הזה, ויספק את דפוסי העיצוב והפרקטיקות הארגוניות הספציפיות שהופכות את השירות של סוכן לשקוף למשתמשים, ומבטיחים שהם יכולים לרתום את הכוח של AI סוכן בביטחון ובשליטה. העתיד של UX עוסק בהפיכת מערכות לאמינות. להבנה נוספת של AI סוכן, אתה יכול לחקור את המשאבים הבאים:
בלוג בינה מלאכותית של גוגל על AI Agentic המחקר של מיקרוסופט על סוכני AI
