מדריך מעשי: כך תבחרו בין RAG ל-Fine-Tuning לפרודקשן
מדריך צעד-אחר-צעד לבוני מוצר: מסגרת החלטה ברורה בין RAG לכיוונון עדין, עלויות בפועל, ארכיטקטורות שילוב ומלכודות שכדאי להכיר לפני פרודקשן.
כל צוות שבונה מוצר על מודלי שפה גדולים מגיע לצומת הזה: המודל לא מכיר את הדאטה שלנו, אז מה עושים? מחברים אחזור מידע מוגבר (RAG) או משקיעים בכיוונון עדין של מודלים? המדריך הזה נותן מסגרת החלטה מעשית, מספרים מהשטח ותרשים דרך ברור, כדי שתגיעו לפרודקשן עם הארכיטקטורה הנכונה ולא עם זו שסתם נשמעה מרשימה בישיבת התכנון.
צעד ראשון: להבין מה כל גישה באמת פותרת
ההבחנה הבסיסית פשוטה יותר ממה שנדמה. RAG מזריק ידע חיצוני למודל בזמן אמת: השאילתה של המשתמש מומרת לווקטור, מסד נתונים וקטורי שולף את הקטעים הרלוונטיים ביותר מהמסמכים שלכם, והם מצורפים לפרומפט כהקשר. המודל עצמו לא משתנה. Fine-Tuning, לעומת זאת, משנה את המשקלים של המודל עצמו באמצעות אימון על דוגמאות, ומטמיע בו התנהגות: סגנון, פורמט פלט, טרמינולוגיה של תחום.
מכאן נגזר הכלל שהתגבש בפריסות פרודקשן לאורך 2025 ו-2026: ידע משתנה שייך לאחזור, התנהגות יציבה שייכת לכיוונון. מחירון שמתעדכן כל שבוע, מסמכי מדיניות, תיעוד מוצר - כל אלה שייכים ל-RAG. טון דיבור של מותג, פלט JSON קשיח, ניסוח משפטי אחיד - אלה מועמדים לכיוונון עדין. לנסות לכפות על כלי אחד את שתי המשימות זו הדרך המהירה ביותר למערכת שברירית.
צעד שני: מסגרת ההחלטה - שאלו את עצמכם חמש שאלות
לפני שנוגעים בקוד, עברו על הרשימה הבאה. היא מבוססת על מסגרות ההחלטה שפורסמו השנה על ידי כמה גופי מחקר וייעוץ, והיא מכריעה את רוב המקרים בלי צורך בניסויים יקרים.
- האם המידע משתנה בתדירות גבוהה או שהיקפו גדול? אם כן - RAG. עדכון אינדקס לוקח דקות, ריצת אימון לוקחת ימים ועולה כסף.
- האם אתם חייבים ציטוטים ומקורות לכל תשובה, למשל לצורכי רגולציה או אמון משתמשים? RAG הוא היחיד שמספק זאת באופן טבעי.
- האם הבעיה היא סגנון, פורמט או עקביות שהנדסת פרומפטים לא אוכפת באמינות? זה המקרה הקלאסי לכיוונון עדין.
- האם תקציב ה-latency שלכם צפוף? שלב האחזור מוסיף זמן לכל בקשה. אם כל מילישנייה קריטית, מודל מכוונן ללא אחזור עשוי לנצח.
- האם יש לכם בכלל דאטה מתויג לאימון? בלי מאות עד אלפי דוגמאות איכותיות, Fine-Tuning פשוט לא על השולחן.
לפני הכול: תקנו את הפרומפטים. הערכה שחוזרת אצל מומחים בתחום היא שכ-80% מהצוותים שמנסים Fine-Tuning יכלו לפתור את הבעיה בהנדסת פרומפטים טובה יותר ובצנרת RAG מסודרת. הסדר הנכון: פרומפטים, אחר כך RAG, אחר כך evals, ורק בסוף כיוונון.
צעד שלישי: לתמחר את ההחלטה במספרים אמיתיים
הפער הכלכלי בין הגישות משמעותי, אבל הוא לא חד-כיווני. צנרת RAG בסיסית נבנית תוך ימים, ועלות ההסקה שלה עומדת בדרך כלל על פחות מ-5 דולר לאלף שאילתות. כיוונון בשיטת LoRA, שהפכה לברירת המחדל המוחלטת בתחום (יחד עם QLoRA), עולה בין 100 ל-1,000 דולר לריצת אימון חד-פעמית, וההסקה אחר כך זולה מאוד באחסון עצמי. Fine-Tuning מלא של מודל משמעותי? בין 5,000 ל-50,000 דולר ומעלה לריצה, וזה כמעט אף פעם לא מוצדק לצוות מוצר רגיל.
החישוב מתהפך בנפחים גבוהים. ארכיטקטורת ניתוב שבה מסווג קל שולח שאילתות שגרתיות למודל Llama 3.3 8B מכוונן ורק מקרי קצה מגיעים ל-GPT-5 או Claude Sonnet 4.6 חוסכת בפריסות טיפוסיות בין 70 ל-90 אחוז לעומת שימוש בלעדי ב-API של מודל חזית. לסטארטאפ ישראלי עם מיליוני קריאות בחודש, זה ההבדל בין חשבון API שמכרסם את ה-runway לבין מבנה עלויות בר-קיימא.
צעד רביעי: לבחור דפוס ארכיטקטורה, ולרוב זה שילוב
הנתונים מהשטח חד-משמעיים: בפריסות פרודקשן ב-2025 ו-2026, כ-60% מהפרויקטים משתמשים בשתי הגישות יחד. לפי דוח של Menlo Ventures, 51% מהפריסות הארגוניות של AI משתמשות ב-RAG בפרודקשן, לעומת 9% בלבד שמסתמכות בעיקר על Fine-Tuning. גם המחקר האקדמי תומך: עבודה שפורסמה ב-arXiv הראתה ש-RAG עולה בעקביות על כיוונון עדין במשימות של שליפה עובדתית.
הצוותים שמצליחים בפרודקשן לא שואלים 'RAG או Fine-Tuning' אלא 'מה בידע שלנו משתנה ומה בהתנהגות שלנו קבוע'. ברגע שמנסחים את השאלה כך, הארכיטקטורה כמעט כותבת את עצמה.
דפוס השילוב הנפוץ: מודל קטן שעבר כיוונון LoRA כדי לדבר בקול המותג ולהחזיר פלט מובנה, שמקבל הקשר עובדתי טרי מצנרת RAG. כך כל רכיב עושה את מה שהוא טוב בו. וטרנד שכדאי להכיר לפני שרצים לבנות אינדקס: אם בסיס הידע שלכם קטן מספיק, ייתכן שאפשר לדלג על RAG לגמרי ולעבוד עם הקשר מלא בתוספת prompt caching. ה-context window של המודלים הנוכחיים הופך את זה לאופציה לגיטימית לתיעוד של עשרות עמודים.
def route_request(query: str, user) -> str:
# 1. אחזור עם אכיפת הרשאות ברמת המסמך
docs = vector_db.search(
embed(query), top_k=5,
filter={"acl": user.permissions}
)
# 2. ניתוב: שגרתי למודל מכוונן, מורכב למודל חזית
model = "llama-3.3-8b-lora" if classifier.is_routine(query) \
else "frontier-api"
return llm(model, context=docs, query=query)מה זה אומר לצוותים בישראל, ואיפה נופלים
לחברות ישראליות שמוכרות לארגונים בחו"ל, בעיקר בפינטק, ביטחון ובריאות, יש שיקול שמכריע לרוב לטובת RAG: ממשל נתונים. כשהדאטה נשאר במסד הנתונים הווקטורי ולא נטמע במשקלי המודל, קל בהרבה לעמוד בדרישות מחיקה, הפרדת לקוחות וביקורת. וכאן גם המלכודת הנפוצה ביותר: אחזור הפסקה הנכונה אינו מספיק, המשתמש חייב להיות מורשה לראות אותה. אינדקס וקטורי שמתעלם מבקרות גישה ברמת המסמך הוא פרצת אבטחה שמחכה לקרות, במיוחד במערכות ארגוניות רב-לקוחיות.
יתרון תפעולי נוסף של RAG שקל לפספס: יכולת דיבוג. כשמערכת RAG טועה, אפשר לפתוח את הלוג ולראות בדיוק אילו מסמכים אוחזרו ולמה. כשמודל מכוונן מאבד דיוק, האבחון קשה ויקר בהרבה. לצוות קטן שצריך לנוע מהר, זה שיקול שלא מופיע בגיליון האקסל אבל מורגש בכל שבוע של תחזוקה. ואם בכל זאת מגיעים לכיוונון, כדאי לדעת ש-OpenAI הרחיבה לאחרונה את בקרות הכיוונון, מדדי הוולידציה וכלי ה-workflow, כולל תמיכה בכיוונון מולטימודאלי, כך שהחסמים הטכניים נמוכים מאי פעם. החסם האמיתי נשאר איכות הדאטה שלכם.
נקודת פתיחה מומלצת לצוות ישראלי ממוצע: התחילו עם RAG על מודל חזית דרך API, מדדו איכות עם סט evals קבוע, ורק כשהנפח מצדיק זאת כלכלית הוסיפו מודל מכוונן LoRA לשאילתות השגרתיות. כך אתם דוחים את ההשקעה הגדולה עד שיש נתונים שמצדיקים אותה.
שאלות נפוצות
מה ההבדל בין RAG ל-Fine-Tuning?
RAG שולף מידע רלוונטי ממסד נתונים וקטורי ומזריק אותו לפרומפט בזמן אמת, בלי לשנות את המודל. Fine-Tuning מאמן מחדש את משקלי המודל על דוגמאות כדי להטמיע התנהגות, סגנון או פורמט. הכלל המעשי: ידע משתנה שייך ל-RAG, התנהגות קבועה שייכת לכיוונון.
כמה עולה Fine-Tuning של מודל שפה?
כיוונון בשיטת LoRA עולה בדרך כלל בין 100 ל-1,000 דולר לריצת אימון חד-פעמית, בעוד Fine-Tuning מלא של מודל משמעותי מגיע ל-5,000 עד 50,000 דולר ומעלה. לשם השוואה, צנרת RAG בסיסית נבנית תוך ימים ועולה פחות מ-5 דולר לאלף שאילתות בהסקה.
האם אפשר לשלב RAG ו-Fine-Tuning יחד?
כן, וזה הדפוס הנפוץ ביותר בפרודקשן: כ-60% מהפריסות משלבות את שתי הגישות. שילוב טיפוסי הוא מודל קטן שכוונן ב-LoRA לסגנון ולפורמט, שמקבל הקשר עובדתי עדכני מצנרת RAG, לעיתים עם שכבת ניתוב שחוסכת 70-90% מעלויות ה-API.
דרגו את הכתבה
הדירוג עוזר לנו לדעת מה שווה לכם.
תגובות