ההגדרות בקצרה – שנוודא שאנחנו על אותו דף
RAG (Retrieval Augmented Generation) – כשמשתמש שואל שאלה, המערכת קודם שולפת מסמכים רלוונטיים ממאגר, מזינה אותם למודל AI ביחד עם השאלה, והמודל עונה על סמך המידע ששלפנו.
Fine-tuning – לוקחים מודל בסיס (למשל GPT-4) ומאמנים אותו על הדאטה הספציפית שלכם. אחרי fine-tuning, המודל ‘זוכר’ את הידע ומגיב בסגנון שלימדתם אותו.
ההבדל המהותי: ב-RAG הידע חיצוני למודל ומעודכן בזמן אמת. ב-Fine-tuning הידע ‘בתוך’ המודל. שני קצוות של ספקטרום.
מתי RAG הוא הבחירה הנכונה
כשהדאטה שלכם משתנה תדיר. חברת ביטוח שיש לה 200 מסמכי מדיניות – כל שבוע יש עדכונים. Fine-tuning תדרוש לאמן מחדש כל שבוע. RAG – פשוט מעדכנים את המסמך במאגר.
כשאתם צריכים לצטט מקורות. מוסד רפואי, משפטי, פיננסי – חייבים להראות למשתמש מהיכן המידע. RAG יודע להחזיר את המסמך המקורי + הציטוט. Fine-tuning לא.
כשיש לכם מגבלות רגולציה או פרטיות. הדאטה שלכם רגישה – GDPR, HIPAA. אתם לא רוצים ש’תלמדו’ את OpenAI. ב-RAG הדאטה נשארת אצלכם, רק נשלחת בזמן אמת.כשהתקציב מוגבל. Fine-tuning עולה יקר. RAG משתמש במודל בסיס ומוסיף רק retrieval infrastructure.
מתי Fine-tuning עדיף
כשאתם צריכים סגנון או פורמט ספציפי. מותג שרוצה שכל תוכן AI יהיה בטון שלו. Fine-tuning על 100 דוגמאות של הטון = תוצאה עקבית. RAG יכול לתת variance.
כשיש לכם דומיין ייחודי. רפואי מאוד ספציפי, משפטי מקומי, טכני עמוק. הידע הזה לא ב-GPT הבסיס. Fine-tuning על terminology ייחודי משפר את התוצאות.
כשאתם רוצים latency נמוך יותר. RAG מוסיף שלב retrieval (100-300ms). Fine-tuning – שאילתה ישירה למודל.
כשאתם עובדים בקנה מידה גדול. במיליון קריאות בחודש, ההבדל בעלות בין fine-tuned model קצר לbetween RAG עם context ארוך – משמעותי.
Hybrid Approach – מה שאנחנו עושים בפועל ב-90% מהמקרים
רוב הפרויקטים שלנו משלבים את שניהם. הרעיון: fine-tune על סגנון + terminology, RAG על ידע ספציפי ומעודכן.
דוגמה: פלטפורמת content לחברת ביטוח. Fine-tuning על הטון של המותג + terminology ביטוחי. RAG על מדיניות ספציפיות שמשתנות.
יתרון: מקבלים את הטוב משתי העולמות. סגנון עקבי + ידע מעודכן.
חסרון: מורכבות. שני מערכות לתחזק, שתי pipelines. אבל בפרויקטים בקנה מידה – זה שווה.
טעויות נפוצות שראיתי בפרויקטים שקיבלנו לתיקון
Fine-tuning עם 50 דוגמאות. Fine-tuning דורש 500+ דוגמאות איכותיות. עם 50 – המודל ‘שוכח’ את המקור בלי ללמוד את החדש.
RAG בלי chunking נכון. חלוקת מסמכים ל-chunks – זה קריטי. chunks גדולים מדי = context overflow. קטנים מדי = חסר קשר. הגישה שלנו: 500-800 tokens per chunk עם overlap של 100.
Embedding models שגויים. משתמשים ב-embeddings ישנים או לא מותאמים לעברית. תוצאה – retrieval לא רלוונטי.
Vector DB לא נכון לנפח. Pinecone טוב לקטנים. עברנו ל-Weaviate או Postgres+pgvector בפרויקטים גדולים.
Roadmap להחלטה – 5 שאלות שתשאלו את עצמכם
1. עד כמה הידע שלכם משתנה? יומי – RAG. שנתי – Fine-tuning.
2. האם אתם צריכים לצטט מקורות? כן – RAG.
3. האם יש לכם 500+ דוגמאות איכותיות של הפורמט הרצוי? לא – RAG.
4. מה הקנה מידה? מיליון קריאות בחודש – שקלו Fine-tuning. פחות – RAG.
5. מה מגבלות התקציב? נמוך – RAG. גבוה – שקלו Hybrid.
מבוסס על פרויקטים אמיתיים
המדריך הזה מבוסס על עבודה עם:
קריאה נוספת
אם המדריך הזה עזר לכם, אולי תרצו לקרוא גם על פתרונות AI לעסקים – המדריך המקיף שלנו לתחום.
רוצים לדבר על הפרויקט שלכם?
שיחת ייעוץ חינם, ללא התחייבות - הרעיון שלכם + הניסיון שלנו
רוצים לדבר על הפרויקט שלכם?
אנחנו מתמחים בפיתוח SaaS, פתרונות AI, עיצוב UX/UI ובניית אתרים. ספרו לנו מה אתם צריכים.
דברו איתנו ←