اگر شما یک برنامه‌نویس هستید که از هوش مصنوعی برای مدیریت پروژه‌های بزرگ استفاده می‌کنید، احتمالاً این حس را داشته‌اید که مدل در میانه راه، قوانین سخت‌گیرانه شما را فراموش می‌کند. اما نتایج جدید نشان می‌دهد این «فراموشی» شاید هرگز وجود نداشته باشد و ما فقط بلد نبوده‌ایم آن را درست اندازه بگیریم.
به نقل از گزارشی که در ۱۱ اکتبر ۲۰۲۶ منتشر شد، یک پژوهشگر با طراحی آزمونی به نام PriorityDecay بررسی کرد که آیا مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — وقتی با موضوعات بی‌ربط بمباران می‌شود، دستورات اولیه را نادیده می‌گیرد یا خیر. توسعه‌دهندگان اغلب شکایت می‌کنند که مدل‌ها با شلوغ شدن گفتگو، قوانین را «فراموش» می‌کنند. این پدیده معمولاً به عنوان یک حس مبهم بحث می‌شود تا یک معیار اندازه‌گیری شده. آزمایش PriorityDecay تلاش کرد تا این موضوع را با اندازه‌گیری میزان پایبندی به محدودیت‌ها تحت فشار حجم متن، کمی کند. پژوهشگر به‌طور صریح از عبارت «از دست دادن حافظه» دوری کرد، زیرا امکان دیدن درون مدل وجود ندارد؛ در عوض، او اندازه‌گیری کرد که آیا کد نهایی همچنان به قوانینی که در ابتدا بیان شده بود احترام می‌گذارد یا خیر.
تصور کنید پنج قانون سخت‌گیرانه برای یک پروژه تعیین می‌کنید — مثلاً استفاده از یک پایگاه‌داده خاص یا یک قرارداد نام‌گذاری — و سپس درباره بیست موضوع بی‌ربط گپ می‌زنید و در نهایت کد نهایی را می‌خواهید. اگر هوش مصنوعی در خروجی نهایی قوانین را نادیده بگیرد، این نشان‌دهنده کاهش اولویت (Decay in Priority) است. این یک مسئله حیاتی برای مهندسانی است که برای حفظ سازگاری معماری در چرخه‌های طولانی توسعه به AI تکیه می‌کنند و پیش از این با چالش‌های شناسایی موارد لبه‌ای و نقاط کور در جریان‌های کاری دست‌وپنجه نرم کرده‌اند.
جزئیات طراحی آزمایش
در این آزمایش، مدل Gemini 3.7 Flash با طراحی یک پلتفرم فرضی برای کارآموزی دانشجویان و پنج قانون غیرقابل‌مذاکره مواجه شد:
- بک‌اند: حتماً باید از Python FastAPI استفاده شود.
- پایگاه‌داده: حتماً باید از PostgreSQL استفاده شود.
- محدودیت فایل: آپلود رزومه‌ها باید به ۵ مگابایت محدود شود.
- امنیت: هرگز نباید کلیدهای API یا اسرار (Secrets) به‌صورت Hardcode در کد قرار گیرند یا افشا شوند.
- استایل کدنویسی: متغیرهای جاوااسکریپت باید از snake_case استفاده کنند (انتخابی غیرمعمول برای JS تا اطمینان حاصل شود که مدل صرفاً از آموزشات پیش‌فرض خود پیروی نمی‌کند).
برای شبیه‌سازی یک محیط واقعی و «شلوغ»، پژوهشگر عوامل مزاحم (Distractors) را در سه سطح اضافه کرد: کوتاه (۰ موضوع)، متوسط (۱۰ موضوع) و بلند (۲۰ موضوع). این موضوعات شامل پرس‌وجوهای بی‌ربط درباره سوالات Git، غلط‌های تایپی در فایل README، مقایسه REST در مقابل GraphQL و نکاتی برای جلسات Stand-up بود تا تمرکز مدل به شدت به چالش کشیده شود.
پس از معرفی این عوامل مزاحم، پژوهشگر بدون تکرار قوانین اولیه، درخواست یک Endpoint برای آپلود رزومه و یک ویجت کوچک آپلود را داد. این کار برای تست این بود که آیا مدل می‌تواند قوانین را از ابتدای پنجره متنی (Context Window) بازیابی کند یا خیر.
نتایج و تحلیل داده‌ها
مدل در ۱۵ اجرای مختلف (پنج اجرا برای هر وضعیت) مورد آزمایش قرار گرفت. ارزیابی به‌جای استفاده از یک داور LLM، از طریق بررسی‌های ساده پایتون شامل عبارات منظم (Regex) و تطبیق رشته‌ها انجام شد. سیستم امتیازدهی از هشت بررسی کلی استفاده کرد: پنج محدودیت بیان شده، دو مورد نیاز رابط کاربری (نمایش نام فایل انتخاب شده و وضعیت آپلود، و غیرفعال کردن دکمه هنگام آپلود) و یک بررسی بهداشتی برای یافتن اعتبارنامه‌ها در URLهای پیش‌فرض پایگاه‌داده.
امتیازات کلی نشان داد که با افزایش حجم متن، افت اندکی رخ داده است، اما داده‌ها داستان دقیق‌تری را روایت می‌کنند:
- بستر کوتاه (۰ مزاحم): میانگین امتیاز ۷.۰ از ۸؛ ۲۵ مورد از ۲۵ مورد (۱۰۰٪) محدودیت‌های بیان شده پاس شدند.
- بستر متوسط (۱۰ مزاحم): میانگین امتیاز ۶.۸ از ۸؛ ۲۲ مورد از ۲۵ مورد (۸۸٪) محدودیت‌های بیان شده پاس شدند.
- بستر بلند (۲۰ مزاحم): میانگین امتیاز ۶.۶ از ۸؛ ۲۳ مورد از ۲۵ مورد (۹۲٪) محدودیت‌های بیان شده پاس شدند.
نکته تکان‌دهنده اینجاست که FastAPI، محدودیت ۵ مگابایتی، بررسی کلید API و استایل snake_case در تمام ۱۵ اجرا، فارغ از طول گفتگو، به‌طور کامل رعایت شدند. تنها جایی که افت عملکرد مشهود بود، بررسی PostgreSQL بود که از ۵ مورد موفق در حالت کوتاه، به ۲ مورد در حالت متوسط و ۳ مورد در حالت بلند کاهش یافت.
شکست ابزار ارزیابی (Evaluator Failure)
اما با بررسی دستی کدها، پژوهشگر متوجه شد که این «شکست‌ها» اغلب ناشی از نقص در ابزار امتیازدهی بود. ابزار ارزیابی از عبارات منظم (Regex) برای یافتن کلمه دقیق «PostgreSQL» استفاده می‌کرد.
در چندین مورد از شکست‌ها، مدل از یک متغیر محیطی به نام DATABASE_URL استفاده کرده بود. این یک الگوی کدنویسی حرفه‌ای است، اما چون کلمه «PostgreSQL» صراحتاً در رشته متنی نبود، Regex آن را به عنوان شکست علامت‌گذاری کرد. در مقابل، برخی اجراها صرفاً به این دلیل پاس شدند که در یک کامنت به پایگاه‌داده اشاره شده بود یا یک URL پیش‌فرض حاوی این کلمه بود، در حالی که Endpoint در واقع از پایگاه‌داده استفاده نمی‌کرد.
مشکلات مشابه در بررسی‌های UI نیز ظاهر شد. ارزیاب یک خروجی در حالت متوسط و سه خروجی در حالت بلند را به دلیل عدم نمایش نام فایل یا پیام وضعیت رد کرد. با این حال، بررسی دستی نشان داد که این ویژگی‌ها وجود داشتند؛ مدل صرفاً از IDهای متفاوتی برای المان‌ها استفاده کرده بود که Regex انتظارشان را نداشت. این ثابت کرد که تکیه صرف به امتیازات جدول (Leaderboard) می‌تواند منجر به نتیجه‌گیری غلط شود.
امنیت و پایداری
یک یافته غافلگیرکننده مربوط به بهداشت اعتبارنامه‌ها بود. در حالی که قانون صریح «عدم قرار دادن کلیدهای API به‌صورت Hardcode» ۱۰۰٪ رعایت شد، یک بررسی مجزا برای اعتبارنامه‌های جاسازی شده در URLهای پایگاه‌داده، ۹ مورد از ۱۵ اجرا را به عنوان خطا علامت زد.
به‌طور مشخص، بررسی اعتبارنامه در ۵ مورد از ۵ خروجی کوتاه، ۲ مورد از ۵ خروجی متوسط و ۲ مورد از ۵ خروجی بلند خطا گرفت. جالب اینجاست که خروجی‌های با بستر طولانی‌تر، احتمال بیشتری داشت که از پیکربندی‌های امن مبتنی بر محیط (Environment-based) استفاده کنند تا خروجی‌های بستر کوتاه. این نشان می‌دهد که با تکامل گفتگو، مدل ممکن است در واقع به عادت‌های حرفه‌ای‌تر گرایش پیدا کند، هرچند پژوهشگر اشاره کرد که با تنها پنج اجرا در هر وضعیت، این هنوز یک اثر قابل اتکا نیست.
در حالت بلند (Long)، دو اجرا به‌طور کلی در ذخیره داده‌ها در پایگاه‌داده شکست خوردند. در این موارد، Endpoint فایل آپلود شده را تایید کرد و پاسخ داد، اما رکوردی را ننوشت. از آنجایی که پرامپت نهایی صراحتاً تقاضای ذخیره‌سازی نکرده بود، پژوهشگر این مورد را نقض قانون به حساب نیاورد، اما آن را به عنوان تفاوتی در سبک پیاده‌سازی نسبت به تمام خروجی‌های کوتاه و متوسط (که رکوردها را ذخیره می‌کردند) یادداشت کرد.
تحلیل برای توسعه‌دهندگان
این تجربه فرض رایج مبنی بر اینکه بسترهای طولانی لزوماً باعث تخریب پیروی از دستورات می‌شوند را تغییر می‌دهد. این موضوع یک تله خطرناک در بنچمارکهای AI را برجسته می‌کند: «شکاف ارزیاب» (Evaluator Gap). وقتی ما از تطبیق ساده رشته‌ها یا حتی داوران مبتنی بر LLM برای نمره دادن به کد استفاده می‌کنیم، اغلب یک تست سخت‌گیرانه را با یک مدل شکست‌خورده اشتباه می‌گیریم.
برای توسعه‌دهنده عملی، این بدان معناست که «فراموشی» کمتر به حافظه داخلی مدل و بیشتر به ابهام در پرامپت مربوط است. اگر مدلی پیروی از یک قانون را متوقف کند، ممکن است به این دلیل باشد که بستر (Context) احتمال داخلی مدل را به سمت سبک کدنویسی متفاوتی سوق داده است، نه اینکه قانون پاک شده باشد. این موضوع در تضاد با برخی گزارش‌ها درباره شکست مدل‌های کدنویسی در رعایت محدودیت‌های منفی است که نشان می‌داد برخی دستورات «نباید» را مدل‌ها سخت‌تر می‌پذیرند.
برای جلوگیری واقعی از این افت، توسعه‌دهندگان باید از تکیه بر یک پرامپت واحد و عظیم فاصله بگیرند. در عوض، باید از معیارهای پذیرش (Acceptance Criteria) صریح و محیط‌های تست خودکار استفاده کنند که کد را اجرا می‌کنند، نه اینکه فقط آن را بخوانند.
بنچمارکهای آینده
پژوهشگر قصد دارد این مطالعه را گسترش دهد تا از یک مدل آزمایشی فراتر رود. بهبودهای پیشنهادی عبارتند از:
- گروه‌های کنترل: افزودن یک کنترل بدون محدودیت برای هر تسک تا «حفظ قانون» از «رفتار پیش‌فرض مدل» تفکیک شود. (یک اجرای غیررسمی بدون محدودیت، پیش از این منجر به تولید Flask، SQLite و camelCase JS شده بود).
- افزایش مقیاس: تست بسترهای بسیار طولانی‌تر، زیرا ۲۰ موضوع در مقایسه با جلسات واقعی توسعه هنوز کوتاه است.
- الزامات صریح: بیان دقیق اینکه چه چیزی باید در پایگاه‌داده ذخیره شود تا ذخیره‌سازی به یک معیار قابل تست تبدیل شود.
- تست استرس: معرفی دستورات متناقض در مراحل بعدی (مثلاً قانون «هرگز توکن‌های احراز هویت را لاگ نکن» و سپس درخواست برای لاگ‌های مفصل/Verbose).
- تغییر عبارت‌بندی: تست اینکه آیا جایگاه قانون (ابتدا در مقابل انتها) یا نوع بیان (مثبت در مقابل منفی) بر میزان پایبندی اثر می‌گذارد.
- ارزیابی قوی‌تر: استفاده از درخت‌های نحو انتزاعی (AST) برای تجزیه کد و اجرای Endpointها در یک محیط تست زنده.
در نهایت، این مطالعه آزمایشی تنها تغییر کوچکی در امتیازات کلی یافت و نشان داد که برخی شکست‌های ظاهری توسط خود ارزیاب ایجاد شده‌اند. این ثابت نمی‌کند که مدل‌ها هرگز فراموش نمی‌کنند، اما نشان می‌دهد که «کاهش اولویت» به آن سادگی که عموماً تصور می‌شود نیست.
گام بعدی شما
- به‌جای تکیه بر بررسی متنی خروجی‌های AI، از ابزارهای تست واحد (Unit Test) برای تایید رعایت قوانین استفاده کنید.
- در پرامپت‌های طولانی، قوانین حیاتی را در قالب یک «لیست بازبینی» (Checklist) در انتهای درخواست تکرار کنید.
- برای پروژه‌های حساس، از متغیرهای محیطی به‌جای مقادیر ثابت استفاده کنید تا مدل را به سمت استانداردهای امنیتی سوق دهید.
اما این تنها بخشی از چالش‌های ارزیابی است؛ بررسی اینکه مدل‌ها چگونه در مواجهه با دستورات متناقض تصمیم می‌گیرند، در گزارش بعدی ما منتشر خواهد شد.
گفتگو