अधिकांश इंजीनियरिंग टीमें retrieval-augmented generation के साथ एक ही समस्या का सामना करती हैं। वे ट्यूटोरियल प्लेबुक का पालन करती हैं: दस्तावेज़ों को पांच सौ बारह या एक हजार चौबीस टोकन के निश्चित चंक्स (chunks) में विभाजित करना, उन्हें एक ही एम्बेडिंग मॉडल (embedding model) के माध्यम से भेजना, और एक साधारण top-k लुकअप के साथ वेक्टर डेटाबेस को कॉल करना। एक स्लाइड डेक पर, यह ठोस दिखता है। लेकिन प्रोडक्शन में, यह बिखर जाता है।
निश्चित चंक्स (Fixed chunks) कंटेंट की परवाह नहीं करते। वे खुशी-खुशी एक कानूनी अनुबंध (legal contract) को वाक्य के बीच में ही विभाजित कर देंगे, जिससे लायबिलिटी क्लॉज (liability clauses) टेक्स्ट के दो असंबंधित हिस्सों में लटक जाएंगे। वे एक पूरे API एंडपॉइंट विवरण को एक इतने बड़े और भारी चंक में डाल देंगे कि आपके उपयोगकर्ता द्वारा पूछा गया विशिष्ट पैरामीटर शोर (noise) में दब जाएगा। और जब रिट्रीवल धीमा होता है, तो लेटेंसी (latency) का हर मिलीसेकंड सीधे उपयोगकर्ता अनुभव को प्रभावित करता है। हमने यह कठिन अनुभव से सीखा। फिर हमने अपने रिट्रीवल लेयर को पूरी तरह से बदलकर फिर से बनाया। हमारा recall at ten 78% से बढ़कर 95% हो गया। लेटेंसी बढ़ी नहीं, बल्कि काफी कम हो गई।
कॉपी-पेस्ट RAG के साथ समस्या
मानक RAG स्टैक एक तरह की डिफॉल्ट सेटिंग बन गया है। छोटे चंक्स, एक एम्बेडिंग मॉडल, वेक्टर सर्च, बस हो गया। यह दृष्टिकोण डेमो में तो काम कर जाता है क्योंकि डेमो में साफ-सुथरे सवाल और व्यवस्थित दस्तावेज़ होते हैं। प्रोडक्शन डेटा कभी भी व्यवस्थित नहीं होता।
कानूनी दस्तावेज़ों की एक पदानुक्रमित (hierarchical) संरचना होती है। सेक्शन में सब-सेक्शन होते हैं। सब-सेक्शन में क्लॉज होते हैं। यदि आप उन्हें एक साधारण टोकन काउंटर से काटते हैं, तो आप उन संबंधों को ही नष्ट कर देते हैं जिनके बारे में मॉडल को तर्क (reasoning) करने की आवश्यकता होती है। API डॉक्यूमेंटेशन की भी संरचना होती है, लेकिन वह अलग होती है। एक फंक्शन सिग्नेचर, उसके पैरामीटर, उसका रिटर्न वैल्यू और एक उदाहरण उपयोग एक तार्किक इकाई (logical unit) बनाते हैं। इसे एक निश्चित टोकन विंडो में जबरदस्ती फिट करने पर या तो उदाहरण कट जाता है या चंक को असंबंधित फंक्शन्स से भर दिया जाता है। सपोर्ट टिकट अव्यवस्थित, संवादात्मक और अचानक विषय बदलने वाले होते हैं। विकी (Wikis) विस्तृत और क्रॉस-रेफरेंस्ड होते हैं। एक ही चंकिंग रणनीति इन सभी के लिए काम नहीं कर सकती, फिर भी टीमें नियमित रूप से यही करती हैं। हमने यह ढोंग करना बंद कर दिया कि यह संभव है।
रणनीतिक चंकिंग: सामग्री के अनुसार विधि का मिलान करें
हम कंटेंट-अवेयर चंकिंग (content-aware chunking) की ओर बढ़े। कानूनी दस्तावेज़ों के लिए, हम रिकर्सिव चंकिंग (recursive chunking) का उपयोग करते हैं जो दस्तावेज़ के पदानुक्रम का सम्मान करती है। यह क्लॉज को बरकरार रखती है और सेक्शन के बीच पैरेंट-चाइल्ड संबंधों को सुरक्षित रखती है। API डॉक्यूमेंटेशन के लिए, हमने फंक्शन-अवेयर चंकिंग (function-aware chunking) बनाई है जो प्रत्येक फंक्शन या एंडपॉइंट को एक सीमा (boundary) मानती है। यदि किसी पैरामीटर का विवरण लंबा है, तो चंक उस फंक्शन के आसपास फैलता है, न कि टोकन सीमा के आसपास। सपोर्ट टिकटों के लिए, हम सिमेंटिक चंकिंग (semantic chunking) का उपयोग करते हैं जो प्राकृतिक विषय सीमाओं का पता लगाती है। जब कोई ग्राहक अचानक बिलिंग शिकायत से तकनीकी बग पर स्विच करता है, तो विभाजन उसी मोड़ पर होता है। विकी और असंरचित नॉलेज बेस के लिए, हम एजेंटिक चंकिंग (agentic chunking) का उपयोग करते हैं जहाँ एक हल्का LLM टेक्स्ट का मूल्यांकन करता है और तय करता है कि एक सार्थक सीमा कहाँ होनी चाहिए। इसे सेटअप करना कैरेक्टर स्प्लिट की तुलना में धीमा है, लेकिन यही काम करने वाले रिट्रीवल और केवल अनुमान लगाने वाले रिट्रीवल के बीच का अंतर है।
हाइब्रिड रिट्रीवल: केवल वेक्टर सर्च ही क्यों पर्याप्त नहीं है
वेक्टर सर्च अर्थ को समझता है, लेकिन यह सटीक मिलान (exact matches) को छोड़ सकता है। यदि कोई उपयोगकर्ता ERR_CONNECTION_RESET_0x5F3 जैसा एरर कोड पेस्ट करता है, तो सिमेंटिक समानता (semantic similarity) इसे उन पैराग्राफों से नीचे रैंक कर सकती है जो केवल सामान्य रूप से नेटवर्क त्रुटियों पर चर्चा करते हैं। दूसरी ओर, BM25 सटीक स्ट्रिंग्स को ढूंढता है लेकिन वैचारिक संबंध (conceptual relatedness) को मिस कर देता है। आपको दोनों की आवश्यकता है।
हम वेक्टर सर्च और BM25 को समानांतर (parallel) रूप से चलाते हैं। फिर हम परिणामों को Reciprocal Rank Fusion, या RRF के साथ जोड़ते हैं, जो दोनों अलग-अलग सर्च स्पेस के स्कोर को एक ही स्केल में बदलने के बजाय उन्हें सामान्य (normalize) करता है। फ्यूजन के बाद, हम शीर्ष उम्मीदवारों को क्रॉस-एनकोडर रीरैंकर (cross-encoder reranker) के माध्यम से भेजते हैं। इससे थोड़ी लेटेंसी बढ़ती है, लेकिन सटीकता (precision) में होने वाला लाभ महत्वपूर्ण है। रीरैंकर क्वेरी और प्रत्येक उम्मीदवार को एक साथ पढ़ता है और एक प्रासंगिकता स्कोर (relevance score) देता है जो शुरुआती एम्बेडिंग की कोसाइन समानता (cosine similarity) की तुलना में कहीं अधिक सटीक होता है। व्यवहार में, यह संयोजन उन सटीक एरर कोड को पकड़ लेता है जिन्हें शुद्ध वेक्टर सर्च मिस कर देता है, जबकि साथ ही उन वैचारिक रूप से संबंधित समस्या निवारण चरणों (troubleshooting steps) को भी सामने लाता है जिन्हें कीवर्ड सर्च अनदेखा कर देता।
क्वेरी एक्सपेंशन: इंडेक्स तक पहुँचने से पहले यूजर इनपुट को ठीक करना
उपयोगकर्ता सटीक सर्च क्वेरी नहीं लिखते हैं। वे मल्टी-हॉप (multi-hop) सवाल पूछते हैं जैसे कि "मेरा पिछला डिप्लॉय क्यों विफल हुआ और मैं इसे कैसे रोलबैक करूँ", जिसके लिए ज्ञान के दो अलग-अलग स्रोतों को खोजने और उन्हें जोड़ने की आवश्यकता होती है। या वे अस्पष्ट प्रश्न पूछते हैं जो इंडेक्स के साथ ठीक से मेल नहीं खाते।
We transform queries before searching. A multi-hop question gets broken into sub-questions. A vague intent gets expanded into multiple specific search queries. We found that expanding one user query into five distinct search queries can move recall from seventy-eight percent to ninety-six percent. This is not about prompting the LLM harder. It is about giving the retrieval system more shots at finding the right context. Each generated query captures a different angle or terminology, and the merged results paint a complete picture.
Bayesian Optimization: Stop Guessing
Once you have multiple chunking strategies, hybrid retrieval, and query expansion, you face a new problem. There are too many knobs. Chunk size, overlap percentage, vector weight versus BM25 weight, reranking thresholds, and top-k values all interact in nonlinear ways. Manual tuning becomes a guessing game.
We stopped guessing. We treat the