रिकर्सिव सारांश से LLM की दीर्घकालिक संवाद मेमोरी लागू करना

 (arxiv.org)
1 पॉइंट द्वारा GN⁺ 2023-09-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • दीर्घकालिक संवादात्मक chatbot में, लंबी context window होने पर भी पिछली interactions के मुख्य बिंदुओं को उत्तरों में स्थिर रूप से शामिल करना कठिन होता है, और यह शोध रिकर्सिव सारांश मेमोरी के जरिए consistency समस्या को कम करने की विधि पर चर्चा करता है
  • मुख्य प्रक्रिया यह है कि छोटी बातचीत से प्रारंभिक मेमोरी बनाई जाती है, फिर हर नए session के जुड़ने पर पिछली मेमोरी और नई बातचीत को साथ में सारांशित करके उसे नवीनतम मेमोरी के रूप में अपडेट किया जाता है
  • retrieval-आधारित तरीका इस बात पर निर्भर करता है कि retriever ज़रूरी पुरानी utterances को कितनी सटीकता से ढूंढ पाता है, और मौजूदा memory-आधारित तरीकों में अपडेट न हुई पुरानी जानकारी उत्तर की गुणवत्ता को प्रभावित कर सकती है
  • Llama, ChatGLM, OpenAI GPT-3.5-Turbo जैसे सार्वजनिक और निजी LLM पर किए गए प्रयोगों में, स्वचालित और मानव मूल्यांकन दोनों में, मौजूदा तरीकों की तुलना में दीर्घकालिक संवाद consistency अधिक पाई गई
  • यह तरीका लंबी context window या retrieval-augmented LLM के साथ भी इस्तेमाल किया जा सकता है, इसलिए पूरी बातचीत की लंबाई को अंधाधुंध बढ़ाए बिना बहुत लंबे संवाद संदर्भ को संभालने का एक व्यावहारिक विकल्प बन सकता है

सिर्फ लंबा context दीर्घकालिक संवाद स्मृति के लिए पर्याप्त नहीं

  • GPT-4, ChatGPT जैसे LLM विभिन्न विषयों पर dynamic और context-उपयुक्त बातचीत कर सकते हैं, लेकिन दीर्घकालिक संवाद में वे पुरानी जानकारी छूट जाने के कारण असंगत उत्तर दे सकते हैं
  • लंबी context window पूरी बातचीत का इतिहास input के रूप में लेने देती है, फिर भी पुरानी interactions को समझकर मुख्य जानकारी को उत्तर में एकीकृत करने की क्षमता अभी भी सीमित है
  • पिछली बातचीत की स्मृति की ज़रूरत वाले प्रतिनिधि उदाहरण personal AI companion और health support services हैं
    • personal AI companion को संबंध बनाने के लिए पिछली बातचीत याद रखनी होती है
    • health support service को diagnosis परिणाम देने के लिए मरीज की पूरी query history पर विचार करना होता है
  • Multi-Session Chat Dataset के उदाहरण में, लगभग 20 turns बाद जब उपयोगकर्ता ने अतीत के “composition” विषय का फिर उल्लेख किया, तो ChatGPT gpt-turbo-3.5-0301 संस्करण ने अपने बारे में “पारंपरिक अर्थ में कोई पेशा न रखने वाला AI language model” कहा, जिससे उसके पिछले persona से असंगत उत्तर उत्पन्न हुआ

retrieval-आधारित और memory-आधारित approaches की सीमाएँ

  • दीर्घकालिक संवाद क्षमता बढ़ाने के दो प्रमुख approaches हैं: retrieval-आधारित तरीका और memory-आधारित तरीका
  • retrieval-आधारित तरीका पुरानी utterances को repository में रखता है, फिर वर्तमान संवाद से सबसे संबंधित history को retriever के जरिए खोजकर response generation में उपयोग करता है
    • इसकी सीमा यह है कि वर्तमान संवाद के लिए आवश्यक अर्थ को पूरी तरह पकड़ने वाला आदर्श retriever पाना कठिन है
  • memory-आधारित तरीका अलग training model या शक्तिशाली LLM की मदद से पुरानी बातचीत का सारांश बनाकर मुख्य जानकारी संग्रहीत करता है
    • यदि बार-बार अपडेट करने की व्यवस्था कमज़ोर हो, तो संचित पुरानी जानकारी सीधे उत्तर की गुणवत्ता को नुकसान पहुँचा सकती है
  • MemoChat वक्ता के topic के अनुसार पुराने संवाद इतिहास का पुनर्गठन करता है, और generation के समय structured memory से retrieval करने के लिए LLM को prompt करता है
  • MemoryBank हर संवाद session का पहले सारांश बनाता है, फिर उसे global summary में संपीड़ित करने वाली memory mechanism का प्रस्ताव देता है
    • यदि संग्रहीत memory पूरी तरह स्थिर हो जाए, तो चल रहे संवाद के साथ consistency सुनिश्चित करना कठिन हो जाता है

रिकर्सिव रूप से अपडेट होने वाली मेमोरी का निर्माण

  • प्रस्तावित तरीका एक सरल plugin approach है, जिसमें LLM खुद सारांश बनाता है और पुराने context को लगातार अपडेट व पुनरावलोकन करके वक्ता की real-time जानकारी संग्रहीत करता है
  • प्रक्रिया तीन चरणों में बनी है
    • generative LLM छोटे संवाद context को input लेकर प्रारंभिक summary बनाता है
    • उसके बाद पिछली memory और आगे की बातचीत को जोड़कर नई summary या memory को लगातार अपडेट करता है
    • chatbot वर्तमान संवाद का उत्तर देने के लिए नवीनतम memory को मुख्य संदर्भ के रूप में उपयोग करता है
  • चूँकि बना हुआ summary पूरी बातचीत से बहुत छोटा होता है, इसलिए अधिकतम input length को महँगा बनाए बिना कई sessions तक फैले बहुत लंबे context को संभाला जा सकता है
  • दीर्घकालिक संवाद को कई sessions से बने Multi-Session Dialogue के रूप में परिभाषित किया गया है
    • इसमें पिछले sessions के समूह S = {S1, S2, ..., SN}, वर्तमान session का dialogue context Ct, और सही उत्तर rt का उपयोग होता है
    • लक्ष्य यह है कि पिछले sessions और वर्तमान context के आधार पर प्रासंगिक और उच्च-consistency वाला उत्तर बनाया जाए
  • memory Mi वह memory है जो iवें session के अंत में उपलब्ध होती है, और पूरी प्रक्रिया को एक क्रमिक प्रक्रिया के रूप में परिभाषित किया गया है जिसमें हर memory केवल वर्तमान session और पिछली memory पर निर्भर करती है

मेमोरी iteration और response generation

  • प्रस्तावित तरीका किसी भी LLM को दो काम सौंपता है
    • memory iteration: दीर्घकालिक संवाद प्रवाह के अनुसार मुख्य जानकारी को रिकर्सिव रूप से सारांशित करना
    • memory-आधारित response generation: नवीनतम memory और वर्तमान संवाद को मिलाकर उपयुक्त और सुसंगत उत्तर बनाना
  • memory iteration वह प्रक्रिया है जिससे chatbot उपयोग के लिए सुसंगत और अद्यतन summary प्राप्त करता है
  • कुछ पुराने शोध memory अपडेट करने के लिए summary पर replace, append, delete जैसी “hard operations” लागू करते हैं
    • ऐसे तरीके operation labels लगे high-quality dialogues पर निर्भर करते हैं, summary की semantic consistency में बाधा डालते हैं, और दीर्घकालिक प्रबंधन के लिए उपयुक्त नहीं हैं
  • प्रस्तावित तरीका dialogue context और पिछली memory को साथ में देकर LLM से memory या summary को रिकर्सिव रूप से generate कराता है
    • पिछली summary का उपयोग करने से model वर्तमान dialogue context को बेहतर ढंग से समझ सकता है और उच्च-गुणवत्ता वाली memory बना सकता है
  • उदाहरण में, पहले session के बाद प्रारंभिक memory बनाई जाती है, और दूसरे session के बाद पिछली memory में “बॉट ने हाल ही में 24 घंटे चलने वाले नए gym में join किया” जैसी नई व्यक्तित्व जानकारी एकीकृत कर दी जाती है

प्रयोग परिणाम और उपयोग की संभावना

  • प्रयोग Llama, ChatGLM, OpenAI GPT-3.5-Turbo जैसे आधुनिक सार्वजनिक और निजी LLM पर किए गए
  • दीर्घकालिक संवाद प्रदर्शन स्वचालित और मानव मूल्यांकन दोनों में मौजूदा लोकप्रिय approaches से बेहतर पाया गया
  • इससे दीर्घकालिक संवाद में explicit memory उपयोग की प्रभावशीलता और यह तथ्य सत्यापित हुआ कि प्रस्तावित तरीके से बनी memory को LLM अधिक आसानी से प्रोसेस कर सकता है
  • in-context learning (ICL) को जोड़ने पर response quality और बेहतर हो सकती है
    • (dialogue, memory, correct response) फ़ॉर्मेट के कई samples LLM को दिखाए जाते हैं
    • इससे LLM generated memory का अधिक लचीले ढंग से उपयोग कर पाता है
  • text-davinci-003 में BLEU score लगभग +3% बेहतर हुआ
  • प्रस्तावित तरीका GPT-3.5-Turbo-16k, LongLoRA-8k जैसी लंबी context window वाले LLM और LLM-BM25, LLM-DPR जैसे retrieval-augmented LLM को पूरक करता है
  • सार्वजनिक code qingyue2014/Rsum पर उपलब्ध है

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

1 टिप्पणियां

 
GN⁺ 2023-09-04
Hacker News की राय

  • “टेक्स्ट स्पेस” में memory जमा करने का हर तरीका काफ़ी hacky लगता है
    मॉडल के अर्थ को पूरी तरह सुरक्षित रखने के लिए, बार-बार summary दोबारा बनाने वाली पैबंद जैसी प्रक्रिया की बजाय dense embedding space में स्टोर करना ज़्यादा स्वाभाविक लगता है
    साथ ही मॉडल को memory को पहचानने और इस्तेमाल करने के तरीके से train किया जाना चाहिए, और मुमकिन हो तो शुरुआत से ही ऐसे setup में सीखना बेहतर होगा

    • hacky तो लगता है, लेकिन देखा जाए तो conversational LLM की अवधारणा खुद भी ऐसी ही है
      आखिरकार उससे दिए गए conversation में अगला word जोड़ने को कहा जाता है, और किसी बिंदु पर वह termination token निकालता है तो application फिर control user को लौटा देती है
      मुझे लगता है latent space और text space उतने दूर नहीं हैं जितना लगता है। LLM काफ़ी भोले हैं, लेकिन बोलने में बहुत सक्षम हैं; code लिखना भी कुछ वैसा ही है इसलिए वे उसमें अच्छे हैं, लेकिन math जैसे क्षेत्रों में जहाँ असल abstract thinking चाहिए, वे टूट जाते हैं
      ऐसे text space hacks असल में अच्छे से काम करते हैं, और “step by step सोचो” जैसे prompts आम होने की वजह भी यही है
      LoRA बताई गई दिशा के ज़्यादा करीब है, और बहुत कम data में बहुत सारी understanding compress करने में शानदार है। लेकिन किसी single conversation के लिए weights adjust करना अभी practical नहीं है, इसलिए उस use case के लिए text space explore किया जा रहा है
    • इसे ऐसे सोचें कि आप अपने दिमाग में यह तरीका इस्तेमाल कर रहे हैं। अब तक की discussion को recursively summarize करने से memory बेहतर हो सकती है
      दिमाग में किसी चीज़ को summarize करना “hacky” लग सकता है, लेकिन मुझे लगता है असल memory के काम करने के तरीके का बड़ा हिस्सा कुछ ऐसा ही है
    • दिलचस्प बात यह है कि लगातार summaries regenerate करने का तरीका human brain, कम-से-कम long-term memory के काम करने के माने जाने वाले तरीके से बहुत अलग नहीं है
      https://news.northwestern.edu/stories/2012/09/your-memory-is...
    • आज हम जो computing इस्तेमाल करते हैं, उसका लगभग सब कुछ भी पर्याप्त abstraction और error handling जुड़ जाने के कारण hack जैसा नहीं दिखता, लेकिन मूल रूप से वह अक्सर hacky constructions ही होता है
    • मुझे जानना है कि dense embedding space से complete meaning preservation हो सकता है, ऐसा intuition क्यों आता है
      मेरी समझ में embeddings मूलतः lossy compression के करीब हैं। text summary हो तो कम-से-कम agent verify कर सकता है कि summary original information को सही तरह represent करती है या नहीं

  • CodeRabbit में हम incremental PR review और code changes के context में conversations के लिए पहले से ही यह तरीका इस्तेमाल कर रहे हैं
    यह bot को असलियत से कहीं ज़्यादा context वाला दिखाता है, और बड़े PRs (100+ files) तक AI code review scale करने के लिए इस्तेमाल की जाने वाली कई tricks में से एक है
    हर commit पर file-wise diff summarize किया जाता है, फिर उन summaries की summary बनाई जाती है, और PR में commits जुड़ने पर उसे incrementally update किया जाता है। summaries की यह summary PR comment के अंदर छिपाकर store की जाती है, और हर file review करते समय या user questions का जवाब देते समय इस्तेमाल होती है
    कुछ code open source है, और recursive summarization में इस्तेमाल होने वाला संबंधित prompt यहाँ है: https://github.com/coderabbitai/ai-pr-reviewer/blob/main/src...
    [0]: coderabbit.ai

    • मुझे जानना है कि prompt result parse करते समय problems आती हैं या नहीं
      अगर आती हैं, तो क्या आपने free text output parse करने के बजाय function calling इस्तेमाल करके देखा है

  • अगर stage “code और scripts बाद में release होंगे” वाला है, तो अब किसी भी claim पर भरोसा करना मुश्किल है
    यह सच भी हो सकता है और बकवास भी, लेकिन अगर experiment को कम cost में reproduce करने का तरीका नहीं है, तो मैं ऐसे papers को authors के resume में डालने के लिए लिखा हुआ मानता हूँ
    LLM field में “code बाद में release होगा” वाले papers का 6 महीने से ज़्यादा इंतज़ार किया है, लेकिन सच में release होने का कोई संकेत नहीं है। यहाँ तक कि कुछ papers तो parked domains पर जाने वाले broken links डालने जितने बेशर्म हैं
    अब समय आ गया है कि community इस unreleased code practice को ठीक से पहचाने

    • सही। यह बहुत simple idea है जिसमें ज़्यादा code की ज़रूरत नहीं होनी चाहिए, इसलिए इसे साफ़ करके release करना मुश्किल नहीं होना चाहिए
      पहले मैंने API dashboard में सिर्फ prompts खुद tweak करके इसी तरह के idea पर experiment किया था; संभावना तो दिखी, लेकिन API cost जितनी value लगती नहीं थी। शायद vector embedding approach कहीं बेहतर हो

  • एक personal case में, हमारी company के पास “Briefings” नाम के हजारों offline panels हैं, जो एक घंटे के, कभी-कभी पूरे दिन चलने वाले होते हैं
    हमने हर briefing को successfully summarize किया, और messy transcripts अच्छी तरह पाँच-paragraph summary में व्यवस्थित हो गए
    ज़्यादा relevant हिस्सा यह है कि हमने हर briefing को topics और subtopics में 1:N classify किया। topics में दर्जनों briefings और subtopics में करीब दर्जन भर briefings grouped थे, और related summaries के subsets को फिर से summarize करके व्यापक testing की गई, जिसमें LLM से बहुत अच्छे results मिले
    शुरुआत में मुझे शक था कि यह काम करेगा या नहीं, लेकिन यह बहुत अच्छी तरह काम किया। अगर context window काफ़ी बड़ी होती तो हम ऐसा नहीं करते, लेकिन सौभाग्य से यह problem नहीं बना

    • context window बड़ी हो तब भी यह technique useful है
      समस्या को MapReduce की तरह तोड़ना, सब कुछ 32k की विशाल context window में ठूंसकर एक बार में solve कराने से कहीं बेहतर काम करता है

  • कुछ महीने पहले open source model से recursive summary memory बनाकर देखी थी, लेकिन अगर इसे भोले तरीके से implement करें तो यह अक्सर किसी खास विषय में हमेशा के लिए फंस जाती थी
    क्योंकि कुछ टुकड़े हर summary round में बचे रह जाते हैं

    • सही है। अगर amplification को काफी कम न किया जाए, तो known material के लिए chunk size को हाथ से adjust करने पर भी context जिस तरह “मरते हुए विचार” को पकड़े रहता है, वह हैरान करने वाली हद तक Alzheimer’s जैसा दिखता है
    • इतना ही नहीं, यह साबित किया जा सकता है कि यह approach scale नहीं करती
      किसी भी text block को छोटे text block में घटाते हुए जानकारी का एक भी हिस्सा न खोना असंभव है
      अगर ऐसा संभव हो, तो इसका मतलब infinite compression संभव है, और किसी भी dataset को 1 bit में घटाकर फिर पूरी तरह restore किया जा सकना चाहिए। लेकिन ऐसा नहीं हो सकता
      बातचीत को summary में compress करने पर कुछ जानकारी जरूर गायब होगी। कितनी भी tuning, folding या smart तरीके अपना लें, मूल रूप से information loss होगा ही
      ऊपर से यह process recursive है, इसलिए किसी समय summaries के bundle को फिर से summarize करना पड़ेगा, और तब भी कुछ हद तक जानकारी खोएगी
      इसलिए मामूली cases में यह मदद कर सकती है, लेकिन recursive summary को prompt में डालना काफी मूर्खतापूर्ण लगता है और अगर इससे सच में उपयोगी काम करवाया जाए तो यह लगभग निश्चित रूप से ठीक से काम नहीं करेगी। जब recursive summary ज्यादा इस्तेमाल नहीं होती, तब कम जानकारी खोती है इसलिए यह काम करती हुई लगती है, लेकिन असल इस्तेमाल में इसकी सीमाएं जल्दी सामने आ जाने की संभावना ज्यादा है
    • “खराब hallucination experience” या compulsive patterns याद आते हैं
      trauma या development process भर से भी इंसानी मन कितनी आसानी से पटरी से उतर जाता है, यह सोचें तो human-like AI का विचार कितना उम्मीदों से भरा हुआ है, यह महसूस होता है
    • जो असंबंधित लगे उसे भूलने, यानी summary में skip करने का निर्देश दे सकते हैं

  • paper थोड़ा निराशाजनक है। technique के details लगभग हैं ही नहीं, बस एक table है कि उनकी इस्तेमाल की हुई methodology से अच्छे results आते हैं
    मुझे पता है कि आजकल science में यह आम है, लेकिन LLMs के साथ काम करने वाले developer के नजरिए से paper की value लगभग नहीं है। हां, authors की academic reputation थोड़ी बढ़ जाएगी, और लगता है शायद यही मकसद रहा होगा

    • आखिरी page देखें तो prompt है
    • यह भी लिखा है, “code और scripts बाद में release करेंगे”
      सोच रहा हूं कि इस तरह के कुछ papers साथ में लिखकर देखूं। पता नहीं कितने papers लिखने होंगे ताकि resume के सबसे ऊपर “ML researcher” title लगा सकूं
    • ऐसा लगता है जैसे एक simple topic को scientific paper के format में डालकर उसे कहीं ज्यादा complex बना दिया गया हो
      examples और prompts पर कहीं ज्यादा समय लगाना चाहिए था

  • कुछ हफ्ते पहले भी मैंने मिलता-जुलता लिखा था, लेकिन लोग summary वाले हिस्से को जरूरत से ज्यादा simplify कर रहे हैं: https://news.ycombinator.com/item?id=37117515
    long-term memory की value हर use case में थोड़ी अलग होती है
    अगर आप home assistant बना रहे हैं, तो NER से नाम identify करने होंगे, समझना होगा कि उस व्यक्ति को message भेजते समय कैसी tone पसंद है, और places व modes of travel को समझना होगा
    अगर आप customer support bot बना रहे हैं, तो उन queries को identify करना होगा जो लंबी बातचीत में बदल गईं या अचानक cart abandonment तक पहुंचीं
    सिर्फ generic summary level से भी चमकदार demo बन सकता है, लेकिन अभी सच में useful product बनाना है तो एक कदम आगे जाना होगा

  • यहां नया क्या है, यह मुझे ठीक से समझ नहीं आ रहा
    LLM-based chat history memory summarization पहले से कई LLM frameworks में implemented एक well-known technique है। paper की तरह हर message पर summarize करें तो यह बड़ा performance bottleneck बनता है और chat loop में काफी latency जोड़ता है
    कई implementations fixed-size buffer इस्तेमाल करती हैं और buffer से बाहर धकेले गए पुराने memory chunks को incremental तरीके से summarize करती हैं। ideally यह काम भी chat loop के बाहर handle होना चाहिए
    मैं open source long-term memory store Zep के authors में से एक हूं, और हमने summarization इसी तरीके से implement किया है
    0: https://github.com/getzep/zep

    • Aider भी last N से पुराने messages को background thread में summarize करके ऐसा ही करता है
      https://github.com/paul-gauthier/aider/blob/main/aider/histo...
    • मैं भी काफी beginner हूं, लेकिन मैंने Andrew Ng का LangChain पर एक घंटे का lecture देखा था, और उसमें recursive summarization को standard memory management technique के रूप में cover किया गया था
      https://www.deeplearning.ai/short-courses/langchain-for-llm-...
    • सही है। इसमें नया कुछ भी नहीं है। middle school का ChatGPT user भी यह जानता होगा

  • article या discussion से थोड़ा हटकर बात है, लेकिन short memory सच में एक limitation है
    हालांकि GPT-4 की capabilities पर ज्यादातर criticism इंसानों पर भी उतना ही, या उससे ज्यादा, लागू होता है
    reverse Turing test की स्थिति में कोई जीवित इंसान मुझे यह विश्वास दिला पाएगा कि वह GPT-4 है, ऐसा नहीं लगता। GPT-4 के तेज और व्यवस्थित जवाब भर ही इंसानी क्षमता से आगे निकल जाते हैं
    यहां तक कि अगर इंसानों की team हर सवाल का जवाब देने के लिए 60 मिनट भी ले सके, तब भी interesting queries पर GPT-4 के responses की बराबरी करना मुश्किल हो सकता है। यह एक दिलचस्प competition होगा

  • paper का implementation असल में memory text को prompt के एक हिस्से के रूप में जोड़ने वाला तरीका है
    मैं सोच रहा हूं कि context window tokens का इस्तेमाल न करने वाला storage-and-retrieval system क्यों नहीं इस्तेमाल करते। उदाहरण के लिए, store करते समय यानी user prompt आने पर data को tags से automatically classify किया जा सकता है, और retrieve करते समय LLM response देने से पहले अनुमानित tags से filter करने वाली query चला सकता है
    hardcoded tag names या style जैसे कुछ initial rules भर हों तो भी काफी अच्छे results आ सकते हैं, ऐसा मेरा intuition है