प्रकार के आधार पर मेमोरी को व्यवस्थित करने से रिट्रीव किए गए टोकन लगभग 40% कम हो जाते हैं।
एक फ्लैट मेमोरी स्टोर क्यों विफल हो जाता है
अधिकांश शुरुआती ट्यूटोरियल एक LLM एजेंट को हर नई जानकारी को एक ही लिस्ट में जोड़कर और हर टर्न में उस लिस्ट को मॉडल को वापस भेजकर "याद रखने" की शिक्षा देते हैं। कोड वास्तव में केवल तीन लाइनों का होता है, और यह एक वर्किंग डेमो तैयार कर देता है। व्यवहार में, यह लिस्ट बिना किसी नियंत्रण के बढ़ती जाती है। इसके दो लक्षण दिखाई देते हैं:
- एजेंट पुराने डेटा को अभी भी सही मानता है, उदाहरण के लिए, ऐसा ETA देना जो घंटों पहले समाप्त हो चुका हो।
- कॉन्टेक्स्ट विंडो ऐसी फालतू जानकारी से भर जाती है जो उत्तर को प्रभावित नहीं करती, जिससे API लागत बढ़ जाती है और रिस्पॉन्स टाइम धीमा हो जाता है।
एक साधारण वेक्टर स्टोर या सरल की-वैल्यू कैश (key-value cache) यूजर के जॉब टाइटल और किसी अस्थायी प्रोजेक्ट स्टेटस के बीच अंतर नहीं कर सकता। जब एजेंट सिमेंटिक सर्च (semantic search) करता है, तो समानता एल्गोरिदम (similarity algorithm) केवल इसलिए एक पुराना ETA सामने ला सकता है क्योंकि क्वेरी में वही शब्द हैं, भले ही वह डेटा अब प्रासंगिक न हो।
स्ट्रक्चर्ड मेमोरी: चार बकेट, एक उद्देश्य
इसका समाधान यह है कि मेमोरी को एक अखंड इकाई (monolith) के रूप में मानना बंद करें और प्रत्येक प्रविष्टि को चार श्रेणियों में से एक में वर्गीकृत करना शुरू करें:
- User facts – स्थिर गुण जैसे कि यूजर की भूमिका, पसंदीदा भाषा, या सुरक्षा मंजूरी। ये शायद ही कभी बदलते हैं और पूरे सेशन के लिए कैश किए जा सकते हैं।
- Feedback – स्पष्ट नियम जिनका एजेंट को पालन करना चाहिए, जैसे, "डेटाबेस पासवर्ड कभी न बताएं" या "अनुपालन (compliance) संबंधी प्रश्नों में हास्य से बचें।" क्योंकि ये व्यवहार को नियंत्रित करते हैं, इसलिए इन्हें सर्च करने योग्य पूल के बजाय सिस्टम प्रॉम्प्ट में होना चाहिए।
- Project state – तेजी से बदलने वाला डेटा जैसे वर्तमान ETA, कार्य की प्रगति, या अस्थायी टोकन। इस बकेट को एक्सपायरी चेक की आवश्यकता होती है; एक बार जब टाइमस्टैम्प एक निर्धारित विंडो से बाहर हो जाता है, तो प्रविष्टि को हटा दिया जाना चाहिए।
- References – बाहरी सेवाओं, डॉक्यूमेंट आईडी, या API एंडपॉइंट्स के पॉइंटर्स। ये प्रदर्शित किए जाने वाले कंटेंट नहीं हैं, बल्कि आवश्यकता पड़ने पर नया डेटा प्राप्त करने के मार्ग हैं।
Mem0 डेवलपर्स को प्रत्येक मेमोरी रिकॉर्ड के साथ मनमाना मेटाडेटा जोड़ने की अनुमति देता है। "kind" फ़ील्ड पर इंडेक्सिंग करके, LLM द्वारा परिणाम का उपयोग करने का निर्णय लेने से पहले, एक क्वेरी प्रासंगिक बकेट के लिए फ़िल्टर कर सकती है।
Mem0 के साथ दो-चरणीय रिट्रीवल
- Pull memories by kind – एक छोटा फ़िल्टर क्वेरी Mem0 से "सभी फीडबैक" या "एक छोटे अंतराल से नए प्रोजेक्ट-स्टेट प्रविष्टियों" के बारे में पूछता है। परिणाम सेट पहले से ही उचित श्रेणी तक सीमित होता है।
- Let the LLM decide – फ़िल्टर किए गए स्निपेट्स को यूजर के वर्तमान प्रश्न के साथ प्रॉम्प्ट में डाला जाता है। अब मॉडल अप्रासंगिक तथ्यों को छाने बिना उनके बारे में तर्क दे सकता है।
एक ठोस उदाहरण: "डेटाबेस का मजाक न उड़ाएं" नियम को सामने लाने के लिए सिमेंटिक मैच का इंतजार करने के बजाय, डेवलपर उस नियम को सेशन की शुरुआत में सीधे सिस्टम प्रॉम्प्ट में डाल देता है और पूरे इंटरैक्शन के लिए उसे कैश कर देता है। भले ही यूजर की क्वेरी में डेटाबेस का कोई स्पष्ट संदर्भ न हो, मॉडल पहले से ही उस प्रतिबंध को जानता है।
लागत कम रखने के व्यावहारिक तरीके
- Cache feedback rules – नियम सेट को प्रति सेशन एक बार स्टोर करें और हर टर्न पर फिर से खोजने के बजाय उसका पुन: उपयोग करें। यह प्रत्येक राउंड में टोकन के उपयोग को कम करता है।
- Skip project-state searches when irrelevant – यदि यूजर पूरी तरह से वैचारिक प्रश्न पूछता है ("सुपरवाइज्ड और रीइन्फोर्समेंट लर्निंग के बीच क्या अंतर है?"), तो किसी भी ETA या कार्य प्रगति डेटा को निकालने की आवश्यकता नहीं है।
इन दो आदतों को लागू करके, एक साधारण फ्लैट मेमोरी दृष्टिकोण की तुलना में टोकन के उपयोग को लगभग 40% तक कम किया जा सकता है। यह बचत सीधे तौर पर कम API बिल और तेज़ टर्नअराउंड में बदल जाती है, विशेष रूप से उन एजेंटों के लिए जो कई एक्सचेंजों तक सक्रिय रहते हैं।
किसे लाभ होगा, किसे चिंता होगी
Winners – कस्टमर-सपोर्ट बॉट्स, इंटरनल वर्कफ़्लो असिस्टेंट, या किसी भी मल्टी-टर्न LLM इंटरफ़ेस को बनाने वाली टीमें। उन्हें अधिक विश्वसनीय उत्तर मिलते हैं, पुराने डेटा के कारण होने वाली शर्मनाक गलतियों से बचाव होता है, और वे अपने बजट का बेहतर उपयोग कर पाती हैं।
मुख्य बात (Takeaway)
यदि आप एक ऐसा LLM एजेंट चाहते हैं जो लंबे सेशन के दौरान भी सटीक बना रहे, तो हर तथ्य को एक ही कॉन्टेक्स्ट विंडो में भरना बंद करें। प्रत्येक मेमोरी को user fact, feedback, project state, या reference के रूप में टैग करें, जहाँ आवश्यक हो वहाँ एक्सपायरी लागू करें, और Mem0 जैसे टूल को भारी काम करने दें। इसका परिणाम है ताज़ा उत्तर, कम अनावश्यक टोकन और परिचालन लागत में उल्लेखनीय कमी।