یک عامل هوش مصنوعی بدون حافظه محکوم است در هر گفتوگو دوباره خودش را معرفی کند. راهحل یک پایگاهداده برداری است — embeddingهای اسناد، یادداشتها یا گفتوگوهای گذشته شما را ذخیره میکند تا عامل بتواند بخشهای مرتبط را در صورت نیاز به یاد بیاورد (همان «R» در RAG). میتوانید آن را به صورت یک سرویس مدیریتشده اجاره کنید، یا خودتان روی یک VPS اجرایش کنید و دادههایتان را — که اغلب دادههای خصوصی شماست — روی سروری که خودتان کنترل میکنید نگه دارید. اینجا میبینیم چگونه، و واقعاً چقدر RAM میگیرد.
دو گزینه خوب
به چیز عجیب و غریبی نیاز ندارید. دو مسیر تقریباً همه را پوشش میدهند:
pgvector — یک افزونه Postgres. اگر همین حالا Postgres را اجرا میکنید (یا مایل هستید)، این جستوجوی برداری را به پایگاهدادهای که همین حالا دارید اضافه میکند. یک سرویس، یک بکاپ، SQL که بلدید. با فاصله زیاد، کمدردسرترین شروع.
Qdrant — یک موتور برداری اختصاصی. وقتی سراغش بروید که تعداد زیادی بردار دارید (چند میلیون به بالا) یا فیلترینگ سریع فراداده و یک API اختصاصی میخواهید. سرویس جداگانهای است که باید اجرا کنید، اما دقیقاً برای همین کار ساخته شده است.
برای بیشتر عاملهایی که تازه دارند جا میافتند، pgvector پاسخ اول درست است. وقتی از آن بزرگتر شدید سراغ Qdrant بروید، نه زودتر.
واقعیت RAM (این بخشی است که مردم دستکم میگیرند)
جستوجوی برداری سریع است چون ایندکس در حافظه زندگی میکند — پس RAM، نه دیسک، محدودیت واقعی شماست. یک راهنمای سرانگشتی:
- چند صد هزار embedding — راحت در ۲ گیگابایت.
- چند میلیون — برای ۴ گیگابایت به بالا برنامهریزی کنید و ایندکس را تنظیم کنید.
- دیسک بخش آسان ماجراست: یک میلیون embedding فقط چند گیگابایت است، پس ۲۵ تا ۴۵ گیگابایت یک ذخیرهساز جدی را پوشش میدهد.
پس برای ایندکس اندازه بگیرید، نه برای فایل. (همان منطق راهنمای اندازهگیری عمومی — چیز سنگین تا وقتی اندازه نگیرید آشکار نیست.)
شروع سریع: pgvector
روی سروری که Postgres دارد (Docker سادهترین است — همان الگوی خودمیزبانی n8n):
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE memory (
id bigserial PRIMARY KEY,
content text,
embedding vector(1536) -- match your embedding model's dimensions
);
-- after you have data, build an index for fast search:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);
عامل شما content را بهعلاوه embedding آن درج میکند، سپس با ORDER BY embedding <=> $query_embedding LIMIT 5 پرسوجو میکند تا نزدیکترین حافظهها را بیرون بکشد. کل حلقه همین است.
Qdrant را ترجیح میدهید؟ یک کانتینر Docker است که یک API از نوع HTTP/gRPC ارائه میدهد؛ یک collection با اندازه بردار خود میسازید و pointها را upsert میکنید. همان ایده، موتور اختصاصی.
آیا میتواند یک سرور را با عامل به اشتراک بگذارد؟
بله — برای ذخیرهسازهای حافظه کوچک تا متوسط، پایگاهداده برداری را روی همان VPS عامل اجرا کنید. سادهتر است و تأخیر عملاً صفر. تنها زمانی آنها را روی سرورهای جدا تقسیم کنید که یکی شروع به بیرونراندن دیگری از RAM کند. این تصمیمی است برای بعد و از جنس مسئلههای خوب، نه دغدغه روز اول.
هشدارهای صادقانه
- RAM دیوار است، و بیصداست. جستوجو سریع میماند تا وقتی ایندکس دیگر در حافظه جا نگیرد، آنوقت افت میکند. حافظه را زیر نظر بگیرید و پیش از آنکه دردسرساز شود اندازه را بزرگ کنید — منتظر نمانید پرسوجوهای کند خبرش را به شما بدهند.
- ساختن embeddingها توکن هزینه دارد. هر سندی که embed میکنید یک فراخوان API به یک مدل embedding است. میزبانی ذخیرهساز ارزان است؛ تولید بردارها هزینه تکرارشونده است — مرتبط با هزینه واقعی اجرای یک عامل.
- از آن بکاپ بگیرید. حافظه عامل شما هم مثل هر داده دیگری داده است. اگر مهم است، از آن snapshot بگیرید.
با رعایت این نکات، یک ذخیرهساز برداری خودمیزبان راهی تمیز است برای دادن حافظه پایدار به یک عامل، بدون سپردن دادههای خصوصیتان به شخص ثالث. با pgvector روی یک سرور ۲ گیگابایتی شروع کنید، حواستان به RAM باشد، و تنها زمانی که اعداد به شما میگویند به Qdrant یا یک پلن بزرگتر مهاجرت کنید.
نظرات
هنوز نظری نیست. اولین نفر باشید.