למה פרומפטים ואישור ידני לא יצילו את סוכני ה-AI שלכם

למה פרומפטים ואישור ידני לא יצילו את סוכני ה-AI שלכם

פרומפטים הם לא קוד. הם המלצות, ובמקרה הטוב, המודל יחליט להתחשב בהן. אם אתם בונים את האוטומציה העסקית שלכם על התקווה שרשימה ארוכה של הוראות תשמור על סוכן ה-AI שלכם במסלול, אתם בונים על חול.

רוב היזמים ומנהלי הטכנולוגיה מתייחסים לסוכני AI כמו למתמחים שפשוט צריכים ספר הדרכה טוב יותר. הם משקיעים שבועות בליטוש ה-"System Prompt", מוסיפים הוראות כמו "אל תעשה את זה" ו-"תמיד תעשה את ההוא", רק כדי לגלות שהסוכן מתחיל להזות או לשבור פרוטוקולים שלושה ימים אחרי העלייה לאוויר. ואז, כפתרון חירום, הם מוסיפים כפתור "אישור ידני" כרשת ביטחון.

זו טעות. זהו כשל אסטרטגי שיוצר תחושת ביטחון מזויפת בזמן שהוא למעשה מגדיל את הסיכון התפעולי שלכם.

נקודות מפתח

• דעיכת הפרומפט: מודלי שפה מאבדים את הקשר עם ההוראות ככל שהשיחה מתארכת, מה שהופך פרומפטים ארוכים ללא אמינים.
• מלכודת האישור: כפתורי אישור ידניים מובילים ל-"עייפות התראות", מצב שבו בני אדם מאשרים פעולות באופן אוטומטי בלי לבדוק.
• שחיקת ערך: אם אדם חייב לבדוק כל צעד, ה-ROI של האוטומציה פשוט נעלם.
• בטיחות מבנית: אמינות מגיעה מקוד דטרמיניסטי וארכיטקטורה מודולרית, לא מתארים יפים יותר בתוך הפרומפט.

המציאות הטכנית של דעיכת הפרומפט

אנחנו אוהבים לחשוב על חלון ההקשר (Context Window) כעל מרחב עבודה דיגיטלי נקי. הוא לא. הוא דומה יותר לחדר צפוף שבו ה-AI מנסה להקשיב לעשרים אנשים בבת אחת.

ככל שהשיחה או המשימה מתקדמת, מנגנון ה-"Attention" של המודל משתנה. מחקרים על תופעת ה-"Lost in the Middle" מראים שמודלי שפה מצוינים במעקב אחר הוראות שנמצאות ממש בתחילת הפרומפט או ממש בסופו. כל מה שבאמצע הופך לערפל.

כשאתם נותנים לסוכן פרומפט מערכת של 2,000 מילים מלא במקרי קצה, אתם למעשה הופכים אותו לפחות אמין. המודל מתקשה לתעדף איזו הוראה היא החשובה ביותר. אם הסוכן מנהל כרטיס תמיכה ארוך, עד ההחלפה העשירית של הודעות, חוקי הבטיחות שכתבתם בהתחלה מתחרים עם אלפי טוקנים של היסטוריית שיחה.

בסופו של דבר, ההיסטוריה מנצחת. הסוכן שוכח שאסור היה לו להציע זיכוי, או שהוא מתחיל להשתמש בטון דיבור שפסלתם במפורש. אי אפשר לפתור באמצעות פרומפטים את הארכיטקטורה הבסיסית של האופן שבו טרנספורמרים עובדים.

⁨AI Strategy Consulting service⁩

הפסיכולוגיה של כפתור ה-"אישור"

קו ההגנה השני שרוב הצוותים משתמשים בו הוא שלב האישור הידני. זה נשמע הגיוני. "ה-AI יכתוב את המייל, אבל בן אדם ילחץ על שלח".

בפועל, זהו אסון משתי סיבות.

ראשית, ישנה הבעיה של עייפות התראות (Alert Fatigue). בני אדם אינם מסוגלים ביולוגית לשמור על רמת ריכוז גבוהה במשימות חזרתיות. אם סוכן מציג 50 טיוטות נכונות ברצף, המפעיל האנושי יפסיק לקרוא אותן. הוא יתחיל ללחוץ על "אישור" כרפלקס. כך טעויות קטסטרופליות חומקות לייצור. בפעם האחת שה-AI יציע משהו מטורף, האדם כבר יהיה על טייס אוטומטי.

שנית, אישור ידני הורג את הצעת הערך של המוצר. אם הצוות שלכם צריך להשקיע 30 שניות בבדיקה של כל משימה של 10 שניות שה-AI ביצע, לא חסכתם זמן. פשוט שיניתם את אופי העבודה מ-"ביצוע" ל-"בייביסיטר". רוב העובדים שונאים לעשות בייביסיטר לבוטים. זה מרגיש כמו מטלה מעיקה, לא כמו כוח-על.

למה חלוצות בתחום עוזבות את הפרומפטים

חברת Lindy, אחת הסטארט-אפים המובילים בתחום הסוכנים, למדה את זה בדרך הקשה. הם הבינו שכדי לבנות סוכן אוטונומי באמת, הם לא יכולים לסמוך על המשתמש שיהיה המעקה הבטיחותי.

הם עברו לגישה דטרמיניסטית יותר. במקום להגיד ל-AI "תהיה זהיר עם היומן", הם בנו מגבלות קשיחות בקוד סביב כלי היומן עצמו. ה-AI יכול להציע פגישה, אבל הקוד שמתחת בודק התנגשויות עוד לפני שה-AI בכלל רואה את האופציה.

זה ההבדל בין גישת "פרומפט תחילה" לגישת "מוצר תחילה". בגישת מוצר תחילה, משתמשים ב-LLM למה שהוא טוב בו (הסקה ושפה) ומשתמשים בהנדסת תוכנה מסורתית למה שהיא טובה בו (חוקים וגבולות).

⁨Automations for SMBs⁩

איך בונים סוכנים שבאמת עובדים

אם אתם רוצים לעבור את שלב ה-"פרומפט ותקווה לטוב", אתם צריכים לשנות את הארכיטקטורה שלכם.

תפסיקו לבנות סוכנים ענקיים ויודעי-כל. במקום זאת, בנו נחיל של סוכנים קטנים ומתמחים. סוכן אחד עושה את המחקר. סוכן שני מעביר ביקורת על המחקר. סוכן שלישי מעצב את הפלט. לכל אחד מאלה יש פרומפט קטן וממוקד שהרבה יותר קשה להתעלם ממנו.

השתמשו ב-"מעריכים" (Evaluators). במקום שאדם ילחץ על כפתור, תנו ל-LLM שני וזול יותר (כמו GPT-4o-mini) לבדוק את העבודה של ה-LLM הראשי מול צ'ק-ליסט ספציפי. זה מהיר יותר, זול יותר, ולא סובל משעמום.

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

המחיר של מיתוס ה-"אדם בלולאה"

בעלי עסקים רבים מרגישים בטוחים יותר כשיש אדם בלולאה (Human-in-the-loop). הם חושבים שזה מגביל את האחריות שלהם. במציאות, זה לרוב רק דוחה את הבלתי נמנע.

כשאתם מסתמכים על אדם שיתפוס את הטעויות של ה-AI, אתם לא בונים מערכת סקיילבילית. אתם בונים מערכת שבירה. ברגע שהאדם הזה עייף, חולה או לחוץ, המערכת נשברת. אמינות אמיתית מגיעה מבניית מערכת שיודעת להיכשל בחן בלי התערבות אנושית.

שאלו את עצמכם: אם הייתם מסירים את כפתור ה-"אישור" היום, האם העסק שלכם היה שורד? אם התשובה היא לא, אין לכם סוכן AI. יש לכם השלמה אוטומטית יקרה מאוד ובעלת מצבי רוח.

שאלות ותשובות

ש: האם זה אומר שפרומפטים של מערכת הם חסרי תועלת? לא. הם חיוניים לקביעת הכיוון הראשוני והטון. אבל הם לא שכבת אבטחה. תחשבו עליהם כעל מצפן, לא כעל גדר.

ש: איך אני מונע עייפות התראות בצוות שלי? צמצמו את מספר האישורים. בקשו התערבות אנושית רק כשציון הביטחון של ה-AI נמוך או כשהפעולה היא בעלת סיכון גבוה (כמו העברת כספים).

ש: האם עדיף להשתמש בפרומפט אחד גדול או בהרבה קטנים? הרבה קטנים. פרומפטים מודולריים קלים יותר לבדיקה, קלים יותר לניפוי שגיאות, ויש סיכוי גבוה בהרבה שהמודל יעקוב אחריהם בדייקנות.

ש: מה זה מעקה בטיחות דטרמיניסטי? זהו קטע קוד מסורתי שבודק את הפלט של ה-AI לפני שהוא מבוצע. לדוגמה, סקריפט שמוודא שכתובת URL שנוצרה היא אכן תקינה לפני שהיא נשלחת ללקוח.

אם סוכן ה-AI שלכם דורש אדם שיצפה בו עובד, האם אתם באמת עושים אוטומציה, או שאתם פשוט מייצרים סוג חדש של עומס ניהולי?

מהי המשימה האחת שאתם "מאשרים" כרגע ידנית שיכולה לעבור לטיפול של ארכיטקטורת מערכת טובה יותר?