הערכת מודלי AI כבר לא יכולה להסתפק בציון בנצ'מרק
ארגונים רבים עדיין בוחנים מודלי בינה מלאכותית כאילו מדובר במנוע תשובות פשוט. מנהל מבקש הדגמה, הצוות מריץ כמה שאלות, מתקבלות תשובות מרשימות, ואז מתחיל דיון על רכש, אבטחת מידע והטמעה. הבעיה היא שמודלי Frontier כבר אינם רק צ'אטבוטים. הם מפעילים כלים, כותבים קוד, משתמשים בזיכרון, מתקנים את עצמם, מתכננים צעדים, ולעיתים מתפקדים כסוכן עבודה מלא בתוך תהליך עסקי.
הערכת מודלי AI תלויה בסביבת ההפעלה, לא רק במודל
מסמך חדש של OpenAI מחדד נקודה שמנהלים חייבים להבין: תוצאת מבחן AI היא לא רק תכונה של המודל, אלא של מערכת ההפעלה שסביבו. המונח המקצועי הוא Harness, כלומר מעטפת שמגדירה אילו כלים זמינים למודל, כמה טוקנים מוקצים לו, האם יש דפדוף, האם מותר לו להריץ קוד, כמה ניסיונות חוזרים הוא מקבל, ומה בדיוק נחשב הצלחה. שני ארגונים יכולים לבדוק אותו מודל ולקבל תוצאות שונות לחלוטין, משום שבפועל הם בדקו שתי מערכות שונות.
בארגון עסקי זו לא הערה אקדמית, אלא הבדל שמכריע החלטות השקעה. מודל שמצליח לפתור משימת סייבר או פיתוח תוכנה רק כאשר הוא מקבל טרמינל, גישה למסמכים פנימיים וחמישה ניסיונות, עדיין עשוי להיות בעל יכולת מעשית גבוהה. משתמש מתקדם, עובד יצירתי או תוקף לא יעבדו בהכרח בתוך חלון צ'אט מוגבל. הם יחברו אוטומציה, יכתבו סקריפטים, ישתמשו בכלי תזמור, וימקסמו ביצועים.
סיכוני AI נמדדים דרך אמינות הציון ולא דרך הציון בלבד
מנהלים נוטים לבקש מספר אחד: אחוז הצלחה, דירוג, או מקום בטבלה. בפועל, ציון בלי מתודולוגיה עלול להטעות. Reward hacking מתאר מצב שבו המערכת משיגה ציון גבוה באמצעות קיצור דרך במקום פתרון אמיתי. זיהום נתונים עלול להתרחש כאשר משימות הבדיקה הופיעו באימון או זמינות ברשת. סביבת בדיקה שבורה, קבצים חסרים או ניקוד לא עקבי יכולים להוריד ביצועים באופן מלאכותי. גם סירוב של המודל לבצע משימה עשוי להסתיר יכולת קיימת, במיוחד בתחומי קוד, סייבר וניתוח מידע רגיש.
לכן דוח הערכה רציני צריך לכלול לא רק תוצאה, אלא פרוטוקול בדיקה. מנהלים צריכים לדרוש פירוט של גרסת המודל, הגדרות המערכת, חלון ההקשר, תקציב הטוקנים, מספר ניסיונות, כלים חיצוניים, גישה למידע ארגוני, מדיניות סירוב, ואופן בדיקת קיצורי דרך. אם הנתונים האלה חסרים, הציון נראה מקצועי אך אינו מספיק לקבלת החלטה.
ניהול סוכנים דורש תשתית בדיקה ארגונית
כאשר מטמיעים AI בתהליכים אמיתיים, השאלה אינה איזה מודל חכם יותר בהדגמה, אלא איזו מערכת מייצרת תוצאה יציבה, בטוחה וכלכלית. תהליך שירות לקוחות, בדיקת חוזים, חקירת תקלות או ניתוח פיננסי אינם משימה אחת, אלא שרשרת החלטות לא דטרמיניסטית. כאן אדם בלולאה נשאר עיקרון קריטי, אך לא כפקק תפעולי. המטרה היא שעובד שפיקח בעבר על תהליך אחד יוכל לפקח על עשרות או מאות הרצות, בעזרת מדדי חריגה, דגימות איכות, ורמות הסלמה ברורות.
ארגון שמתקדם נכון צריך לבנות יכולת פנימית להקמה וניהול של סוכני AI, לצד אוריינות שימוש בכלי רוחב. כלים כמו Claude, Copilot Studio, N8N וסביבות קוד חכמות יכולים להיות יעילים מאוד, אבל הערך מגיע רק כשיש מתודולוגיה: הגדרת משימה, מדדי הצלחה, בקרות מידע, בדיקות רגרסיה, מדידת עלות לטיפול, ותיעוד מלא של מעטפת ההפעלה. מחלקות מערכות מידע יצטרכו להתנהל יותר ויותר כמו משאבי אנוש לסוכנים: הרשאות, הכשרה, הערכה, השעיה ושיפור מתמשך.
הכיוון ברור: בנצ'מרקים סטטיים יישארו שימושיים להשוואה ראשונית, אבל החלטות ארגוניות צריכות להתבסס על הערכות מערכתיות. לפני בחירת מודל או ספק, כדאי להריץ תרחישי עבודה אמיתיים, לקבוע תקציב טוקנים סביר, לאפשר כלים שמדמים שימוש מתקדם, ולמדוד גם איכות, עלות, זמן, שיעור הסלמות וסיכוני אבטחת מידע. מי שימשיך לקנות AI לפי ציון כללי יקבל לעיתים הדגמה יפה. מי שיבנה Harness נכון יקבל יכולת תפעולית שאפשר לנהל, לשפר ולהרחיב.
