एक Retrieval-Augmented Generation (RAG) पाइपलाइन को चार महीने तक Jupyter notebook से निकालकर लाइव सर्विस में लाने के बाद, लेखक ने उन पांच ठोस विकल्पों की पहचान की जिन्होंने एक दिखावटी डेमो को एक ऐसे सिस्टम में बदल दिया जिस पर उपयोगकर्ता वास्तव में भरोसा कर सकें। इसका अंतर आंकड़ों में दिखता है: टेक्स्ट को विभाजित करने के तरीके में एक साधारण बदलाव ने रिट्रीवल हिट रेट (retrieval hit rate) को 61% से बढ़ाकर 83% कर दिया, और 200 वास्तविक प्रश्नों के एक मामूली मूल्यांकन सेट (evaluation set) से अब ग्राहकों तक पहुँचने से पहले ही अधिकांश रिग्रेशन (regressions) पकड़ लिए जाते हैं।
यह क्यों महत्वपूर्ण है
RAG डेमो प्रभावशाली लगते हैं – वे कुछ ही सेकंड में एक पैराग्राफ खोजते हैं और एक संभावित उत्तर देते हैं। प्रोडक्शन में, वही दृष्टिकोण अक्सर पुराने तथ्य, छूटे हुए एरर कोड, या टूटे हुए वाक्य देता है, जिससे उपयोगकर्ता का भरोसा कम होता है। बाधा (bottleneck) शायद ही कभी लैंग्वेज मॉडल होती है; यह कंटेंट को इनजेस्ट (ingest), इंडेक्स (index) और सर्व (serve) करने का तरीका है। पाइपलाइन को सही ढंग से तैयार करना एक ऐसे उत्पाद के बीच का अंतर हो सकता है जो वैल्यू जोड़ता है और एक ऐसा जो बोझ बन जाता है।
1. फिक्स्ड-साइज़ चंक्स (fixed-size chunks) का उपयोग करना बंद करें
कई प्रोटोटाइप हर डॉक्यूमेंट को 512-टोकन ब्लॉक्स में काट देते हैं। यह छोटे टेक्स्ट के लिए तो ठीक है, लेकिन तकनीकी मैनुअल, सपोर्ट थ्रेड्स और कोड स्निपेट्स को पूरी तरह खराब कर देता है। वाक्य टूट जाते हैं, हेडिंग्स गायब हो जाती हैं, और रिट्रीवल इंजन उस संदर्भ (context) को नहीं मिल पाता जिसकी उपयोगकर्ता अपेक्षा करता है।
सिमेंटिक यूनिट्स को सुरक्षित रखने के लिए स्ट्रक्चर-अवेयर चंकिंग (structure-aware chunking) पर स्विच करें—हेडिंग्स, बातचीत की सीमाओं, या कोड फेन्सेस (code fences) पर विभाजित करें। लेखक के सिस्टम में, केवल इसी बदलाव से प्रासंगिक पैराग्राफ खोजने वाले प्रश्नों का हिस्सा 61% से बढ़कर 83% हो गया। यह सुधार डेटा-फॉर्मेट में बदलाव से आता है; मूल मॉडल वही रहता है।
2. हाइब्रिड सर्च (hybrid search) का उपयोग करें
शुद्ध वेक्टर सर्च (embedding-based similarity) समान अर्थ वाले पैराग्राफ खोजने में उत्कृष्ट है, लेकिन यह एरर कोड, वर्जन नंबर, या विशिष्ट शब्दावली जैसे सटीक पहचानकर्ताओं (exact identifiers) पर लड़खड़ा जाता है। “ERR-XXXX” जैसा एरर कोड खोजने वाला उपयोगकर्ता एक ऐसा सिमेंटिक रूप से समान पैराग्राफ प्राप्त कर सकता है जिसमें वह कोड बिल्कुल भी न हो।
हाइब्रिड सर्च एक डेंस वेक्टर इंडेक्स (dense vector index) को पारंपरिक BM25 इंडेक्स (term-frequency आधारित) के साथ जोड़ता है। दोनों स्कोर को वेटेज (weighting) देकर, सिस्टम उन आइटम्स को रिट्रीव करता है जो सिमेंटिक रूप से भी करीब हों और जिनमें वे सटीक शब्द भी हों जो उपयोगकर्ता ने टाइप किए हैं। प्रोडक्शन के लिए, हाइब्रिड सर्च एक बुनियादी आवश्यकता है, न कि कोई अतिरिक्त सुविधा।
3. पुराने डेटा (stale data) को संभालें
पुराने हो चुके प्राइसिंग टेबल, पॉलिसी डॉक्यूमेंट, या फर्मवेयर रिलीज़ नोट्स विश्वसनीयता को तेजी से खत्म कर देते हैं। इंडेक्स को ताज़ा रखने के लिए तीन व्यावहारिक कदम:
- हर डॉक्यूमेंट को वर्जन स्टैम्प या टाइमस्टैम्प के साथ टैग करें।
- स्कोरिंग के दौरान 'रेसेन्सी बूस्ट' (recency boost) लागू करें ताकि नए आइटम्स पुराने को पीछे छोड़ दें।
- सोर्स सिस्टम से बदलावों को शामिल करने के लिए हर रात इंक्रीमेंटल री-इंडेक्सिंग (incremental re-indexing) चलाएं।
ये सुरक्षा उपाय सिस्टम को पिछले तिमाही में मान्य रहे मूल्य या ऐसी पॉलिसी देने से रोकते हैं जो पहले ही बदल दी गई है।
4. मॉडल अपग्रेड करने के बजाय रीरैंक (Rerank) करें
एम्बेडिंग मॉडल को अपग्रेड करने से केवल गुणवत्ता में मामूली सुधार मिलता है, जबकि एक क्रॉस-एनकोडर रीरैंकर (cross-encoder reranker) जोड़ने से कम लागत में बहुत बड़ी छलांग मिलती है।
प्रोडक्शन फ्लो हाइब्रिड सर्च का उपयोग करके 20 सस्ते कैंडिडेट (candidates) निकालता है, फिर शीर्ष पांच को चुनने के लिए उन्हें रीरैंकर के माध्यम से भेजता है। यह दो-चरणीय दृष्टिकोण पूर्ण मॉडल अपग्रेड के खर्च के एक छोटे से हिस्से में गुणवत्ता में बड़ी वृद्धि प्रदान करता है।
5. एक वास्तविक मूल्यांकन सेट (evaluation set) बनाएं
आप उसे बेहतर नहीं बना सकते जिसे आप माप नहीं सकते। लेखक ने 200 वास्तविक उपयोगकर्ता प्रश्नों का एक टेस्ट सूट तैयार किया, जिनमें से प्रत्येक को एक विशेषज्ञ द्वारा तैयार किए गए उत्तर के साथ जोड़ा गया है। हर कोड परिवर्तन इस सूट के विरुद्ध चलाया जाता है; किसी भी रिग्रेशन को डिप्लॉयमेंट से पहले ही पकड़ लिया जाता है।
जब कोई उपयोगकर्ता गलत उत्तर की रिपोर्ट करता है, तो उस प्रश्न को तुरंत मूल्यांकन सेट में जोड़ दें, जिससे वास्तविक दुनिया की विफलताओं को भविष्य के सुरक्षा उपायों में बदला जा सके। प्रत्येक जनरेट किए गए उत्तर का निरंतर लॉगिंग मूल्यांकन लूप को फीड करता है, जिससे सिस्टम वास्तविक उपयोग के साथ तालमेल बनाए रखता है।
प्रोडक्शन पाइपलाइन का व्यावहारिक उपयोग
- Ingest: स्ट्रक्चर-अवेयर चंकिंग हेडिंग्स, कोड ब्लॉक्स और बातचीत के क्रम को सुरक्षित रखती है।
- Index: डेंस एम्बेडिंग्स और BM25 टर्म स्टैटिस्टिक्स दोनों को स्टोर करें।
- Retrieve: हाइब्रिड सर्च सिमेंटिक समानता और सटीक शब्द मिलान के बीच संतुलन बनाते हुए 20 कैंडिडेट लौटाता है।
- Rerank: एक क्रॉस-एनकोडर सूची को पांच सबसे आशाजनक पैराग्राफ तक सीमित कर देता है।
- Generate: LLM अंतिम उत्तर तैयार करने के लिए इन शीर्ष चंक्स और उनके मेटाडेटा को प्राप्त करता है।
- Evaluate: प्रत्येक प्रतिक्रिया को लॉग किया जाता है; विफलताओं को वापस 200-प्रश्न वाले टेस्ट सेट में फीड किया जाता है।
जोखिम और समझौते (Stakes and trade-offs)
एक अच्छी तरह से ट्यून किया गया पाइपलाइन hallucinations को कम करता है, उत्तर की प्रासंगिकता में सुधार करता है, और over-provisioned मॉडल्स की लागत को कम करता है। इसका लाभ उच्च उपयोगकर्ता संतुष्टि और कम सपोर्ट ओवरहेड के रूप में मिलता है। इन चरणों की अनदेखी करने से एक अस्थिर सेवा मिलती है जो ब्रांड के भरोसे को कम करती है और महंगी संकट प्रबंधन (firefighting) की स्थिति पैदा करती है।
आगे क्या देखने लायक है
जैसे-जैसे ओपन-सोर्स embeddings और vector databases परिपक्व होंगे, "dense" और "sparse" retrieval के बीच का अंतर धुंधला हो जाएगा, लेकिन semantic और exact matching को संयोजित करने का सिद्धांत बना रहेगा।
मुख्य बात: एक RAG सिस्टम में, लैंग्वेज मॉडल शायद ही कभी चोक पॉइंट होता है। असली काम इस बात पर निर्भर करता है कि आप अंतर्निहित सामग्री को कैसे स्लाइस, इंडेक्स और सतह पर लाते हैं। इन निर्णयों को सही ढंग से लेना एक चकाचौंध भरे डेमो को एक भरोसेमंद उत्पाद में बदल देता है।