فشرده‌سازی حافظه در عامل‌های هوش مصنوعی نرخ بازیابی داده را ۵۷٪ کاهش داد

تصور کنید دستیاری دارید که هر چه به او می‌گویید را یادداشت می‌کند، اما وقتی می‌گویید «دیگر در شهر گوآ زندگی نمی‌کنم»، او دقیقاً جمله «من در گوآ زندگی می‌کنم» را به دفترچه‌اش اضافه می‌کند. این شکستِ منطقی، هسته اصلی گزارش ۲۳ اوت ۲۰۲۶ از پروژه Arc Rector است؛ یک پشته تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — که از اجزای رایگان و قابل‌میزبانی شخصی ساخته شده است.

بسیاری از توسعه‌دهندگان با حافظه هوش مصنوعی مانند یک سطل واحد برخورد می‌کنند، اما Project Arc Rector سه لایه مجزا را تعریف می‌کند: تکه‌های کوتاه‌مدت برای پرسش فعلی، تاریخچه نشست برای کاربر فعال و حقایق ماندگاری که برای همیشه ذخیره می‌شوند. برای کسانی که عامل‌های محلی می‌سازند، چالش اصلی نه در ذخیره داده، بلکه در تصمیم‌گیری برای به‌روزرسانی یا حذف آن‌هاست.

طبق گزارش وب‌سایت dev.to، این پروژه یک آداپتور (لایه سازگارساز) بدون وابستگی را آزمایش کرد که از الگوهای regex برای استخراج حقایق اول‌شخص استفاده می‌کرد. نتایج یک شکاف منطقی بزرگ را فاش کرد: اگر کاربر بگوید «من به گوآ نقل مکان کردم»، سیستم هیچ‌چیز ذخیره نمی‌کند چون با الگوی «من زندگی می‌کنم در...» مطابقت ندارد. اما اگر کاربر بگوید «فراموش کن که در گوآ زندگی می‌کنم»، سیستم به‌طور طنزآمیزی جمله «من در گوآ زندگی می‌کنم» را در حافظه می‌نویسد.

همان‌طور که در بحث‌های گذشته ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، مدیریت داده‌های ورودی بدون لایه‌های پالایش، منجر به رفتارهای پیش‌بینی‌ناپذیر می‌شود. این ناپایداری در خروجی‌ها مشابه چالش‌هایی است که در محیط‌های عملیاتی با تغییر نسخه‌های مدل‌ها رخ می‌دهد؛ موضوعی که در بررسی راهکارهای تثبیت نسخه‌های مدل Mistral برای جلوگیری از پس‌رفت به آن پرداختیم.

پیاده‌سازی فنی و محک‌ها

برای حل این مشکل، پروژه ابزار Mem0 را ادغام کرد که به‌صورت محلی از طریق Ollama (با مدل llama3.2:3b و nomic-embed-text) و یک مجموعه Qdrant اجرا می‌شود. تفاوت در کارایی بسیار چشمگیر است:

• ذخیره‌ساز متوالی (Append-only): ۵ حقیقت را در ۶ نوبت حفظ کرد، اما تضاد ایجاد کرد (مثلاً همزمان ذخیره کرد که کاربر «از ویندوز استفاده می‌کند» و «از ویندوز استفاده نمی‌کند»).
• تطبیق Mem0: با استفاده از فراخوانی‌های مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — بین گزینه‌های افزودن، به‌روزرسانی، حذف یا نادیده گرفتن تصمیم گرفت و در همان ۶ نوبت، تنها ۲ حقیقت پاک و بدون تضاد را نگه داشت.
• حفاظ‌های عملکردی: برای جلوگیری از توقف سیستم، تابع افزودن روی یک رشته (thread) مجزا با مهلت زمانی ۴۵ ثانیه اجرا می‌شود.

پرتگاه فشرده‌سازی

این پروژه همچنین هزینه فشرده‌سازی حافظه را اندازه‌گیری کرد؛ یعنی تبدیل گفتگوهای طولانی به یک بودجه محدود از توکن (Token) — تکه‌های کوچکی از متن، شبیه برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد. وقتی ۱۰ نوبت گفتگو در بودجه ۲۲۰ توکنی فشرده شد، ۵۱٪ متن باقی ماند، اما امتیاز بازیابی (Recall@3) برای استخراج حقایق از ۱.۰۰ به ۰.۴۳ سقوط کرد.

این داده‌ها یک نقطه کور خطرناک در نظارت بر هوش مصنوعی را نشان می‌دهد: داشبورد مدیریتی ممکن است گزارش دهد که ۶۰٪ گفتگو حفظ شده است، در حالی که بازیابی واقعی حقایق بیش از نصف کاهش یافته است. داده‌ها نشان می‌دهند که بازیابی تنها در بودجه ۳۲۰ توکنی، جایی که ۷۸٪ متن حفظ می‌شود، به ثبات می‌رسد.

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

گام بعدی شما

• اگر از حافظه‌های ساده append-only استفاده می‌کنید، لایه‌ای برای تطبیق (Reconciliation) مانند Mem0 اضافه کنید تا از تضاد داده‌ها جلوگیری شود.
• هنگام فشرده‌سازی تاریخچه گفتگو، به‌جای تکیه بر درصد متن باقی‌مانده، یک آزمون بازیابی (Recall Test) برای حقایق کلیدی طراحی کنید.
• بودجه توکن‌های حافظه را بر اساس نقطه ثبات بازیابی (در این مورد ۳۲۰ توکن) تنظیم کنید، نه بر اساس کمترین هزینه.

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