למה מיגרציה של LLM שוברת את איכות התשובות
מיגרציה של LLM נראית כמו החלפה של כתובת שירות ומפתח גישה — שורה אחת בקובץ ההגדרות. בפועל, החלפת מודל שפה משנה את ההתנהגות של כל השרשרת: כללי טוקניזציה אחרים, אורך הקשר אחר, הוראות מערכת נאכפות אחרת.
הוראות שהותאמו למודל הקודם מתחילות להחזיר טקסט חופשי במקום מבנה קפדני, מוסיפות הסברים מיותרים וחותכות שדות.
ירידה באיכות התשובות לעתים רחוקות נראית בהדגמה. היא מתגלה בקלט ארוך, בתרחישים נדירים ובערכי קצה: במקום שבו המודל הקודם החזיר תשובה מובנית בביטחה, החדש מוסיף משפט פתיחה ושובר את ניתוח התשובה.
מקרה מעצבן במיוחד הוא כשספק מעדכן מודל תחת אותו שם — הרגרסיה מגיעה בלי הודעה, והמשתמשים הם הראשונים לשים לב אליה.
האפקט השני — עלייה בהשהיות תחת עומס. הספק מגביל את קצב הבקשות, בשיא גדל הזמן עד לטוקן הראשון, מופיעים חזרות ותור, וההמתנה עוברת במפל אל הממשק. תלות בספק מודל חיצוני מוסיפה לכך שינוי תנאים, זמינות אזורית והגבלות גישה פתאומיות — השירות נשבר, למרות שבקוד שלנו לא השתנתה אף שורה.
נפרט איך זה נסגר: במה אנחנו מודדים איכות לפני ואחרי החלפת המודל ואיך בונים מעטפת שבה אפשר להחליף ספק בלי לאבד התנהגות.
מה משתנה אחרי המעבר: מהירות, יציבות, שליטה
אחרי המעבר, הדבר הראשון שמשתנה במדדים הוא פיזור זמני התגובה של המודל, ולא הערך הממוצע. אנחנו מסתכלים על שיעור הבקשות שנכנסות לסף היעד ועל גידול התור תחת עומס שיא: מודל אחר מתנהג אחרת על טקסט קלט ארוך, וזה נראה מוקדם יותר מאשר בגרף מסכם. מעבר כזה כבר עברנו בין מודלים חיצוניים, כולל Anthropic Claude, וגם עם משפחות פתוחות על חומרה שלנו.
יציבות השירות נקבעת לא לפי מהירות, אלא לפי סוג הכשלים שהמעבר מסיר. חלק מהתקלות מגיעות מצד הספק: מיצוי מכסה, תקופות של ירידת ביצועים, שינוי התנהגות המודל בלי אזהרה.
אחרי המעבר הבקשות עוברות דרך שכבת הניתוב שלנו — במקרה של שגיאה התעבורה עוברת למודל גיבוי, והמשקלים והספים למעבר מוגדרים בקונפיגורציה, בלי שינויים בקוד המוצר.
בקרת איכות התשובות נשענת על סט בקשות ייחוס עם תוצאה ניתנת לבדיקה. הרצה לפני המעבר מראה את שיעור התשובות המוצלחות ואת הפערים מול המודל הקודם; אחרי — אותה דגימה עוברת לפי לוח זמנים, כדי לתפוס ירידת ביצועים על נתונים חדשים, ולא לפי תלונות משתמשים.
נראות סוגרת את שאלת האמון: יומן בקשות ותשובות, מדדי השהיות ושגיאות בנפרד לכל ספק, התראה כאשר שיעור התשובות המוצלחות יורד. המעבר הופך לפעולה מנוהלת — רואים מה בדיוק השתנה, והמסלול הקודם מוחזר בדגל בקונפיגורציה. במקביל מוסרת התלות בספק אחד: החלפת מודל מפסיקה להיות פרויקט והופכת להגדרה.
אפשרויות מיגרציה של LLM: החלפה מלאה, היברידי, מודלים פתוחים
לפני בחירת המצב, מקבעים מה בדיוק תלוי במודל מסוים: תבניות בקשות, קריאות לכלים, ניתוח תשובה מובנית, טיפול בקטיעות זרם ובהפעלות לפי מכסות.
אם הנקודות האלה מוציאו לשכבת מתאם אחת, החלפת מודל בלי לכתוב מחדש את הלוגיקה מצטמצמת לתיקון הגדרות הפנייה וכללי הניסיונות החוזרים — התרחישים נשארים אותם, ורק המבצע משתנה.
בהמשך הבחירה היא בין ארבעה מצבים, והם לא סותרים זה את זה: החלפה מלאה נלקחת במערכות קצרות, היברידי — כשהעומס לא אחיד, מודלים פתוחים — כשהנתונים לא צריכים לצאת מהמעטפת.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| החלפה מלאה | תרחיש אחד-שניים, כולם מכוסים בבדיקות אוטומטיות | העברה חד-פעמית של הנחיות וכיול מחדש של פורמט התשובה; חזרה לאחור — רק החזרת המודל הקודם במלואו |
| מצב היברידי | העומס לא אחיד: תשובות קצרות וחילוץ שדות מופרדים משיקולים מורכבים | הניתוב מסבך את הדיבוג — צריך לתעד איזה מודל טיפל בבקשה |
| מודלים פתוחים על התשתיות שלנו | נתונים רגישים או נפח בקשות צפוי | האיכות בשפות נדירות ובהקשר ארוך יורדת, נדרש מעטפת עדכונים וניטור משלנו |
| מעבר הדרגתי לפי תרחישים | המערכת עובדת ברציפות, השבתה אינה מותרת | נדרשת שכבת מתאם ומדדי פערים בין המודל הישן לחדש |
מה בודקים לפני המעבר: סט רגרסיה על בקשות אמיתיות, שיעור התרחישים שבהם התשובות נבדלות במשמעות ולא בניסוח, וזמן ההתאוששות בחזרה למודל הקודם.
התאמת תרחישים מאושרת לא בהשוואת תשובות «בעין», אלא בסט בדיקות שניתן לשחזר לכל מסלול — אז מעבירים למודל החדש תרחיש מסוים, ולא את כל המערכת בבת אחת.
איך עובר היישום: מהאודיט ועד מסירה לצוות
היישום עובר מספירת מלאי של תרחישים אל מעטפת שצוות הלקוח ממשיך להפעיל בעצמו. כל שלב נסגר בארטיפקט: תיאור תרחיש, קונפיגורציית ניתוב, סט בקשות ייחוס.
- אודיט תרחישים. אוספים את כל הפניות למודל — צ'אט, חילוץ שדות, סיכום — ומסמנים היכן האיכות קריטית והיכן מודל קל מספיק. בפלט מתקבלת רשימת תרחישים עם תדירות, אורך הקשר ודרישות לפורמט התשובה.
- סכימת מעבר. לכל תרחיש מגדירים מודל ראשי ומודל גיבוי, ומתארים ניתוב לפי סוג המשימה ואורך הקלט. הקונפיגורציה נשמרת בנפרד מהקוד — החלפת מודל לא דורשת בנייה מחדש של השירות.
- שכבת תאימות. מנרמלים בקשות ותשובות לפורמט אחיד: הנחיות מערכת, קריאות לפונקציות, פלט בזרימה. המתאם מנטרל הבדלים בתחביר ובפרמטרי יצירה, כדי שהלוגיקה של האפליקציה לא תהיה תלויה במודל הנבחר.
- כיול על נתונים אמיתיים. מכווננים הנחיות, מגבלות אורך, חזרות במקרה כשל ומגבלות קצב. כאן גם סוגרים מטמון וחישוב צריכת טוקנים לכל תרחיש.
- בדיקה על בקשות ייחוס. כמה מאות בקשות עם תשובות צפויות קבועות מריצים במקביל על המודל הישן והחדש. בודקים התאמה, שיעור כשלים, השהיה ויציבות הפורמט.
- חזרה לאחור. מעבירים תעבורה בהדרגה: קודם חלק נסתר, אחר כך חצי, ואז את כל הנפח. המתג למודל הקודם נשאר זמין — החזרה אורכת דקות, בלי פריסה של גרסה חדשה.
- מסירה לצוות. מוסרים תיעוד של הסכימה, הרשאות ותקנון עדכון בקשות הייחוס. בהמשך הצוות מחליף מודלים וכללי ניתוב בעצמו.
מה מוסרים בסיום: סכימות, קונפיגורציות, תקנונים
המיגרציה מסתיימת לא בהעברת תעבורה, אלא בסט שלפיו הפתרון ממשיך לחיות בלי מחבר השינויים. אנחנו מוסרים אותו בקבצים ובתקנונים, ולא בהסברים בעל פה: מהנדס בצוות הלקוח יכול להרים סטנד, להחליף ספק מודל ולוודא שאיכות התשובות לא ירדה, בלי לשחזר את היסטוריית הפרויקט מהתכתבות.
- קונפיגורציות במאגר — כתובות נקודות קצה, מכסות, חזרות, פסקי זמן ופרמטרי יצירה בקבצים נפרדים; סודות מועברים למשתני סביבה ולא נכנסים לקוד.
- סכימות אינטגרציה — זרימות מהאפליקציה דרך שכבת פרוקסי לספק, נקודות החלפת מודל, נרמול בקשות ותשובות לפורמט אחיד, טיפול בפערים בקריאות לכלים.
- כללי גישה למודל — מפתחות בנפרד לכל שירות, מכסות ומגבלות קצב, תפקידים ותחומי נראות, יומן פניות וסדר רוטציה.
- תקנון בדיקת איכות — סט בקשות ייחוס, מדדי נכונות וזמן תגובה, סף שמתחתיו לא משחררים גרסה, וסדר השוואה בין המודל החדש לנוכחי על אותו סט.
- מתאמים ושכבת פרוקסי — היכן הספק מוחלף בתיקון הגדרות, מה נשאר משותף בין המודלים ואילו הבדלים מנוטרלים ברמת שכבת הגישה.
- הוראות לצוות — איך לפרוס סטנד, לעדכן מודל, לחזור למודל הקודם ומה לבדוק בלוגים במקרה של כשלים.
- מפת תלויות וסיכונים — היכן הפתרון תלוי במודל מסוים, באילו תרחישים ירידת ביצועים קריטית ומה יש לכתוב מחדש במעבר הבא.
הסט מספיק לעצמו: הצוות הבא נכנס לפרויקט לפי המסמכים האלה, ולא לפי הזיכרון של הצוות הקודם.
מקרה בוחן: מעבר למודל אחר בלי לעצור את השירות
שירות תמיכת לקוחות עבד על מודל שפה אחד: תחת עומס שיעור התשובות הנכונות ירד ל-87%, ובבקשות ארוכות ההשהיה הגיעה לארבע שניות. התמיכה קיבלה כמאה פניות בשבוע — כמעט כולן על עובדות מומצאות בתשובות וקטיעות באמצע. סימן קלאסי: האיכות מחזיקה בנפחים קטנים ומתפרקת בשיא.
פיצלנו את המעטפת לשכבת קריאה למודל, מדיניות ניתוב והנחיות מנוהלות גרסאות. זה איפשר לחבר מודל שני — Claude — ולהעביר תעבורה בין מנועים בלי שינויים בלוגיקה העסקית: קוד האפליקציה מכיר רק ממשק, ולא ספק מסוים. תבניות ההנחיות וכללי ניתוח התשובות הועברו לגרסאות נפרדות, כדי שההשוואה תתבצע על אותם נתוני קלט.
איך עבר המעבר
התעבורה הועלתה במנות: 5% → 25% → 50% → 100%, בכל שלב השווינו את שיעור התשובות הנכונות, שיעור הכשלים וזרימת הפניות לתמיכה. המעבר המלא ארך כארבעים דקות, החזרה למנוע הקודם — פקודה אחת ושתי דקות: גרסאות הקונפיגורציה נשמרות, והקודמת נשארת פעילה.
מדדים לפני ואחרי
- שיעור התשובות הנכונות: 87% → 96%;
- השהיה בבקשות ארוכות: 4 שנ' → 1.6 שנ';
- פניות לתמיכה בנוגע לאיכות התשובות: ~100 → 30 בשבוע;
- כשלים בגלל אי-זמינות הספק: מכוסים במסלול שני;
- השבתת השירות בזמן המעבר: אפסית, חזרה לאחור — 2 דקות.
בנפרד סגרנו נראות: לוגים של בקשות ותשובות, השוואת איכות על דגימה מושהית והתראה בירידת מדדים. כעת החלפת מודל היא פעולה מתוכננת, ולא אירוע חירום: לשירות תמיד יש מסלול פעיל ונקודת חזרה מדודה.
מה לעשות אם המודל כבר מוטמע במוצר
מודל מוטמע כמעט אף פעם לא צריך להוציא לגמרי. הצעד הראשון — לרכז את כל הפניות אליו בשכבת תאימות אחת: פונקציית יצירה אחידה מקבלת בקשה בפורמט פנימי, מנרמלת פרמטרים, מנתחת את התשובה ומביאה שגיאות לצורה אחידה. כל עוד הקריאות מפוזרות בקוד, כל החלפה משמעה כתיבה מחדש של המוצר; לאחר ההוצאה — תיקון במקום אחד.
בהמשך — הפרדת זרמים. חלק מהתעבורה (ניתוח פניות, חילוץ שדות, תשובות טיוטה) עובר למודל החדש, והשאר ממשיך לעבוד על הקודם. משווים לא על בקשות מייצגות, אלא על סט שנשמר מראש של זוגות אמיתיים «בקשה — תשובת ייחוס»: כך רואים פער בכל תרחיש, ולא רושם כללי.
במעבר, למשל, למודלים של Anthropic, מוקדם מכול עולים הבדלים בפורמט התשובה ובהתנהגות בהקשר ארוך — אותם סוגרת שכבת התאימות, ולא תיקונים בלוגיקה העסקית. מדד המעבר פשוט: שיעור הבקשות שבהן המודל החדש אינו גרוע יותר בעמידה בסכימה, בשלמות ובהיעדר עובדות מומצאות. כל עוד הוא מתחת לסף, הזרם נשאר על המודל הישן.
מעבר הדרגתי הוא גידול שיעור התעבורה על המודל החדש כשהקודם עדיין פעיל: חזרה לאחור אפשרית בכל רגע, כי שני המסלולים חיים באותה שכבה. כיבוי המודל הישן הופך לצעד האחרון, ולא לפרויקט נפרד עם כתיבה מחדש.
ספקות טכניים נפוצים לפני התחלה
לפני מיגרציה של LLM למודל אחר הצוות שואל את אותן שאלות — על איכות התשובות, דרישות לנתונים, עומס על אנשים והדרך חזרה. להלן תשובות מהניסיון במעבר פרויקטים ממודל ספק למודל פתוח ובחזרה.
איכות התשובות תרד?
לא «תרד», אלא תשתנה — וזה מדיד. אוספים סט ייחוס של בקשות אמיתיות ומריצים אותו דרך המודל הישן והחדש, ומשווים תשובות לפי קריטריונים שהוגדרו מראש. חלק מהתרחישים מרוויחים, חלק דורשים עבודה נוספת על הפרומפטים, ולפעמים גם אימון נוסף על הדוגמאות שלנו.
מה הדרישות לנתונים?
תלוי באופן החיבור. בפנייה למודל חיצוני חותכים מהבקשות נתונים אישיים ומזהים תפעוליים — החוצה יוצא רק טקסט אנונימי. מודל פתוח על השרתים שלנו לא מוציא נתונים מחוץ למעטפת בכלל: לא הלוגיקה של המוצר משתנה, אלא מעטפת ההפעלה.
עד כמה זה יעמיס על הצוות שלנו?
העומס העיקרי אינו בכתיבה מחדש של הקוד, אלא בבדיקת איכות ובכיול פרומפטים. האינטגרציה בדרך כלל מוסתרת מאחורי ממשק פנימי אחיד, לכן החלפת ספק היא תיקון קונפיגורציה והרצה חוזרת של בדיקות, ולא כתיבה מחדש של המוצר מאפס.
אפשר לחזור אחורה?
כן. שני המודלים נשארים זמינים, והמעבר הוא פרמטר בקונפיגורציה. אם מראש קבעו מדדים שבהם חוזרים לאפשרות הקודמת, החזרה אורכת דקות: התעבורה מוחזרת בלי לאבד את היסטוריית השיחות ואת הנתונים שנצברו.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי שהערכת מיגרציה של LLM תישען על עובדות ולא על שיקולים כלליים, אנחנו צריכים גישה להקשר של המערכת שלכם: היכן קוראים למודל, מה נחשב לתשובה טובה ואילו מגבלות אסור להפר.
ככל שהקלטים קונקרטיים יותר, כך התוכנית מדויקת יותר — בדרך כלל אחרי שיחה אחת אנחנו כבר מבינים אם אפשר להסתפק בהחלפת מודל או שנדרשת בנייה מחדש של לוגיקת הקריאות.
מה נדרש מכם כדי להתחיל:
- רשימת תרחישים שבהם המודל פועל כיום, ושיעור הבקשות בכל אחד מהם;
- 50–100 דוגמאות אנונימיות של בקשות ותשובות אמיתיות — זה מספיק כדי להרכיב סט בדיקות;
- קריטריוני איכות שלפיהם אתם מקבלים תשובה כיום: מי מעריך ולפי אילו סימנים;
- מגבלות נתונים: מה לא יכול לצאת מהמעטפת שלכם ואילו דרישות להרשאות ולאחסון;
- נקודות אינטגרציה: תורים, מטמון, לוגים, טיפול בשגיאות ובחזרות;
- חלון המעבר הרצוי והשבתה מותרת.
לסיכום הדיון אנחנו מחזירים מסמך עבודה, ולא מצגת: ניתוח תרחישים עם עדיפויות, תוכנית עבודה לפי שלבים עם נקודות חזרה למודל הקודם, הערכת לוחות זמנים והרכב צוות למשימה — מהנדס נתונים, מפתח אינטגרציות ומומחה להערכת איכות.
בנפרד אנחנו מציגים סכימת השוואה: סט בדיקות, מדדי איכות, השהיה ועומס לבקשה, וגם סיכונים וסדר פעולות אם המודל המיועד יורד בביצועים בתרחיש קריטי. תארו את המשימה — נחזור עם הערכה ותוכנית.