מעקב וביקורת של סוכני AI: שקיפות ושליטה מלאה

טרייסינג של סוכני AI: היכן אובדת השליטה על הסשן

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

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

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

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

מה נותנת נראות של שרשראות קריאות כלים

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

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

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

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

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

טרייסינג של סוכני AI: השוואת מצבי איסוף נתונים

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

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

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

שלבי הטמעה: מביקורת סשנים ועד מסירת נהלים

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

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

תצורה וארטיפקטים שנשארים אצל הלקוח

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

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

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

קייס: חקירת תקלה בשעות במקום שבועות

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

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

מה שינינו

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

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

מטריקות לפני ואחרי

• שיעור הכשלים הניתנים לשחזור: 20% → 85%.
• זמן איתור הסיבה: 2-4 ימי עבודה → 2-4 שעות.
• העבודה הידנית של התמיכה הצטמצמה פי שלושה: פניות טיפוסיות נסגרות לפי הטרייס, בלי מפתח.
• הסלמות למהנדסים הצטמצמו פי ארבעה — נשארות רק אלה שדורשות תיקון קוד או פרומפט.

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

מה לעשות אם המערכת כבר עובדת בלי בקרה?

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

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

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

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

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

ספקות טכניים: אחסון, עומס, גישה

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

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

איך מנטרלים נתונים אישיים?

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

כמה זמן נשמרת ההיסטוריה ואפשר לשנות תקופות?

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

איך מחלקים גישה לטרייסים?

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

מה אם צריך להשהות את האיסוף או להחזיר מדיניות אחורה?

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

בואו נדון במשימה: סכמת איסוף ותוכנית הטמעה

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

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

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

מה שמועיל להכין לפני השיחה:

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

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