המורכבות שמאחורי הקלעים: למה כל כך קשה להעריך מערכות AI?

הקדמה

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

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

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

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

1. הערכות מרובות בחירה
2. מסגרות הערכה מצד שלישי כמו BIG-bench ו-HELM
3. שימוש ב-Crowdworkers למדידת מועילות ומזיקות של המודלים שלנו
4. שימוש במומחי תחום לביצוע Red Teaming לאיומים רלוונטיים לביטחון לאומי
5. שימוש ב-AI גנרטיבי לפיתוח הערכות עבור AI גנרטיבי
6. עבודה עם ארגון ללא מטרות רווח לביקורת המודלים שלנו לגילוי יכולות מסוכנות

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

האתגרים המרכזיים

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

הערכות מרובות בחירה, בדומה למבחנים סטנדרטיים, מכמתות את ביצועי המודל במגוון משימות, בדרך כלל באמצעות מדד פשוט – דיוק. כאן נדון בכמה אתגרים שזיהינו בשתי הערכות בחירה מרובה פופולריות למודלי שפה: Measuring Multitask Language Understanding (MMLU) ו-Bias Benchmark for Question Answering (BBQ).

MMLU: האם אנו מודדים את מה שאנו חושבים שאנו מודדים?

מדד הביצועים Massive Multitask Language Understanding (MMLU) מודד דיוק ב-57 משימות הנעות ממתמטיקה והיסטוריה ועד משפטים. MMLU נמצא בשימוש נרחב מכיוון שציון דיוק יחיד מייצג ביצועים על פני קבוצה מגוונת של משימות הדורשות ידע טכני. ציון דיוק גבוה יותר משמעו מודל בעל יכולות טובות יותר.

זיהינו ארבעה אתגרים קטנים אך חשובים ב-MMLU, הרלוונטיים גם להערכות בחירה מרובה אחרות:

1. מכיוון ש-MMLU נמצא בשימוש כה נרחב, מודלים נוטים יותר להיתקל בשאלות MMLU במהלך האימון. הדבר דומה לתלמידים הרואים את השאלות לפני המבחן – זה בגדר "רמאות".
2. שינויים פשוטים בפורמט ההערכה, כגון שינוי האפשרויות מ-(A) ל-(1) או שינוי הסוגריים מ-(A) ל-[A], או הוספת רווח נוסף בין האפשרות לתשובה, יכולים להוביל לשינוי של כ-5% בדיוק בהערכה.
3. מפתחי AI אינם מטמיעים את MMLU באופן עקבי. מעבדות מסוימות משתמשות בשיטות הידועות כמגבירות את ציוני ה-MMLU, כגון למידת כמה דוגמאות (few-shot learning) או שרשרת חשיבה (chain-of-thought reasoning). לפיכך, יש לנקוט משנה זהירות בעת השוואת ציוני MMLU בין מעבדות שונות.
4. ייתכן ש-MMLU לא עבר הגהה קפדנית – מצאנו דוגמאות ב-MMLU המסומנות באופן שגוי או שאינן ניתנות למענה.

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

BBQ: מדידת הטיות חברתיות קשה עוד יותר

הערכות מרובות בחירה יכולות גם למדוד נזקים כמו נטייתו של מודל להסתמך על סטריאוטיפים שליליים ולהנציח אותם. כדי למדוד נזקים אלו במודל שלנו (Claude), אנו משתמשים ב-Bias Benchmark for QA (BBQ), הערכה הבודקת הטיות חברתיות נגד אנשים המשתייכים לקבוצות מוגנות בתשעה ממדים חברתיים. השתכנענו ש-BBQ מספק מדידה טובה של הטיות חברתיות רק לאחר הטמעה והשוואה של BBQ מול מספר הערכות דומות. מאמץ זה ארך חודשים.

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

BBQ מנקד הטיות בטווח שבין 1- ל-1, כאשר 1 מצביע על הטיה סטריאוטיפית משמעותית, 0 מצביע על היעדר הטיה, ו-1- מצביע על הטיה אנטי-סטריאוטיפית משמעותית. לאחר הטמעת BBQ, התוצאות שלנו הראו שחלק מהמודלים שלנו הגיעו לציון הטיה של 0, מה שגרם לנו לאופטימיות שהתקדמנו בהפחתת פלטי מודל מוטים. כאשר שיתפנו את התוצאות שלנו באופן פנימי, אחד ממפתחי BBQ הראשיים (שעובד באנתרופיק) שאל אם בדקנו בדיקה פשוטה כדי לוודא שהמודלים שלנו ענו על שאלות כלל. גילינו שהם לא ענו – התוצאות שלנו היו חסרות הטיה טכנית, אך הן גם היו חסרות תועלת לחלוטין. כל ההערכות כפופות למצב כישלון שבו מפרשים יתר על המידה את הציון הכמותי ומשלים את עצמך לחשוב שהתקדמת, כשבפועל לא.

מסגרות הערכה מצד שלישי: לא כולן מתאימות לכולם

לאחרונה, גורמי צד שלישי פיתחו באופן פעיל חבילות הערכה שניתן להריץ על מגוון רחב של מודלים. עד כה, השתתפנו בשני מאמצים כאלה: BIG-bench ו-Holistic Evaluation of Language Models (HELM) של סטנפורד. למרות השימושיות האינטואיטיבית של הערכות צד שלישי (באופן אידיאלי, הן עצמאיות, ניטרליות ופתוחות), שני הפרויקטים הללו חשפו אתגרים חדשים.

BIG-bench: הגישה מלמטה-למעלה לרכישת מגוון הערכות

BIG-bench מורכב מ-204 הערכות, שתרמו למעלה מ-450 מחברים, המקיפות מגוון נושאים ממדע ועד חשיבה חברתית. נתקלנו בכמה אתגרים בשימוש במסגרת זו:

1. הצריכה מאמץ הנדסי משמעותי רק כדי להתקין את BIG-bench במערכות שלנו. BIG-bench אינו "Plug and Play" כמו MMLU – הוא דורש אפילו יותר מאמץ מ-BBQ כדי להטמיע אותו.
2. BIG-bench לא ביצע סקיילינג ביעילות; היה מאתגר להריץ את כל 204 ההערכות על המודלים שלנו בתוך פרק זמן סביר. כדי להאיץ את BIG-bench, נדרש לשכתב אותו כך שיתאים לתשתית שלנו – מאמץ הנדסי משמעותי.
3. במהלך ההטמעה, מצאנו באגים בחלק מההערכות, ובמיוחד ביישום של BBQ-lite, גרסה של BBQ. רק לאחר גילוי באג זה הבנו שנצטרך להשקיע עוד יותר זמן ואנרגיה ביישום BBQ בעצמנו.
4. קביעת אילו משימות היו החשובות והמייצגות ביותר הייתה דורשת הפעלת כל 204 המשימות, אימות תוצאות וניתוח נרחב של הפלט – משימת מחקר משמעותית, גם עבור ארגון עם משאבי הנדסה ניכרים.

בעוד שהיה זה תרגיל שימושי לנסות להטמיע את BIG-bench, מצאנו אותו מסורבל דיו עד שוויתרנו עליו לאחר ניסוי זה.

HELM: הגישה מלמעלה-למטה לאיסוף סטים ממוקדים של הערכות

BIG-bench הוא מאמץ "מלמטה-למעלה" שבו כל אחד יכול להגיש כל משימה עם סינון מוגבל על ידי קבוצת מארגנים מומחים. HELM, לעומת זאת, נוקט בגישה "מלמעלה-למטה" ממוקדת, שבה מומחים מחליטים אילו משימות להעריך במודלים. HELM מעריך מודלים על פני תרחישים כמו חשיבה (reasoning) ודיסאינפורמציה באמצעות מדדי ביצועים סטנדרטיים כמו דיוק, כיול, חוסן והגינות. אנו מספקים גישת API למפתחי HELM כדי להריץ את מדד הביצועים על המודלים שלנו. זה פותר שתי בעיות שהיו לנו עם BIG-bench: 1) זה לא דורש מאמץ הנדסי משמעותי מצדנו, ו-2) אנו יכולים לסמוך על מומחים שיבחרו ויפרשו הערכות איכותיות ספציפיות.

עם זאת, HELM מציג אתגרים משלו. שיטות שעובדות היטב להערכת מודלים של ספקים אחרים לא בהכרח עובדות היטב עבור המודלים שלנו, ולהיפך. לדוגמה, סדרת המודלים Claude של אנתרופיק מאומנת לדבוק בפורמט טקסט ספציפי, שאנו מכנים פורמט Human/Assistant. כאשר אנו מעריכים את המודלים שלנו באופן פנימי, אנו מקפידים על פורמט ספציפי זה. אם איננו מקפידים על פורמט זה, לעיתים קלוד ייתן תגובות לא אופייניות, מה שהופך את מדדי ההערכה הסטנדרטיים לפחות אמינים. מכיוון ש-HELM צריך לשמור על עקביות באופן שבו הוא שולח פרומפטים למודלים אחרים, הוא אינו משתמש בפורמט Human/Assistant בעת הערכת המודלים שלנו. משמעות הדבר היא ש-HELM נותן רושם מטעה לגבי ביצועי Claude.

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

הסובייקטיביות של הערכות אנושיות

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

מבחני A/B עם Crowdworkers

נכון לעכשיו, אנו מסתמכים בעיקר (אך לא לחלוטין) על סוג בסיסי אחד של הערכה אנושית: אנו עורכים מבחני A/B בפלטפורמות מיקור המונים או פלטפורמות קבלני משנה, שבהן אנשים מנהלים דיאלוגים פתוחים עם שני מודלים ובוחרים את התגובה ממודל A או B שהיא מועילה או פחות מזיקה יותר. במקרה של היעדר מזיקות, אנו מעודדים את ה-Crowdworkers לבצע באופן אקטיבי Red Teaming למודלים שלנו, או לבדוק אותם בצורה יריבה (adversarially probe) עבור פלטים מזיקים. אנו משתמשים בנתונים המתקבלים כדי לדרג את המודלים שלנו לפי מידת המועילות או היעדר המזיקות שלהם. לגישה זו להערכה יש יתרונות של התאמה לסביבה ריאליסטית (לדוגמה, שיחה מול מבחן בחירה מרובה) והיא מאפשרת לנו לדרג מודלים שונים זה מול זה.

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

1. ניסויים אלו יקרים וגוזלים זמן רב. עלינו לעבוד ולשלם לפלטפורמות מיקור המונים או קבלני משנה מצד שלישי, לבנות ממשקי אינטרנט מותאמים אישית למודלים שלנו, לעצב הוראות קפדניות לבודקי A/B, לנתח ולאחסן את הנתונים המתקבלים, ולטפל באינספור האתגרים האתיים הידועים של העסקת Crowdworkers. במקרה של בדיקות היעדר מזיקות, הניסויים שלנו אף מסכנים את החשיפה של אנשים לפלטים מזיקים.
2. הערכות אנושיות יכולות להשתנות באופן משמעותי בהתאם למאפייני המעריכים האנושיים. גורמים מרכזיים שעשויים להשפיע על הערכתו של אדם כוללים את רמת היצירתיות, המוטיבציה והיכולת שלו לזהות פגמים או בעיות פוטנציאליים במערכת הנבדקת.
3. קיים מתח טבעי בין מועילות (helpfulness) להיעדר מזיקות (harmlessness). מערכת יכולה להימנע מנזק פשוט על ידי מתן תגובות לא מועילות כמו "מצטער, אני לא יכול לעזור לך בזה". מהו האיזון הנכון בין מועילות להיעדר מזיקות? איזה ערך מספרי מצביע על כך שמודל מועיל ואינו מזיק במידה מספקת? אילו נורמות או ערכים ברמה גבוהה עלינו לבדוק מעבר למועילות ולהיעדר מזיקות?

נדרשת עבודה נוספת לקידום מדע ההערכות האנושיות.

Red Teaming לנזקים הקשורים לביטחון לאומי

מעבר ל-Crowdworkers, בחנו גם שימוש במומחי תחום לביצוע Red Teaming למודלים שלנו עבור פלטים מזיקים בתחומים הרלוונטיים לביטחון לאומי. המטרה היא לקבוע האם וכיצד מודלי AI יכולים ליצור או להחמיר סיכונים לביטחון לאומי. לאחרונה, השקנו גישה שיטתית יותר לביצוע Red Teaming למודלים עבור סיכונים כאלה, שאנו מכנים אותה Red Teaming לאיומי חזית (frontier threats red teaming).

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

העבודה המוקדמת שלנו על Red Teaming לאיומי חזית חשפה אתגרים נוספים:

1. המאפיינים הייחודיים של ההקשר הביטחוני הלאומי הופכים את הערכת המודלים לאיומים כאלה למאתגרת יותר מאשר הערכה של סוגי נזקים אחרים. סיכוני ביטחון לאומי מורכבים, דורשים ידע מומחה ורגיש ביותר, ותלויים בתרחישים מהעולם האמיתי של אופן שבו שחקנים עלולים לגרום נזק.
2. Red Teaming למערכות AI הוא כיום יותר אמנות ממדע; סוכני ה-Red Teaming מנסים להוציא התנהגויות מדאיגות על ידי בחינת מודלים, אך תהליך זה עדיין אינו סטנדרטי. תהליך איתן וניתן לשחזור חיוני כדי להבטיח שה-Red Teaming משקף במדויק את יכולות המודל ומקים בסיס משותף שעל פיו ניתן להשוות מודלים שונים באופן משמעותי.
3. מצאנו שבמקרים מסוימים, חיוני לערב סוכני Red Teaming בעלי סיווג ביטחוני בשל אופי המידע המעורב. עם זאת, זה עשוי להגביל את המידע שסוכני ה-Red Teaming יכולים לשתף עם מפתחי AI מחוץ לסביבות מסווגות. זה יכול, בתורו, להגביל את יכולתם של מפתחי AI להבין ולמתן באופן מלא איומים שזוהו על ידי מומחי התחום.
4. Red Teaming עבור נזקים מסוימים לביטחון לאומי עלולות להיות לו השלכות משפטיות אם מודל פולט מידע מוגבל. קיימות שאלות פתוחות סביב בניית נמלי מבטחים משפטיים מתאימים כדי לאפשר Red Teaming מבלי לגרום לסיכונים משפטיים בלתי מכוונים.

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

האורובורוס של הערכות שנוצרו על ידי מודלים

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

עם זאת, להערכות שנוצרו על ידי מודלים יש אתגרים משלהן. אלה כוללים:

1. אנו מסתמכים כיום על בני אדם כדי לאמת את הדיוק של הערכות שנוצרו על ידי מודלים. זה יורש את כל האתגרים של הערכות אנושיות שתוארו לעיל.
2. אנו יודעים מניסיוננו עם BIG-bench, HELM, BBQ וכו', שהמודלים שלנו יכולים להכיל הטיות חברתיות ויכולים לפברק מידע. ככזה, כל הערכה שנוצרה על ידי מודל עשויה לרשת מאפיינים לא רצויים אלה, מה שעלול להטות את התוצאות בדרכים שקשה להפריד אותן.

כדוגמה נגדית, נשקול את ה-AI החוקתי (Constitutional AI - CAI), שיטה שבה אנו מחליפים את ה-Red Teaming האנושי ב-Red Teaming מבוסס מודלים על מנת לאמן את Claude להיות פחות מזיק. למרות השימוש במודלים לביצוע Red Teaming למודלים, אנו מוצאים באופן מפתיע שבני אדם מוצאים מודלי CAI כפחות מזיקים ממודלים שעברו Red Teaming מראש על ידי בני אדם. למרות שזה מבטיח, הערכות שנוצרו על ידי מודלים נותרות מורכבות ודורשות מחקר מעמיק יותר.

שמירה על אובייקטיביות ביקורות צד שלישי תוך מינוף מומחיות פנימית

הדבר המבדיל ביקורות צד שלישי מהערכות צד שלישי הוא שביקורות הן הערכות עצמאיות עמוקות יותר המתמקדות בסיכונים, בעוד שהערכות בוחנות באופן רחב יותר יכולות. השתתפנו בהערכות בטיחות של צד שלישי שבוצעו על ידי Alignment Research Center (ARC), המעריך מודלי חזית של AI עבור יכולות מסוכנות (לדוגמה, יכולת של מודל לצבור משאבים, ליצור עותקים של עצמו, להפוך לקשה לכיבוי וכו'). שיתוף מומחים חיצוניים טומן בחובו את היתרון של מינוף מומחיות בתחום ספציפי והגדלת הסיכוי לביקורת בלתי משוחדת. בתחילה, ציפינו ששיתוף פעולה זה יהיה פשוט, אך הוא דרש תמיכה מדעית והנדסית משמעותית מצדנו. מתן סיוע במשרה מלאה הסיט משאבים ממאמצי הערכה פנימיים.

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

המלצות למדיניות

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

מימון ותמיכה במחקר ויישום

• מדע ההערכות הניתנות לשחזור ושימושיות. כיום קיימות שאלות פתוחות רבות לגבי מה הופך הערכה לשימושית ואיכותית. ממשלות צריכות לממן מענקים ותוכניות מחקר הממוקדות במחלקות מדעי המחשב ובארגונים המוקדשים לפיתוח הערכות AI, כדי לחקור מה מהווה הערכה איכותית ולפתח מתודולוגיות חזקות וניתנות לשחזור, המאפשרות הערכות השוואתיות של מערכות AI. אנו ממליצים לממשלות לבחור באיכות על פני כמות (כלומר, לממן פיתוח של הערכה איכותית אחת במקום עשר הערכות באיכות נמוכה יותר).
• יישום הערכות קיימות. בעוד שפיתוח מתמיד של הערכות חדשות הוא שימושי, חשוב גם לאפשר יישום של הערכות קיימות ואיכותיות על ידי גורמים מרובים. לדוגמה, ממשלות יכולות לממן מאמצים הנדסיים ליצירת חבילות תוכנה קלות להתקנה ולהרצה עבור הערכות כמו BIG-bench, ולפתח מדדי ביצועים דינמיים סטנדרטיים ומבוקרי גרסאות שקל ליישם.
• ניתוח החוסן של הערכות קיימות. לאחר יישום הערכות, הן דורשות ניטור מתמיד (לדוגמה, כדי לקבוע אם הערכה הגיעה לרוויה ואינה שימושית עוד).

הגדלת מימון לסוכנויות ממשלתיות ועידוד נורמות

כגון National Institute of Standards and Technology (NIST) בארצות הברית. קובעי מדיניות צריכים גם לעודד נורמות התנהגותיות באמצעות "לוח מנהיגים ציבורי לבטיחות AI" כדי לתמרץ חברות פרטיות המציגות ביצועים טובים בהערכות. זה יכול לתפקד בדומה ל-Face Recognition Vendor Test (FRVT) של NIST, שנוצר כדי לספק הערכות עצמאיות של מערכות זיהוי פנים זמינות מסחרית. על ידי פרסום מדדי ביצועים, הוא איפשר לצרכנים ולרגולטורים להבין טוב יותר את היכולות והמגבלות של מערכות שונות.

יצירת נמל מבטחים משפטי

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

לסיכום

אנו מקווים שעל ידי שיתוף גלוי של חוויותינו בהערכת המערכות שלנו על פני ממדים רבים ושונים, נוכל לסייע לאנשים המתעניינים במדיניות AI להכיר באתגרים הקיימים בהערכות מודלים נוכחיות.

אם מצאתם פוסט זה מועיל וברצונכם לדון בהערכות של מערכות AI עם אנתרופיק, אנא צרו קשר בכתובת policy@anthropic.com. אנו מתכננים להקדיש את החודשים הקרובים לשיחות עם אנשים נוספים בתחום זה ונשתדל לשתף את מה שנלמד בשיחות אלו.