ניטור איכות תשובות LLM: מדדים, סחיפה והתראות

ניטור LLM: היכן נשברת איכות התשובות של המודל

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

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

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

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

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

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

מה נותן בקרת איכות רציפה של תשובות המודל

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

מה נעשה למדיד

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

על השאלה "האם נעשה גרוע יותר אחרי תיקון תבנית הבקשה" עונים בדקות, ולא בשבוע של איסוף משוב.

כיצד זה משנה את התפעול

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

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

מה מפסיק להגיע למשתמש

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

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

ניטור LLM: השוואה בין גישות לתצפית

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

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

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

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

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

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

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

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

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

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

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

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

מה נשאר אצל צוות הלקוח לאחר ההטמעה

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

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

את הערכה מוסרים יחד עם הדרכת משמרת התורנות וניתוח האירוע הראשון.

מקרה בוחן: כיצד צמצמנו את שיעור התשובות הכושלות ואת זמן התגובה

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

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

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

מה קרה למדדים

שיעור התשובות השגויות ירד מ-12% ל-3–4%, זמן התגובה לאירוע — מ-6–8 שעות ל-30–40 דקות, שיעור החריגות שנמצאו בדיעבד — מ-70% ל-15%. רגרסיה לאחר עדכון המודל נתפסת כעת בבדיקה: אם ההערכה על מערך הייחוס צונחת ביותר מ-5% ביחס להרצה הקודמת, הגרסה אינה יוצאת למשתמשים.

במה נבדלת הערכת תשובות על ידי מודל מתיוג ידני?

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

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

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

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

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

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

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

ספקות טכניים נפוצים בנוגע לתצפית על המודל

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

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

בתשובות יש נתונים אישיים של לקוחות

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

האם אפשר לעקוב בלי גישה לבקשות המשתמשים?

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

כמה זמן לשמור היסטוריית בקשות?

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

נדון במשימה: מה נחוץ להתחלת התצפית

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

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

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

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

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

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