अधिकांश RAG ट्यूटोरियल डेमो पर ही समाप्त हो जाते हैं। आप टोकन काउंट के आधार पर चंकिंग (chunking) करते हैं, सब कुछ एक वेक्टर डेटाबेस में डाल देते हैं, और काम खत्म मान लेते हैं। यह तब काम करता है जब कोई उपयोगकर्ता किसी साफ-सुथरे FAQ में "रिटर्न पॉलिसी क्या है?" जैसा सवाल पूछता है। लेकिन यह तब विफल हो जाता है जब कोई आधा कॉन्ट्रैक्ट पेस्ट करता है और तीसरे क्लॉज (clause) के बारे में पूछता है, या जब कोई डेवलपर आपके डॉक्यूमेंटेशन सर्च में कोई अस्पष्ट एरर कोड टाइप करता है।

फिक्स्ड टोकन विंडो कानूनी समझौतों को वाक्य के बीच में ही काट देती हैं। बड़े चंक्स (chunks) API संदर्भों को शोर भरे पैराग्राफों के नीचे दबा देते हैं। सबसे बुरा यह है कि धीमी रिट्रीवल (retrieval) के कारण उपयोगकर्ता मॉडल द्वारा जनरेट करना शुरू करने से पहले ही क्वेरी छोड़ देते हैं। हमने यह सबक कठिन अनुभव से सीखा। जब हमने अपने रिट्रीवल लेयर को केवल उम्मीद के भरोसे छोड़ने के बजाय मापन (measurement) पर आधारित किया, तो हमने लेटेंसी (latency) को चालीस प्रतिशत कम कर दिया और रिकॉल (recall) को पचानवे प्रतिशत तक पहुँचा दिया। यहाँ बताया गया है कि वास्तव में क्या बदला।

Smart Chunking

चंक साइज (chunk size) को कोई जादुई नंबर समझना बंद करें। 512-टोकन विंडो ऐसे कानूनी दस्तावेज़ के लिए कोई मायने नहीं रखती जहाँ एक अकेला क्लॉज कई पैराग्राफों तक फैला हो, और यह API डॉक्स के लिए भी उतना ही बेकार है जहाँ एक फंक्शन सिग्नेचर और उसका दो-लाइन का विवरण एक साथ रहना चाहिए। हम स्ट्रक्चर-अवेयर स्प्लिटिंग (structure-aware splitting) पर आ गए।

कानूनी टेक्स्ट के लिए, रिकर्सिव चंकिंग (recursive chunking) दस्तावेज़ के पदानुक्रम (hierarchy) का सम्मान करती है। क्लॉज सुरक्षित रहते हैं। API डॉक्यूमेंटेशन के लिए, हम फंक्शन-अवेयर स्प्लिटिंग (function-aware splitting) का उपयोग करते हैं जो सिग्नेचर, पैरामीटर्स और उदाहरणों को परमाणु इकाइयों (atomic units) के रूप में एक साथ रखता है। सपोर्ट टिकटों और संवादात्मक डेटा (conversational data) को सिमेंटिक सीमाओं (semantic boundaries) की आवश्यकता होती है, जहाँ विषय बदलता है वहाँ स्प्लिटिंग होनी चाहिए, न कि किसी मनमाने कैरेक्टर काउंट पर। इसका परिणाम यह है कि प्रत्येक चंक उपयोगी होने के लिए पर्याप्त संदर्भ (context) रखता है, लेकिन इतना भी नहीं कि वह सिग्नल को कमज़ोर कर दे। आपके एम्बेडिंग मॉडल (embedding model) का अटेंशन बजट सीमित होता है। इसे समझदारी से खर्च करें।

Hybrid Retrieval

वेक्टर सर्च वैचारिक रूप से समान सामग्री खोजने में उत्कृष्ट है। धीमी डेटाबेस क्वेरी के बारे में पूछें और यह परफॉरमेंस ट्यूनिंग गाइड सामने ले आता है। लेकिन "Error 0x80070057" के बारे में पूछें और सिमेंटिक सर्च असंबंधित क्षेत्रों में भटक जाता है क्योंकि डेंस एम्बेडिंग्स (dense embeddings) सटीक मिलान (exact matches) को अच्छी तरह से नहीं संभाल पाते हैं। दूसरी ओर, BM25 सटीक स्ट्रिंग्स और दुर्लभ शब्दों को सटीक रूप से पकड़ लेता है, फिर भी इसे यह पता नहीं होता कि "latency" और "slow response time" का अर्थ एक ही है।

हम दोनों को समानांतर (parallel) में चलाते हैं और उन्हें Reciprocal Rank Fusion के साथ मर्ज करते हैं। RRF सरल और प्रभावी है। यह प्रत्येक विधि से रैंक की गई सूचियों को लेता है और उनकी स्थिति के आधार पर दस्तावेज़ों को स्कोर देता है, जिससे किसी भी सिस्टम के मजबूत उम्मीदवारों को उचित अवसर मिलता है। फ्यूजन के बाद, हम संयुक्त परिणामों पर एक cross-encoder reranker चलाते हैं और केवल शीर्ष पांच परिणाम वापस करते हैं। reranker लगभग पचास मिलीसेकंड की लेटेंसी जोड़ता है लेकिन इसने हमारे रिकॉल को पंद्रह प्रतिशत तक सुधार दिया। जनरेशन की गुणवत्ता में यह ट्रेड-ऑफ कई गुना सार्थक साबित होता है।

Query Expansion

उपयोगकर्ता क्वेरी करने में बहुत खराब होते हैं। वे शब्दों को छोटा कर देते हैं, गलत वर्तनी (misspell) लिखते हैं, या तीन सवालों को एक लंबे भटकाव में भर देते हैं। यदि आप ठीक वही खोजते हैं जो उन्होंने टाइप किया है, तो आप उन दस्तावेज़ों को मिस कर देते हैं जिनकी उन्हें वास्तव में आवश्यकता है।

अब हम इंडेक्स तक पहुँचने से पहले हर क्वेरी को ट्रांसफॉर्म करते हैं। सबसे पहले, हम पर्यायवाची शब्दों और वैकल्पिक वाक्यांशों को कवर करने के लिए मूल प्रश्न के कई पुनर्गठित (rephrased) संस्करण तैयार करते हैं। दूसरा, हम जटिल प्रश्नों को छोटे उप-प्रश्नों (sub-questions) में तोड़ देते हैं। "Why is the refund failing for international customers and how do I fix it?" जैसी क्वेरी दो अलग-अलग खोजों में बदल जाती है: एक अंतरराष्ट्रीय रिफंड विफलताओं के बारे में और दूसरी सुधार के कदमों (remediation steps) के बारे में। केवल क्वेरी एक्सपेंशन ने हमारे रिकॉल को अठहत्तर प्रतिशत से बढ़ाकर चौरानवे प्रतिशत कर दिया। सबक सीधा है: उपयोगकर्ता के पहले ड्राफ्ट पर भरोसा न करें। उनकी मदद करें।

Stop Guessing, Start Searching

चंक साइज, ओवरलैप प्रतिशत, top-k कटऑफ और reranker की गहराई ऐसे तरीकों से परस्पर क्रिया (interact) करती है जिन्हें हाथ से ट्यून करना असंभव है। हमने इस बात पर बहस करने में बहुत अधिक समय बर्बाद किया कि क्या 256 टोकन 512 से बेहतर थे, जबकि हम उस ओवरलैप सेटिंग को नज़रअंदाज़ कर रहे थे जो वास्तव में सुसंगतता (coherence) को नष्ट कर रही थी।

हमने अंतर्ज्ञान (intuition) को Bayesian optimization से बदल दिया। ग्रिड सर्च के बजाय, जो स्पष्ट रूप से खराब क्षेत्रों पर कंप्यूट बर्बाद करता है, Bayesian तरीके इस बात का एक संभाव्य मॉडल (probabilistic model) बनाते हैं कि क्या काम करता है और सक्रिय रूप से उस Pareto frontier की तलाश करते हैं जो लेटेंसी को कम करते हुए रिकॉल को अधिकतम करता है। हमारे स्टैक के लिए, इसका मतलब चंक साइज, ओवरलैप और top-k का वह विशिष्ट संयोजन खोजना था जिसने हमारे लेटेंसी बजट को बिगाड़े बिना हमें पचानवे प्रतिशत रिकॉल दिया। अलग-अलग उपयोग के मामलों (use cases) के लिए उस फ्रंटियर पर अलग-अलग बिंदु मिले। ग्राहक-केंद्रित चैटबॉट्स ने गति को प्राथमिकता दी। आंतरिक कानूनी अनुसंधान ने रिकॉल को प्राथमिकता दी। स्वचालित अनुकूलन (automated optimization) ने हमें कॉन्फ़िगरेशन फ़ाइलों को मैन्युअल रूप से कॉपी-पेस्ट किए बिना दोनों को सेवा देने की अनुमति दी।

The Results

आंकड़े स्पष्ट रूप से सब कुछ कह रहे हैं। हमारा Recall@10 बहत्तर प्रतिशत से बढ़कर पचानवे प्रतिशत हो गया। p95 latency 850 मिलीसेकंड से घटकर 320 मिलीसेकंड रह गई। और क्योंकि मॉडल को अंततः शोर (noise) के बजाय प्रासंगिक संदर्भ (relevant context) मिलने लगा, इसलिए hallucination rate बारह प्रतिशत से गिरकर तीन प्रतिशत हो गया। बेहतर रिट्रीवल न केवल उत्तरों को तेज़ बनाता है, बल्कि उन्हें सटीक भी बनाता है।

आगे क्या करें

यदि आप अपने रिट्रीवल लेयर (retrieval layer) को फिर से बना रहे हैं, तो यहाँ से शुरुआत करें:

  • टोकन काउंट के बजाय दस्तावेज़ की संरचना के आधार पर चंक (chunk) करें। अपनी स्प्लिटिंग रणनीति (splitting strategy) को अपने डेटा के स्वरूप के अनुसार ढालें।
  • हाइब्रिड रिट्रीवल (hybrid retrieval) का उपयोग करें। वेक्टर सर्च (vector search) और BM25 को मिलाएं, Reciprocal Rank Fusion के साथ मर्ज करें, और जनरेट करने से पहले री-रैंक (rerank) करें।
  • बेहतर कवरेज के लिए क्वेरीज़ (queries) का विस्तार करें। सर्च चलने से पहले उन्हें फिर से लिखें (rephrase) और विघटित (decompose) करें।
  • टेस्टिंग के लिए एक गोल्डन डेटासेट (golden dataset) बनाएं। आप उस चीज़ को ऑप्टिमाइज़ नहीं कर सकते जिसे आप माप नहीं सकते।
  • ऑटोमेटेड टूल्स के साथ पैरामीटर्स को ऑप्टिमाइज़ करें। बेयसियन सर्च (Bayesian search) आपके अंदाज़े से बेहतर सेटिंग्स ढूंढ लेगा।

रिट्रीवल कोई ऐसी कॉन्फ़िगरेशन फ़ाइल नहीं है जिसे आप एक बार सेट करके भूल जाएं। यह इंफ्रास्ट्रक्चर है, और इंफ्रास्ट्रक्चर भी प्रोडक्शन कोड की तरह ही कठोरता (rigor) का हकदार है: टेस्ट, माप और निरंतर ऑप्टिमाइज़ेशन। इसके साथ इसी तरह का व्यवहार करें, और आपका RAG सिस्टम एक डेमो से बदलकर एक वास्तविक प्रोडक्ट बन जाएगा।

वैकल्पिक लर्निंग कम्युनिटी: GyaanSetu AI