Mem0 در برابر Zep و Letta؛ سنجش کارآمدی معماری‌های حافظه

اگر امروز یک عامل هوش مصنوعی می‌سازید که قرار است هفته‌ها با کاربر در ارتباط باشد، احتمالاً در turn چهلم با یک بن‌بست فنی مواجه می‌شوید: مدل حقیقتی قدیمی را بازیابی می‌کند که کاربر پیش‌تر آن را اصلاح کرده است؛ مثلاً رنگ مورد علاقه قدیمی کاربر را می‌گوید، در حالی که کاربر اخیراً آن را تغییر داده است. این شکاف ثابت می‌کند که یک پایگاه‌داده برداری با برچسب بازاریابی، حافظه واقعی نیست.

طبق یک تحلیل فنی که در ۲۶ اوت ۲۰۲۶ منتشر شد، چالش اصلی نه در بازیابی داده‌ها، بلکه در تصمیم‌گیری درباره این است که چه چیزی در طول زمان «درست» باقی می‌ماند. تصور کنید دستیار دیجیتال شما می‌داند شما در ژانویه قهوه می‌خواستید، اما در ژوئن به چای تغییر ذائقه دادید. یک سامانه تولید بازیابی‌افزا (RAG) — مثل دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌‌آورد — هر دو حقیقت را بازیابی کرده و احتمالاً پاسخی متناقض و توهم‌آمیز تولید می‌کند. برای حل این مشکل، توسعه‌دهندگان به سمت لایه‌های حافظه تخصصی می‌روند که می‌توانند اطلاعات را بر اساس قوانین زمانی یا منطقی، اضافه، به‌روزرسانی یا ابطال کنند. در این راستا، استفاده از پایگاه‌داده‌های برداری برای پر کردن شکاف حافظه گامی اولیه برای مدیریت تاریخچه کاربر در سرعت‌های بالا بود، اما اکنون نیاز به منطق پیچیده‌تری برای حل تضادها احساس می‌شود.

همان‌طور که در تحلیل‌های قبلی ما درباره امنیت مدل‌های بازمتن اشاره کردیم، مدیریت وضعیت (State Management) کلید تبدیل یک چت‌بات ساده به یک عامل هوشمند است.

نبرد معماری‌های حافظه

LangChain به‌جای یک سامانه کامل، ابزارهای اولیه‌ای (Primitives) را ارائه می‌دهد. ابزارهایی مانند ConversationBufferMemory ،ConversationSummaryMemory ،ConversationKGMemory و VectorStoreRetrieverMemory بلوک‌های سازنده‌ای هستند که منطق استخراج و حل تضاد را کاملاً به دوش توسعه‌دهنده می‌اندازند.

این ابزارها نقاط ضعف و موازنه (Trade-off) مشخصی دارند:

• ConversationSummaryMemory در هر نوبت کل تاریخچه را بازخلاصه می‌کند؛ این بدان معناست که با طولانی شدن گفتگو، هزینه و تأخیر افزایش می‌یابد، حتی اگر اندازه خروجی نهایی ثابت بماند.
• ConversationKGMemory سه‌تایی‌های داده (Triples) را استخراج می‌کند اما مکانیزمی برای ابطال آن‌ها ندارد. وقتی حقیقت جدیدی با قدیمی در تضاد باشد، هر دو در گراف هم‌زیستی می‌کنند و سامانه راهی برای ترجیح داده به داده جدیدتر ندارد.

این رویکرد برای کسانی که از LangGraph و قابلیت چک‌پوینتینگ (Checkpointing) آن استفاده می‌کنند کنترل کاملی فراهم می‌کند، اما تلاش دستی زیادی می‌طلبد تا از هم‌زیستی حقایق قدیمی و جدید جلوگیری شود. اگر می‌خواهید حافظه «به‌سادگی کار کند»، این گزینه مناسب نیست، زیرا این بخش از پیاده‌سازی به عنوان یک تمرین برای توسعه‌دهنده باقی مانده است.

Mem0 یک حلقه با میانجی‌گری مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیارد‌ها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — برای مدیریت تضادها پیاده کرده است. این سامانه از یک فرآیند دو مرحله‌ای استفاده می‌کند: ابتدا در یک گذر استخراج (Extraction Pass)، حقایق کاندید را بیرون می‌کشد (مثلاً «کاربر حالت تار یا Dark Mode را ترجیح می‌دهد»). سپس در مرحله دوم — بخشی که اکثر لایه‌ها نادیده می‌گیرند — یک فراخوانی مجدد از LLM انجام می‌دهد تا کاندیدها را با حافظه‌های موجود مقایسه کرده و درباره یک اقدام تصمیم بگیرد: اضافه کردن (ADD برای داده‌های کاملاً جدید)، به‌روزرسانی (UPDATE برای مقادیر تغییر یافته)، حذف (DELETE برای داده‌های متناقض) یا نادیده گرفتن (NOOP برای داده‌های از پیش شناخته شده).

این منطق اجازه نمی‌دهد حافظه «حساسیت به میگو» در کنار داده قدیمی «مصرف منظم میگو» باقی بماند. برای مثال، اگر کاربر بگوید «قبلاً قهوه دوست داشتم اما حالا به چای تغییر داده‌ام»، Mem0 تغییر ترجیح را شناسایی کرده و به‌جای یک افزودن ساده، دستور UPDATE را صادر می‌کند.

Mem0 از ذخیره‌سازهای قابل تعویض (Pluggable) مثل Qdrant ،Chroma ،pgvector و Weaviate پشتیبانی می‌کند. همچنین یک لایه گراف مبتنی بر Neo4j برای پرس‌وجوهای رابطه‌ای (مثلاً «کاربر به چه کسی گزارش می‌دهد؟») دارد که پایگاه‌داده‌های برداری ساده در آن‌ها ضعیف هستند. از آنجا که افزودن داده‌ها به‌صورت پیش‌فرض ناهمگام (Async) است، در برنامه‌های چت که به تأخیر حساس هستند، مسیر پاسخ‌دهی را مسدود نمی‌کند.

Zep رویکرد متفاوتی با موتور گراف زمانی Graphiti دارد. به‌جای انتخاب بین حفظ یا جایگزینی یک حقیقت قدیمی، Zep از یک مدل دو-زمانی (Bi-temporal) استفاده می‌کند. این سامانه برچسب زمانی را هم برای «زمان وقوع رویداد» و هم «زمان ورود داده به سیستم» ثبت می‌کند و حقایق منسوخ را به‌جای حذف، «نامعتبر» علامت‌گذاری می‌کند.

این قابلیت به سامانه اجازه می‌دهد به پرس‌وجوهای «نقطه زمانی» پاسخ دهد؛ مثلاً «کاربر در سال ۲۰۲۳ کجا کار می‌کرد؟». Zep به‌جای تبدیل تاریخچه به یک مقدار فعلی واحد، کل تاریخ را حفظ می‌کند. این امر یک ردپای بازرسی (Audit Trail) داخلی ایجاد می‌کند که برای حوزه‌های حساس به انطباق و قوانین حیاتی است، هرچند برای کسانی که فقط وضعیت فعلی یک حقیقت را می‌خواهند، ممکن است بیش از حد پیچیده (Overkill) باشد.

Letta (که پیش‌تر MemGPT نام داشت) مدیریت حافظه را به خودِ عامل می‌سپارد. مدل زبانی ابزارهایی مانند core_memory_append ،core_memory_replace و archival_memory_insert را در اختیار دارد تا در میانه گفتگو، وضعیت خود را ویرایش کند.

Letta از یک سلسله‌مراتب شبیه به سیستم‌عامل استفاده می‌کند:

• حافظه هسته (Core Memory): بخش کوچکی که همیشه در پرامپت حضور دارد و مستقیماً قابل ویرایش است.
• حافظه آرشیوی/فراخوانی (Archival/Recall Memory): داده‌های خارجی که هنگام نیاز از طریق جست‌وجو به صورت صفحه‌بندی شده (Paged in) وارد می‌شوند.

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

انتخاب ابزار مناسب

• LangChain: برای ساخت‌های سفارشی در LangGraph که کنترل کامل بر منطق استخراج می‌خواهید و حاضرید سیستم حل تضاد خود را بسازید.
• Mem0: ایده‌آل برای محصولات چندکاربره (مثل Copilotهای CRM، بات‌های پشتیبانی، دستیاران شخصی) که حقایق در آن‌ها تغییر می‌کنند و نیاز به تطبیق خودکار دارند.
• Zep: ضروری برای حوزه‌های حساس به قوانین یا پروفایل‌های طولانی‌مدت که نیاز به تاریخچه کامل تغییرات دارند تا مشخص شود در هر زمان خاص، چه چیزی درست بوده است.
• Letta: طراحی شده برای عامل‌های خودمختار بلندمدت که مدیریت حافظه بخشی از فرآیند استدلال و تفکر خودِ عامل است، نه یک اثر جانبی.

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

برای توسعه‌دهندگان، موازنه اکنون بین تأخیر و دقت است. مرحله حل تضاد در Mem0 هزینه و زمان را در مسیر نوشتن داده افزایش می‌دهد. همچنین، پرامپت‌های استخراج تهاجمی می‌توانند منجر به «تورم حافظه» (Memory Bloat) شوند؛ یعنی صدها حقیقت کم‌ارزش که کیفیت بازیابی را کاهش می‌دهند. رویکرد فراخوانی ابزار در Letta، نوشتن در حافظه را غیرقطعی (Non-deterministic) کرده و عیب‌یابی را سخت‌تر می‌کند، زیرا شما باید ردپای فراخوانی ابزارها را بررسی کنید، نه صرفاً لاگ‌های خط لوله (Pipeline logs).

گام بعدی شما

• جلسات کاربران خود را بررسی کنید تا ببینید آیا عامل شما به‌طور مکرر با اطلاعات متناقض مواجه می‌شود یا خیر.
• اگر ترجیحات کاربران شما ایستا است، همان پایگاه‌داده برداری ساده را حفظ کنید؛ اما اگر تغییر می‌کنند، لایه‌ای مانند Mem0 را تست کنید.
• برای سیستم‌های حساس به انطباق (Compliance)، معماری دو-زمانی Zep را بررسی کنید.

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