RAG או Fine-tuning? ההחלטה מתחילה בסוג הבעיה, לא בשם הטכנולוגיה

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

שלוש הבעיות עלולות להיראות באותה צורה למשתמש: תשובה לא טובה. מבחינה טכנית, הן אינן דורשות בהכרח אותו פתרון.

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

RAG: להביא את המידע הדרוש בזמן הנכון

Retrieval-Augmented Generation היא דרך לחבר יצירת תשובה לשליפת מידע. המערכת מקבלת שאלה, מחפשת מקורות רלוונטיים ומעבירה אותם למודל כחלק מההקשר.

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

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

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

Fine-tuning: ללמוד דפוס עבודה מתוך דוגמאות

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

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

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

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

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

אבחון לפני בחירה

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

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

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

זו אינה נוסחה שמכריעה כל פרויקט. זו דרך למנוע טיפול יקר בשכבה הלא נכונה.

חלון הקשר גדול אינו מבטל את בעיית הבחירה

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

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

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

הבחירה בין הקשר מלא לשליפה צריכה להתבסס על מדידה. לפעמים קובץ אחד מלא הוא הטוב ביותר; לפעמים דרושה שליפה ממוקדת; ולעיתים שילוב של תקציר מבני וקטעים מדויקים נותן תוצאה טובה יותר.

הרשאות צריכות להגיע לפני יצירת התשובה

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

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

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

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

מקורות בתשובה: קישור נכון אינו מספיק

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

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

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

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

איך בונים בדיקה שלא נותנת לעצמה ציון גבוה מדי

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

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

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

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

שילוב בין RAG לאימון אינו כישלון בבחירה

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

למשל, המידע על מוצר מגיע ממקור חי, ואילו המודל מותאם לחילוץ פרטים לתבנית פנימית. האימון אינו מחליף את המקור; הוא משפר את השימוש בו.

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

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

המחיר האמיתי של כל גישה

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

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

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

השורה התחתונה

RAG ו־Fine-tuning אינם שני מחנות שצריך לבחור ביניהם לפי אופנה. הם משנים חלקים שונים של המערכת.

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

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

שאלות נפוצות

האם RAG מבטל המצאות?

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

האם Fine-tuning מתאים למחירון שמשתנה?

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

האם חייבים מסד נתונים וקטורי?

לא. סוג החיפוש תלוי במידע ובשאלות. אפשר לשלב חיפוש מילולי, וקטורי ושאילתות מובנות.

האם אפשר להשתמש בשתי הגישות?

כן. אפשר לשלוף מידע עדכני ולהעביר אותו למודל מותאם למשימה. יש להוכיח שהשילוב מצדיק את המורכבות והתחזוקה.