RAG או Fine-tuning: מסמכים משתנים הופכים אימון מחדש לבחירה היקרה

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

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

ידע עדכני מול שינוי התנהגות

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

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

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

מטריצת החלטה לידע ארגוני

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

• קצב שינוי: כשנהלים, מחירים או מפרטים מתחלפים לעיתים קרובות, אחזור מאפשר להחליף את המקור במאגר. כשהמשימה יציבה והכשל הוא באופן הביצוע שלה, אימון נוסף נעשה רלוונטי יותר.
• הפניות למקורות: אם עובד צריך לדעת על איזו גרסה של נוהל התבססה תשובה, יש יתרון למסלול שבו המסמך נשלף בזמן הבקשה. גם אז נדרשת בדיקה שהגרסה הנכונה הוחזרה ושהציטוט מדויק.
• פורמט והתנהגות: אם העובדות נכונות אך שדות חסרים, הסיווג משתנה בין מקרים דומים או הסגנון אינו מתאים, כדאי לבדוק תחילה הוראות ודוגמאות בפרומפט. כישלון חוזר על אותן דוגמאות עשוי להצדיק fine-tuning.
• תחזוקה ועלות: RAG דורש קליטת מסמכים, אינדוקס, חיפוש ובקרת איכות. אימון נוסף דורש דוגמאות מתאימות, הרצת אימון ובדיקות חוזרות כשהמשימה או הידע שנלמד משתנים.
• רגישות והרשאות: בשתי השיטות צריך לקבוע מי רשאי להשתמש במידע והיכן הוא נשמר. ב־RAG החיפוש חייב לכבד הרשאות למסמכים; באימון נוסף צריך לבחון אילו פרטים רגישים נכנסים לדוגמאות האימון.

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

איפה נוצרת העלות כשמסמך משתנה

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

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

לפני אימון נוסף: מאבחנים תשובה חלשה

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

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

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

מתי השילוב מצדיק את המורכבות

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

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

קראו גם:

• Patreon מבטלת תשלום לפי יצירה — היוצרים צריכים לתמחר מחדש