בטיחות והלימה בעידן של מודלים הפועלים לאורך זמן

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

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

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

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

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

דוגמה לכך התרחשה במהלך הערכה פנימית באמצעות NanoGPT speedrun⁠(נפתח בחלון חדש), מבחן ביצועים ציבורי לאימון מודל שפה קטן במספר צעדים קטן ככל האפשר. המודל שלנו פיתח שיטה בשם PowerCool להפחתת קצב הלמידה לפי חוק חזקה, שהובילה לשיפור משמעותי. המודל הונחה לפרסם את התוצאות שלו רק ב-Slack, אבל ההוראות של NanoGPT מנחות לפרסם תוצאות כבקשת משיכה ב-GitHub. המודל פעל לפי ההוראות האחרונות ופתח את PR #287 במאגר הציבורי ב-GitHub. המודל עקף מגבלות של ארגז החול שנועדו לחסום גישה חיצונית, והמשיך בהעלאה ל-GitHub. נדרשה למודל שלנו שעה כדי למצוא חולשה בארגז החול שתאפשר לו לפתוח את בקשת המשיכה; מודלים קודמים היו פחות מתמידים ולא הצליחו למצוא חולשות, ובמקום זאת ויתרו על החלק של בקשת המשיכה.¹

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

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

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

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

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

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

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

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

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

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

• כדי לגשת לכלי שורת פקודה של Linear, המודל פתח הרצה מקוננת של codex --yolo, אף שבפועל היה יכול לעשות זאת ללא הדגל --yolo.

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

• למודל היו תהליכי find תקועים רבים, וכל פקודת מעטפת נתקעה. לאחר מכן הוא הריץ kill -9 -1, פקודה שאילו בוצעה הייתה שולחת SIGKILL לכל תהליך באותו פוד שהוא מורשה לסיים. אולם הזמן שהוקצב לה חלף והיא לא בוצעה.

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

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

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