سه مفهوم متفاوت پشت واژهٔ حافظه
در یک دستیار پشتیبانی، کاربر شمارهٔ تجهیز را در پیام اول گفته و اکنون دربارهٔ تعمیر همان تجهیز سؤال می‌کند. برای پاسخ، سامانه ممکن است از پیام‌های جاری، خلاصهٔ جلسه یا اطلاعات ذخیره‌شدهٔ پرونده استفاده کند. این سه چیز یکسان نیستند: زمینهٔ درخواست، تاریخچهٔ برنامه و حافظهٔ ماندگار هرکدام عمر و قواعد متفاوتی دارند.
مستندات LangChain میان حافظهٔ کوتاه‌مدت در محدودهٔ گفتگو و حافظهٔ بلندمدت میان گفتگوها تفکیک می‌کند. استفاده از این تفکیک در مقاله به معنای توصیهٔ یک محصول خاص نیست. مسئلهٔ معماری این است که تیم بتواند برای هر داده توضیح دهد کجا ذخیره می‌شود، چه زمانی دوباره خوانده می‌شود و چه کسی اجازهٔ استفاده از آن را دارد.
پنجرهٔ زمینه، بایگانی دائمی نیست
پنجرهٔ زمینه ظرفیت ورودی قابل استفاده برای یک فراخوانی مدل است. اگر برنامه اطلاعاتی را از درخواست کنار بگذارد، صرف حضور آن در گفتگوی قدیمی ثابت نمی‌کند مدل در همان لحظه آن را می‌بیند. ظرفیت و سهم خروجی به مدل و تنظیمات وابسته است؛ عدد تبلیغاتی را به ظرفیت مفید سناریوی خود تبدیل نکنید.
در پروندهٔ تعمیر، بهتر است شناسهٔ تجهیز و مرحلهٔ تأییدشدهٔ کار به‌صورت دادهٔ صریح برنامه نگه‌داری شود. اگر کاربر تجهیز را عوض کرد، وضعیت باید روشن تغییر کند. اتکا به اینکه مدل در میان ده‌ها پیام متوجه تغییر شده است، جای یک انتقال وضعیت قابل بررسی را نمی‌گیرد.
متن بیشتر همیشه شاهد بهتر نیست
پژوهش Lost in the Middle در مدل‌ها و وظایف بررسی‌شده نشان داد محل قرارگیری اطلاعات می‌تواند بر کیفیت استفاده از زمینه اثر بگذارد. این نتیجه را نباید درصد خطای قطعی همهٔ مدل‌های امروز دانست. ارزش آن برای تیم محصول، طراحی آزمونی است که فقط اندازهٔ پنجره را نمی‌سنجد؛ نحوهٔ استفاده از شواهد را هم می‌سنجد.
برای آزمون پیشنهادی، بند حیاتی راهنمای تعمیر را یک بار ابتدای بسته، یک بار وسط و بار دیگر انتها قرار دهید. متن‌های مزاحم مشابه را هم اضافه کنید. ورودی، پاسخ مورد انتظار و نسخهٔ مدل ثابت بماند. اگر نتیجه به محل بند حساس شد، راه‌حل لزوماً خرید پنجرهٔ بزرگ‌تر نیست؛ انتخاب و ترتیب زمینه را نیز بررسی کنید.
خلاصه‌سازی چه چیزی را ممکن است حذف کند؟
خلاصه برای ادامهٔ کار مفید است، اما قراردادِ بی‌خطا برای حفظ تمام جزئیات نیست. در نمونهٔ تعمیر، جملهٔ «قطعه تعویض شود» اگر شرط «پس از تأیید سرپرست» را از دست بدهد، معنای عملی متفاوتی پیدا می‌کند. خلاصه باید به پیام یا سند مبنا وصل بماند و به‌جای مدرک اصلی ننشیند.
در گزارش مهندسی زمینهٔ Anthropic، خلاصه‌سازی و یادداشت ساختاریافته از روش‌های مدیریت کار طولانی‌اند. پیشنهاد تحریریه برای سناریوی ما این است که شناسه‌ها، تصمیم‌ها، محدودیت‌ها و موارد حل‌نشده را در فیلدهای جدا نگه دارید. پیش از اقدام، شرط مجوز را از وضعیت معتبر برنامه بخوانید، حتی اگر خلاصه آن را به یاد داشته باشد.
برای هر یادداشت ماندگار، منبع و دامنه تعریف کنید
ذخیرهٔ «این کاربر همیشه گزارش ماهانه می‌خواهد» ممکن است یک ترجیح مفید باشد؛ ذخیرهٔ حدس مدل دربارهٔ اختیار مالی او موضوع دیگری است. حافظهٔ پایدار باید نوع داده، صاحب، منبع، زمان ثبت و دامنهٔ استفاده داشته باشد. ترجیح مکالمه نباید به مجوز دسترسی یا حقیقت سازمانی تبدیل شود.
در یک طراحی پیشنهادی، یادداشت پرونده فقط در همان پرونده قابل بازیابی است و ترجیح نمایشی کاربر در محدودهٔ حساب او قرار می‌گیرد. دادهٔ مشترک سازمان نیز مسیر تأیید خودش را دارد. هنگام تغییر نقش یا بستن پرونده، استفاده از یادداشت باید دوباره با وضعیت معتبر سنجیده شود؛ قدیمی بودن یک داده فقط مسئلهٔ تاریخ نیست، مسئلهٔ اختیار هم هست.
برای ادامهٔ این بحث، مقالهٔ «معماری داده برای عامل‌های هوشمند سازمانی» را در دانشنامهٔ لیان بخوانید.
وقتی حافظه با سند تازه تعارض دارد چه کنیم؟
فرض کنید خلاصهٔ جلسه می‌گوید تجهیز تحت گارانتی است، اما پروندهٔ جاری پایان گارانتی را نشان می‌دهد. مدل نباید صرفاً یکی را با لحن مطمئن انتخاب کند. جریان پیشنهادی باید تعارض را آشکار کند، نسخه و تاریخ اعتبار هر منبع را نشان دهد و در صورت نیاز پاسخ را به مسئول پرونده ارجاع دهد.
برای داده‌های متغیر مانند وضعیت سفارش، مانده یا سطح دسترسی، منبع جاری سامانه را دوباره بخوانید. برای شرح گفتگوی گذشته، تاریخچه ارزش دارد. تعریف این تقدم‌ها به نوع سؤال وابسته است؛ یک قانون ساده مانند «آخرین متن همیشه درست است» هم می‌تواند پیام ناشناس تازه را بالاتر از سند مصوب قرار دهد.
حذف و دسترسی را در تمام کپی‌ها بررسی کنید
وقتی کاربر درخواست حذف یک یادداشت مجاز را ثبت می‌کند، باید معلوم باشد کدام مخزن، خلاصه، کش و نمایه در دامنهٔ آن درخواست قرار می‌گیرد. این مقاله حکم حقوقی دربارهٔ مدت نگه‌داری صادر نمی‌کند؛ تیم داده و مسئول سیاست سازمان باید دامنه و استثناها را مشخص کنند و سامانه همان سیاست را اجرا کند.
در آزمون عملی، دادهٔ ساختگی قابل تشخیص را ثبت کنید، حذف یا لغو دسترسی را انجام دهید و همان پرسش را در جلسهٔ تازه تکرار کنید. متن نباید از یک خلاصهٔ فراموش‌شده برگردد. گزارش آزمون باید مسیرهای بررسی‌شده و محدودیت‌های باقی‌مانده را نشان دهد، نه فقط پیام «عملیات موفق بود» در رابط کاربری.
چهار آزمون برای حافظهٔ قابل‌اعتماد
اول، جزئیات یک پرونده نباید وارد پروندهٔ نامرتبط شود. دوم، تغییر صریح شناسهٔ تجهیز باید ارجاع بعدی را تغییر دهد. سوم، لغو اختیار باید حتی در ادامهٔ همان گفتگو مؤثر باشد. چهارم، سند تازهٔ تأییدشده باید تعارض با خلاصهٔ قدیمی را آشکار کند. برای هر آزمون، پاسخ مجاز و رفتار ارجاع را پیشاپیش بنویسید.
زمان پاسخ و مقدار زمینهٔ مصرف‌شده را نیز ثبت کنید، اما کاهش هزینه را موفقیت کامل ندانید اگر خلاصه شرط ایمنی را حذف کرده است. تحویل مطلوب شامل نقشهٔ مخازن حافظه، قواعد خواندن و نوشتن، مالک سیاست و نمونه‌های خطاست. قابلیت به‌خاطر سپردن زمانی ارزش سازمانی دارد که فراموش‌کردن و دوباره بررسی‌کردن نیز قابل کنترل باشند.
پرسش‌های متداول
آیا مدل در جلسهٔ جدید همه‌چیز را به خاطر دارد؟
فقط اگر برنامه اطلاعاتی را دوباره در اختیارش بگذارد یا از حافظهٔ تعریف‌شده بازیابی کند. رفتار دقیق به محصول و تنظیمات آن بستگی دارد.
آیا پنجرهٔ بزرگ‌تر نیاز به RAG را حذف می‌کند؟
خیر؛ انتخاب منبع معتبر، تازگی، هزینه و دسترسی همچنان مسئله‌اند. برای هر سناریو، زمینهٔ بلند و بازیابی انتخابی را روی آزمون یکسان مقایسه کنید.
آیا حافظه می‌تواند مجوز اجرا را نگه دارد؟
مجوز را از سیاست و وضعیت جاری سامانه بگیرید. یک یادداشت گفتگو یا خلاصه نباید به‌تنهایی سند اختیار برای اقدام حساس باشد.
منابع و مطالعهٔ پژوهشی
- LangChainMemory overviewOfficial documentation
- Liu et al.Lost in the Middle: How Language Models Use Long ContextsResearch paper · 2023 · arXiv:2307.03172
- AnthropicEffective context engineering for AI agentsEngineering article
مطالعهٔ بیشتر در دانشنامهٔ لیان
- لیان داتا پارسمعماری داده برای عامل‌های هوشمند سازمانیبرای طراحی زمینهٔ معتبر، مطلب لیان نقش مالکیت، تازگی و سطح دسترسی داده را در انتخاب منابع عامل توضیح می‌دهد.