RAG הוא לא למידת מכונה: הטעות היקרה שמכשילה פרויקטי AI ארגוניים
ארגונים רבים מתייחסים למערכות RAG כאילו היו מודלי למידת מכונה שיש לאמן, לכוונן ולמדוד בממוצעים. בפועל, מדובר בעיקר בבעיית חיפוש, עיבוד מסמכים והנדסת מערכת. ההבחנה הזו יכולה לחסוך חודשים של עבודה בכיוון הלא נכון.
למה פרויקטי RAG נתקעים במקום הלא נכון
הדיון סביב מערכות RAG, כלומר יצירת תשובות באמצעות אחזור מידע ממסמכים, סובל מבלבול עמוק: מאחר שהמערכת משתמשת במודלי שפה ובהטמעות וקטוריות, ארגונים מניחים שמדובר בפרויקט למידת מכונה קלאסי. מכאן הדרך קצרה להרצות ניסויי Optuna, לכוונן גדלי מקטעים, לבנות סט בדיקה מפואר ולרדוף אחרי מדד דיוק אחד. הבעיה היא שכל זה עלול להיות פעילות מרשימה מאוד, אך לא בהכרח רלוונטית.
רוצה להישאר מעודכן ב-AI?
הירשם לדיוור השבועי שלנו וקבל עדכונים, המלצות על כלים, חדשות ודוחות מיוחדים
במערכת ML רגילה המודל לומד דפוסים מנתונים ומנסה להכליל למקרים חדשים. ב-RAG ארגוני, לעומת זאת, התשובה כבר קיימת במסמך או שאינה קיימת כלל. אם משתמש שואל מהו תאריך תחילת החוזה, אין כאן הסתברות שצריך לנבא. יש שורה במסמך שצריך למצוא, להבין ולצטט. אם המערכת מחזירה תשובה שגויה, זו אינה טעות סטטיסטית נסבלת אלא כשל הנדסי שניתן לאתר בשרשרת: פרסר, הבנת שאלה, אחזור, או ניסוח התשובה.
הבעיה אינה אימון, אלא ארכיטקטורת חיפוש
RAG דומה יותר למנוע חיפוש עם שכבת ניסוח חכמה מאשר למודל שיש לאמן מחדש. זו הבחנה קריטית למנהלי מוצר, CTO וצוותי דאטה, משום שהיא משנה את סדרי העדיפויות. במקום לשאול מהו ה-chunk size האופטימלי, צריך לשאול האם המסמכים פוענחו נכון, האם הטבלאות והכותרות נשמרו, האם ראשי תיבות פנימיים מופו למונחים עסקיים, והאם מנגנון האחזור יודע להבחין בין תאריך נקודתי לבין סעיף חוזי שלם.
בפועל, אין גודל מקטע יחיד שמתאים לכל שאלה. שאלה על סכום ביטוחי דורשת דיוק בשורה אחת. שאלה על חריגים בפוליסה דורשת הבנה של סעיף מלא ולעיתים כמה סעיפים סמוכים. לכן הפתרון הבוגר אינו חיפוש מספר קסם, אלא ניתוב לפי סוג השאלה: חיפוש שורות, חיפוש סעיפים, חיפוש טבלאות, או שילוב חוקים מילוניים עם חיפוש סמנטי.
מדידה נכונה: לא דיוק ממוצע, אלא אבחון כשל
אחת הטעויות הנפוצות היא להסתפק בדיוק כולל. מדד כזה מסתיר יותר משהוא מגלה. מערכת עם 75 אחוז הצלחה יכולה להיכשל לגמרי בשאלות השוואה, אבל להיראות טובה בשאלות פשוטות על תאריכים. לכן מדידה מקצועית של RAG צריכה להתפרק לפי סוגי שאלות ולפי מקור הכשל: האם התשובה קיימת בקורפוס, האם הקטע הנכון אוחזר, האם מודל השפה נשאר נאמן לטקסט, והאם המערכת ידעה לומר שלא נמצאה תשובה.
זו גם הסיבה שמסגרות הערכה כלליות אינן מספיקות לבדן. הן עשויות לספק שכבת בקרה מועילה, אך אינן מחליפות בדיקה ספציפית של הקורפוס הארגוני. חוזים, מסמכי ביטוח, נהלי ציות ומפרטים הנדסיים נכשלים בדרכים שונות לחלוטין ממאגרי ידע ציבוריים.
המשמעות העסקית: פחות קסם, יותר הנדסה
הלקח לתעשייה ברור: פרויקט RAG מוצלח צריך פחות חוקרי ML ויותר שילוב בין מהנדסי תוכנה, מומחי אחזור מידע ומומחי תחום. מודל השפה אינו אמור להחליף את עורך הדין, החתם או איש הציות. הוא אמור להגדיל את התפוקה שלהם, לקרוא במהירות אלפי עמודים, להחזיר ציטוטים מדויקים ולעצב תשובות שמישות.
כאשר מבינים זאת, גם מחזורי השיפור מתקצרים. במקום חודשים של כוונון ואימון, צוות יכול לעקוב אחרי שאילתה כושלת, לבדוק מה אוחזר בפועל, לזהות שהפרסר ערבב עמודות או שהמילון החמיץ מונח פנימי, לתקן קובץ קונפיגורציה ולמדוד שוב. בעולם הארגוני, זו אינה רק הבחנה טכנית. זו דרך להחזיר אמון במערכות AI שמתחברות למסמכים קריטיים.