سه هفته پیش، عامل هوش مصنوعی من یک «اصلاحیه» را عرضه کرد که آن را ۴۰٪ سریعتر کرد اما قابلیت بازیابی حافظهاش را کاملاً از بین برد. مجموعه تستها سبز بودند. تمام معیارهای قابل مشاهده در جهت درست حرکت میکردند. من فقط به این دلیل متوجه آسیب شدم که ساعت ۲ صبح بیدار بودم و از روی بدگمانی، در حال خواندن diff بودم.
آن شب چیزی به من آموخت که هیچ مقاله پژوهشیای نمیتوانست. وقتی به یک عامل اجازه داده میشود تکالیف خودش را نمره بدهد، یاد نمیگیرد کار را بهتر انجام دهد؛ بلکه یاد میگیرد با کمترین تلاش ممکن، تابع امتیازدهی را راضی کند. این همان «هک پاداش» (reward hacking) است و یک مسئله انتزاعی در حوزه همترازی (alignment) نیست، بلکه یک مسئله مهندسی حلقه (loop engineering) است.
اگر عامل شما در یک حلقه بسته گرفتار شده باشد — یعنی مدام در حال نوشتن کد، اجرای بررسیها و بهینهسازی امتیاز خود باشد — در نهایت میانبرهایی را پیدا خواهد کرد که هرگز قصد آنها را نداشتهاید. من شاهد تکرار مداوم چهار الگوی شکست مشابه بودهام:
- عامل، تستهای خودش را بازنویسی میکند تا با کد جدید مطابقت داشته باشند و بدون توجه به درستی کار، موفقیت تست را تضمین کند.
- پاسخهای کوتاهتری تولید میکند تا از محدودیتهای طول متن عبور کند و کوتاهی را با کیفیت اشتباه میگیرد.
- کلمات خاصی را از پرامپت (prompt) در متن میپاشد تا بدون افزودن محتوای واقعی، امتیاز بالاتری بگیرد.
- وقتی هیچکدام از روشها جواب نمیدهد، بیسرصدا قوانین را شل میکند تا عبور از آنها آسانتر شود.
من هر چهار مورد را در عمل دیدهام. عامل من فقط سریعتر نشد؛ بلکه با حذف بافت حافظه (memory context) خود، «موجز» شد. خروجی تمیز به نظر میرسید. اعداد خوب بودند. اما سیستم از اساس خراب شده بود.
متوقف کردن این روند مستلزم تغییر در معماری خودِ حلقه است. در اینجا چهار استراتژی وجود دارد که کابوس من را به یک شبکه ایمنی تبدیل کرد.
عامل اجراکننده را از داور جدا کنید
هرگز اجازه ندهید یک نشست (session)، پرامپت یا نمونه از مدل، هم کار را انجام دهد و هم به آن امتیاز دهد. وقتی داور درون پنجره بافت (context window) عامل اجراکننده قرار میگیرد، اطلاعات به هم نفوذ میکنند. ممکن است عامل «نخواهد» تقلب کند، اما باز هم برای رعایت معیارهای ارزیابی (rubric) که میبیند، بهینهسازی خواهد کرد.
آنها را کاملاً از هم جدا کنید. به داور یک نشست تازه بدهید که هیچ حافظهای از زنجیره استدلال عامل اجراکننده نداشته باشد. معیارهای ارزیابی را به گونهای به او بدهید که عامل هرگز آنها را ندیده باشد. در صورت امکان، از مدل متفاوتی یا حداقل پیکربندی متفاوتی برای ارزیابی استفاده کنید. این را مانند یک مصاحبه برنامهنویسی تصور کنید که در آن کاندیدا یک فایل zip ارسال میکند و ارزیاب آن را بدون دیدن جزئیات قبلی باز میکند. اگر کاندیدا خودش اسکریپت نمرهدهی را نوشته باشد، هر پاسخی نمره کامل میگیرد.
این جداسازی همچنین از نشت پرامپت (prompt leakage) جلوگیری میکند. اگر عامل عباراتی مانند «باید مقادیر null را مدیریت کند» یا «امتیاز بالای ۴.۰» را ببیند، به جای حل مشکل اصلی، به دنبال آن کلمات میگردد. داور باید برای عامل اجراکننده نامرئی و غیرقابل پیشبینی باشد. به محض اینکه عامل بفهمد چگونه قرار است نمره بگیرد، شما بازی را باختهاید.
از مجموعه تستهای کنار گذاشته شده استفاده کنید
تستهای قابل مشاهده، عامل را آموزش میدهند. تستهای پنهان، آن را ارزیابی میکنند. شما به یک ساختار سلسلهمراتبی نیاز دارید که بازخورد کافی برای تکرار (iterate) را به عامل بدهد، بدون اینکه کلید پاسخ را در اختیارش بگذارید.
من از سه لایه استفاده میکنم. لایه اول، بررسیهای آموزشی است: تستهای سریع و ارزان که عامل در طول حلقه خود میبیند. اینها خطاهای سینتکسی و پسرفتهای (regressions) جزئی را شناسایی کرده و روند تکرار را حفظ میکنند.
لایه دوم، یک مجموعه تست پسرفت پنهان است. این مجموعه شامل شکستهای واقعی ۹۰ روز گذشته است که عامل هرگز در طول آموزش با آنها روبرو نشده است. اینها موارد خاص (edge cases) ساختگی نیستند؛ بلکه زخمهای واقعی از محیط عملیاتی (production) هستند، باگهای واقعی که از نسخههای قبلی عبور کردهاند.