बिना मेमोरी के एक AI एजेंट हर बातचीत में ख़ुद को दोबारा परिचित कराते अटका रहता है। समाधान एक वेक्टर डेटाबेस है — यह आपके दस्तावेज़ों, नोट्स या पिछली चैट के एम्बेडिंग संग्रहीत करता है ताकि एजेंट माँग पर प्रासंगिक हिस्से याद कर सके (यही RAG का "R" है)। आप इसे एक प्रबंधित सेवा के रूप में किराए पर ले सकते हैं, या आप इसे ख़ुद एक VPS पर चला सकते हैं और अपना डेटा — जो अक्सर आपका निजी डेटा होता है — एक ऐसे बॉक्स पर रख सकते हैं जिसे आप नियंत्रित करते हैं। यहाँ है कैसे, और इसकी असल में RAM में क्या लागत है।
दो अच्छे विकल्प
आपको कुछ अनोखा नहीं चाहिए। दो रास्ते लगभग सबको कवर करते हैं:
pgvector — एक Postgres एक्सटेंशन। अगर आप पहले से Postgres चला रहे हैं (या ख़ुश हैं), यह उस डेटाबेस में वेक्टर खोज जोड़ता है जो आपके पास पहले से है। एक सेवा, एक बैकअप, वह SQL जो आप जानते हैं। एक बड़े अंतर से सबसे कम-मेहनत की शुरुआत।
Qdrant — एक उद्देश्य-निर्मित वेक्टर इंजन। जब आपके पास बहुत सारे वेक्टर हों (निचले लाखों+) या तेज़ मेटाडेटा फ़िल्टरिंग और एक समर्पित API चाहते हों तो इसकी ओर बढ़ें। यह चलाने के लिए एक अलग सेवा है, पर यह ठीक इसी काम के लिए बना है।
अपने पैर जमाते ज़्यादातर एजेंट्स के लिए, pgvector सही पहला जवाब है। जब आप इससे बड़े हो जाएँ तब Qdrant पर जाएँ, पहले नहीं।
RAM की हक़ीक़त (यही वह हिस्सा है जिसे लोग कम आँकते हैं)
वेक्टर खोज तेज़ है क्योंकि इंडेक्स मेमोरी में रहता है — तो RAM, डिस्क नहीं, आपकी असली बाधा है। एक मोटी गाइड:
- कुछ लाख एम्बेडिंग — 2 GB में आरामदेह।
- निचले लाखों — 4 GB+ की योजना बनाएँ और इंडेक्स ट्यून करें।
- डिस्क आसान हिस्सा है: दस लाख एम्बेडिंग सिर्फ़ कुछ GB है, तो 25–45 GB एक गंभीर स्टोर कवर करती है।
तो इंडेक्स के लिए साइज़ करें, फ़ाइल के लिए नहीं। (सामान्य साइज़िंग गाइड जैसा ही तर्क — भारी चीज़ नापने तक स्पष्ट नहीं होती।)
झटपट शुरुआत: pgvector
Postgres वाले एक बॉक्स पर (Docker सबसे आसान है — n8n स्व-होस्ट करने जैसा ही पैटर्न):
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE memory (
id bigserial PRIMARY KEY,
content text,
embedding vector(1536) -- अपने एम्बेडिंग मॉडल के आयामों से मिलाएँ
);
-- डेटा होने के बाद, तेज़ खोज के लिए एक इंडेक्स बनाएँ:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);
आपका एजेंट content + उसका एम्बेडिंग डालता है, फिर सबसे नज़दीकी मेमोरी खींचने के लिए ORDER BY embedding <=> $query_embedding LIMIT 5 से क्वेरी करता है। यही पूरा लूप है।
Qdrant पसंद है? यह एक HTTP/gRPC API उजागर करता एक अकेला Docker कंटेनर है; आप अपने वेक्टर आकार के साथ एक कलेक्शन बनाते और पॉइंट अपसर्ट करते हैं। वही विचार, समर्पित इंजन।
क्या यह एजेंट के साथ एक बॉक्स साझा कर सकता है?
हाँ — छोटे-से-मझोले मेमोरी स्टोर के लिए, वेक्टर DB को एजेंट के समान VPS पर चलाएँ। यह सरल है और लेटेंसी मूलतः शून्य है। उन्हें अलग सर्वरों पर तभी बाँटें जब एक दूसरे को RAM से बाहर भीड़ने लगे। वह एक बाद का, अच्छी-समस्या-रखने-योग्य फ़ैसला है, पहले-दिन का नहीं।
ईमानदार चेतावनियाँ
- RAM दीवार है, और यह शांत है। खोज तब तक तेज़ रहती है जब तक इंडेक्स मेमोरी में फ़िट होता है, फिर यह ख़राब होती है। मेमोरी देखें और इसके काटने से पहले आकार बढ़ाएँ — धीमी क्वेरी के आपको बताने का इंतज़ार न करें।
- एम्बेडिंग बनाने में टोकन ख़र्च होते हैं। आप जो हर दस्तावेज़ एम्बेड करते हैं वह एक एम्बेडिंग मॉडल को एक API कॉल है। स्टोर होस्ट करने में सस्ता है; वेक्टर जनरेट करना आवर्ती लागत है — एक एजेंट चलाने में असल में क्या ख़र्च आता है से प्रासंगिक।
- इसका बैकअप लें। आपके एजेंट की मेमोरी किसी भी अन्य की तरह डेटा है। अगर यह मायने रखती है, इसका स्नैपशॉट लें।
उसके भीतर, एक स्व-होस्टेड वेक्टर स्टोर एक एजेंट को अपना निजी डेटा किसी तीसरे-पक्ष को सौंपे बिना टिकाऊ मेमोरी देने का एक साफ़ तरीक़ा है। एक 2 GB बॉक्स पर pgvector से शुरू करें, RAM पर नज़र रखें, और तभी Qdrant या एक बड़े प्लान में बढ़ें जब आँकड़े आपको कहें।
टिप्पणियाँ
अभी तक कोई टिप्पणी नहीं। पहले बनें।