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