MemGPT - अनंत context के लिए self-editing memory वाले LLMs

 (github.com/cpacker)
2 पॉइंट द्वारा GN⁺ 2023-10-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Letta एक ऐसा प्रोजेक्ट है जिसका उद्देश्य advanced memory पर आधारित AI बनाना है, जो समय के साथ सीख सकता है और खुद को बेहतर बना सकता है
  • उपयोग का तरीका दो भागों में बंटा है: local terminal में agent चलाने के लिए Letta Code और applications में agent integrate करने के लिए Letta API
  • CLI के लिए Node.js 18+ जरूरी है; npm install -g @letta-ai/letta-code से install करने के बाद letta चलाकर local computer पर memory वाला agent चलाया जाता है
  • Letta Code agent coding और computer पर किए जा सकने वाले कामों में मदद करता है, skills और subagents को support करता है, और advanced memory व continuous learning के लिए pre-built skills/subagents bundled देता है
  • Letta model-agnostic है, और README best performance के लिए Opus 4.5 और GPT-5.2 की सिफारिश करता है तथा ranking reference के रूप में model leaderboard से जोड़ता है
  • Letta API stateful agents को applications में integrate करने के लिए है, और full-featured agents API के साथ Python और TypeScript SDK प्रदान करता है
    • TypeScript/Node.js package: @letta-ai/letta-client
    • Python package: letta-client
    • उदाहरण में LETTA_API_KEY और Letta API key का उपयोग करके agent बनाने और messages भेजने का flow दिखाया गया है
  • Letta और संबंधित Letta services का उपयोग privacy policy और terms of service से सहमति की शर्त पर है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-10-17
Hacker News की राय

  • हम MemGPT के लेखक हैं। अगर implementation से जुड़े सवाल हों, तो जवाब देंगे
    अगर आप इसे खुद आज़माना चाहते हैं, तो MemGPT Discord server के Discord bot(https://discord.gg/9GEQrxmVyE) में memory editing को काम करते देख सकते हैं। bot से बात करने पर दिखेगा कि MemGPT user और अपने बारे में profiles update करने के लिए memory को कैसे modify करता है
    सब कुछ open source है, इसलिए https://github.com/cpacker/MemGPT code से इसे local पर भी चला सकते हैं। repository में LlamaIndex API docs के बारे में MemGPT से बातचीत करने वाला docs-focused example भी है

  • सोच रहा हूँ कि सब कुछ एक ही context window के अंदर क्यों handle किया जा रहा है। कुछ महीने पहले जब मैंने ऐसा ही कुछ experiment किया था, तो preprocessing/postprocessing stage में कई agents के साथ parallelize किया था
    उदाहरण के लिए, main context window को यह पता नहीं था कि memory बनाई जा रही है या search की जा रही है; postprocessor अपने-आप conversation से memories बनाकर store करता था, और पूरी conversation भी vector database में store होती थी। preprocessor conversation के हिसाब से relevant memories और context को automatic inject करता था, यहाँ तक कि history को फिर से लिखकर main context window के नजरिए से ऐसा दिखाता था जैसे वह memory शुरू से ही मौजूद थी
    इस तरह main context window में बेकार system prompts वगैरह पर खर्च होने वाली काफी जगह बच जाती थी

    • अच्छे points हैं। chatbot context में memory management किसे सौंपना है, यह design choice है, और मुझे लगता है कि मोटे तौर पर दो तरीके हैं: implicit memory management और explicit memory management
      implicit तरीके में “main LLM”, chat में “conversation thread”, background में हो रहे memory management से अनजान रहता है। यह management “memory LLM”, rule-based script, छोटा neural network वगैरह कर सकते हैं
      explicit तरीका MemGPT वाला है, जहाँ एक LLM सब कुछ handle करता है। multi-session/long-range chat से जुड़ी existing research आम तौर पर अलग memory creation process वाले implicit तरीके का इस्तेमाल करती है, और consumer chatbots के memory stores भी ज़्यादातर implicit होने की संभावना है
      explicit memory management के लिए complex instruction following चाहिए, इसलिए मौजूदा public LLMs में से ज़्यादातर के साथ यह मुश्किल लगता है। हम open models को fine-tune करने जैसे तरीकों से इसे solve करने की दिशा देख रहे हैं
      trade-off वही हैं जो आपने बताए। implicit तरीके में memory management instructions को LLM pre-prompt में पूरा डालना नहीं पड़ता। MemGPT का पूरा system message करीब 1K tokens का है। उल्टा, explicit memory management में जब LLM सही काम करता है, तो पूरा system कहीं ज्यादा simple हो जाता है, क्योंकि parallel threads में कई LLM models manage करने का overhead नहीं रहता
    • दिलचस्प approach है। मैं कुछ ऐसा ही बना रहा हूँ, जिसमें feedback loop के हिस्से के तौर पर transaction data को context window में डालकर history को rewrite किया जाता है
      मेरा मानना है कि LLM और natural language processing structured data के लिए अधिक practical interface बन सकते हैं। किसी specific business context में data generate होने पर data extract किया जाता है, embeddings बनाए जाते हैं और vector database build किया जाता है
      postprocessing में, main model के response देने के बाद postprocessor conversation के आधार पर memories अपने-आप बनाकर store करता है। इससे महत्वपूर्ण context save रहता है, लेकिन main model पर इस काम का बोझ नहीं पड़ता। request के हिस्से के रूप में relevant business logic भी run किया जाता है और फिर system में feedback किया जाता है
      preprocessing में, new input को main model को भेजने से पहले stored memories check की जाती हैं, relevant context inject किया जाता है और logic भी run किया जाता है। preprocessor main model को पिछली conversation की “review” देता है, ताकि वह अधिक consistent और information-rich response के लिए तैयार हो सके
    • multi-agent में काफी potential है। agent responses में कुछ entropy होती है, इसलिए इसे आज़माना और भी worthwhile लगता है

  • limitations में लिखी बात को लेकर: अगर Llama 2 70B variants function calling के लिए fine-tune होने के बावजूद गलत function calls बनाते हैं या दिए गए schema के बाहर के functions hallucinate करते हैं, तो grammar-based sampling इस्तेमाल की जा सकती है
    कम से कम यह guarantee की जा सकती है कि function call syntax के हिसाब से valid हो
    [0] https://github.com/ggerganov/llama.cpp/tree/master/grammars

    • grammar-based sampling अच्छा idea है और MemGPT जैसी चीज़ के लिए बहुत अच्छी तरह fit बैठता है। non-gpt-4 models के साथ MemGPT experiment करते समय performance पर सबसे ज्यादा असर डालने वाली problems function argument misuse और function hallucination थीं
      उदाहरण के लिए, function-calling data पर fine-tuned बड़े model(https://huggingface.co/jondurbin/airoboros-l2-70b-2.1#agentf...) ने भी आम तौर पर parse हो सकने वाला JSON output किया, लेकिन arguments या function names गलत थे
      जैसे data लिखते समय pre-prompt में explicitly बताए गए सही working_context.append call के बजाय, वह पूरी तरह unspecified personal_diary.add call output कर देता था

  • title देखकर लगा था कि यह LLM की neural network memory, यानी context नहीं बल्कि weight-level memory को conversation के दौरान बदलने वाली memory editing technique होगी, जैसे ROME [1] वाला approach
    असल में यह एक शानदार RAG काम है, यह जानकर अच्छा लगा, और जल्द ही मैं MemEditGPT का अपना version बनाऊँगा
    [1] https://arxiv.org/abs/2202.05262

    • अगर contribute करना चाहते हैं, तो repository में issue या PR खोल सकते हैं। सब कुछ open source और Apache 2.0 है, और हम CLI में common workflows को integrate करने पर actively विचार कर रहे हैं
      आपने सही समझा: MemGPT, ROME की तरह LLM weights edit नहीं करता। MemGPT में “memory” weight-level नहीं, बल्कि text/token level पर है
      core idea यह है कि LLM को context के अंदर रखे जाने वाले working memory scratchpad को edit करने और functions के जरिए external context को read/write करने की ability दी जाए। एक महत्वपूर्ण detail यह है कि finite context limit से निपटने के लिए reads हमेशा page-level, यानी chunks में होते हैं
      MemGPT एक single user input में functions को chain करके कई बार repeat करते हुए read और write कर सकता है। इसलिए README के LlamaIndex API docs example की तरह, यह बड़े document database को search कर सकता है और कई sources से information इकट्ठी करके answer return कर सकता है

  • कुछ समय तक मुझे शक था कि ChatGPT का वेब वर्जन (chat.openai.com, API नहीं) बातचीत के अंदर कुछ इसी तरह काम करता है। बहुत लंबी chat history में भी ऐसा लगता था कि वह सब कुछ अचानक भूलने के बजाय धीरे-धीरे quality में गिरावट दिखाता है
    बेशक, हो सकता है context में मेरी सोच से ज्यादा clues मौजूद हों
    वैसे भी, मुझे लगता है कि ऐसी idea आगे चलकर सभी chatbots की basic feature बनने की काफी संभावना है

    • recursive summarization infinite context का भ्रम देने का एक आसान और लोकप्रिय तरीका है। जब space खाली करनी हो, तो सबसे पुराने N messages को compress करके एक summary message बना देना काफी है
      इसमें loss होता है और आखिर में महत्वपूर्ण जानकारी खो जाती है, लेकिन performance अपेक्षाकृत धीरे-धीरे degrade हो सकती है। MemGPT में सभी explicit memory management के ऊपर implicit recursive summarization भी इस्तेमाल होता है
    • उम्मीद से कहीं ज्यादा clues बचे रहते हैं। इसके अलावा context window standard English text के हिसाब से करीब 12 pages की होती है, और system prompt से बहुत ज्यादा जगह भी waste नहीं होती
      अगर आपने थोड़ा भी दिलचस्प काम किया है, तो output prompt की ओर strongly biased होता है। पिछले output/history का सिर्फ एक sample होने के कारण smooth probability distribution के बजाय कुछ information खो जाती है, और कई inputs एक ही output पर map हो सकते हैं, इसलिए कुछ और information खोती है
      लेकिन real-world prompts अक्सर मनचाहा result पाने के लिए दिमाग में आने वाली सबसे आसान और छोटी expression होते हैं। इसलिए अगर LLM उस prompt का अंदाजा लगा ले, तो missing context की उसकी interpretation काफी हद तक सही होने की संभावना होती है। यानी जो बहुत-सी information गायब लगती है, वह LLM output में बनी रहती है, और पुराना context बाहर धकेले जाने पर भी एक बार में खोने वाली information की मात्रा बहुत बड़ी नहीं होती
    • ChatGPT में performance degradation दिखने की वजह यह है कि वह context length से बाहर memory बढ़ाने के लिए कुछ खास नहीं करता
      lossy memory implement करने की कई trivial techniques हैं। उदाहरण के लिए sentence transformers में इस्तेमाल होने वाले तरीके की तरह tokens को average pooling करना। बहुत सारे context को prompt में compress करने के लिए यह तरीका कम क्यों इस्तेमाल होता है, यह मुझे ठीक से पता नहीं। यह असल में medium-term memory की तरह काम करता है
    • closed-source models असल में क्या करते हैं, यह पता नहीं, लेकिन कुछ prompt attacks देखकर लगता है कि इस thread में बताई गई चीजों के अलावा वे recursive summarization भी इस्तेमाल करते हैं
    • मेरे हिसाब से token limit के नीचे रहने के लिए conversation से सबसे पुराने tokens की सिर्फ उतनी न्यूनतम मात्रा काटी जाती है जितनी जरूरी हो। conversation ऐसे degrade नहीं होती जैसे उसके पास medium-term memory हो

  • नाम याद नहीं, लेकिन एक esoteric programming language पहले से है जो commands को unstable तरीके से execute करती है। अगर program को सावधानी से design किया जाए, तो command sequence को 99%, 99.9% जैसी reliability के साथ execute करवाया जा सकता है

    • शायद वह Java2000 होगा
      20 साल बाद वही approach infrastructure field में “chaos engineering” के नाम से बिना किसी irony के popular हो गया
    • Malbolge से थोड़ा मिलता-जुलता है, लेकिन लगता है बिल्कुल वही नहीं है। https://en.m.wikipedia.org/wiki/Malbolge

  • Update: MemGPT के ऊपर implement किया गया Discord persistent chatbot अभी release किया है। इसे यहां try किया जा सकता है: https://discord.gg/9GEQrxmVyE
    GitHub code से chatbot demo और एक docs Q&A bot demo भी local पर चला सकते हैं, जिसमें API documentation के बारे में MemGPT से सवाल पूछे जा सकते हैं

  • मुझे लगता है LLM की सबसे बड़ी limitation context window है। इसकी बेहतरीन reasoning ability भी real use cases में अक्सर context window limit से टकरा जाती है

    • सही है। उम्मीद है कि यहां बताई गई techniques से persistent chatbot design करने की दिशा में सोचा जा सकेगा

  • मैं इस बात से सहमत हूं कि recursive summarization भरी हुई context window को handle करने का simple तरीका है, लेकिन inherently lossy है और आखिर में system memory में बड़े holes बना देता है
    लेकिन MemGPT भी वही काम कर रहा है और उसमें भी वही समस्या है। फर्क बस इतना है कि सब कुछ recursively summarize करने के बजाय यह history को selectively search करके हर request के लिए generate करता है। idea अच्छा है
    लेकिन मुझे संदेह है। यह approach मूल रूप से इस assumption पर निर्भर है कि मौजूदा context low-entropy में summarize किया जा सकने वाला context है, और query history के सिर्फ कुछ हिस्सों पर निर्भर करती है
    chat या “बहुत बड़े document set से सवालों के जवाब देना” जैसे cases में यह सही हो सकता है। लेकिन code generation में, जहां context कुछ specific API definitions जैसी ऐसी information से भरा होता है जिसे छोड़ा नहीं जा सकता, और कई API definitions की तरह wide context की जरूरत होती है, वहां दोनों assumptions गलत हैं
    structure और implementation interesting हैं और demo भी बढ़िया है, लेकिन summary-related papers इस approach की fundamental limitations को स्वीकार नहीं करते, यह बात खलती है

    • paper देखने के लिए धन्यवाद। कोई misunderstanding न हो, इसलिए साफ कर दूं कि recursive summarization MemGPT के memory management का सिर्फ एक हिस्सा है
      जैसा आपने कहा, MemGPT की conversation queue को previous research या कई chatbot implementations की तरह recursive summarization से manage किया जाता है। लेकिन recursive summarization से अलग एक readable/writable “fixed” area वाली LLM memory भी है, जिसे paper में “working context” कहा गया है
      इसलिए MemGPT automatically generated recursive summary और उस working context, दोनों को access कर सकता है जिसे MemGPT actively up-to-date manage करता है
      ये दोनों MemGPT के external context से भी अलग हैं, जिसे function calls के जरिए conversation queue में लाया जाता है। सभी examples में external context reads compress नहीं होते, और बिना summarization के page-by-page होते हैं
      जब queue summarization trigger होती है, तो MemGPT को system notification मिलता है, इसलिए अगर conversation queue की कोई खास detail बनाए रखनी हो, तो वह delete या summarize होने से पहले working context में लिख सकता है
      conversational agent example में working context user और agent के बारे में key facts store करने के लिए इस्तेमाल होता है, ताकि consistent conversation बनी रहे। working context हमेशा LLM को दिखता है, इसलिए अलग से search करने की जरूरत नहीं होती
      document Q&A में working context का इस्तेमाल current task/question और उसकी progress track करने के लिए किया जा सकता है। complex queries में यह MemGPT को previous searches, previous page requests जैसी details follow करने में मदद करता है