अधिकांश टीमें अभी भी अपना पहला रिट्रीवल पाइपलाइन (retrieval pipeline) एक ही तरह से बनाती हैं। वे एक निश्चित टोकन सीमा चुनती हैं, शायद 512, दस्तावेज़ों को समान ब्लॉक्स में विभाजित करती हैं, और उन ब्लॉक्स को वेक्टर डेटाबेस में डाल देती हैं। सरल प्रश्नों वाले छोटे डेटासेट पर, यह जादुई लगता है। लेकिन प्रोडक्शन में, यह पूरी तरह विफल हो जाता है।
जब कोई क्लॉज (clause) वाक्य के बीच में ही कट जाता है, तो कानूनी अनुबंध (legal contracts) अर्थहीन टुकड़ों में बंट जाते हैं। यदि एक ही चंक (chunk) में तीन असंबंधित फंक्शन समा जाते हैं, तो API डॉक्यूमेंटेशन शोर से भरा कचरा बन जाता है। सेगमेंट के बीच ओवरलैप न होने के कारण कस्टमर सपोर्ट टिकट अपना पूरा संदर्भ खो देते हैं। इसका परिणाम अनुमानित है: अत्यधिक लेटेंसी (latency), कमजोर रिकॉल (recall), और ऐसे उत्तर जो जनरेटर को हैलुसिनेट (hallucinate) करने पर मजबूर कर देते हैं।
हमने अपने रिट्रीवल लेयर को पूरी तरह से बदलकर फिर से बनाया। इसका परिणाम रिकॉल में 78 प्रतिशत से 95 प्रतिशत की वृद्धि, लेटेंसी में 62 प्रतिशत की कमी, और एक ऐसा पाइपलाइन था जो आखिरकार एक 'वीकेंड हैक' के बजाय वास्तविक इंफ्रास्ट्रक्चर की तरह काम करता है। यहाँ बताया गया है कि वास्तव में क्या काम आया।
स्मार्ट चंकिंग: टोकन के बजाय स्ट्रक्चर पर ध्यान दें
पहली गलती यह मान लेना है कि हर दस्तावेज़ एक ही भाषा बोलता है। 512-टोकन का चंक कथात्मक गद्य (narrative prose) के लिए तो ठीक है, लेकिन इसके अलावा लगभग कहीं भी नहीं। हम एक ऐसी रणनीति पर चले गए जो सोर्स की संरचना (anatomy) का सम्मान करती है।
कानूनी दस्तावेज़ों के लिए, हम रिकर्सिव चंकिंग (recursive chunking) का उपयोग करते हैं। एल्गोरिदम पहले सेक्शन और आर्टिकल्स जैसी उच्च-स्तरीय सीमाओं पर विभाजित करने का प्रयास करता है। यदि कोई सेक्शन अभी भी बहुत लंबा है, तो यह सब-सेक्शन, फिर पैराग्राफ और फिर वाक्यों को देखता है। यह क्लॉज के तार्किक क्रम (logical nesting) को बनाए रखता है। एक नॉन-कंपीट एग्रीमेंट (non-compete agreement) सुरक्षित रहता है। परिभाषाएं क्षतिपूर्ति शर्तों (indemnity terms) में नहीं मिलतीं।
API डॉक्यूमेंटेशन के लिए स्ट्रक्चर-अवेयर चंकिंग (structure-aware chunking) की आवश्यकता होती है। एक फंक्शन सिग्नेचर, उसका पैरामीटर टेबल और उसका उदाहरण अनुरोध (example request) एक साथ होने चाहिए। एक निश्चित टोकन संख्या के बाद विभाजित करने से अक्सर पैरामीटर एक चंक में और उदाहरण दूसरे चंक में रह जाते हैं। इसके बजाय, हम डॉक्यूमेंट ऑब्जेक्ट के आधार पर चंकिंग करते हैं। एक चंक में एक पूरा एंडपॉइंट या एक सिंगल फंक्शन होता है। रिट्रीवर फिर एक ऐसा आत्मनिर्भर संदर्भ (self-contained reference) दे सकता है जो वास्तव में प्रश्न का उत्तर देता है।
सपोर्ट टिकट स्वाभाविक रूप से सिमेंटिक चंकिंग (semantic chunking) के लिए उपयुक्त होते हैं। टोकन बाउंड्री पर काटने के बजाय, हम पता लगाते हैं कि विषय कहाँ बदल रहा है। एक टिकट जो लॉगिन शिकायत के साथ शुरू होता है और बिलिंग प्रश्न की ओर मुड़ जाता है, वह दो सुसंगत टुकड़ों में विभाजित हो जाता है। प्रत्येक टुकड़ा आवश्यक मेटाडेटा रखता है, और मॉडल को अब यह अनुमान लगाने की ज़रूरत नहीं पड़ती कि उपयोगकर्ता वास्तव में किस समस्या की परवाह कर रहा है।
इंटरनल विकी (Internal wikis) अधिक अव्यवस्थित होते हैं। वे गद्य, टेबल, आरेख और एम्बेडेड थ्रेड्स का मिश्रण होते हैं। इनके लिए, हम एजेंटिक चंकिंग (agentic chunking) का उपयोग करते हैं। एक छोटा लैंग्वेज मॉडल आगे पढ़ता है और तय करता है कि विषयगत रूप से पूर्ण इकाई कहाँ समाप्त होती है। इसमें डेटा इनजेशन (ingestion) के समय थोड़ा अधिक खर्च होता है, लेकिन यह हर नए पेज फॉर्मेट के लिए नियमों को मैन्युअल रूप से ट्यून करने की मानवीय मेहनत को खत्म कर देता है।
हाइब्रिड रिट्रीवल: हर पहलू को कवर करें
वेक्टर सर्च अस्पष्ट अर्थ (fuzzy meaning) को पकड़ने में उत्कृष्ट है। यदि आप धीमे अपलोड के बारे में पूछते हैं, तो यह खुशी-खुशी लेटेंसी और बैंडविड्थ के बारे में पैराग्राफ लौटा देगा। लेकिन यह सटीक मिलान (exact matches) को बिगाड़ने के लिए कुख्यात है। यदि कोई डेवलपर एरर कोड ERR_CONNECTION_REFUSED खोजता है, तो डेंस एम्बेडिंग्स (dense embeddings) अक्सर इसे सामान्य शोर (generic noise) मान लेती हैं।
BM25, जो कि एक क्लासिक कीवर्ड एल्गोरिदम है, इसके विपरीत काम करता है। यह सटीक स्ट्रिंग्स और दुर्लभ शब्दों को सटीक रूप से पकड़ता है, फिर भी यह सिमेंटिक बारीकियों (semantic nuance) को छोड़ देता है। समझौते पर हस्ताक्षर करने के बारे में एक क्वेरी शायद ही कभी उस कंटेंट को सामने लाए जिसे 'कॉन्ट्रैक्ट को निष्पादित करना' (executing the contract) के रूप में टैग किया गया हो।