گرمای تابستان — همه‌چیز آب می‌شود، حتی قیمت‌های ما.−25%−۲۵٪ روی هر پلن سالانه، تا ۳۱ اوتدیدن پلن‌ها
EQVPS

RAG خودمیزبان در مقیاس: یک ایندکس برداری واقعاً چقدر RAM می‌خورد

18 مرداد 1405 · 3 دقیقه مطالعه · EQVPS Team

هر آموزش RAG روی لپ‌تاپ با چند صد سند اجرا می‌شود، و بی‌دردسر به نظر می‌رسد. بعد آن را به یک مجموعه‌داده‌ی واقعی وصل می‌کنید — اسناد یک شرکت، سال‌ها تیکت، یک پایگاه دانش — و ناگهان کل بحث می‌شود حافظه.

RAG با CPU مقیاس نمی‌گیرد. با RAM مقیاس می‌گیرد.

چرا ایندکس حافظه می‌خواهد

بازیابی با تبدیل هر تکه‌ی متن به یک embedding کار می‌کند — یک بردار، چند صد تا چند هزار عدد. جستجو یعنی مقایسه‌ی بردار کوئری شما با همه‌ی آن‌ها، به‌سرعت. «سریع» کلمه‌ی کلیدی است: برای تأخیر پایین، ایندکس باید در RAM زندگی کند. روی دیسک هم کار می‌کند، اما هر کوئری جریمه می‌پردازد، و بازیابی کم‌تأخیر از همان اول دلیل خودمیزبان‌کردن بود.

پس صورتحساب حافظه با دو چیز مقیاس می‌گیرد: چند تکه دارید، و هر بردار چقدر پهن است.

اعداد واقعی، تقریبی

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

یک سیستم چندعامله که یک ایندکس بزرگ را هم نگه می‌دارد هر دو هزینه را روی یک دستگاه روی هم می‌چیند — این‌طوری است که یک پلن ۳۲ گیگابایتی بی‌سروصدا به ۶۴ گیگابایت تبدیل می‌شود.

انتخاب موتور، به‌اختصار

اگر همین‌الان Postgres اجرا می‌کنید، pgvector کم‌زحمت‌ترین گزینه است — یک افزونه است، نه یک سرویس جدید برای مراقبت. وقتی میلیون‌ها بردار دارید و جستجوی فیلترشده‌ی سریع می‌خواهید، یک موتور اختصاصی مثل Qdrant یا Weaviate پروسه‌ی جداگانه را توجیه می‌کند. روز اول بیش‌ازحد مهندسی‌اش نکنید؛ چیزی را که همین‌حالا اداره می‌کنید اجرا کنید و وقتی جستجو واقعاً کند شد آن را جدا کنید.

چرا اصلاً خودمیزبانی

دو دلیلی که مردم واقعاً این کار را می‌کنند، و هیچ‌کدام «برای صرفه‌جویی چند دلار» نیست:

حریم خصوصی. embeddingها انتزاعی نیستند — متنی را که از آن آمده‌اند کد می‌کنند. اسناد شما، محتوای مشتریانتان، یادداشت‌های داخلی‌تان، که به بردار تبدیل شده و به سرورهای شخص ثالث فرستاده می‌شوند. خودمیزبانی این را روی دستگاهی که کنترلش می‌کنید نگه می‌دارد. اگر داده آن‌قدر حساس است که با رمزارز بدون KYC هم پرداخت می‌کنید، یک ابر برداری مدیریت‌شده کل هدف را نقض می‌کند.

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

این برای انتخاب اندازه چه معنایی دارد

با اندازه‌گرفتن مجموعه‌داده‌تان شروع کنید، نه با حدس‌زدن. تعداد embedding و بُعدتان را بگیرید، یک نمونه بارگذاری کنید، حافظه‌ی ساکن را تماشا کنید، برون‌یابی کنید. بعد یک پلن با فضای اضافی برای ایندکس به‌علاوه‌ی هر چیز کنارش انتخاب کنید — اپلیکیشن، کلاینت مدل، جا برای رشد.

برای هر چیزی فراتر از چند میلیون بردار که به‌طور خصوصی نگه داشته می‌شود، خط Pro با ۳۲ تا ۸۰ گیگابایت به‌همراه یک IP اختصاصی و بکاپ شبانه اجرا می‌شود، که وقتی ایندکس همان محصول است و از دست دادنش دردناک است، اهمیت دارد.

سؤالات متداول

چرا RAG این‌قدر RAM می‌خواهد؟

جستجوی برداری سریع می‌خواهد ایندکس در حافظه ساکن باشد. هر تکه‌ی سند به یک embedding تبدیل می‌شود — برداری از چند صد تا چند هزار عدد اعشاری — و در حد میلیون‌ها تکه این عددها روی هم انباشته می‌شوند. اگر ایندکس را روی دیسک بفرستید، تأخیر جستجو جهش می‌کند؛ نگه‌داشتن کل دلیلی که خودمیزبان کردید (سرعت + کنترل) یعنی نگه‌داشتن آن در RAM.

برای یک مجموعه‌داده‌ی مشخص چقدر RAM؟

حس تقریبی: چند صد هزار embedding راحت در ۲ تا ۴ گیگابایت جا می‌گیرد. میلیون‌های پایین، همراه با اپلیکیشن و سیستم‌عامل کنارشان، به ۱۶ تا ۳۲ گیگابایت می‌رسید. ده‌ها میلیون یا بردارهای با بُعد بالا و به ۴۸ تا ۸۰ گیگابایت می‌رسید، و فراتر از آن روی چند سرور تقسیم می‌کنید. بُعد و نوع ایندکس این را خیلی جابه‌جا می‌کنند، پس خودتان اندازه بگیرید.

pgvector یا یک موتور اختصاصی مثل Qdrant؟

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

چرا خودمیزبان به‌جای یک سرویس برداری مدیریت‌شده؟

دو دلیل واقعی: embeddingهای شما اغلب داده‌ی خصوصی را کد می‌کنند (اسناد، یادداشت‌ها، محتوای مشتری)، و خودمیزبانی این را روی سروری که کنترلش می‌کنید نگه می‌دارد. و هزینه‌اش ثابت است — سرویس‌های مدیریت‌شده بر اساس تعداد بردار و کوئری کنتور می‌اندازند، یک VPS یک عدد ماهانه است بدون صورتحساب به‌ازای هر کوئری.

← بازگشت به وبلاگ← پلن‌ها و قیمت‌ها

نظرات

هنوز نظری نیست. اولین نفر باشید.

یک نظر بگذارید

نظرات پیش از نمایش بررسی می‌شوند.