RAG או Fine-tuning: מה מתאים לסוכן AI עסקי

# RAG או Fine-tuning: מה מתאים לסוכן AI עסקי התשובה הקצרה: אם הבעיה היא מידע עסקי שמשתנה, מתחילים ב־RAG. אם הבעיה היא התנהגות עקבית במשימה צרה, בוחנים Fine-tuning. ברוב העסקים אין סיבה לבחור צד אחד לכל המערכת. לפעמים צריך חיפוש טוב, לפעמים צריך מודל שהתאמן על דוגמאות, ולעיתים החיבור ביניהם הוא הפתרון הנכון. הבלבול מתחיל כשהמילים "ידע" ו"למידה" נשמעות דומות. העלאת מחירון למאגר אינה מלמדת את המודל מחיר חדש. היא מאפשרת לסוכן למצוא את המחיר בזמן העבודה. Fine-tuning, לעומת זאת, משנה את דפוסי התגובה של המודל באמצעות דוגמאות אימון. הוא לא הופך מסמך משתנה למקור אמת שקל לעדכן. זו התזה של המאמר: בוחרים RAG או Fine-tuning לפי סוג השינוי שרוצים לנהל. מידע משתנה צריך להישאר מחוץ למודל ונגיש בזמן הריצה. התנהגות יציבה שחוזרת על עצמה עשויה להצדיק אימון, אם יש מספיק דוגמאות טובות ודרך למדוד שיפור. ## שתי שאלות שנשמעות זהות למנהל, אבל דורשות פתרון אחר נניח שסוכן AI מכין תשובות לצוות מכירות. המנהל מבקש ממנו "להכיר את העסק". מאחורי המשפט הזה יכולות להסתתר שתי בקשות שונות לגמרי. הבקשה הראשונה היא עובדתית: לדעת אילו חבילות פעילות, מה כולל כל מסלול, אילו אזורי שירות זמינים ומה כתוב במדיניות הביטולים. המידע הזה משתנה. יש לו בעלים, תאריך תחולה ולעיתים כמה גרסאות תקפות במקביל. הבקשה השנייה היא התנהגותית: לנסח תשובה קצרה, לשאול שאלה חסרה לפני שמציעים מסלול, להפריד בין עובדה להערכה ולשמור על מבנה קבוע בסיכום. אלה דפוסים שאפשר להדגים שוב ושוב. RAG, קיצור של Retrieval-Augmented Generation, מטפל בעיקר בבקשה הראשונה. לפני שהמודל עונה, המערכת מאתרת חומר רלוונטי ומצרפת אותו להקשר. Fine-tuning מטפל בעיקר בשנייה. המודל עובר אימון נוסף על דוגמאות שמלמדות אותו כיצד לבצע משימה מסוימת. אם מערבבים בין שתי הבקשות, מתחילים לאמן מודל בכל פעם שמחיר משתנה, או בונים מאגר מסמכים ענק כדי לפתור בעיית ניסוח. שתי האפשרויות יקרות לתחזוקה ומפספסות את הבעיה. ## מחירון חדש שייך למקור הידע, לא לזיכרון של המודל עסק שמעדכן תנאים מסחריים צריך לדעת מתי המידע השתנה, מי אישר אותו ועל אילו מקרים הוא חל. RAG מאפשר לשמור את החומר במקור שניתן לעריכה, לאינדוקס ולניהול גרסאות. בזמן בקשה, הסוכן מחפש את הקטעים המתאימים ומבסס עליהם את התוצאה. היתרון העסקי אינו רק עדכניות. אפשר להציג לאדם את המקור ששימש לתשובה. אפשר להסיר מסמך, להגביל גישה למחלקה מסוימת ולבדוק מדוע נשלף סעיף אחד ולא אחר. המידע נשאר נכס נפרד מהמודל. אבל RAG אינו כפתור "חבר תיקייה וגמרנו". איכות התשובה תלויה באיכות האחזור. מסמכים כפולים, כותרות עמומות, קבצים ללא תאריך תחולה וחלוקה גרועה לקטעים יגרמו לסוכן למצוא חומר לא נכון או להחמיץ חומר נכון. Google Cloud מציינת שמנגנון האחזור ואיכות מאגר הידע משפיעים ישירות על הרלוונטיות של התוצאה. לכן פרויקט RAG טוב מתחיל בסידור החלטות על ידע: * איזה מקור גובר כששני מסמכים סותרים זה את זה * אילו שדות קובעים שהקטע מתאים ללקוח או למקרה * מה הסוכן עושה כשלא נמצאה ראיה מספקת * כיצד מציגים את המקור לאדם שבודק את התשובה אם אין תשובות לשאלות האלה, החיפוש יהיה מהיר יותר, אבל לא בהכרח אמין יותר. ## Fine-tuning מתאים לדפוס שחוזר, לא לעובדה שמתחלפת Fine-tuning משנה את המודל באמצעות אוסף דוגמאות של קלט ותוצאה רצויה. לפי התיעוד של OpenAI, נתוני האימון מוגשים במבנה ייעודי ונוצר מודל מותאם. Microsoft מתארת את הגישה כמתאימה לביצועים במשימה מסוימת ולתוכן יציב יחסית, בתנאי שיש נתונים מתאימים. הדגש נמצא במילה דוגמאות. מסמך נהלים בן ארבעים עמודים אינו בהכרח ערכת אימון. כדי ללמד מודל לסווג בקשות רכש, למשל, צריך מקרים שמייצגים את המציאות: בקשות תקינות, ניסוחים חלקיים, מסמכים לא רלוונטיים, חריגות ודוגמאות שבהן התוצאה הנכונה היא עצירה. Fine-tuning עשוי להתאים כאשר המודל הבסיסי מתקשה שוב ושוב באותה משימה צרה גם אחרי שיפור ההנחיות והדוגמאות בהקשר. הוא יכול לעזור בפורמט קבוע, בסיווג ייחודי לעסק או בסגנון פלט שנדרש בנפח גדול. עדיין צריך ערכת בדיקה נפרדת. אם בוחנים את המודל על הדוגמאות שעליהן התאמן, מקבלים ציון יפה בלי לדעת איך יתנהג על מקרה חדש. הוא בחירה גרועה למחיר, מלאי, רשימת עובדים, זמינות ביומן או מדיניות שמתעדכנת. עובדה שנקברה בתוך משקלי המודל קשה לאיתור ולתיקון נקודתי. גם אחרי אימון אין הבטחה שהמודל ישלוף אותה בצורה מדויקת בכל ניסוח. ## מבחן ארבעת השינויים במקום להתחיל משמות טכנולוגיים, קחו את התוצאה הרצויה ושאלו מה צפוי להשתנות אחרי העלייה לאוויר. * כשמחירים, נהלים ומסמכים משתנים, RAG הוא הבחירה הסבירה. אפשר לעדכן מקור ולשמור גרסאות. * כשצורת הסיווג או מבנה הפלט משתנים, Fine-tuning עשוי להתאים. השיפור המבוקש הוא דפוס התנהגות. * כשהמידע ואופן הביצוע משתנים יחד, ייתכן שנדרש שילוב. האחזור מספק עובדות והאימון מסייע במשימה. * כשמדובר בכללי אישור והרשאות, צריך מנגנון קשיח. גבול עסקי אינו נשאר לזיכרון או לניסוח של המודל. השורה האחרונה חשובה. לא RAG ולא Fine-tuning מחליפים הרשאות, בדיקות תקינות או כללים כספיים. אם אסור לסוכן לאשר הנחה מעל סכום מסוים, הגבול צריך להיאכף במערכת שמבצעת את הפעולה. מסמך שאומר "אל תאשר" ודוגמאות שבהן המודל לא אישר הם שכבות עזר, לא מנעול. המבחן גם מונע החלטה גורפת. סוכן אחד יכול להשתמש ב־RAG כדי לקרוא נהלים, במודל מותאם כדי להפיק סיווג עקבי ובאוטומציה קשיחה כדי לעדכן שדה מותר. הארכיטקטורה נקבעת לפי כל צעד, לא לפי מצגת שבה טכנולוגיה אחת אמורה לפתור הכול. ## שלוש טעויות רכישה שאפשר לעצור לפני הצעת המחיר הטעות הראשונה היא לקנות Fine-tuning כי רוצים שהסוכן "יידע את כל החומרים שלנו". שאלו את הספק כיצד מעדכנים סעיף אחד, כיצד מסירים מידע שגוי וכיצד רואים על מה התבססה תשובה. אם התשובה דורשת אימון מחדש לכל שינוי תפעולי, כנראה שהבעיה שייכת לשכבת הידע. הטעות השנייה היא לקנות RAG בלי לבדוק את האחזור. הדגמה שבה שואלים שאלה זהה לכותרת המסמך אינה מבחן. בקשו לראות שאלה עמומה, שתי גרסאות של אותו נוהל ומקרה שבו אין תשובה. חשוב לראות עצירה נכונה לצד תשובה מרשימה. הטעות השלישית היא לשלב את שתי הגישות לפני שנמדד קו בסיס. שילוב יכול להיות מצוין, אבל הוא מוסיף שני מקומות שבהם תוצאה עלולה להשתבש. קודם בודקים מה המודל הבסיסי עושה עם הנחיה טובה ומידע נכון. אחר כך יודעים אם הבעיה נמצאת בחיפוש, בהתנהגות או בכלל בתהליך העסקי. בכל הצעה כדאי לבקש תשובות לחמש שאלות: 1. איזו תקלה מדויקת אמורה להיעלם בעקבות הבחירה? 2. מהי ערכת הבדיקה, ומי קבע את התוצאה הנכונה? 3. כמה עבודה נדרשת כאשר מסמך או מדיניות משתנים? 4. איזו ראיה נשמרת אחרי תשובה או פעולה? 5. מה נשאר קשיח מחוץ למודל? ספק שמסביר את ההבדל דרך המוצר שלו בלבד כנראה מוכר פטיש. עסק צריך מפת החלטה. ## ההחלטה הנכונה מתחילה בדוגמת כשל אחת אל תפתחו פרויקט עם "אנחנו צריכים RAG" או "בואו נאמן מודל". הביאו מקרה שבו הסוכן הקיים נכשל ותארו מה היה צריך לקרות. אם הוא ענה לפי נוהל ישן, בדקו את מקור הידע, הגרסאות והאחזור. אם הוא מצא את הנוהל הנכון אבל החזיר תוצאה במבנה לא עקבי, בדקו הנחיות, דוגמאות ורק אחר כך Fine-tuning. אם הוא פעל למרות שהיה צריך אישור, הבעיה אינה ידע ואינה אימון. זהו גבול ביצוע שלא נאכף. ההפרדה הזאת חוסכת פרויקט שנבנה סביב מונח אופנתי. היא גם משפרת את השיחה עם אנשי המקצוע: במקום לבקש "מודל שמכיר אותנו", מבקשים מערכת שמוצאת את המקור הנכון, מבצעת משימה מוגדרת ומשאירה תוצאה שאפשר לבדוק. אם אתם מתלבטים בין RAG, Fine-tuning או שילוב, שלחו ל־AI BUDDY דרך [aibuddy.co.il](https://aibuddy.co.il) דוגמת כשל אחת ומסמך אחד שהסוכן היה אמור להשתמש בו. נמפה האם הבעיה נמצאת בידע, בהתנהגות או בגבול הביצוע, לפני שבוחרים טכנולוגיה. ### מקורות * [Microsoft Learn: השוואה בין RAG ל־Fine-tuning](https://learn.microsoft.com/en-au/azure/developer/ai/augment-llm-rag-fine-tuning) * [Google Cloud: מהו RAG](https://cloud.google.com/use-cases/retrieval-augmented-generation) * [OpenAI API: Fine-tuning](https://platform.openai.com/docs/api-reference/fine-tuning)