לוגינג LLM: היכן נשבר איסוף הבקשות והתשובות
כשל טיפוסי נראה תמיד אותו דבר: ביומן יש זמן, קוד תשובה ומשך הקריאה, אך גוף הבקשה והתשובה — חסרים. לוגינג מופעל בדרך כלל ברמת ה-reverse proxy, בעוד שהפרומפט נבנה בשירות ואינו מגיע אליו. בסופו של דבר יומן הפניות למודל מורכב ממטא-נתונים, שלפיהם לא ניתן לנתח תקלה.
צוואר הבקבוק השני הוא הזרמת התשובה. המודל מחזיר טקסט בקטעים, והאוסף או שומר רק את הקטע הראשון, או מדביק אותם ללא גבולות בין הודעות. בזמן timeouts וניסיונות חוזרים נרשמת ביומן רשומה אחת במקום כמה — הסיבה לכשל אינה נראית.
מזהה רוחבי (end-to-end) בין השירותים הולך לאיבוד, ולכן אין במה לקשור את הבקשה, את התשובה ואת פעולת המשתמש הבאה.
סיבה נוספת — נתונים אישיים ומפתחות בתוך הפרומפטים: בגללם לעיתים קרובות מכבים לוגינג LLM כליל, או מסווים אותו כך שמהטקסט נשאר אוסף תווים בלתי שמיש לניפוי שגיאות. בגלל זה נפגעת התחקור של אינטגרציית AI.
הפתרון שעובד — כללי עריכה בצד האפליקציה לפני הכתיבה: שדות רגישים מוחלפים, והשאר נשמר במלואו. נוח לבנות את הייצוא על תקן פתוח OpenTelemetry — פורמט אחיד מסיר את התלות של היומן בספק מודל אחד.
עבור התמיכה והמוצר משמעות הדבר היא אזור עיוור: אי אפשר לשחזר תלונה, אי אפשר למדוד את איכות התשובות, וחלקן של הקריאות הכושלות אינו ידוע. אנו מפרקים כיצד איסוף הבקשות והתשובות נסגר בכל אחד מהמקטעים הללו.
מה משתנה לאחר ההגדרה: זמן הניתוח ומחלקות הכשל
לפני הגדרת איסוף הנתונים, ניתוח פנייה לשירות AI מזכיר ארכיאולוגיה: המשתמש מתאר סימפטום במילים, התמיכה משחזרת את השרשרת בעזרת צילומי מסך ולוגים של האפליקציה, והבקשה עצמה למודל כבר אינה שמורה בשום מקום.
על השחזור הולכות שעתיים-שלוש, ובמחצית מהמקרים הסיבה נשארת לא מוכחת — תיקון בפרומפט או בעיבוד התשובה מתבצע "ליתר ביטחון".
תיעוד בקשות (tracing) סוגר זאת ישירות. כל פנייה מקבלת מזהה שקושר את בקשת המשתמש, את הפרומפט הסופי, את תשובת המודל, את הכלים שנקראו ואת משך כל שלב. המהנדס פותח כרטיס אחד ורואה את הרצף כולו — בלי ניחושים.
בפועל זמן ניתוח התקלה יורד משעות ל-10–15 דקות, ומקרים שנויים במחלוקת נבחנים לפי נתונים בפועל, ולא לפי תיאור.
ה-observability של שירות AI מעניקה תוצאה שנייה — ניהול מחלקות הכשל של המודל. במקום "השירות לא הגיב" אחד מופיעות בסטיסטיקה קטגוריות ניתנות להפרדה: חריגה מזמן ההמתנה אצל הספק, כשל בפענוח מבנה התשובה, סטייה מהפורמט המחייב, כשל בבדיקה שלנו.
עבור כל מחלקה מוגדרת התנהגות משל עצמה: ניסיון חוזר, נסיגה למודל גיבוי, או כשל מבוקר עם הודעה ברורה. חלק מהתקלות מפסיקות להגיע למשתמש פשוט מפני שעכשיו הן מתגלות בצד שלנו.
גם בקרת איכות התשובות משתנה לא פחות. כשכל זוג "בקשה — תשובה" שמור ומתויג, אין צורך בקריאה ידנית מלאה: די בבדיקה מדגמית לפי מדגם ובכללים אוטומטיים על פורמט ועל ניסוחים אסורים. שיעור הפניות הדורשות מעורבות אנושית יורד לכמה אחוזים.
אנו בונים זאת על בסיס תקן ה-tracing המבוזר OpenTelemetry — ייצוא תואם נשאר אצלכם, ולא מתמוסס בפאנל של מישהו אחר.
דרכי האיסוף: שכבת ביניים, עטיפת קריאה, זרם אירועים
דרך האיסוף קובעת היכן בדיוק מיורטת הפנייה למודל ומי אחראי על סכימת הרשומה. שכבת ביניים עומדת בגבול שבין השירות למודל ורואה את כל התעבורה, כולל קריאות משירותי legacy שאיש אינו רוצה לגעת בהם.
עטיפת קריאה חיה בתוך האפליקציה, ולכן מכירה את המשתמש, את התרחיש ואת מזהה הסשן, אך דורשת תיקון בכל נקודת פנייה.
זרם אירועים מפריד בין האפליקציה לאחסון: השירות רק מפרסם אירוע, והכתיבה, ההעשרה ותקופת השמירה חיים בצינור נפרד. מבחינת העומס האפשרויות נבדלות: שכבת ביניים מוסיפה מעבר רשת, עטיפה — השהיה בתשובת המודל עצמה, וזרם אירועים — סיכון לאובדן בעת הצפת מאגר, אם לא הוגדר שחרור לדיסק.
גם התחזוקה שונה: בשינוי פורמט הבקשה מתקנים את הסכימה במקום אחד בשער, בכמה נקודות קוד, או בחוזה האירוע.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| שכבת ביניים | סטאק מגוון, יש קריאות מקוד זר, נדרש פורמט כתיבה אחיד | אינה רואה הקשר עסקי ללא תגיות בכותרים; הופכת לנקודת כשל בנתיב הבקשה |
| עטיפת קריאה למודל | שירות אחד, חשוב הקשר מלא של הסשן והמשתמש | תיקונים בכל נקודת קריאה; פניות העוקפות את העטיפה אינן נרשמות |
| זרם אירועים | תדירות פניות גבוהה, אנליטיקה ואחסון בנפרד מהמוצר | השהיה עד להגעה לאחסון; נדרש פיקוח על הצפה ועל כפילויות |
בפועל משלבים בין השיטות: העטיפה מספקת הקשר, שכבת הביניים — כיסוי מלא, וזרם האירועים — עמידות תחת עומס.
שלבי ההטמעה: מסיור שטח ועד מסירת נהלים
סדר הצעדים כאן חשוב יותר מהמהירות: אם מתחילים ביירוט, מתקבל זרם של רשומות מפוזרות ללא בעלים, ללא תקופת שמירה וללא קישור למשתמש. לכן הולכים ממפת הזרמים לסכימת האחסון, ורק לאחר מכן מפעילים את האיסוף. כל שלב מסתיים בארטיפקט שניתן לבדוק לפני המעבר לשלב הבא.
- סיור שטח בזרמים. סקר מלאי: אילו שירותים פונים למודל, היכן הקריאות סינכרוניות והיכן מקובצות, מהם הנפחים בעומס שיא, ובאילו שדות בקשה מופיעים נתונים אישיים.
- סכימת זרמי נתונים. קובעים את הרכב הרשומה (בקשה, תשובה, משך, סמן שגיאה), את מקום ותקופת האחסון, את הפרדת הרשאות הגישה ואת כללי ההסוואה של שדות רגישים לפני הכתיבה.
- הגדרת היירוט. את האיסוף מציבים בשכבה נפרדת לפני המודל, כדי שהאפליקציה לא תתעטף בעטיפות מיותרות. את הרשומות מביאים לפורמט אחיד, ומקשרים במזהה בקשה, בגרסת התבנית ובחשבון היוזם.
- בדיקה על תעבורה חיה. מפעילים בהדרגה: תחילה נתח קטן של בקשות, לאחר מכן את כל הזרם. מודדים השהיה, שיעור אובדן רשומות ומלואות השדות, ומצליבים את היומן מול הקריאות בפועל.
- הכשרת הצוות. מראים כיצד לאתר דיאלוג מסוים, לשחזר כשל ולנתח תשובת מודל שנויה במחלוקת לפי הנתונים השמורים, ללא ייצוא מסביבת הפרודקשן.
- מסירת התיעוד. מוסרים את סכימת הזרמים, תיאור השדות, מדיניות האחסון והגישה, וסדר העדכון עם הופעת תרחישים חדשים.
בפלט — לא הגדרה חד-פעמית, אלא נוהל: ברור מי הבעלים של היומן, מה מונח בו וכיצד להשתמש בו בניתוח תקלות.
ארטיפקטים: סכימות, כללי גישה, נהלים ותיוג
לידי הלקוח נמסרת לא ערכת הגדרות, אלא תיעוד עובד, שלפיו הצוות שלו עצמו יוכל לשנות מסננים, להוסיף שדות ולנתח פניות בלי מעורבותנו. הכול מקושר לקונפיגורציות במאגר: התיקון מתואר כך שניתן לבצע אותו ולבדוק אותו בסביבת בדיקות.
- סכימת זרמי הרשומות — מנקודת הכניסה של הבקשה ועד האחסון: היכן מתבצע האלמון, באיזה שלב הרשומה הופכת לבלתי הפיכה, ואילו שירותים כותבים לאותו זרם.
- קונפיגורציות האיסוף — אילו שדות בקשה ותשובה נרשמים, רמות הפירוט, שיעור הדגימה, תגיות של שירות, סביבה וגרסת מודל.
- מדיניות גישה — תפקידים ותחומי ראייה: למי נגיש גוף התשובה, למי רק המטא-נתונים, וכיצד מקצים ומבטלים מפתחות.
- כללי שמירה ומחיקה — תקופות במעגל החם ובמעגל הארכיוני, כללי מחזור החיים, וסדר מחיקת רשומות לפי פנייה של משתמש.
- נוהל ניתוח פניות — כיצד לאתר לפי מזהה את שרשרת העיבוד המלאה, מי אחראי ובאילו מועדים.
- תיעוד האיסופים — רשימת השדות עם ייעודו של כל אחד, רשימת הנתונים המוסווים, והדרך לוודא שההסוואה פעלה.
- צ'ק-ליסט קבלה — תרחישי בדיקה: הרשומה מופיעה, הגישה מוגבלת לפי תפקיד, המחיקה עובדת, ובשינוי מודל הסכימה אינה נשברת.
הערכה יושבת במאגר של הלקוח ומתעדכנת יחד עם שינויי האיסוף — כך התיעוד אינו סוטה מהקונפיגורציה בפועל.
קייס: כיצד קיצרנו את זמן ניתוח הפניות לתמיכה
לפני הטמעת הלוגינג הרוחבי, ניתוח פנייה לתמיכה נראה כך: בטיקט יש את שאלת המשתמש ותשובה מוזרה של המודל, אך איזו גרסת פרומפט הייתה ברגע הקריאה, עם אילו פרמטרי יצירה ומה פעל לפניה ואחריה — אינו ידוע.
את הסיבה חיפשו בניסוי וטעייה של השערות, וחלק מהפניות נסגרו בניסוח "לא הצלחנו לשחזר". פגם שנמצא פעם אחת יכול היה לחזור לאחר התיקון הבא בפרומפט ולעבור שוב את אותו מסלול.
מה שינינו
כל פנייה קיבלה מזהה רוחבי שמקשר את הטיקט ב-Jira לרשומת הקריאה למודל. ברשומה נשמרים טקסט הפרומפט המלא עם תגית גרסה, פרמטרי היצירה, התשובה כולה, סיבת העצירה, המסננים שפעלו, ותוצאת הקריאות החוזרות בעת כשל.
נתונים אישיים מוסווים לפני הכתיבה, הגישה לארכיון מופרדת לפי תפקידים, ותקופת השמירה מוגדרת במדיניות ואינה דורשת ניקוי ידני.
| מדד | לפני | אחרי |
|---|---|---|
| שיעור הפניות ללא סיבה מוסברת לתשובה | 31% | 4% |
| זמן איתור הסיבה לפנייה (חציון) | 95 דקות | 12 דקות |
| שיעור הפגמים הניתנים לשחזור לפי היומן | 18% | 94% |
| חזרת פגם סגור לאחר תיקון בפרומפט | הבחנו בדיעבד | נתפס בהרצה לפני העלייה לאוויר |
יכולת השחזור של פגמים הפסיקה להיות הגרלה: תקלות מאותו סוג מתקבצות לפי גרסת פרומפט ומחלקת שגיאה, והתיקון נבדק על אותה קבוצת פניות מהארכיון. שחזוריות התשובה הפכה לתכונה של המערכת, ולא למזל של מהנדס מסוים.
במה שונה לוגינג LLM מיומן אפליקציה רגיל?
יומן אפליקציה רגיל נכתב סביב אירוע: סט שדות קבוע, רמת חשיבות, מזהה בקשה, זמן. לוגינג LLM נבנה סביב דיאלוג — יחידת הרשומה כאן היא לא "השירות החזיר שגיאה", אלא החלפה מלאה עם המודל, שאין לה מבנה יציב וגודל צפוי.
ההקשר של הבקשה הוא הסיבה העיקרית לכך שאי אפשר לקחת את סכימת הרשומה מיומן האפליקציה. בקריאה אחת נשלחים הוראה מערכתית, היסטוריית התכתבות, קטעים מוזרקים ממאגר הידע וטקסט המשתמש; האורך נע בין כמה שורות לעשרות אלפי תווים.
לכן מפרקים את הרשומה לשדות עם תפקידים ומסמנים בנפרד אילו חלקים בהקשר השפיעו בפועל על התשובה — בלי זה ניתוח התקלה הופך לקריאה של שורה ענקית אחת.
תשובה זורמת שוברת את המודל המוכר של "רשומה אחת — עובדה אחת". הקטעים מגיעים בחלקים, והיומן צריך לאסוף אותם לשלם, תוך שמירת הזמן עד לקטע הראשון וסמן לכך שהיצירה הסתיימה ולא נקטעה באמצע.
שכבה מחויבת — סינון נתונים רגישים: נתונים אישיים, מפתחות גישה ומסמכים פנימיים נכנסים לבקשה יחד עם שאלת המשתמש. ההסוואה מבוצעת לפני השמירה, ולא בזמן הקריאה, אחרת באחסון כבר מונח מה שדלף.
נפח האחסון גדל לא לפי מספר הפניות, אלא לפי אורך ההקשר: יממה של עובד על עוזר דיאלוגי עם היסטוריית התכתבות מכריעה חודשים של יומן רגיל. סכימה עובדת — להפריד שכבה חמה עם גופי בקשות מלאים ושכבה קרה עם מטא-נתונים ומדדים, לשמור פניות שגויות במלואן, ופניות מוצלחות באופן מדגמי.
ספקות טכניים נפוצים לפני תחילת העבודה
ספקות לפני התחלה עוסקים בדרך כלל לא ב"האם צריך לוגינג לבקשות LLM", אלא באופן שבו הוא מתקיים לצד הפרודקשן: נתונים רגישים בטקסטים, נפח האחסון, ההשפעה על זמן התשובה. אנו מפרקים חמש התנגדויות שעולות בתדירות הגבוהה ביותר.
בבקשות יש נתונים אישיים — מה איתם?
מסווים בכניסה לאחסון: דואר, טלפונים, מספרי מסמכים מוחלפים ב-placeholders, והמקור אינו נשמר. רשומות גולמיות נגישות רק לתפקיד נפרד וחיות תקופה מוגבלת — הלוגינג אינו הופך להעתק נוסף של מסד הנתונים עם נתוני לקוחות.
הלוגים ימלאו מהר את כל האחסון?
כותבים לא את הבקשה המלאה, אלא מבנה מנורמל: מזהה סשן, טביעת אצבע של הפרומפט, אורך, סטטוס. החלון החם קצר — הוא מספיק לניתוח תקלות, ומעבר לכך נשארים אגרגטים. הנפח גדל ממספר התרחישים, ולא באופן לינארי לתעבורה.
האם עומס העבודה יעמוד בזה?
הכתיבה א-סינכרונית: התשובה יוצאת למשתמש בלי להמתין לאחסון. אם היעד אינו זמין, הרשומות נצברות במאגר, והנתיב הראשי אינו נחסם. בתרחישים המוניים פועלת כתיבה מדגמית, ובקריטיים — כתיבה מלאה.
כיצד לאתר את כל שלבי הדיאלוג האחד?
מזהה סשן רוחבי נוצר בכניסה לשרשרת ומועבר דרך כל הקריאות, כולל ניסיונות חוזרים ופניות לשירותים חיצוניים. לפיו הדיאלוג נאסף במלואו, ולא כאוסף שורות לא קשורות.
כיצד להבין מה בדיוק כשל?
ברשומה נרשמת מחלקת הכשל: כשל של המודל עצמו, שגיאת אינטגרציה — תעבורה, הרשאות, פענוח תשובה — או שגיאה בקוד שלנו. המדדים וההתראות עבורם נפרדים, ולכן התורן רואה מיד את אזור החיפוש.
נדון במשימה שלכם: מה נדרש להערכה ולתוכנית
כדי לחזור עם הערכה ותוכנית עבודה, ולא עם עיונים כלליים, נדרשים נתוני קלט על המערכת שלכם. אין חובה ברשימה מלאה — נתחיל ממה שכבר מתואר, ואת השאר נדייק תוך כדי הניתוח. ככל שקווי המתאר מוגדרים מדויק יותר, כך ייכנסו פחות הנחות לתוכנית ההטמעה.
- סכימת הקריאות: אילו שירותים פונים למודל, באופן סינכרוני או דרך תור, והאם יש שער ביניים בין האפליקציה למודל.
- פרופיל העומס: כמה בקשות ביממה, חלונות שיא, שיעור התשובות הזורמות והסשנים הארוכים.
- דרישות לאחסון: תקופת החיים של היומן, האם נדרשים טקסטים מלאים של בקשות ותשובות או שמספיקים מטא-נתונים, והיכן פיזית מונחים הנתונים.
- תפקידים והרשאות: מי קורא את היומן, כיצד מופרדות הזכויות, ומה יש להסוות לפני הכתיבה.
- סדר ניתוח הפניות: כיצד מנותחות כעת תלונות על איכות התשובות, מי מקבל את ההחלטה ובאיזה מועד נדרש התוצאה.
- תשתית: היכן ממוקמים הרכיבים, אילו אחסונים ותורים כבר בשימוש, והאם יש מגבלות רשת.
- כלים קיימים: מה כבר אוסף מדדים ומקשר רשומות בין שירותים, כדי לא לשכפל איסוף.
לפי נתוני קלט אלה אנו מתארים את סכימת הלוגינג: נקודות היירוט, פורמט הרשומה, הפרדת ההרשאות, כללי השמירה והניקוי. לאחר מכן חוזרים עם הערכה ותוכנית עבודה — שלבים, תחומי אחריות ונוהל לניתוח פניות.