דלג לתוכן
חזרה לבלוג

AI Observability בפרודקשן: מה למדוד ואיך

מוניטורינג LLM בפרודקשן: 5 מדדים שחשובים (latency p95, token throughput, שיעור שגיאות לפי גרסת פרומפט, semantic drift, עלות לבקשה), כלים אמיתיים עם Langfuse ו-Phoenix, ודשבורד אחד שכל מהנדס on-call צריך.

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

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

זהו פוסט 7 בסדרת ה-AI pillar. הפוסטים הקודמים כיסו אוטומציה עם AI לעסק, סוכני AI לכלים פנימיים, מתי RAG שווה לבנות, בחירת ה-LLM הנכון לסטארטאפ, עלויות LLM בפרודקשן והנדסת פרומפטים בפרודקשן. הפוסט הזה עוסק בסגירת פער ה-observability: חמשת המדדים שחשובים, הכלים שלוכדים אותם ודשבורד אחד שכל מהנדס on-call צריך.

למה מוניטורינג LLM שונה ממוניטורינג API רגיל

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

בקשה יכולה להחזיר HTTP 200, בתוך latency מקובל, עם payload JSON תקין — ועדיין להיות שגויה לגמרי. הסיווג היה לא נכון. הסיכום פיספס את הנקודה המרכזית. התשובה הייתה הזיה. אף אחד מהכשלים האלה לא יופיע במדדי התשתית הקיימים שלכם.

AI observability דורשת שכבה שנייה: מדידה לא רק אם המודל הגיב, אלא מה הוא החזיר וכמה עלה להגיע לתשובה.

מדד 1: Latency p95 (לא ממוצע)

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

עקבו אחרי latency בשני רמות:

  • Latency end-to-end: מהרגע שהמשתמש מפעיל את קריאת ה-LLM ועד שהתשובה מוצגת. כולל ה-preprocessing שלכם, סיבוב ה-API, כל שלבי ה-retrieval, ו-postprocessing.
  • TTFT (time to first token): עבור תגובות streaming, זה מה שהמשתמשים תופסים באמת כ”מהיר”. קריאה עם latency כולל של 4 שניות אבל TTFT של 0.3 שניות מרגישה מיידית כי המשתמש רואה טקסט מיד.

הגדירו התראה על latency p95 end-to-end שחוצה סף (נקודת התחלה טובה: התראה ב-3× ה-baseline שלכם). עקבו בנפרד אחר TTFT לנקודות קצה streaming.

מדד 2: Token throughput

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

  1. מספר טוקני קלט לבקשה: אם זה קופץ, הפרומפטים שלכם או ההקשר שנאחזר גדל באופן לא צפוי (סימן נפוץ לבאג ב-pipeline RAG שמאחזר יותר מדי chunks).
  2. מספר טוקני פלט לבקשה: אם זה גדל, המודל מייצר תגובות ארוכות יותר ממה שצפוי, מה שמעלה latency ועלות בו זמנית.
  3. היחס: שינוי פתאומי ביחס קלט/פלט מאותת לעתים קרובות ששינוי פרומפט השפיע באופן לא מכוון על verbose-יות התגובה.

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

מדד 3: שיעור שגיאות לפי גרסת פרומפט

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

שגיאות LLM אינן רק תגובות HTTP 5xx מהספק. הן כוללות:

  • שגיאות parse: המודל החזיר טקסט שנכשל ב-validation של סכמת ה-JSON שלכם
  • שגיאות timeout: בקשות שחרגו מסף ה-timeout בצד הלקוח
  • סירובי תוכן: המודל סירב להגיב (נפוץ כשפרומפטים נסחפים לקצוות מדיניות)
  • פלטים ריקים או קטועים: התגובה הייתה תקינה אבל ריקה, או נקטעה באמצע משפט

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

תיוג הגרסאות הוא קריטי. כל קריאת LLM צריכה לשאת מאפיין prompt_version במטא-הנתונים שלה. בלי זה, לא תוכלו להבחין בין “לגרסת פרומפט זו יש שיעור שגיאות של 3%” לבין “משהו לא בסדר בכל האינטגרציה של ה-LLM שלי.”

מדד 4: זיהוי semantic drift

זהו המדד המתקדם ביותר ברשימה, והערכי ביותר לפיצ’רים LLM שרצים לאורך זמן.

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

זיהוי semantic drift עובד על ידי הטמעת פלטי LLM ומעקב אחרי התפלגות ההטמעות הללו לאורך זמן. כשהפלטים מתחילים להתרחק מהתפלגות ה-baseline שלכם, זה אות שכדאי לחקור — או שהמודל השתנה, או שאופי קלטי המשתמשים השתנה, או שעריכת פרומפט אחרונה השפיעה בדרכים שלא תפסתם ב-eval harness.

יישום מעשי: דגמו 1–5% מהתגובות בפרודקשן, הטמיעו אותן עם מודל הטמעה זול (text-embedding-3-small של OpenAI עולה חלקי אגורה לכל 1,000 תגובות), ושרטטו את ה-centroid והשונות של דגימת כל יום מול ה-baseline שלכם. סחף ב-centroid או עלייה בשונות מצדיקים בחינה ידנית של הפלטים שנדגמו.

מדד 5: עלות לבקשה

ראיתם את מספר העלות המצרפית בחשבון החודשי. אבל האם אתם יודעים את העלות לבקשה מוצלחת? למשתמש? לפיצ’ר?

עלות לבקשה עונה על השאלה שה-economics של ה-LLM שלכם תלויה בה: באיזה קנה מידה הפיצ’ר הזה הופך לבלתי ניתן לתחזוקה? אם העלות הנוכחית שלכם היא $0.008 לבקשה ו-CAC היעד שלכם הוא $200, עלות ה-LLM זניחה ב-10,000 בקשות. ב-1,000,000 בקשות, זה $8,000 — שורה ששווה לנהל.

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

כלים: מה להשתמש בו בפועל

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

Langfuse — קוד פתוח, ניתן להרצה עצמית, נראות מצוינת ברמת ה-trace. לוכד כל פרומפט ו-completion, תומך ב-prompt versioning באופן מובנה, ממשק משתמש טוב לעיון ב-traces ולחיפוש שגיאות. הבחירה הטובה ביותר לצוותים שרוצים נראות ללא תלות בספק. ה-free tier נדיב; הרצה עצמית פשוטה על VM קטן.

Phoenix by Arize — קוד פתוח, ממוקד בהערכת LLM וניתוח הטמעות. חזק במיוחד לזיהוי semantic drift ולהשוואת גרסאות פרומפטים מול ה-eval dataset שלכם. מלווה טוב ל-Langfuse אם אתם רוצים כלי הערכה ייעודיים.

טבלת ClickHouse מותאמת — לצוותים עם נפחי בקשות גבוהים וצרכי ייחוס עלות ספציפיים. תרשמו כל קריאת LLM כשורה: timestamp, feature, prompt_version, model, input_tokens, output_tokens, latency_ms, error_type, user_id. ClickHouse מטפל במיליארדי שורות בעלות נמוכה ונותן לכם צבירה שרירותית עם זמני שאילתה של פחות משנייה. הפשרה היא מאמץ הגדרה: אתם בונים את האינסטרומנטציה, שאילתות הצבירה והדשבורדים בעצמכם.

דשבורד אחד שכל מהנדס on-call צריך

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

  • p95 latency
  • שיעור שגיאות (עם פירוט לפי סוג שגיאה)
  • יחס טוקן קלט/פלט
  • עלות לבקשה

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

התחילו קטן, מדדו מוקדם

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

  1. בהשקה: שיעור שגיאות + latency p95. אלה תופסים את הכשלים הכי משמעותיים.
  2. אחרי החודש הראשון: עלות לבקשה + token throughput. אלה מסייעים לאופטימיזציה.
  3. בקנה מידה: semantic drift. זה הופך לרלוונטי כשיש לכם נפח מספיק לדגימה משמעותית ומספיק זמן הרצה כדי לבסס baseline.

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

אם אתם בונים פיצ’רים AI ורוצים לבנות את תשתית ה-observability נכון מהתחלה — במקום להוסיף אותה אחרי התקרית הראשונה בפרודקשן — CTO חלקי יכול לעזור לכם לתכנן את שכבת המוניטורינג לפני שהיא הופכת לדחופה. קבעו שיחת היכרות — ללא התחייבות.

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

שיחת היכרות חינם