डेव्हलपरची “dreaming” पाइपलाइन दिवसातून दोनदा चालते, जी LLM-agent चा कच्चा (raw) इव्हेंट लॉग एका संक्षिप्त, पडताळलेल्या (vetted) मेमरी स्टोअरमध्ये रूपांतरित करते आणि टोकनचा खर्च लक्षणीयरीत्या कमी करते. ही पद्धत महत्त्वाची आहे कारण बहुतेक एजंट सिस्टम्स त्यांच्या वर्किंग मेमरीमध्ये दिसणारा प्रत्येक तपशील भरत जातात, ज्यामुळे लवकरच विसंगती (contradictions), विसरलेला संदर्भ (forgotten context) आणि वाढता API खर्च यांसारख्या समस्या निर्माण होतात.

LLM एजंट्ससाठी मेमरी का महत्त्वाची आहे

LLM एजंट्स प्रत्येक युजर रिक्वेस्ट, टूल कॉल किंवा अंतर्गत निरीक्षण (internal observation) याला एक नवीन “इव्हेंट” मानतात. साधी पद्धत प्रत्येक इव्हेंट पुढच्या निर्णयासाठी प्रॉम्प्टमध्ये जोडत जाते. प्रत्यक्षात, यामुळे प्रॉम्प्टमध्ये अनावश्यक माहितीचा (noise) ढिगारा साचतो, मॉडेलला जुनी तथ्ये (stale facts) पुन्हा तपासण्यास भाग पाडले जाते आणि टोकनचा वापर उच्च किंमतीच्या टियरमध्ये ढकलला जातो. परिणामी: अधिक त्रुटी आणि प्रत्येक इंटरॅक्शनसोबत वाढत जाणारा छुपा खर्च.

नाईटली "dreaming" प्रक्रिया कशी काम करते

ही सिस्टम write path (एजंटचा लाईव्ह लॉग) आणि work path (मॉडेलची निर्णय घेण्याची प्रक्रिया) वेगळे करते. दिवसातून दोनदा, “dream” असे नाव दिलेला एक बॅकग्राउंड जॉब साठवलेल्या इव्हेंटवर तीन टप्प्यांत प्रक्रिया करतो:

  • Reflect – एक LLM संबंधित इव्हेंटच्या क्लस्टर्सचे स्कॅनिंग करते, संक्षिप्त तथ्ये सुचवते आणि कोणत्या इव्हेंटमुळे ती तथ्ये सुचली आहेत ते नोंदवते.
  • Score – पाइपलाइन तपासते की एखाद्या तथ्याला पुरेसे समर्थन देणारे इव्हेंट आहेत का आणि ते इव्हेंट वेळेच्या दृष्टीने विश्वसनीय आहेत की नाही.
  • Judge – दोन सॅनिटी चेक (sanity checks) हे सुनिश्चित करतात की नवीन तथ्य कोणत्याही अस्तित्वात असलेल्या मेमरीशी विसंगत नाही आणि ते डुप्लिकेट नाही.

सर्व तपासण्यांमधून उत्तीर्ण झालेली तथ्ये permanent memory मध्ये समाविष्ट केली जातात. जी तथ्ये निकषांवर उतरत नाहीत, ती review queue मध्ये जातात, जिथे एक मानवी ऑपरेटर केवळ एका कीस्ट्रोकने त्यांना मंजूर किंवा नाकारू शकतो. प्रत्येक मंजुरीमुळे एक git-style commit तयार होतो, ज्यामुळे कोणती मेमरी कधी बदलली याचा पूर्ण ऑडिट ट्रेल (audit trail) उपलब्ध होतो.

मुख्य इंजिनिअरिंग निष्कर्ष (Key engineering takeaways)

  • Separate write from work. एजंट्सना प्रत्येक निरीक्षण लॉगमध्ये टाकू द्या; काय राखावे हे ठरवण्यासाठी एक समर्पित प्रक्रिया वापरा.
  • Focus on refusal, not generation. नवीन कल्पना निर्माण करणे स्वस्त आहे; परंतु मेमरी प्रदूषण (memory pollution) रोखणे हे कठीण काम आहे.
  • Human gates at the cheapest checkpoint. ऑटो-ड्राफ्टिंग आणि त्यानंतर त्वरित मॅन्युअल मंजुरी घेणे, हे पूर्ण स्वायत्ततेपेक्षा खर्च आणि सुरक्षिततेच्या दृष्टीने अधिक फायदेशीर ठरते.
  • Cap token spend per cycle. प्रत्येक dreaming रनसाठी टोकनची एक कडक मर्यादा ठेवल्यास खर्च नियंत्रणात राहतो.
  • Audit for silent failures. जर एखादा टप्पा पुढच्या टप्प्यापेक्षा वेगळे नियम लागू करत असेल, तर डेटा नकळत गायब होऊ शकतो; स्पष्ट तपासणी (explicit checks) अशा विसंगती पकडू शकतात.

संभाव्य तोटे

ही प्रक्रिया ऑफलाइन चालवल्यामुळे विलंब (lag) निर्माण होतो: एजंटला पुढील 'dream' सायकलपर्यंत नवीन पडताळलेली तथ्ये दिसणार नाहीत. वेगाने बदलणाऱ्या ॲप्लिकेशन्समध्ये, ज्यांना त्वरित शिकण्याची गरज असते, तिथे हा विलंब एक अडथळा ठरू शकतो. ही सिस्टम एकाच मानवी रिव्ह्यूअरवर अवलंबून आहे; मजुरीचा खर्च न वाढवता रिव्ह्यू क्यू स्केल करणे हे अजूनही एक आव्हान आहे.

पुढे काय पाहावे

LLM एजंट्ससोबत प्रयोग करणाऱ्या डेव्हलपर्सनी टोकन बिल आणि एरर लॉग्सवर लक्ष ठेवावे, जेणेकरून “memory pollution” ची चिन्हे ओळखता येतील – म्हणजे अशा वारंवार येणाऱ्या किंवा विसंगत विधानांचा मागोवा घेणे जे कच्च्या इव्हेंट संचयनामुळे निर्माण झाले आहेत. 'dreaming' पाइपलाइन जोडल्यामुळे खर्च कमी करण्यासाठी एक ठोस नियंत्रण मिळते आणि सोबतच एक ऑडिट करण्यायोग्य मेमरी इतिहास देखील प्राप्त होतो. जसजशा अधिक टीम्स 'split-log' मॉडेलचा अवलंब करतील, तसतसे reflect-score-judge स्टेप्स ऑटोमेट करणारी आणि व्हर्जन-कंट्रोल-स्टाईल रिव्ह्यूशी जोडली जाणारी टूल्स उपलब्ध होतील, ज्यामुळे ही पद्धत अधिक सोपी आणि 'plug-and-play' होईल. तात्काळ उपलब्धता आणि मेमरीची स्वच्छता (immediacy and cleanliness) यांच्यातील तडजोड ही 'nightly dream' प्रक्रिया LLM-agent आर्किटेक्चरचा एक मानक भाग म्हणून किती व्यापकपणे स्वीकारली जाईल, हे ठरवेल.