Fine-tuning של מודלים: מדריך מעשי למי שבונה ב-production

מה תצטרכו לפני שמתחילים

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

1. Eval set ברור: 50 עד 200 דוגמאות עם תשובה רצויה. בלי זה אין דרך לדעת אם ה-fine-tune עבד.
2. Baseline מדוד: הריצו את ה-eval על המודל הבסיסי לפני שנגעתם ב-fine-tuning. תרשמו את הציון בטבלה.
3. Training dataset: 100 דוגמאות זה מינימום אבסולוטי, 1,000 הוא נקודת התחלה טובה, 10,000 הוא מספיק לרוב המקרים. איכות מנצחת כמות פי 10.
4. תקציב חישוב: בין $20 ל-$2,000, תלוי בגודל המודל ובכמות הדאטה. תכפילו את האומדן של עצמכם פי 2.

אם אין לכם eval set, תעצרו. אני מתכוון לזה. fine-tuning בלי eval set הוא הימור עיוור, וראיתי צוותים שורפים חודש על אימון בלי דרך למדוד שיפור. בסוף החודש הם משוכנעים שהמודל "נשמע טוב יותר", וזה כמעט תמיד דמיון.

צעד 1: בניית ה-dataset (70% מהעבודה)

כל הפרויקטים המוצלחים שראיתי הקדישו רוב הזמן לכאן. הפורמט של OpenAI fine-tuning API הוא JSONL פשוט עם שדה messages, ואותו רעיון אצל רוב הספקים. הקושי הוא לא הפורמט. הקושי הוא להחליט מה נכנס.

שלושת הכללים שעבדו לי ב-production:

• גיוון אמיתי: אם 60% מהדוגמאות מתחילות באותה מילה, המודל ילמד את הדפוס הזה ולא את ההיגיון. בדקתי על קוד אמיתי, וההבדל בין dataset מגוון לחד-גוני היה 15 נקודות accuracy על ה-eval.
• אורכים משתנים: ערבו תשובות קצרות, בינוניות וארוכות. אחרת המודל הופך לבלתי שמיש לכל סוג שלא ראה במהלך האימון.
• דוגמאות שליליות בכוונה: אם המודל אמור לסרב למשהו, צריך 10% מהדוגמאות שמלמדות אותו לסרב באופן הנכון. בלי זה הוא לומד רק להגיד "כן".

למי שעובד בעברית, יש בעיה נוספת. רוב המודלים הפתוחים סובלים מ-tokenization לא יעיל בעברית, וכל token יקר יותר באימון. DICTA משחררים מודלים שעברו pre-training על עברית, ועבור משימות בעברית הם נקודת התחלה טובה הרבה יותר מ-Llama בסיסי.

צעד 2: בחירת השיטה והמודל

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

1. Full fine-tuning: מאמנים את כל המשקלים. יקר, איטי, אבל הכי גמיש. רלוונטי רק אם יש לכם 10,000+ דוגמאות איכותיות וצורך אמיתי בשינוי עמוק.
2. LoRA (Low-Rank Adaptation): מאמנים שכבות קטנות שמוסיפים מעל המודל. זול פי 10, מהיר פי 5, ולרוב המקרים השוני באיכות זניח. המאמר המקורי של Microsoft מסביר את המתמטיקה.
3. QLoRA: LoRA עם quantization של המודל הבסיסי ל-4 ביט. אפשר לאמן Llama 70B על GPU של 24GB. המדריך של Hugging Face PEFT מכסה את הסטנדרטים.

בחירת המודל הבסיסי תלויה במגבלות שלכם. אם הדאטה חייב להישאר אצלכם (פיננסים, רפואה, מגזר ציבורי בישראל), מודלים פתוחים כמו Mistral, Llama 3.1 או Gemma הם החלופה. אם אתם בסדר עם שליחת הדאטה לענן, fine-tuning ב-API של OpenAI חוסך לכם שבועות של DevOps.

Anthropic לא מציעה fine-tuning ציבורי ל-Claude נכון לגרסה הנוכחית (מאי 2026), פרט ל-Claude 3 Haiku דרך Amazon Bedrock. Gemini מציעה כוונון של Gemini 1.5 Flash דרך Vertex AI, וזו אופציה סבירה לצוותים שכבר ב-GCP. למאמר השוואתי על הכלים האלה תוכלו לקרוא בהשוואת ChatGPT מול Claude.

צעד 3: הרצה, מדידה, איטרציה

ההרצה עצמה היא החלק הקל. אבל פה מתחיל החלק שאף אחד לא מספר עליו. fine-tune אחד הוא ניסוי, לא תוצר. תצפו לאמן 3 עד 8 גרסאות לפני שמגיעים למשהו טוב. הנה הלולאה שאני משתמש בה:

1. הריצו fine-tune עם hyperparameters ברירת מחדל.
2. הריצו את ה-eval set שלכם על המודל החדש.
3. השוו לציון ה-baseline. אם השיפור מתחת ל-5%, יש בעיה ב-dataset, לא ב-training.
4. שנו parameter אחד בלבד (epochs, learning rate, או חלק מה-dataset).
5. הריצו שוב, ותרשמו את הציון בטבלה.

שני הפרמטרים שהכי משפיעים: מספר ה-epochs (כמה פעמים המודל רואה את ה-dataset) ו-learning rate. ברירת המחדל של OpenAI היא 3 epochs, ולפעמים פחות (1 או 2) נותן תוצאות טובות יותר כי המודל לא overfit-ים על דוגמאות ספציפיות. ב-Hugging Face TRL ההמלצה הסטנדרטית היא להתחיל ב-learning rate של 2e-4 ל-LoRA.

3 דברים שנשברו לי ב-production

בעוד פסקה תראו למה ה-troubleshooting הוא לא optional. שלושת המקרים האלה אכלו לי שבוע עבודה כל אחד.

1. Catastrophic forgetting: ה-fine-tune שלי על תמיכה טכנית שיפר את המענה לבעיות API ב-22%, אבל המודל "שכח" איך לכתוב שאילתות SQL בסיסיות. הפתרון: ערבבו 10% עד 20% מהאימון עם דוגמאות מ-distribution הרחב יותר (instruction-following כללי).

2. Data leakage ב-eval: גיליתי שה-eval set שלי שיתף 12 דוגמאות עם ה-training. הציון נראה מצוין, ובפועל המודל בקושי השתפר. אל תסתמכו על split אוטומטי, בדקו ידנית. כתבו סקריפט שמוודא אפס חפיפה.

3. עלות נסתרת ב-inference: מודל fine-tuned של OpenAI עולה פי 2 עד 4 לטוקן לעומת המודל הבסיסי, לפי דף התמחור הרשמי. אם אתם עושים מיליון קריאות ביום, ההפרש הוא $20,000 לחודש בקלות. בדקתי על traffic אמיתי, ולפעמים RAG עם מודל בסיסי זול יותר ב-70% כולל infrastructure.

מה זה אומר ל-3 סוגי צוותים בישראל

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

• מייסדי סטארטאפ בשלב seed: אל תיגעו ב-fine-tuning עד שיש לכם 10,000 משתמשים פעילים בחודש. בשלב הזה, פרומפט engineering ו-RAG ייתנו 90% מהערך ב-10% מהזמן. ראיתי סטארטאפ ישראלי שגייס $3M ושרף $40K על fine-tuning של מודל לפני שהיה product-market fit. הם פיבטו, וכל ה-fine-tune ירד לפח יחד עם ה-dataset שאיש לא רצה לתחזק.
• צוותי ML בחברות בינוניות (100-500 עובדים): כאן fine-tuning כבר מצדיק את עצמו, אבל רק אם יש data engineer ייעודי לפרויקט. בלי מישהו שאחראי על איכות ה-dataset, התוצאה תהיה גרועה. תקציב טיפוסי שראיתי אצל חברות SaaS ישראליות הוא $5,000 עד $15,000 לסיבוב POC ראשון, כולל זמן צוות של 4-6 שבועות.
• מנהלי מוצר בקורפורייט (בנקים, ביטוח, ממשלה): כאן fine-tuning של מודל פתוח על תשתית on-prem הוא לרוב חובה רגולטורית מצד הפיקוח על הבנקים או רשות הסייבר, לא בחירה. תכננו 4 עד 6 חודשים מסיכום דרישות עד production, וכוונון מתמשך אחר כך. הצוות שיהיה אחראי על המודל צריך 2-3 מהנדסים במשרה מלאה רק לתחזוקה.

BestAI Take

fine-tuning הוא כלי מצוין שמשתמשים בו לא נכון ב-90% מהמקרים. לפני שאתם משקיעים שבועיים ו-$500 באימון, נסו את שלושת אלה: פרומפט טוב יותר, RAG מעל הידע שלכם, וחלוקה למשימות קטנות יותר. אם אחרי שלושת אלה עדיין יש פער ספציפי בסגנון או בפורמט, אז fine-tuning הוא ההשקעה הנכונה. לצוותים בישראל שבונים מוצרים ב-vertical ספציפי (משפט, רפואה, פיננסים), fine-tune של מודל פתוח עם DICTA כבסיס יכול לתת יתרון תחרותי אמיתי. ב-BestAI אנחנו רואים שצוותים שמתחילים עם eval set ברור מצליחים פי 3 לעומת אלה שמתחילים עם dataset. תתחילו מהמדידה, לא מהאימון.