תשובה שגויה של סוכן AI יצאה ללקוח. סדר הפעולות הוא עצירה, שחזור מדויק של מה שקרה, בלימת מה שכבר נשלח והעברה לאדם. עריכת הפרומפט היא המהלך האחרון.
עיקרי הדברים
- הנזק ממשיך להצטבר כל עוד הסוכן פועל. עצירה היא הפעולה הראשונה, גם כשעדיין לא ברור מה קרה.
- תיקון פרומפט לפני שחזור הוא ניחוש, והוא הופך אירוע יחיד לבעיה שאי אפשר לשחזר.
- הבליעה האמיתית היא לא בסוכן אלא במה שכבר יצא: הודעות שנשלחו, רשומות שנכתבו וקבצים שנוצרו.
- כל תשובה שגויה שאושרה כאירוע נכנסת לסט רגרסיה. בלי זה אותה שגיאה תחזור אחרי השינוי הבא.
- אם אין רשומת ריצה מלאה, אין חקירה. זה הפריט היחיד שחייב להיות מוכן מראש.
כשסוכן AI מסר תשובה שגויה, סדר הפעולות הוא עצירה, שחזור, בלימה והעברה לאדם. עריכת הפרומפט היא הפעולה האחרונה ולא הראשונה, כי עורך פרומפט לפני ששחזר את הריצה משנה מערכת שהוא עדיין לא יודע מה עשתה, ומוחק את הראיות תוך כדי.
מה נחשב "תשובה שגויה" שמצדיקה עצירה?
לא כל תשובה לא מוצלחת היא אירוע. ההבחנה עוברת לפי מה שהתשובה גרמה, לא לפי כמה היא נשמעת רע.
| דרגה | מה קרה | פעולה מיידית | מי מיודע |
|---|---|---|---|
| נמוכה | ניסוח חלש, המידע נכון | תיעוד בלבד, ממשיכים | הצוות שאחראי לתוכן |
| בינונית | מידע שגוי שלא הוביל לפעולה | הפסקת התהליך הספציפי | האחראי התפעולי |
| גבוהה | מידע שגוי שהלקוח פעל לפיו | עצירת הסוכן בערוץ הזה | מנהל התחום |
| קריטית | התחייבות, מחיר, תאריך או נתון של לקוח אחר | עצירה מלאה ובלימה | כל מי שנוגע בלקוח |
השורה הקריטית קיימת מפני שהיא לא נפתרת בהודעת תיקון. התחייבות שנמסרה ומחיר שנמסר הם עובדה מול הלקוח גם כשהמערכת טעתה, ושתי הדרגות התחתונות לא מצדיקות עצירה כלל.
הפעולה הראשונה: לעצור, לא לתקן
עצירה בהקשר הזה היא לא כיבוי שרת. היא מתג שמפסיק את הסוכן להשיב בערוץ שבו התקלה קרתה, ומעביר את התנועה לאדם.
- הפסיקו את המענה האוטומטי בערוץ הפגוע בלבד, אם אפשר, ובכולם אם לא.
- אל תמחקו את השיחה, את ההודעה או את הרשומה השגויה. זו הראיה.
- אל תערכו את הפרומפט, את מסמכי המקור או את ההגדרות בשלב הזה.
- רשמו שעה מדויקת של העצירה, כדי לתחום את חלון האירוע.
- קבעו מי מטפל. אירוע בלי בעלים נשאר פתוח.
הסיבה שהעצירה קודמת לכול פשוטה: סוכן שטעה פעם אחת מטעם מסוים ימשיך לטעות מאותו טעם עד שמישהו יעצור אותו. כל דקה נוספת מרחיבה את רשימת הלקוחות שצריך לפנות אליהם.
התנגדות נפוצה היא שעצירה פוגעת בשירות. זה נכון, וזה עדיין המחיר הזול. תור פניות שממתין לאדם נפתר בשעה. שלוש עשרה הודעות שגויות שיצאו בשעה הזאת נפתרות בשיחות טלפון, בזיכויים ובאמון שנשחק. לכן כדאי שהמתג יהיה מוכן מראש ולא יידרש שינוי קוד כדי להפעיל אותו.
איך משחזרים מה באמת קרה בריצה?
השחזור מתחיל מרשומת הריצה ולא מהזיכרון של מי שדיווח. אם הרשומה לא קיימת, זה הממצא הראשון של האירוע.
- אתרו את הריצה לפי מזהה ההודעה או מזהה השיחה, לא לפי שעה משוערת.
- הוציאו את הקלט המדויק כפי שהגיע, כולל מה שהמשתמש כתב לפני כן.
- הוציאו את ההקשר שנשלח למודל: אילו מסמכים נשלפו ובאיזה סדר.
- הוציאו את הפלט הגולמי, לפני עיבוד, וגם את הפלט אחרי העיבוד.
- סמנו את הנקודה הראשונה שבה השניים כבר לא תואמים למציאות.
- הריצו את אותו קלט שוב באותה גרסה, ובדקו אם התוצאה חוזרת.
שלב שש הוא ההבדל בין שני עולמות. תוצאה שחוזרת היא באג יציב שאפשר לתקן ולבדוק. תוצאה שלא חוזרת מצביעה על אקראיות, על הקשר שהשתנה או על מקור שנשלף אחרת, וכל אלה נדרשים לתיקון אחר לגמרי.
שווה גם לרשום מה הייתה התשובה הנכונה, בניסוח מדויק, לפני שממשיכים. בלי זה השלב הבא הופך לוויכוח על מה הסוכן היה אמור לומר, ומקרה הבדיקה שייכתב בסוף לא יהיה ניתן להכרעה אוטומטית.
בלימה: מה שכבר יצא החוצה
הסוכן נעצר, אבל התשובה כבר קיימת בעולם. הבלימה היא רשימת המקומות שהיא הגיעה אליהם, ולא הרגשה שהטיפול הסתיים.
- הודעות שנשלחו ללקוח בכל ערוץ, כולל תזכורות שנקבעו לעתיד.
- רשומות שנכתבו במערכות: משימות, סטטוסים, שדות שעודכנו.
- מסמכים שנוצרו, למשל הצעה או סיכום שנשלח בקובץ.
- פעולות שהופעלו במורד הזרם על ידי אוטומציה אחרת שהאזינה לאותה רשומה.
- לקוחות נוספים שקיבלו את אותה תשובה, אם מדובר בתבנית ולא במקרה יחיד.
הפריט הרביעי הוא זה שנשכח. זרימה שמאזינה לשינוי סטטוס לא יודעת שהסטטוס נכתב בטעות, והיא תמשיך לפעול. סקירת השרשרת שאחרי הסוכן היא חלק מהבלימה, כמו בכל הסלמה בטיפול בפניות.
הדרך המהירה לבנות את הרשימה הזאת היא לשאול על כל מערכת שמחוברת: מה היא עושה כשרשומה משתנה. אם התשובה אינה "כלום", המערכת הזאת נכנסת לרשימת הבלימה. חצי שעה על השאלה הזאת חוסכת שבוע של גילויים מאוחרים.
למה עריכת הפרומפט היא המהלך האחרון?
מפני שהיא מרגישה כמו תיקון והיא בעיקר משנה ראיות. ברגע שהפרומפט השתנה, כבר אי אפשר להריץ מחדש את התנאים שגרמו לתקלה, והתשובה לשאלה "האם זה נפתר" הופכת לבלתי ניתנת לבדיקה.
יש גם סיבה מהותית יותר: לא כל תשובה שגויה מקורה בפרומפט. אותה תופעה יכולה לנבוע ממסמך מקור שהתעדכן, משליפה שהחזירה קטע לא רלוונטי, מכלי חיצוני שהחזיר שגיאה שהמודל התעלם ממנה, או מקלט חריג שאיש לא צפה. שינוי הפרומפט במקרים האלה מוסיף שכבה ולא מסיר גורם. רקע רחב יותר על מקורות הטעות יש באיך מונעים טעויות והזיות של AI.
מה נשאר אחרי שהאירוע נסגר
- רשומת אירוע בעמוד אחד: מה קרה, מתי, מה הגורם, מה נעשה, מה עוד פתוח.
- מקרה בדיקה חדש עם הקלט המקורי והתוצאה הנכונה, שרץ לפני כל שינוי עתידי.
- כלל עצירה מעודכן, אם התברר שהדרגה שהוגדרה לא תפסה את המקרה הזה.
- שיפור בלוגים, אם השחזור נתקע כי שדה מסוים לא נשמר.
- החלטה מפורשת מתי הסוכן חוזר לפעול, ומי מאשר.
סט הרגרסיה הוא הנכס האמיתי. אחרי עשרה אירועים יש עשרה מקרים שנכשלו פעם אחת ואסור שיחזרו, וזה הדבר היחיד שמונע מכל תיקון להיות מקור לתקלה הבאה. מי שמריץ אותם אוטומטית לפני פרסום גם מקבל תשובה מיידית לשאלה אם השינוי האחרון החזיר בעיה ישנה.
מקורות
שאלות נפוצות
מתי עוצרים את הסוכן לגמרי לעומת ערוץ אחד?
עוצרים את הערוץ כשהגורם מזוהה לערוץ מסוים, למשל תבנית או מקור שמשמשים רק שם. עוצרים הכול כשהגורם לא ידוע, כשהתקלה נוגעת לנתוני לקוח, או כשאותה תשובה שגויה כבר הופיעה ביותר ממקום אחד.
מה עושים אם אין לוג של הריצה?
מתייחסים לחוסר כממצא ראשון ולא כמכשול. אוספים את מה שקיים, כולל צילומי מסך של הלקוח, ומוסיפים מיד שמירה של קלט, הקשר שנשלף ופלט גולמי. בלי שלושת אלה כל אירוע עתידי ייחקר באותה איטיות.
האם צריך להודיע ללקוח שהתשובה הייתה שגויה?
זו החלטה עסקית ולא הנדסית, והיא תלויה במה שהלקוח עשה בעקבות התשובה. מה שההנדסה מספקת היא הרשימה המדויקת של מי קיבל מה ומתי, כדי שההחלטה תתקבל על עובדות ולא על הערכה.
איך מבדילים בין טעות חד-פעמית לבעיה שיטתית?
מריצים את אותו קלט שוב באותה גרסה, ואז מחפשים בלוגים ריצות דומות באותו חלון זמן. תוצאה שחוזרת או מספר ריצות דומות מצביעות על בעיה שיטתית. מקרה יחיד שלא משתחזר מטופל בניטור לפני שמשנים משהו.
להמשך קריאה
שירות רלוונטי
סוכני AI
סוכני AI וצ׳אטבוטים מותאמים, מחוברים למערכות האמיתיות של העסק.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.