عاملهای هوش مصنوعی که قرار است در چند جلسه یا طی زمان طولانی کار کنند، برای نگهداشتن واقعیتها، ترجیحات کاربر، سیاستها و تصمیمهای قبلی به حافظه پایدار متکیاند. پژوهش تازهای از Yi Ting Shen، Kentaroh Toyoda و Alex Leung بررسی میکند وقتی یک داده قدیمی با داده جدید جایگزین میشود، اما خود رکورد قبلی همچنان در حافظه باقی میماند، چه اتفاقی میافتد.
نویسندگان گزارش میکنند در پنج سامانه حافظهای که آزمایش کردهاند، رکوردی که دیگر معتبر شناخته شده بود ممکن است هنگام بازیابی دوباره برگردد و اگر بالاتر از نسخه جدید قرار بگیرد، روی تصمیم بعدی عامل اثر بگذارد. آزمایشها ۹ موقعیت سیاستی، ۹ مدل و ۶ روش دفاعی را در بر میگیرد. این مقاله در ۸ سپتامبر ۲۰۲۶ بهصورت نسخه اولیه در arXiv منتشر شده و هنوز نباید نتیجه آن را به همه سامانههای حافظه تعمیم داد.
نامعتبر کردن یک داده با جلوگیری از بازیابی آن یکی نیست
بسیاری از سامانههای حافظه، تاریخچه را بهجای حذف کامل نگه میدارند. ممکن است یک سیاست یا واقعیت با نسخه تازه جایگزین شود و رکورد قدیمی بهعنوان منقضی یا نامعتبر علامت بخورد، اما برای ثبت تاریخچه یا تحلیل زمانی در پایگاه باقی بماند.
این روش فقط زمانی امن است که مسیر بازیابی نیز همان وضعیت را رعایت کند. نتیجه اصلی پژوهش این است که در پیکربندیهای آزمایششده، پنج سامانه مورد بررسی بهطور پیشفرض مانع بازگشت رکورد نامعتبر نمیشدند. پژوهشگران یک سیاست قدیمی و جایگزین آن را وارد حافظه کردند و سپس سنجیدند آیا نسخه قبلی دوباره پیدا میشود و آیا مدل بر اساس آن عمل میکند. طبق گزارش مقاله، در برخی حالتها داده منسوخ از جایگزین جدید بالاتر قرار گرفته و عامل را به انتخاب نامناسب رسانده است.
مخزن آزمایشی میان دو شیوه تفاوت میگذارد. در یک حالت، قابلیت رسمی همان سامانه برای نامعتبر کردن رکورد مستقیماً استفاده میشود. در حالت دیگر، فقط متن متناقض وارد سامانه میشود و خود لایه حافظه باید تشخیص دهد کدام داده دیگر معتبر نیست. این تفکیک کمک میکند خطای استخراج اطلاعات با ضعف سیاست بازیابی اشتباه نشود.
خطر جدیتر وقتی شکل میگیرد که عامل تصمیمش را دوباره در حافظه ثبت کند
بخش مهمتر پژوهش به مرحله بعد مربوط است. اگر عامل بر اساس یک سیاست قدیمی تصمیم بگیرد و سپس نتیجه کار خود را بهعنوان یک داده تازه در حافظه ثبت کند، رکورد جدید دیگر لزوماً علامت «نامعتبر» رکورد اصلی را همراه ندارد.
در این حالت، دستور منسوخ از مسیر رفتار خود عامل به یک خاطره تازه و ظاهراً معتبر تبدیل میشود. بنابراین پالایش فقط بر اساس برچسب رکوردهای قدیمی کافی نیست. سامانه باید بتواند نشان دهد یک داده جدید از چه اطلاعات و تصمیمهای قبلی به وجود آمده است.
برای محیطهای عملیاتی، این یعنی سابقه و منشأ دادههای حافظه باید بخشی از کنترل باشد. تاریخ ثبت تازه نباید بهتنهایی نشانه اعتبار تلقی شود.
اعتبار حافظه باید در همان مسیر خواندن اعمال شود
تحلیل Aipolix این است که نامعتبر شدن یک رکورد باید در مسیر بازیابی بهصورت فنی اجرا شود، نه اینکه فقط یک ویژگی در کنار داده ذخیره شود.
اگر برنامه بتواند رکوردی را منسوخ اعلام کند، اما جستوجویی که متن عامل را میسازد همچنان آن رکورد را بدون توجه به وضعیتش برگرداند، عملاً ابطال رخ نداده است. پالایش باید پیش از رتبهبندی و پیش از ساختن زمینهای که به مدل داده میشود انجام شود و همین قاعده باید برای همه عاملها و نقشهایی که از حافظه مشترک استفاده میکنند برقرار باشد.
نویسندگان میگویند در ماتریس آزمایشی آنها، پالایش در خود لایه ذخیرهسازی تنها روش بررسیشدهای بود که نرخ خطا را به صفر رساند. آنها همچنین یک محافظ مستقل از سامانه حافظه ساختهاند که رکوردهای صریحاً نامعتبر را کنار میگذارد و میان دادههای باقیمانده تناقضها را بررسی میکند. این نتایج هنوز گزارش خود پژوهشگران است و برای تعمیم به محیطهای دیگر به بازتولید مستقل نیاز دارد.
حافظه مشترک میتواند یک داده قدیمی را به مشکل چندعاملی تبدیل کند
پژوهش آزمایشی با سه نقش اجراکننده، بازبین و برنامهریز روی یک حافظه مشترک نیز انجام شده است. فقط اجراکننده با پرسش تاریخی مهاجم روبهرو میشود و دو نقش دیگر جداگانه از همان مخزن اطلاعات میخوانند. هدف این است که مشخص شود داده منسوخ از طریق حافظه مشترک به نقشهای دیگر میرسد یا نه.
این نکته برای سامانههای چندعاملی مهم است. داشتن یک «بازبین مستقل» زمانی ارزش دارد که منبع اطلاعات او نیز کنترل مستقلی داشته باشد. اگر همه نقشها از یک حافظه آلوده تغذیه شوند، تفاوت در پرامپت یا نام نقش بهتنهایی استقلال ایجاد نمیکند.
بنابراین در طراحی چنین سامانههایی باید استقلال نقش را از استقلال شواهد جدا کرد. بازبینی واقعی زمانی شکل میگیرد که داده ورودی بازبین نیز از نظر اعتبار و منشأ بررسی شود.
کد منتشر شده امکان بررسی میدهد، اما محدودیتها باقی است
نویسندگان مخزنی با مجوز Apache-2.0 منتشر کردهاند که شامل آزمون قطعی بازیابی، ماتریس ارزیابی، آزمایش انتشار اثر در حافظه و پیادهسازی محافظ است. پنج سامانه Graphiti، Zep، mem0، LangMem و cognee در این کار بررسی شدهاند.
با این حال، مخزن توضیح میدهد که خروجی خام آزمایشها و بخشی از جزئیات سرویسهای استفادهشده منتشر نشده است. در نتیجه، برای تأیید نرخهای گزارششده باید آزمایشها دوباره اجرا شوند. مقاله نیز نسخه نخست arXiv است و در اطلاعات موجود، داوری همتا برای آن تأیید نشده است.
پس نتیجه درست این نیست که همه محصولات حافظه آسیبپذیرند. نتیجه قابل اتکا این است که هر معماری که رکوردهای منسوخ را نگه میدارد، باید اعتبار آنها را هنگام بازیابی نیز اجرا کند؛ وگرنه تصمیمهای تازه عامل میتوانند اثر داده قدیمی را پنهان و ماندگار کنند.
تیمها چه چیزی را باید در سامانه خود آزمایش کنند
یک آزمون عملی این است که یک سیاست ثبت شود، سپس با سیاست جدید جایگزین شود و بعد همه مسیرهای بازیابی عامل بررسی شوند. نسخه قدیمی نباید بتواند بر رتبهبندی، متن ورودی مدل یا انتخاب ابزار اثر بگذارد. همین آزمون باید پس از آن هم ادامه پیدا کند که عامل تصمیم حاصل از داده قدیمی را دوباره در حافظه نوشته است.
برای ممیزی نیز بهتر است علت نامعتبر شدن رکورد، رابطه آن با جایگزین، تصمیمهای مرحله بازیابی و منشأ دادههایی که از رفتار عامل ساخته شدهاند ثبت شود. بدون این زنجیره، یک تاریخ تازه میتواند منبع قدیمی و نامعتبر را پنهان کند.
حافظه پایدار عامل را در کارهای طولانی توانمندتر میکند، اما چرخه عمر اطلاعات را نیز به بخشی از امنیت سامانه تبدیل میکند. اگر دادهای قابل ابطال است، معنای ابطال باید در زمان بازیابی قابل اجرا و قابل آزمون باشد.