כוונון עדין של מודל השפה Mistral: LoRA, QLoRA, La Plateforme

מדוע מודל בסיס אינו פותר את המשימה על הנתונים שלכם

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

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

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

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

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

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

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

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

מה נותן fine-tuning mistral: מצבי LoRA ו-QLoRA

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

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

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

היכן האפקט מדיד

בתרחישים טיפוסיים — סיווג פניות, חילוץ ישויות מחוזים, מענה על בסיס מאגר ידע פנימי — אדפטר מאומן מעלה את הדיוק במחלקת היעד מ-60–70% ל-85–92% עם אותו פרומפט. המודל מפסיק "לזלוג" בפורמט התשובה: שיעור ה-JSON התקין ללא ניסיונות חוזרים עולה מ-70% ל-98%.

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

השוואת מצבי אימון מחדש

הבחירה בין LoRA ל-QLoRA היא פשרה בין עודף באיכות לחומרה הזמינה, ולא "טוב/רע". אנחנו מריצים את שני המצבים על מערך הנתונים שלכם ומציגים מטריקות על מדגם נפרד, ולא הבטחות.

אנחנו עובדים עם משקולות פתוחות דרך Hugging Face וסטאק על PyTorch — זה נותן שחזוריות והעברת האדפטר לקונטור שלכם ללא תלות ב-API של אחרים.

איך מתבצעת הטמעת מודל שעבר אימון מחדש: שלבי העבודה

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

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

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

במה LoRA שונה מ-QLoRA ומה לבחור בהתאם לעומס

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

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

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

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

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

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

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

מקרה בוחן: אימון מחדש של Mistral עבור מחלקת תמיכה

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

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

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

מה השתנה במדדים

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

כיצד שומרים על האיכות

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

לאימון השתמשנו ב-Mistral AI — ארכיטקטורה פתוחה מאפשרת להחזיק את המודל בקונטור שלנו, בלי להעביר פניות של לקוחות החוצה.

תאימות, הרשאות גישה וחזרה לאחור: מה יש לדון לפני ההתחלה

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

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

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

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

לאחר המסירה תקבלו לידיכם:

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

תארו את התשתית שלכם ואת המגבלות על הנתונים — נחזור עם הערכה ותוכנית אינטגרציה.

לוחות זמנים להטמעת מודל מכוונן לפי שלבים

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

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

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