הגדרת נראות AI: LangSmith, Langfuse, Helicone

AI observability: למה תשובות של מודל מדרדרות בפרודקשן

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

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

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

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

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

מה נותן AI observability: שינויים מדידים

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

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

זמן תחקור תקלות

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

שיעור הסטיות שנתפסות

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

היקף הבדיקות הידניות

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

אפשרויות חיבור נראות: השוואה

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

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

סדר היישום: מביקורת ועד מסירה

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

ביקורת וספירת מלאי של קריאות

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

סכמת זרימות ואחסון נתונים

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

1. ספירת מלאי של קריאות והסכמה על רשימת השדות.
2. סכמת איסוף: נקודות דגימה, פורמט אירועים, חוצץ בצד האפליקציה.
3. הגדרת אחסון: מדיניות ניקוי, תוחלת חיים של רשומות, הסתרה.
4. בדיקה בסביבת טסטים: הרצת תרחישים, השוואה ללוגים, תחקור תקלה לדוגמה.
5. הערכת גידול נפח והתנהגות תחת עומס.
6. מסירת נהלים: קריאת trace, התראות, פעולות כשהאיסוף נכשל.

ארטיפקטים בפלט: מה נשאר לצוות

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

קונפיגורציות וסכמות

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

מדיניות גישה ונהלים

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

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

מקרה בוחן: איך קיצרנו את זמן תחקור התקלות

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

מה היה לפני

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

• איתור הכשל — 5–6 שעות, אם בכלל הצליחו לאסוף את ההקשר.
• הסיבה הראשונית נמצאה ב-40% מהמקרים, את השאר סגרו בהפעלה מחדש — והתלונה חזרה.
• פניות חוזרות על אותה בעיה — כשליש מהמשתמשים.
• עד 25 תקלות בחודש, חלק מהן רק הלקוח שם לב אליהן.

מה השתנה אחרי

פרסו tracing על Langfuse: כל בקשה — עץ של שלבים עם קלט, פלט, השהיה ומספר טוקנים, ולכן השלב הכושל נראה בלי איסוף ידני. מעל זה — מערך שאלות ייחוס עם בדיקה אוטומטית של תשובות והתראות על ירידה בשיעור התשובות המוצלחות.

• איתור הכשל — 15–20 דקות יחד עם אישור הסיבה.
• הסיבה הראשונית נמצאה ב-9 מתוך 10 תחקורים, מקרים שנויים במחלוקת נסגרים בקישור ל-trace.
• פניות חוזרות ירדו ב-60%: התחקור מסתיים בתיקון, לא בהפעלה מחדש.
• תקלות — מ-25 ל-8 בחודש, את השאר תופס מערך רגרסיה לפני ריליס.

כל תחקור מוסיף למערך הבדיקות, ולכן כשל דומה עולה בטסטים, ולא אצל הלקוח.

במה tracing שונה מלוגים של בקשות

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

Tracing מתאר בקשה כעץ של שלבים עם מזהה חוצה משותף. ב-trace אחד רואים כמה קטעים הועלו מהמאגר, עם אילו פרמטרים קראו למודל, אילו כלים הופעלו וכמה זמן לקח כל שלב. קשרי אב-בן מראים שרשראות קריאה למודל, כולל פניות מקוננות וחוזרות, שבלוג נראות כקבוצה של שורות לא קשורות.

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

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

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

מגבלות: אחסון נתונים, פרטיות, השהיות

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

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

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

ב-trace נשארת מבנה הקריאה ומדדים שמספיקים לתחקור, אבל לא הטקסט שאסור להראות מחוץ לקונטור. רשימת הכללים מתוחזקת יחד עם השינויים בקוד — אחרת שדה חדש בטופס שוב יתחיל לדלוף לטלמטריה.

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

נדבר על המשימה: מה מבררים בפגישה הראשונה

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

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

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