איך מודדים סוכן AI אחרי שהוא עולה לאוויר
# איך מודדים סוכן AI אחרי שהוא עולה לאוויר
אפשר למדוד סוכן AI בעזרת לוח מחוונים מרשים ועדיין לא לדעת אם הוא עושה עבודה טובה. מספר פעולות, זמן תגובה ושיעור אוטומציה מספרים כמה המערכת זזה. הם לא מספרים אם היא זזה לכיוון הנכון.
המדד שמטעה מנהלים במיוחד הוא שיעור האוטומציה: כמה מקרים הסתיימו בלי שאדם התערב. הוא נשמע כמו מבחן יעילות מושלם. בפועל, אם הופכים אותו ליעד המרכזי, מלמדים את המערכת להימנע מהדבר שלפעמים הכי נכון לעשות: לעצור ולהעביר את המקרה לאדם.
העמדה שלי פשוטה. סוכן AI צריך להימדד לפי איכות הסגירה שלו, כולל איכות ההחלטה שלא לסגור. עסק שמודד רק תפוקה יקבל יותר פעולות. עסק שמודד תוצאות, חריגים ונזק אפשרי יקבל מערכת שאפשר לשפר בלי לנחש.
## לוח המחוונים צריך להתחיל בשתי תוצאות, לא בעשרה גרפים
לפני שבוחרים מדדים, צריך להגדיר שתי תוצאות נפרדות.
הראשונה היא תוצאה עסקית. לדוגמה, בקשה מלאה שנפתחה במערכת, פגישה שנקבעה עם כל הפרטים הדרושים, או מסמך שנאסף ונמסר לבעל התפקיד הנכון.
השנייה היא תוצאה בטוחה. אם חסר מידע, קיימת סתירה או הפעולה חורגת מהסמכות, הסוכן עוצר במקום מוגדר ומעביר לאדם חבילה שאפשר לעבוד איתה. גם זו הצלחה. היא פשוט אינה נראית כמו אוטומציה מלאה.
מכאן אפשר לבנות מדידה שימושית. כל ריצה מסתיימת באחד המצבים הבאים: הושלמה נכון, הועברה נכון, נתקעה, או הושלמה באופן שגוי. אין צורך להסתיר את המורכבות בתוך ציון אחד. להפך, ההפרדה היא מה שמאפשר לראות אם הסוכן באמת משתפר.
המסגרת של NIST לניהול סיכוני AI ממליצה להתאים מדדים להקשר שבו המערכת פועלת, לבדוק אותה בתנאים דומים לסביבת העבודה ולנטר את ההתנהגות שלה גם בייצור. זו נקודה חשובה לעסק: מבחן מעבדה ולוח תפוקה אינם תחליף לתיעוד של מה שקרה במקרים אמיתיים.
## שיעור אוטומציה גבוה יכול להיות סימן רע
נניח שסוכן מטפל בבקשות לשינוי מועד אספקה. מתוך מאה בקשות, תשעים הסתיימו בלי מגע יד אדם. המספר נראה מצוין. עכשיו פותחים את עשרת המקרים האחרים ומגלים ששישה הועברו לנציג בגלל מגבלה חוזית, שניים בגלל כתובת לא ברורה ושניים בגלל תקלה בחיבור.
עד כאן הכול סביר. אבל צריך לפתוח גם מדגם מתוך תשעים המקרים שנסגרו. אם הסוכן אישר שינוי בשתי הזמנות שכבר יצאו למחסן, שיעור האוטומציה לא ירד. להפך, הוא קיבל קרדיט על פעולה שהיה צריך לעצור.
זו הסיבה שלא נכון להציב יעד כמו "להגיע ל־95 אחוז אוטומציה" בלי להגדיר קודם מה אסור להשלים אוטומטית. המדד יוצר לחץ לכיוון אחד בלבד. הוא מתגמל מהירות ועצמאות, אך אינו גובה מחיר על ביטחון מופרז.
מדד טוב יותר הוא שיעור הסגירה התקינה מתוך המקרים שהסוכן היה רשאי לסגור. המכנה משנה הכול. מקרים שחייבו אישור אנושי אינם כישלון של המערכת ואינם צריכים לדחוף אותה לעקוף את האישור.
## ארבעה מספרים שמספרים את הסיפור האמיתי
אין מדד יחיד שמספיק. לצורך תפעול שוטף אני מעדיף ארבעה מספרים, שלכל אחד מהם שאלה ברורה.
**סגירה תקינה:** כמה מהמקרים הסתיימו בתוצאה העסקית שהוגדרה, עם כל השדות והראיות הנדרשים? בודקים את זה מול מערכת היעד או במדגם אנושי, לא לפי הודעת "בוצע" שהסוכן כתב לעצמו.
**העברה מוצדקת:** כמה מקרים הועברו לאדם מסיבה שנכללה בכללי העצירה? כאן כדאי להפריד בין העברה טובה לבין העברה עצלה. סתירה במחירון היא סיבה טובה. ניסוח מעט שונה של כתובת אינו בהכרח סיבה לוותר.
**השלמה שגויה:** כמה מקרים נסגרו אף שהתוצאה היתה חסרה, לא נכונה או מחוץ לסמכות? זה המספר שהכי קל לפספס, מפני שלעתים התקלה מתגלה רק מאוחר יותר אצל הנהלת החשבונות, במחסן או בשיחת המשך עם הלקוח.
**זמן התאוששות:** כמה זמן עבר מרגע שהמערכת זיהתה כשל ועד שהמקרה חזר למסלול? גם סוכן טוב יפגוש מערכות לא זמינות ומידע חסר. השאלה התפעולית היא אם המקרה נשאר קבור או מגיע לאדם עם הקשר מספיק לפעולה.
לכל אחד מהמספרים צריך להצמיד נפח מוחלט. שיעור של אחוז אחד נשמע קטן, אבל משמעותו שונה לגמרי בעשרים ריצות ובאלפיים. אין צורך להמציא יעד אחיד לכל עסק. היעד נגזר מהנזק האפשרי ומהיכולת לתקן.
## לא כל טעות שווה אותו דבר
סוכן שכותב שם רחוב בפורמט לא אחיד וסוכן ששולח הצעת מחיר לא מאושרת אינם מייצרים אותה בעיה. אם שניהם נספרים כ"טעות אחת", לוח המדדים משטח את ההחלטה העסקית החשובה ביותר.
כדאי לתת לכל כשל דרגת חומרה לפי שני דברים: מה היתה ההשפעה, וכמה קל היה להפוך את הפעולה. טיוטה שלא נשלחה אפשר לתקן בשקט. הודעה שיצאה ללקוח דורשת טיפול. שינוי שפגע בחיוב או בהתחייבות חוזית דורש בדיקה אחרת לגמרי.
החלוקה הזאת אינה תרגיל ניהולי. היא קובעת מה מתקנים קודם. עשרים טעויות עיצוב קטנות לא צריכות לדחוק הצידה כשל יחיד בהרשאה. במקביל, אסור להשתמש בחומרה כדי להתעלם מתקלות קטנות שחוזרות שוב ושוב ומעמיסות עבודה על הצוות.
NIST מדגיש שמדידת סיכון צריכה לכלול גם אי ודאות, השוואה לקווי בסיס ותיעוד של מגבלות. עבור סוכן בעסק, המשמעות המעשית היא לא להסתפק בספירת תשובות נכונות. צריך לדעת באילו תנאים הוא טועה, כיצד הוא נכשל ומה נשאר לאדם לעשות אחריו.
## מדגם אנושי קטן עדיף על ביטחון אוטומטי גדול
מערכת יכולה לבדוק אם שדה התמלא, אם הודעה נשלחה ואם רשומה עודכנה. קשה לה יותר לבדוק אם ההחלטה היתה נכונה מבחינה עסקית. לכן גם אחרי העלייה לאוויר נדרש מדגם אנושי קבוע.
המדגם לא צריך להיות אקראי בלבד. בוחרים בו גם מקרים שהסוכן סגר בביטחון גבוה, מקרים שהועברו לאדם, קלטים חדשים ומקרים שבהם כמה מקורות חלקו זה על זה. כך בודקים את המקומות שבהם ההנחה של המערכת עלולה להיות שגויה.
שירותי הערכת סוכנים של Google Cloud, למשל, בנויים סביב מערך נתונים של משימות ומטרות מוגדרות. העיקרון שימושי גם בלי להשתמש בכלי מסוים: אי אפשר להעריך סוכן מתוך שיחה אחת מוצלחת. צריך אוסף מקרים מייצג ותוצאה צפויה שאפשר להשוות אליה.
את ממצאי המדגם מחזירים לשתי רשימות. הראשונה היא רשימת כללים או בדיקות שצריך לשנות. השנייה היא רשימת סוגי מקרים שהעסק עדיין אינו יודע להכריע בהם. לא כל פער הוא בעיית מודל. לפעמים הסוכן פשוט חושף מחלוקת שהצוות פתר עד היום לפי מי שהיה במשמרת.
## ההתנגדות הסבירה: כל הבקרה הזאת מבטלת את החיסכון
אם כל ריצה עוברת בדיקה אנושית, ההתנגדות נכונה. אין טעם לבנות סוכן ולשחזר לידו את כל העבודה הידנית.
אבל זו אינה ההצעה. בתחילת ההפעלה בודקים מדגם גדול יחסית ומצמצמים אותו כשההתנהגות מתייצבת. כשנכנסת פעולה חדשה, מקור מידע משתנה או מתגלה סוג כשל חדש, מרחיבים שוב את המדגם. הבקרה זזה עם הסיכון.
העלות האמיתית אינה כמה דקות הושקעו בבדיקה. צריך להשוות אותה למחיר של פעולה שגויה שלא התגלתה, ולזמן שהצוות מבזבז בחיפוש אחר מקור התקלה. לוג מסודר ומדגם מכוון יכולים לקצר את העבודה הזאת מאוד.
גם כאן, המטרה אינה להגיע לאפס התערבות אנושית. המטרה היא להשאיר את תשומת הלב האנושית למקרים שבהם היא משנה את התוצאה.
## החלטת ההרחבה מתקבלת מהחריגים
אחרי כמה שבועות, מנהלים נוטים להסתכל על כמות העבודה שהסוכן ביצע ולשאול איזה תהליך מחברים עכשיו. אני הייתי מתחיל במקום אחר: פותח את החריגים.
אם רוב ההעברות נובעות משדה אחד שחסר, מתקנים את איסוף המידע. אם הן נובעות מכלל עסקי לא ברור, לא מוסיפים יכולת לפני שהצוות מכריע בו. אם הסוכן משלים היטב מקרים רגילים אך טועה בפעולות בעלות השפעה גבוהה, מצמצמים סמכות. ואם שיעור ההשלמה השגויה נמוך ויציב גם במדגם אנושי, אפשר לשקול הרחבה צרה.
כך לוח המדדים הופך מכלי דיווח לכלי החלטה. הוא אומר מה לשפר, מה לאשר ומה עדיין לא להעביר לסוכן.
אם כבר פועל אצלכם סוכן ואתם עדיין מודדים בעיקר כמה הודעות או משימות הוא יצר, הביאו ל[פגישת גילוי אוטומציה](/automation-discovery) עשרים ריצות אחרונות, כולל המקרים שהועברו לאדם. ב־AI BUDDY נמפה איתכם ארבע תוצאות: סגירה, העברה, כשל והתאוששות. משם אפשר יהיה להחליט אם להרחיב את הסוכן, לצמצם אותו או לתקן קודם את התהליך.
### מקורות
* [NIST AI Risk Management Framework Core, Measure](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/)
* [NIST AI Risk Management Framework 1.0](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10)
* [Google Cloud: Evaluate agents using the GenAI Client](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/evaluate)