RAG-এর এত RAM কেন দরকার?

দ্রুত vector search চায় index memory-তে থাকুক। প্রতিটি নথি-chunk হয় একটি embedding — কয়েকশো থেকে কয়েক হাজার float-এর একটি vector — আর মিলিয়ন-মিলিয়ন chunk-এ তা জমে। index ডিস্কে ঠেলুন আর search latency লাফ দেয়; সেলফ-হোস্ট করার পুরো কারণ (গতি + নিয়ন্ত্রণ) রাখা মানে এটি RAM-এ রাখা।

একটি নির্দিষ্ট corpus-এর জন্য কত RAM?

মোটামুটি অনুভূতি: কয়েক লক্ষ embedding 2–4 GB-তে ভালোই বসে। কয়েক মিলিয়ন, চারপাশে app ও OS সহ, আর আপনি 16–32 GB-তে। কয়েক কোটি বা high-dimension vector আর আপনি 48–80 GB-তে, আর তার বেশি হলে আপনি সার্ভার-জুড়ে ভাগ করেন। dimension ও index-টাইপ এটিকে অনেকটা দোলায়, তাই নিজেরটা মাপুন।

pgvector নাকি Qdrant-র মতো একটি dedicated engine?

আপনি ইতিমধ্যেই Postgres চালালে, pgvector সবচেয়ে কম-শ্রমের পথ — একটি extension, একটি database। ভারী filtering সহ মিলিয়ন-মিলিয়ন vector-এর জন্য, একটি purpose-built engine তার আলাদা সার্ভিস অর্জন করে। আপনি ইতিমধ্যেই যা চালান তা দিয়ে শুরু করুন; search ধীর হলেই কেবল সরুন।

একটি managed vector সার্ভিসের বদলে সেলফ-হোস্ট কেন?

দুটি আসল কারণ: আপনার embedding প্রায়ই প্রাইভেট ডেটা এনকোড করে (নথি, নোট, গ্রাহক-কনটেন্ট), আর সেলফ-হোস্টিং তা আপনার নিয়ন্ত্রিত একটি সার্ভারে রাখে। আর এটি flat খরচ — managed সার্ভিস vector ও query অনুযায়ী মিটার করে, একটি VPS কোনো per-query বিল ছাড়া একটি মাসিক সংখ্যা।

স্কেলে সেলফ-হোস্টেড RAG: একটি vector index আসলে কত RAM খায়

প্রতিটি RAG tutorial কয়েকশো নথি সহ একটি ল্যাপটপে চলে, আর এটি অনায়াস লাগে। তারপর আপনি এটিকে একটি আসল corpus-এর দিকে তাক করেন — একটি কোম্পানির নথি, বছরের পর বছরের টিকিট, একটি knowledge base — আর হঠাৎ memory-ই পুরো কথোপকথন।

RAG CPU দিয়ে scale করে না। এটি RAM দিয়ে scale করে।

index কেন memory চায়

Retrieval কাজ করে টেক্সটের প্রতিটি chunk-কে একটি embedding-এ রূপান্তরিত করে — একটি vector, কয়েকশো থেকে কয়েক হাজার সংখ্যা দীর্ঘ। Search মানে আপনার query vector-কে সব কটির সাথে দ্রুত তুলনা করা। "দ্রুত"-ই মূল শব্দ: কম latency-র জন্য index-কে RAM-এ থাকতে হয়। ডিস্কে এটি কাজ করে, কিন্তু প্রতিটি query একটি জরিমানা দেয়, আর কম-latency retrieval-ই প্রথমে সেলফ-হোস্ট করার বিন্দু ছিল।

তাই memory-বিল দুটি জিনিসের সাথে scale করে: আপনার কত chunk আছে, আর প্রতিটি vector কত প্রশস্ত।

আসল সংখ্যা, মোটামুটি

নিজেরটা মাপুন — dimension ও index-টাইপ এটিকে অনেকটা নড়ায় — তবে একটি শুরুর অনুভূতি হিসেবে:

কয়েক লক্ষ embedding — 2–4 GB-তে আরামদায়ক। একটি ব্যক্তিগত knowledge base, একটি একক প্রোডাক্টের নথি।
কয়েক মিলিয়ন — app, model client, ও চারপাশে OS সহ, 16–32 GB ধরুন। এটি একটি গুরুতর কোম্পানি knowledge base বা একটি multi-source RAG।
কয়েক কোটি, বা high-dimension vector — এখন আপনি 48–80 GB-তে, আর তার বেশি কয়েকটি বক্স-জুড়ে। বড় নথি-ভান্ডার, multi-tenant retrieval, বা আপনি একসাথে কয়েকটি index গরম রাখছেন।

একটি multi-agent সিস্টেম যা একটি বড় index-ও ধরে সেটি একই বক্সে দুটি খরচ জমায় — এভাবেই একটি 32 GB প্ল্যান নীরবে একটি 64 GB হয়ে যায়।

engine-পছন্দ, সংক্ষেপে

আপনি ইতিমধ্যেই Postgres চালালে, pgvector সবচেয়ে কম-শ্রমের বিকল্প — এটি একটি extension, দেখভাল করার একটি নতুন সার্ভিস নয়। আপনার যখন মিলিয়ন-মিলিয়ন vector আছে ও দ্রুত filtered search চান, Qdrant বা Weaviate-র মতো একটি dedicated engine আলাদা process অর্জন করে। প্রথম দিনে এটি over-engineer করবেন না; আপনি ইতিমধ্যেই যা চালান তা চালান ও search আসলে ধীর হলে আলাদা করুন।

সেলফ-হোস্ট করার ঝামেলা কেন

মানুষ আসলে দুটি কারণে এটি করে, আর কোনোটাই "কয়েক ডলার বাঁচাতে" নয়:

প্রাইভেসি। Embedding বিমূর্ত নয় — এরা যে টেক্সট থেকে এসেছে তা এনকোড করে। আপনার নথি, আপনার গ্রাহকের কনটেন্ট, আপনার অভ্যন্তরীণ নোট, vector-এ রূপান্তরিত ও একটি তৃতীয় পক্ষের সার্ভারে পাঠানো। সেলফ-হোস্টিং তা আপনার নিয়ন্ত্রিত একটি মেশিনে রাখে। ডেটা এতই সংবেদনশীল হলে যে আপনি no KYC-তে ক্রিপ্টোতেও পরিশোধ করছেন, একটি managed vector cloud পুরো বিন্দু নষ্ট করে।

Flat খরচ। Managed vector সার্ভিস সঞ্চিত vector ও চালানো query অনুযায়ী বিল করে। একটি VPS একটি মাসিক সংখ্যা আর আপনি যত খুশি চাপাতে পারেন। স্কেলে, অনুমেয় মিটার-করাকে হারায়।

এর মানে sizing-এর জন্য কী

অনুমান নয়, আপনার corpus মেপে শুরু করুন। আপনার embedding-সংখ্যা ও dimension নিন, একটি নমুনা load করুন, resident memory দেখুন, extrapolate করুন। তারপর index plus চারপাশের সবকিছুর জন্য headroom সহ একটি প্ল্যান বাছুন — app, model client, বাড়ার জায়গা।

কয়েক মিলিয়ন vector-এর বেশি প্রাইভেটভাবে ধরে রাখা যেকোনো কিছুর জন্য, Pro লাইন একটি dedicated IP ও রাত্রিকালীন backup সহ 32 থেকে 80 GB চালায়, যা গুরুত্বপূর্ণ যখন index-ই প্রোডাক্ট আর এটি হারানো ব্যথা দেয়।