הערכת איכות מערכת RAG (RAGAS, דיוק, נזכרות, נאמנות)

למה הערכת RAG נשברת על נתונים אמיתיים

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

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

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

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

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

מה משתנה לאחר הטמעת בדיקות סדירות

הרצה סדירה על מערך שאלות קפוא מעבירה את איכות התשובות מתחושות למדד.

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

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

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

דרכי בדיקה: מסימון ידני ועד בדיקות אוטומטיות

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

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

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

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

שלבי הטמעת מעגל בקרת איכות

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

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

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

מה מועבר: מערכי בדיקות, ספים, נהלים

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

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

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

מקרה בוחן: הערכת RAG על זרם פניות לקוחות

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

מה היה

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

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

מה стало

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

דיוק הפגיעה בהקשר עלה מ-0.61 ל-0.87, נאמנות התשובה — מ-0.72 ל-0.94, שלמות המדגם — מ-0.58 ל-0.83. שיעור התשובות שנבנו על קטע לא רלוונטי ירד בערך פי שלושה — נעלמו עצות שגויות ופניות חוזרות באותו נושא.

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

במה שונה בדיקת חיפוש מבדיקת יצירה

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

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

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

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

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

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

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

שאלות טכניות נפוצות ומגבלות

לפני שמתחילים מתעדים את גבולות המדידה: מדדים כמו faithfulness, precision ו-recall מתארים את התנהגות המערכת על מערך שאלות מוכן, ולא את איכותה בכלל.

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

מהן המגבלות של המדדים עצמם?

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

באיזו תדירות להריץ הערכה ומתי לעדכן את המערך?

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

נדון במשימה ונחזור עם תוכנית עבודה

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

• תרחיש: אילו שאלות שואלים המשתמשים ואיזו תשובה נחשבת לנכונה;
• 20–50 שאילתות אמיתיות עם תשובות ייחוס והפניה לקטע המקור;
• הגדרות החיפוש הנוכחיות: כיצד המסמכים נחתכים לצ'אנקים, איזו מודל אמבדינגס, כמה קטעים מוזנים להקשר;
• קורפוס המסמכים או חתך אנונימי שלו — את הבדיקות אנחנו מריצים על הנתונים שלכם, ולא על מערך הדגמה;
• מדדים, אם כבר מחשבים: precision, recall, faithfulness, שיעור תשובות בלי עיגון בהקשר;
• תקלות ששמתם לב אליהן: עובדות מומצאות, קטעים מיושנים, אובדן מידע מאמצע המסמך;
• מגבלות נתונים: היכן אפשר לפרוס את המעגל, ואילו שירותים חיצוניים מותרים.

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

תארו את המשימה — נחזור עם הערכה ותוכנית.