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 प्रणालींना अधिक सानुकूलन आवश्यक असते.

Chonkie सारख्या ग्रंथालयांत दिसणाऱ्या अधिक प्रगत भाग-विभाजन रणनीती Timescale ने समाविष्ट केल्या आणि Anthropic ची संदर्भाधारित माहिती-पुनर्प्राप्ती यांसारख्या प्रगत रचनांना पाठबळ दिले, तर उत्तम होईल.

2) बहुमाध्यमी नव्हे, तर मजकूर-केंद्री.

RAG मधील अनेक रंजक समस्या आता केवळ मजकुरापुरत्या मर्यादित राहिलेल्या नाहीत:

• आकृत्या असलेले PDF

• पटलचित्रे किंवा प्रतिमा

• ध्वनिमुद्रणे

• चित्रफीत अंश

या स्रोतांमधून “मजकूर काढता” आला, तरी ती खरी बहुमाध्यमी एम्बेडिंग प्रक्रिया ठरत नाही.

भविष्यात pgai ने बहुमाध्यमी मॉडेलना संपूर्ण प्रक्रियेत पाठबळ दिले, म्हणजे S3 मध्ये साठवलेल्या मोठ्या प्रतिमा, ध्वनी किंवा चित्रफिती घेऊन त्यांचे भाग पाडणे, एम्बेडिंग करणे आणि विश्वसनीय समक्रमण करणे शक्य झाले, तर ते प्रभावी ठरेल. मात्र आज तो मजकूर एम्बेडिंगचा कार्यप्रवाह आहे.

3) तुम्हाला केवळ एम्बेडिंग हवे असल्यास pgai ची गरज नसू शकते.

तुमची डेटा-ग्रहण प्रक्रिया आधीपासून सानुकूल असेल किंवा तशी असणे आवश्यक असेल, तर “मजकुराच्या भागांचे एम्बेडिंग करणे” हा RAG मधील सर्वांत कठीण भाग नाही. अशा परिस्थितीत pgai समस्येतील सर्वांत सोपा भाग सोडवत आहे.

तसेच, तुमचा ज्ञानसंग्रह क्वचित अद्ययावत होत असेल, तर एम्बेडिंगच्या स्वयंचलित समक्रमणाचे मूल्य तितकेसे राहत नाही.

तुमच्या डेटाबेसवर मजकूर-ते-SQL संवादपटल उपलब्ध करणे हा pgai वापरण्याचा विशेषतः चांगला मार्ग ठरू शकतो. 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 वापरून तुमच्या डेटा शब्दकोशांमधील माहिती semantic catalog मध्ये संकलित करा. यामुळे तुमच्या डेटा-संग्रहातून साधारणपणे असा दिसणारा संदर्भ तयार होतो:

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 महिने झाले आहेत.

डेटाबेसकडून RAG मधील अधिक नियमित परिचालन कामे करून घेण्याची pgai ची पद्धत रंजक आहे. त्यामुळे अनुप्रयोगाचा कोड अधिक सोपा ठेवता येतो.

सध्या तो:

• सोप्या RAG रचनांसाठी वापरण्यायोग्य आणि खरोखरच सोयीचा आहे

• अधिक सानुकूल प्रक्रियांसाठी, विशेषतः बहुमाध्यमी प्रक्रियांसाठी, पुरेसा लवचिक नाही

तो आशादायक आहे आणि त्याची प्रगती कशी होते यावर नक्कीच लक्ष ठेवण्यासारखे आहे.