क्या Postgres आपकी RAG पाइपलाइन संभाल सकता है?

• LLM एक बार में सीमित मात्रा में टेक्स्ट ही “देख” सकते हैं, जिसे कॉन्टेक्स्ट विंडो कहते हैं. यह छोटे कामों के लिए कारगर है, लेकिन हज़ारों पृष्ठों वाले ज्ञान-आधार के साथ विफल होने लगता है. कॉन्टेक्स्ट विंडो पर्याप्त होने पर भी “भूसे के ढेर में सुई” वाली समस्या से प्रदर्शन घट सकता है.

• RAG (“पुनर्प्राप्ति-संवर्धित जनरेशन”) एक बेहद प्रचलित तरीका बन गया है. इसमें आप ज्ञान-आधार (दस्तावेज़, विकी, नीतियाँ, प्रतिलेख आदि) बनाए रखते हैं, उपयोगकर्ता की क्वेरी पर सिमैंटिक खोज करके एम्बेडिंग की मदद से सबसे प्रासंगिक अंश निकालते हैं और फिर प्रश्न के साथ उन हिस्सों को LLM में भेजते हैं. इससे मॉडल का कॉन्टेक्स्ट सीमित रहता है और सही ढंग से लागू करने पर उत्तरों की गुणवत्ता सुधर सकती है तथा मनगढ़ंत जवाब घट सकते हैं.

• pgai एक मुक्त-स्रोत Postgres एक्सटेंशन और सहायक टूलसेट है, जो भरोसेमंद मुक्त-स्रोत डेटाबेस PostgreSQL पर “AI पुनर्प्राप्ति” कार्यप्रवाह बनाने में मदद करता है.

• मुख्य विचार मानक RAG पाइपलाइन का अधिक हिस्सा डेटाबेस स्तर पर ले जाना है (ग्रहण → खंड बनाना → एम्बेड करना → एम्बेडिंग को समकालिक रखना), न कि डेटाबेस को एम्बेडिंग के लिए “सिर्फ़ भंडारण” मानना.

• शुरुआती आकलन में यह आशाजनक लगता है, लेकिन RAG पाइपलाइन थोड़ी भी जटिल होते ही, खासकर खंड बनाने के तरीकों के कारण, यह उपयुक्त नहीं रहता. फिर भी, हम इस परियोजना पर बारीकी से नज़र रखेंगे.

RAG बनाने के कई तरीके हैं. अलग-अलग RAG दृष्टिकोणों का विस्तृत विश्लेषण पढ़ने के लिए अनुकूलित RAG समाधानों के व्यावहारिक उदाहरण. देखें. गुणवत्ता अहम होते ही डिज़ाइन की संभावनाएँ आश्चर्यजनक रूप से जटिल हो जाती हैं और आम “डिफ़ॉल्ट” तरीका सामान्यतः ऐसा होता है:

1. दस्तावेज़ों का एक संग्रह लें.

2. उन्हें खंडों में बाँटें. ऐसा करने के कई तरीके हैं, जैसे अनुच्छेद या अर्थ-आधारित समूह.

3. हर खंड को एम्बेडिंग में बदलें.

4. एम्बेडिंग को किसी वेक्टर डेटाबेस (Pinecone, Milvus आदि) में या pgvector की मदद से Postgres में संग्रहीत करें.

5. क्वेरी के समय सबसे करीबी खंड खोजें `और उन्हें LLM में भेजें. फिर से कहें तो ऐसा करने के भी कई तरीके हैं.

कई तकनीकी स्टैक में चरण (1)–(3) डेटाबेस के बाहर, ऐप्लिकेशन कोड या डेटा पाइपलाइन में पूरे होते हैं और डेटाबेस मुख्यतः इन कामों में उपयोग होता है:

• एम्बेडिंग संग्रहीत करना

• एम्बेडिंग खोजना

pgai एक Postgres एक्सटेंशन है, जो मुक्त-स्रोत है और Timescale ने विकसित किया है. यह उस विभाजन को धुंधला करने का प्रयास करता है.

एम्बेडिंग को ऐप्लिकेशन द्वारा मैन्युअल रूप से प्रबंधित करने के बजाय, pgai उसे डेटाबेस की सुविधा बना देता है:

• आप तय करते हैं कि किस तालिका या किन दस्तावेज़ों को एम्बेड करना है.

• आप एम्बेडिंग मॉडल और खंड बनाने की रणनीति निर्दिष्ट करते हैं.

• बाकी काम pgai संभालता है. स्रोत डेटा बदलने पर एम्बेडिंग को अद्यतन रखना भी इसमें शामिल है.

इसकी संभावनाएँ आकर्षक हैं:

• रखरखाव की ज़रूरत वाला विशेष संयोजक कोड कम हो जाता है.

• मूल स्रोत दस्तावेज़ बदलने पर एम्बेडिंग को “ताज़ा” रखना आसान होना चाहिए.

• Postgres/pgai आपके पुनः प्रयास, दर सीमाएँ, विफल कार्य आदि संभालता है.

पाठक के लिए टिप्पणी: pgai में pgvector भी शामिल है, जो RAG के लिए एक और बेहद लोकप्रिय Postgres एक्सटेंशन है. pgvector, Postgres में वेक्टर भंडारण और समानता खोज जोड़ता है. pgai इसी आधार पर खंड बनाने, एम्बेडिंग तैयार करने और उन्हें अद्यतन रखने जैसे RAG पाइपलाइन चरणों को स्वचालित करता है.

1) इसे शुरू करना आसान है.

सब कुछ सही चले तो प्रक्रिया काफ़ी सरल है:

• Timescale की Docker इमेज (डेटाबेस + वर्कर) डाउनलोड करें.

• अपने एम्बेडिंग प्रदाता की API कुंजी दें.

• वेक्टराइज़र घोषित करने के लिए थोड़ा-सा SQL चलाएँ. यानी क्या एम्बेड करना है, उसके खंड कैसे बनाने हैं और कौन-सा मॉडल इस्तेमाल करना है.

इसके बाद pgai एक अलग प्रक्रिया के रूप में वेक्टराइज़र वर्कर चलाता है और एम्बेडिंग अतुल्यकालिक रूप से बनाता है, जैसे हर 5 मिनट पर या आपकी पसंद के किसी भी अंतराल पर.

2) पूरी पाइपलाइन को डेटाबेस के “पास” चलाना सुविधाजनक है.

pgai तालिकाओं से सामग्री ग्रहण कर सकता है. यह S3 जैसी जगहों से दस्तावेज़ लोड करके उनका विश्लेषण, खंडीकरण और एम्बेडिंग भी कर सकता है. यह PDF, Markdown आदि जैसे अलग-अलग टेक्स्ट दस्तावेज़ प्रारूप भी संभाल सकता है.

1) आपका बहुत-सा नियंत्रण छिन जाता है, जबकि RAG में कभी-कभी नियंत्रण ज़रूरी होता है.

उत्तर की गुणवत्ता के आधार पर मापे जाने वाले उच्च-प्रदर्शन RAG सिस्टम को अक्सर विशेष पाइपलाइन की ज़रूरत होती है, जैसे:

• अनुकूलित खंडीकरण नियम, जैसे शीर्षक, पृष्ठ या वक्ता बदलने के आधार पर

• मेटाडेटा को ध्यान में रखने वाला खंडीकरण, जिसमें अनुभाग शीर्षक, समय-मुद्राएँ, लेखक और दस्तावेज़ प्रकार सुरक्षित रहें

• हर दस्तावेज़ प्रकार के लिए अलग एम्बेडिंग रणनीतियाँ

उपरोक्त मामलों में pgai कम लचीलापन देता है.

फिलहाल खंडीकरण की दो मुख्य रणनीतियाँ हैं: वर्ण-आधारित टेक्स्ट विभाजक और पुनरावर्ती वर्ण-आधारित टेक्स्ट विभाजक. इसके अलावा, खंडीकरण न करने का विकल्प भी है. यह कुछ उपयोग मामलों के लिए पर्याप्त हो सकता है, लेकिन उत्पादन में इस्तेमाल होने वाले कई RAG सिस्टम को अधिक अनुकूलन चाहिए.

अगर Timescale, Chonkie जैसी लाइब्रेरी में मिलने वाली कुछ अधिक परिष्कृत खंडीकरण रणनीतियाँ शामिल कर सके और Anthropic की प्रासंगिक पुनर्प्राप्ति जैसे उन्नत डिज़ाइन का भी समर्थन करे, तो यह शानदार होगा.

2) टेक्स्ट-प्रथम, बहुविध नहीं.

RAG की कई दिलचस्प समस्याएँ अब केवल टेक्स्ट तक सीमित नहीं हैं:

• आरेखों वाली PDF फ़ाइलें

• स्क्रीनशॉट / चित्र

• ऑडियो रिकॉर्डिंग

• वीडियो क्लिप

इन स्रोतों से “टेक्स्ट निकाला” जा सके, तब भी यह वास्तविक बहुविध एम्बेडिंग पाइपलाइन के समान नहीं है.

अगर pgai अंततः शुरू से अंत तक बहुविध मॉडल का समर्थन करे, यानी S3 में रखे बड़े चित्र, ऑडियो और वीडियो को मज़बूत समकालन के साथ लोड → खंडित → एम्बेड करे, तो यह बेहद उपयोगी होगा. लेकिन आज यह टेक्स्ट एम्बेडिंग कार्यप्रवाह है.

3) अगर आपको केवल एम्बेडिंग चाहिए, तो शायद pgai की ज़रूरत नहीं है.

अगर आपकी ग्रहण पाइपलाइन पहले से अनुकूलित है या उसे ऐसा होना ही है, तो “टेक्स्ट के खंडों को एम्बेड करना” RAG का सबसे कठिन हिस्सा नहीं है. ऐसी स्थिति में pgai समस्या के सबसे आसान हिस्से को हल कर रहा है.

साथ ही, अगर आपका ज्ञान-आधार बहुत कम अद्यतन होता है, तो स्वचालित एम्बेडिंग समकालन का महत्व भी उतना अधिक नहीं रहता.

pgai का एक विशेष रूप से अच्छा उपयोग अपने डेटाबेस के ऊपर टेक्स्ट-टू-SQL इंटरफ़ेस तैनात करना होगा. pgai के semantic_catalog मॉड्यूल से यह काफ़ी आसानी से किया जा सकता है. बस इसे इस तरह सेट अप करें:

1OPENAI_API_KEY="your-OpenAPI-key-goes-here"2TARGET_DB="postgres://user:password@host:port/database"3CATALOG_DB="postgres://user:password@host:port/database"

और pgai semantic-catalog create की मदद से सिमैंटिक कैटलॉग को आपकी डेटा डिक्शनरी से जानकारी लेने दें. इससे आपके डेटा भंडार के आधार पर ऐसा कॉन्टेक्स्ट बनता है:

1---2schema: postgres_air3name: aircraft4type: table5description: Lists aircraft models with performance characteristics and unique codes.6columns:7- name: model8  description: Commercial name of the aircraft model.9- name: range10  description: Maximum flight range in kilometers.11- name: class12  description: Airframe class category or configuration indicator.13- name: velocity14  description: Cruising speed of the aircraft.15- name: code16  description: Three-character aircraft code serving as the primary key.17...

अब यह कॉन्टेक्स्ट pgai को कई तरीकों से उपलब्ध है:

सिमैंटिक खोज के माध्यम से:

यह क्वेरी वे तालिकाएँ, फ़ंक्शन और अन्य ऑब्जेक्ट लौटाएगी जो आपकी स्वाभाविक भाषा वाली क्वेरी के लिए प्रासंगिक हो सकते हैं:

1pgai semantic-catalog search -p "Your natural language question goes here!"

अपरिष्कृत कॉन्टेक्स्ट पाएँ:

यह आपकी स्वाभाविक भाषा वाली क्वेरी से संबंधित अपरिष्कृत YAML कॉन्टेक्स्ट प्रदर्शित करेगा:

1pgai semantic-catalog search -p "Your natural language question goes here!" --render

SQL जनरेट करें:

या अपनी क्वेरी का उत्तर देने के लिए आवश्यक अपरिष्कृत SQL सीधे जनरेट कर सकते हैं. पिछले चरण का कॉन्टेक्स्ट LLM को भेजा जाता है और जवाब जनरेट होता है:

1pgai semantic-catalog generate-sql -p "Your natural language question goes here!"

अगर आप अपेक्षाकृत सरल RAG सिस्टम बना रहे हैं, तो इन ज़रूरतों के लिए pgai आज़माया जा सकता है:

• रिकॉर्ड की आधिकारिक प्रणाली के रूप में Postgres,

• बहुत कम संयोजक कोड,

• अपने-आप समकालिक रहने वाली एम्बेडिंग,

• अपने डेटाबेस पर टेक्स्ट-टू-SQL लागू करने का तेज़ तरीका,

• नए RAG टूल और Postgres एक्सटेंशन आज़माना.

अगर आपकी RAG पाइपलाइन को इनमें से किसी चीज़ की ज़रूरत है, तो शायद pgai के लिए अभी प्रतीक्षा करना बेहतर होगा:

• अत्यधिक अनुकूलित ग्रहण या खंडीकरण तर्क

• अलग-अलग विश्लेषण आवश्यकताओं वाले कई दस्तावेज़ प्रकार

• बहुविध एम्बेडिंग

अंत में, यह साफ़ है कि pgvector को बड़े पैमाने पर अपनाया गया है, लेकिन pgai को उतनी ही रुचि और इसलिए उतना समर्थन मिलेगा या नहीं, यह स्पष्ट नहीं है. हालाँकि इसे आए अभी लगभग 18 महीने ही हुए हैं.

pgai, RAG के लिए एक दिलचस्प दृष्टिकोण है. यह डेटाबेस को रोज़मर्रा के अधिक संचालन संबंधी काम करने देता है, जिससे आपका ऐप्लिकेशन कोड सरल रह सकता है.

फिलहाल यह:

• सरल RAG व्यवस्थाओं के लिए उपयोगी और वास्तव में सुविधाजनक है

• अधिक विशिष्ट पाइपलाइन, खासकर बहुविध पाइपलाइन, के लिए पर्याप्त लचीला नहीं है

यह आशाजनक है और इसकी प्रगति पर नज़र रखना निश्चित रूप से सार्थक होगा.