जिस हफ़्ते हमने अपने एजेंट को एक असली दीर्घकालिक मेमोरी दी, रिकॉल बदतर हो गया।

तुरंत नहीं। पहला दिन जादुई था — एजेंट ने सोमवार के सत्र की एक डिप्लॉय की बारीकी बुधवार को याद रखी, बिना दोबारा समझाए। दूसरे हफ़्ते के अंत तक वह "हम रेट-लिमिटिंग कैसे संभालते हैं" के लिए पाँच लगभग एक जैसे नोट लौटा रहा था, हर एक थोड़ा-थोड़ा ग़लत, और कोई भी वह नहीं जो मुझे सचमुच चाहिए था। एजेंट हर अवलोकन, हर बंद गली, हर अधबनी अटकल पर लगन से memorize बुला रहा था। उसने अपने लिए एक कबाड़ का दराज़ बना लिया था और अब हर क्वेरी पर उसी में टटोल रहा था।

"अपने एजेंट को मेमोरी दीजिए" का यही वह हिस्सा है जिसके बारे में कोई चेतावनी नहीं देता। एक मेमोरी जो सिर्फ़ बढ़ती है, मेमोरी नहीं है — वह एक लॉग है। और जिस लॉग को आप अर्थ से खोजते हैं, वह बढ़ने के साथ और शोर भरा होता जाता है, क्योंकि आपके द्वारा संग्रहीत हर लगभग-डुप्लिकेट रैंकिंग के उसी हिस्से के लिए प्रतिस्पर्धा करता है। अधिक यादें, बदतर रिकॉल। ठीक उसका उल्टा जिसके लिए आपने हामी भरी थी।

Octobrain इसका हमारा ओपन-सोर्स समाधान है — Rust में लिखा एक MCP मेमोरी सर्वर जो किसी भी एजेंट को स्थायी, अर्थ-आधारित खोज वाली दीर्घकालिक मेमोरी देता है। हमने इसे अप्रैल में पेश किया था, और 0.7.0 रिलीज़ में मेमोरी ने भूलना सीखा। यह लेख वही गाइड है जो काश मेरे पास होती: स्थायी LLM मेमोरी कैसे सेट करें जो तेज़ बनी रहे, दो विचारों का उपयोग करके — इसे प्रति-प्रोजेक्ट स्कोप दें, और इसे समेकित होने दें — साथ ही यह व्यावहारिक सवाल कि क्या संग्रहीत करें और क्या छोड़ दें।

असली समस्या: रिकॉल, संग्रहण नहीं

चीज़ें संग्रहीत करना आसान है। कोई भी की-वैल्यू स्टोर यह कर सकता है। एजेंट की दीर्घकालिक मेमोरी का कठिन हिस्सा वही है जो मानव स्मृति का कठिन हिस्सा है: सही चीज़ को सही क्षण पर वापस लाना, एक ऐसे ढेर में से जो बढ़ना कभी बंद नहीं करता।

Octobrain अर्थ से पुनर्प्राप्त करता है, की-वर्ड से नहीं। अंदरूनी तौर पर यह हर मेमोरी को एक स्थानीय मॉडल से एक वेक्टर में एम्बेड करता है (डिफ़ॉल्ट fastembed:nomic-ai/nomic-embed-text-v1.5 है, 768-आयामी, CPU पर चलता है, कोई API की नहीं) और उन्हें डिस्क पर एक LanceDB वेक्टर डेटाबेस में संग्रहीत करता है। एक remember क्वेरी उसी तरह एम्बेड होती है, और निकटतम वेक्टर वापस आते हैं। शुद्ध-अर्थ खोज को सटीक स्ट्रिंग चूकने से रोकने के लिए, खोज हाइब्रिड है: BM25 पूर्ण-पाठ और वेक्टर समानता को Reciprocal Rank Fusion से जोड़ा जाता है। इसके ऊपर एक वैकल्पिक क्रॉस-एनकोडर रीरैंकिंग है।

यह तंत्र अच्छा है। BEIR के SciFact बेंचमार्क पर, Octobrain की हाइब्रिड पुनर्प्राप्ति 0.742 nDCG@10 स्कोर करती है, जबकि क्लासिक BM25 का 0.665 और सादे एम्बेडिंग का 0.713 — फ़्यूज़न अकेले एम्बेडर के ऊपर लगभग +2 nDCG@10 जोड़ता है। पुनर्प्राप्ति की गुणवत्ता कभी अड़चन नहीं रही।

अड़चन यह थी कि हम उसे क्या खिला रहे थे। एक ही बग के बारे में पाँच परस्पर-व्यापी नोट उनमें से किसी को भी ऊपर नहीं उठाते; वे संकेत को बाँट देते हैं। शोर भरे कॉर्पस पर अच्छी पुनर्प्राप्ति भी एक शोर भरा जवाब ही है। तो समाधान बेहतर एम्बेडर नहीं है। यह कॉर्पस को संवारना है — स्वचालित रूप से, क्योंकि कोई भी इंसान एजेंट की मेमोरी को हाथ से नहीं छाँटेगा।

विचार एक: मेमोरी को प्रति-प्रोजेक्ट स्कोप दें

शोर का पहला स्रोत क्रॉस-कंटैमिनेशन है। अलगाव के बिना, हर प्रोजेक्ट की यादें एक ही पूल साझा करती हैं, और आपके वेब ऐप में "auth flow" की क्वेरी तीन असंबंधित सेवाओं के auth नोट खींच लाती है।

Octobrain यादों को स्कोप के आधार पर अलग करता है। एक स्कोप एक स्ट्रिंग है, और डिफ़ॉल्ट रूप से यह आपके git remote से व्युत्पन्न होता है। इसी ब्लॉग का रिपॉज़िटरी खोलिए और स्कोप github.com/muvon/muvon-web है। व्युत्पत्ति ठीक वैसी है जैसा आप अंदाज़ा लगाएँगे:

git remote get-url origin  →  host/org/repo

तो [email protected]:muvon/octobrain.git बन जाता है github.com/muvon/octobrain। कोई git remote नहीं? तब यह पथ-आधारित local/<parent>/<dir> स्कोप पर लौटता है ताकि एक टेम्पररी डायरेक्टरी को भी अलगाव मिले। और एक आरक्षित स्कोप है — खाली स्ट्रिंग "" — ग्लोबल यादों के लिए जो हर जगह दिखनी चाहिए।

वह ग्लोबल/प्रोजेक्ट बँटवारा पूरा मानसिक मॉडल है, और यह एक असली अंतर से मेल खाता है:

स्कोप यहाँ संग्रहीत करें उदाहरण
प्रोजेक्ट (github.com/org/repo) तथ्य जो इस रिपॉज़िटरी के भीतर सच हैं "टेस्ट pnpm -r test:unit से चलते हैं", "staging API को X-Acme-Token हेडर चाहिए", "यहाँ हमने token-bucket रेट लिमिटिंग चुनी"
ग्लोबल ("") तथ्य जो आपके बारे में, हर जगह सच हैं "टैब पसंद करता है", "हमेशा conventional-commit संदेश चाहता है", "fish उपयोग करता है, bash नहीं"

लाभ: जब आपका एजेंट ब्लॉग रिपॉज़िटरी में चलता है, एक remember कॉल केवल ब्लॉग-रिपॉज़िटरी यादों और आपकी ग्लोबल पसंदों के विरुद्ध रैंक करता है। उस दूसरी सेवा के auth नोट उम्मीदवार-समूह में होते ही नहीं। साफ़ उम्मीदवार, तेज़ रिकॉल — कोई समेकन चलने से पहले ही।

स्कोप कैसे सेट होता है

यदि आप Octobrain को किसी ऐसे MCP क्लाइंट के ज़रिए चलाते हैं जो सत्र हैंडशेक करता है, तो स्कोप वर्किंग डायरेक्टरी से स्वतः लॉक हो जाता है — एजेंट को इसके बारे में कभी सोचना नहीं पड़ता, और scope पैरामीटर टूल स्कीमा से पूरी तरह हटा दिया जाता है ताकि वह ग़लती न कर सके। सर्वर अपने MCP निर्देशों में उपलब्ध स्कोप तक बता देता है:

Available project scopes (pass as the 'scope' parameter):
  github.com/muvon/muvon-web

जब सत्र लॉक नहीं होता, टूल scope को सीधे एक्सपोज़ करते हैं, और memorize एक global: true फ़्लैग लेता है ताकि आप जहाँ भी हों, किसी तथ्य को जानबूझकर साझा स्कोप में डाल सकें। वह फ़्लैग केवल तभी दिखता है जब ओवरराइड करने को कोई लॉक प्रोजेक्ट स्कोप हो; वरना आप ख़ुद scope: "" पास कर देते हैं। टूल विवरण में पकाया गया मार्गदर्शन दो-टूक है: प्राथमिकताओं और परंपराओं जैसे क्रॉस-प्रोजेक्ट तथ्यों के लिए global उपयोग करें; प्रोजेक्ट-विशिष्ट ज्ञान के लिए इसे मत उपयोग करें। स्कोप का रिसाव ही वह शोर है जिससे आप बचने की कोशिश कर रहे हैं।

वह टूल सर्फ़ेस जिसे आप सचमुच बुलाते हैं

Octobrain जानबूझकर एक छोटा MCP सर्फ़ेस एक्सपोज़ करता है। आपके द्वारा एक्सपोज़ किया गया हर टूल एजेंट को हर बारी पर संदर्भ की कीमत देता है — वह कुछ भी करने से पहले स्कीमा पढ़ता है — इसलिए 0.7.0 रिलीज़ ने सर्फ़ेस को संकुचित किया और 0.8.0 ने उसे हल्का बनाए रखा। चार टूल, चार काम:

memorize    एक मेमोरी संग्रहीत करें (वैकल्पिक इनलाइन संबंधों के साथ)
remember    अर्थ-आधारित रिकॉल (1-हॉप ग्राफ़ पड़ोसी लौटाता है)
forget      हटाएँ (confirm=true चाहिए)
knowledge   बाहरी दस्तावेज़ और URL को इंडेक्स/खोज/पढ़ें/मैच करें

memorize

संग्रहण का क्रिया-शब्द। अनिवार्य: एक title (5–200 अक्षर) और content (10–10000 अक्षर)। बाकी सब वैकल्पिक है पर समझने योग्य:

  • memory_type — architecture, bug_fix, decision, user_preference, goal जैसी श्रेणी। रिकॉल पर फ़िल्टरिंग के लिए उपयोग होता है।
  • importance — 0.0–1.0। टूल विवरण असली एंकर देता है: उपयोगकर्ता-कथित तथ्य 0.8–1.0, निर्णय 0.7–0.9, बग फ़िक्स 0.6–0.8, AI अनुमान 0.3–0.6।
  • source — एक भरोसा-स्तर, या तो user_confirmed (उपयोगकर्ता ने स्पष्ट रूप से कहा) या agent_inferred (एजेंट ने निष्कर्ष निकाला)। यह दिखावटी नहीं है: पुष्ट तथ्य पुनर्प्राप्ति में ऊपर रैंक करते हैं, और परिणाम [CONFIRMED] / [INFERRED] टैग के साथ लौटते हैं ताकि एजेंट जान सके किस पर कितना भरोसा करना है।
  • tags, related_files — फ़िल्टरिंग के लिए और एक मेमोरी को उस कोड से बाँधने के लिए जिसका वह वर्णन करती है।
  • related_to — दिलचस्प वाला। मौजूदा यादों से टाइप किए गए लिंक का एक अरे, उसी कॉल में बनाया गया। इसी तरह आप दूसरी बार आए-गए बिना ग्राफ़ बनाते हैं।

एक ठोस संग्रहण, जैसे एक एजेंट इसे जारी करता:

{
	"title": "Rate limiting uses a token bucket",
	"content": "We rate-limit the public API with a token bucket (100 req/min/key), returning 429 + Retry-After on exhaustion. Chosen over fixed-window to avoid burst-at-boundary.",
	"memory_type": "decision",
	"importance": 0.85,
	"source": "user_confirmed",
	"tags": ["api", "rate-limiting"],
	"related_files": ["src/middleware/ratelimit.rs"]
}

remember

रिकॉल का क्रिया-शब्द, और वह जिसे आपको पहले बुलाना चाहिए — memorize से पहले (डुप्लिकेट संग्रहीत करने से बचने के लिए) और किसी कार्य के आरंभ में (संदर्भ लोड करने के लिए)। यह एक query लेता है जो या तो एक एकल स्ट्रिंग है या, बेहतर तरीक़े से, व्यापक अर्थ-कवरेज के लिए 2–5 संबंधित शब्दों का एक अरे। यह शीर्ष मिलानों के साथ-साथ उनके तात्कालिक ग्राफ़ पड़ोसियों को स्वचालित रूप से लौटाता है, ताकि एक मेमोरी पर मिलान उससे लिंक की गई यादें सामने ले आए।

यह उन फ़िल्टरों को भी लेता है जो हाल की रिलीज़ में सक्रिय हुए: समय-संबंधी सवालों जैसे "हमने पिछले हफ़्ते क्या तय किया" के लिए created_after / created_before (ISO-8601), गुणवत्ता-सीमा के लिए min_relevance, और संकुचन के लिए memory_types / tags। वह क्वेरी विस्तार जो धुँधले सवालों को बचा लेता है — Octobrain का HyDE-lite स्यूडो-रेलेवेंस फ़ीडबैक — स्वचालित रूप से चलता है और बिना LLM और बिना कॉन्फ़िगरेशन के एक उद्धृत +10–30% रिकॉल लॉन्ग-टेल क्वेरियों पर जोड़ता है।

forget

स्थायी विलोपन। confirm: true चाहिए — कोई आकस्मिक भूलना नहीं। एक के लिए memory_id से, या थोक हटाने के लिए query + फ़िल्टर से हटाएँ। टूल विवरण एक नियम रखता है जिसे आत्मसात करना चाहिए: यादों को सिर्फ़ इसलिए मत भूलिए कि वे पुरानी हैं — उसे ह्रास (decay) संभालता है (नीचे)। forget तभी करें जब कुछ वास्तव में ग़लत हो या अप्रचलित हो गया हो।

knowledge

मेमोरी का दूसरा आधा हिस्सा: बाहरी दस्तावेज़। memorize एजेंट द्वारा उत्पादित आसुत अंतर्दृष्टियों के लिए है; knowledge उस स्रोत-सामग्री के लिए है जिसे एजेंट पढ़ता है। पाँच कमांड, एक command फ़ील्ड से डिस्पैच होते हैं:

# एक एकल स्रोत को इंडेक्स और खोजें (तुरंत इंडेक्स होता है)
knowledge command=search query="how to handle async tasks" source=https://docs.rs/tokio/

# एक फ़ाइल या URL का पूरा पाठ पढ़ें (अंतिम उपाय जब खोज पतली हो)
knowledge command=read source=/path/to/design-doc.md

# इंडेक्स की गई सामग्री में regex से grep करें
knowledge command=match pattern="spawn_blocking|block_in_place"

# एक की के तहत कच्चा पाठ रखें और हटाएँ (सत्र-स्कोप)
knowledge command=store key=meeting-notes content="..."
knowledge command=delete key=meeting-notes

एक सख़्त नियम जिसे स्कीमा लागू करता है और सर्वर अपने निर्देशों में दोहराता है: source हमेशा एक एकल फ़ाइल या URL होता है, कभी डायरेक्टरी नहीं। डायरेक्टरी पास करें तो वह अस्वीकार होती है। समर्थित प्रकार हैं .html, .txt, .md, .pdf, .docx, और साथ में http/https URL।

विचार दो: मेमोरी को ख़ुद समेकित होने दें

स्कोप देना क्रॉस-प्रोजेक्ट शोर काटता है। यह एक-ही-प्रोजेक्ट-में-पाँच-लगभग-डुप्लिकेट-नोट वाली समस्या के लिए कुछ नहीं करता। उसी के लिए समेकन है, और 0.7.0 में मुख्य डिज़ाइन निर्णय इसे स्वायत्त बनाना था — क्योंकि एकमात्र चीज़ जिस पर आप भरोसा नहीं कर सकते, वह यह है कि कोई एजेंट (या इंसान) सफ़ाई करना याद रखेगा।

स्लीप समेकन

शुरुआत पर, यदि पिछले पास से एक दिन बीत गया हो, Octobrain एक "स्लीप" पास चलाता है: यह समान, हाल की, अब भी Working अवस्था वाली यादों के समूह ढूँढता है और हर समूह को एक एकल समेकित अंतर्दृष्टि में मोड़ देता है। मूल यादें मिटाई नहीं जातीं — वे घटे हुए महत्व के साथ Consolidated अवस्था में चली जाती हैं, नए मूल के नीचे उद्गम (provenance) के रूप में लिंक होकर। रेट-लिमिटिंग के पाँच धुँधले नोट एक साफ़, उच्च-विश्वास मेमोरी बन जाते हैं, और कच्चे नोट तक वापस का निशान ऑडिट के लिए बचा रहता है।

यह एक मार्कर फ़ाइल से नियंत्रित होता है, इसलिए यह सुस्त है — न कोई cron, न पृष्ठभूमि शेड्यूलर — और एक धीमा या असफल पास कभी कुछ नहीं रोकता। डिफ़ॉल्ट रूढ़िवादी हैं:

[memory]
sleep_consolidation_enabled          = true   # opt-out, not opt-in
sleep_consolidation_interval_hours   = 24     # at most once a day
sleep_consolidation_threshold        = 0.85   # cosine similarity to cluster
sleep_consolidation_min_cluster_size = 3      # need 3+ to bother
sleep_consolidation_max_age_days     = 7      # only recent Working memories

परीक्षण के लिए आप CLI से एक पास बाध्य कर सकते हैं — octobrain memory sleep-consolidate --threshold 0.85 --min-size 3 — पर मुद्दा यह है कि आपको कभी करना ही नहीं पड़े।

लक्ष्य-केंद्रित समेकन

स्लीप समेकन समानता पर समूह बनाता है। तेज़ संस्करण इरादे पर समूह बनाता है। Octobrain में एक goal मेमोरी प्रकार और एक असली जीवनचक्र है — Working → Consolidated → Archived। प्रवाह, पूरी तरह memorize के related_to लिंक के ज़रिए व्यक्त, यह है:

  1. उस कार्य के लिए जो आप करने की कोशिश कर रहे हैं, एक goal-प्रकार की मेमोरी memorize करें।
  2. रास्ते में हर निष्कर्ष के लिए, related_to: [{ target_id: <goal_id>, relationship_type: "achieves" }] के साथ memorize करें।
  3. जब कार्य समाप्त हो, सीखे-गए-सबक वाली नोट को relationship_type: "closes" के साथ memorize करें।

वह closes लिंक समेकन को स्वचालित रूप से ट्रिगर करता है — कोई अलग टूल कॉल नहीं। समापन नोट समेकित मूल बन जाती है (इसका महत्व max(sources) * 1.1 तक बढ़ा), और हर achieves स्रोत घटे हुए महत्व के साथ Consolidated अवस्था में चला जाता है, ऑडिट के लिए अब भी खोजने योग्य। पाँच बिखरे निष्कर्ष एक ऐसी मेमोरी में सिमट जाते हैं जो कुछ अर्थ रखती है, उस इरादे से जुड़ी जिसने इसे जन्म दिया।

यही यह भी समझाता है कि स्वतंत्र consolidate टूल अब MCP सर्फ़ेस में क्यों नहीं है: किसी लक्ष्य को बंद करना अब बस एक closes लिंक वाला memorize है, और स्लीप समेकन ख़ुद चलता है। कम टूल, वही ताक़त। (octobrain memory consolidate <goal-id> CLI कमांड हाथ से और प्रशासनिक उपयोग के लिए अब भी मौजूद है।)

अर्ध-आयु ह्रास: रैंकिंग संकेत के रूप में भूलना

तीसरा तंत्र लगातार चलता है। हर मेमोरी का महत्व एक एबिंगहाउस अर्ध-आयु अनुसूची पर ह्रासित होता है — और हर बार जब आप किसी मेमोरी तक पहुँचते हैं, वह सुदृढ़ होती है। बार-बार याद की गई यादें मज़बूत रहती हैं; जिन्हें कोई नहीं छूता वे रैंकिंग में धीरे-धीरे फीकी पड़ जाती हैं।

[memory]
decay_enabled            = true
decay_half_life_days     = 90    # higher = memories stay relevant longer
access_boost_factor      = 1.2   # reinforcement multiplier per access
min_importance_threshold = 0.05  # floor — decay never deletes

दो सुरक्षा-उपाय इसे सुरक्षित बनाते हैं। एक महत्व का फ़र्श है — एक बासी मेमोरी पीछे की ओर डूबती है पर कभी ग़ायब नहीं होती, क्योंकि ह्रास एक री-रैंकिंग संकेत है, विलोपन नहीं। और एक्सेस गिनतियाँ रीस्टार्ट के बीच बनी रहती हैं, इसलिए मेमोरी का यह बोध कि "क्या गर्म है" हर सत्र में रीसेट नहीं होता। शुद्ध प्रभाव यह है कि जिन यादों को आप सचमुच उपयोग करते हैं वे ऊपर तैरती हैं और जिन्हें आपने एक बार संग्रहीत किया और कभी ज़रूरत न पड़ी वे डूब जाती हैं, आपकी ओर से शून्य संवारने के साथ। ठीक इसीलिए forget टूल एजेंट से कहता है कि चीज़ों को पुराना होने के कारण मत हटाएँ — ह्रास पहले से ही उसे संभालता है, सुघड़ता से, इतिहास खोए बिना।

क्या संग्रहीत करें, और क्या छोड़ दें

तंत्र आपको बस एक हद तक ले जाता है। जिस अनुशासन ने हमारे रिकॉल को ठीक किया, वह यह तय करना था कि किस चीज़ को मेमोरी मिलनी चाहिए। एजेंट की प्रवृत्ति सब कुछ संग्रहीत करने की है; सही नीति उसके उलट के करीब है।

संग्रहीत करें:

  • निर्णय और उनका औचित्य। "हमने burst-at-boundary के कारण फ़िक्स्ड-विंडो के बजाय token-bucket चुना।" क्यों वह हिस्सा है जिसे फिर से बनाना महँगा है।
  • इस रिपॉज़िटरी के बारे में मुश्किल से अर्जित तथ्य। ग़ैर-स्पष्ट टेस्ट कमांड, staging हेडर, वह माइग्रेशन जो पहले चलना चाहिए। वे चीज़ें जिन्हें एजेंट वरना हर सत्र फिर से खोजता (या फिर से अनुमान लगाता) है।
  • उपयोगकर्ता प्राथमिकताएँ — ग्लोबल स्कोप में। एक बार कहीं, हर जगह सच।
  • मूल कारण सहित बग फ़िक्स। "webhook ठीक किया" नहीं बल्कि "webhook रीट्राई को आइडेमपोटेंसी की चाहिए थी; उनके बिना, रीट्राई दोहरा शुल्क लगाते थे।"

संग्रहीत मत करें:

  • क्षणिक अवस्था। वर्तमान शाखा, वर्किंग ट्री में क्या है, आज कौन सा टेस्ट विफल हो रहा है। यह अगले सत्र से पहले बासी हो जाता है और उसके बाद हमेशा के लिए शुद्ध शोर बन जाता है।
  • कुछ भी जो आसानी से फिर से निकाला जा सकता है। यदि एक-पंक्ति का शेल कमांड इसे फिर बना देता है, तो वह कमांड ही मेमोरी है — उसका आउटपुट नहीं।
  • असत्यापित अटकलें, मानो वे तथ्य हों। यदि एजेंट को कोई अंदेशा दर्ज करना ही हो, इसी के लिए source: agent_inferred और कम महत्व हैं। अनिश्चितता को टैग करें ताकि पुनर्प्राप्ति इसे पुष्ट ज्ञान से नीचे रखे।
  • एक ही अंतर्दृष्टि पाँच बार। memorize से पहले remember बुलाएँ। यदि कोई लगभग-मिलान लौटे, एक और लगभग-डुप्लिकेट ढेर करने के बजाय उसे अपडेट या प्रतिस्थापित करें।

उस अंतिम बिंदु को टूल का समर्थन है। जब कोई नया तथ्य पुराने को प्रतिस्थापित करे — कोई मान बदला, कोई निर्णय पलटा — नए तथ्य को related_to: [{ target_id: <old_id>, relationship_type: "supersedes" }] के साथ memorize करें। तब पुनर्प्राप्ति वर्तमान तथ्य को अप्रचलित से ऊपर रखती है, जो इतिहास के लिए खोजने योग्य बना रहता है। आप रिकॉर्ड को खोए बिना सुधार देते हैं।

इसे सेट करना

इंस्टॉल करें और इस पर एक MCP क्लाइंट इंगित करें।

# crates.io
cargo install octobrain

# या macOS पर Homebrew के ज़रिए
brew install muvon/tap/octobrain

पहले CLI से पूरा चक्र आज़माएँ:

octobrain memory memorize --title "API Design Pattern" \
  --content "Use REST for CRUD, GraphQL for complex queries" \
  --memory-type architecture --tags "api,design"

octobrain memory remember "how should I design APIs"

फिर इसे एक MCP क्लाइंट से जोड़ें। Claude Desktop के लिए, claude_desktop_config.json में जोड़ें:

{
	"mcpServers": {
		"octobrain": {
			"command": "/path/to/octobrain",
			"args": ["mcp"]
		}
	}
}

stdio के लिए octobrain mcp चलाएँ, या HTTP के लिए octobrain mcp --bind 0.0.0.0:12345। संग्रहण ~/.local/share/octobrain/ (macOS/Linux) या %APPDATA%\octobrain\ (Windows) में रहता है, और प्रोजेक्ट यादें ऊपर वर्णित अनुसार स्कोप द्वारा अलग होती हैं। हर चीज़ के समझदार डिफ़ॉल्ट हैं — स्लीप समेकन, ह्रास, हाइब्रिड खोज और HyDE सभी बॉक्स से बाहर चालू हैं। सभी नॉब्स का पूरा सेट रिपॉज़िटरी में config-templates/default.toml में प्रलेखित है।

जिस एक कॉन्फ़िग निर्णय को जानबूझकर लेना सार्थक है, वह decay_half_life_days है। 90-दिन का डिफ़ॉल्ट एक लगातार विकसित होते कोडबेस के लिए उपयुक्त है। एक स्थिर प्रोजेक्ट के लिए इसे बढ़ाएँ जहाँ निर्णय लंबे समय तक वैध रहते हैं; एक तेज़ी से बदलते प्रोटोटाइप के लिए इसे घटाएँ जहाँ पिछले महीने का सच इस महीने का झूठ है।

अक्सर पूछे जाने वाले सवाल

क्या भूलना जानकारी खो देता है?

नहीं। ह्रास एक फ़र्श वाला रैंकिंग संकेत है — कम-एक्सेस यादें डूबती हैं पर कभी मिटती नहीं। समेकन स्रोतों को Consolidated अवस्था में ले जाता है, घटा हुआ पर अब भी खोजने योग्य, उनके मूल के नीचे उद्गम के रूप में लिंक। एकमात्र चीज़ जो सचमुच मिटाती है, वह confirm: true वाला एक स्पष्ट forget है। आप हमेशा पीछे की ओर निशान खोज सकते हैं।

memorize, knowledge से कैसे अलग है?

memorize उन अंतर्दृष्टियों को संग्रहीत करता है जिन्हें एजेंट उत्पादित करता है — निर्णय, फ़िक्स, निष्कर्ष। knowledge उन दस्तावेज़ों को इंडेक्स करता है जिन्हें एजेंट पढ़ता है — डॉक्स, डिज़ाइन फ़ाइलें, URL — ताकि वह उन्हें खोज और उद्धृत कर सके। आसुत बुद्धि बनाम स्रोत-सामग्री। अलग जीवनचक्र, अलग टूल।

क्या मुझे स्कोप हाथ से संभालने होंगे?

आमतौर पर नहीं। सत्र हैंडशेक करने वाले MCP क्लाइंट के साथ, स्कोप आपकी वर्किंग डायरेक्टरी के git remote से लॉक होता है और scope पैरामीटर स्कीमा से हटा दिया जाता है। आप स्कोप को स्पष्ट रूप से केवल एक ग्लोबल प्राथमिकता संग्रहीत करने के लिए छूते हैं (global: true, या scope: "")।

सिर्फ़ चार MCP टूल क्यों? दूसरे मेमोरी सर्वर एक दर्जन एक्सपोज़ करते हैं।

क्योंकि आपके द्वारा एक्सपोज़ किया गया हर टूल वह स्कीमा है जिसे मॉडल हर बारी फिर से पढ़ता है, और कैटलॉग बढ़ने के साथ टूल-चयन की सटीकता घटती है। समेकन स्वायत्त हो गया और relate/consolidate memorize के संबंध-लिंक में सिमट गए, इसलिए जिन कामों को पहले अपना टूल चाहिए था, उन्हें अब नहीं चाहिए। प्रशासनिक काम के लिए CLI में अब भी पूरा सेट है।

क्या मुझे API की या GPU चाहिए?

नहीं। डिफ़ॉल्ट एम्बेडिंग मॉडल fastembed के ज़रिए स्थानीय रूप से CPU पर चलता है — कोई की नहीं, कोई नेटवर्क नहीं। क्लाउड एम्बेडर (Voyage, OpenAI, Google, Jina) समर्थित हैं यदि आप उच्च गुणवत्ता चाहते हैं, पर वे वैकल्पिक हैं।

जिस चीज़ ने हमारे रिकॉल को ठीक किया, वह बेहतर खोज एल्गोरिदम नहीं था — Octobrain की पुनर्प्राप्ति तो बेंचमार्क पर BM25 को पहले ही हरा रही थी जबकि हम डूब रहे थे। यह यह स्वीकारना था कि उपयोगी बने रहने के लिए मेमोरी को भूलना ही पड़ता है। इसे ऐसे स्कोप दें कि सही चीज़ें उम्मीदवार भी बनें; इसे समेकित होने दें ताकि डुप्लिकेट सिमट जाएँ; इसे ह्रासित होने दें ताकि मृत भार डूब जाए। तब एजेंट कबाड़ के दराज़ में टटोलना बंद कर देता है और एक मेमोरी से जवाब देने लगता है।

निर्णय और मुश्किल से अर्जित तथ्य संग्रहीत करें। क्षणिक शोर छोड़ें। memorize से पहले remember बुलाएँ। बाकी को ख़ुद चलने दें।

— Don

Octobrain Apache-2.0 के अंतर्गत ओपन सोर्स है। यहाँ वर्णित समेकन और ह्रास तंत्र 0.7.0 में आया; स्कोपिंग और हल्का टूल सर्फ़ेस 0.8.0 में जारी रहा। यदि कोई सेटअप बारीकी अटका दे या आप किसी स्कोप/ह्रास डिफ़ॉल्ट को बदलवाना चाहें, एक issue खोलें — हम उन्हें पढ़ते हैं।