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