כיוונון עדין של מודל השפה GigaChat

כיוונון עדין של GigaChat: היכן המודל הבסיסי נשבר על הנתונים

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

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

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

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

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

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

מה נותנת התאמת המודל לתחום התוכן

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

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

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

יכולת השחזור של הניסוחים חשובה יותר מתשובה מוצלחת בודדת.

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

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

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

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

דרכי התאמת המודל: השוואת גישות

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

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

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

כיוונון עדין של GigaChat: שלבי עבודת ההנדסה

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

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

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

חפצי מסירה: משקלים, סכמות, תקנות

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

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

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

מקרה בוחן: ניתוח פניות לתמיכה לאחר התאמה

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

מה היה קודם

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

מה שינו

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

מה נהיה

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

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

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

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

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

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

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

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

ספקות טכניים: נתונים, נפחים, סיכונים, לוחות זמנים

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

מה לעשות אם התיוג חלש?

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

כיצד נבדקת איכות המודל?

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

האם המודל לא יאבד ידע כללי?

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

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

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

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

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

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

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

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