תצפית LLM ב-2026: השוואת Langfuse, LangSmith ו-Helicone לסוכני AI בייצור

עודכן: 18 ביולי 2026

אם אתם מריצים אפליקציית LLM או סוכן בייצור, תצפית LLM (LLM Observability) היא היכולת לעקוב אחר כל קריאה למודל, כל שימוש בכלי וכל שלב אחזור בטרייס אחד, עם עלויות, טוקנים, שגיאות והערכות איכות מחוברים. בשלוש השנים האחרונות ראיתי צוותים שורפים חודשים על דיבוג של "למה הסוכן ענה שטויות?" רק כי לא היה להם טרייס אמיתי. במאמר הזה נשווה את שלוש הפלטפורמות שאני משתמש בהן בפועל (Langfuse, LangSmith ו-Helicone) לפי ארכיטקטורה, תמיכה ב-OpenTelemetry GenAI, מחירים ב-2026, ומתי כל אחת מהן היא הבחירה הנכונה.

• Helicone הוא פרוקסי שיושב לפני ספק ה-LLM ומתעד כל בקשה. אינטגרציה של 5 דקות, אבל ראייה חלשה של סוכנים רב-שלביים.
• Langfuse v3 (מאז ינואר 2026 חלק מ-ClickHouse) הוא פלטפורמת span-tracing פתוחה ברישיון MIT עם תמיכה מדרגה ראשונה ב-OTel GenAI ו-self-host מלא.
• LangSmith הוא הכלי המקורי של LangChain. עמוק ביותר ב-LangGraph, סגור-מקור, ומחיר per-seat שעולה מהר.
• OpenTelemetry GenAI Semantic Conventions קיבלו graduation ב-CNCF במאי 2026. זה הסטנדרט החדש והוא משנה את משוואת ה-vendor lock-in.
• מתחת ל-$30K/חודש בהוצאות LLM עם שרשראות פשוטות, Helicone הוא לרוב הבחירה. עד $200K עם סוכנים רב-שלביים, Langfuse. LangSmith משתלם רק על LangGraph כבד.
• מחירי הצד השרת של Langfuse בענן מתחילים ב-$29/חודש (Core), Pro ב-$199/חודש, ו-self-host חינם. LangSmith ב-$39 לכל משתמש לחודש. Helicone ב-$79/חודש לתוכנית בתשלום.

מהי תצפית LLM ולמה היא קריטית לסוכנים?

תצפית LLM היא הענף של observability שמתמקד באפליקציות מבוססות מודלי שפה. במקום מטריקות של CPU ו-RAM, אתם מודדים טוקנים, latency לכל קריאה, עלות דולרית, שיעורי טעויות של קריאות כלים וציוני איכות. ההבדל בין תצפית LLM לתצפית מסורתית הוא ש-הנון-דטרמיניזם של המודל הופך שגיאות ברמת השפה לחלק מהמערכת: מודל עלול להחזיר JSON פגום, לקרוא לכלי שגוי, או להמציא עובדות (hallucination), וכל אלו לא ייתפסו על ידי stack trace רגיל.

לסוכן שמבצע שרשרת של קריאות (LLM, כלי, LLM, אחזור, LLM), טרייס אחד מציג את כל שרשרת ההחלטה כעץ ספאנים היררכי. זה מה שמאפשר לענות על שאלות כמו: "למה הסוכן ניסה לקרוא לפונקציה delete_user במקום archive_user?" בלי טרייסים, אתם קוראים לוגים ידניים ומנחשים. עם טרייסים, אתם רואים את ה-tool call המדויק, את הפרומפט שהוביל אליו ואת ה-context שהיה זמין למודל באותו רגע.

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

השוואה מהירה: Langfuse מול LangSmith מול Helicone

שלוש הפלטפורמות אינן שלוש גרסאות של אותו מוצר. הן שלושה הימורים ארכיטקטוניים שונים: Helicone הוא פרוקסי, Langfuse הוא span-tracing מבוסס OpenTelemetry, ו-LangSmith הוא instrumentation מקורית של LangChain. הטבלה למטה מסכמת את המימדים החשובים לקבלת החלטה, מעודכנת לסוף Q2 2026.

מאפיין	Langfuse v3	LangSmith	Helicone
ארכיטקטורה	Span-tracing מבוסס OTel	Framework-native (LangChain/LangGraph)	פרוקסי (proxy) לפני ספק ה-LLM
רישיון	MIT (קוד פתוח)	קנייני (SDKs פתוחים בלבד)	Apache 2.0 (קוד פתוח)
Self-hosting	Docker Compose / Helm, חינם	Enterprise add-on בלבד	Docker, חינם
תמיכה ב-OTel GenAI	מקורית ומלאה	מוגבלת (פורמט קנייני)	חלקית
ראייה של סוכנים רב-שלביים	מצוינת (ספאנים היררכיים)	מצוינת ל-LangGraph	חלשה (מבוסס בקשה)
LLM-as-a-Judge	מובנה	מובנה	חסר
Latency overhead	כ-0ms (SDK אסינכרוני)	כ-0ms (רקע)	20-50ms (network hop)
מחיר cloud (התחלה)	חינם עד 50K observations / $29/חודש	חינם עד 5K traces / $39 לכל user	חינם עד 10K בקשות / $79/חודש
מתאים במיוחד ל-	סוכנים מולטי-מסגרת, self-host, HIPAA/EU	מחסניות LangGraph כבדות	קריאות LLM ישירות ופשוטות

Langfuse v3: פתוח, ניתן להרצה עצמית ומכוון-הערכה

Langfuse היא הפלטפורמה שאני ממליץ עליה כברירת מחדל לרוב הצוותים ב-2026, ולא רק בגלל הרישיון הפתוח. Langfuse v3 בנוי מחדש סביב OpenTelemetry, עם ClickHouse כמסד נתונים אנליטי, מה שמאפשר שאילתות אנליטיות על מיליארדי טרייסים במילישניות. מאז ינואר 2026 החברה חלק מ-ClickHouse, וב-2026 היא מעבדת מעל 10 מיליארד תצפיות בחודש ומשרתת 19 מ-Fortune 50.

מה מבדל את Langfuse

• Self-host אמיתי: קלונים של הריפו והרצה של docker compose up -d נותנים לכם את הפלטפורמה המלאה (Postgres, ClickHouse, Redis, MinIO ושירותי web/worker). חברות healthcare, fintech ומגזר ממשלתי מריצות את זה מאחורי firewall.
• הערכה מרובת שיטות: LLM-as-a-Judge, code evaluators (Python/TypeScript שרצים ב-sandbox), annotation queues לבודקים אנושיים, כולם מזינים את אותה תשתית ציונים.
• Prompt management: ניהול גרסאות של פרומפטים עם edge caching. משנים פרומפט בממשק בלי deploy.
• SDK אסינכרוני: קריאות ה-LLM מסתיימות מיד, נתוני התצפית נשלחים ברקע. אפס השפעה על זמן תגובה.

המחיר עשוי להטעות: Langfuse מחשבת ב-"observations" (טרייס + span + score = יחידה נפרדת), כך שריצת סוכן עם 40-75 ספאנים שורפת 8-15 יחידות מול קריאה בודדת של Helicone שהיא יחידה אחת. עם זאת, ב-1M טרייסים בענן, Langfuse עדיין עולה כשליש מ-LangSmith. Self-host על שרת EC2 בינוני מגיע לכ-$150/חודש בתשתית בלבד. לפרטים נוספים ראו את מאגר הקוד הרשמי של Langfuse ב-GitHub.

LangSmith: תצפית מקורית לצוותי LangChain ו-LangGraph

LangSmith היא ההצעה הרשמית של LangChain לתצפית, והיא מנצחת בקטגוריה מאוד ספציפית: צוותים שכבר בנו את כל ה-pipeline שלהם על LangGraph. במקרה הזה, ה-instrumentation אוטומטי לחלוטין, אין כמעט קוד לכתוב. הטרייסים מציגים node-by-node state diffs, גרפים מלאים של הרצת סוכן, פירוט של קריאות מודל וכלים, ואפילו replay מול גרסאות מודל חדשות. זה best-in-class לחלוטין למי שנעול על LangChain.

מנגד, LangSmith סגור-מקור (למעט ה-SDKs), פורמט ה-tracing שלו קנייני, ותמיכת OTel שלו מוגבלת (אתם יכולים לייצא חלק מהנתונים, אבל זה לא מקורי). Self-host זמין רק במסלול Enterprise. מבחינת מחיר, Plus מתחיל ב-$39 לכל user לחודש, כולל 10K trace בסיסיים, ו-overage של $2.50 לכל 1K trace עם 14 יום שמירה, או $5 לכל 1K עם 400 יום. צוות של 5 אנשים בייצור בקלות מגיע ל-$500 עד $1,000 לחודש.

ההחלטה שלי היא פשוטה. אם הצוות שלכם מבוסס LangGraph ואתם מעריכים את ה-debugger שלו (שהוא באמת מצוין), LangSmith מצדיק את הפרימיה. אם אתם מערבבים ספריות (mixed SDK), הנעילה למסגרת אחת הופכת לחסרון גדול. לרקע רחב יותר על המסגרת עצמה, כדאי לקרוא את המדריך שלי לבניית מערכות מרובות סוכנים ב-2026, שם אני מפרט מתי LangGraph מוצדק כברירת מחדל.

Helicone: פרוקסי פשוט לרישום קריאות LLM

Helicone היא הפלטפורמה עם התקנת המצווה הכי נמוכה בקטגוריה. משנים base URL אחד בקליינט של OpenAI/Anthropic וכל הקריאות שלכם נכנסות למערכת אוטומטית. בפרויקטים early-stage שבהם הצוות עדיין לא מוכן להשקיע ב-instrumentation מלא, זו הבחירה הכנה מבחינה הנדסית. Helicone תומכת ב-100+ ספקי LLM דרך פורמט ה-OpenAI SDK, ומספקת caching, rate limiting ו-retry שמובנים לתוך הפרוקסי, פיצ'רים שאף אחת מהאחרות לא מספקת בצורה כזו.

המגבלות שאסור להתעלם מהן

• ראייה של סוכנים: Helicone מבוססת בקשה/תגובה, לא ספאנים. סוכן רב-שלבי נתפר יחד רק בדיעבד מ-metadata של בקשות, ואין transcript view או debugger אמיתי.
• Latency: הפרוקסי מוסיף 20-50ms לכל קריאת LLM. עבור אפליקציות streaming זה יכול להיות מורגש.
• הערכה: אין LLM-as-a-Judge מובנה. הצוות שלכם יצטרך להריץ הערכות offline בכלי נפרד.

מבחינת עלות, החינם מכסה 10K בקשות/חודש, והתשלום מתחיל ב-$79/חודש. עבור צוות שמריץ ChatGPT wrapper פשוט או chatbot חד-שלבי בעלות של פחות מ-$30K/חודש בהוצאות LLM, Helicone היא לרוב ההחלטה הנכונה. לא כי היא הכי טובה, אלא כי כל השאר overkill. אבל ברגע שאתם מוסיפים סוכן עם tool use, הגבולות שלה קופצים החוצה.

OpenTelemetry GenAI: הסטנדרט של 2026

ב-21 במאי 2026 ה-CNCF הכריזה על ה-graduation של OpenTelemetry, וזה שינה את המשוואה של תצפית LLM. במקביל, ה-GenAI Semantic Conventions התבגרו, קבוצת שמות סטנדרטיים לתכונות ספאנים, מטריקות ו-events שמייצגות עומסי AI. במילים אחרות: ספאן שיוצא מקריאת LangChain צריך להיראות זהה לספאן מקריאת OpenAI ישירה.

תכונות סטנדרטיות מרכזיות

• gen_ai.system, ספק ה-LLM (openai, anthropic, google וכו').
• gen_ai.request.model, שם המודל.
• gen_ai.request.temperature, טמפרטורה לצורכי model governance.
• gen_ai.usage.input_tokens, gen_ai.usage.output_tokens, שימוש בטוקנים.

הקונבנציות ממליצות במפורש לא לאחסן טקסט פרומפטים בתכונות ספאנים (attributes תמיד נוצרים אינדקס, מגבלות גודל, וחשיפת PII). במקום זאת, הטקסט נשמר ב-span events, שאפשר לסנן או להוריד ברמת ה-Collector בלי לגעת בקוד האפליקציה. זה שינוי חשוב לצוותי compliance.

Auto-instrumentation packages קיימים ל-OpenAI, Anthropic, LangChain ו-LlamaIndex. ה-overhead של OTel נמדד בפחות ממילישניה (קריאת LLM עם latency של 100ms עד 30s מכתיבה את הכל בכל מקרה). הפרטים המלאים על ה-schema מפורסמים ב-בלוג OpenTelemetry הרשמי.

איך בוחרים? מטריצת החלטה מעשית

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

• מתחת ל-$30K/חודש בהוצאות LLM, שרשראות פשוטות: Helicone. אתם צריכים לוגים, לא debugger.
• בין $30K ל-$200K/חודש, סוכנים רב-שלביים, SDK מעורב: Langfuse (managed cloud אם מהירות חשובה, self-host אם compliance קריטי).
• מעל $200K/חודש, השקעה עמוקה ב-LangGraph: LangSmith מצדיק את הפרימיה. ה-debugger שלו חוסך שעות דיבוג ביום.
• HIPAA / GDPR / air-gapped: רק Langfuse self-hosted מספק מסלול תואם באמת. LangSmith Enterprise קרוב, אבל רק אחרי חוזה.
• סטארט-אפ מוקדם בלי תקציב: Langfuse cloud (50K observations בחינם). התוכנית החינמית שלו הכי נדיבה.

שימו לב שרוב הצוותים הבוגרים שאני עובד איתם משתמשים ב-שתיים מהפלטפורמות: Langfuse לתצפית ייצור והערכה, ו-LangSmith בפיתוח כשמדובר ב-LangGraph. זה לא כפילות. אלה תפקידים שונים.

קוד לדוגמה: הטמעת Langfuse עם OpenAI SDK

הדוגמה הבאה מראה איך לחבר את Langfuse ל-OpenAI SDK עם decorator שמייצר טרייס מלא כולל span לכל קריאה. הקוד עובד גם עם Langfuse cloud וגם עם self-host (רק ה-host משתנה). שימו לב שאני משתמש ב-flush() בסוף, וזה קריטי בסביבות serverless שבהן התהליך עלול להסתיים לפני שה-batch נשלח. הכשלתי pod שלם ככה בפעם הראשונה שדחפתי סוכן ל-Lambda, אז אני ממליץ ללמוד את זה קודם.

from langfuse import Langfuse, observe
from langfuse.openai import openai  # OpenAI SDK wrapped for auto-tracing

langfuse = Langfuse(
    public_key="pk-lf-...",
    secret_key="sk-lf-...",
    host="https://cloud.langfuse.com",  # or your self-host URL
)

@observe(name="customer-support-agent")
def answer_customer(question: str, user_id: str) -> str:
    # decorator creates a parent trace that includes all nested calls
    langfuse.update_current_trace(user_id=user_id, tags=["support", "prod"])

    # step 1: classify the question type
    classification = openai.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": "Classify: technical / billing / other"},
            {"role": "user", "content": question},
        ],
        name="classify-intent",  # shows up as the span name
    )
    intent = classification.choices[0].message.content

    # step 2: generate the answer with the appropriate model
    answer = openai.chat.completions.create(
        model="gpt-4o" if intent == "technical" else "gpt-4o-mini",
        messages=[
            {"role": "system", "content": f"You are a {intent} agent. Be concise."},
            {"role": "user", "content": question},
        ],
        name="generate-answer",
    )

    # step 3: custom quality score, e.g. answer length
    langfuse.score(name="answer-length", value=len(answer.choices[0].message.content))

    return answer.choices[0].message.content


if __name__ == "__main__":
    reply = answer_customer("How do I reset my password?", user_id="u_123")
    print(reply)
    langfuse.flush()  # critical in serverless — force the batch to send

עם הקוד הזה, כל פעם ש-answer_customer נקרא, אתם מקבלים בממשק Langfuse עץ ספאנים: trace אב עם השאלה כקלט, שני spans צאצאים לשתי הקריאות ל-OpenAI, ציון אחד, וטוקנים ועלות מחושבים אוטומטית. אם אתם רוצים לחבר גם כלים חיצוניים, ה-@observe עובד על כל פונקציה, כולל קריאות API, שאילתות DB וקריאות retriever.

לצוותים שכבר משתמשים ב-Prompt Caching של Claude ו-OpenAI, Langfuse קולטת את מטריקות ה-cache אוטומטית מה-response. אתם רואים cache hits, savings וההשפעה על ה-latency באותו dashboard.

טעויות נפוצות בתצפית על סוכני LLM

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

1. הפרדת trace context בין service ל-service

כשסוכן קורא ל-microservice אחר (למשל retriever ב-service נפרד), אם לא מעבירים את ה-trace context ב-HTTP headers, אתם מקבלים שני טרייסים נפרדים במקום אחד. השתמשו ב-W3C Trace Context standard. כל SDK מכובד תומך בזה מובן.

2. אחסון פרומפטים ב-attributes במקום events

זה מפר את ה-OTel GenAI conventions, מייקר את ה-storage, וחושף PII ב-backend. השתמשו בספאן events לתוכן. הם ניתנים לסינון ב-Collector.

3. הסתמכות רק על LLM-as-a-Judge בלי code evaluators

Judges הם דרך יקרה, לא-דטרמיניסטית לענות על שאלות שלעיתים קרובות קוד רגיל עונה עליהן מושלם. אם אתם בודקים "האם התשובה מכילה JSON תקין?" השתמשו ב-regex או ב-JSON schema, לא ב-LLM. שמרו judges לשאלות סובייקטיביות באמת (טון, עוזרות, בטיחות). אני מרחיב על זה במאמר על בדיקות והערכת אפליקציות LLM עם DeepEval.

4. דגימה (sampling) לא נכונה בייצור

אם אתם דוגמים 1% מהטרייסים כי הכמות עצומה, זה בסדר, אבל ודאו שאתם דוגמים 100% של טרייסים עם שגיאה. Langfuse ו-LangSmith שניהם תומכים ב-tail sampling, הפעילו את זה.

5. שימוש בתצפית כתחליף להערכה offline

תצפית אומרת לכם מה קרה בייצור. הערכה offline על datasets אומרת לכם אם השינוי הבא שלכם ישפר את זה. אתם צריכים את שניהם. הגישה שלי: כל trace בעייתי מהייצור נכנס אוטומטית ל-dataset הערכה, ואז אנחנו רצים eval sweep לפני deploy. זה משתמש ב-Langfuse ו-DeepEval יחד.

שאלות נפוצות

מה ההבדל בין LangSmith ל-Langfuse?

LangSmith הוא מוצר קנייני של LangChain עם אינטגרציה מקורית לעומק ל-LangChain ו-LangGraph. הוא מדגים node-by-node state diffs וגרפים של הרצת סוכן. Langfuse הוא פלטפורמה פתוחת-מקור (MIT) עם תמיכה מקורית ב-OpenTelemetry GenAI, framework-agnostic, ו-self-host מלא ללא רישוי. לצוותים שלא נעולים ל-LangChain, Langfuse הוא לרוב הבחירה היותר גמישה.

האם Langfuse באמת קוד פתוח וניתן להרצה עצמית?

כן. Langfuse מפורסם ברישיון MIT, וה-docker-compose.yml הרשמי בונה את המחסנית המלאה (Postgres, ClickHouse, Redis, MinIO ושירותי web/worker). הפיצ'רים המלאים, כולל LLM-as-a-Judge, prompt management ו-datasets, זמינים ב-self-host ללא עלות. פיצ'רי enterprise ספציפיים כמו SSO ו-audit logs זמינים בתשלום.

כמה עולה LangSmith לצוות של 5 מפתחים?

LangSmith Plus עולה $39 לכל user לחודש, כלומר $195/חודש רק על מושבים לצוות של 5. הוא כולל 10K trace בסיסיים, ו-overage של $2.50 לכל 1K trace עם 14 יום שמירה (או $5 עם 400 יום). צוות בייצור בקלות מגיע ל-$500 עד $1,000 לחודש. Langfuse Pro עולה $199 לחודש קבוע בלי seat charges.

האם Helicone מתאים לסוכנים רב-שלביים?

לא באמת. Helicone היא פרוקסי מבוסס בקשה/תגובה, לא span-tracing. סוכן רב-שלבי נתפר יחד רק בדיעבד מ-metadata, ואין transcript view או debugger אמיתי. עבור סוכן עם tool use, Langfuse או LangSmith יספקו ראייה עמוקה בהרבה.

מה זה OpenTelemetry GenAI Semantic Conventions ולמה זה חשוב?

אלו סטים סטנדרטיים של שמות תכונות ספאנים, מטריקות וסכמות events שהוגדרו ב-OpenTelemetry GenAI SIG. הם מבטיחים שספאן מ-LangChain יראה זהה לספאן מ-OpenAI ישירה. עם ה-graduation של OTel ב-CNCF במאי 2026, זה הופך לסטנדרט התעשייתי לתצפית AI ומצמצם משמעותית vendor lock-in.