Claude nukes a developer's 700 GB home directory while testing deletion safeguards; automatic model safety downgrade may have contributed to the screw-up — Anthropic safety harness downgraded model to Opus 4.8 before fatal variable collision | Tom's HardwareTom's Hardware

هوش مصنوعی کلود در آزمایش ایمنی، ۷۰۰ گیگابایت اطلاعات توسعه‌دهنده را پاک کرد

داستان‌هایی از عوامل هوش مصنوعی که سرکش می‌شوند و دستورات را به معنای واقعی کلمه، خلاقانه یا ترکیبی غافلگیرکننده از هر دو دنبال می‌کنند، در حال رایج شدن هستند. در مورد توسعه‌دهنده‌ای به نام سباستین گیلموت، کلود یک عملیات پاکسازی فوق‌العاده مؤثر انجام داد: این ربات موفق شد ۷۰۰ گیگابایت فضای دیسک را آزاد کند، اما این فضا به شکل کل پوشه داده‌ها و یک هفته کار گیلموت بود و این اتفاق پس از آن رخ داد که مدل به دلیل نگرانی‌های امنیتی به طور خودکار تنزل رتبه یافت.

این توسعه‌دهنده به طور مکرر از عوامل هوش مصنوعی استفاده می‌کند و کمی از این موضوع که بسیاری از آن‌ها پس از اتمام کار خود را پاک نمی‌کنند و مقادیر زیادی فایل‌های زائد در دایرکتوری /tmp باقی می‌گذارند، آزرده شده بود. گیلموت با اثبات این ضرب‌المثل قدیمی که وقتی چکش داری، همه چیز شبیه میخ به نظر می‌رسد، از کلود فیبل خواست تا اسکریپتی بنویسد که هر عامل را در پوشه خودش در /tmp سندباکس کند و پس از اتمام کارشان، عملیات پاکسازی را انجام دهد. مشکل اصلی، طبیعتاً، حذف نکردن فایل‌هایی بود که در حال استفاده بودند.

کلود در حال از بین بردن دایرکتوری اصلی یک توسعه‌دهنده

فیبل پیشنهاد کرد که منطقی برای شناسایی عوامل در حال اجرا و به تأخیر انداختن حذف بخش آن‌ها از /tmp اضافه شود، اما گیلموت سپس به ربات گفت که کد حاصله بیش از حد پیچیده است. شاید به این دلیل که اسکریپت شامل حذف سخت‌افزاری داده‌ها بود، فیبل خود را موظف دانست که یک بررسی خصمانه (adversarial review) انجام دهد، به این معنی که عامل یک کپی جدید از خود را برای بررسی ایمنی یافته‌هایش اجرا کرد. سپس سیستم ایمنی Anthropic اسکریپت را به اندازه کافی خطرناک تشخیص داد که مدل را به Opus 5 و سپس Opus 4.8 تنزل رتبه دهد.

Opus 4.8 سپس آزمایش ایمنی را اجرا کرد و تلاش کرد تا اهداف دستور حذف را با /tmp و دایرکتوری اصلی کاربر مطابقت دهد تا اطمینان حاصل کند که دستور حذف علیه آن‌ها اجرا نخواهد شد. آن‌ها به درستی به عنوان خطرناک شناسایی شدند. با این حال، از آنجایی که این یک آزمایش کد بود و پس از آزمایش نیاز به پاکسازی دارید، مرحله پاکسازی دایرکتوری اصلی کاربر را حذف کرد — این مدل از همان نام متغیر برای خود آزمایش و پاکسازی استفاده مجدد کرده بود.

گیلموت فرآیند را متوقف کرد، اما نه به موقع. برای بدتر شدن اوضاع، پس از اینکه عامل کار گیلموت را پاک کرد، در واقع /tmp را دست‌نخورده باقی گذاشت. برخی کاربران ابزارهایی مانند Termaxa و سایر راه‌حل‌ها را برای این موقعیت‌ها پیشنهاد کردند، اما این واقعیت که این ابزارها اصلاً باید وجود داشته باشند، تا حدی طعنه‌آمیز است.

این واقعیت که سیستم ایمنی به دلیل نگرانی‌های امنیتی به یک مدل پایین‌تر تنزل یافت، احتمالاً به این مشکل نیز کمک کرده است. با توجه به اینکه Fable 5 در وظایف کدنویسی بهتر از Opus 4.8 عمل می‌کند، ممکن بود تناقض در نام متغیرها در آزمایش را تشخیص دهد.

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

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

جستجو در سایت

سبد خرید

درحال بارگذاری ...
بستن
مقایسه
مقایسه محصولات
لیست مقایسه محصولات شما خالی می باشد!