Human-in-the-Loop: היכן נשבר הסוכן האוטונומי
סוכן אוטונומי נבדל מצ'אטבוט לא באיכות התשובות, אלא בזכות לפעול: הוא מפעיל בעצמו כלים, כותב למסד נתונים, שולח מיילים ללקוחות ומבצע החזרות. כל עוד הוא פועל על עותק של נתונים בסנדבוקס, שגיאה עולה בהרצה אחת כושלת.
ברגע שניתנת לסוכן גישה לסביבת עבודה, Human-in-the-Loop הופך למחסום היחיד בין פעולה שגויה של הסוכן לבין תוצאה בלתי הפיכה.
זה נשבר במקומות צפויים. פעולה בלתי הפיכה — מיזוג המוני של כפילויות במסד לקוחות, מחיקת ענף, החזרה מאושרת או שינוי הרשאות גישה: ניתן לשחזר דבר כזה רק מגיבוי, וגם זה לא תמיד. הצגת משימה דו-משמעית — הסוכן בוחר פרשנות אחת מתוך כמה ומוביל את השרשרת עד הסוף בביטחון.
מפל שגיאות — שגיאה בשלב הראשון עוברת בדיקה בשלב החמישי, מפני שהסוכן מתייחס למסקנת הביניים של עצמו כאל עובדה מאומתת.
מניתוח מקרי תקלה ב-AI Incident Database עולה כי הנזק נגרם לא ממודל חלש, אלא מהיעדר נקודת אישור לפני שלב בלתי הפיך. שליטת מפעיל לא מוצבת בכל פעולה — אחרת הסוכן מפסיק לחסוך זמן והופך להשלמה אוטומטית יקרה.
נקודות אישור מציבים במקום שבו השלב משנה מצב מחוץ למערכת: כתיבה במסד העבודה, שליחה ללקוח, חיוב, מתן הרשאות. כל השאר נכתב ליומן ומנותח בדיעבד — לפי התיעוד רואים באיזה שלב הסוכן סטה מהמשימה המקורית.
מה נותן מעגל שליטה עם משוב
מעגל Human-in-the-Loop אינו בדיקה לשם בדיקה, אלא סט של נקודות בקרה שבהן מפעיל מאשר או דוחה את החלטת הסוכן. המשוב של המפעיל אינו הולך לאיבוד: כל אישור ותיקון נרשמים ביומן וחוזרים לכללי הסוכן. להלן ארבעה אפקטים שמהם רואים שהמעגל עובד.
שיעור הפעולות השגויות
כל פעולה שעוברת דרך נקודת בקרה מתועדת יחד עם החלטת המפעיל — אושרה, נדחתה או שונתה. נתונים אלה מראים היכן הסוכן טועה באופן שיטתי, והכללים מתוקנים באופן ממוקד. בתרחישים חוזרים שיעור הצעדים השגויים יורד לא באחוזים בודדים, אלא פי כמה, והירידה נשמרת ולא מתבטלת אחרי שבוע.
זמן תגובה לתקלה
כל עוד נקודת הבקרה פועלת במצב אישור, הפעולה השנויה במחלוקת פשוט אינה ממשיכה הלאה — היא ממתינה למפעיל במקום להתבצע. המהנדס רואה את השלב המסוים, את נתוני הקלט ואת היסטוריית ההחלטות בכרטיס אחד, ולכן הניתוח אורך דקות במקום שעות של חפירה בלוגים. מכאן המסקנה הישירה: זמן התגובה לתקלה מתקצר משעות לדקות.
סוג הכשלים שהוסרו
המעגל מכסה לא את כל התקלות, אלא תקלות מוגדרות היטב: פעולות בלתי הפיכות — שליחה, מחיקה, כתיבה למערכת חיצונית — וכן חריגה ממגבלות ומקרים דו-משמעיים שבהם הסוכן אינו בטוח. דווקא סוג כשלים זה עולה ביוקר רב ביותר בניתוח, ודווקא אותו מסיר אישור המפעיל.
העומס על המפעיל
המפעיל לא יבדוק הכול — אחרי יממה הוא יתחיל לאשר בלי להסתכל. לכן סף הביטחון מוגדר: צעדים שגרתיים עוברים אוטומטית, ורק חלק קטן מהפעולות מועבר לאישור. ככל שמצטברים תיקונים, הסף עולה והזרימה למפעיל פוחתת — השליטה נשמרת, והעבודה הידנית מצטמצמת.
מצבי שליטה: השוואת גישות ומגבלות
שליטה על סוכן AI אינה "סימון תיבה", אלא בחירת הנקודה שבה האדם במעגל (Human-in-the-Loop) באמת נחוץ. מצב נוקשה מדי עוצר את הזרימה בפעולות שהסוכן מבצע ללא שגיאה; מצב מתירני מדי מניח לשגיאה לעבור לפעולה בלתי הפיכה. להלן ארבעה מצבים שאותם אנו מגדירים על אותו סוכן ומשלבים לפי סוגי פעולות.
ארבעה מצבי שליטה על סוכן אחד
| מצב שליטה | מתי מתאים | מגבלות |
|---|---|---|
| אישור ידני מלא | צעדים בלתי הפיכים: חיוב, עריכת חוזה, שליחה ללקוח | תפוקת המערכת שווה למהירות המפעיל, הסוכן ממתין בתור |
| בדיקה סלקטיבית לפי כללים | פעולות עם סט תנאים ברור: סכום, קטגוריה, צד מתקשר חדש | את הכללים יש לתחזק, תרחישים לא טיפוסיים נותרים מחוץ לכיסוי |
| בדיקה לפי סף ביטחון | החלטות המוניות מאותו סוג, שבהן הסוכן מעריך את ביטחונו | הסף מכויל על מדגם מתויג, אחרת גדל שיעור ההעברות המיותרות למפעיל |
| אוטומציה מלאה של הקטע | צעדים הפיכים: טיוטות, תיוג, התראות פנימיות | את השגיאה מבחינים מאוחר יותר — יש צורך ביומן פעולות ובשחזור מהיר |
המצבים אינם סותרים זה את זה: תרחיש אופייני הוא אוטומציה מלאה בהכנת נתונים, סף ביטחון באישור, ואישור ידני בשלב הבלתי הפיך. שילוב כזה שומר על מהירות הסוכן במקום שבו הסיכון נמוך, ומשאיר את האדם בדיוק בהחלטות שבהן מחיר הטעות גבוה מעלות הבדיקה. מעבר בין מצבים אנו מבצעים ברמת התצורה, בלי לכתוב מחדש את לוגיקת הסוכן.
שלבי הטמעת שליטה עם משוב
מעגל עם משוב אינו מופעל "ליתר ביטחון" — הוא מוצב בנקודות מסוימות שבהן שגיאת המודל יקרה מעיכוב בתשובה. סדר העבודה אחיד: תחילה מנתחים את מסלול ההחלטות, אחר כך מציבים את הבדיקות, ורק לאחר מכן מוציאים את Human-in-the-Loop לעומס אמיתי. להלן כיצד נראית הטמעת השליטה בפרויקט.
-
ביקורת מסלול ההחלטות. מנתחים כיצד הבקשה עוברת דרך הסוכן: אילו צעדים המודל מבצע בעצמו, היכן הוא משנה נתונים או קורא למערכות חיצוניות, באיזה שלב ההחלטה הופכת לבלתי הפיכה. התוצאה — מפה עם הנקודות שבהן מחיר הטעות מקסימלי.
-
סכימת נקודות בקרה. עבור כל נקודה מגדירים את סוג הבדיקה: אישור לפני הפעולה, בדיקת התוצאה לאחריה, או בקרה סלקטיבית של חלק מהבקשות. חלק מהצעדים נותרים אוטומטיים לחלוטין — שליטה נחוצה במקום שבו היא משנה את התוצאה.
-
כללים וסכימת אסקלציה. מנסחים את התנאים להעברה למפעיל: ביטחון נמוך של המודל, התנגשות עם כלל עסקי, בקשה מעל הסף שהוגדר. מתעדים מה רואה המפעיל, כמה זמן יש לו להגיב, ומה קורה למשימה אם אין תשובה.
-
הרצה מוגבלת. מפעילים את המעגל על חלק קטן מהתעבורה, תחילה במצב תצפית — החלטת המפעיל רק מתועדת ואינה משפיעה על תשובת הסוכן. משווים את ההכרעות, מדייקים ספים, ומסירים התראות שווא.
-
מסירה והדרכת מפעילים. עורכים ניתוח של מקרים שנויים במחלוקת מהרצת הצל, נותנים הנחיות למצבים טיפוסיים ותקנון פעולה בעת תקלה, וממנים אחראי לעדכון הכללים.
-
הרחבה תחת מדדים. את חלק התעבורה מגדילים בהדרגה, תוך מעקב אחר זמן התגובה, שיעור האסקלציות ומספר השחזורים. את הספים ואת רשימת נקודות הבקרה בוחנים מחדש על פי סטטיסטיקה מצטברת, ולא על פי תקלות חד-פעמיות.
תוצרים: סכימות זרימה, מדיניות, תקנונים
לאחר ההטמעה נשארים אצל הלקוח לא רק סוכנים עובדים, אלא גם סט תוצרים שלפיהם ניתן לבדוק את הפתרון, להעביר אותו לצוות אחר ולפתח אותו בלעדינו. אלה מסמכי עבודה הקשורים לתצורה: מעדכנים אותם יחד עם הזרימה, אחרת הם מתרחקים מההתנהגות בפועל של המערכת ומפסיקים לשמש עוגן בניתוח.
הסט המינימלי שאנו מוסרים יחד עם הפתרון:
- סכימת זרימת ההחלטות — היכן הסוכן פועל בעצמו, היכן חובה אישור מפעיל, אילו ענפים נעצרים. לפיה הלוגיקה משוחזרת בלי לקרוא קוד.
- מדיניות גישה של מפעילים — מי מאשר, מי יכול לבטל החלטה, מי רואה נתונים רגישים ולכמה זמן ניתנו ההרשאות. הגישה נשללת עם החלפת עובד.
- תקנון אסקלציה — ספי ביטחון, זמני המתנה מקסימליים, התנהגות בעת אי-זמינות המפעיל: עצירה והעברה הלאה, ולא ניחוש של המודל.
- יומן החלטות — עבור כל הרצה: קלט, גרסת תצורה, ההכרעה ומי שאישר אותה. ניתן לייצא אותו לצורך ניתוח, והוא משמש בסיס ראייתי.
- כללי משוב — כיצד תיקוני המפעיל הופכים לדוגמאות מתויגות, מה עובר לאימון נוסף, ומה די לתקן בכללים.
- תקנון ניתוח תקלות — סיווג כשלים, זמני תגובה, סדר שחזור לגרסה קודמת של הסוכן וקריטריונים לעצירת הזרימה.
- הנחיות למפעיל ותיעוד מסירה — תרחישים טיפוסיים, מקרים שנויים במחלוקת, נקודות ניטור ומדדי איכות במקום אחד.
מקרה בוחן: כיצד הוסר סוג שלם של כשלי סוכן
מעגל התמיכה עבד בהפעלה אוטומטית מלאה: הסוכן ענה ללקוח בעצמו, שינה את סטטוס ההזמנה ויזם החזרה. הלוגים נרשמו, אך לא היה קשר בין צעד הסוכן לתוצאה במערכת — שגיאות צפו בדיעבד, בממוצע כעבור 40 דקות, וכבר בצורת פנייה של הלקוח.
שיעור הפעולות שנדרש להן שחזור ידני הגיע ל-18% במשמרות שיא, ושגיאות קריטיות — סטטוס שהוסר בטעות, החזרה מיותרת — התרחשו 6–8 פעמים בשבוע.
מה שינו
נקודות אישור הוצבו רק על צעדים בלתי הפיכים: חיוב, שינוי סטטוס, שליחת מייל חיצוני. הסוכן נעצר ומעביר למפעיל לא את כל השיחה, אלא כרטיס החלטה: נתוני הקלט, הפעולה המוצעת, ביטחון המודל, קישורים למקורות.
זהו Human-in-the-Loop בצורתו המעשית, ואת תזמור ההפסקות ושמירת המצב בנינו על LangGraph — המשימה אינה הולכת לאיבוד אם המפעיל יחזור אליה מאוחר יותר.
מה השתנה
תחת אישור עברו דווקא הפעולות הבלתי הפיכות, ואת השאר הסוכן מבצע בעצמו: שיעור השחזורים ירד מ-18% ל-2%. שגיאות קריטיות פסקו לא מפני שהמודל נהיה חכם יותר, אלא מפני ששום פעולה בלתי הפיכה אינה מתבצעת בלי מפעיל — במשך רבעון של תצפיות, אף לא אחת.
הזמן החציוני עד להתערבות התקצר מ-40 דקות ל-90 שניות, והמדדים אומתו על שני זרמים בלתי תלויים: תמיכת לקוחות ועיבוד החזרות.
במה נבדל מעגל Human-in-the-Loop מאוטומציה מלאה?
אוטומציה מלאה מניחה שההחלטה מתקבלת על ידי המודל, והאדם מתחבר רק לניתוח התקלות — כבר אחרי המעשה. מעגל Human-in-the-Loop בנוי אחרת: המפעיל מוטמע בתהליך עצמו ומאשר מעברים מסוימים בזמן שהסוכן מבצע אותם. ההבדל אינו במידת האמון במודל, אלא במקום שבו עובר גבול האחריות.
נקודת ההשתלה נקבעת לא ברמת הסוכן כולו, אלא ברמת פעולה בודדת. קריאה, חיפוש, סיווג והכנת טיוטה נשארים בדרך כלל באוטומטיה — הם הפיכים ואינם משנים דבר במערכות חיצוניות. שליחת מייל, חיוב, שינוי רשומה במערכת חשבונאית או קריאה לשירות חיצוני עוברים למעגל האישור. חלוקה כזו של המשימות אינה מקצצת ביכולות הסוכן, אלא מסירה את סוג השגיאות היחיד שאי אפשר לשחזר.
ביטחון מספיק אינו מספר יחיד מתשובת המודל. הוא מורכב מהערכה עצמית של המודל, ממחיר הטעות עבור הפעולה המסוימת, מהפיכותה, ומהמידה שבה מקרה דומה כבר עבר בדיקה. אם הפעולה בלתי הפיכה, הסף עולה עד לאישור חובה בכל ערך שהוא — האוטומטיה פשוט אינה מקבלת כאן זכות ביצוע.
בפועל המעגל עובד כמו תור: הסוכן נעצר, שומר את המצב וההקשר, המפעיל רואה מה בדיוק מוצע לעשות, ומאשר, מתקן או דוחה. לאחר מכן הסוכן ממשיך מאותה נקודה. כל ההחלטות נרשמות ביומן ביקורת: רואים מי אישר את הפעולה ומאיזו סיבה, דבר שחשוב בניתוח תקלות ובביקורות.
לכן השאלה אינה אם לסמוך על האוטומציה או לא, אלא אילו פעולות היא מבצעת בלי לשאול ואילו — רק באישור. אנו מגדירים חלוקה זו בהתאם לתהליך המסוים: מסף הביטחון ועד הרכב התור וכללי האסקלציה.
ספקות טכניים לפני ההטמעה
לפני שמפעילים בדיקה אנושית במעגל קבלת ההחלטות, לצוותי ההנדסה עולות אותן שאלות: כיצד לקבוע את הספים, מי מחזיק את תור הניתוח, ומה קורה כשהתורן אינו זמין. להלן תשובות קצרות, שבדרך כלל הופכות לבסיס של אפיון טכני.
כיצד לכוונן ספים כדי לא לטבוע בהתראות שווא?
בדיקה אנושית אינה מוצבת אחרי המודל, אלא כמפל: תחילה כללים דטרמיניסטיים, אחר כך הערכת ביטחון, ורק מקרים גבוליים מגיעים למפעיל.
את הספים מכיילים על היסטוריית החלטות מצטברת, ולא "בעין", ובוחנים מחדש לפי סטטיסטיקה — אם המפעיל מאשר תשע התראות מתוך עשר, הסף נמוך מדי ומעלים אותו. התראות שווא לא יורדות לאפס, אך שיעורן הופך למדיד ולשליטה.
האם המפעיל לא יהפוך לצוואר בקבוק?
סופרים את זרימת המשימות, את השיעור שמגיע לבדיקה ואת זמן ההחלטה הממוצע — משלושת המספרים האלה רואים כמה אנשים נדרשים למשמרת. בהמשך פועלים לא בגיוס, אלא בארכיטקטורה: סדרי עדיפויות בתור, קיבוץ פניות מאותו סוג, ניתוח אוטומטי של מקרים בעלי ביטחון גבוה. מדדי הבקרה — עומק התור וזמן עד להחלטה: אם הם גדלים, מוקדם להרחיב את הבדיקה, תחילה מצמצמים את תחומה.
מה לעשות אם התורן אינו זמין?
ניתוב נעשה לקבוצה, ולא לאדם מסוים, עם לוח זמנים ומחליף. בתום זמן ההמתנה הפנייה עוברת אסקלציה, והסוכן עובר למצב בטוח: או מפסיק את הפעולה, או עונה בשאלת הבהרה בלי לבצע פעולות בלתי הפיכות. הרשאות לניתוח ניתנות למספר עובדים — נקודת כשל יחידה על תורן אחד אינה קבילה.
ממה להתחיל הרחבה מדורגת של השליטה?
מסוג פעולות אחד עם השלכות בלתי הפיכות: תשלומים, מחיקת נתונים, שליחות חיצוניות. בשבועות הראשונים נרשמות החלטות גם של הסוכן וגם של האדם — זה מספק חומר לכיול הספים ולניתוח מקרים שנויים במחלוקת.
לאחר מכן מעבירים תרחישים למצב אוטומטי אחד אחד, ומשאירים בדיקה ידנית במקומות שבהם מחיר הטעות גבוה מהרווח במהירות.
נדון במשימה ונחזור עם הערכה ותוכנית
את הניתוח מתחילים מהתרחיש שלכם, ולא משיקולים כלליים: בוחנים אילו החלטות הסוכן מקבל בעצמו, היכן נחוצה בדיקה אנושית וכיצד המשוב חוזר למודל. כדי לחזור עם הערכה ותוכנית הטמעה, ולא עם שאלות הבהרה, כדאי לצרף לשיחה הראשונה את הדברים הבאים.
- תרחיש ונקודות בקרה: אילו פעולות של הסוכן דורשות אישור, תיקון או דחייה, ומה קורה בעת סירוב.
- דוגמאות נתונים: 20–50 בקשות ותשובות אמיתיות של הסוכן, כולל כושלות — עליהן מכוונן המעגל עם משוב (Human-in-the-Loop).
- לוגים של פניות מ-2–4 שבועות ומדדים: שיעור ההחלטות שעברו לבדיקה, זמן התגובה של הבודק, סוגי שגיאות חוזרים.
- תקנון: מי מוסמך לאשר, מה נחשב לשגיאה קריטית, מי מנתח את התקלה ובאיזה מועד.
- מפת אינטגרציות: המערכות שאיתן מתחלף הפתרון — תור הפניות, מערכת חשבונאית, בסיס ידע, שער התראות.
- הרשאות גישה: מעגל בדיקה וחשבונות עם ההרשאות המינימליות הנדרשות — המהנדסים משחזרים את התרחיש במלואו בלי לגעת בנתוני העבודה.
- מגבלות: היכן מותר לעבד בקשות, תקופות שמירה, בדיקות חובה והרכב יומן הפעולות.
בהמשך נחזור עם הערכה ותוכנית: שלבים, הרכב העבודות, תפקידים מצדכם. מתחילים בהרצה מוגבלת על תרחיש אחד — כך המעגל נבחן על נתונים חיים, וההרחבה מתבצעת לאחר אישור המדדים.







