ברוב התכנונים של סוכני AI מובנית הנחה שכמעט אף אחד לא בוחן: אם מידע רלוונטי למענה על שאלה, הסוכן אמור להיות מסוגל להשתמש בו.
זה נשמע הגיוני, אבל זה שגוי.
בארגונים שמפעילים פלטפורמות עם כמה קבוצות משתתפים – לקוחות וסוחרים, נוסעים ונהגים, לקוחות וספקי שירות – ההנחה הזו היא מה שהופך בשקט פריסות AI לבעיות אמון.
מלכודת הרלוונטיות
לקוח פונה לתמיכה בעקבות משלוח שהתעכב. הוא רוצה לדעת מה קרה ומבקש החזר.
המידע הרלוונטי ביותר כולל את זמני ההכנה הממוצעים של המסעדה, חלון ההכנה הספציפי של ההזמנה, היסטוריית המסלולים של הנהג וכל התראה שעלתה במהלך הביצוע. כל זה שימושי ישירות ומאפשר תשובה טובה ומדויקת יותר.
אבל זה גם יחשוף נתוני ביצועים תפעוליים של מסעדה ללקוח שאין לו שום סיבה לראות אותם. זה יפליל את התנהגות הנהג בלי הליך הוגן. וזה ייצור קשר ישיר בין התוצאה של צד אחד לנתונים של צד אחר, בלי ידיעת או הסכמת אף אחד מהצדדים.
הסוכן לא טעה – הוא עשה בדיוק את מה שתוכנן לעשות: למצוא את מה שרלוונטי ולהשתמש בו. הטעות הייתה ההנחה שרלוונטיות והרשאה הן אותו דבר.
למה ההבחנה הזו קשה יותר ממה שנראה
במוצר חד-צדדי, רלוונטיות והרשאה בדרך כלל חופפות. המשתמש ששואל את השאלה הוא גם מי שהנתונים שלו בתחום. הפער בין מה שמועיל למה שמותר צר מספיק כדי שרוב הסוכנים יעברו אותו בלי תקלות.
פלטפורמות רב-צדדיות שוברות את ההנחה הזו לחלוטין.
לכל קבוצת משתתפים יש נתונים, תהליכי עבודה וציפיות פרטיות משלה, וגם הגדרה משלה לתוצאה הוגנת. כשסוכן AI פועל מול כולן מתוך בסיס ידע משותף, הוא לא מתנהל בסביבת נתונים אחת. הוא מתנהל בכמה סביבות בו-זמנית, בלי גבולות נוקשים ביניהן.
שוב ושוב מופיעים 3 דפוסי כשל:
דליפת נתונים בין ממשקים. מידע שרלוונטי בממשק אחד שייך למשתתף בממשק אחר. סוכן לקוחות שיכול לראות את היסטוריית המחלוקות של סוחר, פורטל סוחרים שחושף פרטי תלונות של לקוחות, או ממשק נהגים שמתייחס לנתוני אכיפה ברמת הפלטפורמה.
פעולות שיוצרות השלכות שלא נבדקו במקום אחר. החזר שמונפק בממשק הלקוח מפעיל ניכוי מהתשלום בממשק הסוחר. סוכן AI שיכול לבצע את הפעולה הראשונה אבל לא רואה את ההשלכה השנייה יקבל החלטות שנשמעות סבירות ויוצרות בעיות שהוא לעולם לא נתקל בהן. לולאת המשוב לא נסגרת.
יחס לא עקבי לפי קבוצת משתתפים. אותה שאלה בבסיסה – למה התשלום שלי הופחת? – משמעותה שונה מהותית אם שואל אותה סוחר או נהג. הנתונים הזמינים, התגובה המתאימה והפעולות המותרות – כולם שונים. סוכן בלי גבולות ממשק נוקשים מייצר תשובות מדויקות מבחינה טכנית ושגויות מבחינת ההקשר.
אף אחד מאלה אינו באשמת סוכן ה-AI – אלה כשלים בארכיטקטורה. אף אחד לא אמר לסוכן איפה עוברים הקווים.
רלוונטיות היא נקודת פתיחה, לא הרשאה
זו נקודת המבט שחשוב לאמץ: הרלוונטיות צריכה להנחות את מה שהסוכן מחפש, אבל הזכאות צריכה לקבוע למה הוא יכול לגשת בפועל.
2 שאלות נפרדות, שנענות לפי הסדר.
הזכאות קודמת. לפני שהסוכן שולף משהו, הפלטפורמה צריכה כבר לענות: מאיזה ממשק מגיעה האינטראקציה? איזו קבוצת משתתפים מאומתת? אילו נתונים ופעולות נמצאים בתחום עבור הממשק הזה, התפקיד הזה והקשר המדיניות הזה? מה אסור באופן גורף, לא משנה כמה הוא רלוונטי?
אלה לא שאלות שהמודל אמור לחשוב עליהן. אלה אילוצים שהפלטפורמה אוכפת באופן דטרמיניסטי, לפני שהסוכן מתחיל לפעול. הרלוונטיות פועלת אחר כך בתוך האילוצים האלה, ולא במקומם.
ההשפעה המעשית משמעותית. סוכן שתחומו מוגבל לממשק הלקוח לא יכול לחשוף בטעות נתוני סוחרים. לא כי הורו לו שלא לעשות זאת, אלא כי הנתונים האלה מעולם לא היו זמינים לו. אפשר לעקוף הוראות בפרומפט. אי אפשר לעקוף אילוצי זכאות.
ההבחנה הזו חשובה יותר ממה שנראה. "לא אמור להשתמש" ו"לא יכול לגשת" אינן אותה רמת הגנה. בהיקף גדול, בסביבות מורכבות, עם מקרי קצה אמיתיים – רק השנייה מחזיקה.
מה זה אומר בפועל
פלטפורמות שעושות את זה נכון לא בונות סוכנים מוגבלים יותר – הן בונות סוכנים עם ארכיטקטורה טובה יותר. יכולת ההסקה של הסוכן לא משתנה; מה שמשתנה הוא הממשק שעליו הוא מסיק.
התוצאה אינה סוכן פחות מסוגל. זהו סוכן שאפשר לסמוך עליו מול כל קבוצות המשתתפים בו-זמנית. בפלטפורמות רב-צדדיות, זו היכולת שמאפשרת לגדול.
רלוונטיות מביאה אתכם לתשובה טובה. זכאות מביאה אתכם לתשובה אמינה.
ראו את זה על השיחות שלכם.
בקשו הדגמה מותאמת אישית ללא עלות.
