הערכת RAG בלי אשליות: כך מונעים ציון גבוה שמסתיר סיכון עסקי
ארגונים רבים בונים היום מערכות RAG שמחברות מודלי שפה למסמכים פנימיים, נהלים, חוזים, בסיסי ידע ומערכות שירות. ההבטחה ברורה: פחות חיפוש ידני, תשובות מהירות יותר, ויכולת להפוך ידע ארגוני מפוזר לכלי עבודה חי. הבעיה מתחילה כאשר ציון הערכה מרשים, למשל 97%, הופך לתעודת ביטוח ניהולית. בפועל, ציון כזה עלול לשקף מערכת שלמדה את הבחינה ולא מערכת שמסוגלת להתמודד עם השטח.
הערכת RAG חייבת להפריד בין פיתוח לבדיקה
מערכת RAG נמדדת בדרך כלל בשני צירים: איכות השליפה ואיכות התשובה. בצד השליפה בודקים מדדים כמו Precision@k, Recall@k או MRR, ובצד התשובה בוחנים נאמנות למקור, דיוק, כיסוי, היעדר הזיות ויכולת לומר איני יודע. כאשר מריצים שוב ושוב את אותן שאלות, משנים פרומפטים, מכוונים את הרטריבר, מסננים מסמכים ומסירים שאלות בעייתיות, סט הבדיקה מפסיק להיות בדיקה. הוא הופך לחלק מתהליך הפיתוח.
בלמידת מכונה קלאסית ההפרדה בין סט אימון, סט ולידציה וסט בדיקה היא עיקרון בסיסי. במערכות RAG ההפרדה מורכבת יותר, כי הדאטה בנוי משפה טבעית, מסמכים, הקשרים ותשובות אפשריות. לכן קל מאוד לייצר Overfitting בלי לשים לב. שאלה שנוסחה מתוך מסמך מוכר, תיקון פרומפט בעקבות כישלון ספציפי, או בחירת chunk size שמתאים בדיוק לשאלות ההערכה, יכולים לשפר מדד מספרי ועדיין לפגוע ביכולת הכללה.
בעיה של Overfitting היא סיכון AI ניהולי
חוק גודהארט רלוונטי כאן במיוחד: כאשר מדד הופך למטרה, הוא מפסיק להיות מדד טוב. בארגון, המשמעות אינה אקדמית בלבד. מערכת שמדורגת גבוה במעבדה יכולה להיכשל בשאלה של נציג שירות, בטענה משפטית עדינה, או בבירור פיננסי שמצריך שילוב בין שלושה מקורות. ברגע שהמערכת עונה בביטחון על בסיס הקשר חלקי, הסיכון עובר ממדד טכני להחלטה עסקית שגויה.
כאן בדיוק נדרשת הבנה שהטמעת AI אינה משימה טכנית בלבד. צריך ידע עמוק במודלים, בתהליכים עסקיים, בממשקי עבודה ובניהול סיכונים. כאשר צוותים מתמקדים רק בפרומפט או בכלי, הם מפספסים את שכבת הממשל: מי רשאי לשנות את סט ההערכה, מי מאשר גרסה חדשה, איך מתעדים כשלי תשובה, ואילו החלטות אסור לאפשר ללא אדם בלולאה. אדם בלולאה אינו אמור לבדוק כל תשובה ידנית, אלא לפקח על מאות תהליכים באמצעות דגימה חכמה, התרעות חריגה ובדיקות עומק בנקודות סיכון.
מדדי RAG צריכים להיבנות כמו מוצר ארגוני
הדרך הנכונה מתחילה בבניית שלושה סטים נפרדים: סט פיתוח פתוח לצוות, סט ולידציה לכיול מבוקר, וסט בדיקה שמור שאינו נחשף למי שמבצע אופטימיזציה יומית. מומלץ להוסיף לכל גרסת מערכת לפחות 50 עד 200 שאלות חדשות מהשטח, מסווגות לפי תחום, רמת עמימות, צורך בחציית מסמכים ורמת סיכון. לצד מדדים אוטומטיים, צריך דירוג אנושי מובנה של נאמנות למקור, שימוש בציטוטים, זיהוי חוסר ידע ואיכות ההסבר העסקי.
ארגון שרוצה להפעיל RAG ברמת ייצור צריך להתייחס להערכה כתשתית מתמשכת ולא כאירוע לפני השקה. יש לתעד גרסאות של אינדקסים, פרומפטים, מודלים, מסנני אבטחת מידע ומדיניות הרשאות. יש למדוד גם כישלונות: תשובות ללא מקור, תשובות עם מקור לא מתאים, שליפה נכונה ותשובה שגויה, ותשובה נכונה שנאמרה בביטחון נמוך מדי. הנתונים האלה הם חומר הגלם לשיפור אמיתי, לא רק למצגת הנהלה יפה.
העמדה המקצועית שלנו ברורה: אין לאשר מערכת RAG ארגונית רק כי המדד עלה. צריך לאשר אותה כאשר ברור מה היא יודעת, מה היא לא יודעת, באילו תרחישים היא דורשת פיקוח, ואיך הארגון ימשיך למדוד אותה אחרי העלייה לאוויר. בינה מלאכותית יכולה לייצר התייעלות תפעולית משמעותית, אבל רק כאשר מחברים יכולת טכנולוגית, ניסיון עסקי, ממשל נתונים ואוריינות ניהולית. מערכת שזוכרת מבחן אינה נכס אסטרטגי. מערכת שמכלילה נכון, מסבירה את עצמה ונבדקת ברציפות, היא כבר תשתית עסקית שאפשר לבנות עליה.
