לזכור לקוח לא אומר להשתמש מחדש בכל הודעה ישנה. מגדירים אילו פרטים יכולים להישמר, למי שייך ההקשר ומתי הסוכן צריך לאמת, לתקן או להפסיק להשתמש בהם.
נכתב בסיוע AI. אלו המלצות מעשיות להגדרת היקף; הדוגמאות הן להמחשה ואינן תוצאות של לקוחות.
מפרידים שיחה פתוחה מעובדת לקוח שנשמרת לאורך זמן
לקוח שירות מבקש שיתקשרו אליו אחרי 14:00 היום. כעבור שבועות אותו איש קשר פותח פנייה אחרת. האם סוכן AI עדיין צריך להתייחס להוראה החד־יומית כהעדפה קבועה? זיכרון שימושי מתחיל בהחלטה מה הייתה משמעות האמירה הקודמת, לא בשמירת היסטוריית שיחה ארוכה יותר. זו דוגמת תכנון להמחשה, לא אירוע של לקוח ולא טענה על יכולת AgenticShip שכבר נמסרה.
תיעוד הזיכרון של LangChain מבחין בין מצב שיחה שמוגבל לשרשור לבין מידע ארוך טווח שאפשר לשלוף בין שרשורים באמצעות מאגרים ומרחבי שמות. ההבחנה הטכנית עוזרת למסגר את התכנון, אך אינה קובעת באילו עובדות לקוח מותר לעסק להשתמש שוב. במדריך הזה זיכרון פירושו הקשר שנשמר ביישום, לא הבטחה לגבי שינויים באימון המודל.
שיחה פתוחה, סיכום של מקרה שנסגר והעדפת איש קשר שנבדקה משרתים מטרות שונות. מגדירים באילו מהם הפנייה הבאה יכולה להיעזר. חלון צ׳אט חדש אינו מוכיח שההקשר הישן נעלם, והיסטוריה ארוכה יותר אינה מוכיחה שהסוכן מבין אילו אמירות עדיין חלות.
כותבים כלל קליטה לזיכרון לפני ששומרים פרופיל
לכל פריט שמועמד לשמירה מגדירים אחראי, מקור, נושא, קהל מורשה, מטרה עסקית, מקרה או אתר רלוונטי ותנאי לבדיקה או לפקיעת תוקף. מתעדים גם אם זו אמירת לקוח, עובדה תפעולית שאומתה או הוראה מאושרת. אלו שדות אפיון שאנחנו מציעים, לא טענה שכל פלטפורמת סוכנים מספקת אותם אוטומטית.
מעדיפים פריט קטן עם תחולה ואחריות מוגדרות על פרופיל עמום שמורכב מכל ההודעות. העדפת שפה עשויה להשתייך לאיש קשר מסוים, לא לכל מי שעובד באותה חברה לקוחה. הוראת הגעה זמנית עשויה להשתייך לביקור אחד, לא לכל הזמנה עתידית בכתובת. מזהה חשבון לבדו אינו מבטא את כל ההבדלים האלה.
מסכימים מי יכול לקלוט או לעדכן כל סוג פריט. ייתכן שלסוכן מותר להציע העדפה, בעוד היישום או אדם מורשה מאשרים אותה. מפרידים את ההחלטה הזאת מהטקסט שמסכמים. בקשת לקוח לזכור דבר מה אינה הופכת אותו כשלעצמו למדיניות עסקית או להרשאה לקרוא חשבון אחר.
עוברים על איש קשר אחד ושתי פניות שירות
נבחן את חשבון הלקוח C-41, איש הקשר P-6 ופניית השירות R-18. לאיש הקשר יש העדפה שנבדקה לתקשורת בעברית. בתוך R-18 הוא מבקש שיתקשרו אליו אחרי 14:00 באותו יום, ומציין שחשבונית כבר שולמה. המזהים והפרטים הומצאו לצורך התרגיל.
כש־P-6 פותח בהמשך את R-25, התכנון המוצע יכול להשתמש שוב בהעדפת השפה שנבדקה, אם תחולתה והרשאות הגישה העדכניות מאפשרות זאת. הוא לא אמור להעביר בשקט את הוראת השיחה החד־יומית לפנייה החדשה. אמירת התשלום נשארת טענה מיוחסת למקור לגבי המקרה הקודם, עד שהמערכת הפיננסית האחראית או עובד מורשה מאמתים את הסטטוס הרלוונטי. שליפת הטענה אינה אימות של תשלום.
עכשיו משנים את ההקשר: איש קשר אחר משתמש באותה תיבת דואר ארגונית, או שהמפעיל עובר לחשבון C-92. המערכת צריכה לקבוע את הנושא הנוכחי ואת הרשאות הגישה לפני טעינת פרופיל. לא מאחדים אנשים משום שניסוח ההודעה או כתובת האימייל נראים מוכרים. אם הזהות או התחולה אינן פתורות, מבקשים את המידע החסר או מעבירים לאדם במקום לנחש למי שייך הזיכרון.
משתמשים בטבלה שמגדירה מה יכול לעבור הלאה
מתאימים את טבלת ההחלטות הזאת עם האחראי לתהליך. מטרתה להבהיר באיזה הקשר מותר להשתמש בפנייה הבאה. זו אינה מדיניות שמירה אוניברסלית, מסווג אוטומטי או ראיה לכך שאחת מהבקרות המוצעות כבר מומשה.
| פריט הקשר מועמד | גבול השימוש החוזר המוצע | מה הפנייה הבאה צריכה לבדוק |
|---|---|---|
| העדפת שפה של איש קשר שנבדקה | איש הקשר המסוים ומטרת התקשורת שסוכמה | זהות איש הקשר הנוכחי, הרשאות והאם ההעדפה השתנתה |
| הוראת תזמון או הגעה לביקור אחד | הביקור המקורי ותקופת התוקף שסוכמה | האם הפנייה החדשה באמת עוסקת באותו ביקור; אחרת לא משתמשים בה כברירת מחדל |
| אמירת לקוח שחשבונית שולמה | טענה המיוחסת למקור ומקושרת למקרה שלה | סטטוס שאומת בתהליך האחראי לפני פעולה על סמך תשלום |
| סיכום מקרה שנוצר בידי AI | מגבלות הקהל, התחולה והסטטוס של מקרה המקור | גם הסיכום וגם ההקשר שבבסיסו עדיין מותרים לשימוש |
| טקסט שמבקש לשנות כללים או לחשוף חשבון אחר | תוכן נכנס, לא כלל פעולה שקיבל הרשאה חדשה | גבולות ההוראות וההרשאות הקיימים ממשיכים להיאכף |
בודקים זכאות לפני שמחפשים את הזיכרון הרלוונטי ביותר
קובעים את זהות המפעיל או הלקוח המאומת, את החשבון ואת המקרה מתוך ההקשר המהימן של היישום. משתמשים בהקשר הזה כדי להגביל את השליפה לפני שהחומר מגיע למודל. לא נותנים למזהה לקוח שהמודל יצר או לערך שהועתק מקובץ נכנס להחליט איזה חשבון היישום רשאי לקרוא. רלוונטיות מועילה רק בתוך קבוצת המידע המותרת.
דפוס סינון האבטחה של Azure AI Search מבית Microsoft מספק דוגמה מסוימת: מחרוזות שקשורות לזהות מסננות תוצאות, אך המחרוזות עצמן אינן אימות זהות או הרשאה. הדפוס המתועד דורש את המסנן בכל שאילתה. מכאן נובעת השאלה היכן היישום שלכם אוכף גישה; אין בכך ראיה שמרחב שמות של זיכרון מספק את הבקרה הזאת אוטומטית.
מחילים את אותו גבול על סיכומים ועל הקשר נגזר אחר. סיכום קצר של מקרה מוגבל עדיין יכול לחשוף את המידע שבו. חיבור של שני סיכומים שנראים מותרים יכול גם ליצור הקשר שהמשתמש הנוכחי אינו זכאי לראות. בודקים את החומר שהוחזר בפועל ואת כללי היישום, במקום להסתמך על הנחיה שמבקשת מהסוכן להפריד בין לקוחות.
מגדירים תיקון ופקיעת תוקף מעבר לכפתור מחיקה אחד
נניח ש־P-6 משנה את העדפת השפה, או שאדם מגלה שסיכום קודם שויך לחשבון הלא נכון. מחליטים מי מתקן את הפריט, כיצד בודקים את המקור שלו ואילו מסלולי שליפה מאוחרים יותר צריכים להפסיק להשתמש בגרסה הישנה. כוללים בתרגיל סיכומים שמורים, עותקים ניתנים לחיפוש, מטמונים ושיחות שכבר פתוחות, אם המימוש משתמש בהם.
מסמנים פריט שפג תוקפו או שנמצא במחלוקת כלא כשיר למסלול התשובה הרלוונטי בזמן שהאחראי מטפל בו. שומרים רק את ההיסטוריה המוגבלת שהעסק באמת צריך לפי הכללים שסוכמו. הסרת פריט זיכרון אחד אינה ראיה לכך שכל עותק, יומן ספק או תשובה שכבר הוכנה הוסרו. מאמתים את התנהגות הרכיבים שנבחרו ומתארים במדויק את המגבלות שנותרו.
סיכום צריך לשמר חוסר ודאות. הפיכת הלקוח אומר ששילם לתשלום אושר יוצרת עובדה חדשה שאינה נתמכת. באותה מידה, הוצאת משפט מהמקרה המקורי שלו לא אמורה למחוק את תקופת התוקף או את הקהל שלו. משאירים הפניות למקור וסטטוס זמינים למפעיל שצריך לתקן אותם, בלי להעתיק שיחות פרטיות שלמות ליומני אבחון לא מוגבלים.
בודקים שני חשבונות, שתי פניות ושיחה ישנה
בונים קבוצת בדיקה מבודדת עם רשומות מומצאות ופעולות אמיתיות החוצה מושבתות. משתמשים שוב ב־C-41 וב־P-6 בפניות R-18 ו־R-25, ואז מוסיפים איש קשר אחר וחשבון C-92. בודקים תיבת דואר משותפת, הוראת ביקור שפג תוקפה, טענת תשלום שלא אומתה וטקסט נכנס שמנסה להפוך את עצמו להוראה קבועה. מתעדים את ההקשר המותר הצפוי לפני הפעלת הסוכן.
מתקנים העדפה שמורה אחת ופותחים מחדש שיחה קודמת. מאמתים מה נשלף ונכלל בתשובה הבאה, לא רק מה מסך הפרופיל מציג. אם משתמשים בסיכומים או בתוצאות מטמון, בודקים גם את המסלול שלהם. בודקים פנייה שאין עבורה זיכרון כשיר: סוכן מועיל צריך לשאול או להעביר לטיפול, במקום לשחזר פרטים שהוחרגו מתוך שם מוכר.
מסכימים על תוצאות שחוסמות שחרור, למשל כניסת הקשר מחשבון אחר לתשובה או הפיכת הערה זמנית לכלל קבוע. בודקים גם שפניות רגילות ומורשות ממשיכות לעבוד; סירוב לכל דבר אינו תכנון זיכרון מועיל. התרגיל הממוקד משלים הערכה רחבה יותר של הסוכן ואינו מוכיח הגנה מכל כשל אפשרי.
במימוש ראשון של סוכן AI, מגדירים סוג אחד של עובדה שנשמרת ומסלול תיקון ברור. מרחיבים כשהעסק יכול להסביר מה הועבר הלאה, מדוע היה כשיר לשימוש ואיך מפסיקים להשתמש בו. התוצר הוא גבול הקשר נשלט, לא הבטחה שהסוכן יזכור הכול לתמיד.
מקורות ראשוניים
ההנחיות למעלה מתארות את הגישה המוצעת של AgenticShip. המקורות הבאים מספקים רקע טכנולוגי להמלצות הרלוונטיות.