הערכת RAG בלי אשליות: איך Overfitting הופך ציון AI של 97% לסיכון עסקי
מערכות RAG נמדדות לעיתים שוב ושוב על אותן שאלות עד שהציונים נראים מצוינים. אבל מאחורי שיפור עקבי במדדים עלולה להסתתר בעיית Overfitting קלאסית, שמטעה צוותי AI, מנהלים ולקוחות לגבי ביצועי המערכת בעולם האמיתי.
כשהמבחן הופך לחלק מהאימון
בפרויקטי בינה מלאכותית ארגוניים, ובעיקר במערכות RAG המחברות מודלי שפה למאגרי ידע פנימיים, שלב ההערכה נתפס לעיתים כשלב טכני בסוף הדרך. מריצים סט שאלות, בודקים תשובות, מתקנים פרומפטים, משנים את מנגנון השליפה ומריצים שוב. אם הציון מטפס מ-82% ל-91% ואז ל-97%, קל להרגיש שהמערכת מתבגרת. בפועל, ייתכן מאוד שהיא פשוט לומדת את המבחן.
רוצה להישאר מעודכן ב-AI?
הירשם לדיוור השבועי שלנו וקבל עדכונים, המלצות על כלים, חדשות ודוחות מיוחדים
זו אינה רק בעיה מתודולוגית. זו בעיה עסקית. ארגון שמאשר מערכת RAG על בסיס סט בדיקות שנעשה בו שימוש חוזר עלול לפרוס לייצור מערכת שנראית מדויקת במעבדה אך מתקשה מול שאלות אמיתיות של עובדים, לקוחות, אנשי תמיכה או צוותים משפטיים. במקרה כזה, המדד אינו מודד עוד יכולת הכללה, אלא התאמה צרה לתרחישים שכבר נחשפו לצוות הפיתוח.
ההבדל הקריטי בין הערכה לפיתוח
בלמידת מכונה קלאסית נהוג להפריד בין סט אימון, סט ולידציה וסט בדיקה. סט הבדיקה אמור להישאר נקי, כלומר כזה שהמודל ותהליך קבלת ההחלטות סביבו לא נגעו בו. ברגע שמשתמשים בתוצאות הבדיקה כדי לשנות את המודל, לבחור פרומפט, להחליף רטריבר או להסיר שאלות בעייתיות, סט הבדיקה מפסיק להיות בדיקה והופך לחלק מתהליך הפיתוח.
ב-RAG הבעיה מבלבלת יותר, משום שהדאטה אינו נראה כמו טבלת מספרים מסודרת. הוא מורכב משאלות, מסמכים, קטעי ידע ותשובות בשפה טבעית. צוות יכול לכתוב שאלות מתוך המסמכים שכבר אונדקסו, לבחור ניסוחים שהמערכת מצליחה לשלוף עבורם הקשרים טובים, או להסיר שאלות שמייצרות כישלונות מביכים. כל פעולה כזו נראית הגיונית בפני עצמה, אך יחד הן יוצרות הערכה מוטה.
חוק גודהארט מגיע לעולם ה-RAG
חוק גודהארט קובע שכאשר מדד הופך למטרה, הוא מפסיק להיות מדד טוב. זה בדיוק מה שקורה כאשר צוותי AI מתחילים למקסם Precision@k, Recall@k, MRR או ציוני תשובה בלי לשאול האם המדדים עדיין משקפים שימוש אמיתי. ברגע שהיעד הוא להגיע לציון גבוה בדוח, ולא להבטיח תשובות מהימנות בסביבת ייצור, המערכת עלולה להשתפר במספרים ולהידרדר במציאות.
לכן, הערכת RAG רצינית צריכה לכלול סט בדיקה שמור שאינו משמש לכיול שוטף, שאלות שנכתבות באופן בלתי תלוי יחסית מההתנהגות הידועה של המערכת, ומדידה תקופתית על תרחישים חדשים. לצד מדדים אוטומטיים, חשוב לשלב בדיקה אנושית של איכות התשובה, נאמנות למקור, יכולת לומר 'לא יודע' ועמידות מול שאלות מעורפלות או חוצות מסמכים.
המשמעות למנהלים ולצוותי AI
הלקח המרכזי הוא שציון גבוה אינו שקול לבשלות מוצרית. מנהל מוצר AI צריך לשאול מתי נבנה סט ההערכה, מי ראה אותו, כמה פעמים נעשה בו שימוש, והאם תיקונים בוצעו בעקבותיו. צוות דאטה צריך לתעד גרסאות של סטים, להפריד בין סט פיתוח לסט בדיקה, וליצור מנגנון מתמשך לאיסוף שאלות אמיתיות מהשטח.
מערכת RAG טובה אינה מערכת שזוכרת בחינה קודמת. היא מערכת שמצליחה לענות באופן עקבי, מבוסס ומבוקר גם כאשר השאלה מגיעה לראשונה. בעולם שבו ארגונים מחברים מודלי שפה לידע רגיש, ההבדל הזה הוא ההבדל בין הדגמה מרשימה לבין מערכת שאפשר לסמוך עליה.