حافظه به عنوان یک سابقه، نه یک کش
یک کش برای نرخ اصابت بهینه می‌شود. یک سابقه برای پاسخگویی بهینه می‌شود. بیشتر سیستم‌های حافظه عامل مانند کش ساخته می‌شوند و سپس از آن‌ها خواسته می‌شود مانند سابقه رفتار کنند، به همین دلیل است که در حسابرسی‌هایی که هرگز برای عبور از آن‌ها طراحی نشده بودند، شکست می‌خورند.
هر موردی که یک عامل نگه می‌دارد باید پیش از نوشته شدن چهار فیلد داشته باشد: یک منبع (کدام تعامل، سند یا فراخوانی ابزار آن را تولید کرده)، یک برچسب زمانی (زمانی که مشاهده شده، نه زمانی که جاسازی شده)، یک مالک (کدام کاربر، مستأجر یا سرویس در قبال آن پاسخگو است) و یک دلیل برای نگهداری (تصمیم آینده مشخصی که انتظار می‌رود به آن اطلاع دهد). بدون این چهار مورد، مخزن توده‌ای از بردارها بدون معنای قابل دفاع است. یک بازیابی که یک ترجیح را برمی‌گرداند در بازبینی بی‌فایده است اگر نتوانید بگویید ترجیح از کجا آمده یا آیا هنوز اعمال می‌شود.
خلاصه‌ها سریع‌ترین منشأ را از دست می‌دهند. وقتی یک رد رویدادی طولانی به یک پاراگراف فشرده می‌شود، مرحله فشرده‌سازی پیوندهای بازگشت به نوبت‌های اصلی را دور می‌ریزد. خلاصه مصنوعی است که به احتمال زیاد بازیابی می‌شود و دفاع از آن در آینده سخت‌ترین است، زیرا شواهد ادعاهایش قبلاً دور انداخته شده است. بنابراین یک خلاصه باید به عنوان یک سابقه مشتق‌شده با اشاره‌گر منشأ خودش در نظر گرفته شود، نه به عنوان جایگزینی برای ردی که از آن آمده است. اگر اشاره‌گر وجود نداشته باشد، خلاصه حافظه نیست؛ یک ادعای بدون انتساب است.
سیاست نگهداری در عمل
اولین تفکیکی که باید انجام شود بین ردهای رویدادی و حقایق پایدار است. ردهای رویدادی آنچه در طول یک اجرا اتفاق افتاده است: فراخوانی‌های ابزار، استدلال میانی، اسناد بازیابی‌شده، نتایج جزئی. حقایق پایدار آنچه باید از اجرا جان سالم به در ببرد: یک ترجیح تأییدشده، یک شناسه حل‌شده، یک سیاستی که اعمال و پذیرفته شده است. فقط دسته دوم به حافظه بلندمدت تعلق دارد. هر چیز دیگری باید به جلسه محدود شود و هنگام بسته شدن جلسه دور انداخته شود.
انقضا به طور پیش‌فرض، ارتقا با بازبینی. موارد جدید با یک زمان زندگی کوتاه و وزن اعتماد پایین وارد می‌شوند. ارتقا به وضعیت پایدار یک رویداد صریح است، نه خودکار. در عمل این به معنای یک مسیر نوشتن است که به این شکل است:
memory.write(
key="shipping.preference",
value="carrier_a",
source="interaction:4821",
observed_at="2025-01-14T09:12:00Z",
owner="tenant:acme",
reason="applied in checkout flow",
ttl="P30D",
trust="provisional",
)
فیلد trust اهرم است. موارد موقت می‌توانند برای زمینه بازیابی شوند اما نباید برای تصمیم‌گیری‌های برگشت‌ناپذیر استفاده شوند. ارتقا به confirmed نیازمند یک مشاهده دوم یا یک اقدام صریح کاربر است، و خود ارتقا ثبت می‌شود. این معامله صادقانه است: قوانین ارتقای سخت‌گیرانه نرخ به نظر رسیدن حافظه عامل را کاهش می‌دهند، زیرا موارد کمتری از میله عبور می‌کنند. جایگزین یک مخزن است که با اطمینان چیزهایی را به یاد می‌آورد که هرگز درست نبوده‌اند.
حذف باید به خلاصه‌ها و جاسازی‌های مشتق‌شده منتشر شود، نه فقط به مخزن اصلی. اینجاست که بیشتر پیاده‌سازی‌ها نشت می‌کنند. یک سابقه از مخزن کلید-مقدار حذف می‌شود، اما خلاصه‌ای که آن را نقل کرده باقی می‌ماند، و جاسازی‌ای که معنای آن را رمزگذاری می‌کند در نمایه برداری باقی می‌ماند. از دید عامل، این واقعیت هنوز حاضر است، زیرا بازیابی بر روی مصنوعات مشتق‌شده عمل می‌کند. انتشار باید یک عملیات درجه یک باشد: وقتی یک سابقه حذف می‌شود، هر خلاصه‌ای که به آن استناد می‌کند باطل می‌شود و هر جاسازی مشتق‌شده از آن حذف یا بازمحاسبه می‌شود. بدون این، حذف یک اشاره است نه یک تضمین.
ترجیحات کهنه با اطمینان به زمینه‌های جدید اعمال می‌شوند
ترجیحی که در یک زمینه مشاهده شده، سیاستی برای همه زمینه‌ها نیست. عاملی که به یاد می‌آورد کاربر پاسخ‌های کوتاه را ترجیح می‌دهد ممکن است آن ترجیح را به یک بازبینی حقوقی که کامل بودن در آن مهم است اعمال کند. شکست این نیست که حافظه اشتباه است؛ این است که حافظه محدوده ندارد. منشأ اینجا کمک می‌کند، زیرا منبع و برچسب زمانی به لایه بازیابی اجازه می‌دهد بپرسد آیا ترجیح تحت شرایط قابل مقایسه شکل گرفته است. حافظه بدون محدوده در همه جا اعمال می‌شود، و عامل دقی
راه کاهش این است که به هر واقعیت پایدار یک محدوده متصل شود: دامنه، نوع وظیفه و شرایطی که تحت آن مشاهده شده است. سپس بازیابی قبل از رتبه‌بندی بر اساس ارتباط، بر اساس محدوده فیلتر می‌کند. این فراخوانی را کاهش می‌دهد، و آن هزینه واقعی است. یک عامل با حافظه محدودشده گاهی در اعمال ترجیحی که یک انسان به درستی تعمیم می‌داد شکست می‌خورد. جایگزین، حافظه بدون محدوده، خطاهایی تولید می‌کند که تشخیص آن‌ها سخت‌تر است زیرا با اطمینان کامل عامل همراه هستند.
نشت بین مستأجران
وقتی یک فضای نام حافظه واحد به بسیاری از کاربران خدمت می‌کند، بازیابی بر اساس شباهت معنایی در نهایت داده‌های یک مستأجر را به دیگری نشان می‌دهد. این یک شکست ظریف نیست؛ یک شکست ساختاری است. جستجوی شباهت هیچ مفهومی از مستأجری ندارد مگر اینکه مستأجری قبل از جستجو اعمال شود، نه بعد از آن. فیلتر کردن نتایج پس از بازیابی کافی نیست، زیرا نمایه جاسازی ممکن است قبلاً محتوا را به مرحله رتبه‌بندی افشا کرده باشد، و زیرا فیلتری که در لایه اشتباه اعمال می‌شود به راحتی در یک بازآرایی حذف می‌شود.
مکانیزمی که کار می‌کند جداسازی فضای نام در لایه ذخیره‌سازی است، با مستأجری به عنوان بخشی از کلید نه یک محمول بر روی پرس‌وجو. هر خواندن و نوشتن به یک پارتیشن مستأجر محدود می‌شود، و خواندن‌های بین پارتیشنی به دلیل ساختار غیرممکن هستند نه به دلیل قرارداد. این برای عملیات گران‌تر است، زیرا تعداد نمایه‌ها را چند برابر می‌کند و تحلیل‌های جهانی را سخت‌تر می‌کند. این معامله است: جداسازی هزینه سادگی عملیاتی را دارد، و جایگزین هزینه درستی را.
این برای طراحی عامل چه معنایی دارد
حافظه یک ویژگی نیست که به یک عامل اضافه می‌کنید؛ یک سیاست است که اجرا می‌کنید. سیاست باید برای هر مورد نگهداری‌شده پاسخ دهد که از کجا آمده، چه کسی مالک آن است، چرا نگه داشته می‌شود و چه زمانی منقضی می‌شود. خلاصه‌ها و جاسازی‌ها سوابق مشتق‌شده هستند و تعهدات منابع خود را به ارث می‌برند. حذف تنها زمانی معنا دارد که از طریق هر شکل مشتق‌شده منتشر شود.
پیامد عملی این است که سیستم‌های حافظه باید حول حذف و بازبینی طراحی شوند، نه حول انباشت. عاملی که کمتر به یاد می‌آورد اما می‌تواند آنچه را به یاد می‌آورد توجیه کند در تولید مفیدتر است از عاملی که همه چیز را به یاد می‌آورد و هیچ چیز را نمی‌تواند توضیح دهد. رد حسابرسی سربار نیست؛ چیزی است که حافظه را به اندازه کافی قابل اعتماد می‌کند تا بر اساس آن عمل شود.