מנטרים סוכני AI לפי תוצאות עסקיות מאומתות, לא לפי תשובות בטוחות בעצמן. מדריך מעשי למדידת השלמה, העברה לאדם, כשלים בכלים, עלויות וחזרה בטוחה לפעילות.
נכתב בסיוע AI. אלו המלצות מעשיות להגדרת היקף; הדוגמאות הן להמחשה ואינן תוצאות של לקוחות.
מנטרים את התוצאה העסקית, לא רק את התשובה
הסוכן אומר שפתח משימת מסירה. הבקשה חזרה בלי שגיאה. אבל האם המשימה קיימת אצל הלקוח הנכון, עם ההיקף שאושר ואחראי לביצוע? הניטור צריך לענות על השאלה הזאת. שרת תקין ותשובה מנוסחת היטב לא מוכיחים שהעבודה העסקית הושלמה.
לפני ההשקה, הבדיקות בוחנות אם התהליך מוכן לעלייה מבוקרת לאוויר. אחרי ההשקה, הניטור בוחן אם כל מקרה אמיתי הגיע למצב תקין ומה השתנה כשהוא לא הגיע אליו. המדריך מציע דף עבודה לשאלה השנייה, לא מדד אוניברסלי או הבטחה שאפשר להפעיל סוכן ללא פיקוח.
מחברים את תיעוד ההרצה לרשומה מאומתת
נותנים לכל מקרה עסקי מזהה קבוע ומקשרים אליו את ניסיונות הביצוע. שומרים את הפעולה המותרת, גרסאות המודל והתהליך, תוצאות הכלים, ההפניה לאישור ומזהה הרשומה הסופית. מפרידים בין ניסיון שהסתיים לבין מקרה שנפתר. ניסיון חוזר הוא עוד ניסיון באותו מקרה, לא בקשת לקוח נוספת שהושלמה.
התיעוד של LangSmith מתאר traces כקבוצות של שלבי ביצוע, ומטא־נתונים כאמצעי לסינון הרצות לפי הקשר כמו גרסת האפליקציה. המאמר של OpenTelemetry על ניטור סוכנים מסביר את תפקיד נתוני הניטור באבחון ובהערכה. אלה אבני בניין טכניות; העסק עדיין צריך להגדיר בעצמו מהי תוצאה מאומתת.
שומרים רק את הראיות שנחוצות להפעלה ולחקירת התהליך. מעדיפים מזהים פנימיים וסיכומים ללא פרטים רגישים על פני הודעות לקוח מלאות. מגבילים גישה, מגדירים תקופת שמירה ומרחיקים סודות מנתוני הניטור. אם אוספים traces מפורטים רק במדגם, שומרים בנפרד רישום מינימלי מלא של התוצאות, כדי שהמדדים לא יספרו רק את המקרים שנכללו במדגם.
בונים טבלת מדדים שחושפת עבודה שלא הסתיימה
בוחרים קבוצה קבועה של מקרים שנכנסו לתהליך ומועד סגירה לדוח, ומציגים את גודל הקבוצה לצד כל שיעור. מוציאים בדיקות באופן מפורש, מאחדים אירועים כפולים ומשאירים מקרים לא פתורים גלויים. את המדדים המוצעים כאן כדאי לפלח לפי גרסת התהליך וסוג מקרה רלוונטי; אחרת שינוי בתמהיל הבקשות הקלות והמורכבות עלול להיראות כמו שיפור באיכות.
| מה מודדים | איזו ראיה שומרים | איזו החלטה זה משרת |
|---|---|---|
| השלמה מאומתת | רשומה סופית תקינה ומזהה מקרה, לא הצהרת הסוכן | האם העבודה שהועברה לסוכן באמת הסתיימה |
| העברה שאדם קיבל לטיפול | נמען מוגדר, סיבה ומועד אישור הקבלה | האם יש אחראי אמיתי לחריגה |
| משך הזמן ללא פתרון | זמן מאז הקליטה, כולל המתנה לאישור ובתור | באילו מקרים צריך להתערב לפני המועד האחרון |
| פעולות כלי חוזרות או לא ודאיות | ניסיונות, בקשות ללא תשובה והתאמה למצב במערכת היעד | האם ניסיון חוזר עלול ליצור פעולה מהותית כפולה |
| עלות ומאמץ בדיקה | עלות כל הניסיונות וזמן הבדיקה האנושית של הקבוצה | האם עדיין משתלם להפעיל את התהליך |
| חריגות מסמכות | פעולה אסורה מאומתת או אישור נדרש שחסר | האם להשעות מיד את ההרשאות שנפגעו |
דוגמה מחושבת: 90% טופלו אינו אומר 90% אוטומציה
דוגמה להמחשה, לא תוצאה של לקוח AgenticShip: השבוע נכנסו לתהליך 200 בקשות ייחודיות שעומדות בתנאי הקבלה. במועד סגירת הדוח, ל־150 יש השלמה מאומתת, 30 הועברו כראוי לאנשים שאישרו קבלת אחריות, ו־20 נותרו ללא פתרון. שיעור ההשלמה הוא 150 ÷ 200 = 75%. העברות שהתקבלו לטיפול הן 15%. מקרים לא פתורים הם 10%.
הנתון המשולב של 90% מתאר השלמה או העברה שהתקבלה לטיפול; הוא לא מתאר השלמה עצמאית. אם 12 מתוך 150 המקרים שהושלמו דרשו תיקון ידני, מציגים אותם בנפרד ולא מסתירים את המאמץ הזה. בקשת אישור שממתינה בתיבת הדואר עדיין ממתינה, ואינה העברה שהתקבלה לטיפול. מגדירים מצבים שאינם חופפים במועד הדוח כדי שאותו מקרה לא ינפח שני סכומים.
נניח שכל הניסיונות בקבוצה עלו 60 דולר בשימוש במודל ובכלים. חלוקה ב־150 השלמות מאומתות נותנת 0.40 דולר של עלות שימוש קבוצתית לכל השלמה מאומתת. זאת אינה העלות המלאה של השירות: זמן עובדים, תשתיות וטיפול ידני בהמשך אינם כלולים. מציגים אותם בנפרד ולא מוציאים ניסיונות שנכשלו מהמונה כדי שהסוכן ייראה זול יותר.
מגדירים כללי עצירה לפני שמגיעה ההתראה
מגדירים לתהליך מגבלות זמן, מספר קריאות לכלים, כשלים חוזרים והוצאה. אוכפים אותן באפליקציה ולא רק כהוראות למודל. חריגה מגיעה למפעיל מוגדר עם מזהה המקרה, המצב שנצפה והפעולה הבטוחה הבאה. היעדר אות ניטור אומר שהמצב אינו ידוע; הוא לא מעיד שהכול תקין.
כתיבה מאומתת ללא הרשאה צריכה להוביל להגבלת היכולת שנפגעה. תוצאה לא ודאית של פתיחת משימה צריכה לעצור את אותו מקרה לבדיקת המצב בפועל, ולא בהכרח לעצור את כל התהליכים האחרים. תור אישורים איטי עשוי לדרוש העברת אחריות ולא החלפת מודל. מתאימים את התגובה לכשל ומשאירים מסלול ידני לעבודה שלא יכולה להמתין.
לפני שחוזרים לפעילות, מאמתים מה כבר קרה במערכת היעד, מונעים ביצוע כפול ומגדירים מי רשאי לאשר את החזרה. עצירה אינה מבטלת הודעה או רשומה שכבר נכתבה. שומרים תיעוד תקרית, מתקנים את הגורם והופכים את הכשל למקרה בדיקה מוגן. לא מריצים מחדש תור שלם באופן עיוור אחרי התיקון.
הופכים את הניטור לחלק משגרת העבודה
מטפלים בחריגות דחופות כשהן מתרחשות וקובעים סקירה שוטפת לפי היקף הפעילות והסיכון בתהליך. בודקים מקרים לא פתורים, מדגם של השלמות שנראות תקינות, תיקונים ידניים ותוצאות לפי גרסה. בוחנים את זמן ההמתנה הכולל לצד זמן התגובה של המודל. תשובה מהירה יותר עדיין יכולה להשאיר את הלקוח ממתין זמן רב יותר לאחראי.
מסיימים כל סקירה בהחלטה מסוימת: להשאיר את ההיקף הקיים, לתקן כשל, לצמצם הרשאות או לבדוק שינוי מוצע. מתעדים אחראי ומועד בדיקה הבא. הניטור מועיל כשהוא משנה את אופן הטיפול בעבודה, לא כשהוא רק מייצר דשבורד מרגיע. מתחילים מתהליך מחובר אחד ומרחיבים רק כשהראיות מצדיקות זאת.
מקורות ראשוניים
ההנחיות למעלה מתארות את הגישה המוצעת של AgenticShip. המקורות הבאים מספקים רקע טכנולוגי להמלצות הרלוונטיות.