כדי לבחור מודל AI לעסק, צריך לדעת איזו תוצאה תאשרו. בסיווג פניות זו יכולה להיות רשומה עם שדות נכונים; בסיכום פגישה, משימות ללא מועדים מומצאים; ובקוד, שינוי שעובר בדיקות. שם המודל וציון במבחן כללי אינם מספיקים כדי לבחור עבור התהליך שלכם.
המדריך משתמש בנתונים שפורסמו במקורות של היצרנים. לכל טבלה מוצגים המקור, התאריך וגרסת המבחן. ציונים ממבחנים שונים אינם מחוברים לדירוג כללי, ומודל שאין עבורו ציון מאומת אינו מקבל ציון משוער.
איך קוראים השוואה בין מודלים
תחילה בודקים מה נמדד: פתרון בעיות קוד, שימוש בכלים, דיוק תמלול או העדפה חזותית. לאחר מכן בודקים את גרסת המבחן, גרסת המודל, רמת החשיבה והכלים שהיו זמינים. שינוי באחד מהם יכול לשנות את התוצאה.
לדוגמה, בפרסום GPT-6 Astra של OpenAI מופיעה השוואה ב־Terminal-Bench 4.0. טבלת הפיתוח שלהלן משתמשת בתוצאות מאותו פרסום. נתון מ־Terminal-Bench 2.1 אינו נוסף אליה כאילו נמדד באותם תנאים.
הטבלה היא השוואה שפרסם יצרן. היא מספקת מידע על מבחן מוגדר, אך אינה מוכיחה איזה מודל יתאים לכל תהליך עסקי.
ארבעה מדדים בפרסום של OpenAI
| מבחן | GPT-6 Astra | GPT-5.6 Sol | Claude Fable 5.1 |
|---|---|---|---|
| Terminal-Bench 4.0פיתוח תוכנה | 57.9% | 37.3% | 55.8% |
| AutomationBenchעבודה מקצועית | 41.4% | 18.1% | 31.4% |
| GPQA Diamondידע מדעי | 96.0% | 94.6% | 93.7% |
| Artificial Analysis Intelligence Index v4.1.1מדד אינטליגנציה משולב · ציון, לא אחוז | 61.2 | 60.9 | 65.7 |
אלה ציוני השיא שפורסמו, ברמות מאמץ שעשויות להיות שונות. Sol מתייחס לגרסת API, Codex ו־ChatGPT Work. ציון גבוה עדיף בכל הטבלאות; — מציין שלא פורסם נתון.
תוכן נכון ופורמט תקין הם דרישות שונות
תשובה יכולה להיות נכונה ועם זאת לא להתאים למבנה שהמערכת צריכה. לדוגמה, טלפון חסר צריך להישאר ריק, בעוד שם שדה לא מוכר או טקסט סביב JSON עלולים להכשיל קליטה אוטומטית. אלה תנאי קבלה של היישום; אין לייחס למודל שיעור הצלחה בהם על סמך מבחן קוד כללי.
בסיכום פגישה יש לבדוק שהצעה לא הפכה להתחייבות. במענה מתוך מסמכים צריך לוודא שהמקור תומך בתשובה. אפשר להיעזר במדריך סיכום הפגישות ובמדריך RAG כדי להגדיר את הדרישות.

מבחני פיתוח: להפריד בין סוגי המשימות
| מבחן | GPT-6 Astra | GPT-5.6 Sol | Claude Fable 5.1 |
|---|---|---|---|
| DeepSWE v1.1הנדסת תוכנה | 74.1% | 72.7% | 67.4% |
| FrontierCode 1.1 Extended (score)גרסת Extended | 64.5%* | 60.6% | 63.6% |
| FrontierCode 1.1 Main (score)גרסת Main | 53.3%* | 47.5% | 50.9% |
| Internal Database Migration Tasksהעברת מסדי נתונים · מבחן פנימי | 63.9% | 42.7% | 57.8% |
ב־FrontierCode, תוצאות Astra המסומנות ב־* התקבלו עם הוראת developer הדומה להנחיות Codex. לפי OpenAI, ההוראה לא הותאמה במיוחד למבחן. תנאי המבחן במקור
מחיר המודל והעלות של התהליך
תעריף למיליון טוקנים הוא נתון לחישוב. הוא אינו עלות קבועה לפנייה: אורך הקלט, החשיבה, הכלים, ניסיונות חוזרים ובקרה אנושית משפיעים על התוצאה. גם ציון גבוה במבחן אינו מדידת זמן תגובה במערכת שלכם.
בדקו את המחיר והתנאים העדכניים במדריכי GPT-6 Astra, Gemini 3.8 Flash ו־Muse Spark 1.3. הגדירו תקרת תקציב ואישור להוצאה לפני הרצות בתשלום.
Meta מפרסמת מתודולוגיית הערכה ל־Muse Spark 1.3. בהיעדר ציון מספרי מאומת ובר־השוואה במקורות שנבדקו כאן, הוא אינו נוסף לטבלה ולא מוצג כאפס.
השוואת עבודת ידע בפרסום של Google
| מבחן | Gemini 3.8 Flash | Gemini 3.7 Flash | GPT-5.6 Sol |
|---|---|---|---|
| GDPVal-AA v2עבודת ידע · ציון Elo | 1545 | 1482 | 1710 |
| Vals Finance Agent v2משימות ניתוח פיננסי | 61.4% | 59.0% | 53.8% |
| Harvey’s Legal Agent Benchmarkתהליכי עבודה משפטיים · all pass rate | 10.0% | 8.8% | 2.5% |
| GDP.PDFהבנת מסמכי PDF · all pass rate | 35.0% | 34.0% | 40.0% |
כל המדדים גבוהים יותר כאשר התוצאה טובה יותר. GDPVal-AA הוא ציון Elo, לא אחוז הצלחה. Google מפנה ל־Artificial Analysis ול־Vals עבור שלוש השורות הראשונות; GDP.PDF נמדד בידי Google לכל הדגמים. אלו תוצאות מבחנים שונים, ואין לחשב מהן ממוצע. תנאי המבחן במקור
טבלאות OpenAI ו־Google נשמרות בנפרד, עם שמות המודלים והתנאים שבכל מקור. אותו דגם עשוי לקבל מספר שונה בפרסום אחר בגלל מועד, תצורה או גרסת מבחן. המטרה אינה לבחור את הציון הנוח לכל עמודה, אלא להציג השוואה שאפשר לעקוב אחר מקורה. ההדגשה הצבעונית מסמנת את המודל המרכזי בטבלת המקור; היא אינה אומרת שהוא מוביל בכל שורה.
בונים מבחן שמתאים לעסק שלכם
בחרו דוגמאות שמייצגות גם את החריגים. אם המערכת מסווגת פניות, כללו פנייה עם שני צרכים, חוסר בפרטי קשר ובקשה להעברה לאדם. אם היא עונה מתוך נהלים, כללו נוהל ישן ושאלה שאין עליה תשובה. אם היא כותבת קוד, הגדירו בדיקות על התנהגות שחשובה למשתמש.
שמרו את הבקשה, גרסת המודל, ספק ההרצה, ההגדרות, התשובה ומדדי השימוש. הריצו שוב לאחר שינוי הוראות או ספק. החלפת מודל יכולה לשנות פורמט והתנהגות גם כשהמשימה העסקית נשארה זהה.
לניסוח דרישות אפשר להיעזר במדריך כתיבת פרומפט. מי שמעדיף לעבוד בתוך משפחת Claude יכול להתחיל במדריך בחירת מודלי קלוד, ולבדוק את ההתאמה באותה שיטה.
למשימה חזותית אפשר לעיין בגלריית SVG. אלה דוגמאות קיימות לצפייה, ללא חיבור לדירוג המודלים במבחני הקוד.
דוגמה לבחירה לפי תהליך העבודה
דוגמה מלאה: לבחור מודל לסיכום פניות
נניח שמנהלת שירות רוצה לקבל בכל בוקר סיכום של הפניות הפתוחות. היא צריכה לדעת מה הלקוח ביקש, מה כבר נעשה ומי אמור להמשיך. הדוח אינו צריך לנבא רכישה או להמציא מועד סיום. לפני בחירת המודל הכינו כמה פניות בדיוניות שמייצגות את העבודה: פנייה קצרה, שיחה ארוכה, שני נושאים באותה שיחה ומקרה שבו הלקוח שינה את הבקשה באמצע.
להגדיר מה הופך סיכום לשימושי
תוצר טוב שומר על הפעולה האחרונה שסוכמה ועל מי שאחראי לה. הוא מבדיל בין בקשת הלקוח להבטחה של העובד ומציין מידע חסר. אם הסיכום נשמע שוטף אך משייך את המשימה לאדם הלא נכון, הוא נכשל בדרישה מרכזית. לעומת זאת, ניסוח מעט פחות אלגנטי שומר על בסיס עבודה אמין שאפשר לערוך במהירות. הגדירו מראש אילו טעויות מחייבות עצירה ואילו הן תיקוני סגנון.
להשוות בלי לחשוף את שם המודל לקורא הראשון
כאשר כמה טיוטות נבדקות בידי צוות, אפשר להציג אותן תחילה בלי שם הדגם ולבקש הערכה מול אותם תנאים. כך שם מפורסם או מחיר גבוה אינם מחליפים בדיקה של התוכן. אין צורך להפוך תרגיל פנימי לבנצ׳מרק ציבורי. המטרה היא להבין איזו תוצאה מתאימה לתהליך שלכם, ולשמור את הדוגמאות שעליהן התבססה ההחלטה. כל הרצה בתשלום דורשת תקציב מוסכם מראש.
לבדוק גם את המידע שלא נכנס לתוצר
עברו על המקור וחפשו תנאי, שינוי החלטה או בקשה להעברה לאדם שנעלמו בסיכום. טעות של השמטה פחות בולטת מטענה מומצאת, אבל יכולה לשנות את העבודה. אם הסיכום קצר מדי, אפשר להגדיר חלק חובה לכל פנייה: בקשה, מצב, פעולה הבאה ומידע חסר. הפורמט צריך לעזור לעובד לזהות מה לעשות, ולא רק ליצור טבלה שנראית מסודרת.
להפוך את הבחירה להחלטה מתועדת
בסוף הבדיקה רשמו איזה דגם נבחר, באיזו תצורה ולאילו סוגי פניות. ציינו גם מקרה שלא עבר ומה עושים איתו. ההחלטה יכולה להיות ״זה הדגם שמתאים להפקת טיוטת הבוקר, עם סקירת עובד לפני העברה לצוות״. ניסוח כזה מאפשר לשנות בהמשך את המודל בלי לאבד את הדרישות המקצועיות שנשארות קבועות. הוא גם מבהיר לעובדים מתי אפשר להשתמש בתוצר ומה עדיין באחריותם.
מתי הבעיה אינה במודל
אם כמה דגמים טועים באותו פרט, בדקו את חומר המקור. ייתכן שהתמלול שגוי, שהמסמך חסר או שהמערכת שלפה נוהל ישן. מעבר למודל יקר יותר יכול להפיק ניסוח בטוח יותר על אותו מידע שגוי. הפרידו בין קריאת המקור, שליפת הנתונים ויצירת התשובה. בדיקה של כל שלב מאפשרת לתקן את המקום שבו המידע אבד במקום להחליף את כל התהליך.
גם הוראות עמומות יכולות להסביר הבדל בין ציפייה לתוצאה. ״סכם בקצרה״ אינו מגדיר מה אסור להשמיט, ו״תן המלצה״ אינו קובע אילו שיקולים חשובים לעסק. כתבו את ההחלטה שהקורא צריך לקבל ואת המידע הדרוש לה. לאחר מכן אפשר לבדוק אם הדגם מצליח לעמוד במשימה. בחירת מודל היא החלטה משמעותית, אך היא יושבת בתוך תהליך שהעסק צריך להגדיר.
לבחון את ההפעלה השוטפת
אחרי שהתקבלה החלטה, שמרו דרך לעקוב אחרי תקלות שהמשתמשים פוגשים. לדוגמה, אפשר לסמן סיכום שדרש תיקון ולרשום מה היה חסר בו. בדקו האם הבעיה חוזרת על סוג מסוים של פניות. המידע הזה מאפשר לשפר הוראות, להוסיף מקור או לשנות מסלול לטיפול אנושי. אין צורך להחליף מודל בעקבות כל טעות בודדת, אבל גם אין להתעלם מכשל שחוזר ומשפיע על העבודה.
לפני עדכון משמעותי, חזרו לדוגמאות שעליהן התקבלה הבחירה. בדקו שהתוכן, הפורמט והפעולות עדיין מתאימים. אם נוסף מודל חלופי למקרי תקלה, הוא צריך לעבור אותה בדיקה ולהופיע בתיעוד. מערכת שמחליפה ספק ברקע יכולה לשנות עלות וזמן וגם את אופן עיבוד המידע. הבחירה צריכה להיות גלויה ומוסברת למי שאחראי על התהליך, גם כשהמשתמש הסופי אינו רואה את שם הדגם.
להחליט מה כדאי לבדוק ראשון
בחרו פעולה שחוזרת לעיתים קרובות ויש לה תוצר שניתן לביקורת. התחלה מתהליך רחב מאוד, כמו ״ניהול כל השירות״, מקשה להבין איזה חלק הצליח ומה נכשל. אפשר להתחיל מטיוטת סיכום, להגדיר תנאי קבלה ולהוסיף בהמשך חיבור למערכת. כל הרחבה מוסיפה אחריות: כתיבת רשומה, שליחת הודעה או שינוי סטטוס דורשים גם בדיקות של הרשאות ושל התוצאה שנשמרה בפועל.
קבעו מראש מי מוסמך לשנות את ההגדרות. עובד שמשפר ניסוח לצורך משימה בודדת אינו בהכרח משנה את ההוראות לכל הצוות. שמרו גרסה מאושרת ודרך להציע שיפור. כך אפשר ללמוד מהשימוש בלי שכל שיחה תשנה את ההתנהגות העסקית. לאחר שנבנה בסיס ברור, השוואת מודלים הופכת להחלטה ממוקדת שאפשר להסביר באמצעות דוגמאות, מקורות ועלות כוללת.
תעדו מי יכול לשנות את הבחירה ומתי בוחנים אותה מחדש. שינוי במקורות המידע או בדרישות התוצר יכול להצדיק בדיקה, גם בלי שהושק מודל חדש.
שאלות נפוצות
האם לבחור מודל אחד לכל הפעולות?
לא בהכרח. אפשר לבחון מודל אחד לסיווג קצר ומודל אחר למשימה מורכבת. פיצול מוסיף מורכבות תפעולית, ולכן הוא מוצדק רק אם התוצאות מראות יתרון ברור לתהליך.
האם ציון בנצ׳מרק מספיק להחלטת ייצור?
לא. ציון מתאר את הביצועים בתנאי המבחן שפורסם. הפעלה עסקית מחייבת גם התאמה למסמכים, להרשאות ולמקרי הכשל של התהליך, ומעקב לאחר ההטמעה.
איך יודעים מה למדוד קודם?
מגדירים מה נחשב תוצר שמיש ומה המחיר של טעות. אפשר לעבוד יחד על בחירת התהליך והמודל, במסגרת ליווי אישי, פיתוח מערכת או בניית סוכן AI מותאם לעסק.


