← Resources
By Priya Shah
— Senior Engineer, RAG + Knowledge
·
· TUTORIAL
RAG के लिए चंकिंग रणनीतियाँ: साइज़, ओवरलैप और क्या कारगर है
रिट्रीवल शुरू होने से पहले ही चंकिंग RAG की गुणवत्ता की अधिकतम सीमा तय कर देती है। यह गाइड व्यवहार में सबसे प्रचलित छह रणनीतियों की तुलना करती है, ठोस साइज़ और ओवरलैप के आंकड़े देती है, और बताती है कि किस तरह की क्वेरी के लिए कौन-सी रणनीति उपयुक्त है।
चंकिंग RAG की गुणवत्ता क्यों तय करती है
चंक वही इकाई है जिसे आपका रिट्रीवर असल में फ़ेच करता है, इसलिए चंक की सीमाएँ आगे के पूरे पाइपलाइन की अधिकतम सीमा तय कर देती हैं। चंक बहुत छोटे बनाएँ तो हर एम्बेडिंग में इतना सिग्नल नहीं रहता कि वह भरोसेमंद ढंग से मिल सके; बहुत बड़े बनाएँ तो प्रासंगिक पैसेज का सिग्नल औसत में दब जाता है, वेक्टर पतला पड़ जाता है और क्वेरी से मेल नहीं खाता। चंकिंग गलत हो जाए तो कोई रिरैंकर या बड़ा मॉडल रिकॉल को नहीं बचा सकता — सही पैसेज तो कभी रिट्रीव ही नहीं हुआ। यही वजह है कि आमतौर पर मॉडल चुनने से पहले सबसे पहले चंकिंग ही ट्यून की जाती है।
व्यवहार में हावी छह रणनीतियाँ
मौजूदा व्यवहार मोटे तौर पर छह दृष्टिकोणों में बँटता है:
- Fixed-size: ओवरलैप के साथ बराबर टोकन/कैरेक्टर स्पैन। सबसे पुराना, सबसे सस्ता, पुनरुत्पादनीय — और हैरान कर देने वाला मजबूत बेसलाइन।
- Recursive: सीमाओं का सम्मान करते हुए साइज़ की हद के भीतर रहने के लिए सेपरेटर की प्राथमिकता के क्रम में विभाजन (पैराग्राफ → लाइन → वाक्य)। अनुशंसित डिफ़ॉल्ट।
- Semantic: एम्बेडिंग समानता के आधार पर वाक्यों को समूहित करें ताकि हर चंक एक ही विषय का हो। recursive की तुलना में फ़ायदा असंगत रहता है और अतिरिक्त एम्बेडिंग कंप्यूट लगती है।
- Structure-aware: डॉक्यूमेंट की संरचना (हेडिंग, सेक्शन, पेज, Markdown) के आधार पर विभाजन। PDF, मैनुअल और वित्तीय दस्तावेज़ों के लिए सर्वोत्तम।
- Late chunking: पहले पूरे दस्तावेज़ को लॉन्ग-कॉन्टेक्स्ट मॉडल से एम्बेड करें, फिर टोकन एम्बेडिंग को चंक में पूल करें — ताकि हर चंक में ग्लोबल कॉन्टेक्स्ट समाया रहे।
- Contextual retrieval: इंडेक्सिंग से पहले हर चंक के आगे LLM-जनरेटेड कॉन्टेक्स्ट का छोटा-सा विवरण जोड़ें।
recursive से शुरुआत करें; जब आपके दस्तावेज़ या क्वेरी के प्रकार माँग करें, तभी बाकी रणनीतियों की ओर बढ़ें।
चंक साइज़ और ओवरलैप: ठोस आंकड़े
कोई सार्वभौमिक सर्वोत्तम साइज़ नहीं है, पर अच्छे शुरुआती बिंदु ज़रूर हैं। लगभग 400–512 टोकन से शुरू करें, 10–20% ओवरलैप के साथ (500-टोकन चंक पर मोटे तौर पर 50–100 टोकन)। फिर साइज़ को क्वेरी के प्रकार से मिलाएँ: छोटे चंक (128–256 टोकन) सटीक तथ्य और कीवर्ड लुकअप के लिए बेहतर हैं, जबकि बड़े चंक (512–1024 टोकन) उन विश्लेषणात्मक और सारांश क्वेरीज़ के लिए बेहतर हैं जहाँ नैरेटिव का प्रवाह मायने रखता है।
ओवरलैप अर्थ को सीमा पर कटने से रोकता है — बहुत कम हो तो कॉन्टेक्स्ट टुकड़ों में बँट जाता है, बहुत ज़्यादा हो तो इंडेक्स फूल जाता है और रिट्रीवल में डुप्लीकेशन आ जाता है। NVIDIA के बेंचमार्क में वित्तीय दस्तावेज़ों पर लगभग 15% ओवरलैप इष्टतम पाया गया, और पेज-स्तरीय चंकिंग ने मिश्रित कॉर्पोरा में सबसे ऊँची और सबसे सुसंगत सटीकता दी, जिसमें फैक्टॉइड क्वेरीज़ 256–512 टोकन पर और विश्लेषणात्मक क्वेरीज़ 1024+ पर चरम पर थीं।
उन्नत: contextual retrieval और late chunking
दो नई तकनीकें एक ही समस्या से जूझती हैं — "revenue increased 15%" पढ़ने वाला चंक बेकार है अगर यह न पता चले कि बात किस कंपनी या किस तिमाही की है।
Anthropic का Contextual Retrieval एम्बेडिंग और BM25 इंडेक्सिंग दोनों से पहले हर चंक के आगे LLM-जनरेटेड 50–100-टोकन का कॉन्टेक्स्ट नोट जोड़ता है। 5.7% की बेसलाइन टॉप-20 फेलियर रेट के मुकाबले, contextual एम्बेडिंग ने फेलियर 35% घटाई, contextual BM25 जोड़ने पर 49% और रिरैंकिंग जोड़ने पर 67% — प्रॉम्प्ट कैशिंग के साथ प्रति मिलियन डॉक्यूमेंट टोकन लगभग $1.02 की लागत पर।
Jina का late chunking पाइपलाइन को उलट देता है: पूरे दस्तावेज़ को लॉन्ग-कॉन्टेक्स्ट मॉडल से एम्बेड करें (लगभग 8,192 टोकन तक), फिर contextualized टोकन एम्बेडिंग को चंक में पूल करें, ताकि हर चंक एम्बेडिंग पहले से ही क्रॉस-चंक कॉन्टेक्स्ट अपने साथ लिए चले। इसे ऐसे लंबे दस्तावेज़ों के लिए इस्तेमाल करें जिनमें लंबी-दूरी की निर्भरताएँ हों।
पैरेंट-डॉक्यूमेंट रिट्रीवल और मेटाडेटा
दो परिष्कार लगभग हर जगह फ़ायदा देते हैं। Parent-document ("small-to-big") retrieval रिट्रीवल की ग्रैन्युलैरिटी को जनरेशन से अलग कर देता है: सटीक मिलान के लिए छोटे चाइल्ड चंक (≈100–500 टोकन) इंडेक्स करें, लेकिन मॉडल को बड़ा पैरेंट सेक्शन (≈500–2,000 टोकन) लौटाएँ ताकि उसे आसपास का कॉन्टेक्स्ट मिले। और मेटाडेटा संवर्धन — हर चंक के साथ सोर्स, सेक्शन हेडिंग, पेज नंबर और टाइमस्टैम्प जोड़ना — फ़िल्टरिंग बेहतर करता है, उद्धरण संभव बनाता है, और चंक साइज़ से स्वतंत्र रूप से रिट्रीवल प्रिसिज़न बढ़ाता है।
osFoundry में चुनना — और ट्यून करना
एक झटपट निर्णय गाइड: recursive सुरक्षित डिफ़ॉल्ट है; संरचित दस्तावेज़ों के लिए structure-aware या page-level; विषय-गहन गद्य के लिए semantic; लॉन्ग-कॉन्टेक्स्ट एम्बेडर वाले लंबे दस्तावेज़ों के लिए late chunking; ऐसे high-stakes कॉर्पोरा के लिए contextual retrieval जहाँ कॉन्टेक्स्ट का खोना महँगा पड़े; जब प्रिसिज़न और कॉन्टेक्स्ट दोनों चाहिए तब parent-document।
osFoundry इन सबको कोड नहीं, कॉन्फ़िगरेशन के रूप में मानता है। Auto-chunking एक समझदार recursive डिफ़ॉल्ट के साथ आती है, और custom RAG पाइपलाइन आपको हर नॉलेज बेस के लिए साइज़, ओवरलैप और रणनीति अलग-अलग ट्यून करने देती है, जिसमें रिरैंकिंग और parent-document retrieval पाइपलाइन-स्टेज टॉगल के रूप में मौजूद हैं। चूँकि स्टेज कॉन्फ़िगरेबल हैं, आप अपनी क्वेरी डिस्ट्रिब्यूशन — फैक्टॉइड बनाम विश्लेषणात्मक — के विरुद्ध A/B चंकिंग सेटिंग्स आज़मा सकते हैं और बाकी स्टैक को स्थिर रख सकते हैं — यही तो वह ट्यूनेबल-पैरामीटर वर्कफ़्लो है जिसकी शोध सिफ़ारिश करता है।
Frequently asked questions
- RAG के लिए सबसे अच्छा चंक साइज़ क्या है?
- कोई सार्वभौमिक उत्तर नहीं है, पर एक अच्छा शुरुआती बिंदु 10 से 20% ओवरलैप के साथ 400 से 512 टोकन है। फिर अपनी क्वेरी के प्रकार के अनुसार ट्यून करें: सटीक तथ्य लुकअप के लिए 128 से 256 टोकन, और विश्लेषणात्मक या सारांश क्वेरीज़ के लिए 512 से 1024 टोकन। किसी एक डिफ़ॉल्ट पर भरोसा करने के बजाय अपने ही सवालों के विरुद्ध कुछ साइज़ बेंचमार्क करें।
- चंक में कितना ओवरलैप होना चाहिए?
- चंक साइज़ का दस से बीस प्रतिशत — 500-टोकन चंक पर लगभग 50 से 100 टोकन। ओवरलैप अर्थ को सीमा पर कटने से रोकता है; बहुत कम हो तो विभाजन-बिंदु पर कॉन्टेक्स्ट टुकड़ों में बँट जाता है, और बहुत ज़्यादा हो तो इंडेक्स फूल जाता है और near-duplicate रिट्रीवल होने लगती है। NVIDIA ने वित्तीय दस्तावेज़ों पर लगभग 15% को इष्टतम पाया।
- क्या semantic chunking, fixed-size से बेहतर है?
- भरोसेमंद ढंग से नहीं। Semantic chunking वाक्यों को विषय के अनुसार समूहित करती है, जो सुनने में बेहतर लगता है, पर बेंचमार्क दिखाते हैं कि recursive या fixed-size chunking की तुलना में इसका फ़ायदा असंगत है और अक्सर अतिरिक्त एम्बेडिंग कंप्यूट को सही नहीं ठहराता। fixed और recursive chunking मजबूत, सस्ते बेसलाइन बने हुए हैं — वहीं से शुरू करें और semantic की ओर तभी बढ़ें जब आपका मूल्यांकन सचमुच का सुधार दिखाए।
- Late chunking क्या है और इसे कब इस्तेमाल करें?
- Late chunking पहले पूरे दस्तावेज़ को लॉन्ग-कॉन्टेक्स्ट एम्बेडिंग मॉडल से एम्बेड करती है, फिर टोकन एम्बेडिंग को चंक में पूल करती है — ताकि हर चंक का वेक्टर सिर्फ़ अपने टेक्स्ट का नहीं, पूरे दस्तावेज़ का कॉन्टेक्स्ट अपने साथ लिए चले। इसे ऐसे लंबे दस्तावेज़ों के लिए इस्तेमाल करें जिनमें लंबी-दूरी की निर्भरताएँ हों, जहाँ कोई पैसेज पहले के कॉन्टेक्स्ट के बिना अर्थहीन रहता है।
- क्या contextual retrieval सचमुच सटीकता बढ़ाता है?
- हाँ, मापने योग्य ढंग से। Anthropic ने बताया कि हर चंक के आगे LLM-जनरेटेड कॉन्टेक्स्ट नोट जोड़ने से contextual एम्बेडिंग के साथ टॉप-20 रिट्रीवल फेलियर 35%, contextual BM25 के साथ मिलाने पर 49%, और रिरैंकिंग जोड़ने पर 67% घटी — प्रॉम्प्ट कैशिंग के साथ प्रति मिलियन डॉक्यूमेंट टोकन लगभग $1.02 की लागत पर। यह ऐसे high-stakes कॉर्पोरा के लिए सबसे ज़्यादा सार्थक है जहाँ कोई पैसेज छूट जाना महँगा पड़ता है।
- Parent-document (small-to-big) retrieval क्या है?
- यह "कैसे मिलान करते हैं" को "क्या लौटाते हैं" से अलग कर देता है। आप सटीक मिलान के लिए छोटे चाइल्ड चंक इंडेक्स करते हैं, पर जब कोई मेल खाता है तो मॉडल को बड़ा पैरेंट सेक्शन सौंप देते हैं ताकि उसे आसपास का कॉन्टेक्स्ट मिल जाए। इससे आपको छोटे चंक की रिकॉल और बड़े चंक की सुसंगतता दोनों मिलती हैं, बिना किसी से समझौता किए।
- मुझे किस चंकिंग रणनीति से शुरुआत करनी चाहिए?
- लगभग 500 टोकन और 15% ओवरलैप के साथ recursive chunking। यह प्राकृतिक सीमाओं का सम्मान करती है, सस्ती है, और ज़्यादातर कंटेंट के लिए मजबूत बेसलाइन है। PDF और मैनुअल के लिए structure-aware splitting जोड़ें, जब उत्तरों को ज़्यादा कॉन्टेक्स्ट चाहिए तब parent-document retrieval, और contextual retrieval सिर्फ़ तब जब दाँव अतिरिक्त लागत को सही ठहराते हों।
Sources