چرا ایجنتت بعد از چند ماه بدتر شده؟
هوش مصنوعیClaude Opus 5خلاصهٔ کاملتر
تو این مقاله اومده که یکی از رایجترین و کمبحثترین دلیلهای افت کیفیت ایجنتها تو محیط واقعی، ورم هارنس هست. هارنس یعنی هر چیزی که دور مدل پایه پیچیده میشه تا رفتارش رو شکل بده: پرامپت سیستمی، مثالهای few-shot، تعریف ابزارها، اسناد دانشی، گاردریلها، حافظهٔ گفتوگو و قالب خروجی. مشکل هیچکدوم از اینها به تنهایی نیست؛ مشکل انباشت بدون حاکمیته.
نویسنده میگه این ورم تقریباً همیشه محصول توسعهٔ واکنشیه: یه چیزی خراب میشه، یه قانون اضافه میکنیم؛ یه حالت خاص پیش میاد، یه دستور توضیحی میچسبونیم. ولی هیچوقت چیزی حذف نمیشه، چون حذف کردن ترسناکه. نتیجهش هارنسیه که همزمان متناقض، تکراری، بیربط به قابلیتهای حذفشده و سنگین روی پنجرهٔ کانتکسته.
نشونهها رو هم فهرست میکنه: کیفیت پایین اومده ولی مدل عوض نشده، ایجنت وسط گفتوگو خودش رو نقض میکنه، بعضی دستورها بیسروصدا نادیده گرفته میشن، تأخیر و هزینهٔ هر فراخوانی بالا رفته، عضو جدید تیم بدون کندوکاو تو تاریخچه نمیفهمه هر قانون چرا اونجاست، و ایجنت ابزارهایی رو صدا میزنه که اصلاً لازم نیست.
مکانیزم خرابی هم روشنه: تو ترنسفورمرها هر توکن سر توجه مدل با بقیه رقابت میکنه، پس پرامپت طولانی و متراکم توجه رو رقیق میکنه. وقتی دو دستور با هم تناقض دارن، مدل خطا نمیده بلکه یه انتخاب احتمالاتی میکنه که همیشه هم یکسان نیست. ابزارهای زیاد با توضیحهای مبهم و همپوشان هم مسئلهٔ انتخاب ابزار رو سختتر میکنن.
چارچوب پیشنهادی نویسنده شش اصل داره: اول قبل از حذف، نقشه بردار و از هر دستور و ابزار و سند فهرست بگیر؛ بعد قبل و بعد هر تغییر اندازهگیری کن؛ دستورهای تکراری رو ادغام کن (سه جور گفتن یه حرف، وزنش رو بیشتر نمیکنه)؛ تناقضها رو صریح حل کن، ترجیحاً با شرط گذاشتن بهجای امید بستن به حدس مدل.
دو اصل آخر به ابزارها و دانش برمیگرده: لاگها رو بکش بیرون و ببین هر ابزار واقعاً چقدر صدا زده میشه و درست صدا زده میشه یا نه؛ ابزار بیمصرف حذف، ابزار بدمصرف با توضیح بهتر اصلاح. برای اسناد دانشی هم اگه یه سند سههزار کلمهای به همهٔ فراخوانیها تزریق میشه ولی فقط بیست درصد گفتوگوها بهش نیاز دارن، جاش بازیابی پویا (RAG) هست.
روند عملی ممیزی هم مرحله به مرحله توضیح داده شده: خروجی گرفتن کل هارنس، ساختن مجموعهٔ تست با ۱۵ تا ۲۵ ورودی نماینده و چند حالت مرزی، تست پایه، برچسب زدن هر دستور با یکی از چهار حالت فعال، تکراری، متناقض یا نامعلوم، بعد ادغام و حذف، ممیزی ابزارها و اسناد، تست دوباره و در آخر مستندسازی دلیل وجود هر دستور.
نویسنده هشدار میده که این تمیزکاری هم میتونه بد انجام شه: حذف بدون تست، کنار گذاشتن ابزار کماستفادهای که حالتهای حساس رو پوشش میده، ادغام دستورهایی که ظاهرشون شبیهه ولی رفتار متفاوتی رو کد کردن، و مهمتر از همه انجام دادن دهها تغییر با هم که دیگه نمیشه فهمید کدوم باعث افت شده.
نکات کلیدی:
- ورم هارنس یه مشکل نگهداریه، نه مشکل مدل؛ تدریجی و از راه اضافههای واکنشی ساخته میشه.
- تناقض و تکرار تو دستورها واریانس خروجی رو بالا میبره و باعث نادیده گرفته شدن بعضی قانونها میشه.
- ابزار زیاد لزوماً یعنی توانایی بیشتر نیست؛ توضیح مبهم و همپوشانی، انتخاب ابزار رو خراب میکنه.
- بدون مجموعهٔ تست پایه، هر حذفی حدس و گمانه؛ تغییرها باید کوچیک و قابل ردیابی باشن.
- تزریق سند دانشی بزرگ به همهٔ فراخوانیها رو با بازیابی پویا عوض کن تا کانتکست سبک بمونه.
- برای ایجنتهای فعال، یه ممیزی سبک هر ۴ تا ۶ هفته و یه ممیزی عمیق فصلی منطقیه.
