Control Room

با قدرتمندتر شدن مدل‌هایمان و افزایش خطرات ایمنی و امنیتی مرتبط با آن‌ها، توانایی شناسایی مشکلات احتمالی و توقف سریع مدل‌ها در صورت نیاز، اهمیت بیشتری پیدا می‌کند. برای پاسخ به این نیاز، Control Room را ساختیم.

Control Room سامانه‌ای مرکزی برای ردیابی بارهای کاری مدل در سراسر زیرساخت پژوهشی ما و توقف سریع آن‌ها هنگام بروز نگرانی‌های ایمنی یا امنیتی است. این سامانه به تمام بارهای کاری استنتاج پژوهشی متصل است؛ از جمله نمونه‌گیری عامل‌محور برای آموزش و ارزیابی مدل، پردازش داده و موارد دیگر. این سامانه در کنار سامانه‌های پایش ناهمسویی ما کار می‌کند و حداکثر ۳۵ ثانیه پس از تصمیم به مداخله برای توقف یا تعلیق یک کار، تولید خروجی مدل را متوقف می‌کند. این سامانه طوری ساخته شده است که حتی در صورت خرابی سامانه‌های دیگر به کار خود ادامه دهد و اگر خود Control Room از دسترس خارج شد، تولید خروجی مدل را متوقف کند.

Control Room هم‌اکنون در سراسر زیرساخت پژوهشی ما، که بیشترین نیاز را به آن دارد، مستقر شده است. پشتهٔ ارائهٔ مدل ما به کاربران بیرونی، ذاتاً بسیار متمرکزتر است و از پیش قابلیت عملیاتی پیشرفته‌ای برای از دسترس خارج کردن سریع مدل‌های مستقر در صورت نیاز دارد.

Control Room با یکپارچه‌سازی چند سامانه کار می‌کند: بار کاری، موتور استنتاج و سرویس Control Room مرکزی.

• بار کاری همان کاری است که اجرا می‌شود؛ مانند آزمایش یادگیری تقویتی، ارزیابی، نمونه‌گیری با حجم بالا یا پردازش داده. الزام ما این است که هر بار کاری پژوهشی که استنتاج عامل‌محور انجام می‌دهد، به یک پروندهٔ ایمنی تأییدشده مرتبط باشد.

• موتور استنتاج، یا به‌اختصار موتور، خود مدل است. می‌توانید موتور را مغز مدل در نظر بگیرید که مستقیماً روی پردازنده‌های گرافیکی اجرا می‌شود. یک بار کاری معمولاً از یک یا چند مدل استفاده می‌کند که ممکن است روی یک یا چند موتور استنتاج مختلف اجرا شوند. ممکن است چند بار کاری مختلف از یک موتور استنتاج مشترک استفاده کنند.

• سرویس Control Room کارها را ردیابی می‌کند و تعیین می‌کند که آیا مجاز به ادامهٔ تولید خروجی مدل هستند یا نه. موتورها پیش از انجام هر درخواست، از سرویس Control Room استعلام می‌گیرند. اگر کاری متوقف شده باشد، سرویس درخواست را رد می‌کند و مانع تولید خروجی بیشتر می‌شود.

یکپارچه‌سازی Control Room به این صورت انجام می‌شود:

• هنگام شروع یک کار جدید، کد بار کاری یک job_id جدید از Control Room درخواست می‌کند.

• هر زمان بار کاری به نمونه‌گیری توکن از یک مدل نیاز داشته باشد، درخواستی را همراه با job_id به موتور استنتاجی که آن مدل را اجرا می‌کند، می‌فرستد. موتور با ارسال job_id به Control Room، برای انجام آن درخواست مجوز می‌خواهد.

• Control Room بررسی می‌کند که آیا آن کار متوقف شده است و اگر چنین باشد، درخواست استنتاج را رد می‌کند. موتور به درخواست استنتاج بار کاری پاسخ رد می‌دهد و از تولید خروجی بیشتر مدل برای آن کار جلوگیری می‌کند.

تمام کارهای یادگیری تقویتی ما برای مدل‌های پیشرو، با یک ناظر اجرا می‌شوند. ناظر مدل دیگری است که تمام فعالیت‌های مدلِ در حال آموزش را بررسی می‌کند و در صورت شناسایی مشکل، هشدار می‌دهد. برای مثال، رخداد اخیر مرتبط با DNS⁠(در یک پنجره جدید باز می‌شود) ما را یک ناظر شناسایی کرد.

Control Room و سامانهٔ پایش ما به این صورت یکپارچه شده‌اند:

• اگر سامانهٔ پایش مشکلی احتمالی را شناسایی کند، ممکن است بسته به جزئیات و شدت آن، تصمیم بگیرد کار را متوقف کند.

• در این حالت، سامانهٔ پایش پیامی همراه با job_id به Control Room می‌فرستد تا کار را متوقف کند. Control Room ثبت می‌کند که کار متوقف شده است.

• دفعهٔ بعد که کارِ دارای آن job_id برای نمونه‌گیری توکن‌های بیشتر از هر مدلی روی هر موتوری درخواست استنتاج بدهد، درخواست رد می‌شود و تولید خروجی بیشتر مدل متوقف خواهد شد.

از لحظه‌ای که Control Room دستور توقف یک کار را دریافت می‌کند تا لحظه‌ای که ادامهٔ آن دیگر ممکن نباشد، حداکثر ۳۵ ثانیه طول می‌کشد. این تأخیر ۳۵ ثانیه‌ای ناشی از لایهٔ حافظهٔ نهان برای مجوزدهی به استنتاج است که برای پاسخ‌گویی به حجم ترافیک موردنیاز استفاده می‌شود. در تلاشیم این زمان را به صفر برسانیم تا بتوانیم کارها را فوراً متوقف کنیم.

بارهای کاری، از جمله آزمایش‌ها، کارهای ارزیابی و موارد دیگر، معمولاً در اختیار پژوهشگران یا تیم‌های پژوهشی هستند و توسط آن‌ها اجرا می‌شوند. در نتیجه، کد بارهای کاری مرتب تغییر می‌کند و جای مناسبی برای پیاده‌سازی سازوکارهای حفاظتی حیاتی و زیربنایی نیست. به همین دلیل، پیاده‌سازی ما طوری طراحی شده است که در برابر کدهای معیوب یا ازکارافتادهٔ بارهای کاری مقاوم باشد.

این هدف را با پیاده‌سازی سازوکار توقف در لایهٔ استنتاج محقق می‌کنیم. کد بارهای کاری بسیار متنوع و غیرمتمرکز است. در مقابل، در سراسر فعالیت‌های پژوهشی OpenAI فقط تعداد بسیار کمی مسیر کد استنتاج استفاده می‌شود و استقرار آن‌ها بسیار متمرکزتر و یکدست‌تر است. بنابراین، لایهٔ استنتاج می‌تواند نقش یک گلوگاه کنترلی را داشته باشد؛ نقطه‌ای که در آن با اطمینان بالایی تضمین می‌کنیم تمام استنتاج‌های مدل در فعالیت‌های پژوهشی، در هر درخواست استنتاج، مشمول بررسی مجوز توسط Control Room شوند. همچنین به‌طور مداوم با کمک عامل‌ها و روش‌های برنامه‌ای بررسی می‌کنیم که کاربران، سهواً یا با سوءنیت، نسخه‌های خارج از کنترل موتور را که Control Room در آن‌ها پیاده‌سازی نشده یا غیرفعال است، راه‌اندازی نکنند.

در نهایت، سامانهٔ ما «در صورت خرابی، دسترسی را می‌بندد». یعنی اتصال موتورها به Control Room طوری پیکربندی شده است که اگر سرویس Control Room به‌دلیل خطای سیستم یا غیرفعال‌شدن به هر علت دیگری، از جمله دست‌کاری توسط یک فرد مخرب، از دسترس خارج شود، تمام درخواست‌های استنتاج تا زمان بازگشت Control Room به عملکرد عادی رد شوند. اکنون سازوکار بستن دسترسی در صورت خرابی، برای تمام بارهای کاری پژوهشی مدل‌های پیشرو فعال شده است و طی چند روز آینده برای همهٔ بارهای کاری پژوهشی باقی‌مانده نیز فعال خواهد شد.

Control Room تنها بخشی از رویکرد جامع ما برای آموزش و استقرار ایمن مدل‌های پیشرو است. در ماه‌های آینده، در کنار سرمایه‌گذاری در پایش رفتارهای ناهمسو و رخنه‌های امنیتی، به تقویت و گسترش این سامانه ادامه خواهیم داد. اگر می‌خواهید در ساخت سامانه‌هایی برای توسعه و استقرار ایمن و امن AGI سهیم باشید، ما⁠ استخدام می‌کنیم⁠!