हमने एजेंटों को कॉन्टेक्स्ट विंडो में एक मिलियन टोकन दिए, लेकिन फिर भी वे काम नहीं करते।
इसे सेव करें :)
आप एक सक्षम मॉडल को कुछ टूल और एक लंबा कार्य देते हैं। पहले पंद्रह चरणों तक, यह शानदार होता है। केंद्रित और सटीक। सवालों के जवाब देना और उपयोगकर्ता से अच्छी तरह पूछताछ करना।
हालांकि, जैसे-जैसे बातचीत बढ़ने लगती है, एजेंट भटकने लगता है। एजेंट उन फैसलों का खंडन करने लगता है जो उसने दस कदम पहले लिए थे। वह कॉन्टेक्स्ट विंडो को मनगढ़ंत जानकारी से दूषित करने लगता है। वह जानता है कि उपयोगकर्ता की प्राथमिकताएँ मौजूद हैं, लेकिन उन्हें विश्वसनीय रूप से प्राप्त नहीं कर पाता। यह सब तब होता है जब आप यह समझने के लिए संघर्ष कर रहे होते हैं कि चीजें क्यों टूट गईं।
तो आप अंततः और अधिक की तलाश करने लगते हैं। एक बड़ी कॉन्टेक्स्ट विंडो वाला मॉडल जो कार्य को अधिक समय तक संभाल सके। RAG पाइपलाइन को अनुकूलित करने की कोशिश करते हैं। एजेंट मेमोरी समाधानों के लिए इंटरनेट छान मारते हैं।
और कुछ भी वैसा काम नहीं करता जैसा आप उम्मीद करते हैं।
इसके पीछे के 'क्यों' को समझना हमें सीधे उस सबसे मूल्यवान, सबसे कम समझी जाने वाली परत की ओर ले जाता है जो पूरे एजेंट स्टैक में है।
विफलता एक लूप है
एजेंटों के खराब होने का कारण क्षमता की कमी नहीं है। यह एक फीडबैक लूप है, और इसकी चार कड़ियाँ हैं। एक बार जब आप सभी चार को देख लेते हैं, तो सामान्य सुधार समाधान नहीं लगते।
पहली कड़ी: एक मॉडल अपने पूरे कॉन्टेक्स्ट का समान रूप से उपयोग नहीं कर सकता, और जैसे-जैसे कॉन्टेक्स्ट भरता है, यह और खराब होता जाता है।
यह वह हिस्सा है जिसे अधिकांश लोग कभी आत्मसात नहीं कर पाते। जानकारी का उपयोग करने की एक मॉडल की क्षमता उसकी कॉन्टेक्स्ट विंडो में एक समान नहीं होती। मॉडल विश्वसनीय रूप से उस जानकारी का उपयोग करते हैं जो बिल्कुल शुरुआत और बिल्कुल अंत में होती है, और वे मध्य भाग पर व्यवस्थित रूप से कम ध्यान देते हैं, भले ही वे विशेष रूप से लंबे इनपुट के लिए बनाए गए हों। अधिक डालें, और विश्वसनीयता और गिर जाती है। यह शब्दों की सूची को दोहराने जैसे मामूली कार्यों पर भी दिखाई देता है। एक एकल विकर्षक जोड़ें, और प्रदर्शन मापनीय रूप से गिर जाता है। कई यौगिक चीजें जोड़ें।
तो प्रभावी कॉन्टेक्स्ट, वह हिस्सा जिस पर मॉडल वास्तव में विश्वसनीय रूप से तर्क कर सकता है, बॉक्स पर लिखी संख्या से कहीं छोटा होता है। और जैसे-जैसे आप अधिक भरते हैं, यह सिकुड़ता जाता है।
अब सोचें कि एक एजेंट क्या करता है। या संचित करता है। हर टूल परिणाम, हर कदम का इतिहास, हर स्वयं-नोट कॉन्टेक्स्ट में जुड़ जाता है। जिसका अर्थ है कि एजेंट लगातार अपने द्वारा उठाए जाने वाले हर कदम की गुणवत्ता को कम कर रहा है। बढ़ता हुआ कॉन्टेक्स्ट प्रति-चरण त्रुटियों का निर्माण कर रहा है।
दूसरी कड़ी: वे प्रति-चरण त्रुटियाँ जुड़ती नहीं हैं। वे गुणा होती हैं।
थोड़ी सी प्रति-चरण त्रुटि ठीक होती अगर एजेंट मुट्ठी भर कदम उठाते। वे दर्जनों कदम उठाते हैं। और विफलताएँ जमा होने के बजाय चक्रवृद्धि होती हैं। एक एजेंट जो पाँच चरणों में 95 प्रतिशत विश्वसनीय है, वह 20-चरणीय कार्य पर 95 प्रतिशत विश्वसनीय नहीं रहता। पर्याप्त कदम चलाएँ, और आप एक सिक्के के उछाल के करीब पहुँचते रहते हैं।
यह उससे भी बदतर है, क्योंकि त्रुटियाँ स्व-प्रबलित होती हैं। एक टूल कॉल जो थोड़ा सा पथभ्रष्ट हो जाता है, अगले के भी पथभ्रष्ट होने की संभावना बढ़ा देता है। इसे पहली कड़ी के ऊपर रखें, जहां आधार त्रुटि दर स्वयं विंडो भरने के साथ बढ़ रही है, और आपको लंबी-अवधि वाले एजेंटों की विशिष्ट विफलता मोड मिलती है। वे शालीनता से खराब नहीं होते। वे थामे रहते हैं और फिर अचानक चट्टान की तरह गिर जाते हैं।
तीसरी कड़ी: कार्य लंबा है, मॉडल स्टेटलेस है, इसलिए आप मॉडल के बाहर कहीं राज्य रखते हैं।
भाषा मॉडल कॉलों के बीच कुछ भी बनाए नहीं रखते। हर कॉल खाली शुरू होता है। एक मॉडल केवल वही जानता है जो आप उसे वापस खिलाते हैं। तो किसी भी लंबे कार्य के लिए, आपको राज्य को बाहरी बनाना होगा। स्क्रैचपैड। प्रगति फ़ाइलें। चेकपॉइंट। वेक्टर स्टोर। समर्पित मेमोरी परतें जो तथ्यों को निकालती हैं और उन्हें सत्रों में पुनः प्रस्तुत करती हैं।
यह सही और आवश्यक है। और यह एक साफ-सुथरे समाधान जैसा दिखता है। एजेंट कुछ भी महत्वपूर्ण नहीं भूलता, क्योंकि सब कुछ महत्वपूर्ण टिकाऊ भंडारण में रहता है।
चौथी कड़ी: संग्रहीत मेमोरी निष्क्रिय है, और इसे वापस खींचना उसी समस्या को बढ़ावा देता है जिसे हल करने के लिए इसे बनाया गया था।
यहीं पर लूप बंद होता है। एक मॉडल डेटाबेस पर तर्क नहीं कर सकता। वह केवल उसी पर तर्क कर सकता है जो उसकी कॉन्टेक्स्ट विंडो में है। तो मेमोरी केवल उसी क्षण मदद करती है जब इसे वापस खींचा जाता है। और हर पुनर्प्राप्ति टोकन जोड़ती है। एजेंट द्वारा प्रगति को ट्रैक करने के लिए लिखा गया हर सारांश एक टोकन है जिसे उसे बाद में फिर से पढ़ना होगा। इतिहास को संक्षिप्त करने के लिए जगह बनाने वाला हर कॉम्पैक्शन चरण हानिपूर्ण होता है, और वह जो विवरण फेंक देता है वह अक्सर वह सूक्ष्म विवरण होता है जिसका महत्व बाद में ही स्पष्ट होता है।
तो आपने जो मेमोरी सिस्टम कॉन्टेक्स्ट सीमा को हराने के लिए बनाया था, वह अंततः उसे ही खिलाता है। अधिक मेमोरी का मतलब अधिक पुनर्प्राप्ति है, जिसका अर्थ है विंडो में अधिक शोर, जिसका अर्थ है अधिक प्रति-चरण त्रुटि, जो चक्रवृद्धि होती है, जो वही है जिसने आपको पहली जगह में मेमोरी की तलाश करने के लिए प्रेरित किया।
लूप वास्तविक है। और इससे कोई फर्क नहीं पड़ता कि आपकी कॉन्टेक्स्ट विंडो कितनी बड़ी है।
क्षमता कभी भी वह धुरी नहीं थी जो मायने रखती थी
एक बार जब आप लूप देख लेते हैं, तो मानक सुधारों की निरर्थकता स्पष्ट हो जाती है।
एक बड़ी कॉन्टेक्स्ट विंडो इसे नहीं तोड़ती। यह केवल उस सड़न की मात्रा पर छत को ऊपर उठाती है जिसे आप चट्टान से गिरने से पहले जमा कर सकते हैं। इस बीच, प्रभावी कॉन्टेक्स्ट पर हर अध्ययन एक ही बात दिखाता रहता है: विश्वसनीय रूप से उपयोग करने योग्य अंश विज्ञापित संख्या की तुलना में कहीं धीमी गति से बढ़ता है। आप ऐसी क्षमता खरीद रहे हैं जिसका आप वास्तव में उपयोग नहीं कर सकते।
अधिक मेमोरी इसे नहीं तोड़ती। यह उस सामग्री की मात्रा बढ़ाती है जो उस विंडो में फिर से प्रवेश करने के लिए प्रतिस्पर्धा कर रही है जिसमें पहले से ही सब कुछ नहीं हो सकता।
अगली आर्किटेक्चर भी इसे नहीं तोड़ेगी। ध्यान के खिलाफ खड़े चुनौती देने वाले, स्टेट-स्पेस मॉडल जैसे Mamba और इसके हाइब्रिड, अतीत को एक निश्चित आकार की स्थिति में संपीड़ित करके जीतते हैं, न कि हर टोकन को पता योग्य रखकर। यह रैखिक-समय अनुमान और एक मेमोरी फुटप्रिंट खरीदता है जो अनुक्रम के साथ नहीं बढ़ता है। यह एक स्मरण नहीं खरीद सकता। एक निश्चित आकार की स्थिति में सब कुछ नहीं हो सकता, इसलिए यह डिज़ाइन द्वारा भूल जाता है। बड़े पैमाने पर, शुद्ध स्टेट-स्पेस मॉडल उसी चीज़ में ट्रांसफॉर्मर से पीछे रह जाते हैं जो बाहरी मेमोरी प्रदान करने के लिए मौजूद है: अनुक्रम में पहले एक मनमाने बिंदु से एक विशिष्ट तथ्य को वापस खींचना। यही कारण है कि ध्यान के बाद के गंभीर प्रयास हाइब्रिड हैं जो स्मरण करने के लिए अल्पसंख्यक ध्यान परतों को बनाए रखते हैं, जो एक स्टेट मॉडल नहीं कर सकता। जब आप आर्किटेक्चर बदलते हैं तो दीवार हिलती नहीं है। आप बस दूसरी तरफ से उस तक पहुँचते हैं।
तो सबक "एक बड़ा नंबर चुनें" नहीं है। यह है कि क्षमता कभी बाध्यकारी बाधा नहीं थी।
बाध्यकारी बाधा इस बारे में निर्णय की गुणवत्ता है कि प्रत्येक चरण में कौन से टोकन विंडो पर कब्जा करते हैं।
यही पूरा खेल है। सबसे बड़ा उपलब्ध कॉन्टेक्स्ट नहीं, बल्कि सबसे छोटा पर्याप्त कॉन्टेक्स्ट। स्मरण पर प्रासंगिकता। एक प्रथम श्रेणी के संचालन के रूप में जानबूझकर भूलना, न कि ट्रंकेशन का एक आकस्मिक परिणाम। शोध सीधे इसका समर्थन करता है: कुछ हज़ार अच्छी तरह से चुने गए टोकन का क्रम-संरक्षण पुनर्प्राप्ति, मॉडल में एक पूर्ण 128K विंडो डंप करने से बेहतर है। लाभ यह चुनने में है कि क्या प्रवेश करता है, न कि इसमें कि कितना प्रवेश कर सकता है।
और यही वह जाल है जो अधिकांश टीमों को पकड़ लेता है, क्योंकि वे जिस उपकरण का उपयोग चुनने के लिए करते हैं वह गलत आकार का होता है।
समानता प्रासंगिकता नहीं है
यह तय करने का डिफ़ॉल्ट तरीका कि कौन सा कॉन्टेक्स्ट वापस खींचना है, समानता खोज है। सब कुछ एम्बेड करें, और जब एजेंट को कॉन्टेक्स्ट की आवश्यकता हो, तो वर्तमान क्वेरी के निकटतम वैक्टर प्राप्त करें।
लेकिन समानता गलत प्रश्न का उत्तर देती है। यह वह लौटाती है जो करीब है, न कि वह जो संबंधित है। और ये बहुत अलग चीजें हैं।
एजेंट को वास्तव में जिस प्रश्न का उत्तर चाहिए वह कभी नहीं होता "यह किसके समान है।" यह होता है "इस कार्य और इस समय की स्थिति को देखते हुए, जो मायने रखता है उससे क्या जुड़ता है।" यह एक संबंधपरक प्रश्न है। यह निर्भरताओं, उत्पत्ति, किसने किसको प्रतिस्थापित किया, और किस निर्णय ने कौन सा परिणाम दिया, के बारे में है। समान वैक्टर प्राप्त करने के लिए ट्यून किया गया एक स्टोर मॉडल को इसके बजाय निकट-चूकों का एक ढेर सौंपता है। और निकट-चूकें पहली कड़ी के विकर्षक हैं, जो प्रति-चरण त्रुटि को चलाते हैं जो चट्टान में चक्रवृद्धि होती है।
यही कारण है कि समाधान एम्बेडिंग स्टोर के सामने एक पतली कैश नहीं हो सकता। बुद्धिमत्ता लुकअप में नहीं है। यह संरचना में है।
वह परत जिसकी कोई कीमत नहीं लगा रहा
एजेंट स्टैक में कब्जा करने के लिए सबसे महत्वपूर्ण परत मॉडल नहीं है, और यह स्टोर नहीं है। यह बीच की परत है। वह जो तय करती है कि मॉडल किस पर ध्यान देता है।
और वास्तव में वह काम करने के लिए, इसे तीन चीजें होनी चाहिए।
इसे तटस्थ होना चाहिए। इंटरनल्स सबके पैरों तले जमीन बदलते रहते हैं। ट्रांसफॉर्मर से स्टेट स्पेस से हाइब्रिड तक। एक फ्रंटियर मॉडल से दूसरे तक, हर कुछ महीनों में एक नया प्राइस-परफॉर्मेंस लीडर। एक एकल मॉडल से जुड़ी एक कॉन्टेक्स्ट रणनीति एक चलते लक्ष्य पर दांव है। आपका संगठन वास्तव में जिस चीज़ में मूल्य संचित करता है वह उसका कॉन्टेक्स्ट है, आपके एजेंट क्या जानते हैं और क्या कर चुके हैं, इसका कठिन-प्राप्त संरचित रिकॉर्ड। इसे एक विक्रेता की मेमोरी सुविधाओं से बांध दें, और आपने अपनी सबसे टिकाऊ संपत्ति को एक रोडमैप का बंधक बना लिया है जो आपका नहीं है। एक चयन परत जो किसी एकल मॉडल के बाहर रहती है, उसी संगठित कॉन्टेक्स्ट को आपके द्वारा चलाए जाने वाले हर मॉडल की सेवा करने देती है, और अगले मॉडल की भी जिसे आपने अभी तक अपनाया नहीं है।
इसे क्षैतिज होना चाहिए। एक फ्रेमवर्क का चेकपॉइंट एक रन के बारे में जानता है। एक मॉडल की अंतर्निहित मेमोरी एक मॉडल की बातचीत के बारे में जानती है। एक वेक्टर इंडेक्स एक कॉर्पस के बारे में जानता है। उनमें से कोई भी उस तस्वीर को नहीं रखता जो वास्तव में एक बार जब आप वास्तविक वर्कलोड चला रहे होते हैं तो मायने रखती है: कई एजेंट, कई सत्र, कई मॉडल, सभी को कॉन्टेक्स्ट के एक सुसंगत, पूछताछ योग्य दृश्य की आवश्यकता होती है। रिकॉर्ड की उस प्रणाली की भूमिका कोई ऐप या फ्रेमवर्क या लैब आकार में नहीं है, क्योंकि प्रत्येक केवल अपना टुकड़ा देखता है। यह अपने आप में एक परत है, जो उन सभी के बीच क्षैतिज रूप से बैठती है।
इसे संरचित होना चाहिए। यही इसे "सिर्फ एक बेहतर डेटाबेस" से अलग करता है। चयन एक प्रासंगिकता समस्या है, और प्रासंगिकता संबंधपरक है। कॉन्टेक्स्ट, रिश्तों और निर्भरताओं, और उत्पत्ति और प्रतिस्थापन पर संरचना, वह है जो पुनर्प्राप्ति को चयन में बदल देती है। यह भंडारण की तुलना में एक मौलिक रूप से भिन्न आदिम है, और यह वही है जो लूप की मांग है।
"क्या लैब्स यह नहीं भेज देंगी?"
स्पष्ट आपत्ति यह है कि मॉडल लैब्स इसे अवशोषित कर लेंगी। वे मेमोरी और कॉन्टेक्स्ट सुविधाएँ भेजती रहती हैं, और उनके पास मॉडल के अपने ध्यान तक विशेषाधिकार प्राप्त पहुँच है।
वे करेंगी, और आपत्ति आधी सही है। एक एकल ऐप को लपेटने वाले एकल मॉडल के लिए, लैब को इसे संभालने देना अक्सर पर्याप्त होता है। यह ठीक है।
लेकिन लैब्स का प्रोत्साहन अपने स्वयं के मॉडल को और अधिक चिपचिपा बनाना है। यह पोर्टेबिलिटी के विपरीत है। एक मॉडल के इंटरनल्स से जुड़ा क्यूरेशन बहु-मॉडल, संगठन-व्यापी मामले की सेवा नहीं कर सकता। एक वास्तविक कॉन्टेक्स्ट सब्सट्रेट उन सुविधाओं के साथ सीधे प्रतिस्पर्धा नहीं कर रहा है। यह उस स्थिति के लिए मौजूद है जिसकी सेवा करने के लिए लैब्स संरचनात्मक रूप से इच्छुक नहीं हैं: वह जहाँ आप कई एजेंटों और टीमों में कई मॉडल चलाते हैं, और आप उस परत को, जो तय करती है कि आपके एजेंट किस बारे में सोचते हैं, उस विक्रेता के स्वामित्व में नहीं होने देना चाहते जिसका मॉडल वे आज चला रहे हैं।
और प्रवृत्ति इसे और तेज करती है। मॉडल जितने अधिक सक्षम होते जाते हैं, उतना ही अधिक उनका उपयोग किया जाता है। जितना अधिक उनका उपयोग किया जाता है, उतने ही अधिक एजेंट एक संगठन चलाता है। जितने अधिक एजेंट यह चलाता है, उतनी ही अधिक एक तटस्थ, क्षैतिज, संरचित चयन परत मूल्यवान होती है।
यह कौन बना रहा है?
यह वह जगह है जहाँ Hydradb आता है। तटस्थ, क्षैतिज और संरचित। यह उन रिश्तों, निर्भरताओं, उत्पत्ति और प्रतिस्थापन को रखता है जिन्हें समानता खोज समतल कर देती है। यह लौकिक रूप से संस्करणित और प्राथमिकता-जागरूक है, और इसलिए केवल यह नहीं जानता कि क्या सच है बल्कि यह भी जानता है कि किसने इसे बदला। यह समय के साथ एक दिए गए एजेंट ने क्या सीखा है, इसकी दृश्यता को अनलॉक करता है। वह संरचना ही पुनर्प्राप्ति को चयन में बदल देती है।
नीचे, HydraDB स्तरीय भंडारण पर चलता है: सक्रिय कॉन्टेक्स्ट के लिए एक हॉट इन-मेमोरी कैश, गर्म के लिए NVMe, ठंडे के लिए ऑब्जेक्ट स्टोरेज। कॉन्टेक्स्ट को हाल ही और महत्व के आधार पर प्रचारित और पदावनत किया जाता है, ताकि मॉडल जिस कार्यशील सेट पर तर्क करता है वह उद्देश्यपूर्ण रूप से छोटा रहे। मॉडल और वह सब कुछ जो वह जान सकता है, के बीच।
वह प्रश्न जिसका हर एजेंट को उत्तर देना है
आर्किटेक्चर बहसों, मेमोरी उत्पादों, कॉन्टेक्स्ट-विंडो हथियारों की दौड़ को हटा दें। इन सबके नीचे, हर लंबे समय तक चलने वाला एजेंट हर एक कदम पर एक ही प्रश्न का उत्तर देता है।
वह सब कुछ जो वह जानता है, उसे अभी किस बारे में सोचना चाहिए?
एक बड़ी विंडो उस प्रश्न का उत्तर नहीं देती। यह केवल एजेंट को अनदेखा करने के लिए अधिक देती है। लूप वास्तविक है, यह स्थायी है, और कोई भी मात्रा में क्षमता इसे बंद नहीं कर सकती।
उद्योग अभी भी क्षमता के साथ अपना रास्ता खरीदने की कोशिश कर रहा है। यह नहीं हो सकता। जो टीमें यह आंतरिक कर लेती हैं कि यह हमेशा एक चयन समस्या थी, वे ऐसे एजेंट भेजेंगी जो काम करते हैं, जबकि बाकी सभी ऐसे एजेंट भेजेंगे जो लगभग करते हैं।
यह कभी मॉडलों की एक शुद्ध सीमा नहीं थी। कोई भी चीज जो एक सीमित बजट के तहत संचालित होती है, उसे चुनना होता है कि वह किस पर ध्यान दे। चयन आज की सीमाओं के लिए एक कामचलाउ व्यवस्था नहीं है। यह वही है जो सीमाओं के तहत तर्क करने के लिए हमेशा आवश्यक रहा है।
अगर आपको यह उपयोगी लगा, तो मुझे फॉलो करें @eng_khairallah1 इस तरह की और AI सामग्री के लिए। मैं हर हफ्ते ब्रेकडाउन, कोर्स और टूल पोस्ट करता हूँ।
उम्मीद है यह आपके लिए उपयोगी था, खैरुल्लाह ❤️
