סוכני AI מתאוששים באופן דרמטי כאשר נותנים להם הרשאה מפורשת להריץ מחדש את הכלים שלהם, כך מצא המחבר – שינוי ניסוח פשוט העלה את שיעור הצלחת התיקון מ-0.16 ל-1.00. התוצאה, שזכתה לכינוי “action-licensing”, מראה שדחיפה (nudging) של סוכן לבדוק את עבודתו יכולה להיות יעילה הרבה יותר מאשר פשוט ניסוח מחדש של המטרה.
למה התיקון הזה חשוב
עוזרי AI שיכולים לקרוא לכלים חיצוניים (מסדי נתונים, מחשבונים, APIs) נמצאים בשימוש גובר בתהליכי עבודה עסקיים. כאשר הסוכנים הללו טועים, השגיאה לרוב מתפשטת בשקט, ומפיקה תשובות שגויות ללא אותות כשל ברורים. דרך אמינה להתערב מבלי לכתוב מחדש את כל הפרומפט יכולה לחסוך למפתחים זמן ולמנוע טעויות יקרות במערכות ייצור (production).
איך הכשלים באים לידי ביטוי
המחבר הבחין בשני דפוסי כשל נפוצים בעלי נראות נמוכה:
Skipped Lookup (דילוג על חיפוש) – הסוכן יודע שהוא צריך לשלוף פיסת מידע (למשל, שם של מנהל מתוך מזהה ID), אך פשוט ממציא תשובה במקום להפעיל את כלי החיפוש. התגובה ברמת המשטח נראית סבירה, אך הבסיס העובדתי חסר.
Validated Nonsense (שטות מאושרת) – הסוכן מזין נתונים משובשים או שגויים לכלי. הכלי מחזיר תוצאה מבלי להקפיץ שגיאה, והסוכן מתייחס לתוצאה הזו כאישור, ובכך למעשה מאשר את הטעות של עצמו.
שני הדפוסים מותירים את המשתמש עם תשובה בטוחה אך שגויה, והם אינם מפעילים את הסימנים הרגילים של לולאה או חוסר בתגובה שמפתחים עוקבים אחריהם.
הניסוי
כדי למדוד כיצד פרומפטים שונים משפיעים על התיקון, המחבר ערך מבחן מבוקר עם תשובות אמת (ground-truth) קשיחות (ללא דירוג מבוסס LLM). הושוו שתי "דחיפות" (nudges):
דחיפת מטרה בלבד – “התשובה חייבת להיות שם המנהל.” שיעור התאוששות: 0.16.
דחיפת action-licensing – “התשובה חייבת להיות שם המנהל. השתמש בכלים כדי לאמת.” שיעור התאוששות: 1.00 (כל ההרצות שנכשלו תוקנו).
ההבדל היחיד היה ההרשאה המפורשת להריץ מחדש כלי. הפרומפט השני אפשר לסוכן לדעת שהוא יכול לחזור אחורה, לשלוף את המידע החסר, ולדרוס את הניחוש המוקדם שלו. ההרשאה הזו הפכה דחיפה שברוב המקרים הייתה לא יעילה לתיקון מובטח במקרים שנבדקו.
מה המספרים מרמזים
קפיצה מ-0.16 ל-1.00 מרמזת שהמחסום לתיקון לא היה ההבנה של הסוכן לגבי המטרה, אלא החופש הנתפס שלו לפעול. כאשר הפרומפט אומר למודל “אתה יכול לנסות שוב”, הוא מתייחס למצב כתת-משימה חדשה ולא כאל מבוי סתם, מה שמאפשר לשרשרת קריאות הכלים להתחיל מחדש.
מגבלות של תיקונים מבוססי פרומפט בלבד
הניסוי הדגיש גם תרחישים שבהם פרומפטינג לבדו אינו יכול להציל את הסוכן:
אם כלי בשלב מאוחר יותר (downstream tool) מקבל קלט גרוע בשקט ומחזיר ערך, לסוכן אין שום אות לכך שהנתונים שלו היו שגויים. שום ניסוח מחדש לא יגרום לו לזהות את הפגם; הכלי עצמו חייב לאכוף אימות קלט או להקפיץ שגיאה.
סוכנים שמתקשים להפעיל כלים בכלל לעולם לא יפיקו תועלת מהוראת “השתמש בכלים”, מכיוון שהיכולת הבסיסית חסרה. בדיקת תיקון במודלים כאלה מערבבת בין הערכת הפרומפט לבין יכולת קריאת הכלים הבסיסית של המודל.
תובנות מעשיות למפתחים
הענקת הרשאה – כשאתם מתערבים, אמרו לסוכן במפורש שהוא יכול לחזור על קריאת כלי או לחשב מחדש. פשוט ניסוח מחדש של התוצאה הרצויה משאיר לעיתים קרובות את הסוכן תקוע במסלול המקורי והשגוי שלו.
הגנה על הכלים – בנו בדיקות קלט והודעות שגיאה ברורות בתוך הכלים שהסוכן משתמש בהם. זה מונע מ“שטות מאושרת” לחמוק דרך.
זיהוי מוקדם – ככל ששגיאה מזוהה מוקדם יותר, כך קל יותר לפרומפט של הרצה מחדש להצליח. ניטור של חוסר התאמה בין השימוש המצופה בכלי לבין השימוש בפועל יכול להפעיל את פרומפט התיקון ברגע הנכון.
אימות יכולות המודל – לפני שמתבססים על תיקון מבוסס פרומפט, ודאו שהמודל יכול לקרוא לכלים באופן אמין מלכתחילה. אחרת, אתם עלולים למדוד את יעילות הפרומפט על בסיס רעוע.
בשורה התחתונה: מתן הרשאה מפורשת לסוכן AI לבצע מחדש את עבודתו יכול להפוך תיקון חלקי להתאוששות מלאה. מעצבי פרומפטים צריכים להתייחס ל—“השתמש בכלים כדי לאמת” כשסתם בטיחות, ולא כתוספת אופציונלית.