AI Observability — Traces, Spans ו-Token Flow במערכת סוכנים

מאת צוות מדיה דיל · 12.08.2026 · AI Evals · 5 דק׳

איך בונים תשתית Tracing שמתאימה למאפיינים הייחודיים של סוכני AI: מבנה Trace/Span מקונן, מעקב Token Flow ברמת Span, וקורלציה בין Trace לציוני Eval.

מערכת סוכנים בפרודקשן מטפלת ב-3,000 בקשות ביום, ופתאום עלות ה-API חצתה יעד תקציבי שלוש פעמים בשבוע אחד. השאלה "למה" נשארת בלי תשובה כי אין שום דרך לדעת אילו בקשות ספציפיות צרכו הכי הרבה טוקנים, אילו סוכנים-משנה במערכת רב-סוכנית קראו זה לזה במעגל מיותר, ואיפה בדיוק בשרשרת הקריאות הזמן והכסף הלכו לאיבוד. Observability לסוכני AI היא לא לוגים רגילים עם עוד שדה — היא דורשת מודל חדש של Traces, Spans ו-Token Flow, שמותאם למאפיינים הייחודיים של מערכת שמורכבת מקריאות מודל מקוננות, כלים, ולפעמים סוכנים שקוראים לסוכנים אחרים.

Trace ו-Span: יחידות המידה של Observability לסוכן

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

המבנה ההיררכי הזה, שמקורו בעולם ה-Distributed Tracing המסורתי (Jaeger, Zipkin), הוא מה שמאפשר לשאול שאלות כמו "כמה זמן לקח לתת-הסוכן של אימות תשלום, בנפרד משאר הריצה" או "האם הכלי החיצוני הזה הוא ה-bottleneck". התקן שהולך והופך למקובל בתעשייה להגדרת Spans כאלה הוא הרחבת GenAI Semantic Conventions של OpenTelemetry, שמגדירה שדות סטנדרטיים לקריאות LLM — שם המודל, מספר טוקנים, עלות משוערת — ומאפשרת לכלי ניטור שונים לקרוא את אותו פורמט. הבסיס הכללי של OpenTelemetry ל-Observability, מעבר לספציפי ל-AI, מפורט במדריך OpenTelemetry Observability.

Token Flow: לעקוב אחרי כסף וזמן ברמת הספאן

ברוב המערכות, עלות מדווחת ברמת הבקשה כולה — סה"כ טוקנים ועלות לכל שיחה. זה שימושי לדוח כספי חודשי, אבל חסר ערך לאבחון: כשעלות בקשה בודדת חורגת פי עשרה מהממוצע, צריך לדעת בדיוק איזה Span צרך את רוב הטוקנים. Token Flow תקין מתעד input tokens ו-output tokens בנפרד לכל Span שכולל קריאת מודל, כולל טוקני ה-context שהוזרקו (system prompt, היסטוריית שיחה, תוצאות כלים שהוחזרו כחלק מהקונטקסט לצעד הבא) — כי לרוב שם, לא בתשובת המודל עצמה, מתחבא הבזבוז.

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

קורלציה בין Trace ל-Eval: לא רק ניטור, גם בדיקה

תשתית Tracing איכותית לא משרתת רק Debugging — היא הבסיס שעליו נבנות שכבות Eval ו-Replay שתוארו במאמרים קודמים. Trace מלא ומתועד הוא בדיוק מה שמאפשר Trajectory Evaluation לבדוק את סדר הצעדים, ומה שמאפשר Replay לשחזר ריצה במדויק. לכן ההשקעה בתשתית Observability לא צריכה להיתפס כפרויקט נפרד מפרויקט ה-Evals — הן חולקות את אותה תשתית בסיסית, ובנייה נכונה של אחת מוזילה משמעותית את בניית השנייה. הקשר בין תיעוד Trace לשחזור כשל מלא מפורט במדריך Agent Replay.

שילוב מעשי נוסף: ניתן לצרף ל-Trace תג ציון Eval — כשמריצים LLM-judge על ריצה אמיתית, הציון והנימוק שלו נשמרים כ-Attribute על ה-Trace המקורי. זה מאפשר לסנן Traces לפי ציון ("הראה לי את כל הריצות עם ציון מתחת ל-3") ישירות בתוך כלי ה-Observability, בלי לתחזק מערכת נפרדת לגמרי לתוצאות Eval.

התראות: מתי Observability הופך לפעולה, לא רק לתצפית

Dashboard יפה שאף אחד לא מסתכל בו לא מונע תקריות. הערך האמיתי של Observability מתממש כשמוגדרות התראות אוטומטיות על סטיות מדפוס נורמלי: קפיצה חדה בעלות טוקנים ליחידת בקשה, עלייה בשיעור קריאות שנכשלו לכלי מסוים, או עלייה במספר הצעדים הממוצע להשלמת סוג משימה נתון (סימן שהסוכן "מתקשה" יותר מבעבר). הסף הנכון להתראה הוא לא ערך מוחלט קבוע אלא סטייה יחסית מ-Baseline נגלל (rolling baseline), כדי שההתראה תסתגל לתנודתיות טבעית בתעבורה בלי להציף בהתראות שווא.

שילוב בין הצד ה"קלאסי" של Observability (זמינות, latency, שגיאות) לצד הספציפי ל-AI (איכות תשובה, עלות טוקנים, דפוסי שימוש בכלים) הוא מה שמבדיל מערכת שבאמת נשלטת מערכת שרק "נראית" מנוטרת. יסודות הצד הקלאסי, שמשלימים את הפרק הזה, מפורטים במדריך LLM Observability.

מערכות רב-סוכניות: כשה-Trace מתפצל לעץ שלם

במערכת שבה סוכן ראשי מאציל משימות לתת-סוכנים מתמחים (לדוגמה, סוכן תיאום שקורא לסוכן חיפוש, סוכן חישוב וסוכן ניסוח תשובה), מורכבות ה-Trace גדלה משמעותית. בלי מזהה Trace אחד משותף שעובר בין כל תת-הסוכנים (Context Propagation), כל תת-סוכן מייצר Trace נפרד ומנותק, ואי אפשר לענות על "כמה זמן וכסף עלתה הבקשה הזו בסך הכל" בלי לאסוף ידנית מכמה מקורות. הפתרון הוא להעביר מזהה Trace יחיד דרך כל הקריאות — כולל קריאות HTTP או תור הודעות בין תת-סוכנים — כך שכלי ה-Observability יכול לבנות מחדש את העץ המלא, גם כשחלקים ממנו רצים על שירותים נפרדים לגמרי.

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

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

תגיות: AI Observability · Tracing · Spans · OpenTelemetry · Token Cost

← חזרה לבלוג · צור קשר