आपके टोकन खत्म नहीं हो रहे हैं। आप उन्हें बर्बाद कर रहे हैं। यहाँ अंतर बताया गया है।

जितना अधिक समय मैं LLM के साथ काम कर रहा हूँ, उतना ही मैं खुद को पर्याप्त संदर्भ, अत्यधिक संदर्भ, टोकन बर्बादी और संघनन युद्ध के बीच एक शाश्वत लड़ाई में पाता हूँ, एजेंटिक मेमोरी सिस्टम को देखते हुए हम देख सकते हैं कि इसमें सहायता के लिए कुछ शक्तिशाली हथियार हैं।

जो निष्कर्ष मैंने 19 सिस्टमों में देखा, वह यह है कि बड़ी विंडो समस्या को हल करने के बजाय बजट की समस्या को और बढ़ा देती हैं। 200K-टोकन विंडो सभी 200K टोकनों पर समान ध्यान नहीं देती। विंडो भरने से बहुत पहले ही प्रदर्शन गिर जाता है। यह गिरावट एक समान नहीं होती: लंबे संदर्भ के बीच की सामग्री पर किनारों की सामग्री की तुलना में कम ध्यान जाता है। और एजेंट का वास्तविक कार्य विंडो के आकार की परवाह किए बिना एक निश्चित हिस्सा घेरता है, जिसका अर्थ है कि बाकी सब कुछ उसी ध्यान बजट के लिए प्रतिस्पर्धा करने वाला ओवरहेड है।

जो सिस्टम इसे अच्छी तरह से संभालते हैं, वे छह तंत्रों पर एकमत हुए हैं। उनमें से कोई भी विदेशी नहीं है। कई आश्चर्यजनक रूप से सरल हैं। लेकिन जो उन्हें छोड़ देते हैं, वे इसकी कीमत चुकाते हैं।

छह तंत्र

संघनन पास

सबसे दृश्यमान तंत्र। आप एक लंबी बातचीत या एक बड़ी मेमोरी सेगमेंट लेते हैं, उसे सारांशित करते हैं, और मूल को सारांश से बदल देते हैं। MemoryOS इसे सेगमेंट स्तर पर करता है: इसका सेगमेंट संक्षेपक तब सक्रिय होता है जब कोई वार्तालाप सेगमेंट एक सीमा से अधिक बढ़ जाता है, उसे कार्यशील संदर्भ से बाहर करने से पहले एक संक्षिप्त प्रतिनिधित्व में संकुचित करता है। कारपैथी-पैटर्न विकियाँ (purpose.md, overview.md) ज्ञान स्तर पर इसका एक संस्करण करती हैं: विकी वह सब कुछ का संकुचित रूप है जो एजेंट ने किसी विषय के बारे में सीखा है, जो सत्रों में बनाए रखा जाता है।

इसका व्यापार-बंद सूचना हानि है। संघनन परिभाषा के अनुसार एक हानिपूर्ण संक्रिया है। सारांश वही कैप्चर करता है जो संघनन के समय संक्षेपक ने प्रासंगिक समझा। यदि एजेंट को बाद में एक ऐसे विवरण की आवश्यकता होती है जिसे प्रासंगिक नहीं माना गया, तो वह चला जाता है। यह संघनन से बचने का कारण नहीं है, लेकिन यह एक कारण है कि इसे एकमात्र तंत्र न मानें।

एक दूसरी लागत भी है जिसे अनदेखा करना आसान है। संघनन रनटाइम पर मुफ्त नहीं है। MemoryOS एक ही इंटरैक्शन में अपने सेगमेंट सारांश को बनाए रखने के लिए 20 या उससे अधिक LLM कॉल का भुगतान कर सकता है। उच्च इंटरैक्शन आवृत्ति वाले सिस्टम के लिए, यह एक वास्तविक परिचालन लागत है।

परिणाम-पूर्वावलोकन छंटाई

हर पुनर्प्राप्ति पर पूर्ण मेमोरी सामग्री लौटाने के बजाय, एक छोटा पूर्वावलोकन लौटाएँ और एजेंट को यह तय करने दें कि पूर्ण रिकॉर्ड लाना है या नहीं। supermemory स्निपेट-लंबाई नियंत्रण प्रदान करता है जो कॉल करने वालों को प्रति परिणाम कितना टेक्स्ट वापस आता है, इसे समायोजित करने की अनुमति देता है। mem9 इसे और आगे ले जाता है: यह स्रोत टर्न को तीन पर्यावरण चर (MEM9_SOURCE_TURN_MIN_SCORE, MEM9_SOURCE_TURN_PER_MEMORY_LIMIT, MEM9_SOURCE_TURN_TOTAL_LIMIT) से सजाता है जो ऑपरेटरों को सटीक नियंत्रण देते हैं कि कितने स्रोत टर्न दिखाई देते हैं और किस न्यूनतम प्रासंगिकता स्कोर पर।

इसका व्यापार-बंद एक अतिरिक्त टूल कॉल है। यदि एजेंट को पूर्ण सामग्री की आवश्यकता है, तो उसे स्पष्ट रूप से इसके लिए पूछना होगा। अधिकांश पुनर्प्राप्ति पैटर्न के लिए यह सही व्यापार-बंद है: एजेंट को यह तय करने के लिए पर्याप्त संकेत मिलता है कि रिकॉर्ड प्रासंगिक है या नहीं, इससे पहले कि वह इसे पूरा पढ़ने का टोकन खर्च करे।

दो-चरणीय पुनर्प्राप्ति

पूर्वावलोकन छंटाई का एक विशिष्ट और महत्वपूर्ण प्रकार। खोज पहचानकर्ता और छोटे पूर्वावलोकन लौटाती है। जब आवश्यक हो, एक अलग GetByID कॉल पूर्ण रिकॉर्ड लाती है। mem9 का MemoryRepo इंटरफ़ेस इस पैटर्न के आसपास बनाया गया है: खोज और लाना अलग-अलग संचालन हैं जिनके अलग-अलग टोकन पदचिह्न हैं।

संख्याएँ इसे स्पष्ट रूप से प्रदर्शित करती हैं। 1,500 टोकन प्रति के दस मैच 15,000 टोकन हैं जो संदर्भ में इंजेक्ट किए जाते हैं, भले ही एजेंट उनका उपयोग करे या नहीं। दो-चरणीय पुनर्प्राप्ति लगभग 450 टोकन कुल में 10 पहचानकर्ता और छोटे पूर्वावलोकन लौटाती है, फिर केवल उन रिकॉर्ड को लाती है जिनकी एजेंट को वास्तव में आवश्यकता होती है। एक सत्र में 20 रिकॉल चरणों में, यह अंतर लगभग 200,000 टोकन बचत में बदल जाता है।

यह सबसे सस्ता अनुशासन है जिसे आप अपना सकते हैं। इसमें मेमोरी स्टोर में कोई आर्किटेक्चरल बदलाव, कोई अतिरिक्त LLM कॉल और कोई सूचना हानि की आवश्यकता नहीं है। यह एक पुनर्प्राप्ति इंटरफ़ेस निर्णय है।

विघटित-फिर-याद करें

पूर्ण उपयोगकर्ता क्वेरी को पुनर्प्राप्ति परत पर भेजने के बजाय, पहले इसे उप-प्रश्नों में विघटित करें। SimpleMem का इरादा-जागरूक पुनर्प्राप्ति योजनाकार आने वाली प्रश्नों को मेमोरी स्टोर पर जाने से पहले परमाणु पुनर्प्राप्ति इरादों में तोड़ता है। GitNexus अपने क्वेरी टूल विघटन के साथ कुछ समान करता है: जटिल प्रश्न लक्षित उप-प्रश्नों में विभाजित होते हैं, जिनमें से प्रत्येक मेमोरी ग्राफ का एक केंद्रित टुकड़ा पुनर्प्राप्त करता है।

लाभ सटीकता है। एक विघटित क्वेरी कम अप्रासंगिक सामग्री पुनर्प्राप्त करती है, जिसका अर्थ है संदर्भ में कम शोर। व्यापार-बंद विलंबता है: विघटन पुनर्प्राप्ति शुरू होने से पहले एक योजना चरण जोड़ता है। इंटरैक्टिव एजेंटों के लिए यह मायने रखता है। बैच या पृष्ठभूमि एजेंटों के लिए आमतौर पर ऐसा नहीं होता।

स्तरीय भंडारण बजट फिल्टर के रूप में

यदि आपने पहले से ही एक स्तरीय मेमोरी आर्किटेक्चर बनाया है (पिछले सप्ताह के लेख का विषय), तो आपको एक साइड इफेक्ट के रूप में बजट फ़िल्टरिंग मिलती है। supermemory का तीन-स्तरीय मॉडल यह सुनिश्चित करता है कि गर्म, बार-बार उपयोग की जाने वाली सामग्री एक ऐसे स्तर में रहती है जो संक्षिप्त, उच्च-संकेत परिणाम लौटाता है। ठंडी सामग्री एक ऐसे स्तर में है जिसे डिफ़ॉल्ट रूप से क्वेरी नहीं किया जाता है। Hindsight का अवलोकन स्तर उसी तरह काम करता है: कच्चे अवलोकन सीधे संदर्भ में इंजेक्ट नहीं होते; वे पुनर्प्राप्ति उम्मीदवार बनने से पहले उच्च स्तरों पर प्रोत्साहित होते हैं।

इसका व्यापार-बंद रिकॉल पूर्णता है। जिस सामग्री को प्रोत्साहित नहीं किया गया है वह प्रासंगिक हो सकती है लेकिन मानक पुनर्प्राप्ति पास में सामने नहीं आएगी। यह संघनन के समान व्यापार-बंद है, लेकिन विफलता मोड अलग है: सारांशीकरण के माध्यम से जानकारी खोने के बजाय, आप इसे पदावनति के माध्यम से खोते हैं।

स्व-निर्देशन उपकरण प्रतिक्रियाएँ

सबसे कम चर्चित तंत्र, और अधिक दिलचस्प में से एक। एजेंट को टूल कॉल के बाद क्या करना है यह तय करने के लिए छोड़ने के बजाय, टूल प्रतिक्रिया में स्वयं आगे क्या करना है इसका एक संकेत शामिल होता है। GitNexus टूल प्रतिक्रियाओं में एक ---
**Next:** ब्लॉक जोड़ता है, जो अनुवर्ती कार्रवाइयों का सुझाव देता है। mem9 स्रोत टर्न को संरचित मेटाडेटा से सजाता है जो एजेंट के अगले पुनर्प्राप्ति चरण का मार्गदर्शन करता है।

प्रभाव यह है कि एजेंट टूल कॉल के बीच योजना बनाने पर कम टोकन खर्च करता है। टूल प्रतिक्रिया में अगले चरण को स्पष्ट करने के लिए पर्याप्त संरचना होती है। व्यापार-बंद प्रॉम्प्ट-इंजीनियरिंग प्रयास है: अच्छी स्व-निर्देशन प्रतिक्रियाएँ लिखने के लिए पहले से जानना आवश्यक है कि एजेंट को आगे क्या चाहिए होगा, जो हमेशा संभव नहीं है।

Tolaria सीमा मामला

Tolaria को अलग से देखने लायक है क्योंकि यह बजट अनुशासन के चरम पर तार्किक अंत बिंदु का प्रतिनिधित्व करता है। ADR-0009 सिस्टम से पूरी तरह से एम्बेडिंग हटाने के निर्णय का दस्तावेजीकरण करता है। Tolaria केवल सबस्ट्रिंग खोज का उपयोग करता है। कोई वेक्टर इंडेक्स नहीं, कोई सिमेंटिक पुनर्प्राप्ति नहीं, कोई एम्बेडिंग कॉल नहीं।

तर्क सीधा है: सबसे सस्ता टोकन वह है जिसे आप पहले स्थान पर कभी पुनर्प्राप्त नहीं करते। एम्बेडिंग-आधारित पुनर्प्राप्ति सिमेंटिक रूप से समान परिणाम लौटाती है, जिसका अर्थ है कि यह ऐसे परिणाम लौटाती है जो एजेंट ने स्पष्ट रूप से नहीं मांगे। उनमें से कुछ परिणाम उपयोगी होते हैं। कई नहीं होते। इन सभी की कीमत टोकन होती है।

Tolaria की स्थिति यह है कि अप्रासंगिक-लेकिन-समान परिणामों की लागत, एक सत्र में चक्रवृद्धि होने पर, इसके उपयोग मामले के लिए सिमेंटिक रिकॉल के लाभ से अधिक होती है। क्या यह व्यापार-बंद आपके सिस्टम के लिए मान्य है, यह इस बात पर निर्भर करता है कि आपका सिस्टम किस लिए है। उन सिस्टमों के लिए जहाँ प्रश्न सटीक और संरचित हैं (कोड नेविगेशन, पहचानकर्ता द्वारा दस्तावेज़ खोज), Tolaria की स्थिति बचाव योग्य है। उन सिस्टमों के लिए जहाँ प्रश्न अस्पष्ट और खोजपूर्ण हैं, एम्बेडिंग हटाने से रिकॉल इस तरह टूटता है जिससे उबरना मुश्किल है।

Tolaria मामले का मूल्य यह नहीं है कि आपको इसकी नकल करनी चाहिए। यह है कि यह सिमेंटिक पुनर्प्राप्ति की लागत को इस तरह दृश्यमान बनाता है जैसे अधिकांश सिस्टम नहीं करते।

केवल-संघनन सिस्टम के खिलाफ मामला

19 सिस्टमों में से कई संघनन पर अपने प्राथमिक या एकमात्र बजट तंत्र के रूप में निर्भर हैं। विफलता मोड का नाम लेना उचित है।

पहला यह कि सारांशीकरण उन विवरणों को खो देता है जो संघनन के समय प्रासंगिक नहीं समझे गए लेकिन बाद में प्रासंगिक हो जाते हैं। यह काल्पनिक नहीं है: यह किसी भी हानिपूर्ण संपीड़न योजना का मानक विफलता मोड है जो ऐसी जानकारी पर लागू होता है जिसकी भविष्य की प्रासंगिकता अज्ञात है।

दूसरा यह कि संघनन एक हॉट-पाथ लागत है। MemoryOS द्वारा प्रति इंटरैक्शन 20+ LLM कॉल का भुगतान करना संघनन-भारी सिस्टम के लिए असामान्य नहीं है। बड़े पैमाने पर, यह लागत नगण्य नहीं है।

तीसरा, और सबसे सूक्ष्म, यह है कि बिना किसी भागने के छेद के संघनन धीमी गति से भूलना है। यदि संदर्भ आकार कम करने का एकमात्र तरीका सारांशित करना है, और सारांश हानिपूर्ण हैं, तो सिस्टम लगातार जानकारी को त्याग रहा है जिसे पुनर्प्राप्त करने का कोई तरीका नहीं है। दो-चरणीय पुनर्प्राप्ति, स्तरीय भंडारण और परिणाम-पूर्वावलोकन छंटाई सभी मूल रिकॉर्ड को संरक्षित करते हैं। संघनन नहीं करता।

इसका मतलब यह नहीं है कि संघनन गलत है। इसका मतलब है कि अकेला संघनन पर्याप्त नहीं है।

हाल की भारांक और सतत कतार

दो तंत्र जो ऊपर की छह श्रेणियों में बिल्कुल फिट नहीं होते, वे ध्यान देने योग्य हैं।

graymatter आधे भार पर हाल के साथ RRF फ्यूजन का उपयोग करता है। यह सख्त अर्थों में बजट तंत्र नहीं है, लेकिन यह एक के रूप में कार्य करता है: पुनर्प्राप्ति रैंकिंग में पुरानी सामग्री को कम भार देकर, यह संभावना कम करता है कि बासी, कम-संकेत रिकॉर्ड हाल ही के, उच्च-संकेत वाले को बाहर कर दें। प्रभाव स्पष्ट स्तर प्रोत्साहन के बजाय रैंकिंग भार के माध्यम से नरम स्तरीकरण है।

llm-wiki का 540-लाइन इनजेस्ट कतार राज्य मशीन एक अलग दृष्टिकोण लेता है। कतार इनजेस्ट संचालन को क्रमबद्ध करती है और मेमोरी स्टोर में कुछ भी प्रवेश करने से पहले एक चार-संकेत प्रासंगिकता रैंकर लागू करती है। बजट नियंत्रण पढ़ने के समय के बजाय लिखने के समय होता है। जो सामग्री प्रासंगिकता सीमा को पार नहीं करती, वह संग्रहीत नहीं होती, जिसका अर्थ है कि इसे पुनर्प्राप्त नहीं किया जा सकता और यह संदर्भ का उपभोग नहीं कर सकता। यह अप्रत्यक्ष बजट नियंत्रण है, लेकिन यह टिकाऊ है: बचत हर भविष्य के सत्र में चक्रवृद्धि होती है।

अच्छी तरह से डिज़ाइन किए गए सिस्टम में क्या समान है

19 सिस्टमों को देखते हुए, जो संदर्भ बजट को अच्छी तरह से संभालते हैं, उनमें कुछ गुण साझा होते हैं।

वे पुनर्प्राप्ति को एक-चरणीय इंजेक्शन के बजाय दो-चरणीय संचालन के रूप में मानते हैं। वे पूर्ण रिकॉर्ड से पहले पूर्वावलोकन लौटाते हैं। वे सारांश के साथ बदलने के बजाय मूल रिकॉर्ड को संरक्षित करते हैं। वे हार्डकोडेड डिफ़ॉल्ट के बजाय स्पष्ट पैरामीटर के माध्यम से ऑपरेटरों को पुनर्प्राप्ति मात्रा पर नियंत्रण देते हैं। और वे पढ़ने के समय के साथ-साथ लिखने के समय भी बजट के बारे में सोचते हैं।

जो इसे खराब तरीके से संभालते हैं, वे आमतौर पर एक एकल तंत्र, आमतौर पर संघनन पर निर्भर होते हैं, और संदर्भ विंडो को एक ऐसे संसाधन के रूप में मानते हैं जिसे प्रबंधित किया जाना चाहिए, न कि एक बफर के रूप में जिसे भरा जाना चाहिए।

शोध से निकलने वाली अंतिम स्थिति सरल है। बड़ी विंडो अधिक अनुशासन की मांग करती हैं, कम की नहीं। इसलिए नहीं कि उन्हें भरना सिद्धांत रूप में गलत है, बल्कि इसलिए कि उन्हें गलत सामग्री से भरने की लागत कमरे को खाली छोड़ने से अधिक होती है।

अपने अगले लेख के लिए मैं मेमोरी-एज़-इंजेक्शन से मेमोरी-एज़-टूल्स पर स्थानांतरित होने की योजना बना रहा हूँ, जिसमें यह शामिल होगा कि 19 सिस्टम उस सीमा को कैसे संभालते हैं कि क्या स्वचालित रूप से संदर्भ में धकेला जाता है और क्या एजेंट को स्पष्ट रूप से पूछना पड़ता है।*

हमेशा की तरह, यदि आपको यह दिलचस्प, उपयोगी लगा या बस ज्ञान फैलाने में मदद करना चाहते हैं:

कृपया साझा करें