लोक सतत RAG साठी श्रद्धांजली लिहीत आहेत. तुम्ही आतापर्यंत त्या हेडलाईन्स नक्कीच पाहिल्या असतील. लांब कॉन्टेक्स्ट विंडोजमुळे (Long context windows) ते संपले. एजंट्सनी त्याची जागा घेतली. संपूर्ण पॅटर्नच कालबाह्य झाला आहे. पण सत्य यापेक्षा अधिक मर्यादित आणि अत्यंत उपयुक्त आहे. RAG संपलेले नाही. प्रत्यक्षात ज्या गोष्टीचा भ्रम होता, तो कोसळला आहे—तो भ्रम म्हणजे तुम्ही कागदपत्रांचा ढीग तुकड्यांमध्ये (chunks) विभागू शकता, ते वेक्टर डेटाबेसमध्ये टाकू शकता आणि अचानक तुमच्याकडे एक विश्वसनीय, सत्य सांगणारा AI असेल.

काही वर्षांपूर्वी, याचे सादरीकरण त्याच्या साधेपणामुळे मोहक वाटत होते. तुमचा नॉलेज बेस एम्बेड करा. त्याला LLM शी जोडा. एक प्रश्न विचारा आणि मॉडेलने केवळ तुमच्या डेटाचा वापर करून उत्तर देताना पहा. नियंत्रित डेमो आणि लहान FAQ बॉट्ससाठी, हे खरंच काम करायचे. वीस पानांचे हेल्प डेस्क मॅन्युअल असो किंवा एखादा व्यवस्थित अंतर्गत विकी (internal wiki). बॉट साधारणपणे योग्य परिच्छेद उद्धृत करायचा आणि नेतृत्व (leadership) त्या पायलट प्रोजेक्टला मंजुरी द्यायचे. पण पायलट म्हणजे प्रोडक्शन नाही. प्रोटोटाइप्समध्ये प्रत्यक्ष व्यावसायिक कामकाजातील आव्हाने आणि अनुभव नसतात.

प्रोडक्शन डेटा गोंधळलेला असतो. त्यात एकाच प्रकारची ट्रबलशूटिंग नोट डझनभर फाईल्समध्ये कॉपी केलेली असू शकते, ज्यामध्ये वेगवेगळे टाइमस्टॅम्प्स आणि परस्परविरोधी स्टेटस लेबल्स असू शकतात. त्यात अशी जटिल टेबल्स असतात जी पानांच्या पलीकडे पसरलेली असतात, आणि जेव्हा एखादा 'स्प्लिटर' (splitter) त्यांना मधूनच कापतो, तेव्हा त्यातून अर्थहीन माहिती मिळते. तो विरोधाभासही जतन करतो. २०२३ च्या पॉलिसी मॅन्युअलमध्ये एक गोष्ट लिहिली आहे, तर मार्च २०२४ च्या सुधारणेमध्ये (amendment) दुसरी गोष्ट. जुना PDF कधीच आर्काइव्ह केला गेला नाही. चंक (chunk), स्टोअर आणि रिट्रिव्ह (retrieve) ही साधी पद्धत प्रत्येक परिच्छेदाकडे एक स्वतंत्र बेट म्हणून पाहते. तिला हायरार्की (hierarchy), व्हर्जन हिस्ट्री किंवा संघर्ष निवारणाचे (conflict resolution) भान नसते. मॉडेल हॅल्युसिनेट (hallucinate) करते कारण LLM खराब आहे म्हणून नाही, तर त्याला मिळालेला कॉन्टेक्स्ट (context) तुकड्यांमध्ये विभागलेला, विस्कळीत किंवा पूर्णपणे चुकीचा असतो.

काही निरीक्षकांचे म्हणणे आहे की मिलियन-टोकन कॉन्टेक्स्ट विंडोजमुळे (million-token context windows) रिट्रिव्हलची गरज उरलेली नाही. त्यांचा युक्तिवाद सरळ आहे. संपूर्ण मजकूर प्रॉम्प्टमध्ये टाका आणि मॉडेलला तो वाचू द्या. हे ऐकायला सुटसुटीत वाटते, पण ते धोकादायकपणे आशावादी आहे. एखादे मॉडेल तांत्रिकदृष्ट्या एका लहान कादंबरीइतका मजकूर ग्रहण करण्यास सक्षम असू शकते, तरीही त्या अफाट मजकुरातून एखादा विशिष्ट क्लॉज (clause) शोधणे ही पूर्णपणे वेगळी क्षमता आहे. गवताच्या ढिगाऱ्यात सुई शोधणे अजूनही कठीण आहे. लांब कॉन्टेक्स्ट विंडोज उपलब्ध जागा वाढवतात, पण त्या कॅनव्हासवर नक्की काय असावे हे ठरवण्याचे कठीण काम ते सोडवत नाहीत. समस्या कधीच केवळ रिट्रिव्हलची नव्हती. ती नेहमीच 'कॉन्टेक्स्ट असेंब्ली'ची (context assembly) होती.

साध्या रिट्रिव्हलपासून कॉन्टेक्स्ट इंजिनीअरिंगपर्यंत

२०२६ मध्ये, हे क्षेत्र प्रगल्भ होत आहे. आपण अशा टप्प्यातून पुढे जात आहोत जिथे RAG कडे केवळ एक सरळ पाईपलाईन म्हणून पाहिले जात असे, आणि आता आपण अशा आर्किटेक्चरकडे वळत आहोत जिथे कॉन्टेक्स्टला एक हेतुपुरस्सर इंजिनीअर केलेले उत्पादन (engineered product) मानले जाते.

शुद्ध सिमेंटिक्सपेक्षा हायब्रिड सर्च (Hybrid search). सिमेंटिक साम्य (Semantic similarity) हे हेतू समजून घेण्यासाठी उत्कृष्ट आहे, परंतु अचूक आयडेंटिफायर्ससाठी ते अपुरे पडते. जर एखादा इंजिनिअर ERR_CONNECTION_REFUSED सारखा विशिष्ट एरर कोड किंवा v3.2.1 सारखा सॉफ्टवेअर व्हर्जन शोधत असेल, तर शुद्ध वेक्टर सर्च (pure vector search) संकल्पनादृष्ट्या समान पण प्रत्यक्षात अप्रासंगिक असलेल्या निकालांच्या महासागरात अचूक मॅच शोधण्यात कमी पडू शकते. येथील उत्क्रांती सरळ आहे. आधुनिक प्रणाली कीवर्ड सर्चसोबत (keyword search) डेंस वेक्टर रिट्रिव्हल (dense vector retrieval) एकत्र करतात, ज्यामध्ये एम्बेडिंग्जसोबत BM25 किंवा इन्व्हर्टेड इंडेक्स (inverted indexes) सारख्या पद्धतींचा वापर केला जातो. नेमकी नावे, एरर कोड, व्हर्जन स्ट्रिंग्स आणि प्रॉडक्ट आयडी कीवर्ड लेयरद्वारे पकडले जातात, तर संकल्पनात्मक बारकावे वेक्टर लेयरद्वारे हाताळले जातात.

जनरेशनपूर्वी रँकिंग (Reranking). रिट्रिव्हल हे नैसर्गिकरित्या 'रिकॉल' (recall) कडे झुकलेले असते. एखादा महत्त्वाचा परिच्छेद सुटून जाऊ नये म्हणून तुम्ही चाळीस-पन्नास चंक्स (chunks) खेचून आणता. पण हे सर्व गोंधळ (noise) मोठ्या मॉडेलमध्ये टाकल्यामुळे टोकन्स वाया जातात आणि महत्त्वाचा सिग्नल दबला जातो. रँकिंग यावर उपाय शोधते; यासाठी दुसरे, सहसा लहान मॉडेल वापरले जाते जे प्रत्येक संभाव्य परिच्छेदाला विशिष्ट क्वेरीच्या संदर्भात गुण (score) देते. त्यातील टॉप पाच परिच्छेद पुढे जातात आणि बाकीचे काढून टाकले जातात. हे रिट्रिव्हल आणि जनरेशन दरम्यान एक अचूक फिल्टर म्हणून काम करते, ज्यामुळे महागड्या रिझनिंग मॉडेलला केवळ खरोखर महत्त्वाचा मजकूरच वाचावा लागतो.

अर्थ जपणारे कॉन्टेक्स्ट्युअल रिट्रिव्हल (Contextual retrieval). चंकिंग (Chunking) ही एक हिंसक प्रक्रिया आहे. एखादा स्प्लिटर एखाद्या परिच्छेदाला त्याच्या सेक्शन हेडरपासून, टेबल कॅप्शनपासून, त्याच्या आसपासच्या कायदेशीर डिस्क्लेमरपासून किंवा त्याच्या अर्थाला बदलणाऱ्या फुटनोटपासून वेगळे करू शकतो. कॉन्टेक्स्ट्युअल रिट्रिव्हल हे तुकडे मॉडेलपर्यंत पोहोचण्यापूर्वीच त्यांना समृद्ध करून ही समस्या कमी करते. तुम्ही त्यासोबत मेटाडेटा (metadata) जोडता जो त्याचा उगम दर्शवतो: हा उतारा Q3 2024 च्या इन्सिडेंट रिपोर्टमधील, Database Outage विभागातील आणि Severity Critical श्रेणीतील आहे. मॉडेलला केवळ एक तरंगता वाक्य दिसत नाही, तर संदर्भासह असलेली माहिती दिसते. त्या तुकड्याला पुन्हा त्याचा मूळ संदर्भ प्राप्त होतो.

हेतूनुसार (intent) मॉड्युलर राउटिंग. प्रत्येक प्रश्नासाठी डॉक्युमेंटेशनने भरलेल्या वेक्टर स्टोअरची गरज नसते. पासवर्ड कसा रिसेट करायचा हे विचारणाऱ्या वापरकर्त्याला बहुधा एका हेल्प आर्टिकलची गरज असते. गेल्या तिमाहीत ईशान्य भागात महसूल का घटला हे विचारणाऱ्या वापरकर्त्याला डेटा वेअरहाऊसवर SQL क्वेरीची गरज असते, प्रादेशिक विक्री धोरणाबद्दलच्या अर्थपूर्ण परिच्छेदाची नाही. प्रगत प्रणाली आता हेतूनुसार (intent) क्वेरी राउट करतात आणि योग्य साधन निवडतात. प्रक्रियेसाठी डॉक्युमेंटेशन. स्ट्रक्चर्ड ॲनालिटिक्ससाठी रिलेशनल डेटाबेस. ट्रेस डीबगिंगसाठी लॉग अ‍ॅग्रिगेटर्स. लाईव्ह स्टेटससाठी APIs. रिट्रिव्हल लेयर आता एक 'डिस्पॅचर' बनतो, केवळ एकच प्रकारचा स्रोत (monoculture) राहत नाही.

एजेंटिक रिझनिंग लूप्स (Agentic reasoning loops). काही प्रश्नांची उत्तरे एकाच शोध टप्प्यात देता येत नाहीत. त्यांना पुनर्रचनेची (reformulation) गरज असते. अस्पष्ट सुरुवातीची क्वेरी स्पष्ट केली जाते. मिळवलेले दावे दुसऱ्या स्रोताशी पडताळून पाहिले जातात. जर डॉक्युमेंटेशन आणि API स्पेसिफिकेशनमध्ये विसंगती असेल, तर प्रणाली कोणताही मध्यमार्ग शोधण्याऐवजी त्या संघर्षाकडे लक्ष वेधते. मॉडेल कधी पुन्हा शोधायचे, कधी आपली क्वेरी सुधारून घ्यायची आणि उत्तर देण्यासाठी पुरेसा पुरावा कधी गोळा झाला आहे, हे स्वतः ठरवते. हे 'वन-शॉट रिट्रिव्हल' नाही. हे एक स्ट्रक्चर्ड रिझनिंग आहे जे शोध (search) चा वापर सबरुटीन (subroutine) म्हणून करते.

रिलेशनल प्रश्नांसाठी GraphRAG. काही व्यावसायिक प्रश्न वाक्यांविषयी नसून संबंधांविषयी असतात. कोणत्या घटकाच्या बिघाडामुळे कोणते डाउनस्ट्रीम अलर्ट आले? कोणता पुरवठादार कोणत्या कारखान्याला माल पुरवतो आणि पर्यायी मार्ग कोणता आहे? संस्थेमध्ये या विशिष्ट बजेट लाइनवर कोणाचे निर्णय घेण्याचे अधिकार आहेत? फ्लॅट टेक्स्ट चंक्स (Flat text chunks) हे संबंधांना सपाट करतात कारण त्यांची रचना टोपोलॉजी (topology) जपण्यासाठी केलेली नसते. नॉलेज ग्राफ्स (Knowledge graphs) हे करू शकतात. जेव्हा प्रश्न प्रभाव, वंशावळ (lineage), नमुने (patterns) किंवा नेटवर्क स्ट्रक्चरबद्दल असतो, तेव्हा ग्राफचा वापर केल्याने असा संदर्भ मिळतो जो केवळ परिच्छेद शोधून (paragraph retrieval) मिळवणे अशक्य आहे.

खरोखर महत्त्वाचे असलेले प्रश्न

RAG संदर्भातील चर्चा बदलण्याची गरज आहे. केवळ एक सामान्य RAG पाइपलाइन कशी तयार करायची हे विचारणे थांबवा. मॉडेलने नेमके कोणते कार्य पूर्ण केले पाहिजे, अचूकतेसाठी त्याला नेमका कोणता डेटा हवा आहे आणि गोळा केलेला संदर्भ पुरेसा आहे की नाही हे तुम्ही कसे तपासता, हे विचारण्यास सुरुवात करा. हे प्रश्न तुम्हाला डेटा गुणवत्ता, स्कीमा डिझाइन, व्हेरिफिकेशन लूप्स आणि स्रोतांच्या मूळ माहितीकडे (source provenance) नेतात. तुमच्या नॉलेज बेसचा स्वयंचलित वापरासाठी (automated consumption) उपयोग होऊ शकतो की नाही, हे यातून स्पष्ट होते.

RAG ही आता केवळ एकदा इन्स्टॉल करून विसरण्याची एक रेखीय प्रक्रिया राहिलेली नाही. मॉडेल प्रभावीपणे विचार करू शकेल यासाठी योग्य संदर्भ गोळा करणे ही एक शिस्त आहे. याचा अर्थ असा की रिट्रिव्हलकडे केवळ एक लायब्ररी इम्पोर्ट म्हणून न पाहता, एक 'सिस्टम डिझाइन' समस्या म्हणून पाहणे.

साधने अधिक प्रगत होत आहेत. सर्च आता हायब्रिड आहे. राउटिंग इंटेलिजंट आहे. रिट्रिव्हल आता रँक्ड, एनरिच्ड आणि व्हेरिफाईड आहे. २०२२ मधील साध्या भ्रमांचा अंत होणे आवश्यक होते, जेणेकरून खरोखर उपयुक्त गोष्टींचा उदय होऊ शकेल. तुमचे काम आता केवळ डेटाबेसमधून मजकूर शोधणे हे नाही. तर मॉडेलने विचार करण्यास सुरुवात करण्यापूर्वीच त्याला कशाची गरज आहे, हे समजून घेणारी प्रणाली तयार करणे हे आहे.

जर तुम्ही या क्षेत्रात काम करत असाल, तर GyaanSetu लर्निंग कम्युनिटी ही अशा लोकांशी व्यावहारिक अनुभव आणि माहिती शेअर करण्यासाठी एक उत्तम जागा आहे जे तुमच्यासारख्याच समस्या सोडवत आहेत: https://t.me/GyaanSetuAi