इस हफ़्ते Towards Data Science पर Priyansh Bhardwaj का एक व्यावहारिक लेख यह बताता है कि प्रोडक्शन में अधिकांश RAG विफलताएँ वास्तव में chunking की विफलताएँ हैं, न कि retrieval या generation की। लेख का मुख्य वाक्य उद्धृत करना आसान है: "LLM अड़चन नहीं है। अड़चन यह निर्णय है कि एक chunk कहाँ समाप्त होता है और अगला कहाँ शुरू।" लेख अमूर्त तर्क से आगे बढ़कर चार ठोस विफलता-प्रकार और दस्तावेज़-प्रकार-सजग chunking रणनीति से प्राप्त मापित सुधार प्रस्तुत करता है। जिस किसी ने RAG सिस्टम भेजा है और उसे तकनीकी रूप से संभाव्य किंतु सूक्ष्मतः ग़लत उत्तर लौटाते देखा है, उसे ये विफलताएँ जानी-पहचानी लगेंगी।
Bhardwaj जिन चार pattern की ओर इशारा करते हैं, वे सब सामान्य हैं और सब debug करने में महँगे। सबसे ख़राब है तार्किक सीमाओं पर कटौती: एक chunk "ठेकेदार खंड 4 में वर्णित मानक onboarding प्रक्रिया का पालन करते हैं" पर समाप्त होता है और अगला "जब तक वे अनुबंध B के अधीन वर्गीकृत किसी परियोजना पर नियोजित न हों" से शुरू होता है, जिससे दो खंड बनते हैं, अलग-अलग में दोनों ग़लत हैं, और retriever उनका संयोजन कभी नहीं बना पाता। स्थिर आकार की token-खिड़कियाँ (512 token और 50 token overlap का वह डिफ़ॉल्ट जो अभी भी बहुत सारे stack में जीवित है) तीन-पैराग्राफ़ के अपवादों और क्रमांकित सूचियों को बीच से काट देती हैं, क्योंकि वे संरचना-अंध हैं। तालिकाओं का समतलन ग्रिड को उनके headers से अलग हुए अनाथ मानों की लम्बी अनुक्रमों में बदल देता है। layout-अनजान PDF-निष्कर्षण ऊपर की सब बातों को बढ़ा देता है, क्योंकि तब अंतर्निहित text-stream उस दृश्य-संरचना से मेल नहीं खाता जिस पर लेखक निर्भर था।
अनुशंसित उपचार उत्तेजक नहीं है, और ठीक वही है। दस्तावेज़ प्रकार के अनुसार रूट कीजिए। स्पष्ट पदानुक्रम वाले संरचित दस्तावेज़ (spec, runbook) को पदानुक्रमित chunking और AutoMergingRetriever चाहिए। कथात्मक सामग्री (नीतियाँ, गाइड, व्याख्यात्मक गद्य) को SentenceWindowNodeParser और 3-वाक्य की context-window चाहिए। मिश्रित और अ-संरचित सामग्री को semantic chunking चाहिए, इस ईमानदार चेतावनी के साथ कि latency की लागत होती है। PDF और slides को किसी भी chunking से पहले PyMuPDF या pdfplumber के माध्यम से layout-सजग पूर्व-संसाधन चाहिए। Bhardwaj का कथात्मक-सामग्री परिवर्तन पर बेंचमार्क अल्प-चकाचौंध परन्तु वास्तविक है: केवल chunker को दस्तावेज़ के आकार से मिलाकर, context recall 0.72 से 0.88 पर पहुँचा और context precision 0.71 से 0.83 पर। ये वैसे आँकड़े हैं जो तब मिलते हैं जब आप RAG को मॉडल-समस्या मानना छोड़कर सामग्री-अभियांत्रिकी की समस्या मानना शुरू करते हैं।
यदि आपका RAG सिस्टम प्रोडक्शन में है और आपने कभी chunking को विफलता-स्रोत के रूप में instrument नहीं किया, तो पहले वहीं देखिए। ठोस क़दम: हाल की 50 ऐसी क्वेरियाँ लीजिए जहाँ उत्तर ग़लत या कम था, प्राप्त chunks को हाथ से पढ़िए, और गिनिए कि कितने chunk-सीमाओं से ही बर्बाद हैं, चाहे उनके ऊपर कोई भी मॉडल generation करे। यह संख्या लगभग हमेशा टीमों की अपेक्षा से बड़ी होती है। दूसरा क़दम है अपने corpus को सजातीय मानना बन्द करना; दस्तावेज़-प्रकार के अनुसार रूट कीजिए, क्योंकि 200 पन्नों के नीति PDF के लिए काम करने वाला chunker तालिका-भारी SKU कैटलॉग के लिए काम नहीं करेगा। यह कल के memweave लेख के साथ जोड़ी बनाता है। दोनों एक ही बड़े बिंदु को भिन्न कोणों से कह रहे हैं। जो इन्फ्रास्ट्रक्चर-निर्णय सबसे उत्तेजक दिखते हैं (बड़ा vector DB, नया मॉडल, लम्बा context), आम तौर पर वहाँ आपकी गुणवत्ता-समस्याएँ नहीं रहतीं। आपका डेटा कैसे काटा और index किया जाता है, ये उबाऊ निर्णय ही रहते हैं।