כיוונון עדין של GPT-4 ו-GPT-4o: התאמה אישית של LLM למשימות עסקיות

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

Fine-tuning GPT-4: מדוע מודל הבסיס אינו פותר את המשימה

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

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

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

אימון נוסף של מודל שפה כאן אינו „שיפור לשם שיפור”, אלא דרך להעביר כללים מההנחיה למשקלים.

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

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

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

מה נותן fine-tuning: דיוק ושליטה

אימון נוסף על סט מתויג משנה את התנהגות המודל היכן שההנחיות בבקשה כבר לא עוזרות. האפקט נראה על חלק הנתונים המוחזק, שהמודל לא ראה באימון: שיעור התשובות הנכונות עולה מ-70–75% ל-90–95%, והפיזור בין הרצות מצטמצם לכמה אחוזים בודדים. Fine-tuning GPT-4 בצד OpenAI נותן דיוק בתחום התוכן שלכם, ולא על סט ממוצע ממקורות פתוחים.

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

תיוג של 300–1000 דיאלוגים אמיתיים סוגר את זה — המודל משחזר את הלקסיקון שלכם ועונה באותה צורה לניסוחים מחדש של אותה שאלה: הפער בין חמישה ניסוחים יורד מ-20–30% ל-5%.

פורמט פלט אחיד הוא אפקט מדיד נפרד. סכימת תשובה קשיחה (שדות, סדרם, ערכים ממאגרי עזר, היעדר הקדמות) מסירה שכבת עיבוד לאחר מעשה: התשובות מנותחות ישירות על ידי קוד, ושיעור הפניות שעובד בודק ידנית יורד מ-30–40% ל-5–10%.

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

מצבי התאמה של המודל: השוואת גישות

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

נשווה לפי שני צירים מעשיים: מתי המצב באמת נדרש ובמה משלמים עבורו.

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

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

שלבי הטמעה: מביקורת נתונים ועד מסירה

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

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

ארטיפקטים של הטמעה: משקלים, סכימות, תקנונים

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

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

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

מקרה בוחן: סיווג אוטומטי של פניות

נקודת התחלה

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

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

מה שינינו ומה השתנה

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

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

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

במה שונה אימון נוסף מהנחיות בפרומפט?

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

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

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

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

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

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

ספקות טכניים לפני תחילת העבודה

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

כמה נתוני אימון דרושים?

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

האם אפשר לאמן מודל בקונטור סגור?

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

המודל לא יאבד כישורים כלליים?

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

באיזו תדירות יש צורך באימון חוזר?

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

נדון במשימה: מה דרוש מצדכם

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

  • הגדרת המשימה — איזה תהליך אנו הופכים לאוטומטי, מי משתמש בו ואיך נראית תשובה מוצלחת.
  • דוגמאות „קלט → תשובה נכונה”: אפילו 50–100 מקרים מתויגים מראים אם נדרש אימון נוסף של GPT-4 על הנתונים שלכם או שדי בהתאמת הנחיות מדויקת.
  • קריטריוני קבלה — שיעור התשובות הנכונות במדגם החזקה, השהיית תשובה מותרת, פורמט פלט.
  • מגבלות נתונים: מה אפשר להוציא מההיקף, מה נשאר בצד שלכם, אילו דרישות אבטחה חלות.
  • נכסים קיימים — פרומפטים, מודלים שאומנו בעבר, לוגים של פניות: לעיתים קרובות חלק מהעבודה כבר נעשה.
  • איש קשר של מהנדס מצדכם לבירורים בענייני תיוג ודוגמאות שנויות במחלוקת.

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

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