Goodfire پایش عامل‌های AI را ارزان کرد؛ ۹۴٪ حمله‌ها شناسایی شدند

طبق گزارش Superpower Daily، Goodfire در ۸ اکتبر ۲۰۲۶ پایش درونی عامل‌های AI را از مسیر Baseten معرفی کرد و در آزمون خود روی Kimi K3، ۹۴٪ نشست‌های هک مخرب را شناسایی کرد؛ ۸٫۷٪ نشست‌های سالم به بررسی بیشتر رفتند و پایش حدود ۱۵۰۰ نشست ۵۱ دلار هزینه داشت، در برابر ۲۳۳ دلار برای داور ارزان‌تر و حدود ۱۰ هزار دلار برای داور پیشرفته. این ارقام از آزمون شرکت می‌آیند و عملکرد مانیتور را در بار کاری همهٔ مشتریان نشان نمی‌دهند.

مانیتور هنگام اجرای مدل به سیگنال‌های درونی آن نگاه می‌کند و بررسی پرهزینه با مدل دوم را به گام‌هایی محدود می‌کند که مشکوک تشخیص داده شده‌اند. Baseten در معرفی Project Beacon همکاری با Goodfire را شرح داد و گفت قابلیت‌های ایمنی یکپارچه با سامانهٔ استنتاج خود را طی ماه‌های آینده، ابتدا با مدل‌ها و رفتارهای منتخب و شمار محدودی از شرکای اولیه، عرضه می‌کند. بنابراین دسترسی گزارش‌شده به مانیتورها و عرضهٔ کامل کنترل‌های برنامه‌ریزی‌شده برای Project Beacon دو وضعیت متفاوت‌اند.

پروب Goodfire چگونه گام مشکوک را پیدا می‌کند؟

روش رایج پایش عامل، سپردن متن درخواست‌ها، پاسخ‌ها و گام‌های کار به یک مدل داور است. هرچه نشست طولانی‌تر شود، داور باید محتوای بیشتری را دوباره پردازش کند و هزینه و تأخیر بالا می‌رود. در روش Goodfire، طبقه‌بندهای کوچکی به نام «پروب» از فعال‌سازی‌هایی استفاده می‌کنند که مدل در جریان تولید پاسخ ایجاد کرده است. پروب برای هر ورودی، فراخوانی ابزار یا خروجیِ مرتبط امتیاز خطر می‌سازد؛ اگر امتیاز از آستانهٔ تنظیم‌شده بگذرد، همان بخش برای ارزیابی دقیق‌تر به مدل داور فرستاده می‌شود.

این سازوکار برای عاملی اهمیت دارد که پیش از پایان نشست ابزار فراخوانی می‌کند یا اقدامی بیرونی انجام می‌دهد. بررسی همهٔ متن پس از پایان کار ممکن است هشدار را دیر برساند، اما سیگنالِ هم‌زمان امکان تصمیم‌گیری پیش از اقدام بعدی را فراهم می‌کند. خودِ هشدار معادل مسدود شدن نیست: برنامه می‌تواند رویداد را ثبت کند، تأیید بخواهد، به مسیر جایگزین برود یا درخواست را رد کند. نتیجهٔ اعلام‌شده برای کشف نشست‌های هک را نیز نباید به خطرهای دیگری مانند تزریق دستور یا افشای داده تعمیم داد؛ هر رفتار به تعریف، داده و ارزیابی مخصوص خود نیاز دارد.

اعداد Kimi K3 چه چیزی را اندازه گرفته‌اند؟

پژوهش فنی Goodfire برای زنجیرهٔ پروب و داور، در مجموعه‌ای داخلی شامل حدود ۲۴۰۰ نشست و بیش از ۶۰ هزار نوبت گفت‌وگو، حدود ۹۳٪ کشف نشست‌های زیان‌بار را با ارجاع ۵٫۵٪ نشست‌های سالم گزارش می‌کند. این ارزیابی از گفت‌وگوهای شبیه‌سازی‌شده، وظایف عامل‌محور و نمونه‌هایی از گفت‌وگوهای واقعی تشکیل شده و از برچسب‌های Claude Opus 5 به‌عنوان مرجع استفاده کرده است. ترکیب داده و پیکربندی زنجیره در این پژوهش با آزمون اولیه‌ای که رقم ۹۴٪ را به آن نسبت داده‌اند یکسان توصیف نشده است؛ اختلاف دو درصد را نمی‌توان به تغییر عملکرد یک تنظیم ثابت نسبت داد.

• کشف: رقم ۹۴٪ به شناسایی نشست‌های هک مخرب در گزارش اولیه مربوط است. رقم حدود ۹۳٪ به ارزیابی گسترده‌تر زنجیرهٔ پروب و داور تعلق دارد. در هر دو مورد، واحد نتیجه «نشست» است، نه شمار تک‌تک فرمان‌ها یا حمله‌های موفق در محیط واقعی.
• ارجاع سالم: ۸٫۷٪ در گزارش اولیه و ۵٫۵٪ در ارزیابی فنی، سهم نشست‌های سالمی را نشان می‌دهند که دست‌کم یک بار برای بررسی علامت خورده‌اند. این اعداد نرخ توقف قطعی عامل یا نرخ خطای بررسی انسانی نیستند؛ سیاست پاسخ برنامه تعیین می‌کند پس از هشدار چه اتفاقی بیفتد.
• هزینه: مقایسهٔ ۵۱ دلار برای حدود ۱۵۰۰ نشست به آزمون اولیه مربوط است. پژوهش فنی هزینهٔ محاسبات زنجیره را با واحد دیگری، یعنی به‌ازای هر یک میلیون نوبت عامل، ۶۵ دلار بدون استدلال داور و ۱۸۵ دلار با استدلال داور برآورد می‌کند. تبدیل مستقیم این دو سنجه به قیمت ثابت هر نشست ممکن نیست.

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

هزینهٔ کمتر از کجا می‌آید؟

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

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

عرضهٔ تدریجی چه اثری بر استفادهٔ واقعی دارد؟

کار Goodfire بر مدل‌ها و رفتارهای پشتیبانی‌شده متمرکز است؛ نقش Baseten رساندن سیگنال‌های پایش به سامانه‌ای است که پاسخ برنامه را اجرا می‌کند. Project Beacon برای اتصال پایشِ فعال‌سازی به کنترل‌هایی مانند درخواست تأیید، رد درخواست، مسیر جایگزین و ثبت رویداد طراحی شده است. در مرحلهٔ نخست، دامنهٔ مدل‌های پشتیبانی‌شده و رفتارهای تحت پایش محدود خواهد بود. بنابراین هزینه و نرخ کشف آزمون Kimi K3 را نمی‌توان قیمت یا کارایی ازپیش‌تعیین‌شدهٔ هر عامل میزبانی‌شده در Baseten دانست.

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

بیشتر بخوانید:

• عامل‌های OpenAI داخل AWS اجرا می‌شوند؛ پیش‌نمایش فقط در سه منطقه است
• Trebellar هجده میلیون دلار گرفت؛ اجاره‌نامه‌ها خوراک عامل‌های AI شدند
• عامل تازهٔ AWS هر هفته معماری را می‌سنجد؛ دسترسی از Business+ شروع می‌شود