Structured Context Engineering for File-Native Agentic Systems: Evaluating Schema Accuracy, Format Effectiveness, and Multi-File Navigation at Scale
यह शोध पत्र एक बड़े पैमाने पर अनुभवजन्य अध्ययन प्रस्तुत करता है जो यह प्रदर्शित करता है कि फ़ाइल-नेटिव (file-native) LLM एजेंटों के लिए, मॉडल की क्षमता प्रदर्शन को प्रभावित करने वाला प्रमुख कारक है, जबकि फ़ाइल-आधारित रिट्रीवल और डेटा फॉर्मेटिंग जैसी कॉन्टेक्स्ट इंजीनियरिंग रणनीतियों की प्रभावशीलता सार्वभौमिक सर्वोत्तम प्रथाओं का पालन करने के बजाय विशिष्ट मॉडल टियर पर अत्यधिक निर्भर करती है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक बहुत ही बुद्धिमान लेकिन बहुत ही शाब्दिक (literal) सुपर-इंटेलिजेंट असिस्टेंट (एक AI एजेंट) को काम पर रख रहे हैं, जो आपके लिए सूचनाओं के एक विशाल पुस्तकालय का प्रबंधन करेगा। आपका लक्ष्य इस असिस्टेंट से विशिष्ट पुस्तकें खोजने, उनकी सामग्री की जांच करने और जो कुछ भी वह पाता है उसके आधार पर एक सारांश लिखने के लिए कहना है।
यह शोध पत्र एक विशाल प्रयोग है ताकि यह पता लगाया जा सके कि उस पुस्तकालय को व्यवस्थित करने का सबसे अच्छा तरीका क्या है ताकि आपका असिस्टेंट अपना काम पूरी तरह से कर सके। शोधकर्ताओं ने 11 अलग-अलग "असिस्टेंट" (AI मॉडल) का परीक्षण 4 अलग-अलग तरीकों (फॉर्मेट) से व्यवस्थित की गई किताबों के साथ किया, और पुस्तकालय छोटे बुकशेल्फ़ से लेकर 10,000 शेल्फ वाले एक गोदाम तक के आकार के थे।
यहाँ उनके निष्कर्षों का विवरण दिया गया, जिसे रोजमर्रा की भाषा में अनुवादित किया गया है:
1. पुस्तकालय सौंपने के दो तरीके
शोधकर्ताओं ने इस बात का परीक्षण करने के लिए दो मुख्य रणनीतियों का परीक्षण किया कि असिस्टेंट को जानकारी कैसे दी जाती है:
- "पूरा पुस्तकालय डंप करने" का तरीका (प्रॉम्प्ट इंजीनियरिंग): आप असिस्टेंट को शुरुआत में ही एक बहुत बड़े कागज के ढेर के रूप में पूरे पुस्तकालय की सूची दे देते हैं। उसे जो कुछ भी चाहिए उसे खोजने के लिए सब कुछ पढ़ना पड़ता है।
- "टॉर्च लिए हुए लाइब्रेरियन" का तरीका (फाइल-नेटिव एजेंट्स): आप असिस्टेंट को एक टॉर्च और एक नक्शा देते हैं। पुस्तकालय बहुत बड़ा है, इसलिए असिस्टेंट विशिष्ट कीवर्ड्स (keywords) खोजने के लिए एक टूल (जैसे
grep) का उपयोग करता है और एक-एक करके केवल आवश्यक पृष्ठों को बाहर निकालता है।
बड़ा आश्चर्य:
- "सुपर-जीनियस" असिस्टेंट के लिए (फ्रंटियर मॉडल्स जैसे Claude, GPT-5): "टॉर्च" वाला तरीका बेहतर रहा। ये स्मार्ट असिस्टेंट खोजने और ठीक वही चीज़ चुनने में अच्छे हैं जिसकी उन्हें आवश्यकता है, इसलिए वे कागज के एक विशाल ढेर से अभिभूत (overwhelmed) नहीं हुए।
- "स्मार्ट लेकिन नए" असिस्टेंट के लिए (ओपन सोर्स मॉडल्स): "टॉर्च" वाले तरीके ने वास्तव में उन्हें नुकसान पहुँचाया। ये असिस्टेंट खोजने की प्रक्रिया में भ्रमित हो गए। वे तब बेहतर प्रदर्शन करते थे जब आप उन्हें एक बार में ही पूरा कागज का ढेर पढ़ने के लिए दे देते थे।
- उपमा: यह एक शतरंज के ग्रैंडमास्टर को एक विशिष्ट चाल खोजने के लिए नक्शा देने जैसा है (वे इसे पसंद करते हैं), लेकिन एक नौसिखिए को नक्शा देने से वह घबरा जाता है और खेल हार जाता है।
2. क्या "फॉन्ट" या "कागज का प्रकार" मायने रखता है? (फॉर्मेट)
शोधकर्ताओं ने पुस्तकालय को चार अलग-अलग तरीकों से व्यवस्थित करने का प्रयास किया:
- YAML: एक व्यवस्थित, इंडेंटेड लिस्ट की तरह।
- Markdown: हेडर और बोल्ड टेक्स्ट के साथ एक ब्लॉग पोस्ट की तरह।
- JSON: एक सख्त, कंप्यूटर-पठनीय कोड ब्लॉक की तरह।
- TOON: जगह बचाने के लिए डिज़ाइन किया गया एक सुपर-कॉम्पैक्ट, शॉर्टहैंड कोड।
निष्कर्ष:
कुल मिलाकर, इससे ज्यादा फर्क नहीं पड़ा कि आपने कौन सा फॉर्मेट इस्तेमाल किया। असिस्टेंट लगभग 75% बार सही उत्तर दे देते थे, चाहे फॉर्मेट कुछ भी हो।
- हालांकि, कुछ विशिष्ट असिस्टेंट की अपनी पसंद थी। एक को "शॉर्टहैंड" फॉर्मेट (TOON) से नफरत हो सकती है और वह "ब्लॉग पोस्ट" स्टाइल (Markdown) पसंद कर सकता है, जबकि दूसरा इसके विपरीत पसंद कर सकता है।
- मुख्य सीख: सटीकता बढ़ाने के लिए फॉर्मेट के पीछे पागल न हों। इसके बजाय, वह फॉर्मेट चुनें जिसे संभालना इंसानों के लिए सबसे आसान हो या जो "कागज" (टोकन्स) पर पैसे बचाने में मदद करे।
3. "बौद्धिक क्षमता" का अंतर बहुत बड़ा है
सबसे बड़ा कारक यह नहीं था कि पुस्तकालय का संगठन कैसा था या फॉर्मेट क्या था—बल्कि यह था कि असिस्टेंट शुरू से कितना स्मार्ट था।
- "सुपर-जीनियस" मॉडल्स, "ओपन सोर्स" मॉडल्स की तुलना में लगभग 21% अधिक सटीक थे, चाहे आपने कुछ भी किया हो।
- उपमा: यदि आप एक पीएचडी छात्र और एक हाई स्कूल के छात्र को एक ही कठिन गणित की परीक्षा देते हैं, तो पीएचडी छात्र हर बार जीतेगा, चाहे वह परीक्षा कॉमिक सैन्स (Comic Sans) में छपी हो या टाइम्स न्यू रोमन (Times New Roman) में। पहले एक स्मार्ट मॉडल में निवेश करें; बाद में फाइल फॉर्मेट की चिंता करें।
4. स्केलिंग अप: 10,000-टेबल की समस्या
क्या होता है जब पुस्तकालय 10 किताबों से बढ़कर 10,000 हो जाता है?
- समस्या: यदि आप पूरी लाइब्रेरी को एक ही विशाल फ़ाइल में रखते हैं, तो असिस्टेंट खो जाता है।
- समाधान: शोधकर्ताओं ने पुस्तकालय को सेक्शन (जैसे "फिक्शन," "हिस्ट्री," "साइंस") में विभाजित किया।
- परिणाम: भले ही 10,000 टेबल हों, यदि पुस्तकालय अच्छी तरह से विभाजित है, तो "टॉर्च" वाला तरीका पूरी तरह से काम करता है। असिस्टेंट इतिहास के बारे में पूछे जाने पर बस "हिस्ट्री" सेक्शन में देखता है, बाकी को अनदेखा कर देता है।
5. "ग्रैप टैक्स" (बहुत संक्षिप्त होने का छिपा हुआ खर्च)
यह दक्षता के बारे में एक दिलचस्प खोज है।
- जाल: आप सोच सकते हैं कि एक सुपर-कॉम्पैक्ट फॉर्मेट (जैसे TOON) पैसे बचाता है क्योंकि फाइलें छोटी होती हैं।
- वास्तविकता: कभी-कभी, बहुत अधिक संक्षिप्त होना असिस्टेंट को अधिक मेहनत करने और अधिक पैसा खर्च करने पर मजबूर कर देता है।
- क्यों? जब असिस्टेंट एक कॉम्पैक्ट फाइल में एक लाइन खोजने के लिए अपने "टॉर्च" (सर्च टूल) का उपयोग करता है, तो वह एक सिंगल लाइन इतनी अधिक जानकारी से भरी हो सकती है कि वह टेक्स्ट का एक बहुत बड़ा हिस्सा वापस कर देती है। या, क्योंकि वह फॉर्मेट इतना नया और अजीब है, असिस्टेंट को सही चीज़ खोजने से पहले कई अलग-अलग तरीकों से खोजने की कोशिश करनी पड़ती है।
- उपमा: कल्पना कीजिए कि एक शब्दकोश है जहाँ प्रत्येक परिभाषा बहुत छोटे, घने फॉन्ट में लिखी गई है। आप कागज बचाते हैं, लेकिन आपकी आँखें थक जाती हैं, और आपको समझने के लिए एक ही लाइन को तीन बार फिर से पढ़ना पड़ता है। वह "दोबारा पढ़ना" आपको समय और ऊर्जा खर्च कराता है।
सारांश: आपको क्या करना चाहिए?
यदि आप डेटा प्रबंधित करने के लिए एक AI सिस्टम बना रहे हैं, तो यहाँ इस पेपर से मिली 'चीट शीट' है:
- पहले अपना मॉडल चुनें: यदि आपके पास शीर्ष-स्तरीय "सुपर-जीनियस" मॉडल के लिए बजट है, तो फाइल-नेटिव (टॉर्च) दृष्टिकोण का उपयोग करें। यदि आप एक सस्ता, ओपन-सोर्स मॉडल उपयोग कर रहे हैं, तो प्रॉम्प्ट इंजीनियरिंग (बड़ा ढेर) पर टिके रहें।
- फॉर्मेट की चिंता न करें: यदि आप टोकन्स बचाने के लिए पैसे बचाना चाहते हैं और चीजों को व्यवस्थित रखना चाहते हैं, तो YAML का उपयोग करें। यदि आप चाहते हैं कि इंसान इसे आसानी से पढ़ सकें, तो Markdown का उपयोग करें। किसी नए "सुपर-कॉम्पैक्ट" फॉर्मेट का आविष्कार तब तक न करें जब तक कि आप ठीक से न जानते हों कि आपका विशिष्ट AI इसे कैसे हैंडल करता है।
- विषय के आधार पर व्यवस्थित करें: यदि आपका डेटा बहुत बड़ा है, तो फोल्डर (डोमेन) में विभाजित करें। सब कुछ एक ही विशाल फ़ाइल में न डालें।
- "शॉर्टहैंड" से सावधान रहें: यदि आप बहुत ही कॉम्पैक्ट, कस्टम फॉर्मेट का उपयोग करते हैं, तो आपका AI भ्रमित हो सकता है और सही पैटर्न खोजने के लिए पैसा बर्बाद कर सकता। विशेषज्ञ न होने तक मानक फॉर्मेट का ही उपयोग करें।
निष्कर्ष: कोई "एक ही आकार सबके लिए फिट" (one size fits all) वाला जादू नहीं है। आपको अपने पुस्तकालय संगठन की रणनीति को अपने असिस्टेंट के बुद्धिमत्ता स्तर के साथ मिलाना होगा।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।