RAG کو اتنی RAM کیوں چاہیے؟

تیز vector search index کو memory میں resident چاہتا ہے۔ ہر document chunk ایک embedding بنتا ہے — چند سو سے چند ہزار floats کا ایک vector — اور لاکھوں chunks پر یہ جمع ہوتا ہے۔ index کو ڈسک پر دھکیلیں اور search latency چھلانگ لگاتی ہے؛ self-host کرنے کی پوری وجہ (رفتار + کنٹرول) رکھنے کا مطلب اسے RAM میں رکھنا ہے۔

ایک دیے گئے corpus کے لیے کتنی RAM؟

کچا احساس: چند لاکھ embeddings 2–4 GB میں ٹھیک بیٹھتے ہیں۔ چند لاکھوں (Low millions)، ان کے گرد ایپ اور OS کے ساتھ، اور آپ 16–32 GB پر ہیں۔ دسیوں ملین یا high-dimension vectors اور آپ 48–80 GB میں ہیں، اور اس سے آگے آپ سرورز میں تقسیم کرتے ہیں۔ Dimension اور index قسم اسے بہت جھلاتے ہیں، تو اپنا خود ماپیں۔

pgvector یا Qdrant جیسا ایک dedicated engine؟

اگر آپ پہلے ہی Postgres چلاتے ہیں، تو pgvector سب سے کم-محنت راستہ ہے — ایک extension، ایک database۔ بھاری filtering والے لاکھوں vectors کے لیے، ایک purpose-built engine اپنی الگ سروس کماتا ہے۔ جو آپ پہلے ہی چلاتے ہیں اس سے شروع کریں؛ صرف تب منتقل ہوں جب search سست ہو۔

ایک managed vector سروس کے بجائے self-host کیوں؟

دو حقیقی وجوہات: آپ کے embeddings اکثر نجی ڈیٹا encode کرتے ہیں (docs، notes، customer content)، اور self-hosting اسے آپ کے کنٹرول کیے سرور پر رکھتا ہے۔ اور یہ flat cost ہے — managed سروسز vectors اور queries سے میٹر کرتی ہیں، ایک VPS بغیر کسی per-query بل کے ایک ماہانہ نمبر ہے۔

Self-hosted RAG بڑے پیمانے پر: ایک vector index دراصل کتنی RAM کھاتا ہے

ہر RAG tutorial چند سو دستاویزات والے ایک لیپ ٹاپ پر چلتا ہے، اور یہ بے-محنت محسوس ہوتا ہے۔ پھر آپ اسے ایک حقیقی corpus پر لگاتے ہیں — ایک کمپنی کی docs، سالوں کے tickets، ایک knowledge base — اور اچانک memory پوری گفتگو ہے۔

RAG CPU سے scale نہیں کرتا۔ یہ RAM سے scale کرتا ہے۔

index کو memory کیوں چاہیے

Retrieval متن کے ہر chunk کو ایک embedding میں بدل کر کام کرتا ہے — ایک vector، چند سو سے چند ہزار نمبر لمبا۔ Search کا مطلب آپ کے query vector کا ان سب سے موازنہ کرنا، تیزی سے۔ "تیز" کلیدی لفظ ہے: کم latency کے لیے index کو RAM میں رہنا چاہیے۔ ڈسک پر یہ چلتا ہے، لیکن ہر query ایک جرمانہ ادا کرتی ہے، اور کم-latency retrieval پہلی جگہ self-host کرنے کا نکتہ تھا۔

تو memory بل دو چیزوں سے scale کرتا ہے: آپ کے پاس کتنے chunks ہیں، اور ہر vector کتنا چوڑا ہے۔

حقیقی نمبر، تقریباً

اپنا خود ماپیں — dimension اور index قسم اسے بہت ہلاتے ہیں — لیکن ایک ابتدائی احساس کے طور پر:

چند لاکھ embeddings — 2–4 GB میں آرام دہ۔ ایک ذاتی knowledge base، ایک واحد product کی docs۔
چند لاکھوں (Low millions) — ایپ، model client، اور اس کے گرد OS کے ساتھ، 16–32 GB کا منصوبہ بنائیں۔ یہ ایک سنجیدہ کمپنی knowledge base یا ایک multi-source RAG ہے۔
دسیوں ملین، یا high-dimension vectors — اب آپ 48–80 GB پر ہیں، اور اس سے آگے کئی باکسز میں۔ بڑے document estates، multi-tenant retrieval، یا آپ ایک ساتھ کئی indexes گرم رکھ رہے ہیں۔

ایک multi-agent سسٹم جو ایک بڑا index بھی رکھتا ہے وہ دونوں لاگتیں اسی باکس پر ڈھیر کرتا ہے — اسی طرح ایک 32 GB پلان خاموشی سے ایک 64 GB والا بن جاتا ہے۔

engine انتخاب، مختصراً

اگر آپ پہلے ہی Postgres چلاتے ہیں، تو pgvector سب سے کم-محنت اختیار ہے — یہ ایک extension ہے، سنبھالنے کو ایک نئی سروس نہیں۔ جب آپ کے پاس لاکھوں vectors ہوں اور آپ تیز filtered search چاہیں، تو Qdrant یا Weaviate جیسا ایک dedicated engine الگ process کماتا ہے۔ پہلے دن اسے over-engineer نہ کریں؛ جو آپ پہلے ہی چلاتے ہیں وہ چلائیں اور جب search دراصل سست ہو تو اسے الگ کریں۔

self-host کرنے کی زحمت کیوں

دو وجوہات جن سے لوگ دراصل یہ کرتے ہیں، اور کوئی "چند ڈالر بچانے کو" نہیں:

نجی پن۔ Embeddings تجریدی نہیں — وہ اُس متن کو encode کرتے ہیں جہاں سے آئے۔ آپ کی docs، آپ کے گاہکوں کا content، آپ کے اندرونی notes، vectors میں بدلے اور ایک تیسرے-فریق کے سرورز پر بھیجے گئے۔ Self-hosting اسے ایک مشین پر رکھتا ہے جو آپ کنٹرول کریں۔ اگر ڈیٹا اتنا حساس ہے کہ آپ کرپٹو سے بغیر KYC ادا بھی کر رہے ہیں، تو ایک managed vector cloud پورا نکتہ ختم کر دیتا ہے۔

Flat cost۔ Managed vector سروسز ذخیرہ کیے vectors اور چلائی گئی queries سے bill کرتی ہیں۔ ایک VPS ایک ماہانہ نمبر ہے اور آپ اسے جتنا چاہیں سختی سے مار سکتے ہیں۔ بڑے پیمانے پر، پیشگوئی کے قابل metered کو مات دیتا ہے۔

sizing کے لیے اس کا کیا مطلب ہے

اپنے corpus کو ماپ کر شروع کریں، اندازہ لگا کر نہیں۔ اپنی embedding گنتی اور dimension حاصل کریں، ایک sample لوڈ کریں، resident memory دیکھیں، extrapolate کریں۔ پھر index plus اس کے گرد ہر چیز — ایپ، model client، بڑھنے کی جگہ — کے لیے headroom والا ایک پلان چنیں۔

چند ملین vectors نجی طور پر رکھنے سے آگے کسی بھی چیز کے لیے، Pro لائن ایک dedicated IP اور nightly backups کے ساتھ 32 سے 80 GB چلاتی ہے، جو اہم ہے جب index ہی product ہو اور اسے کھونا تکلیف دے۔