سیستم‌های نظارتی در برابر حافظهٔ مدل در مدیریت دستورات عامل‌ها

تصور کنید ساعت‌ها وقت صرف طراحی معماری یک پروژه کرده‌اید و قوانین سخت‌گیرانه‌ای برای عامل (Agent) خود تعریف کرده‌اید، اما می‌بینید مدل تنها پس از سی دقیقه، حیاتی‌ترین محدودیت‌ها را نادیده می‌گیرد. شما ممکن است یک جلسه را با تعیین پیش‌فرض‌ها شروع کنید، سؤالات پژوهشی بپرسید و معماری را در فایل‌های markdown یا لیست‌های TODO با دستورالعمل‌های واضح و موجز شرح دهید. سپس، شروع به ساخت اولین مؤلفه می‌کنید. اما همواره، چند ساعت بعد، عامل تصمیمی می‌گیرد که شما دوست ندارید. او ممکن است ابتکار عمل عجیبی به خرج دهد و کلاسی ایجاد کند که شما نخواسته‌اید، یا بدون هیچ بازبینی کدی، همه چیز را روی ارائه‌دهنده ابری شما مستقر کند. او صرفاً سعی می‌کند مفید باشد. شما او را توبیخ می‌کنید و می‌گویید دیگر هرگز این کار را نکند. چندین چرخه بعد، او دوباره لغزش می‌کند. شما پافشاری می‌کنید: «دیگر هرگز و تحت هیچ شرایطی این کار را نکن» و تقاضا می‌کنید این دستور را در ذهنش حک کند. و بعد، او دوباره لغزش می‌کند. و باز هم تکرار می‌شود.

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

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تکیه بر لایه‌های داخلی مدل برای حفظ قوانین، همواره با ریسک شکست همراه است. این چالش‌ها در ابزارهای تخصصی‌تر نیز دیده می‌شود؛ برای مثال، پروژه Cortex برای مقابله با فراموشی در عامل‌های کدنویسی از SQLite برای بازسازی حافظه محلی استفاده کرد. طبق گزارشی که در ۱۰ اوت ۲۰۲۶ در dev.to منتشر شد، سیستم‌های فعلی با سه نقص اصلی در حافظه دست‌وپنجه نرم می‌کنند:

• مشکل فراموشی: سیستم‌های متنی اغلب نمی‌توانند همان متنی را که خودشان نوشته‌اند به یاد آورند. اگر پس از چند دور فشرده‌سازی متن از مدل بپرسید درباره موضوع خاصی چه گفته‌اید، احتمالاً پاسخی ساختگی می‌دهد. به طور پیش‌فرض، این سیستم‌ها حتی زمان فعلی را نمی‌دانند؛ اگر گفتگویی را از ماه گذشته از سر بگیرید، عامل به سادگی فرض می‌کند که امروز روز بعد از آن است. اگرچه اندازه پنجره متنی و بازنویسی عوامل مؤثری هستند، اما ذخیره و جست‌وجوی متن باید امری ساده باشد.
• تغییر عقیده: در گفتگوهای طولانی، وقتی بستر گم می‌شود و متن در حین فشرده‌سازی خلاصه می‌گردد، مشکل ایجاد می‌شود. با این حال، ما باید بتوانیم آنچه گفته شده و ترتیب آن را ردیابی کنیم. اگر هدفی در میانه گفتگو تغییر کند یا دانش جدید جایگزین مفروضات قدیمی شود، سیستم باید بتواند پرامپت‌هایی با کلمات مشابه را بیابد و آن‌ها را جایگزین کند. اگر کاربر ابتدا X را بگوید و سپس آن را به Y تغییر دهد، سیستم باید این تضادها را با بازنویسی یا جایگزینی دستور قدیمی با جدید حل کند.
• عدم تشخیص اهمیت: عامل‌ها نمی‌توانند تفاوت بین یک نظر گذرا و یک محدودیت سخت را بفهمند. «مرتبط بودن» با «تازگی» یا «بازیابی بر اساس شباهت» یکی نیست. بخش زیادی از ارتباطات انسانی ضمنی است و به جای بیان صریح، در لایه‌های زیرین است، که این موضوع یافتن راهکارهای سازگار را دشوار می‌کند. کاربران اغلب خود را در حال تکرار دستورات با ناامیدی مطلق و زبان تند می‌بینند، اما عامل نیم ساعت بعد آن‌ها را نادیده می‌گیرد. مضحک است که فرض کنیم چنین سیگنال‌های شدیدی مهم نیستند.

برای حل این بحران، نویسنده مقاله پیشنهاد می‌کند از تکیه بر «توجه» (Attention) داخلی مدل دست برداریم و به سمت یک سیستم «ترغیب» قطعی حرکت کنیم. در این معماری، به‌جای امید به حافظه مدل، باید پیش از تولید پاسخ، بستر (Context) مرتبط به‌صورت صریح استخراج و به مدل تزریق شود. عامل باید در هر پاسخ یا اقدام، دسترسی به‌روزی به بستر مربوط به ثوابت یا ترجیحات قبلاً بیان شده داشته باشد.

استراتژی‌های پیشنهادی برای تقویت بستر عبارت‌اند از:

• بازیابی دوگانه: ذخیره پرامپت‌ها هم در پایگاه‌داده برداری (Vector Database) — مثل کارت معرفی عددی برای هر واژه که همسایگانش را می‌شناساند — برای جست‌وجوی معنایی، و هم در یک ذخیره‌ساز متنی (Document Store) برای جست‌وجوی دقیق و واژه-به-واژه. این کار با فناوری فعلی تریویال و نسبتاً ارزان است.
• بازنویسی پرس‌وجو: سیستم برای یافتن بستر دقیق‌تر، سؤال کاربر را بازنویسی می‌کند تا بتواند اطلاعات قدیمی‌تر را از میان هزاران توکن بیرون بکشد. برای مثال، اگر کاربر بپرسد «دو هفته پیش درباره X چه گفتم؟»، سیستم X را بازنویسی کرده، بر اساس رشته گفتگو و بازه زمانی فیلتر می‌کند و هم بردارها و هم متن مکتوب را برای افزودن به بستر بازیابی می‌کند.
• حل فعال تضادها: سیستم نباید منتظر بماند تا مدل تصمیم بگیرد چه زمانی از API استفاده کند یا بستر را بازیابی کند. برای جلوگیری از تغذیه مدل با اطلاعات متناقض، سیستم باید تغییرات در اظهارات کاربر را شناسایی کرده و پرامپت‌های قدیمی را در تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب را باز می‌کند — با نسخه‌های به‌روز جایگزین کند.
• تشخیص ثوابت: با استفاده از جست‌وجوی شباهت برای تشخیص زمان‌هایی که کاربر در حال تکرار حرف‌های خود است و شناسایی استفاده از زبان تند، سیستم می‌تواند به‌طور خودکار ثوابت، ترجیحات شدید و اقدامات ممنوعه را شناسایی کند.

حتی با بازیابی کامل، مدل‌ها گاهی «می‌دانند اما تخلف می‌کنند»؛ یعنی می‌توانند یک قانون را بازگو کنند و بلافاصله آن را بشکنند. یک دیوار متنی که شامل همه چیز در پنجره فعلی و خلاصه‌ای از موارد قبلی باشد، اغلب جزئیات حیاتی را نادیده می‌گیرد. برای مقابله با این وضعیت، یک خط لوله «توصیف-سپس-مقایسه» پیشنهاد شده است:

۱. توصیف: یک فراخوانی Meta-LLM، اقدام مورد نظر عامل را به صورت شخص سوم توصیف می‌کند. مثلاً: «عامل در پاسخ به کاربر، به او گفت که موضوع را در اینترنت جست‌وجو کند و با پاسخ بازگردد».
۲. مقایسه: این توصیف با یک ثابت ذخیره شده مقایسه می‌شود، مانند: «به کاربر نگو که چیزها را جست‌وجو کند؛ خودت این کار را انجام بده. تو ابزارهای دسترسی به اینترنت را داری».
۳. تأیید: سپس تضاد مورد قضاوت قرار می‌گیرد. این کار می‌تواند با استفاده از استنتاج زبان طبیعی (NLI) انجام شود، جایی که یک پیش‌فرض («به کاربر نگو جست‌وجو کند») و یک فرضیه («عامل به کاربر گفت جست‌وجو کند») به عنوان استلزام، تضاد یا خنثی برچسب می‌خورند. مدل‌های کوچک‌تر و سریع‌تری مثل DeBERTa می‌توانند در این تشخیص تضاد تخصص پیدا کنند.

در مورد اقدامات ساختاریافته مثل فراخوانی API، موضوع ساده‌تر است. یک فراخوانی ابزار، داده‌ای ساختاریافته (نام تابع و پارامترها) است و نه متنی. یک فراخوانی مانند deploy(target="prod", skip_review=true) را می‌توان از طریق یک جست‌وجوی مستقیم در سیاست‌ها، در برابر قانون سخت «هرگز بدون بازبینی مستقر نکن» بررسی کرد. این فرآیند به هیچ قضاوت LLM نیاز ندارد و بسیار قابل‌اعتمادتر از یک پرامپت تک‌مرحله‌ای «آیا این قانون را نقض می‌کند» است.

واقعیت‌های آماری نشان می‌دهند که این مسیر دشوار است. محک HaluMem ثابت می‌کند سیستم‌های حافظه در مراحل استخراج و به‌روزرسانی داده، دچار توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که وجود ندارد — می‌شوند و این توهمات در مراحل بعدی به پاسخ‌های غلط تبدیل می‌شوند. همچنین گزارش MemStrata نشان می‌دهد جست‌وجوی ساده بر اساس شباهت برداری برای تشخیص تضادها تقریباً بی‌فایده است و مقدار AUROC کسینوسی آن تنها ۰.۵۹ است؛ حقایق متناقض اغلب شبیه‌تر از بازنویسی‌های واقعی به متن اصلی به نظر می‌رسند.

سایر محک‌های کلیدی عبارت‌اند از:

• LoCoMo: بررسی یادآوری عامل در گفتگوهای بسیار طولانی که تا ۳۵ جلسه و هزاران نوبت گفتگو را در بر می‌گیرد. یک حسابرسی بعدی باگی را در اسکریپت ارزیابی آن یافت که در آن سیستم‌هایی که به‌درستی از پاسخ دادن امتناع کرده بودند، مشابه سیستم‌هایی که پاسخ‌های ساختگی می‌دادند امتیاز گرفته بودند.
• LongMemEval: ابزاری که به‌طور مستقل حسابرسی شده و به عنوان مکمل LoCoMo برای بررسی متقاطع حافظه بلندمدت استفاده می‌شود.
• TOKI: حل تضاد حافظه را به عنوان یک مسئله کنترل هم‌زمانی فرموله می‌کند و روش‌هایی مانند «آخرین نویسنده برنده است» (last-writer-wins) و ادغام وزنی بر اساس شواهد را تحلیل می‌کند.
• Mem0: معماری تولیدی که از تشخیص تضاد صریح در زمان نوشتن استفاده می‌کند و نمرات ۹۲.۵ در LoCoMo و ۹۴.۴ در LongMemEval را گزارش کرده، در حالی که تنها یک‌سوم توکن‌های روش‌های بستر-کامل را مصرف می‌کند.
• TRUSTMEM: از یک مدل تأییدکننده منجمد و مجزا برای امتیازدهی به به‌روزرسانی‌های حافظه بر اساس پوشش و وفاداری استفاده می‌کند، به‌جای آنکه به مدل نویسنده اعتماد کند.

علاوه بر این، محک CompliBench فاش کرد که حتی پیشرفته‌ترین مدل‌های داور در تشخیص نقض سیاست‌ها در گفتگوهای چندمرحله‌ای ضعیف هستند و اغلب تخلفات واقعی را شناسایی نمی‌کنند در حالی که نوبت‌های مطابق با قانون را به‌اشتباه پرچم‌گذاری می‌کنند. این موضوع با پژوهشی تأیید می‌شود که نشان می‌دهد مدل‌ها می‌توانند یک محدودیت را به‌درستی بازگو کنند و در همان پاسخ آن را نقض کنند؛ نرخ تخلف در هفت مدل مختلف بین ۸ تا ۹۹ درصد متغیر است.

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

برای توسعه‌دهندگان، این یعنی عصر مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن — در حال تبدیل شدن به عصر «معماری عامل» است. هدف دیگر یافتن کلمات جادویی نیست، بلکه ساخت سیستمی است که بداند کاربر راننده است و هوش مصنوعی تنها یک ابزار. در این مسیر، استفاده از کتابخانه‌هایی مانند engineering-docs برای خودکارسازی مستندات فنی با مهارت‌های تخصصی می‌تواند به ساختارمند کردن ورودی‌های عامل کمک کند.

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

گام بعدی شما

• نقاط ضعف عامل‌های خود را تحلیل کنید و ببینید در چه مواردی بیشترین «لغزش» را دارند.
• برای حیاتی‌ترین قوانین پروژه، یک لایه بررسی خارجی (External Check) ساده پیاده‌سازی کنید.
• به‌جای افزایش طول پرامپت، روی استراتژی‌های بازیابی دوگانه برای ثوابت پروژه تمرکز کنید.

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