LLM Observability — Logs, Traces, Tokens, Latency ועלויות

מאת צוות מדיה דיל · 09.08.2026 · AI · 6 דק׳

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

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

למה Observability קלאסי לא מספיק ל-LLM

מערכות תוכנה רגילות נהנות מ-Observability בשל ותיק: logs, metrics, traces (שלושת עמודי ה-Observability הקלאסיים). מערכות LLM זקוקות לכל אלה, ועוד: תוכן הפרומפט המלא שנשלח בכל קריאה (לא רק "נקרא endpoint X"), שרשרת ההחלטות של Agent על פני כמה קריאות מודל, שימוש בטוקנים ועלות שמשתנה מקריאה לקריאה, ואיכות התוצאה — שהיא הרבה יותר קשה למדידה אוטומטית מקוד קלאסי שמחזיר True/False. לכן Observability ל-LLM דורש שכבת תיעוד ייעודית מעבר למה שכלי APM רגילים מספקים.

שלושת השכבות: Logs, Traces, Metrics

• Logs — רשומה מלאה של כל קריאה: הפרומפט המלא שנשלח (System + User + כל הקשר שהוזרק), התשובה שהתקבלה, מספר הטוקנים בקלט ובפלט, וזמן התגובה. ללא הפרומפט המלא, כל דיבוג הופך לניחוש.
• Traces — קישור בין כל הקריאות שהתרחשו בשירות בקשה אחת של משתמש — כולל קריאות כלים, קריאות RAG, וקריאות לסוכנים אחרים ב-Multi-Agent. trace ID משותף שעובר בין כל הרכיבים הוא הבסיס לכל ניפוי שגיאות רציני במערכת מורכבת.
• Metrics — מדדים מצטברים: latency ממוצע ו-p95/p99, עלות ממוצעת לבקשה, שיעור שגיאות, שיעור אסקלציה לאדם. מדדים אלה מאפשרים לזהות מגמות (התדרדרות הדרגתית) שלוג בודד לא יחשוף.

{
  "trace_id": "req-8f3a...",
  "span": "tool_call",
  "tool": "search_orders",
  "input_tokens": 412,
  "output_tokens": 128,
  "latency_ms": 340,
  "cost_usd": 0.0021,
  "model": "claude-x",
  "status": "success"
}

מבנה נתונים ל-Span ולתיוג הקשר עסקי

כדי שנתוני Observability יהיו שימושיים ולא רק "עוד לוגים", כל span (יחידת עבודה נמדדת — קריאת מודל, קריאת כלי, שלב RAG) צריך תיוג עקבי: מזהה משתמש או ארגון (בלי מידע מזהה רגיש עצמו), סוג המשימה העסקית, גרסת הפרומפט או המודל ששימשה, וסביבה (פיתוח/סטייג'ינג/פרודקשן). תיוג כזה מאפשר לשאול שאלות עסקיות אמיתיות — לא רק "מה קרה בקריאה הזו" אלא "האם משתמשי הפלטפורמה בתשלום מקבלים latency טוב יותר ממשתמשי הניסיון החינמי", או "האם גרסת פרומפט חדשה שיפרה את שיעור ההצלחה בפועל". בלי תיוג עסקי, נתוני Observability נשארים ברמה טכנית בלבד ולא מספקים תובנות שמניעות החלטות מוצר.

מעקב אחר עלות ברמת בקשה

אחד ההבדלים הגדולים מ-Observability קלאסי: כל קריאה למודל עולה כסף שמשתנה לפי אורך הקלט והפלט. בלי מעקב עלות ברמת בקשה בודדת, אי אפשר לדעת אילו תרחישים יקרים במיוחד, אילו משתמשים או תכונות "שורפים" תקציב, ומתי חלה עלייה חשודה בעלות שיכולה להעיד על תקלה (למשל Agent שנכנס ללולאה ומכפיל קריאות). מעקב טוב מפרק עלות לפי מודל, לפי תכונה, ולפי סוג משימה — לא רק מספר כולל בסוף החודש. הרחבה בAI Cost Engineering ובToken Engineering.

הבדל בין ניטור זמן-אמת לניתוח בדיעבד

שני שימושים שונים ל-Observability דורשים כלים שונים במידה מסוימת: ניטור זמן-אמת — דשבורדים ומדדים שמראים את מצב המערכת עכשיו, מיועדים לתפוס בעיות תוך דקות (עלייה בשיעור שגיאות, latency חורג); וניתוח בדיעבד (post-hoc) — חקירה מעמיקה של אירוע ספציפי, לרוב בעקבות תלונת משתמש או חשד לבעיה, שדורשת יכולת לחפש ולסנן לוגים היסטוריים לפי קריטריונים ספציפיים (משתמש מסוים, טווח זמן, סוג שגיאה). מערכת שמתמקדת רק בדשבורדים בזמן אמת בלי יכולת חיפוש היסטורי טובה תתקשה מאוד כשמישהו יבוא עם "מה קרה אצל הלקוח הזה אתמול ב-15:32" — שאלה שדורשת בדיוק את סוג הפירוט שדשבורד מצטבר לא נותן.

Distributed Tracing במערכות Multi-Agent

כשבקשה בודדת עוברת דרך כמה סוכנים, כלים ושכבות RAG, טרייס בודד לא מספיק — נדרש Distributed Trace שמראה את כל העץ: איזה סוכן קרא לאיזה, באיזה סדר, כמה זמן כל שלב לקח, ומה הייתה התוצאה. בלי זה, זיהוי צוואר בקבוק (איזה שלב איטי) או מקור טעות (איזה סוכן קיבל מידע שגוי) הופך לחקירה ידנית ארוכה. כלי tracing טובים מציגים את זה כעץ ניתן לחיפוש, לא רק כרשימת לוגים שטוחה. ראו הרחבה במערכות Multi-Agent.

זיהוי רגרסיות איכות — לא רק תקלות טכניות

ההבדל המהותי ביותר בין Observability רגיל ל-LLM: מערכת יכולה לרוץ "בריאה" מבחינה טכנית (200 OK, latency תקין) ובכל זאת להחזיר תשובות באיכות ירודה. לכן Observability למערכות AI חייב לכלול גם מדדי איכות — שיעור תשובות שסומנו כלא מספקות (feedback שלילי), שיעור אסקלציה לאדם, וציוני evals אוטומטיים שרצים על מדגם קבוע מהתעבורה החיה. ראו מדריך LLM Evals להרחבה על מדידת איכות שיטתית.

התראות (Alerting) — מתי לעורר מישהו

ניטור בלי התראות הוא דשבורד שאף אחד לא מסתכל עליו עד שהמערכת כבר קרסה. התראות טובות למערכות LLM מתמקדות בסטיות ממה שנחשב "רגיל", לא רק בסף מוחלט: קפיצה פתאומית בעלות ליחידת זמן, ירידה חדה בשיעור ההצלחה, latency שחורג משמעותית מה-baseline, או עלייה במספר האסקלציות לאדם. חשוב להימנע מ"רעש התראות" — כשיש יותר מדי התראות לא קריטיות, הצוות מתחיל להתעלם מכולן, כולל האמיתיות. כלל טוב: כל התראה שנשלחת צריכה להיות פעילה (actionable) — מישהו שמקבל אותה יודע בדיוק מה לבדוק ומה השלב הבא.

Trade-offs: כמה לתעד

• פרטיות מול דיבוג — תיעוד הפרומפט המלא כולל לעיתים מידע רגיש של משתמשים; נדרשת מדיניות מסנון (redaction) לפני אחסון, ובקרת גישה קפדנית ללוגים. ראו אבטחת מידע בעידן ה-AI.
• עלות אחסון — תיעוד מלא של כל קריאה, כולל תוכן ארוך, יכול לצבור נפח אחסון משמעותי; retention policy מוגדר (למשל 30 יום לתוכן מלא, שנה למטא-דאטה מסוכם) מאזן בין יכולת דיבוג לעלות.
• Overhead ביצועים — תיעוד סינכרוני שחוסם את התגובה למשתמש פוגע ב-latency; רוב המערכות שולחות לוגים באופן אסינכרוני כדי לא להאט את חוויית המשתמש.

דוגמה מהשטח

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

שאלות נפוצות

מה ההבדל בין Observability ל-Evals?

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

איזה כלים משמשים ל-LLM Observability?

יש כלים ייעודיים למעקב אחר קריאות LLM (tracing, עלות, טוקנים) לצד כלי APM כלליים. הבחירה תלויה בסטאק הקיים ובצורך בשילוב עם מערכות ניטור ארגוניות קיימות.

האם צריך לתעד כל קריאה, או רק מדגם?

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

איך Observability עוזר להוריד עלויות?

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

מה זה p95/p99 latency ולמה זה חשוב יותר מהממוצע?

אלו אחוזונים שמראים את זמן התגובה של 5% או 1% הבקשות האיטיות ביותר. ממוצע מסתיר בעיות — מערכת עם latency ממוצע טוב יכולה עדיין להשאיר חלק ניכר מהמשתמשים עם חוויה גרועה אם ה-p99 גבוה משמעותית.

כמה זמן שומרים נתוני Observability?

תלוי בדרישות רגולטוריות ובעלות האחסון, אך גישה נפוצה היא retention קצר (30-90 יום) לתוכן מלא של פרומפטים ותשובות, לצד retention ארוך בהרבה למטא-דאטה מסוכם (עלות, latency, שיעורי הצלחה) שתופס הרבה פחות מקום ומאפשר ניתוח מגמות ארוכות טווח.

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

תגיות: LLM Observability · AI Monitoring · Tracing · Token Usage · Latency · AI Cost

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