Fine-Tuning של LLM
— ומתי בכלל צריך
לפני שאתה מכוונן מודל — עצור. ב-90% מהמקרים prompting טוב או RAG יפתרו את הבעיה מהר וזול יותר. אבל כשבאמת צריך התנהגות עקבית, פורמט קבוע או סגנון ייחודי — fine-tuning הוא הכלי. במדריך: מתי לכוונן ומתי לא, מה זה LoRA ו-QLoRA, איך מכינים דאטהסט, ובאילו כלים.
מה זה fine-tuning בעצם
מודל שפה מגיע מאומן מראש על כמות עצומה של טקסט — הוא "יודע" המון. Fine-tuning הוא שלב נוסף שבו אתה ממשיך לאמן את המודל על דאטהסט קטן וממוקד משלך, כדי לעצב את ההתנהגות שלו: הטון, הפורמט, הדומיין או המשימה הספציפית.
חשוב להבין את ההבחנה: fine-tuning מלמד את המודל איך להתנהג — לא מה לדעת. אם המטרה שלך היא להזין ידע עדכני או פרטי (מסמכי החברה, קטלוג מוצרים), RAG הוא הכלי הנכון, לא fine-tuning.
מתי לכוונן — ומתי ממש לא
הכלל: תמיד תתחיל מהזול והמהיר. עלה בסולם רק כשהשלב הקודם לא הספיק.
כשיש לך משימה חוזרת וברורה עם מאות-אלפי דוגמאות איכותיות; כשאתה רוצה מודל קטן ומקומי (7B) שיתנהג כמו מודל גדול במשימה צרה; או כשהפרומפט נהיה ארוך ויקר וכל בקשה משלמת עליו. אז כיוונון חוסך טוקנים וכסף לאורך זמן.
הטעות הכי נפוצה. fine-tuning על עובדות גורם להזיות (המודל "משלים" מה שלא זכר) ומתיישן ברגע שהמידע משתנה. לידע — תמיד RAG.
LoRA ו-QLoRA — כיוונון בלי חומרה של ענק
אימון מלא (full fine-tuning) של כל משקלי המודל דורש חומרה יקרה מאוד. LoRA (Low-Rank Adaptation) פותר את זה: במקום לעדכן את כל המשקולות, מקפיאים את המודל המקורי ומאמנים רק שכבות מתאם קטנות (adapters). התוצאה — פחות מ-1% מהפרמטרים באימון, אך איכות קרובה מאוד לאימון מלא.
QLoRA מוסיף קוונטיזציה: טוענים את המודל הבסיסי ב-4-bit ומאמנים מעליו את ה-adapters. כך אפשר לכוונן מודל 7B–13B על GPU יחיד (אפילו כרטיס צרכני עם 16–24GB). זו הסיבה שכיוונון הפך נגיש לכולם.
| שיטה | זיכרון GPU | מתי |
|---|---|---|
| Full fine-tune | גבוה מאוד | מעט מאוד מקרים |
| LoRA | בינוני | ברירת מחדל טובה |
| QLoRA | נמוך (GPU יחיד) | תקציב/חומרה מוגבלת |
הכנת דאטהסט — כאן ההצלחה נקבעת
90% מההצלחה של fine-tuning היא איכות הדאטה, לא ההיפר-פרמטרים. דאטהסט קטן ונקי מנצח דאטהסט גדול ומלוכלך כל יום.
הפורמט הנפוץ הוא שיחות בסגנון chat — כל דוגמה היא זוג של קלט ופלט רצוי:
{"messages": [
{"role": "system", "content": "אתה נציג שירות מנומס של חברת X."},
{"role": "user", "content": "איך מחזירים מוצר?"},
{"role": "assistant", "content": "בשמחה! ההחזרה פשוטה..."}
]}- איכות לפני כמות — 500–1,000 דוגמאות מצוינות עדיפות על 10,000 בינוניות. כל דוגמה צריכה להיות בדיוק ה"התנהגות" שאתה רוצה לראות.
- עקביות — אם רצית פורמט מסוים, שכל הדוגמאות ידגימו אותו בדיוק. סתירות בדאטה = מודל מבולבל.
- גיוון — כסה את מגוון הקלטים האמיתי, כולל מקרי קצה, כדי שהמודל יכליל.
- חלוקה — שמור 10–15% מהדוגמאות ל-validation כדי למדוד ולזהות overfitting.
כלים ותהליך — איך מכוונים בפועל
- Unsloth — הספרייה הפופולרית ב-2026 לכיוונון מהיר וחסכוני בזיכרון. פי ~2 מהיר, נוח למתחילים, עם notebooks מוכנים ב-Colab.
- Axolotl — פריימוורק מבוסס קונפיג (YAML) לכיוונון ברמת הפרודקשן, גמיש ותומך בהמון מודלים.
- Hugging Face TRL / PEFT — הספריות הרשמיות ל-LoRA ולאימון. ראה את מדריך Hugging Face.
- ענן מנוהל — OpenAI ו-Google מציעים fine-tuning מנוהל דרך API: אתה מעלה דאטהסט והם מאמנים. פחות שליטה, אבל אפס DevOps.
התהליך הטיפוסי: הכנת דאטהסט → בחירת מודל בסיס (למשל Llama/Qwen/Mistral) → אימון LoRA/QLoRA → הערכה מול validation → מיזוג ה-adapter או הרצתו מעל המודל → פריסה (למשל דרך Ollama מקומית).
טיפים ומלכודות נפוצות
- התחל קטן — כוונן על מודל 7B לפני שאתה מבזבז כסף על מודל גדול. אם זה לא עובד על קטן, הבעיה בדאטה.
- מדוד, אל תנחש — הגדר מדד הצלחה ברור והשווה מול המודל הלא-מכוונן ומול RAG. לפעמים תגלה שלא היית צריך לכוונן בכלל.
- היזהר מ-overfitting — יותר מדי epochs והמודל "משנן" את הדאטה ומאבד יכולת הכללה. עצור כשה-validation loss מפסיק לרדת.
- Catastrophic forgetting — כיוונון אגרסיבי עלול לגרום למודל "לשכוח" יכולות כלליות. LoRA מקל על זה כי המודל המקורי קפוא.
- שמור על מודל הבסיס — תעד איזה מודל, איזו גרסה ואילו היפר-פרמטרים. שחזור הוא חצי מהעבודה בפרודקשן.
רוב המערכות המנצחות לא מכווננות בכלל, או משלבות: RAG לידע + fine-tuning קל להתנהגות. RAG מביא את העובדות העדכניות, וכיוונון קטן מלטש את הטון והפורמט. תתחיל מ-RAG (מדריך RAG), ושקול כיוונון רק כשההתנהגות עדיין לא במקום.