איך JetBrains מודדת מודל AI לפני שהיא פורסת אותו: מקרה בוחן

מאת ירון דויטשר עודכן לאחרונה: 19 באוגוסט 2026

מי: JetBrains
איפה: צ'כיה
תחום: כלי פיתוח
עובדים עם: Claude Fable 5

מי זו JetBrains ולמה שווה להקשיב לה

JetBrains היא החברה שמאחורי IntelliJ IDEA, PyCharm ו-WebStorm. לפי הפרסום המשותף שלה עם Anthropic יש לה 12.5 מיליון משתמשים פעילים, ו-88 מתוך 500 החברות הגדולות בעולם ברשימת Fortune Global. במילים אחרות: חברה שכל המוצר שלה הוא כלי עבודה למתכנתים.

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

מה JetBrains בעצם מודדת

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

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

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

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

המספרים, ומה שהם לא אומרים

בערכת הפייתון של JetBrains, פייבל 5 קיבל את שיעור המעבר הטוב ביותר:

	פייבל 5	אופוס 4.8
שיעור מעבר בפייתון	44.3%	28.2%
משימות שהמודל האחר פספס	18	2
צעדים עד לפתרון	כ-22% פחות	הבסיס להשוואה

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

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

למה 44.3% הוא דווקא סימן טוב

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

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

עלות לטוקן מול עלות למשימה

הטור הנפרד לעלות למשימה אינו קוריוז חשבונאי, והנקודה הזאת שווה את כל השאר:

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

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

הצד של האבטחה

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

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

מה לוקח מכאן צוות ישראלי

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

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

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

שורה תחתונה

המספרים של JetBrains תקפים למאגרים של JetBrains. אל תעתיקו אותם, ואל תחליטו לפיהם מה להריץ מחר בבוקר.

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

רוצים את המסגרת המלאה לבחירת מודל ורמת מאמץ בעבודה יומיומית? מודל ומאמץ בקלוד קוד ממשיך בדיוק מכאן.

מה השתנה בפועל

שיעור מעבר של 44.3% בבדיקות הפייתון הפנימיות, מול 28.2% לאופוס 4.8
פתרון 18 משימות פייתון שאופוס 4.8 פספס, מול 2 שהפסיד
כ-22% פחות צעדים עד לפתרון בהשוואה לאופוס 4.8
עלות למשימה נמוכה יותר בחלק מהמקרים, למרות מחיר גבוה יותר לטוקן

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

מקורות

https://claude.com/blog/how-jetbrains-evaluates-and-deploys-claude-fable-5

שאלות נפוצות

איך JetBrains בודקת מודלים של AI?

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

מה שיעור המעבר של פייבל 5 בבדיקות של JetBrains?

‎44.3%‎ בערכת הפייתון שלהם, מול 28.2% לאופוס 4.8 — קפיצה של 16 נקודות. בהשוואה ישירה בין השניים פייבל 5 פתר 18 משימות שאופוס 4.8 פספס והפסיד 2 בלבד, והגיע לפתרון בכ-22% פחות צעדים. חשוב לקרוא את המספר נכון: ההשוואה היא מול אופוס 4.8, שהוא הדור הקודם, ולא מול אופוס 5.

למה 44.3% נשמע נמוך למודל דגל?

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

מה ההבדל בין עלות לטוקן לעלות למשימה?

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

מה אפשר ללמוד מזה לצוות פיתוח קטן?

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