چرا دستورات سخت‌گیرانه‌تر منجر به پاسخ‌های ضعیف‌تر می‌شود؟

تصور کنید ابزاری برای بهینه‌سازی پرامپت دارید که لحنی بسیار منضبط دارد، اما در عمل عملکرد مدل شما را تخریب می‌کند. این یافته‌ی متناقض، حاصل آزمایش‌های میدانی نسخه ۰.۳.۰ از AgentSelfEdit است؛ یک ابزار جانبی متن‌باز که برای بازنویسی پرامپت سیستمی (System Prompt) خود بر اساس بازخوردهای اجرایی طراحی شده است. این سیستم با استفاده از آزمون‌های A/B، ویرایش‌ها را بررسی کرده و تنها گزینه‌هایی را ترویج می‌کند که برتری آماری آن‌ها ثابت شده باشد. کد این پروژه در گیت‌هاب (github.com/deghosal-2026/agent-self-edit/tree/v0.3.0) در دسترس است.

بسیاری از توسعه‌دهندگان تصور می‌کنند اگر یک پرامپت حرفه‌ای‌تر یا سخت‌گیرانه‌تر به نظر برسد، خروجی مدل نیز بهبود می‌یابد. اما طبق گزارش تست‌های میدانی نسخه ۰.۳.۰، شکاف خطرناکی میان «ظاهر» یک پرامپت برای انسان و «عملکرد» واقعی آن در محیط عملیاتی وجود دارد. این موضوع به‌ویژه در سیستم‌هایی صادق است که سعی می‌کنند بدون جست‌وجوی گسترده در فضای مسئله، خودشان را اصلاح کنند.

این وضعیت شبیه مدیری است که هر بار اشتباهی رخ می‌دهد، به کارمندش می‌گوید «حرفه‌ای‌تر باش»، بدون اینکه بررسی کند آیا خودِ فرآیند کاری ایراد دارد یا خیر. در این حالت، کارمند مودبانه‌تر صحبت می‌کند، اما خطاها باقی می‌مانند. بسیاری از بهینه‌سازهای هوش مصنوعی دقیقاً همین رفتار را دارند. این ناتوانی در تشخیص ریشه خطا، یادآور گزارشی است که نشان داد بیش از ۸۰ درصد عامل‌های هوش مصنوعی با وجود شناسایی خطاها، همچنان خروجی‌های معیوب را ارسال می‌کنند.

همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تکیه بر تغییرات سطحی بدون درک ساختاری، اغلب منجر به نتایج غیرقابل‌پیش‌بینی می‌شود.

زمینه: فراتر از طبقه‌بندی

برای مدتی، توسعه‌دهنده این ابزار بهانه‌ای داشت: شاید طبقه‌بندی (Classification) — که شبیه به دسته‌بندی سریع نامه‌ها در یک اداره است — محیط مناسبی برای قضاوت نباشد. طبقه‌بندی سخت‌گیرانه است و نمرات بی‌رحمانه‌ای دارد، زیرا نیازمند برچسب‌های دقیق است و هیچ تخفیفی در امتیازدهی نمی‌دهد. همین ویژگی باعث می‌شود مدل‌های زبانی در این محیط شکننده به نظر برسند.

برای بررسی این فرضیه، نسخه ۰.۳.۰ را به فراتر از طبقه‌بندی بردند. توسعه‌دهنده «حلقه‌های تست ارزان‌قیمت» (reduced-cost cheap-smoke loops) را روی استخراج داده، تولید محتوا و مجموعه‌های ترکیبی اجرا کرد. این‌ها تست‌های میدانی کامل و چند-تکراری نبودند، بلکه نمونه‌های کوچکی بودند که برای پاسخ به یک سؤال خاص طراحی شده بودند: آیا ضعف تحلیل‌گر مختص طبقه‌بندی است یا یک الگوی کلی است که در همه جا تکرار می‌شود؟

الگوی شکست در حوزه‌های مختلف

نتایج نشان داد که این ضعف تعمیم‌پذیر است. در چهار حوزه مختلف، یک ساختار تکرار شد: تحلیل‌گر یک مشکل محلی احتمالی را می‌دید، یک تغییر جزئی در کلمات پیشنهاد می‌داد و اگرچه گاهی کمک می‌کرد، اما معمولاً کافی نبود یا باعث اصلاح بیش از حد (Over-correction) می‌شد.

• طبقه‌بندی: بهینه‌ساز روی بازنویسی مرزهای فوریت (urgency-boundary) تمرکز کرد.
• استخراج: سیستم ویرایش‌های بسیار کوچکی در نام‌گذاری فیلدها، رعایت قراردادهای حروف کوچک (lowercase conventions) و ثبات در فرمت خروجی‌های مختصر پیشنهاد داد.
• تولید: تحلیل‌گر انضباط سخت‌گیرانه‌تر در خروجی، پیروی دقیق‌تر از ساختار و پرهیز از محتوای کلیشه‌ای را پیشنهاد کرد.
• حوزه ترکیبی: فرآیند با توصیه‌های کلی درباره شفافیت و ایجاز شروع شد.

در هر مورد، بهینه‌ساز یک مشکل محلی را شناسایی کرد و آن را با یک قانون لفظی ساده وصله زد. این ثابت کرد که ما با چهار باگ مختلف روبرو نیستیم، بلکه یک الگوی شکست واحد است که لباس‌های متفاوتی به تن دارد.

تله‌ی تولید محتوا

وظایف تولید محتوا تکان‌دهنده‌ترین درس را به توسعه‌دهنده داد و ضربه سختی به غرور او زد. بهینه‌ساز ویرایش‌هایی پیشنهاد کرد که دقیقاً شبیه توصیه‌های استاندارد مهندسی پرامپت (Prompt Engineering) — یعنی هنر سؤال درست پرسیدن، مثل کسی که می‌داند چطور از یک مشاور باتجربه بهترین جواب را بگیرد — بود؛ همان توصیه‌هایی که مهندسان پرامپت مدام به یکدیگر می‌دهند.

با این حال، داده‌های واقعی از اجرای بخش تولید ناامیدکننده بود:

• تکرار اول: ۱ مورد بهبود، ۷ مورد پسرفت.
• تکرار دوم: هیچ پیشنهادی ارائه نشد.
• تکرار سوم: ۱ مورد بهبود، ۲ مورد پسرفت.

این نتایج به‌وضوح نشان داد که یک ویرایش می‌تواند منضبط‌تر به نظر برسد اما مدل را ضعیف‌تر کند. پرامپت فشرده‌تر شد و دستیار مطیع‌تر گشت، اما نتایج نهایی «زشت‌تر» شدند. بنابراین، «درست به نظر رسیدن» معیار بی‌فایده‌ای برای ویرایش پرامپت است.

نتایج استخراج و حوزه‌های ترکیبی

در بخش استخراج داده، نتایج در ابتدا منطقی به نظر می‌رسیدند، تا حدی که تقریباً خسته‌کننده بودند. الگوی مشاهده شده به این شکل بود:

• تکرار اول: ۰ مورد بهبود، ۰ مورد پسرفت.
• تکرار دوم: ۱ مورد بهبود (اندازه اثر = ۰.۰۴۵۵).
• تکرار سوم: ۱ مورد بهبود، ۲ مورد پسرفت.

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

اجراهای حوزه ترکیبی تنها نقطه امید بود، زیرا جالب‌ترین اجرای غیر-طبقه‌بندی را ارائه داد. الگو به این شکل بود:

• تکرار اول: ۰ مورد بهبود، ۰ مورد پسرفت.
• تکرار دوم: ۰ مورد بهبود، ۰ مورد پسرفت.
• تکرار سوم: ۲ مورد بهبود، ۰ مورد پسرفت (اندازه اثر = inf، p = ۰.۴۶).

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

مسئله‌ی عرض جست‌وجو

این شواهد نشان می‌دهد مشکل از اندازه مدل یا داده‌ها نیست، بلکه مسئله «جست‌وجوی کم‌عمق» (shallow search) است. تحلیل‌گر تصادفی عمل نمی‌کند و الگوهای شکست را می‌بیند، اما توانایی فرار از اولین توضیح بدیهی را ندارد. این موضوع تأییدی بر این است که افزایش پارامترهای مدل لزوماً به معنای رفع خطاهای ساختاری در برنامه‌ریزی AI نیست و نیاز به رویکردهای اعتبارسنجی قطعی دارد.

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

برای توسعه‌دهندگانی که سیستم‌های خود-اصلاح‌گر می‌سازند، این یک هشدار است. اگر یک بهینه‌ساز مدام ویرایش‌های «منطقی» مشابهی را در کارهای مختلف تکرار می‌کند، باگ در عادتِ بهینه‌ساز است، نه در داده‌ها. عادت این است: دیدن یک خطای محلی و وصله زدن آن با یک قانون لفظی.

این تغییر در درک ما، معیار مهندسی پرامپت را عوض می‌کند. مرز بعدی برای بهبود عامل‌محور، مدل‌های بزرگ‌تر یا تکرارهای بیشتر نیست، بلکه افزایش «عرض جست‌وجو» است. تحلیل‌گر باید در فرار از اولین توضیح بدیهی، مهارت یابد.

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

گام بعدی شما

• پرامپت‌های بهینه‌شده توسط AI را با معیارهای کمی (Quantitative) بسنجید، نه با حس «حرفه‌ای بودن».
• در صورت تکرار الگوهای ویرایشی مشابه در تسک‌های مختلف، استراتژی جست‌وجوی بهینه‌ساز را تغییر دهید.
• برای شناسایی خطاهای ناشی از سخت‌گیرانه کردن پرامپت، از تسک‌های تولید محتوا (Generation) به عنوان محک استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.