פיתוח מערכת AI לניטור ביצועי סוכני AI

למה ניטור סוכני AI נשבר בקנה מידה

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

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

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

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

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

מה נותנת הנצפות: תגובה, תקלות, השבתות

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

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

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

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

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

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

מצבי איסוף נתונים: השוואת גישות

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

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

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

איך אנחנו בונים מערך ניטור: שלבי העבודה

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

1. ביקורת סכימה ונקודות כשל. מפרקים את מסלול הבקשה לשלבים: פירוק המשימה, הפעלת כלים, פנייה למאגר הידע, תשובה סופית. בכל שלב מחפשים כשל שמסתווה כתוצאה תקינה — חריגה מזמן ההמתנה של הכלי נראית כמו «אין נתונים».
2. תיאום מדדים. קובעים את מה שמשקף את התנהגות הסוכן: זמן תגובה לפי שלבים, שיעור תשובות בלי עיגון במקור, חזרות על קריאות, ניתוק סשן, מספר שלבים למשימה. לכל מדד מוגדר בעלים וטווח מותר.
3. איסוף טרייסים. כל הרצה מקבלת מזהה, נשמרים קלטים ופלטים של כלים, גרסת ההוראות של הסוכן והמודל. בלי הצמדה לגרסה אי אפשר להבין אחרי איזה שינוי המדדים השתנו.
4. כללי סף. גבולות קשיחים לתקלות מפורשות וסטייה מקו הבסיס לאורך חלון — להידרדרות איטית. כלל על חלון נע מחליש קפיצות בודדות שאחרת היו מעירות את התורן בלילה.
5. כללי התראה. רמות חשיבות, מסלול הסלמה, דיכוי חזרות של אותו אות, איסור על הפעלה מחוץ לחלון השירות. האות צריך להגיע למי שיכול לפעול.
6. בדיקה על זרימה אמיתית. הרצה במצב צל: המערך מחשב מדדים, אבל לא מפריע לעבודת הסוכן. משווים למדגם מתויג, מכיילים ספים, מחשבים שיעור התראות שווא.
7. מסירה לפרודקשן. נוהל תורנות, הוראה עם תגובות אופייניות, סדר בדוק לחזרת הסוכן לגרסת ההוראות הקודמת.

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

מה נשאר אצלכם: סכימות, כללים, נהלים

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

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

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

מקרה בוחן: איך הסרנו שטחים עיוורים בעיבוד בקשות

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

מה שינינו

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

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

מה התקבל

זמן איתור הסיבה הצטמצם מארבע-שש שעות ל-20-30 דקות — השרשרת נפתחת בשאילתה אחת, בלי הרכבה ידנית. שיעור הכשלים שנסגרים אוטומטית עלה מ-12% ל-70%: השאר מגיעים לתורן כבר עם הקשר והשערה. רגרסיות נעשו גלויות בזמן ההפצה, לא מתלונות משתמשים.

במה שונה ניטור איכות התשובות מחקירת תקלות?

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

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

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

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

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

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

חששות לפני התחלה: נתונים, עומס, הרשאות

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

האם הניטור יאט את השירות עצמו?

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

אילו הרשאות נדרשות למערכת שלנו?

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

כמה זמן לשמור היסטוריה?

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

מה יקרה אם נחליט לסגור את הניטור?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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