Octobrain 0.7.0: आपकी AI की मेमोरी अब सोती है, भूलती है, और फोकस करती है

एक मेमोरी जो सिर्फ़ बढ़ती ही जाती है, वो मेमोरी नहीं होती। वो एक कबाड़ का दराज़ होती है।

अब तक का हर AI मेमोरी टूल जोड़ने वाला रहा है: स्टोर करो, स्टोर करो, स्टोर करो। ढेर बड़ा होता जाता है, आपकी खोजें शोरगुल भरी होती जाती हैं, और जो चीज़ आपको असल में चाहिए वो उन पाँच लगभग-डुप्लिकेट नोट्स के नीचे दबी होती है जो आपने पिछले मंगलवार उसी के बारे में लिखे थे। ज़्यादा यादों का मतलब बेहतर recall होना बंद हो जाता है।

दिमाग ऐसे काम नहीं करता। वो आपके सोते समय यादों को consolidate करता है। वो अनुपयोगी चीज़ों को मिटने देता है। वो उस चीज़ के इर्द-गिर्द संगठित होता है जो आप करने की कोशिश कर रहे थे, न कि उस क्रम में जिसमें चीज़ें हुईं। वह छँटाई मानव मेमोरी में कोई बग नहीं है — वही पूरी वजह है कि recall तेज़ बना रहता है।

0.6.0 इस बारे में था कि Octobrain क्या ढूँढ सकता है — पूर्ण डॉक्यूमेंट पढ़ना, indexed कंटेंट पर grep करना। 0.7.0 इस बारे में है कि Octobrain की मेमोरी तब क्या करती है जब आप देख नहीं रहे होते। वह एक निष्क्रिय लॉग होना बंद कर देती है और एक दिमाग की तरह व्यवहार करने लगती है।

Sleep Consolidation — एक मेमोरी जो ख़ुद को व्यवस्थित करती है

यही मुख्य बात है। Octobrain अब एक "sleep" पास चलाता है जो हाल की, समान यादों के क्लस्टर ढूँढता है और हर क्लस्टर को एक अकेली consolidated अंतर्दृष्टि में समेट देता है।

मान लीजिए एक हफ़्ते में आपके एजेंट ने एक ही rate-limiting बग का पीछा करते हुए पाँच अलग नोट्स स्टोर किए। 0.7.0 से पहले, एक खोज पाँच धुँधले, ओवरलैपिंग हिट लौटाती और रैंकिंग को किस्मत के भरोसे छोड़ देती। एक sleep पास के बाद, वे पाँच एक साफ़, उच्च-confidence अंतर्दृष्टि में सिमट जाते हैं — और मूल नोट्स मिटते नहीं, वे dampen किए जाते हैं और provenance के रूप में रखे जाते हैं, ताकि कच्चे नोट्स तक वापस जाने का रास्ता बचा रहे।

ज़रूरी बात: यह autonomous है। कोई cron job नहीं। कोई ऐसा टूल नहीं जिसे कॉल करना आपके एजेंट को याद रखना पड़े। यह ख़ुद को आलसी तरीके से ट्रिगर करता है — अगली बार जब Octobrain शुरू होता है, अगर पिछले पास के बाद एक दिन बीत चुका है, तो यह चलता है और चुपचाप किनारे हो जाता है। एक धीमा या विफल पास कभी किसी चीज़ को नहीं रोकता।

[memory]
sleep_consolidation_enabled        = true   # opt-out, not opt-in
sleep_consolidation_interval_hours = 24     # once a day
sleep_consolidation_threshold      = 0.85   # how similar memories must be to cluster
sleep_consolidation_min_cluster_size = 3    # need at least 3 to bother
sleep_consolidation_max_age_days   = 7      # only recent memories

अगर आप एक पास को बाध्य करना चाहते हैं — टेस्टिंग के लिए, या किसी बड़े retrieval से ठीक पहले — तो CLI override अभी भी मौजूद है:

octobrain memory sleep-consolidate

पर डिफ़ॉल्ट यह है कि आप इसे कभी नहीं छूते। मेमोरी ख़ुद को साफ़ रखती है।

Half-Life Decay — जान-बूझकर भूलना

Octobrain अब एक forgetting curve लागू करता है। हर मेमोरी का महत्व समय के साथ half-life शेड्यूल पर decay होता है — पर जिस पल आप किसी मेमोरी को एक्सेस करते हैं, वह फिर से मज़बूत हो जाती है। बार-बार recall की जाने वाली यादें मज़बूत रहती हैं; जिन्हें कोई कभी नहीं छूता वे धीरे-धीरे मिट जाती हैं।

यह Ebbinghaus forgetting curve है, सीधे इस बात से उधार ली गई कि मानव मेमोरी कैसे काम करती है। असर यह है कि रैंकिंग अपने आप सुधरती है। आप कुछ भी curate नहीं करते। जिन यादों का आप असल में उपयोग करते हैं वे ऊपर तैरती हैं; जिन्हें आपने एक बार स्टोर किया और फिर कभी ज़रूरत नहीं पड़ी वे नीचे डूब जाती हैं — बिना कभी फेंके गए।

यहाँ दो guardrails मायने रखते हैं:

  • कुछ भी शून्य नहीं किया जाता। एक importance floor है; एक कम-एक्सेस वाली मेमोरी पीछे की ओर मिटती है पर कभी गायब नहीं होती। Decay एक re-ranking संकेत है, delete नहीं।
  • Decay टिकाऊ है। एक्सेस गिनती और last-accessed टाइमस्टैम्प स्टोर किए जाते हैं और restarts के बाद भी बचे रहते हैं। आपकी मेमोरी का "क्या हॉट है" का बोध हर सेशन में रीसेट नहीं होता।
[memory]
decay_enabled       = true
decay_half_life_days = 90   # higher = memories stay relevant longer

आप प्रति मेमोरी decay को ट्यून भी कर सकते हैं — एक तेज़ी से बदलता नोट दोगुनी तेज़ी से मिटने को कहा जा सकता है, एक बुनियादी निर्णय दोगुना धीमा — पर लगभग सभी के लिए डिफ़ॉल्ट बस काम कर जाता है।

Goal-Anchored Consolidation — एक मेमोरी जिसका एक मक़सद है

यहाँ वह विचार है जिसके इर्द-गिर्द agent-memory रिसर्च बार-बार घूमती है: goal पर consolidate करें, clock पर नहीं। यादों को सिर्फ़ इसलिए सारांशित नहीं किया जाना चाहिए कि समय बीत गया — उन्हें उस चीज़ के इर्द-गिर्द सिमटना चाहिए जो आप पूरा करने की कोशिश कर रहे थे।

0.7.0 इसे एक first-class वर्कफ़्लो बनाता है। एक नया Goal मेमोरी प्रकार है और हर मेमोरी के लिए एक असली lifecycle — Working → Consolidated → Archived। जो यादें किसी goal में योगदान देती हैं वे उससे एक achieves संबंध के साथ जुड़ती हैं। जब goal पूरा हो जाता है, आप उसे बंद करते हैं, और Octobrain हर योगदान देने वाली मेमोरी को एक consolidated अंतर्दृष्टि में समेट देता है: महत्व अपने स्रोतों से ऊपर boost किया गया, स्रोत dampen किए गए और उसके नीचे इस रिकॉर्ड के रूप में जोड़े गए कि आप वहाँ कैसे पहुँचे।

# Five scattered findings, one closed goal → one durable insight
octobrain memory consolidate goal_4f2a -s "Shipped rate limiting: token bucket, 429 + Retry-After"

सारांश छोड़ दें और Octobrain उसे स्रोत शीर्षकों से संश्लेषित कर देता है। किसी भी तरह, जो पाँच ढीले नोट्स थे वे एक ऐसी मेमोरी बन जाते हैं जिसका कुछ मतलब है — उस इरादे से जुड़ी जिसने उसे पैदा किया।

और यही वह मशीनरी है जिस पर sleep consolidation अंदर ही अंदर चलता है: हर क्लस्टर को एक synthetic goal मिलता है, और goal पाइपलाइन बाकी काम करती है। एक consolidation इंजन, उसे ट्रिगर करने के दो तरीके — हाथ से जब आप कुछ पूरा करते हैं, अपने-आप जब आप सोते हैं।

Recall और स्मार्ट हुआ — HyDE-lite, डिफ़ॉल्ट रूप से चालू

धुँधली क्वेरी वही जगह हैं जहाँ semantic search आमतौर पर लड़खड़ाता है। "retries के बारे में वो चीज़" उस नोट के आसपास कहीं embed नहीं होती जो आपने असल में लिखा था।

0.7.0 HyDE-lite क्वेरी एक्सपैंशन भेजता है और इसे डिफ़ॉल्ट रूप से चालू कर देता है। तंत्र सरल है: एक first-pass खोज करें, टॉप रिज़ल्ट लें, उन्हें एक centroid में औसत करें, और असली खोज से पहले उसे वापस अपनी मूल क्वेरी में मिला दें। क्वेरी असल में सीख लेती है कि उसके अपने जवाब कैसे दिखते हैं और बेहतर निशाना लगाती है।

व्यवहार में यह long-tail और कम-निर्दिष्ट क्वेरी पर +10–30% recall है — ठीक वही जो इंसान असल में टाइप करते हैं। इसकी लागत प्रति खोज एक अतिरिक्त vector lookup है, इसे किसी LLM की ज़रूरत नहीं (यह शुद्ध गणित है), और remember इसे अपने-आप शामिल करता है। खोज का keyword (BM25) वाला हिस्सा अभी भी आपके literal टेक्स्ट का उपयोग करता है, तो exact-match क्वेरी अप्रभावित रहती हैं।

आप कुछ भी कॉन्फ़िगर नहीं करते। धुँधले सवाल बस ज़्यादा बार सही मेमोरी ढूँढ लेते हैं।

एक हल्की टूल सतह — 8 MCP टूल घटकर 5

हर वह टूल जो आप MCP पर एक्सपोज़ करते हैं, आपके एजेंट का संदर्भ हर एक टर्न पर खर्च करता है — मोटे तौर पर 500–2000 टोकन का schema जो उसे कुछ भी करने से पहले पढ़ना पड़ता है। एक फूली हुई टूल सतह हर अनुरोध पर एक टैक्स है।

तो हमने Octobrain की MCP सतह को आठ टूल से घटाकर पाँच अलग verbs कर दिया:

memorize     store a memory   (now with optional related_to[])
remember     recall           (HyDE expansion + 1-hop neighbors, automatic)
forget       delete           (with confirmation)
consolidate  close a goal     (fold N memories into 1 insight)
knowledge    documents        (index, read, match, search)

तीन टूल MCP से हटे क्योंकि वे अब अपनी schema लागत के लायक नहीं रहे:

  • sleep_consolidate — अब autonomous है, तो एजेंट को इसे कभी कॉल करने की ज़रूरत नहीं।
  • relate — memorize में समेट दिया गया। आप related_to[] पास कर सकते हैं और एक मेमोरी को दूसरों से उसी कॉल में जोड़ सकते हैं जो उसे स्टोर करता है। किसी goal में योगदान देना अब एक round-trip है: finding स्टोर करें और उसे एक साथ goal को achieves मार्क करें।
  • memory_graph — remember पहले ही एक मेमोरी के तत्काल पड़ोसी लौटाता है, जो आम मामला कवर कर लेता है।

इनमें से कोई भी ग़ायब नहीं हुआ — वे सब अभी भी admin और debugging के लिए CLI में रहते हैं। वे बस अब आपके एजेंट का संदर्भ उन फ़ीचर्स के लिए नहीं खा रहे जिनका वह कम ही उपयोग करता है। पाँच टूल, पाँच verbs, कोई ओवरलोडेड mode flags नहीं।

हमने मेमोरी की गुणवत्ता मापना शुरू किया — LongMemEval

जो आप मापते नहीं, उसे आप सुधार नहीं सकते। 0.7.0 एक LongMemEval बेंचमार्किंग हार्नेस जोड़ता है — लंबे रन के लिए checkpointing के साथ — ताकि हम Octobrain के दीर्घकालिक recall को रिलीज़ों के पार vibes के बजाय एक असली बेंचमार्क पर स्कोर कर सकें। यह ऐसी plumbing है जिसे आप कभी नहीं चलाएँगे, पर यही वजह है कि ऊपर के recall और consolidation दावे ऐसे दावे हैं जिन पर हम खड़े रह सकते हैं, और आगे के दावे भी ऐसे ही होंगे।

कवर के नीचे

कुछ शांत बदलाव मेमोरी के बढ़ने के साथ बत्तियाँ जलाए रखते हैं:

  • समय-समय पर LanceDB रखरखाव अपने-आप चलता है ताकि vector store समय के साथ compact और तेज़ बना रहे।
  • Async auto-linking और graph retrieval — संबंधित यादें बैकग्राउंड में जुड़ती हैं, उस write को धीमा किए बिना जिसने उन्हें ट्रिगर किया।
  • एक consolidated SQL मॉड्यूल केंद्रीकृत literal escaping और hardening के साथ — कम तीखे किनारे, क्वेरी के बारे में सोचने के लिए एक ही जगह।

आप इनमें से किसी को सीधे नोटिस नहीं करेंगे। यही तो बात है।

व्यवहार में 0.7.0 कैसा दिखता है

एक मेमोरी के जीवन का एक हफ़्ता, शुरू से अंत तक:

  1. सोमवार। आपका एजेंट एक झिलमिलाते webhook को debug करते हुए तीन नोट्स स्टोर करता है — हर एक memorize के ज़रिए, उनमें से एक को उसी कॉल में "fix webhook retries" goal को achieves मार्क किया गया।
  2. पूरे हफ़्ते। आप इसके बारे में पूछते रहते हैं। हर remember उन यादों को मज़बूत करता है जिन्हें आप छूते हैं और चुपचाप उन्हें मिटाता है जिन्हें आप नहीं छूते।
  3. शुक्रवार। आप फ़िक्स शिप करते हैं और goal को consolidate करते हैं। तीन नोट्स एक टिकाऊ अंतर्दृष्टि बन जाते हैं: "Webhook retries: exponential backoff, idempotency keys, dead-letter after 5."
  4. रातभर। Sleep consolidation उन लगभग-डुप्लिकेट अवलोकनों को बटोर लेता है जिन्हें आपने कभी स्पष्ट रूप से लिंक नहीं किया, और उन्हें भी समेट देता है।
  5. अगले महीने। कोई पूछता है "हमने webhook failures को कैसे संभाला था?" — एक धुँधली क्वेरी जिसे HyDE विस्तृत कर देता है, और जो पाँच आधी-याद किए गए टुकड़ों के बजाय consolidated अंतर्दृष्टि पर जा टिकती है।

किसी ने कुछ भी curate नहीं किया। मेमोरी ने ख़ुद को संगठित कर लिया।

अपग्रेड करना

0.6.x से, migration छोटा है:

Config — एक rename। अगर आपका [embedding] सेक्शन text_model सेट करता है, उसे model में rename करें। यही एकमात्र breaking config बदलाव है।

[embedding]
model = "fastembed:nomic-ai/nomic-embed-text-v1.5"   # was: text_model

MCP क्लाइंट — तीन टूल CLI-only में चले गए। अगर आपका क्लाइंट कॉन्फिग या एजेंट प्रॉम्प्ट sleep_consolidate, relate, या memory_graph को MCP पर कॉल करते हैं, उन्हें अपडेट करें:

  • sleep_consolidate कॉल पूरी तरह हटा दें — यह अब autonomous है।
  • relate को memorize के related_to[] से बदलें ताकि आप स्टोर करते समय लिंक करें (या मौजूदा-से-मौजूदा लिंक के लिए CLI में octobrain memory relate का उपयोग करें)।
  • memory_graph का आम मामला remember के neighbor रिज़ल्ट से कवर हो जाता है; गहरा traversal octobrain memory graph में रहता है।
  • consolidate_goal का नाम बदलकर consolidate कर दिया गया है — वही schema, साफ़ verb।

स्टोरेज — कुछ करने की ज़रूरत नहीं। नए lifecycle और access-tracking कॉलम पहले रन पर जोड़े जाते हैं, और legacy यादें डिफ़ॉल्ट रूप से पूरी तरह active रहती हैं। कोई मैन्युअल migration नहीं, कोई downtime नहीं।

डिफ़ॉल्ट — sleep consolidation और HyDE अब चालू हैं। अगर आप पुराना व्यवहार चाहते हैं, sleep_consolidation_enabled = false या [search.hyde] enabled = false सेट करें। ज़्यादातर लोगों को इन्हें चालू ही रहने देना चाहिए।

स्रोत और बाइनरी github.com/muvon/octobrain पर। अगर कुछ टूटे, issue खोलें — हम पढ़ते हैं।