प्रकारानुसार मेमरीची रचना केल्यामुळे मिळवलेले टोकन्स सुमारे ४०% ने कमी होतात.
फ्लॅट मेमरी स्टोअर का निकामी ठरते
बहुतेक सुरुवातीच्या ट्युटोरियल्समध्ये LLM एजंटला प्रत्येक नवीन माहिती एका सिंगल लिस्टमध्ये जोडून आणि प्रत्येक वेळी तीच लिस्ट मॉडेलला परत देऊन "लक्षात ठेवण्यास" शिकवले जाते. याचा कोड शब्दशः फक्त तीन ओळींचा असतो आणि तो एक वर्किंग डेमो तयार करतो. प्रत्यक्षात, ही लिस्ट अनियंत्रितपणे वाढत जाते. यामुळे दोन लक्षणे दिसून येतात:
- एजंट जुनाट डेटा अजूनही सत्य मानतो, उदाहरणार्थ, तासनतास आधी संपलेला ETA देतो.
- कॉन्टेक्स्ट विंडो अशा अनावश्यक माहितीने भरून जाते ज्याचा उत्तरावर कोणताही परिणाम होत नाही, ज्यामुळे API खर्च वाढतो आणि प्रतिसाद मिळण्याचा वेग मंदावतो.
एक साधा वेक्टर स्टोअर किंवा साधी की-व्हॅल्यू कॅश (key-value cache), वापरकर्त्याचे पद (job title) आणि तात्पुरती प्रोजेक्ट स्थिती यातील फरक ओळखू शकत नाही. जेव्हा एजंट सिमेंटिक सर्च (semantic search) करतो, तेव्हा सिमिलॅरिटी अल्गोरिदम केवळ क्वेरीमध्ये तीच शब्दांची पुनरावृत्ती असल्यामुळे जुना ETA समोर आणू शकतो, जरी ती माहिती आता संबंधित नसली तरीही.
स्ट्रक्चर्ड मेमरी: चार बकेट्स, एक उद्देश
उपाय म्हणजे मेमरीकडे एक एकसंध (monolith) घटक म्हणून पाहणे थांबवणे आणि प्रत्येक एन्ट्रीचे चार श्रेणींपैकी एकामध्ये वर्गीकरण करणे सुरू करणे:
- User facts – वापरकर्त्याची भूमिका, पसंतीची भाषा किंवा सुरक्षा क्लिअरन्स यांसारखे स्थिर गुणधर्म. हे क्वचितच बदलतात आणि संपूर्ण सेशनसाठी कॅश (cache) केले जाऊ शकतात.
- Feedback – एजंटने पाळायचे स्पष्ट नियम, उदा. "डेटाबेस पासवर्ड कधीही उघड करू नका" किंवा "अनुपालन (compliance) क्वेरीजमध्ये विनोदाचा वापर टाळा." हे नियम वर्तनावर नियंत्रण ठेवतात, म्हणून ते सर्च करण्यायोग्य पूलमध्ये ठेवण्याऐवजी सिस्टम प्रॉम्प्टमध्ये असणे आवश्यक आहे.
- Project state – सध्याचे ETA, कामाची प्रगती किंवा तात्पुरते टोकन्स यांसारखा वेगाने बदलणारा डेटा. या बकेटला एक्सपायरी चेकची (expiry check) गरज असते; एकदा का टाइमस्टॅम्प ठरवलेल्या मर्यादेबाहेर गेला की ती एन्ट्री काढून टाकली पाहिजे.
- References – बाह्य सेवा, डॉक्युमेंट आयडी किंवा API एंडपॉइंट्सचे पॉइंटर्स. हे प्रदर्शित करायचे कंटेंट नसून गरज पडल्यास नवीन डेटा मिळवण्यासाठीचे मार्ग आहेत.
Mem0 डेव्हलपर्सना प्रत्येक मेमरी रेकॉर्डला कोणतेही मेटाडेटा जोडण्याची सुविधा देते. "kind" फील्डवर इंडेक्सिंग करून, LLM ने निकालाचा वापर कसा करायचा हे ठरवण्यापूर्वी, क्वेरी प्रथम संबंधित बकेटसाठी फिल्टर करू शकते.
Mem0 सह दोन-टप्प्यातील रिट्रिव्हल (retrieval)
- kind नुसार मेमरीज मिळवणे – एक छोटी फिल्टर क्वेरी Mem0 ला "सर्व फीडबॅक" किंवा "एका ठराविक कालावधीपेक्षा नवीन प्रोजेक्ट-स्टेट एन्ट्रीज" विचारते. रिझल्ट सेट आधीच योग्य श्रेणीनुसार मर्यादित केलेला असतो.
- LLM ला निर्णय घेऊ देणे – फिल्टर केलेले स्निपेट्स वापरकर्त्याच्या सध्याच्या प्रश्नासोबत प्रॉम्प्टमध्ये समाविष्ट केले जातात. आता मॉडेल अनावश्यक तथ्ये शोधण्याशिवाय त्यांच्याबद्दल तर्क करू शकते.
एक ठोस उदाहरण: "डेटाबेसची थट्टा करू नका" हा नियम सिमेंटिक मॅचद्वारे समोर येण्याची वाट पाहण्याऐवजी, डेव्हलपर तो नियम सेशन सुरू होताना थेट सिस्टम प्रॉम्प्टमध्ये समाविष्ट करतो आणि संपूर्ण संवादासाठी तो कॅश करतो. वापरकर्त्याच्या क्वेरीमध्ये डेटाबेसचा कोणताही स्पष्ट उल्लेख नसला तरीही, मॉडेलला आधीच त्या मर्यादेची माहिती असते.
खर्च कमी ठेवण्यासाठी काही व्यावहारिक युक्त्या
- Feedback नियम कॅश करा – प्रत्येक वेळी पुन्हा शोधण्याऐवजी नियम संच सेशनमध्ये एकदाच स्टोअर करा आणि त्याचा पुन्हा वापर करा. यामुळे प्रत्येक राउंडमध्ये टोकनचा वापर कमी होतो.
- अनावश्यक असल्यास प्रोजेक्ट-स्टेट सर्च टाळा – जर वापरकर्त्याने पूर्णपणे वैचारिक प्रश्न विचारला ("supervised आणि reinforcement learning मध्ये काय फरक आहे?"), तर कोणताही ETA किंवा कामाच्या प्रगतीचा डेटा मिळवण्याची गरज नाही.
या दोन सवयी लागू केल्यामुळे, साध्या फ्लॅट मेमरी पद्धतीपेक्षा टोकनचा वापर सुमारे ४०% ने कमी होऊ शकतो. यामुळे थेट API बिल कमी होते आणि कामाचा वेग वाढतो, विशेषतः अशा एजंट्ससाठी जे अनेक संवादांपर्यंत सक्रिय राहतात.
कोणाचा फायदा होतो आणि कोणाला काळजी वाटते
विजेते (Winners) – कस्टमर-सपोर्ट बॉट्स, अंतर्गत वर्कफ्लो असिस्टंट किंवा कोणतेही मल्टी-टर्न LLM इंटरफेस तयार करणाऱ्या टीम्स. त्यांना अधिक विश्वसनीय उत्तरे मिळतात, जुनाट डेटामुळे होणाऱ्या चुकीच्या चुका टाळता येतात आणि त्यांच्या बजेटचा अधिक चांगल्या प्रकारे वापर करता येतो.
सारांश (Takeaway)
जर तुम्हाला दीर्घ संवादादरम्यान चपळ राहणारा LLM एजंट हवा असेल, तर प्रत्येक तथ्य एका सिंगल कॉन्टेक्स्ट विंडोमध्ये भरत राहणे थांबवा. प्रत्येक मेमरीला user fact, feedback, project state किंवा reference असे टॅग करा, जिथे आवश्यक आहे तिथे एक्सपायरी लागू करा आणि Mem0 सारख्या टूलला मुख्य काम करू द्या. याचा परिणाम म्हणजे अधिक ताजी उत्तरे, कमी अनावश्यक टोकन्स आणि ऑपरेटिंग खर्चात लक्षणीय घट.