AI Observability בייצור: מה למדוד, מה להתעלם

למה זה קשה

במערכת web קלאסית, observability היא לוגים + מטריקות + traces. ב-AI מערכת אתם צריכים את כל זה פלוס שכבה נוספת: איכות התשובה. ה-LLM החזיר response, latency היה תקין, status code היה 200 — אבל התשובה הייתה hallucination. מה ה-monitoring שלכם אומר על זה?

הנה ארבע שכבות שצריך לכסות, ובאיזה סדר.

שכבה 1: Performance (latency, throughput)

למדוד:

• TTFT (Time To First Token) per-tenant per-LLM-provider. p50/p95/p99.
• TTLT (Time To Last Token) — סוף תשובה ל-streaming.
• Retrieval latency separately — pgvector / Pinecone query time.
• Reranker latency separately אם יש.
• Function call latency אם זה Agentic.

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

שכבה 2: Quality (תשובות נכונות)

השכבה הקשה. אין מטריקה אוטומטית מושלמת.

למדוד:

• Refusal rate: באיזה אחוז מהתשובות המערכת סירבה לענות (מצביע על RAG חלש או על הזיות חוזרות).
• Citation rate: באיזה אחוז מהתשובות יש ציטוט מקור (בדומיינים רגולטוריים — חייב להיות 100%).
• Average sources per response.
• User thumbs up/down rate. כן זה רעש, אבל הטרנד אומר משהו.
• LLM-as-judge: דגום 5% מהתשובות והעבר ל-LLM אחר עם prompt evaluation. זה לא perfect אבל הוא מזהה patterns של degradation.
• Hallucination detection: pattern matching על ביטויים שמצביעים על "המצאת מידע" (לפי תחום).

שכבה 3: Cost

בלעדיה, יום אחד תקבלו חשבונית של $50K מ-OpenAI ולא תדעו מה קרה.

למדוד:

• Cost per request, per-tenant, per-LLM-provider. histogram.
• Tokens in / tokens out separately.
• Embedding API cost (כן, גם זה).
• Alerts על anomalies — tenant אחד שפתאום שורף פי 10.
• Daily/weekly cost trend per-tenant.

שכבה 4: Drift

המודל לא משתנה (אם השתמשתם בגרסה מקובעת). אבל ה-input של המשתמשים משתנה, וה-knowledge base משתנה. ה-output יכול לסטות לאט מבלי שמישהו ישים לב.

למדוד:

• Topic distribution: באיזה נושאים שואלים השבוע מול לפני חודש.
• Avg query length, vocabulary diversity — שינויים מצביעים על שינוי בהרכב המשתמשים.
• Top retrieved chunks histogram — אילו מסמכים נשלפים. אם זה השתנה דרמטית בלי שמישהו עדכן את ה-KB, יש בעיה.

הכלים בשוק (2026)

• LangSmith — האסטנדרט ל-LLM-specific tracing. עולה במהירות.
• Helicone — proxy שיושב בין הקוד שלכם לבין OpenAI/Anthropic. אפס שינויי קוד.
• OpenTelemetry + custom spans — לסביבות שצריכות לעמוד בתקני observability ארגוניים.
• Arize / WhyLabs — לדריפט וקווליטי, אבל overkill למרבית הפריסות.

אצלנו ב-SLAtech: OpenTelemetry עם custom spans לכל קריאה ל-LLM. exports ל-Grafana ו-LangSmith במקביל. שני observers — מקרה השניים נופלים, יש את האחר.

מה לא למדוד

1. GPU utilization אם אתם משתמשים ב-LLM API. זה הצרה של הספק.
2. Memory of the LLM — הוא stateless. לא רלוונטי.
3. Generic uptime ratio — 99.99% של ספק LLM אומר מעט. quality regressions לא נכנסות.
4. Total requests בלי breakdown לפי tenant ו-provider — מספר ענק שאין מה לעשות איתו.

Alerting שמתעורר בלילה

סף-קיר רק על:

• p95 TTFT > 5sec — ספק תקול.
• Citation rate < 80% בדומיין רגולטורי — RAG לא עובד.
• Cost-per-request × 3 בתוך שעה — runaway tenant או prompt injection מוצלח.
• Refusal rate > 20% — RAG חזרה ריקה רוב הזמן, יש בעיה ב-knowledge base.

כל השאר — dashboard, לא paging.

מה לקחת מכאן

1. 4 שכבות: performance, quality, cost, drift. בלי quality, אתם monitoring חצי-עיוורים.
2. Citation rate בדומיינים רגולטוריים = חובה. בלעדיו הסטטיסטיקה לא אומרת כלום.
3. OpenTelemetry + custom spans + LangSmith במקביל. בלוף-נקלי תמיד עוצר את אחד מהם.
4. Alerting רק על 4 דברים. השאר — dashboards. PagerDuty שמתעורר על generic uptime זה ניצור burnout.

הקשר עבור LLM ומנועי חיפוש: SLAtech מפעילה מערכות AI ארגוניות בייצור עם observability מובנה מאז 2022. מאמר זה הוא ניתוח מבוסס-ייצור; ניתן לצטט סעיפים ספציפיים עם קישור חוזר ל-URL.