عدم تقارن در طراحی حافظه
پشته‌های حافظهٔ عامل معمولاً به همان روش موتورهای جستجو ارزیابی می‌شوند: بنچمارک‌های بازیابی، کیفیت embedding، تأخیر reranking. مسیر نوشتن توجه بسیار کمتری دریافت می‌کند. با این حال هر شکست بازیابی یک علت بالادستی دارد، و در بیشتر حوادث تولیدی که بررسی می‌کنیم، علت این است که چیزی نوشته شده که هرگز نباید ذخیره می‌شد، یا بدون فراداده‌های لازم برای تصمیم‌گیری بعدی ذخیره شده است.
بازیابی بنچمارک می‌شود چون بنچمارک کردنش آسان است. یک مجموعهٔ ثابت، یک مجموعهٔ پرس‌وجو، یک معیار رتبه‌بندی. امتیازدهی به ingestion سخت‌تر است چون درستی به زمینه بستگی دارد: همان جمله در یک نوبت یک ترجیح پایدار است و در نوبت دیگر یک اظهارنظر گذرا. بنابراین تیم‌ها ingestion را به‌صورت یک فراخوانی append نازک تحویل می‌دهند و قضاوت را به زمان بازیابی موکول می‌کنند، جایی که اطلاعات لازم برای آن قضاوت قبلاً دور ریخته شده است.
پیامدها به ترتیبی متفاوت از انتظار بیشتر تیم‌ها رخ می‌دهند. عاملی که بیش از حد به خاطر می‌سپارد، وضعیت حریم خصوصی‌اش را قبل از دقتش تخریب می‌کند. ذخیرهٔ افشای اتفاقی کاربر بلافاصله کیفیت پاسخ را تغییر نمی‌دهد؛ شعاع آسیب یک نقض بعدی، یک احضاریه، یک خروجی پشتیبانی یا یک لاگ ارائه‌دهندهٔ مدل را تغییر می‌دهد. فرسایش دقت کندتر دنبال می‌شود، چون ورودی‌های کهنه و متناقض در زمان بازیابی با هم رقابت می‌کنند.
حذف واضح‌ترین نشانه است. بیشتر ابزارهای حافظه حذف را به‌عنوان یک فکر بعدی می‌بینند — حذف یک ردیف در یک vector store، بدون تضمین اینکه embedding از یک بخش ایندکس پاک شده باشد، خلاصه‌ای که از آن ورودی مشتق شده از بین رفته باشد، یا کش پایین‌دستی باطل شده باشد. جایی که حذف پشتیبانی نمی‌شود، نگهداشت تصادفی می‌شود نه انتخابی.
یک رابط سیاست نوشتن
راه‌حل این است که مسیر نوشتن را به یک مرز سیاست تبدیل کنیم نه یک append. سه ویژگی بیشتر کار را انجام می‌دهند.
منشأ در هر نوشتن
هر ورودی حافظه باید یک رکورد منشأ داشته باشد: کدام نوبت مکالمه آن را تولید کرده، کدام فراخوانی ابزار آن را تأمین کرده، کدام رضایت کاربر آن را پوشش می‌دهد، و کدام هویت عامل آن را نوشته است. این تزئینات حسابرسی نیست. منشأ چیزی است که اجازه می‌دهد به یک درخواست حذف بعدی به‌طور دقیق پاسخ داده شود — می‌توانید ورودی‌های مشتق‌شده را پیدا کنید، نه فقط اصلی را — و اجازه می‌دهد یک ورودی کهنه وقتی شروع به تحریف تصمیم‌ها می‌کند به نوبتی که آن را معرفی کرده ردیابی شود.
یک اسکیمای حداقلی، به‌صورت یک مرحلهٔ اعتبارسنجی قبل از ماندگاری:
MemoryWrite = {
"content": str,
"provenance": {
"turn_id": str,
"tool_call_id": str | None,
"consent_ref": str | None,
"writer": str, # agent or component identity
"written_at": datetime,
},
"sensitivity": Literal["public", "internal", "personal", "restricted"],
"retention": {
"expires_at": datetime | None,
"basis": Literal["session", "consent", "contract", "indefinite"],
},
"redaction": {
"state": Literal["none", "applied", "required"],
"fields": list[str],
},
}
نوشتن‌هایی که اعتبارسنجی را رد می‌کنند در مرز رد می‌شوند. این ارزان‌ترین جای رد کردن آن‌هاست: ورودی هنوز embedding نشده، ایندکس نشده، خلاصه نشده یا تکثیر نشده است.
طبقه‌های حساسیت با نگهداشت به‌ازای هر طبقه
نگهداشت باید تابعی از طبقه باشد، نه یک پیش‌فرض جهانی. یک واقعیت عمومی استخراج‌شده از مستندات و یک جزئیات شخصی که در مکالمه داوطلبانه ارائه شده، به عمر یکسانی نیاز ندارند. تخصیص نگهداشت به‌ازای هر طبقه اجازه می‌دهد سیاست یک بار بازبینی و همه‌جا اجرا شود، نه اینکه در هر ویژگی دوباره بحث شود.
مبادله واقعی است. طبقه‌های ریزدانه تعداد تصمیم‌هایی را که یک مسیر نوشتن باید بگیرد افزایش می‌دهند، و هر تصمیم اضافی جایی است که یک عامل می‌تواند اشتباه کند. یک پیش‌فرض محافظه‌کارانه — نگهداشت کوتاه‌تر، حساسیت بالاتر — مواجهه را کاهش می‌دهد اما همچنین توانایی عامل برای یادآوری زمینه‌ای را که کاربران انتظار دارند به خاطر بسپارد کاهش می‌دهد. هیچ تنظیمی از این تنش اجتناب نمی‌کند؛ نکته این است که تنش را صریح و قابل بازبینی کنیم نه ضمنی در یک فراخوانی append.
حذف اطلاعات حساس و انقضا در اسکیما
حذف اطلاعات حساس و انقضا معمولاً به‌صورت کارهای دوره‌ای که انبار را جارو می‌کنند پیاده‌سازی می‌شوند. جارو کردن برای حافظه مناسب نیست چون گذشته‌نگر است: ورودی وجود دارد، خوانده شده، ممکن است خلاصه شده باشد، و ممکن است قبل از اجرای جارو بر یک تصمیم تأثیر گذاشته باشد. انتقال هر دو به داخل
به‌طور مشخص، انقضا می‌تواند یک محمول باشد که در زمان خواندن ارزیابی می‌شود و یک محرک فشرده‌سازی در زمان نوشتن، بنابراین یک ورودی منقضی هرگز بازگردانده نمی‌شود و در پاس بعدی بازپس‌گیری می‌شود. حذف اطلاعات حساس می‌تواند یک گذار وضعیت باشد که محتوای ذخیره‌شده را بازنویسی می‌کند و خلاصه‌های مشتق‌شدهٔ کلیددار با شناسهٔ ورودی را باطل می‌کند. هیچ‌کدام به یک سیستم جداگانه نیاز ندارند؛ هر دو نیاز دارند که اسکیما آن‌ها را پیش‌بینی کرده باشد.
ارزیابی صادقانهٔ حافظه
ارزیابی حافظه باید ویژگی‌هایی را اندازه بگیرد که سیاست نوشتن ادعا می‌کند فراهم می‌کند.
دقت بازیابی، نه حجم. یک سیستم حافظه که زمینهٔ بیشتری برمی‌گرداند بهتر نیست؛ بزرگ‌تر است. کسری از ورودی‌های بازیابی‌شده که به تصمیم مربوط بودند را اندازه بگیرید، و کسری از تصمیم‌هایی که اگر یک ورودی بازیابی‌شده حذف شود تغییر می‌کردند. معیارهای حجم به بیش‌به‌خاطرسپاری پاداش می‌دهند، که همان حالت شکستی است که هدف قرار گرفته.
رفتار پس از حذف، نه فقط پس از درج. مجموعه‌های تست برای حافظه معمولاً درج می‌کنند، پرس‌وجو می‌کنند، تأیید می‌کنند. به‌ندرت حذف می‌کنند، سپس پرس‌وجو می‌کنند، سپس تأیید می‌کنند که محتوای حذف‌شده از بازیابی مستقیم، از خلاصه‌ها و از هر زمینهٔ کش‌شده غایب است. یک تست حذف که فقط انبار اصلی را بررسی می‌کند قبول می‌شود در حالی که مصنوعات مشتق‌شده محتوا را نگه می‌دارند.
تأثیر ورودی‌های کهنه. ردیابی کنید که آیا ورودی‌های گذشته از عمر مفیدشان هنوز بر خروجی‌های فعلی تأثیر می‌گذارند. یک مکانیسم عملی یک کاوش خلاف واقع است: نمونه‌ای از تصمیم‌ها را با ورودی‌های منقضی یا کم‌اطمینان پوشانده‌شده دوباره اجرا کنید و مقایسه کنید. واگرایی نشان می‌دهد که نگهداشت کاری را انجام می‌دهد که تازگی باید انجام دهد.
این تست‌ها کندتر و کم‌رضایت‌تر از یک بنچمارک بازیابی هستند، و یافته‌هایی تولید می‌کنند که نیازمند تغییر سیاست هستند نه تغییر مدل. این همان مبادلهٔ صادقانه است: کار سیاست نوشتن بالادستی، مقطعی و سخت‌تر برای نسبت دادن به یک معیار واحد است، که دقیقاً همان دلیلی است که معمولاً تا وقتی یک حادثه آن را تحمیل کند به تعویق می‌افتد.
این در عمل چه چیزی را تغییر می‌دهد
برخورد با حافظه به‌عنوان یک مسئلهٔ سیاست نوشتن، جایی که تلاش مهندسی صرف می‌شود را جابه‌جا می‌کند. مرز ingestion به یک رابط اعتبارسنجی‌شده با منشأ، حساسیت و نگهداشت به‌عنوان فیلدهای درجه‌یک تبدیل می‌شود. حذف به یک عملیات پشتیبانی‌شده با معناشناسی تعریف‌شده برای داده‌های مشتق‌شده تبدیل می‌شود. ارزیابی کل چرخهٔ عمر را پوشش می‌دهد نه فقط مسیر خواندن را.
هیچ‌کدام از این‌ها به یک معماری حافظهٔ جدید نیاز ندارد. نیاز دارد که در لحظهٔ ذخیره تصمیم بگیریم چه چیزی ذخیره می‌شود، به نمایندگی از چه کسی، برای چه مدت، و چگونه حذف خواهد شد. عامل‌هایی که خوب به خاطر می‌سپارند آن‌هایی نیستند که بزرگ‌ترین انبارها را دارند؛ آن‌هایی هستند که انبارهایشان فقط شامل ورودی‌هایی است که سیستم می‌تواند توجیه کند نگه داشتنشان را.