Fine-tuning של מודלים: מדריך מעשי למי שבונה ב-production | BestAI
כללי
Fine-tuning של מודלים: מדריך מעשי למי שבונה ב-production
מדריך הנדסי ל-fine-tuning של מודלים בעברית: מתי באמת צריך, מתי RAG עדיף, ואיך לאמן בלי לבזבז שבועיים על dataset גרוע.
יואב הבונה
צוות BestAI
26 במאי 20265 דקות קריאה
Fine-tuning של מודלים נשמע כמו הפתרון לכל בעיה. הצוות לא מקבל תשובות טובות מ-GPT? Fine-tune. רוצים סגנון מותג? Fine-tune. ב-90% מהמקרים שראיתי, זו טעות. המאמר הזה הוא מדריך מעשי לישראלים שבונים מוצרי AI: מתי באמת צריך fine-tuning (כוונון עדין), איך לעשות את זה בלי לבזבז שבועיים על dataset גרוע, ומה לבדוק לפני שאתם פותחים את ה-API של OpenAI.
הערה אחת לפני שמתחילים. fine-tuning אמיתי דורש משמעת בנתונים, לא חוכמה בקוד. הקוד הוא 20% מהסיפור. כל פרויקט מוצלח שראיתי בארבע השנים האחרונות שרף 80% מהזמן על dataset ו-eval, ורק 20% על הרצה. אם אתם הולכים להפוך את היחס, תעצרו.
למה בכלל fine-tuning, ומתי RAG מספיק
שתי הגישות פותרות בעיות שונות, וזה הבלבול הכי נפוץ שאני רואה בצוותים בארץ. fine-tuning משנה את ההתנהגות של המודל. RAG (אחזור-מוגבר) משנה את הידע שזמין למודל בזמן ריצה.
אם הבעיה היא "המודל לא יודע על המוצר שלנו", צריך RAG. אם הבעיה היא "המודל לא יודע לענות בפורמט הספציפי שלנו אחרי 50 דוגמאות בפרומפט", צריך fine-tuning. שתי הבעיות שונות לחלוטין, והפתרונות לא מתחלפים.
קריטריון
RAG
Fine-tuning
שינוי ידע עובדתי
מצוין
חלש
שינוי סגנון או פורמט
בינוני
מצוין
עלות התחלתית
נמוכה (כתיבת קוד)
גבוהה (dataset איכותי)
עלות תחזוקה
נמוכה (עדכון מסמכים)
גבוהה (אימון חוזר)
זמן ל-MVP
שעות
שבועות
כשבניתי מערכת תמיכת לקוחות לסטארטאפ ישראלי ב-FinTech, התחלנו עם fine-tune של GPT-4o mini על 800 שיחות עבר. זרקנו הכל אחרי שבועיים. עברנו ל-RAG מעל מאגר ה-FAQs, והאיכות עלתה ב-30% לפי ה-eval שלנו. הסיבה: הבעיה לא היתה סגנון, היא היתה ידע על המוצר שמשתנה כל שבוע. fine-tune שאומן ב-1 בחודש מיושן ב-15 בחודש.
fine-tuning הוא תרופה לבעיית סגנון. RAG הוא תרופה לבעיית ידע. שני הסמים יקרים כשלוקחים אותם בלי אבחנה.
מקור התמונה: developers.openai.com
מה תצטרכו לפני שמתחילים
לפני שאתם נוגעים בשורת קוד, ודאו שיש לכם 4 דברים. הסדר הזה לא מקרי.
Eval set ברור: 50 עד 200 דוגמאות עם תשובה רצויה. בלי זה אין דרך לדעת אם ה-fine-tune עבד.
Baseline מדוד: הריצו את ה-eval על המודל הבסיסי לפני שנגעתם ב-fine-tuning. תרשמו את הציון בטבלה.
Training dataset: 100 דוגמאות זה מינימום אבסולוטי, 1,000 הוא נקודת התחלה טובה, 10,000 הוא מספיק לרוב המקרים. איכות מנצחת כמות פי 10.
תקציב חישוב: בין $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 בסיסי.
שלוש שיטות עיקריות. ההבדל ביניהן הוא עלות מול גמישות.
Full fine-tuning: מאמנים את כל המשקלים. יקר, איטי, אבל הכי גמיש. רלוונטי רק אם יש לכם 10,000+ דוגמאות איכותיות וצורך אמיתי בשינוי עמוק.
LoRA (Low-Rank Adaptation): מאמנים שכבות קטנות שמוסיפים מעל המודל. זול פי 10, מהיר פי 5, ולרוב המקרים השוני באיכות זניח. המאמר המקורי של Microsoft מסביר את המתמטיקה.
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 גרסאות לפני שמגיעים למשהו טוב. הנה הלולאה שאני משתמש בה:
הריצו fine-tune עם hyperparameters ברירת מחדל.
הריצו את ה-eval set שלכם על המודל החדש.
השוו לציון ה-baseline. אם השיפור מתחת ל-5%, יש בעיה ב-dataset, לא ב-training.
שנו parameter אחד בלבד (epochs, learning rate, או חלק מה-dataset).
הריצו שוב, ותרשמו את הציון בטבלה.
שני הפרמטרים שהכי משפיעים: מספר ה-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
יש לכם שאלה? בונים משהו ולא יודעים להמשיך?
קהילת BestAI בוואטסאפ, מאות יזמים ובעלי עסקים שמשתמשים ב-AI. שואלים, עונים, משתפים.
fine-tuning הוא כלי מצוין שמשתמשים בו לא נכון ב-90% מהמקרים. לפני שאתם משקיעים שבועיים ו-$500 באימון, נסו את שלושת אלה: פרומפט טוב יותר, RAG מעל הידע שלכם, וחלוקה למשימות קטנות יותר. אם אחרי שלושת אלה עדיין יש פער ספציפי בסגנון או בפורמט, אז fine-tuning הוא ההשקעה הנכונה. לצוותים בישראל שבונים מוצרים ב-vertical ספציפי (משפט, רפואה, פיננסים), fine-tune של מודל פתוח עם DICTA כבסיס יכול לתת יתרון תחרותי אמיתי. ב-BestAI אנחנו רואים שצוותים שמתחילים עם eval set ברור מצליחים פי 3 לעומת אלה שמתחילים עם dataset. תתחילו מהמדידה, לא מהאימון.
שאלות נפוצות
›מתי לבחור fine-tuning ומתי RAG?
הכלל המהיר: אם הבעיה היא סגנון, פורמט, או התנהגות עקבית של המודל, fine-tuning הוא הפתרון. אם הבעיה היא ידע עובדתי שמשתנה (תיעוד מוצר, מאגר לקוחות, מאמרים), RAG הוא הפתרון. הרבה צוותים בישראל מתחילים עם fine-tuning כי זה נשמע יותר "מתקדם", אבל אחרי שלושה חודשים מגלים שהם משלמים פי 3 על תוצאה דומה. הבדיקה הפשוטה: אם תוכלו לתאר את התשובה הרצויה במשפט שמתאר את הסגנון, צריך fine-tune. אם תוכלו לתאר אותה בקטע מתוך מסמך קיים, צריך RAG. אפשר גם לשלב את שניהם, אבל זה רק אחרי שכל אחד מהם עובד בנפרד.
›כמה דוגמאות צריך ל-fine-tune שעובד?
המספר תלוי במורכבות המשימה ובאיכות הדאטה. ל-OpenAI ממליצים לפחות 50 דוגמאות לכל משימה, אבל מהניסיון שלי, 50 זה מספיק רק לשינוי קוסמטי בסגנון. ל-fine-tune אמיתי שעובד ב-production, צריך מינימום 500 דוגמאות איכותיות, ויעד סביר הוא 1,000 עד 3,000. מעל 10,000 ההשפעה השולית קטנה, אלא אם המשימה מאוד מורכבת (multi-turn, decisions). תזכרו: 100 דוגמאות איכותיות ומגוונות שווים יותר מ-1,000 דוגמאות חוזרות. השקיעו את הזמן באיכות, לא בכמות. גם בלי 1,000 דוגמאות אפשר להתחיל, אבל הגדירו ציפיות נמוכות לסיבוב הראשון.
›כמה עולה fine-tuning בישראל?
ב-OpenAI, אימון GPT-4o mini עולה $3 למיליון טוקנים של training (כ-12 ש"ח כולל מע"מ). פרויקט טיפוסי עם 1,000 דוגמאות וגודל ממוצע של 500 טוקנים יעלה $1.50 לסיבוב אימון אחד. אבל זה לא העלות האמיתית. החלק היקר הוא ה-inference: מודל fine-tuned עולה פי 2 עד 4 יותר לקריאה, ואם יש לכם 100 אלף קריאות בחודש זה כבר $300-$1,200 הפרש חודשי. למודלים פתוחים על Hugging Face הוצאה חד-פעמית של $50-$500 על GPU בענן, ואחר כך הוצאות hosting שלכם. בשורה התחתונה, תכננו תקציב של $500-$2,000 לסיבוב POC מלא בישראל, כולל זמן מהנדס.
›האם fine-tuning עובד טוב לעברית?
עובד, אבל עם הסתייגויות. fine-tune של GPT-4o על עברית עובד טוב כי המודל הבסיסי כבר יודע עברית ברמה גבוהה. ההשתפרות מגיעה מהיכרות עם הז'רגון של התחום שלכם. למודלים פתוחים, הסיפור שונה. Llama 3.1 בסיסי לא מדבר עברית טוב, ו-fine-tune של 1,000 דוגמאות לא יתקן את זה. מי שעובד עברית במודלים פתוחים צריך להתחיל ממודלים שעברו pre-training על עברית, כמו אלה של DICTA. הבחנה חשובה נוספת: tokenization בעברית לא יעיל, וכל דוגמה בעברית עולה פי 1.5-2 יותר טוקנים מאותו תוכן באנגלית. תכננו את התקציב והאורך של ה-dataset בהתאם.
›מה ההבדל בין fine-tuning ב-OpenAI לבין Vertex AI של Google?
שתי הפלטפורמות עושות LoRA מאחורי הקלעים, אבל החוויה והעלויות שונות. OpenAI נותנים API פשוט שבולע JSONL ומחזיר מודל מאומן תוך 30-90 דקות. אין שליטה ב-hyperparameters מעבר ל-epochs ו-learning rate multiplier, וזה יתרון לרוב הצוותים כי פחות מקומות להיתקע. Vertex AI של Google מציעה כוונון של Gemini 1.5 Flash עם שליטה רחבה יותר ב-pipeline, אבל דורשת היכרות עם GCP, IAM, ו-Cloud Storage. מבחינת מחיר, OpenAI גובים $25 למיליון טוקני אימון על GPT-4o, ו-Vertex AI גובים $8 לשעת אימון על Gemini Flash. לצוותים שכבר מריצים על GCP, Vertex AI חוסך integration. לכל השאר, OpenAI מהיר יותר לסיבוב הראשון. לא ראיתי הבדל איכותי משמעותי באותם use cases.
