AI Observability
— לראות מה הסוכן עושה
סוכן AI ש"סתם לא עובד" הוא סיוט לדיבוג — קלט לא-דטרמיניסטי, שרשרת קריאות ל-LLM וכלים, ועלויות שמטפסות. Observability הופך את הקופסה השחורה לשקופה: כל trace, כל prompt, כל טוקן ועלות. במדריך: ארבעת עמודי התווך, tracing ו-evals, ו-LangSmith מול Langfuse.
למה observability הוא קריטי למערכות AI
בתוכנה רגילה, אותו קלט תמיד מחזיר אותו פלט. במערכת מבוססת LLM זה לא כך: אותה שאלה יכולה להחזיר תשובות שונות, סוכן יכול לבחור מסלול כלים שונה בכל הרצה, והעלות משתנה מבקשה לבקשה. בלי כלי ניטור ייעודי, אתה "עיוור" — לא יודע למה הסוכן החליט מה שהחליט, איפה הוא נתקע, וכמה זה עלה.
AI Observability הוא ה-equivalent של מוניטורינג בעולם ה-AI: הוא מתעד את כל השרשרת של קריאות ל-סוכן ול-LLM, מודד איכות עם evals, ועוקב אחרי עלויות ו-latency — כדי שתוכל לדבג, לשפר ולסמוך על המערכת בפרודקשן.
ארבעת עמודי התווך
Tracing — הלב של המערכת
Trace הוא רשומה של בקשה שלמה, מפורקת ל-spans — כל צעד בשרשרת. בסוכן טיפוסי, trace אחד יכיל את הפרומפט הראשוני, את החלטת ה-LLM, קריאה לכלי חיפוש, שליפה מ-vector DB, ואת התשובה הסופית — כל אחד עם הקלט, הפלט, הזמן והעלות שלו.
כשמשהו משתבש, אתה פותח את ה-trace ורואה בדיוק היכן: אולי ה-retrieval החזיר מסמכים לא רלוונטיים, אולי הכלי נכשל, אולי הפרומפט היה מבלבל. זה ההבדל בין דיבוג של דקות לבין ניחושים של שעות.
ב-2026 יש התכנסות סביב OpenTelemetry (OTel) כסטנדרט פתוח ל-tracing של LLM. רוב הכלים תומכים בו, כך שאתה לא נעול לספק אחד — אותו instrumentation יכול לשלוח נתונים ל-Langfuse, LangSmith או כל backend אחר.
Evals — איך יודעים שזה באמת עובד
"נראה טוב" זה לא מדד. Evals הן בדיקות שיטתיות של איכות הפלט, ובלעדיהן כל "שיפור" בפרומפט הוא הימור. שלוש גישות עיקריות:
- Ground truth — יש לך תשובה נכונה ידועה, ומשווים אליה (מדויק למשימות סגורות: סיווג, חילוץ נתונים).
- LLM-as-judge — מודל אחר מדרג את התשובה לפי קריטריונים (רלוונטיות, נאמנות למקור, טון). מתאים למשימות פתוחות.
- Human feedback — 👍/👎 ממשתמשים אמיתיים, או דירוג מומחה. יקר אבל אמין.
הכוח האמיתי: evals לצד CI/CD. מריצים סט של דוגמאות (dataset) בכל שינוי בפרומפט או במודל, ורואים אם האיכות עלתה או ירדה — לפני שזה מגיע למשתמשים. וכן — בדיקות אבטחה הן חלק מ-evals.
LangSmith מול Langfuse — מה לבחור
| כלי | מודל | הכי טוב ל |
|---|---|---|
| LangSmith | מנוהל (סגור) | מי שכבר עם LangChain/LangGraph |
| Langfuse | קוד פתוח + ענן | self-host ואגנוסטי לפריימוורק |
| Arize / Phoenix | קוד פתוח + ענן | evals מתקדמים, ML גם יחד |
| Helicone | proxy קליל | מעקב עלויות ו-caching מהיר |
- LangSmith — של יוצרי LangChain. אינטגרציה חלקה עם LangGraph, tracing, datasets ו-evals במקום אחד. מנוהל.
- Langfuse — קוד פתוח, אגנוסטי לפריימוורק, אפשר self-host מלא (חשוב לפרטיות). הפופולרי ביותר בקהילה ב-2026.
- Arize Phoenix — חזק ב-evals ובניתוח, פתוח, מתאים גם לצוותי ML רחבים יותר.
- Helicone — proxy קל שמוסיף מעקב עלויות, caching ו-rate limiting בשורה אחת. מצוין להתחלה מהירה.
איך מתחילים — צעד ראשון
אל תחכה שיהיה "מסודר". תוסיף tracing כבר עכשיו — זה שורות ספורות. עם Langfuse זה נראה כך:
from langfuse.openai import openai # wrapper שקוף
resp = openai.chat.completions.create(
model="gpt-4o",
messages=[{"role":"user","content":"סכם את המסמך"}],
)
# כל קריאה מתועדת אוטומטית: prompt, תשובה, טוקנים, עלות, latency1. הוסף tracing ליום הראשון — כדי לראות מה קורה. 2. הגדר מעקב עלויות עם התראה על חריגה. 3. בנה dataset של דוגמאות וריץ evals בכל שינוי. 4. חבר feedback ממשתמשים אמיתיים לתוך אותו dataset. observability הוא לא פרויקט חד-פעמי — זו לולאת שיפור מתמשכת.