«ضرورت حافظه مجزا»؛ چرا افزایش توکن‌ها برای مدل‌های قابل‌اعتماد کافی نیست

اگر تصور می‌کنید با افزایش پنجرهٔ متنی به میلیون‌ها توکن، دیگر نیازی به مدیریت حافظه در عامل‌های هوش مصنوعی نیست، در اشتباهید. شواهد به‌دست‌آمده از Uteke و چندین مقاله دانشگاهی نشان می‌دهد که صرفاً تزریق حجم انبوهی از داده به پرامپت، به‌جای بهبود، منجر به پدیده‌ای به نام «پوسیدگی زمینه» (Context Rot) و افت شدید کیفیت پاسخ‌ها می‌شود. یک پنجرهٔ متنی یک میلیون توکنی، جایگزینی برای یک سیستم حافظه اختصاصی نیست.

این بحث در حالی شدت گرفته که مدل‌های جدید اکنون با پنجرهٔ زمینه (Context Window) بین ۱ تا ۱۰ میلیون توکن عرضه می‌شوند. روایت رایج در صنعت این است که حافظه‌های خارجی تنها یک راهکار موقت هستند و پنجره‌های بزرگ‌تر به‌زودی آن‌ها را منسوخ می‌کنند. اما برای متخصصان فنی، واقعیت متفاوت است: داده‌های بیشتر، اغلب خروجی‌های بدتری تولید می‌کنند. این چالش با کاهش دقت استدلال در اثر گسترش پنجره‌های زمینه که پیش‌تر بررسی کردیم، هم‌سو است.

مسئلهٔ زمینه (The Context Problem)

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت و مدیریت مدل‌های زبانی اشاره کردیم، مقیاس‌پذیری همیشه به معنای کارایی نیست. طبق تحلیل فنی منتشر شده در ۲ سپتامبر ۲۰۲۶، پدیدهٔ «گم‌شدن در میانه» (Lost-in-the-Middle) همچنان یک نقطه شکست بحرانی است. مطالعهٔ کلیدی لیو و همکاران (arXiv 2307.03172) که روی پرسش‌وپاسخ‌های چندسندی و بازیابی کلید-مقدار (Key-Value Retrieval) انجام شد، نشان داد مدل‌ها زمانی بهترین عملکرد را دارند که اطلاعات مرتبط در ابتدا یا انتهای متن باشند و در میانهٔ متن، دقت به‌شدت افت می‌کند.

شواهد تکمیلی این شکست را تایید می‌کنند:

• مبنای تئوریک: مقاله‌ای در مه ۲۰۲۶ (arXiv 2605.09213) این پروفایل بازیابی U-شکل را از یک مدل تئوریک از دینامیک‌های توجه (Attention Dynamics) استخراج کرد. این موضوع ثابت می‌کند که سوگیری موقعیتی (Position Bias) از دل ریاضیات بیرون می‌آید؛ بنابراین پنجره‌های بزرگ‌تر این سوگیری را به ارث می‌برند، نه اینکه آن را حذف کنند.
• زوال عامل‌های کدنویس: در یک مطالعهٔ جعبه‌سفید (arXiv 2607.17937)، نرخ موفقیت (Pass Rate) عامل‌های کدنویس از ۸/۱۰ در یک زمینهٔ پاک با ۱۰,۹۹۱ کاراکتر، به تنها ۳/۱۰ در زمانی که زمینه به ۲۹۹,۱۴۰ کاراکتر گسترش یافت، سقوط کرد. نکته قابل توجه این است که پر کردن زمینه با مطالب نامرتبط، به اندازه داده‌های مرتبط به مدل آسیب زد؛ این یعنی نیمی از این افت عملکرد، هیچ ارتباطی به مرتبط بودن یا نبودن داده‌ها نداشت.
• توقف زودهنگام: پژوهشی روی چهار مدل پیشرو و سه بنچمارک مختلف (arXiv 2606.29718) مستند کرد که مدل‌ها اغلب مدت‌ها پیش از رسیدن به سقف توکن‌های خود، تسلیم شده یا با اطمینان رو به کاهش پاسخ می‌دهند.

اقتصاد حافظه

فراتر از دقت، اقتصاد پنجره‌های بزرگ ناکارآمد است. هر چیزی که داخل پنجره قرار می‌گیرد، در هر فراخوانی و در هر جلسه دوباره پرداخت می‌شود. حقیقتی که در مارس گذشته ثبت شده است، در هر بار ارسال پرامپت، هزینه‌ای برابر با جمله‌ای دارد که کاربر ۱۰ ثانیه پیش گفته است. این موضوع در واقع بخشی از هزینه‌های پنهان و درجه‌دوم محدودیت‌های پنجرهٔ زمینه است که بهره‌وری عملیاتی را کاهش می‌دهد.

سیستم‌های حافظهٔ مبتنی بر بازیابی (Retrieval) این منحنی هزینه را وارونه می‌کنند؛ داده‌ها یک‌بار ذخیره شده و فقط در صورت نیاز، مجموعه‌ای کوچک از رکوردهای مرتبط فراخوانی می‌شوند. با این حال، طراحی حافظه موازنه‌های خاص خود را دارد (arXiv 2607.17545):

• رکوردهای خام (Raw Records): جزئیات بالا را حفظ می‌کنند اما بودجهٔ توکن را می‌سوزانند.
• تلفیق داده‌ها (Consolidation): فضای بیشتری را در هر توکن پوشش می‌دهند اما ریسک حذف یک حقیقت حیاتی برای پرس‌وجو (Query-critical fact) را دارند.

هر دو استراتژی بر استفاده از یک مجموعه کاری کوچک و گزینش‌شده تأکید دارند، نه یک سیلاب از داده.

حافظه در مقابل زمینه

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

برای کمی کردن این موضوع، Uteke موتور حافظهٔ خود را در محک LongMemEval-S با ۵۰۰ پرسش آزمایش کرد و به امتیاز recall_any@5 معادل ۹۸.۲٪ رسید. برای اطمینان از تکرارپذیری این اعداد، این مجموعه تست روی یک معماری CPU متفاوت مجدداً اجرا شد. ۱۰۷ مورد از ۱۰۸ پرسش، رتبه‌بندی‌های کاملاً یکسانی داشتند؛ تنها مورد استثنا یک تساوی نزدیک در رتبه‌های مجاور بود که ریشه در ترتیب جمع‌بندی اعداد اعشاری (Float Summation Order) داشت.

این تغییر دیدگاه، معیار سنجش عامل‌های هوش مصنوعی را عوض می‌کند. هدف دیگر صرفاً «نگه داشتن توکن‌های بیشتر» نیست، بلکه دستیابی به پنج توانایی تعریف شده در LongMemEval (arXiv 2410.10813) است:

• استخراج اطلاعات (Information Extraction)
• استدلال چند-جلسه‌ای (Multi-session Reasoning)
• استدلال زمانی (Temporal Reasoning)
• به‌روزرسانی دانش (Knowledge Updates)
• خودداری از پاسخ اشتباه (Abstention)

برای توسعه‌دهندگان، این یعنی پنجره‌های بزرگ برای تحلیل یک‌بارهٔ یک سند حجیم، جست‌وجوهای سوزنی (Needle-style lookups) در یک لحظه، یا استدلال روی یک سند بزرگ فعلی عالی هستند، اما به عنوان تاریخچهٔ بلندمدت برای دستیاران شکست می‌خورند. سیستم‌های حافظه زمانی ارزش خود را ثابت می‌کنند که تاریخچه طولانی باشد و حقایق در طول جلسات مختلف تغییر کنند.

در آینده منتظر پذیرش LongMemEval-V2 (مه ۲۰۲۶) باشید که ارزیابی را به این سمت می‌برد که آیا یک عامل می‌تواند در محیط خود به یک «همکار باسابقه» تبدیل شود یا خیر. عامل‌هایی که بیشترین ارزش را ایجاد می‌کنند، آن‌هایی هستند که هر جلسه را از نقطه صفر شروع نمی‌کنند.

گام بعدی شما

• اگر در حال ساخت عامل‌های Agentic هستید، به‌جای تکیه بر پنجره‌های متنی بزرگ، پیاده‌سازی یک لایه حافظهٔ بازیابی‌افزا (RAG) را اولویت دهید.
• برای ارزیابی حافظهٔ مدل خود، از معیار LongMemEval-V2 (انتشار مه ۲۰۲۶) استفاده کنید تا ببینید آیا عامل شما شبیه به یک «همکار باسابقه» رفتار می‌کند یا خیر.
• استراتژی تلفیق داده‌ها (Consolidation) را برای کاهش هزینه استنتاج در حافظه‌های بلندمدت تست کنید.

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