Semantic Diffing לפלטי סוכני קוד — זיהוי שינוי התנהגות בין גרסאות מודל
מאת צוות מדיה דיל · 12.08.2026 · Agentic Development · 5 דק׳
איך בונים שכבת Semantic Diffing שמזהה שינוי אמיתי בהתנהגות סוכן קוד בין גרסאות מודל — לא רק diff טקסטואלי, אלא שינוי בלוגיקה ובתוצאות.
צוות שדרג את המודל שמפעיל את סוכן הקוד שלו לגרסה חדשה, בציפייה לשיפור איכות. שבוע אחר כך גילו שהסוכן התחיל להוסיף type annotations בסגנון שונה לגמרי מהקונבנציה של הפרויקט — לא באג, לא שגיאה, פשוט "טעם" שונה של אותו מודל בגרסה החדשה. שום טסט לא נכשל, כי הקוד היה תקין טכנית. הבעיה התגלתה רק כשמפתח שם לב שה-diff-ים מרגישים "אחרת". Semantic Diffing עוסק בדיוק בפער הזה: לא diff טקסטואלי רגיל בין קוד לקוד, אלא זיהוי שינוי משמעותי בהתנהגות, בסגנון ההחלטות ובאיכות הפלט של סוכן קוד כתוצאה משדרוג מודל — לפני שהשינוי מגיע לפרודקשן ופוגע במשהו אמיתי.
למה diff טקסטואלי רגיל לא תופס את זה
Git diff מראה בדיוק אילו שורות השתנו, אבל הוא עיוור לחלוטין לגבי למה הן השתנו ואם השינוי משקף כוונה טובה יותר או סתם וריאציה אקראית של אותו מודל. שני גרסאות מודל יכולות לפתור את אותה בעיה בשתי דרכים תקינות לחלוטין מבחינה פונקציונלית, אבל שונות מהותית באיכות — אחת שומרת על error handling עקבי עם שאר הקוד, השנייה מתעלמת ממנו כי היא "פתרה את הבעיה המיידית" בלי להתחשב בהקשר הרחב. diff טקסטואלי מראה את שתי הגרסאות כ"שינוי לגיטימי" באותה מידה בדיוק.
הבעיה מחריפה כשמדובר בהחלטות שלא באות לידי ביטוי כלל בטקסט הקוד עצמו — למשל, סוכן שבגרסת מודל אחת נוטה לשאול שאלת הבהרה לפני שינוי מעורפל, ובגרסה החדשה נוטה "לנחש" ולהמשיך. זה שינוי משמעותי מאוד בפרופיל הסיכון של הסוכן, אבל אין לו שום ביטוי ב-diff של הקוד שהוא מייצר בפועל — הוא בא לידי ביטוי רק בהתנהגות השיחה עצמה.
יש גם אפקט מצטבר שקל לפספס בבדיקה חד-פעמית: שינוי קטן בנטייה של המודל, למשל עלייה של כמה אחוזים בהסתברות לבחור פתרון "אגרסיבי" יותר על פני פתרון שמרני, לא נראה משמעותי כשבודקים משימה בודדת. אבל על פני אלפי משימות בחודש, אותו שינוי קטן מתורגם לעשרות מקרים נוספים שבהם הסוכן פעל בצורה שהצוות לא היה מאשר מראש. זו הסיבה שבדיקה סטטיסטית על מדגם גדול חשובה יותר מבדיקת "האם זה נראה בסדר" על כמה דוגמאות בודדות.
מה בודקים בפועל
שכבת Semantic Diffing מעשית לא מסתכלת רק על הקוד הסופי, אלא על כמה ממדים במקביל:
- Behavioral fingerprint — הרצת אותה סוללת משימות סטנדרטית מול שתי גרסאות המודל, והשוואת הפתרונות שהתקבלו לפי מדדי איכות מוגדרים מראש (עמידה בקונבנציית פרויקט, כיסוי edge cases, שימוש בכלים מתאימים).
- Decision trace diffing — השוואת רצף ההחלטות שהסוכן קיבל בדרך לפתרון, לא רק את הפתרון עצמו — האם הוא בדק קובץ מסוים לפני שינוי, האם הוא הריץ טסט לפני שסיים.
- Tool usage patterns — האם תדירות והקשר השימוש בכלים שונים (כתיבת טסט, חיפוש בקוד, בקשת הבהרה) השתנו משמעותית בין גרסאות.
- Failure mode shift — האם סוגי הטעויות שהמודל עושה השתנו — למשל מעבר מ"שוכח edge case" ל"מבצע שינוי רחב מדי מהנדרש".
ההשוואה הזו דורשת סט משימות רגרסיה קבוע וייעודי — לא רק טסטים פונקציונליים רגילים, אלא תרחישים שנועדו במיוחד לחשוף שינוי בסגנון קבלת ההחלטות, ולא רק בתקינות הקוד הסופי.
בניית Baseline להשוואה
אי אפשר למדוד שינוי בלי baseline יציב. לפני כל שדרוג מודל, כדאי להריץ את הגרסה הנוכחית על אוסף משימות ייצוגי (שנלקח מהיסטוריית עבודה אמיתית, לא תרחישים מלאכותיים) ולתעד את התוצאות — לא רק "עבר/נכשל", אלא מטריקות עשירות יותר כמו מספר קבצים שהשתנו, האם הסוכן ביקש הבהרה, ואיזה טון ניסוח נבחר בהודעת ה-commit. רק מול baseline כזה אפשר לזהות סטייה משמעותית בגרסה החדשה, ולא רק להסתמך על תחושת בטן שמשהו "מרגיש שונה".
הגישה הזו קשורה ישירות לנושאים שנדונו במדריך סקירת קוד עם AI, אבל עם הבדל מהותי: שם המטרה היא לזהות בעיה בקוד ספציפי, כאן המטרה היא לזהות מגמת שינוי שיטתית שחוצה הרבה משימות שונות בו-זמנית.
מתי לחסום שדרוג מודל
לא כל שינוי בהתנהגות מצדיק חסימת שדרוג — לרוב מודל חדש יותר טוב יותר, וזה בדיוק הסיבה לשדרג. הכלל המעשי הוא להגדיר מראש אילו סוגי שינוי מהווים דגל אדום: ירידה בשיעור עמידה בקונבנציית הפרויקט, עלייה בשיעור פעולות בסיכון גבוה בלי בקשת אישור, או ירידה בשיעור הזיהוי של edge cases שנבדקו בעבר. שדרוג שעובר את הרף הזה נכנס לתקופת "cohort מוגבל" — רק חלק מהמשימות רצות על הגרסה החדשה, בעוד המערכת אוספת עוד נתונים להשוואה, לפני שהוא הופך לברירת המחדל המלאה.
תקופת ה-cohort המוגבל צריכה להימשך מספיק זמן כדי לכסות את סוגי המשימות המגוונים שהצוות באמת מריץ, לא רק כמה ימים של תעבורה רגילה. אם רוב העבודה בפרויקט מתרכזת בימי חול ורוב המשימות המורכבות מגיעות בסופי ספרינט, cohort שרץ רק שני ימים עלול לפספס לגמרי את סוגי המשימה שבהן ההבדל בין הגרסאות הכי בולט. כלל אצבע סביר הוא לכסות מחזור עבודה מלא — שבוע עד שבועיים — לפני שמסיקים מסקנה סופית.
המידע שנאסף בתהליך הזה מזין ישירות את שכבת הטלמטריה הרחבה יותר של המערכת, נושא שמפורט במדריך Agent Telemetry Standardization — כי בלי פורמט אחיד למדידת ביצועי סוכן, קשה להשוות בעקביות בין גרסאות מודל שונות, ועוד יותר קשה כשעובדים עם כמה סוכנים מקבילים כמו שתואר במדריך Parallel Coding Agents, שבו שינוי התנהגות של מודל בודד עלול להשפיע על כל שרשרת התיאום בין הסוכנים.
תיעוד ותקשורת השינוי לצוות
גם כשה-Semantic Diffing מזהה שינוי לגיטימי ורצוי — לא בעיה — שווה לתעד אותו ולתקשר לצוות לפני שהוא מגיע לכולם בהפתעה. מפתחים שרגילים לסגנון מסוים של הצעות מהסוכן, ופתאום רואים סגנון שונה בלי הסבר, נוטים לפתח חוסר אמון כללי כלפי הכלי, גם אם השינוי בפועל הוא שיפור. הודעת שחרור קצרה — "עדכנו את גרסת המודל, שימו לב שהסוכן עכשיו נוטה יותר לפצל פונקציות ארוכות" — חוסכת הרבה מתסכול מיותר ומאפשרת לצוות לכייל את הציפיות שלו בהתאם, בדיוק כפי שהיו עושים עם כל שינוי משמעותי אחר בכלי עבודה משותף. הרגל טוב הוא לצרף להודעה כזו גם דוגמת diff אמיתית שממחישה את השינוי, כדי שהמידע לא יישאר מופשט אלא יתורגם מיד לתמונה קונקרטית שכל מפתח יכול להזדהות איתה מהעבודה היומיומית שלו.
תגיות: semantic diffing · model versioning · AI agent regression · behavioral testing · LLM evaluation · model upgrade