LangSmith או Phoenix: נוחות מנוהלת מול בעלות על נתוני המעקב

לצוות שבונה בעיקר ב־LangGraph ומעדיף שירות מנוהל, LangSmith הוא בדרך כלל הבחירה הנוחה יותר. כשיישום משלב כמה מסגרות פיתוח, או שנתוני המעקב חייבים להישאר בתשתית הארגון, Phoenix עשוי להתאים יותר — בתנאי שיש מי שיתפעל אותו. הבחירה נקבעת לפי הדרך שבה נוצרים ה־traces, המקום שבו הם נשמרים והעבודה הנדרשת כדי להפוך אותם לאבחון שימושי.

היתרון של Phoenix בסביבה מעורבת נשען על מכשור פתוח ורחב: תיעוד Phoenix מתאר קליטת traces דרך OpenTelemetry ותמיכה במכשור למסגרות, ספקי מודלים ושפות שונות. גם LangSmith תומך ב־OpenTelemetry, ולכן התקן לבדו אינו מכריע. לצוות בישראל שמטפל בנתוני לקוחות, השאלה הדחופה יותר היא אילו פרטים נרשמים בכל שלב של הריצה ולאן הרשומה נשלחת.

כשמרבית הריצה בנויה ב־LangGraph

בסביבה שכבר נשענת על LangGraph, החיבור הטבעי ל־LangSmith חוסך עבודת מכשור ראשונית. הסבר LangChain על המכשור מתאר יצירה אוטומטית של traces מיישומי LangChain ו־LangGraph, לצד אפשרות לייצא אותם גם בפורמט OpenTelemetry. צוות שמריץ סוכן בסביבה זו יכול לראות את שלבי הריצה בלי לבנות מראש תיאור ידני לכל קריאה פנימית.

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

כשאותה בקשה עוברת בין כמה SDKs

ביישום שמשלב קריאות למודל, אחזור מסמכים וכלים מספריות שונות, Phoenix נותן לצוות יעד משותף ל־traces שנוצרים במכשור תואם OpenTelemetry. היתרון המעשי אינו עצם האפשרות לקלוט כל פעולה, אלא היכולת לראות אילו פעולות שייכות לאותה בקשת משתמש. לשם כך נדרשת העברה עקבית של הקשר המעקב בין רכיבי היישום; אחרת מתקבלות רשומות נפרדות שקשה לחבר לכשל אחד.

גם LangSmith מסוגל לעבוד עם OpenTelemetry, כך שצוות עם SDKs מגוונים אינו חייב לעבור ל־Phoenix. ההבדל התפעולי הוא היכן הצוות כבר משקיע את עבודת החיבור: במכשור פתוח ובשירות שהוא מפעיל בעצמו, או בקליטת הנתונים לשירות מנוהל. בשני המסלולים כדאי להבחין בין שדות תקניים, כגון מזהי trace ו־span, לבין מאפיינים שהיישום מגדיר לצורכי ניתוח. מאפיינים ייחודיים מדי למסך או למנגנון הערכה של כלי אחד עלולים להקשות על מעבר, גם כשה־traces עצמם נשלחים בתקן פתוח.

איך מבחינים בין כשל באחזור לכשל בתשובה

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

Phoenix מאפשר להצמיד הערכות ל־traces ול־spans, ולהריץ בדיקות מבוססות קוד או מודל על ריצות ומערכי נתונים. תיעוד ההערכה של Phoenix מתאר גם מדדים מוכנים למשימות RAG ולסוכנים המשתמשים בכלים. כך אפשר להפריד, למשל, בין בדיקה של רלוונטיות הקטע שאוחזר לבין בדיקה של התשובה שנוסחה ממנו. LangSmith מציע אף הוא מעקב והערכה; בתרחיש הזה יש יתרון לכלי שבו שלבי האחזור והמשוב כבר קשורים זה לזה באופן שהצוות מסוגל לנתח. בדיקה באמצעות מודל שופט עשויה להוסיף קריאות בתשלום לספק המודל, בלי קשר למחיר מערכת המעקב.

לחשב traces, spans ושמירה בנפרד

ההשוואה הכספית מתחילה ביחידת החיוב. מחירון LangSmith מציג במסלול Developer עד 5,000 traces בסיסיים בחודש למשתמש יחיד, ובמסלול Plus מחיר של 39 דולר למושב בחודש ועד 10,000 traces בסיסיים; שימוש מעבר למכסה מחויב בנפרד, ואפשרויות אירוח עצמי והיברידי מוצעות במסלול Enterprise בתמחור מותאם. המחירון מגדיר trace כריצה אחת שיכולה להכיל צעדים רבים. לכן ספירת קריאות למודל או לכלים אינה תחליף לספירת הריצות לצורך הערכת המכסה.

נניח, כדוגמת תכנון בלבד, שסוכן מבצע 20,000 ריצות בחודש, ובכל ריצה נרשמים בממוצע 12 spans של אחזור, קריאות למודל וכלים. התוצאה היא 20,000 traces וכ־240,000 spans. מספר ה־spans אינו הופך את חיוב LangSmith לחיוב על 240,000 traces, אבל הוא מלמד כמה אירועים ותוכן עשויים להיקלט ולהישמר. גם שתי ריצות עם מספר spans דומה יכולות לתפוס נפח שונה מאוד אם אחת מהן שומרת טקסטים ארוכים או תוצאות אחזור מלאות.

לתרחיש LangGraph בשירות המנוהל יש אפוא בסיס של מושבים, מכסת traces ושימוש נוסף, לצד החלטה אילו ריצות לשמור לפרק זמן ארוך יותר. בתרחיש של Phoenix באירוח עצמי אין דמי רישיון, אך העלות הצפויה נובעת מאחסון, מסד נתונים, גיבויים, שדרוגים וזמן תפעול. ביישום עם SDKs מעורבים מצטרפת גם עבודת המכשור בשני הכלים. מי שמחשב עלות לפי מספר בקשות המשתמש בלבד מפספס את ההבדל בין ריצה קצרה לבין סוכן שמפעיל כלים שוב ושוב, ואת העלות הנפרדת של הערכות שמריצות מודל נוסף.

כשמידע רגיש מחייב אירוח עצמי

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

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

קראו גם:

• Pinecone או Weaviate: יחידות קריאה מול ממדי וקטור משנות את העלות
• Coursera או LinkedIn Learning ל־AI: עומק מול מהירות בדרך לעבודה