למה אני לא עובר לגרסה החדשה של המודל ביום שהיא יוצאת

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

מה באמת עומד על הכף כשמשדרגים

אני מריץ כמה מוצרים שבהם LLM יושב בליבת המערכת: Tadam מייצר קריאייטיב פרסומי בעברית, Brainers Club מפעיל פיצ'רים מבוססי AI ל-10,000 ומעלה חברים, Duks.ai מטפל בלוגיקה של ניהול נכסים שנוגעת בחוזי שכירות ודיירים אמיתיים. בכל אחד מהמוצרים האלה יש פרומפטים ושרשראות שכוונו בדיוק לפי ההתנהגות של מודל ספציפי. מחליפים את המודל מתחת, ואותו פרומפט יכול להוציא פלט עם מבנה, טון או פורמט JSON שונה בעדינות. העדינות היא הבעיה. מודל שנעשה גרוע בצורה בולטת נתפס תוך חמש דקות. מודל שפשוט שונה, אבל עדיין "די טוב", מחליק לפרודקשן ומופיע שלושה שבועות אחר כך כפניית תמיכה.

הצ'קליסט שאני באמת מריץ לפני שדרוג

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

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

איפה זה תופס סטודנטים ובוני מוצר חדשים

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

מתי כן אני עובר מיד

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

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