چرا تکیه بر تاریخچهٔ گفتگو در حافظه‌ی عامل‌های هوش مصنوعی شکست می‌خورد؟

اگر عامل هوش مصنوعی شما شهری را که کاربر دو مرحله پیش گفته است فراموش می‌کند، شما با مشکل حافظه روبه‌رو نیستید، بلکه با یک شکاف استدلالی مواجهید. طبق بررسی‌های فنی منتشرشده در ۷ ژوئن ۲۰۲۶ درباره‌ی سامانه‌های حافظه در لنگ‌گراف (LangGraph)، ریختن ساده‌ی تاریخچهٔ چت در پرامپت، بدوی‌ترین و اغلب ناکارآمدترین روش مدیریت حافظه است.

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

معماری حافظه سه‌لایه

برای ساخت یک سیستم مقاوم، توسعه‌دهندگان باید رویکردی لایه‌بندی شده را پیاده کنند:

• حافظه کوتاه‌مدت: تداوم درون‌جلسه با استفاده از ابزارهایی مثل MemorySaver برای پرسش‌وپاسخ‌های چندمرحله‌ای.
• حافظه بلندمدت: شخصی‌سازی بین‌جلسه‌ای از طریق ذخیره‌سازهای کلید-مقدار (KV stores) پایدار یا پایگاه‌داده‌های برداری.
• فشرده‌سازی: یک نگهبان توکن در طول جلسه که تاریخچه‌های طولانی را با خلاصه‌ها جایگزین می‌کند تا عملکرد مدل حفظ شود.

حافظه کوتاه‌مدت و شکاف استدلالی

حافظه کوتاه‌مدت بر تداوم درون‌جلسه تمرکز دارد. با استفاده از MemorySaver در لنگ‌گراف، توسعه‌دهندگان می‌توانند تاریخچه گفتگو را به یک thread_id خاص متصل کنند. این کار تضمین می‌کند که وقتی کاربر به گفتگو بازمی‌گردد، عامل به‌طور خودکار پیام‌های قبلی را بازیابی کرده و آن‌ها را به فراخوانی‌های بعدی تزریق کند.

با این حال، یافته‌های حیاتی گزارش ۷ ژوئن نشان می‌دهد که زیرساخت با هوشمندی یکی نیست. در یک آزمون بنچمارک، مدل GLM-4-Flash نتوانست جمله‌ی کاربر («من در پکن زندگی می‌کنم») را به سؤال بعدی («هوای جایی که زندگی می‌کنم چطور است؟») متصل کند، در حالی که MemorySaver تاریخچه را به‌درستی منتقل کرده بود. این بنچمارک نشان داد که Thread A (با تاریخچه) و Thread B (بدون بافتار) پاسخ‌های یکسانی دادند: هر دو از کاربر خواستند نام شهرش را بگوید و هیچ‌کدام از ابزار هواشناسی استفاده نکردند.

این موضوع ثابت می‌کند حافظه کوتاه‌مدت دو لایه دارد:

• لایه زیرساختی: تضمین حضور تاریخچه (که توسط MemorySaver مدیریت می‌شود). ✓
• لایه مدل: توانایی مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — برای استخراج و استفاده از آن بافتار ضمنی. ←

در حالی که مدل‌های ضعیف‌تر ممکن است به پرامپت‌های صریح نیاز داشته باشند (مثلاً: «هوای پکن چطور است؟»)، مدل‌های سطح بالایی مثل GPT-4 یا Claude معمولاً این پیوندهای ضمنی را مدیریت کرده و مستقیماً ابزار را بدون کمک اضافی فراخوانی می‌کنند.

حافظه بلندمدت: قدرت حقایق صریح

برای شخصی‌سازی بین‌جلسه‌ای، اتکا به تاریخچه ناکارآمد است. رویکرد برتر، ایجاد یک «ذخیره‌ساز حقایق» (Fact Store) است؛ جایی که مدل داده‌های کلیدی را از گفتگو استخراج کرده، به‌صورت پایدار ذخیره می‌کند و در جلسه بعد آن‌ها را مستقیماً به پرامپت سیستم تزریق می‌کند.

در یک گردش‌کار نمایش‌داده‌شده، عاملی یک گفتگو در جلسه اول (Session 1) را پردازش کرد که در آن کاربر گفت: «من آلیس هستم. من در شانگهای هستم و تیمم از WonderBot Pro استفاده می‌کند. ما عمدتاً از API برای پردازش داده‌ها استفاده می‌کنیم — حدود ۵۰,۰۰۰ فراخوانی در ماه». سیستم از یک تابع خاص به نام extract_facts برای تبدیل این متن بدون ساختار به یک شیء JSON استفاده کرد: {'name': 'alice', 'city': 'shanghai', 'team': 'wonderbot pro', 'api_calls': '50000'}.

در یک جلسه کاملاً جدید (Session 2)، این حقایق بارگذاری شدند و به‌صورت جفت‌های کلید-مقدار صریح در پرامپت سیستم تزریق شدند: Known facts about this user: name=alice; city=shanghai; team=wonderbot pro; api_calls=50000.

این تزریق صریح، نیاز مدل به «استدلال» یا «استنتاج» (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه خودِ آشپزی و نه دوره‌ی آموزش آشپز — از روی لاگ‌های قدیمی را حذف می‌کند. وقتی در جلسه دوم سؤال هواشناسی پرسیده شد، عامل بلافاصله ابزار get_weather را برای شانگهای فراخوانی کرد، بدون اینکه هیچ سؤال شفاف‌سازی بپرسد. حقایق صریح در هر مورد برای قابلیت اطمینان، بر تاریخچه ضمنی غلبه می‌کنند زیرا مدل را مجبور نمی‌کنند تا از میان هزاران توکن تاریخچه، استدلال معکوس انجام دهد.

فشرده‌سازی تاریخچه به عنوان شیر اطمینان

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

در حالی که در دمو از یک آستانه پایین COMPRESSION_THRESHOLD یعنی ۲۵۰ توکن برای تست استفاده شد، آستانه پیشنهادی برای محیط عملیاتی بین ۲,۰۰۰ تا ۴,۰۰۰ توکن است. وقتی آستانه لمس شود، سیستم یک پرامپت خلاصه‌سازی را فعال می‌کند. این پرامپت باید صراحتاً به مدل دستور دهد که «تمام حقایق کلیدی: نام‌ها، شهرها، اعداد و نام محصولات» را حفظ کند تا از انتزاع بیش از حد جلوگیری شود.

در یک تست واقعی با ۵ مرحله، عامل اطلاعات «باب» از شنژن را ردیابی کرد که در حال ارزیابی WonderBot Pro برای ۸ توسعه‌دهنده با هزینه سالانه ۳,۵۸۸ دلار (۲۹۹ ضرب در ۱۲) بود. چون مجموع توکن‌ها ۱۹۸ بود (زیر آستانه ۲۵۰)، فشرده‌سازی هرگز فعال نشد و تاریخچه خام باقی ماند. این تایید می‌کند که فشرده‌سازی یک شیر اطمینان است، نه عملیاتی که هر لحظه تکرار شود؛ تاریخچه خام در گفتگوهای کوتاه دقیق‌تر از خلاصه است.

قواعد کلیدی برای پیاده‌سازی فشرده‌سازی شامل موارد زیر است:

• هرگز فشرده‌سازی را در میانه یک فراخوانی ابزار (tool-call) فعال نکنید، زیرا بافتار اجرا را می‌شکند.
• خلاصه را تنها پس از عبور از آستانه، به‌عنوان جایگزینی برای تاریخچه خام استفاده کنید.
• دقت را بازبینی کنید: مطمئن شوید اعداد حیاتی (مثل هزینه ۳,۵۸۸ دلاری) در فرآیند خلاصه‌سازی باقی می‌مانند.

چک‌لیست طراحی برای پیاده‌سازی

برای استقرار این الگوها، توسعه‌دهندگان باید این چک‌لیست فنی را دنبال کنند:

حافظه کوتاه‌مدت (MemorySaver)

• اختصاص یک thread_id مجزا برای هر کاربر/گفتگو؛ استفاده از User ID به‌جای رشته‌های تصادفی برای تضمین تداوم.
• استفاده از checkpointerهای پایدار (مثل SqliteSaver یا PostgresSaver) به‌جای MemorySaver ساده برای محیط عملیاتی.
• عدم اتکا به حافظه برای حل شکست‌های استدلالی در سطح مدل.

حافظه بلندمدت

• استفاده از LLM برای استخراج حقایق از طریق پارس کردن JSON به‌جای نوشتن دستی Regex یا قوانین پارسینگ.
• تزریق حقایق با فرمت صریح KV در پرامپت سیستم.
• تعریف سیاست به‌روزرسانی برای جایگزینی حقایق قدیمی به‌جای افزودن بی‌پایان.
• استفاده از دیتابیس‌های ساختاریافته برای حافظه واقعی (Factual) و ذخیره‌سازهای برداری برای حافظه معنایی (Semantic).

فشرده‌سازی تاریخچه

• تنظیم آستانه روی ۲۰۰۰-۴۰۰۰ توکن برای جلوگیری از دست رفتن دقت ناشی از فشرده‌سازی‌های مکرر.
• استفاده از پرامپتی که صراحتاً مدل را از انتزاع اعداد و نام‌های خاص منع کند.
• اعتبارسنجی بقای حقایق کلیدی در خلاصه پس از فعال شدن تریگر.

تحلیل: تغییر پارادایم عامل‌ها

این معماری تمرکز توسعه‌دهنده را از «مدل چقدر می‌تواند به یاد بیاورد» به «اطلاعات چگونه ساختار یافته‌اند» تغییر می‌دهد. با حرکت از تاریخچه ضمنی به تزریق صریح KV، توسعه‌دهندگان می‌توانند از مدل‌های کوچک‌تر و ارزان‌تر برای بخش بزرگی از کار استفاده کنند و در عین حال تجربه کاربری باکیفیتی را حفظ نمایند.

برای متخصصان، این بدان معناست که thread_id دیگر صرفاً یک نشانگر جلسه نیست، بلکه کلیدی به یک پروفایل هویتی چندلایه است. اثر ثانویه این رویکرد، کاهش شدید «فراموشی توهم‌آمیز» است؛ جایی که عامل‌ها برای چیزی که کاربر پنج دقیقه پیش گفته بود، عذرخواهی می‌کنند چون آن را فراموش کرده‌اند.

برای پیاده‌سازی این سیستم از همین امروز، ابتدا رشته‌های تصادفی را در thread_id با User IDهای پایدار جایگزین کنید و حیاتی‌ترین ویژگی‌های کاربر را از تاریخچه چت به یک پرامپت سیستم ساختاریافته منتقل کنید. این رویکرد ترکیبی — ایزولاسیون کوتاه‌مدت جلسه، تزریق بلندمدت حقایق و شیر اطمینان فشرده‌سازی توکن — یک سیستم حافظه حرفه‌ای و در سطح سازمانی ایجاد می‌کند.

گام بعدی شما

• رشته‌های تصادفی را در thread_id با User IDهای پایدار جایگزین کنید تا تداوم کاربر حفظ شود.
• ویژگی‌های حیاتی کاربر را از تاریخچه چت خارج کرده و به یک پرامپت سیستم ساختاریافته منتقل کنید.
• برای مدل‌های کوچک‌تر، لایه استخراج حقایق (Fact Store) را پیاده کنید تا نیاز به استدلال پیچیده روی تاریخچه طولانی از بین برود.

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