Fine-tuning vs. Prompting, מה לבחור? | בית הספר של Claude

למה חברות ישראליות בוזבזות חודשים על fine-tuning שלא היה צריך

צוות AI בחברת legaltech בתל אביב בזבז חודשיים וחצי מיליון שקל על fine-tuning מודל לניתוח חוזים בעברית. התוצאות היו בינוניות. יועץ חיצוני הגיע, עיצב מחדש את הפרומפטים עם few-shot examples ו-chain-of-thought, ותוך שלושה ימים קיבלו דיוק גבוה יותר. המקרה הזה חוזר שוב ושוב בסטארטאפים ישראלים. Fine-tuning הוא לא הפתרון הראשון, ואצל רוב הצוותים הוא לא הפתרון בכלל.

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

שלוש גישות, שלוש שאלות שונות

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

Prompting, שואל: "איך להסביר למודל קיים מה אני רוצה?" אין training, אין עלות חד-פעמית גדולה, שינויים מהירים. מתאים לרוב ה-use cases.
RAG (Retrieval-Augmented Generation), שואל: "איך לחבר את המודל למידע שלי, מעודכן ופרטי?" המידע נשמר מחוץ למודל, ניתן לעדכון, וניתן לצטוט. לא בוחר בין זה ל-prompting, משלים אותו.
Fine-tuning, שואל: "איך לשנות את ההתנהגות הבסיסית של המודל?" אימון על נתונים שלך, שינוי ב-weights. עלות גבוהה, גמישות נמוכה, תוצאות עקביות בסקייל גדול.

הטעות הנפוצה: לחשוב שזאת סולם, prompting לתחילה, RAG לשלב הבא, fine-tuning לסיום. זה לא נכון. זה שלוש כלים לשלוש בעיות שונות.

מתי Prompting מספיק, הרוב המוחלט של המקרים

כפי שנמצא שוב ושוב בפרויקטי production: "90% מבקשות fine-tuning שאני רואה יכולות להיפתר עם few-shot examples טובים יותר." תמיד התחילו כאן.

Prompting מספיק כאשר:

יש פחות מ-500 דוגמאות מתויגות ואיכותיות
ה-task משתנה לעיתים קרובות (שינוי prompt קל ממיצוי מודל)
הבעיה היא חוסר בהירות בהנחיות, לא חוסר ביכולת המודל
אתם בשלב MVP או prototype
אין לכם GPU budget או גישה ל-Bedrock

לפני כל דבר אחר, בצעו Baseline Experiment: נסו zero-shot, אחר כך 5-shot, אחר כך 10-shot. מדדו accuracy על 50-100 דוגמאות בדיקה. אם הגעתם ל-85%+, אין צורך להמשיך הלאה.

מתי RAG, ידע פרטי ומתעדכן

RAG הוא הפתרון כשהבעיה היא ידע, לא התנהגות:

מסמכים פנימיים שמשתנים (נהלי HR, מדיניות, פרייסינג עדכני)
צריך לצטט מקורות ספציפיים, fine-tuning לא יכול לעשות זאת
הידע ארוך מדי לפרומפט (אבל: עם 1M context window של מודלים חדשים, RAG פחות הכרחי מבעבר)
חשוב למנוע hallucination, RAG מחזיר מקורות בדיוק, fine-tuning "יודע" אבל עלול להמציא

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

מתי Fine-tuning, מצבים ספציפיים בלבד

Fine-tuning מוצדק כאשר שלושת התנאים האלה מתקיימים יחד:

Prompting הגיע לתקרה: ניסיתם zero-shot, few-shot, chain-of-thought, ועדיין מתחת ל-85% accuracy
יש לכם dataset איכותי: לפחות 500 דוגמאות מתויגות בידי אנושות (לא AI), עם פיזור מאוזן בין classes
הסקייל מצדיק את העלות: אם ה-use case רץ בנפח גבוה (עשרות אלפי בקשות ביום), fine-tuning מחזיר את ההשקעה

מה Claude תומך בו כיום: נכון ל-2025, Fine-tuning זמין עבור Claude 3 Haiku דרך Amazon Bedrock. בדיקות AWS הראו שדיוק עלה מ-81.5% ל-99.6% בסיווג תוכן, עם ירידה של 85% בטוקנים לשאילתה. זה ROI מרשים, אבל רק לאחר שניסיתם הכל אחר.

מתי כדאי לעשות fine-tuning על Claude?

אני ML engineer בסטארטאפ ביטוח ישראלי. יש לי: 800 דוגמאות מתויגות ידנית, task של סיווג תביעות ל-5 קטגוריות בעברית ביטוחית, ללא GPU budget, latency מקסימלי 500ms. כבר ניסיתי few-shot prompting עם Claude Sonnet, קיבלתי 78% accuracy. מה הצעד הבא? השווה: (1) עוד few-shot examples + chain-of-thought, (2) RAG עם הדוגמאות, (3) fine-tuning של Haiku ב-Bedrock. תן baseline experiment לכל אפשרות ועלות משוערת בדולרים.

Decision Matrix, ההחלטה בטבלה

מצב	המלצה	למה
פחות מ-100 דוגמאות	Prompting בלבד	אין מספיק data
מסמכים פרטיים מתעדכנים	RAG	ידע חי + citation
סגנון ייחודי ועקבי בסקייל	Fine-tuning	Prompting לא משיג עקביות מלאה
Latency קריטי, נפח גבוה	Fine-tuning Haiku	פחות טוקנים, מהיר יותר
Accuracy מתחת ל-85%	קודם: שפרו prompt	ברוב המקרים הבעיה בprompt
ידע + התנהגות יחד	RAG + Fine-tuning	Hybrid הוא פטרן 2026

שלוש טעויות נפוצות שעולות כסף

קפיצה ל-fine-tuning בלי baseline prompting: צוותים מבזבזים שבועות על dataset ו-training runs, ואז מגלים שפרומפט טוב יותר היה פותר את הבעיה. תמיד run הbaseline קודם.
Data leakage: augmentation לפני split, test examples נכנסים ל-training dataset. תמיד split ראשית על raw data, ורק אז augment ה-training set.
Fine-tuning על מודל קטן כשהבסיס גרוע: Fine-tuning Haiku על task שה-base model שלו לא מצליח בו כלל לא יעזור. תמיד benchmark base model ראשית. אם Sonnet לא מגיע ל-70%+ zero-shot, הבעיה לא בגודל הפרומפט.

כשצריך ללמד Claude task שלא ראה קודם

כשיש מסמכים פרטיים שClaude לא ראה

כשסקייל גבוה, יש 500+ דוגמאות, וצריך עקביות סגנון

כש-accuracy נמוך מ-80%

RAG שומר ידע בצורה קבועה, fine-tuning מאפשר עדכון

RAG שולף ידע חי ומצטט מקורות; fine-tuning אופה ידע לweights

RAG יותר יקר מfine-tuning תמיד

RAG תומך בעברית, fine-tuning לא

להכין dataset של 1000 דוגמאות

לשדרג ל-Claude Opus

לבצע baseline experiment: zero-shot, few-shot, chain-of-thought

להתקין RAG מיד

סיכום: הסדר הנכון

Prompting, תמיד ראשון. Zero-shot, few-shot, chain-of-thought.
RAG, כשיש ידע פרטי או מתעדכן שצריך לשלב.
Fine-tuning, רק כשהשניים למעלה הגיעו לתקרה, יש לפחות 500 דוגמאות איכותיות, והנפח מצדיק את ההשקעה.
Hybrid, RAG לעובדות משתנות + fine-tuning לסגנון קבוע. פטרן 2026 לsystems מורכבים.

Claude יכול לעזור בכל שלב: לעצב prompts, לבנות baseline experiment, לכתוב קוד לhunking ולembedding, ולהכין dataset בפורמט JSONL לfine-tuning. אבל הוא גם יאמר לכם בכנות, אם prompting מספיק, אין טעם להשקיע יותר.