Fable 5, Opus 4.8 ו-Sonnet 4.6: איך להשוות בצורה הוגנת מודלי LLM על הקוד שלך

כשמודל חדש יוצא, ההודעה לעיתונות עונה על השאלה "עד כמה הוא טוב יותר בבנצ'מרקים" — ואינה עונה על השאלה היחידה שמעניינת אותי: מה הוא ישנה בעבודה שלי. ערכתי ניסוי מבוקר: שלושה מודלים של Claude — Fable 5, Opus 4.8 ו- Sonnet 4.6 — קיבלו משימה זהה מילה במילה לביצוע ביקורת על בסיס הקוד של הבלוג הזה, כל אחד בעותק מבודד של המאגר, עם רובריקה מוסכמת מראש להערכה. במאמר — המתודולוגיה עצמה, שאפשר לחזור עליה בכל פרויקט, התוצאות, ובנפרד — איך הניסוי נשבר פעמיים ומה זה לימד.

למה בנצ'מרקים לא עונים על השאלה שלי

לבנצ'מרקים ציבוריים יש שתי בעיות, ושתיהן מהותיות. הראשונה — זיהום נתונים: דוגמאות מבחן מחלחלות למערכי האימון, והמודל חלקית "נזכר" בתשובות במקום לפתור את המשימה. זו אינה חשד שולי, אלא נושא של כיוון מחקר שלם: סקירה של Xu ועמיתיו (2024) מסדירה את המחקרים על זיהום בנצ'מרקים, ו- סקירת EMNLP 2025 מתעדת את תגובת התעשייה — מעבר ממבחנים סטטיים למבחנים שנוצרים דינמית.

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

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

עיצוב הניסוי: פרומפט אחד, שלושה עולמות מבודדים

המשימה לכל שלושת המודלים הייתה זהה מילה במילה — רק שם הענף ותיקיית התוצאות היו שונים. ארבעה שלבים: ביקורת של מערכת המאמרים הדו-לשונית של הבלוג עם הוכחה לכל ממצא בצורת файл:строка עם ציטוט קוד; בחירת פתרונות לשלושת הממצאים העיקריים עם תיאור הפשרות; יישום תיקון אחד עם בדיקה עצמית; הערה על התוצאות ברוסית ובאנגלית. מחזור עבודה הנדסי מלא, ולא "שאלה-תשובה" מבודדת — גישה ש ממליץ עליה גם Anthropic: להעריך סוכנים על משימות ממוצר אמיתי, לפי רובריקה שהוסכמה לפני ההרצה.

שלושה כללים הפכו את ההשוואה להוגנת:

בידוד. כל מודל עבד ב- git worktree נפרד — עותק משלו של ספריית העבודה עם ענף משלו. המודלים פיזית לא יכלו לראות את התוצאות של זה או להפריע לזה.

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

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

הרובריקה: להעריך רק את מה שאפשר לבדוק בידיים

לפני ההרצה קבעתי שישה צירים בחמש נקודות כל אחד: דיוק הביקורת (בדיקה ידנית של מדגם ממצאים לפי файл:строка), עומק (ממצאים מאומתים שאינם ברמזים), איכות הנימוק על פשרות, קוד ואמיתות הבדיקה העצמית, איכות הטקסט ברוסית ובאנגלית, משמעת (אפס שאלות לאדם, אפס הפרות של המגבלות). העיקרון זהה לזה של סקירת קוד טובה: ככל שהציר נשען פחות על טעם ויותר על עובדה ניתנת לבדיקה, כך אפשר לסמוך עליו יותר.

איך הכול נשבר בפעם הראשונה

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

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

– מסקנה ששווה לי הפעלה מחדש

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

תוצאות: היכן המודלים זהים והיכן הם נבדלים

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

מכאן מתחילים ההבדלים:

	Fable 5	Opus 4.8	Sonnet 4.6
ממצאים מאומתים	11	5	9
ייחודיים לא-טריוויאליים	3	1	2
בדיקה עצמית של התיקון	רינדור אינטגרציוני על מסד נתונים זמני, xmllint, ייחוס בדיקת כשל של אחר	לינטר + רינדור; תפס באג של עצמו	רק לינטר ורשימת ראוטים
טוקנים / זמן	164k / 21 דק'	101k / 12 דק'	131k / 12 דק'
ציון לפי הרובריקה (מתוך 30)	30	24	25,5

הבדלים איכותיים מאלפים יותר מהציונים. Opus 4.8 — היחיד שלא הבחין בכותרת שבורה Content-Type ב-sitemap (שני האחרים מצאו אותה) והשאיר אותה בתיקון שלו עצמו; ובתוך הטקסט הרוסי שלו חלף פנימה מילה באנגלית — "и even путь к картинке". Sonnet 4.6 ביצעה תיקון תקין, אך הבדיקה העצמית שלה הייתה הצהרתית: לינטר במקום הרצה. Fable 5 בלטה דווקא בבדיקה העצמית: גילתה ש- php במכונה שלי הוא עטיפה מעל מיכל docker שממופה לספרייה הראשית, בנתה מחדש את כל הבדיקות דרך מיכלים חד-פעמיים והריצה את התיקון שלה באופן אינטגרציוני על מסד נתונים זמני. ההבדל בין "עשיתי" ל"הוכחתי שעשיתי" — זהו הציר המבדיל ביותר עבור משימות סוכניות.

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

שופט מבין המשתתפים

את ההערכה לפי הרובריקה ביצעה Fable 5 — אותו מודל שהשתתף בהשוואה. זהו חור מתודולוגי, ויש לומר עליו ישירות: שופטי LLM נוטים באופן שיטתי להעריך ביתר את הטקסטים של עצמם, ונטייה זו חזקה יותר ככל שהמודל מזהה טוב יותר את הטקסטים שלו — זה הוצג ב מאמרם של Panickssery ושותפיו ב-NeurIPS 2024. ניתן לרכך את ההטיה בשתי דרכים, והשתמשתי בשתיהן: ראשית, להזיז ככל האפשר את הרובריקה מצירי טעם לעבר עובדות ניתנות לבדיקה — דיוק השורות, שלמות התיקון, מילה זרה שחלפה פנימה — אינם תלויים באהדות השופט; שנית, להצהיר במפורש על ניגוד העניינים ולמסור את הצירים השנויים במחלוקת לבדיקה צולבת של מודל אחר או של אדם. את צירי הסובייקטיביות של הסיכום שלי — איכות הטקסט, איכות החשיבה — יש לקרוא עם תיקון זה.

מגבלות היושר

הרצה אחת למודל — זה n=1: הבדלים של נקודה-שתיים אינם אומרים דבר, ורק פערים איכותיים ראויים לאמון — באג שהוחמץ, עומק הבדיקה העצמית. הניסוי מודד שלושה מודלים על משימה אחת בתחום אחד; "Fable 5 טוב באופן כללי יותר" אינו נובע ממנו. וכדאי לזכור את המחיר: מודל הדגל הוציא פי 1.6 יותר טוקנים וכמעט פי שניים יותר זמן מהמשתתף החסכוני ביותר, ו הטוקן שלו לפי המחירון גם יקר יותר כשלעצמו — עבור משימות שגרתיות זהו שיקול כבד לטובת מודלים פשוטים יותר.

מה אני לוקח לעצמי

המתודולוגיה הצטמצמה לרשימת בדיקה קצרה שעובדת לכל פרויקט ולכל מודל:

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

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

מקורות ומצפנים

• Benchmark Data Contamination of Large Language Models: A Survey (Xu et al., 2024) — שיטתיות של בעיית זיהום הבנצ'מרקים; הטיעון המרכזי לטובת בדיקות על הקוד שלך.
• Benchmarking LLMs Under Data Contamination: From Static to Dynamic Evaluation (EMNLP 2025) — כיצד התעשייה עוברת מבדיקות סטטיות לדינמיות; הניסוי שלי הוא מקרה פרטי של בדיקה דינמית.
• Demystifying evals for AI agents (Anthropic Engineering, 2026) — הפרקטיקה של הערכת סוכנים: משימות מתוך מוצר אמיתי, רובריקות ניתנות לבדיקה, הבחנה בין מסלול לתוצאה.
• LLM Evaluators Recognize and Favor Their Own Generations (NeurIPS 2024) — מדוע מודל-שופט מעלה את הציונים לעצמו ומה לעשות עם זה.
• Run parallel sessions with worktrees (Claude Code Docs) — המנגנון התקני לבידוד סשנים סוכניים מקבילים, שבלעדיו ההרצה הראשונה של הניסוי קרסה.