arrow_forwardמדריכים / Fine-Tuning LLM
מעודכן ליולי 2026 14 דקות קריאה מתקדם

Fine-Tuning של LLM
— ומתי בכלל צריך

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

LoRA
כיוונון יעיל
QLoRA
על GPU אחד
Unsloth
מהיר פי 2

מה כיוונון באמת עושה

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

והנקודה שקובעת את כל השאר, כי היא הפוכה לציפייה הנפוצה: כיוונון מלמד התנהגות, לא ידע.

המודל לומד דפוסים — מבנה תשובה, טון, סגנון, פורמט, איך לסווג. מה שהוא לא לומד באמינות הוא עובדות: מחירי המוצרים שלכם, מדיניות ההחזרות, מי הלקוחות. נתונים שהוזנו באימון עשויים לצוץ בתשובה, והם יצוצו גם מעוותים, גם חלקית, וגם כשהמציאות כבר השתנתה — ואין דרך לדעת מתי.

psychology
המבחן במשפט

אם הבעיה שלכם מתחילה ב"המודל לא יודע ש..." — כיוונון אינו הפתרון. אם היא מתחילה ב"המודל לא עונה כמו ש..." — אולי כן.

שלושה דברים לנסות קודם

רוב מי שמגיע לכיוונון לא צריך אותו, ומגלה את זה אחרי שבועיים ואלפי דוגמאות. שלוש האפשרויות האלה זולות יותר, מהירות יותר, ומתקנות את עצמן — ובסדר הזה:

  1. הנחיה טובה יותר. נשמע מובן מאליו וזה המקום שבו רוב הבעיות נפתרות. הנחיה שמתארת במפורש את הטון, את המבנה ואת מה שאסור — עם שתיים-שלוש דוגמאות מלאות — משיגה חלק גדול ממה שכיוונון משיג, בעשר דקות במקום בשבועיים.
  2. שליפה. אם הבעיה היא שהמודל לא מכיר את התוכן שלכם — זו שליפה, לא אימון. היא זולה, מתעדכנת ברגע שמסמך משתנה, ואפשר להצביע על המקור.
  3. פלט מובנה. אם הבעיה היא שהתשובה לא בפורמט הנכון — אכיפת סכמה פותרת את זה בוודאות, ולא בהסתברות.

וכלל אצבע שחוסך הרבה: אם לא בניתם מערך הערכה, אתם עוד לא בשלים לכיוונון. בלי דרך למדוד, לא תדעו אם הכיוונון שיפר, לא תדעו מה נשבר בדרך, ולא תוכלו להצדיק את העלות.

מתי כיוונון כן מצדיק את עצמו

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

שימו לב למה שמשותף לשלושת האחרונים: הם מצדיקים את עצמם בנפח. בנפח נמוך, הנחיה ארוכה וזולה תנצח כמעט תמיד.

הדאטהסט הוא כל העבודה

אם החלטתם לכוונן, כדאי לדעת איפה תלך רוב האנרגיה: לא באימון עצמו — באיסוף ובניקוי של הדוגמאות. האימון הוא פקודה; הדאטהסט הוא שבועות.

ארבעה כללים שקובעים את התוצאה:

ומאיפה משיגים אותן: מהייצור. אם יש לכם מערכת שרצה, התשובות שאושרו ידנית הן הדאטהסט הטוב ביותר שתמצאו — הן אמיתיות, הן בסגנון שלכם, והן כבר עברו שיפוט אנושי.

איך נראית דוגמה

הפורמט עצמו פשוט — שיחה, בדיוק כמו שהמודל יראה בייצור. מה שקובע הוא מה יש בתוכה:

{"messages": [
  {"role": "system",
   "content": "אתה מסווג פניות לשירות לקוחות."},
  {"role": "user",
   "content": "הזמנתי לפני שבועיים וזה עוד לא הגיע, אפשר לבטל?"},
  {"role": "assistant",
   "content": "{\"category\": \"cancellation\", \"urgency\": \"high\"}"}
]}

שלוש הערות שמשנות את התוצאה יותר מכל פרמטר אימון:

LoRA: למה זה נגיש היום

כיוונון מלא מעדכן את כל משקלי המודל, דורש חומרה רצינית ומייצר עותק מלא. LoRA עושה משהו חכם יותר: הוא מקפיא את המודל המקורי ומאמן שכבה קטנה נוספת לצדו.

שלוש השלכות מעשיות:

QLoRA לוקח את זה צעד נוסף ומאמן על מודל מכווץ, מה שמוריד עוד את דרישות הזיכרון — במחיר של מעט איכות. לרוב המקרים המעשיים, LoRA הוא ברירת המחדל הנכונה, וכיוונון מלא הוא מה שעושים כשהוכח שהוא נחוץ.

שלושת הפרמטרים שבאמת משנים

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

וההרגל שחוסך ימים: הרצה קטנה קודם. מאתיים דוגמאות, סבב או שניים, ומדידה. זה לוקח דקות ומגלה את רוב הבעיות — פורמט שגוי, דוגמאות שנחתכו, דאטהסט לא עקבי — לפני שמשקיעים בהרצה מלאה.

מה זה באמת עולה

עלות האימון היא הסעיף הקטן, וזה מה שמפתיע. העלות האמיתית מחולקת לארבעה, ורק אחד מהם נמדד בשעות GPU:

ההשלכה התכנונית: כיוונון הוא התחייבות, לא שיפור חד-פעמי. כדאי להיכנס אליו כשהמשימה יציבה ולא צפויה להשתנות — ולא בשלב שבו עוד מגלים מה המערכת אמורה לעשות.

כמה דוגמאות באמת צריך

השאלה הראשונה שנשאלת, והתשובה תלויה במשימה יותר מאשר בגודל המודל:

ומה שחשוב מהמספר: להתחיל קטן. כוונו על מאתיים דוגמאות ומדדו לפני שאוספים אלפיים. אם מאתיים לא הזיזו כלום לכיוון הנכון, אלפיים בדרך כלל לא יצילו — בעיה בעקביות הדוגמאות לא נפתרת בכמות, היא מתעצמת בה.

וסימן מובהק שכדאי לזהות: אם בזמן שאתם מנקים את הדאטהסט אתם מתלבטים הרבה מה התשובה הנכונה — עצרו. זה אומר שההגדרה לא ברורה לכם, והמודל בוודאי לא ילמד אותה. כיוונון לא יכול לפתור חוסר החלטה.

כיוונון על עברית

כאן יש הצדקה שאין לה מקבילה באנגלית, וגם מלכודת.

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

והמלכודת: כמות הדוגמאות הנדרשת גדולה יותר. אותו מספר דוגמאות מלמד פחות, כי המודל מתחיל מנקודה חלשה יותר — ומכיוון שהטקסט נשבר ליותר טוקנים, גם עלות האימון גבוהה מהערכה שנעשתה לפי מספר מילים.

ושלושה פרטים מעשיים שחוסכים סבב: לנקות סימני כיווניות נסתרים שמגיעים מטקסט שהועתק מ-PDF; לשמור על כתיב אחיד בכל הדאטהסט — "תוכנה" ו"תכנה" מלמדים את המודל שאין כלל; ולבדוק את החלוקה לטוקנים לפני האימון, כי דוגמאות ארוכות בעברית עשויות להיחתך בשקט.

מקרה מוחשי: סיווג פניות

כדי שהשיקול יהיה ברור, הנה המקרה הנפוץ ביותר שבו כיוונון באמת מצדיק את עצמו — וגם איך מגיעים אליו נכון.

עסק מקבל אלפי פניות בחודש וצריך לנתב כל אחת לאחת משמונה קטגוריות. שלב ראשון: הנחיה עם המודל החזק. זה עובד מצוין, וזה גם עולה — כי ההנחיה מכילה תיאור של שמונה הקטגוריות ודוגמאות, והיא נשלחת בכל פנייה.

שלב שני: לאסוף. אחרי חודש יש אלפי פניות שסווגו, וחלקן תוקנו ידנית. התיקונים הם הנכס — הם בדיוק המקרים שבהם המודל טעה.

שלב שלישי: לכוונן מודל קטן על אלפיים דוגמאות מסודרות, ולמדוד מול המודל הגדול על אותו מערך.

התוצאה האופיינית: המודל הקטן המכוונן מגיע לדיוק דומה או טוב יותר במשימה הצרה הזו, בשבריר המחיר ובמהירות גבוהה יותר — כי אין צורך לשלוח את ההנחיה הארוכה בכל פעם. זה הדפוס שבו כיוונון עובד: משימה אחת, צרה, בנפח גבוה, עם דוגמאות אמיתיות שהצטברו ממילא.

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

איך יודעים אם זה עבד

וכאן חוזרת הנקודה מההתחלה, כי בלעדיה כל התהליך הוא ניחוש יקר. צריך להשוות שלושה דברים על אותו מערך מקרים: המודל הבסיסי עם ההנחיה המקורית, המודל הבסיסי עם הנחיה משופרת, והמודל המכוונן.

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

ושני דברים שחייבים להיבדק ולא נבדקים:

איפה זה רץ, ומה זה אומר על הנתונים

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

אצל ספק, דרך API. הפשוט ביותר — מעלים קובץ, מקבלים מודל מכוונן, וההרצה אצלו. אין חומרה לנהל. המחיר: הדאטהסט שלכם עובר לספק, והמודל שנוצר יושב אצלו ולא בידיכם.

אצלכם, על מודל פתוח. עם LoRA זה נגיש — כרטיס מסך אחד לרוב מספיק למודל בינוני. הדאטהסט לא עוזב, והתוצר הוא קובץ שלכם.

ההחלטה בין השניים היא כמעט תמיד לא טכנית אלא שאלה של מה מותר לשלוח. והיא חדה כאן יותר מבכל שימוש אחר ב-AI, מסיבה שקל לפספס: דאטהסט לכיוונון הוא ריכוז מרוכז של המידע הרגיש ביותר שלכם — מאות שיחות אמיתיות עם לקוחות, במקום אחד, בפורמט נוח לקריאה. שיחה בודדת שנשלחת למודל היא דבר אחד; קובץ עם אלף שיחות הוא דבר אחר לגמרי.

ולכן, לפני שמעלים: לטשטש פרטים מזהים בדוגמאות. ברוב משימות הסיווג והניסוח השם האמיתי של הלקוח אינו נחוץ ללמידה — והחלפתו בערך בדוי לא פוגעת בדפוס שהמודל לומד.

התהליך, מקצה לקצה

  1. לוודא שאין דרך זולה יותר. הנחיה, שליפה, סכמה. כנה, לא פורמלית.
  2. לבנות מערך הערכה ולמדוד את המצב הנוכחי. בלי זה אין נקודת ייחוס.
  3. לאסוף דוגמאות — עדיף מהייצור — לנקות, ולוודא עקביות. כאן רוב הזמן.
  4. להפריש חלק לבדיקה לפני שמתחילים.
  5. לכוונן עם LoRA, בהרצה אחת קטנה קודם.
  6. למדוד מול שלוש נקודות הייחוס ולבדוק גם מה נשבר.
  7. להחליט בכנות אם השיפור מצדיק את התחזוקה — ולהיות מוכנים לומר שלא.

כיוונון ושליפה ביחד

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

החלוקה פשוטה ושווה לזכור: כיוונון קובע איך המערכת עונה; שליפה קובעת על מה היא עונה.

מערכת שמשלבת אותם נראית כך: שליפה מביאה את הקטעים הרלוונטיים מהמסמכים שלכם — מדיניות, מחירים, נהלים — ומודל מכוונן מנסח מהם תשובה בסגנון ובמבנה שהגדרתם. הידע נשאר במסמכים, שם הוא מתעדכן; ההתנהגות נמצאת במודל, שם היא יציבה.

היתרון מעשי מאוד: כשהמדיניות משתנה, מעדכנים מסמך ולא מאמנים מחדש. וכשרוצים לשנות את הטון, לא נוגעים במסמכים. שתי צירי שינוי נפרדים — וזה בדיוק מה שהופך מערכת לתחזוקתית.

ומה שלא כדאי: לנסות ללמד את המודל את המסמכים באימון וגם לשלוף אותם. זה מייצר סתירות — מה שהמודל "זוכר" מהאימון מול מה שנשלף עכשיו — ובמקרה של פער הוא עלול להעדיף את הגרסה הישנה שלמד. הידע במקום אחד בלבד.

מתי ממש לא

מה קורה אחרי שזה עובד

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

ולכן ההחלטה הכנה לפני שמתחילים אינה "האם זה ישפר" אלא "האם נחזור על זה בעוד חצי שנה". אם התשובה שלילית, כנראה שהנחיה טובה ושליפה ישרתו אתכם טוב יותר לאורך זמן.

טעויות שחוזרות