معماری حافظهٔ SupportMind: جداسازی یادآوری از پنجرهٔ متنی برای جلوگیری از نشت

تصور کنید یک عامل پشتیبانی هوش مصنوعی را که باید بین هزاران تیکت قدیمی جست‌وجو کند تا بفهمد مشکل فعلی شما چیست؛ اگر تمام این تاریخچه را در حافظه کوتاه‌مدت مدل بریزید، مدل گیج شده و پاسخ‌های اشتباه می‌دهد. پروژه SupportMind، که توسط سامالا کاویا (Samala Kavya) و تیمی برای یک هکاتون توسعه یافته است، ثابت می‌کند که برای حل این مشکل، ما به مدل‌های بزرگ‌تر یا پنجره‌های بافت (Context Windows) وسیع‌تر نیاز نداریم، بلکه به یک معماری حافظه اختصاصی نیاز داریم. این پروژه تمرکز را از اندازه مدل به سمت بازیابی اطلاعات (Information Retrieval) تغییر می‌دهد.

صورت مسئله

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

در این معماری، مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — تنها به عنوان موتور گفتگو عمل می‌کند و مدیریت حافظه به عهده لایه‌ی اپلیکیشن است. این جداسازی به برنامه اجازه می‌دهد تصمیم بگیرد مدل چه اطلاعاتی را ببیند، از چه ابزارهایی استفاده کند و پس از پاسخ دادن، چه اطلاعاتی را در حافظه ذخیره نماید.

چالش‌های مهندسی

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

برای پاسخ به این چالش‌ها و عملیاتی کردن سیستم برای استفاده در دنیای واقعی، تیم چهار حفاظ (Guardrails) معماری کلیدی را پیاده کرده است:

• ایزولاسیون شناسه‌ای: برای جلوگیری از نشت داده (Data Leakage)، سیستم از یک شناسه مشتری به عنوان ID بانک حافظه استفاده می‌کند. معماری سیستم از منطق hindsight.recall( bank_id=customer_id, query=message ) پیروی می‌کند. این امر تضمین می‌کند تاریخچه یک کاربر، مثلاً مشکلات وای‌فای «پریا»، هرگز با نشست کاربر دیگری مانند «رامش» ترکیب نشود.
• بازیابی هدفمند: به جای ارسال کل تاریخچه، سیستم تنها خاطراتی را بازیابی می‌کند که با پیام فعلی مرتبط هستند. هدف اینجا ارائه «بستر مفید» است، نه صرفاً «بستر بیشتر». این رویکرد شباهت زیادی به جایگزینی خط‌لوله‌های پیچیده با ساختارهای حافظه بهینه دارد که هدفشان ساده‌سازی جریان داده‌هاست.
• وضعیت حافظه صفر: وقتی مشتری جدید است، عامل صراحتاً باخبر می‌شود. اگر هیچ مورد مرتبطی بازیابی نشود، SupportMind به مدل اطلاع می‌دهد که این یک مشتری جدید بدون تاریخچه قبلی است؛ این کار از توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — جلوگیری می‌کند.
• زنجیره تفکر برای خلاصه‌سازی: ابزار «گزارش مشتری» با استفاده از زنجیره تفکر (Chain-of-Thought) — مثل وقتی شاگرد ریاضی پای تخته بلند بلند فکر می‌کند تا به جواب برسد — تاریخچه خام تعاملات را به یک خلاصه کوتاه از مشکلات تکراری و راهکارهای موفق تبدیل می‌کند.

پشته فنی (Technical Stack)

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

• LLM: مدل gpt-oss-120b روی زیرساخت Groq که وظیفه تولید پاسخ‌ها را بر عهده دارد.
• حافظه: ابزار Hindsight که مدیریت بانک‌های حافظه اختصاصی هر مشتری را بر عهده دارد.
• بک‌اند: فریم‌ورک Flask برای مدیریت مسیرهای API و اپلیکیشن وب.
• فرانت‌اند: رابط کاربری که قابلیت‌های انتخاب مشتری، چت، نمایش خاطرات بازیابی‌شده، مقایسه پاسخ‌ها و گزارشات مشتری را نمایش می‌دهد.

مشاهده‌پذیری و بازتاب (Reflection)

یکی از ویژگی‌های برجسته، ابزار «گزارش مشتری» (Customer Briefing) است. در حالی که بازیابی استاندارد به پاسخ دادن به یک سوال خاص کمک می‌کند، این گزارش از قابلیت بازتاب (Reflection) استفاده می‌کند تا تاریخچه خام را به پروفایلی جامع تبدیل کند. این کار به یک اپراتور انسانی یا یک هوش مصنوعی اجازه می‌دهد بدون خواندن تک‌تک تیکت‌ها، درک کلی از وضعیت مشتری داشته باشد.

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

به باور تیم سازنده، گلوگاه فعلی عامل‌های هوش مصنوعی لزوماً هوش مدل نیست. اغلب مدل از قبل می‌داند چگونه مشکل را حل کند، اما فاقد بستر تاریخی (Historical Context) خاص برای انجام آن است.

محدودیت‌های فعلی

اگرچه این پروتوتایپ از داده‌های نمونه استفاده می‌کند و هنوز قادر به انجام کارهایی مانند صدور بازپرداخت (Refund)، تغییر اشتراک‌ها یا دسترسی به حساب‌های واقعی مشتریان نیست، اما یک نقشه راه (Blueprint) برای ادغام با سیستم‌های CRM احراز شده ارائه می‌دهد. فاز بعدی شامل متصل کردن این بانک‌های حافظه به مجوزهای حساب در لحظه و سیستم‌های مدیریت تیکت است.

برای مشاهده این رویکرد در عمل، بررسی کنید که چگونه ادغام یک پایگاه داده برداری مانند Hindsight می‌تواند با جایگزینی پرامپت‌های تاریخچه کامل با بازیابی هدفمند حافظه، هزینه توکن‌های شما را کاهش دهد.

گام بعدی شما

• بررسی جایگزینی پرامپت‌های طولانی با سیستم‌های بازیابی هدفمند برای کاهش هزینه توکن.
• پیاده‌سازی لایه‌ی ایزولاسیون شناسه‌ای در عامل‌های پشتیبانی برای تضمین حریم خصوصی کاربران.
• استفاده از ابزارهای Reflection برای تبدیل تاریخچه خام گفتگوها به پروفایل‌های کاربر.

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