یک بنچمارک اخیر نشان میدهد که طراحی حافظه دو لایه — شامل یک اسکرچپد (scratchpad) مبتنی بر RAM و یک مخزن (vault) محلی SQLite-vec — زمان میانه پرسوجو را به زیر ۱۰۰ میلیثانیه میرساند و در عین حال هزینهی ۱۳۵ دلاری در ماه را که مربوط به یک ذخیرهساز برداری ابری محبوب است، حذف میکند. توسعهدهندگانی که عاملهای هوش مصنوعی خودمختار میسازند، میتوانند یک راهاندازی کاملاً محلی (on-premise) داشته باشند که در این بنچمارک، سریعتر بوده و هیچ هزینه ماهانهای نداشته است.
چرا رویکردهای فعلی حافظه ناکافی هستند
عاملهای هوش مصنوعی اغلب نیاز دارند هزاران تعامل گذشته، واقعیت یا نتایج فراخوانی ابزار (tool-call) را در یک بازه زمانی پاسخدهی محدود بازیابی کنند. اکثر تیمها هر امبدینگ را به یک پایگاه داده برداری مدیریتشده میفرستند و برای هر جستجو به جستجوی برداری از راه دور متکی هستند. این مدل مقیاسپذیر است، اما هر پرسوجو را مجبور میکند از شبکه عبور کند که باعث افزایش زمان رفت و برگشت (round-trip time) و هزینههای ماهانه میشود. در این بنچمارک، میانه تأخیر سرویس ابری ۱۲۷ میلیثانیه بود و صورتحساب ماهانه از ۱۳۵ دلار فراتر رفت؛ همچنین در این دوره آزمایش، یک قطعی (outage) نیز ثبت شد.
تقسیم حافظه به دو سطح
معماری دو سطحی، «حافظه کاری» را از «ذخیرهسازی بلندمدت» جدا میکند:
L1 Scratchpad (RAM)
- کاملاً در حافظه پردازش (process memory) قرار دارد.
- بافتار (context) وظیفه فعلی و آخرین فراخوانیهای ابزار را نگه میدارد.
- رشتههای خام (raw strings) را ذخیره میکند؛ هیچ امبدینگی تولید نمیشود.
- نتایج را در کمتر از ۳ میلیثانیه برمیگرداند که با حافظه کش CPU قابل مقایسه است.
L2 Vault (SQLite-vec)
- تمام امبدینگهای دیگر را در یک پایگاه داده محلی SQLite که با قابلیتهای جستجوی برداری گسترش یافته، ذخیره میکند.
- مجموعه کامل ۱۴,۷۲۶ حافظه استفاده شده در بنچمارک را مدیریت میکند.
- تطابقها را در حدود ۹۴ میلیثانیه برمیگرداند که به راحتی زیر هدف ۱۰۰ میلیثانیهای برای بسیاری از عاملهای بلادرنگ (real-time) است.
- هزینهای فراتر از فضای ذخیرهسازی ماشین میزبان ندارد.
SQLite-vec یک افزونه متنباز است که جستجوی تقریبی نزدیکترین همسایه (approximate nearest-neighbor search) را به یک فایل رابطهای استاندارد اضافه میکند. از آنجایی که پایگاه داده روی همان ماشینی قرار دارد که عامل در آن اجرا میشود، هیچ پرش شبکهای (network hop) وجود ندارد و موتور از ترفندهای ایندکسگذاری موجود در SQLite برای سریع نگه داشتن جستجوها استفاده میکند.
اعداد مهم
| سیستم | میانه تأخیر | هزینه ماهانه | قابلیت اطمینان گزارش شده |
|---|---|---|---|
| ذخیرهساز برداری ابری (Pinecone) | 127 ms | ~$135 | مشاهده قطعی (Outages) |
| مخزن محلی SQLite-vec | 94 ms | $0 | 100% پایداری (uptime) |
تفاوت هزینه، ۰ دلار در مقابل تقریباً ۱۳۵ دلار در ماه است.
مرتب نگه داشتن مخزن
تخلیه خام (raw dump) تمام امبدینگها میتواند میزان مرتبط بودن را کاهش دهد. نویسنده بنچمارک یک سیستم زوال (decay system) معرفی کرد که به حافظهها بر اساس تازگی و تکرار امتیاز میدهد:
- موارد جدید یا مواردی که به طور مکرر مورد دسترسی قرار میگیرند، وزن بیشتری دریافت میکنند.
- مواردی که مدتی است با آنها برخورد نشده، به تدریج وزن خود را از دست میدهند.
- زوال وزندار شده (weighted decay)، «نویز بازیابی» — یعنی تطابقهای نامرتبط — را تا ۳۴٪ کاهش میدهد.
با حذف (pruning) ورودیهای با امتیاز پایین یا کاهش رتبه آنها در ایندکس، عامل از دادههای قدیمی جلوگیری کرده و در عین حال مخزن را برای عملکرد ثابت، به اندازه کافی سبک نگه میدارد.
نتیجهگیری
برای عاملهای هوش مصنوعی که باید هزاران حافظه را در یک ضربالاجل محدود مدیریت کنند، ترکیب یک اسکرچپد با اولویت RAM و یک مخزن محلی SQLite-vec، جایگزینی عملگرایانه برای ذخیرهسازهای برداری کاملاً ابری است. این رویکرد زمان پاسخدهی را کاهش میدهد، هزینههای ماهانه ابری را حذف میکند و خدماتی بدون وقفه ارائه میدهد، در حالی که همزمان قابلیت حذف دادههای نامرتبط را حفظ میکند. بنابراین، اتخاذ مدل دو سطحی میتواند عاملها را سریعتر، ارزانتر و قابلاعتمادتر کند.